Hi
I have a network of 5 nodes whose hardware addresses are 00:12:6d:03:00:00:10:xx where the XX varies from 01 to 05. There is also a border router with a completely different address.
As you can see in the attached picture, sometimes there are unicast neighbor advertisements sent to nonexistent addresses that are the reverse of the one doing the solicitation. In the picture, this is fe80::510:0:36d:1202 instead of fe80::212:6d03:0:1005
I checked the RFC’s and I can’t see why this would be done deliberately, especially as those frames never get acked, so the other side is certainly not expecting this.
Is there a HTONLL bug somewhere in the ND code?
It doesn’t happen all the time, so it can’t be a bug on the main code path, I spent a couple hours looking for it but no luck (I don’t know the codebase well).
Any help would be appreciated
Thanks
Michael
Hi Michael!
As you can see in the attached picture, sometimes there are unicast
neighbor advertisements sent to nonexistent addresses that are the reverse
of the one doing the solicitation. In the picture, this is
fe80::510:0:36d:1202 instead of fe80::212:6d03:0:1005
I checked the RFC's and I can't see why this would be done deliberately,
especially as those frames never get acked, so the other side is certainly
not expecting this.
Is there a HTONLL bug somewhere in the ND code?
It doesn't happen all the time, so it can't be a bug on the main code path,
I spent a couple hours looking for it but no luck (I don't know the
codebase well).
Can you please add some debugging lines in
sys/net/gnrc/network_layer/ndp/gnrc_ndp.c
at line 178, 185 and 190 and set ENABLE_DEBUG to 1 in
sys/net/gnrc/network_layer/ndp/internal/gnrc_ndp_internal.c
to figure out which path is taken when this happens?
Cheers,
Oleg
Thanks!
You are a lifesaver, that has significantly improved the reliability of my mesh, and the demo is tomorrow! I owe you one.
Regards
Michael