Gary,
Interesting. Looking at that code I would think it wouldn't work any different than the original because retries is set to 1, so the first entrance into the first while will reduce that to 0 causing you to never enter that second loop. That should result in the same behavior as if the second loop wasn't even there.
If the second ioctl fails, the request still went out to the other device, so will populate the arp cache for the next sync. That's how it worked in my setup.
Can you give more details on what is not working?
FYI, l'm going to be in the Grand Canyon the next few days and likely won't be able to respond.
Thanks!
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message -------- From: gary guohuizou2000@sina.com Date: 10/25/18 3:06 AM (GMT-07:00) To: 'Sven Eckelmann' sven@narfation.org, Jonathan Haws jhaws@sdl.usu.edu Cc: b.a.t.m.a.n@lists.open-mesh.org Subject: RE: [B.A.T.M.A.N.] alfred and batadv-vis issue
Hi Sven and Jon,
The patch does NOT work for me.
I review the code again and find the issue. The following code may make my testbed work.
--- a/util.c +++ b/util.c @@ -122,14 +122,14 @@ int ipv4_arp_request(struct interface *interface, const alfred_addr *addr, arpreq.arp_dev[sizeof(arpreq.arp_dev) - 1] = '\0';
if (ioctl(interface->netsock, SIOCGARP, &arpreq) < 0) - return -1; - - while (retries-- && !(arpreq.arp_flags & ATF_COM)) { - ipv4_request_mac_resolve(addr); - usleep(200000); - - if (ioctl(interface->netsock, SIOCGARP, &arpreq) < 0) - return -1; + { + while (retries-- && !(arpreq.arp_flags & ATF_COM)) { + ipv4_request_mac_resolve(addr); + usleep(200000); + + if (ioctl(interface->netsock, SIOCGARP, &arpreq) < 0) + return -1; + } }
Regards, Gary
-----Original Message----- From: Sven Eckelmann sven@narfation.org Sent: 2018年10月25日 14:15 To: Jonathan Haws jhaws@sdl.usu.edu Cc: guohuizou2000@sina.com; b.a.t.m.a.n@lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] alfred and batadv-vis issue
On Mittwoch, 24. Oktober 2018 18:39:43 CEST Jonathan Haws wrote: [...]
I just submitted a patch that pulls the request_mac_resolve() routine from batctl, modifies it appropriately, and uses it when MAC resolution isn't from the cache.
I've tested this with my VM setup here and it works properly (after I verified that the nodes were not sharing messages first).
Gary - can you try the patch with your setup and make sure it solves the problem in your setup as well?
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@sina.com
when you've successfully tested it (FirstName and LastName have to be replaced with your actual name).
Kind regards, Sven