alfred and batadv-vis issue

Hello guys,

I setup a testbed like this. (BBN = backbone node)

Switch ---------->BBN1 --------------->MP1

        |
		------->BBN2---------------->MP2

MP1 and MP2 may select BBN1 or BBN2 as gateway.
On both MP1 and MP2, I enable Alfred and batadv-vis as follows:
alfred -i br0 -4 224.0.0.1 -m &
batadv-vis -i bat0 -s

when I run batadv-vis again on MP1, I can't get the info from MP2. If I ping the ip address of MP2 from MP1, MP1 will get MP2's mac address by arp. And then I run batadv-vis again, I can get the data from MP2 now.

Is there any configure or method to get MP2's info without ping test?

Thanks,
Gary

Looks like you are using the experimental IPv4 support which I don't want to actively support. So Jonathan Haws should take care of this.

Kind regards,
Sven

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

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 <[email protected]>
Sent: 2018年10月23日 1:36
To: [email protected]
Cc: [email protected]; [email protected]
Subject: Re: [B.A.T.M.A.N.] alfred and batadv-vis issue

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

It's still at least a week or so out...

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. When I looked at this a few months ago the way it was using the ARP table to pull the MAC address didn't work right and required a separate ARP request to have it work properly.

When I have a chance to dig back into it and develop the fix I can provide more details, but that's what I recall right now. It didn't make sense to me at first either based on the symptoms, but when I dug through the code I realized that was what was required and just didn't have time to put the fix in then.

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

Hi Sven and Jon,

Can you add a payload in multicast packets to carry the mac address, so we can get the mac from the payload without concerning about whether it is IPv4 or IPv6?

Regards,
Gary

-----Original Message-----
From: Sven Eckelmann <[email protected]>
Sent: 2018年10月23日 14:29
To: Jonathan Haws <[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: [B.A.T.M.A.N.] alfred and batadv-vis issue

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

Thanks, Sven, for the clarification!

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!

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/83faa3126d6cc984fff10760aa975bacec043632:/functions.c#l537
and
https://git.open-mesh.org/batctl.git/blob/83faa3126d6cc984fff10760aa975bacec043632:/functions.c#l702

Kind regards,
Sven

https://git.open-mesh.org/batctl.git/blob/83faa3126d6cc984fff10760aa975bacec043632:/functions.c#l537

https://git.open-mesh.org/batctl.git/blob/83faa3126d6cc984fff10760aa975bacec043632:/functions.c#l702

Are these new routines? I may have been looking at old code and don't remember seeing these there. I'm seeing that these will do what we need
- perform a request on the network if the entry is not in the cache?

Thanks!

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

https://git.open-mesh.org/batctl.git/blob/83faa3126d6cc984fff10760aa975bacec043632:/functions.c#l537

https://git.open-mesh.org/batctl.git/blob/83faa3126d6cc984fff10760aa975bacec043632:/functions.c#l702

Sven and Gary,

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?

And Sven, thanks for pointing out those routines - this approach makes much more sense!

Thanks!
Jon

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

when you've successfully tested it (FirstName and LastName have to be replaced with your actual name).

Kind regards,
Sven

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.

@@ -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 <[email protected]>
Sent: 2018年10月25日 14:15
To: Jonathan Haws <[email protected]>
Cc: [email protected]; [email protected]
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:
[...]

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

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 Montag, 29. Oktober 2018 17:07:26 CET Jonathan Haws wrote:
[...]

Uhm, this sounds extremely wrong to me. Why would you receive your own UDP packets (push_data, announce_master, status_txend) again in the first place? See netsock_own_address for the code which drops such packets in the main recv function - you should know it because you've tried to modify it for IPv4 support.

But your memory initialization is completely broken and have to be fixed. Right now, you are just comparing uninitialized memory regions against each other.

Kind regards,
Sven

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.

On Montag, 29. Oktober 2018 18:25:19 CET Jonathan Haws wrote:
[...]

There is no commit yet and it is still queued in patchwork [1]. I am still waiting for a reply with Tested-by: ... line from you.

Kind regards,
Sven

[1] https://patchwork.open-mesh.org/patch/17596/

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 <[email protected]>
Sent: 2018年10月30日 0:07
To: [email protected]; [email protected]
Cc: [email protected]
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?

Right - that is what I found as well as I was doing more testing. My previous testing had an entry that was simply being marked as incomplete instead of being fully flushed.

The latest patch resolves that oversight. From the results you sent it appears that the latest patch is working for you. If so, can you update the patch with a Tested By: name <email> line in patchwork (
https://patchwork.open-mesh.org/patch/17597/)?

Thanks!
Jon

On Dienstag, 30. Oktober 2018 15:20:56 CET Jonathan Haws wrote:
[...]

No, the line must be "Tested-by: $Full $Name <$email@$address.$something>" something else is not detected by Patchwork. The last "Tested By: $Full $Name <$email@$address.$something>" from you for example wasn't detected and I had to manually add it to the commit message.

Kind regards,
Sven