On Tue, 2018-10-23 at 08:29 +0200, Sven Eckelmann wrote:
On Dienstag, 23. Oktober 2018 04:04:42 CEST Jonathan Haws wrote: [...]
I have a doubt for the issue. Alfred should send the info by multicast packets. So the packet's dst mac address should be multicast mac address. The packet with multicast mac address should be received by all group member, isn't it? Why does the mesh point need peer's mac address for sending the info?
The rest of the devs may be able to answer better, but I believe it is how alfred does its data storage and mapping of the source.
Correct, alfred is storing the data from each server using its mac address. It is also looking up the TQ of master servers via the mac address. And the mac address is expected to be extractable from the EUI64 based link-local IPv6 address.
Thanks, Sven, for the clarification!
And of course, Jonathan's IPv4 implementation must get the mac address using different methods. It is using the function ipv4_arp_request to get the information from IPv4 neighbor table. And it looks like his implementation is missing a reliable way to fill this neighbor table.
Yes - my plan is to implement a manual ARP request, which if that fails then the behavior will be as it is now. However, on success, it will have the correct MAC and everything will be good to go.
Thanks!