Hi Hervé
When you send a UDP frame you need only konw its IP address. If the MAC address of this is not in the cache, the ARP task will automatically try to resolve it. It will resolve it by ARP requests of the IP address is within the local sub-net or it will send it to the gateway's MAC address if not (if the gateway is not cached it will resolve it first).
If the UDP frame could be sent the function fnSendUDP() will return the length fo the frame sent. In this case the IP address was already in cache.
If fnSendUDP() returns 0 it means that the ARP task needs to resolve it and you ust be prepated to repeat the UDè frame once thsi is completed.
ARP_RESOLUTION_FAILED will be received as message if ARP could not resolve the address.
ARP_RESOLUTION_SUCCESS will be received once the address has been resolved - and here is where you need to try again.
Therefore, normally, you should never need to know the MAC address of the received when working with UDP.
In the case of a listern, which has just received a UDP frame, the sender's IP address (or gateway if it arrived via a gateway) should always be cached.
If it is a broadcast UDP frame outside of the sub-net it could have arrived directly (not via gateway) in which case an attempt will be made to send it through the default gateway. This may be your problem, since the gateway may not be able to deliver it to the local IP addresses outside of it's own sub-net - you may need to ensure that its sub-net contains the sender(?)
Eg.
Your device has sub-net 255.255.255.0 - eg. 192.168.0.99
The broadcasting device has 255.255.254.0 - eg. 192.168.1.100
Your gateway has 255.255.254.0 (eg. 192.168.0.1) - this shoud be able to route your replies to it to the sender.
However, if the gateway has 255.255.255.0 it will also not be able to communicate with the broadcasting device since it is not in its sub-net.
Does this correspond to your experiences?
Regards
Mark