Hi Jon, Long for your fix. Thanks. 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? Regards, Gary -----Original Message----- From: Jonathan Haws <jhaws(a)sdl.usu.edu> Sent: 2018年10月23日 1:36 To: sven(a)narfation.org Cc: b.a.t.m.a.n(a)lists.open-mesh.org; guohuizou2000(a)sina.com Subject: Re: [B.A.T.M.A.N.] alfred and batadv-vis issue On Thu, 2018-10-18 at 08:22 +0200, Sven Eckelmann wrote: I am aware of this issue, but was under the impression I was the only one it affected. I'm working on a fix (basically check the ARP table and if a record doesn't exist for the MAC then run an ARP query; if that query fails then report a error) and I hope to have it working soon. We have been working around this issue in the same manner as you describe for the time being. Thanks, Jon

On Dienstag, 23. Oktober 2018 04:04:42 CEST Jonathan Haws wrote: [...] 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. 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. Kind regards, Sven

On Dienstag, 23. Oktober 2018 17:52:54 CEST gary wrote: [..] You can do a lot - but I will not accept such a change in alfred. Kind regards, Sven

On Dienstag, 23. Oktober 2018 13:50:42 CEST Jonathan Haws wrote: [...] Manual ARP request sounds weird. What about https://git.open-mesh.org/batctl.git/blob/83faa3126d6cc984fff10760aa975bace… and https://git.open-mesh.org/batctl.git/blob/83faa3126d6cc984fff10760aa975bace… Kind regards, Sven

On Dienstag, 23. Oktober 2018 14:11:41 CEST Jonathan Haws wrote: [...] These routines are not in alfred yet - they are in batctl. And we use them there for the translate subcommand (translate an IP to the responsible originator). And yes, they check whether the entry is available and if not then they will try to send something towards the remote device. They only have to be adjusted for alfred and integrated in your IPv4 codepath(s). Kind regards, Sven

On Mittwoch, 24. Oktober 2018 18:39:43 CEST Jonathan Haws wrote: [...] The patch can be found at https://patchwork.open-mesh.org/patch/17552/ (or directly on the mailing list) Please reply via mail with a line Tested-by: FirstName LastName <guohuizou2000(a)sina.com> when you've successfully tested it (FirstName and LastName have to be replaced with your actual name). Kind regards, Sven

Gary - can you describe to me some more details of your test setup? How are BBN1 and BBN2 configured? Are they machines with two different Ethernet interfaces (i.e. each having one connected to the downstream node and one connected to the switch)? Are they more or less acting as routers (i.e. doing IP forwarding)? The testing I have been doing is just connecting MP1 and MP2 to the same switch and having them on the same subnet. Is that not the case in your setup? The other thing I am interested in is what is the result of the first ioctl() call? I'm guessing it has to be failing, or else the patch would have worked for you. Can you add a print statement before the return that would give the error string as well as the interface and IP (i.e. interface->interface and addr->ipv4.s_addr)? That would be helpful in helping me find the root issue. One thing to note (and Sven, maybe you can tell me if this is expected): in my testing I found that alfred is getting into this ipv4_arp_request call for the local node as well, thus the very first ioctl() will fail with "No such device or address". Should there be a check for this being the local node and just discard it before making the check or is making the check all the time then discarding okay?

On Mon, 2018-10-29 at 17:48 +0100, Sven Eckelmann wrote: I need to double check - I had thought I explicitly disabled IP_MULTICAST_LOOP, but if not I need to. This would be my first guess at why we'd be seeing our own UDP packets. It looks like you fixed the memory initialization issue in your latest commit (recv.c, zeroing the alfred_source variable)? I'll pull this and see how it affects the behavior.

In my test setup, both BBN1/2 and MP1/2 are in one subnet. ipv4_arp_request ret = -1 interface =0x120020070 sipaddr = 0x50505f7 (the first try, sipaddr is right) ipv4_arp_request ret = 0 interface =0x120020070 sipaddr = 0x50505f7 (the second try with latest patch) the cause should be there is no arp entry for the source ip address at the first try. -----Original Message----- From: Jonathan Haws <jhaws(a)sdl.usu.edu> Sent: 2018年10月30日 0:07 To: guohuizou2000(a)sina.com; sven(a)narfation.org Cc: b.a.t.m.a.n(a)lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] alfred and batadv-vis issue Gary - can you describe to me some more details of your test setup? How are BBN1 and BBN2 configured? Are they machines with two different Ethernet interfaces (i.e. each having one connected to the downstream node and one connected to the switch)? Are they more or less acting as routers (i.e. doing IP forwarding)? The testing I have been doing is just connecting MP1 and MP2 to the same switch and having them on the same subnet. Is that not the case in your setup? The other thing I am interested in is what is the result of the first ioctl() call? I'm guessing it has to be failing, or else the patch would have worked for you. Can you add a print statement before the return that would give the error string as well as the interface and IP (i.e. interface->interface and addr->ipv4.s_addr)? That would be helpful in helping me find the root issue. One thing to note (and Sven, maybe you can tell me if this is expected): in my testing I found that alfred is getting into this ipv4_arp_request call for the local node as well, thus the very first ioctl() will fail with "No such device or address". Should there be a check for this being the local node and just discard it before making the check or is making the check all the time then discarding okay?

On Dienstag, 30. Oktober 2018 15:20:56 CET Jonathan Haws wrote: [...] No, the line must be "Tested-by: $Full $Name <$email(a)$address.$something>" something else is not detected by Patchwork. The last "Tested By: $Full $Name <$email(a)$address.$something>" from you for example wasn't detected and I had to manually add it to the commit message. Kind regards, Sven