Hi folks.
I need to initialize an W5500 equipment.
To do that , the configuration equipment will send an UDP broadcast packet to a certain receiver port , with a certain string and data, to trigger the w5500 equipment to initialize. The problem is that, to answer the initialization request, the w5500 needs to know the MAC address of the sender. With that the w5500 may be initialized to point the answer through the SEND-MAC Sn_DHAR .
Using ARP method works only if the w5500 IP is in the same subnet of the sender. Using SEND-MAC command with Sn_DHAR filled with MAC address of the sender would work with any configured SIP of w5500.
The question is: how to obtain the sender MAC address to fill Sn_DHAR?
Is it possible or the sender should insert its own MAC address in the data field?
That , although possible , is not desirable since I want to send the initializing command through a Linux socat manual procedure.
The question is why your W5500 needs to know it, and why IP address is not enough.
In general, if you need to know MAC, the information which is not route-able, you can supply it within the packet data.
I solved it in another way: responding as broadcast MAC ff:ff:ff:ff:ff:ff .
I am developing an initializing procedure for an equipment that uses W5500 chip.
It may be necessary some times to configure the equipment without knowing its IP/SN/GW/DHCP mode/DNS mode.
To accomplish that, the equipment is plugged in the network with any value for the settings.
In a computer (manually with SOCAT terminal window or with a special App) an UDP broadcast packet to port XXXX with ASCII trigger string , password, and data is sent through network.
The equipment listens on port UDP XXXX and configures the network parameters and any other initializing information needed or simply gives back information like serial number, time etc…
To send the answer the ARP protocol only works if the network parameters are of the same subnet of the computer. In a first installation or when moving the equipment the network parameters are usually different.
The other way is to fill the Sn_DHAR with: or the computers MAC, or with MAC broadcast and send the answer UDP packet with SEND_MAC. So the computers App or terminal presents the answer to operator.
I was trying to use the computer’s MAC acquired from the computers request packet. But it appears to be not available for reading in W5500. So using broadcast solves the problem. Doing this, it is not necessary for the computer to send its MAC address inside the data field of the request broadcast UDP packet. The procedure is made for simple human texting in a SOCAT terminal, so any extra procedure needed rises the complexity of the equipment configuration.
Its works perfectly in any network combinations: wired, WiFi , bridges, Power Line Modems repeaters etc. I tested with a lot of equipments available.
Thanks anyway.
Eugeny, since you give a lot of answers in this community I would like to post some clues that you may already know (or not) and may be given to other developers.
As some clues to others that develop W5500 equipments I would say:
-
if using a self generated MAC address (in my case it is part of the serial number) take care to choose a MAC with bits in the second byte that fixes MAC mode to UNICAST and not use OUI exclusive bit. Both bits are documented and available in Wikipedia or other source. I spent a lot of time analyzing network malfunction until I discovered that my own MAC address was MULTICAST. The routers went crazy.
-
For those that do not have extra pins for controlling a W5500 Reset pin or SCSn pin to use variable lenght data mode , it is possible to add a very simple reset circuit from the SCLK clock pin.
Using an SPI mode #3 the clock is normally at level 1 and during activity changes to level 0 generating clock pulses but always returning to level 1 after data exchange. Configuring the SPI properly to mode 1 or setting the SCLK pin to level 0 during 5~10ms , the RST signal goes low reseting W5500.
The trick is that the time constant of the circuit is very different from 1 and 0 levels because of the diode and resistors. So during normal operation the reset signal is always above level 1, not resetting the device.
To reset the chip, in a special part of the initializing code, keep the clock low for 5~10ms. The chip will be reset and then continue to main code for operating the W5500.
This is a very economic solution to avoid using precious microcontroller pins for reset or SPI strobe.
Without this , if the W5500 gets out of sync with the microntroller during power on/off or any SW malfunction, it is not possible to recover the W5500 to a known state without a reset.
Another advantage of the circuit is that is eliminates the use of special power on reset circuits for 3V3 operation. The microcontroller may control everything, reseting the W5500 if it stops responding polling commands.
So only 3 SPI pins: MISO, MOSI e SCLK are used for controlling W5500 in fixed lenght data mode with full funcionallity. Many commands to W5500 use 1/2/4 bytes and fixed mode lenght is as efficient as variable mode. Only when packet data needs large buffer exchange the variable mode is more efficient. But in IOT applications this is not so important since in this kind of use the equipments are simpler.
With Atmel AVR8 microcontrollers the USART/SPI HW is perfect to access a W5500 chip.
Thank you so much for your knowledge sharing!
I also caught it, and several people here on the forum did it too.
Very interesting idea.
Do not forget about security and safety. Not sure it is good idea sending sensitive information openly, and using broadcast. As I understand you make a kind of DHCP clone, but with slightly different functionality. I propose perform handshaking first, without using any sensitive information, and then use another type of (secure) connection to pass sensitive info.
There is a more secure channel for changing parameters. The initial setup is the problem since the equipment does not have any keyboard or display.
In fact the equipment has 3 interfaces:
1- the initial setup (UDP server), used for initial setup or maintenance. In private networks.
It also needs a password (clear text) but in private network. Maybe even on a table with a cable to a switch and/computer.
2- another TCP server interface for managing most of commands through a computer or App. Private network. Home network or condominium reception. Used with password (clear text) but in private network.
3- TCP client interface to connect to an internet cloud server with AES256 encryption.
No password. Authentication is done by the AES encryption and a pre-provisioning of the equipment with the server inserting a particular and unique key/initial vector for the device. This is far more secure. And since the connection is started by the device (not answered by it) it would be very difficult to send hacked commands to it.
The initial setup will be simplified as soon as I put the DHCP and DNS to work. Most of configuration would be solved without any initial setup with the default values of DHCP and DNS turned on.
