aodvv2: port to new network stack#3445
Conversation
|
One thing, though– the initial efforts of this PR were made by @BytesGalore, and I'd like to preserve his authorship, but I had to create a clean branch since the original implementation became messy beyond repair (at least with my git skills) through several PR merges and rebases and fixes... What would be the best way to do this? Just add him as an author? Add his original commit and then rebase this one on top of it? |
Yes add him to as |
sys/net/include/aodvv2/aodvv2.h
Outdated
There was a problem hiding this comment.
Documentation of interface. What is it for? And what's with multiple interface support?
There was a problem hiding this comment.
I'd say AODVv2 can currently only serve one interface and put that into the documentation? Multiple interfaces would be nifty, but I have a huge backlog of draft changes that I'd like to implement first...
f3d1fe2 to
b7e4202
Compare
|
Addressed commits (the “4 days ago” is because my VM got confused), but I haven't tested yet if I broke anything. |
sys/net/routing/aodvv2/aodv.c
Outdated
There was a problem hiding this comment.
Um, I guess this is not needed anymore. (I know that it was HTONS(port) formerly )
|
Needs rebase. |
|
And adaptation to the GNRC renames. |
|
Will do, as soon as my vacation is over and the jet lag is manageable (should be around the 26th) |
1cac47e to
018ec20
Compare
|
(not ready for review yet, the change from local to global addresses broke some stuff and there is still something amiss with unicast source addresses– will let you know once I'm done with fixing & rebasing) |
|
@Lotterleben what's your status on this one, ready for some reviewing? I could spare some time during today H'n'A - maybe you can join as well? Further, I would give it another try on some real hardware, eg. SAMR21 to see what's missing to get it working. |
|
I'll be at the H'n'A to work on this PR, but I was busy with exams up until now :/ |
00939f8 to
30ffa70
Compare
|
Sadly I guess we need to postpone again :( |
|
Indeed :/ For the record, I'm still working on this– there appears to be a bug causing forwarded RREPs to have the wrong source & destination addresses in the IP header (!). I hope I'll be able to fix this asap. But while hunting this bug I fixed one of @smlng s complaints, namely that there are too many threads running (down to 1 from previously 3 threads!). In the process, the weird nested message contents @BytesGalore criticized were chucked as well. And all mallocs are gone too. |
| } | ||
| /* allocate IPv6 header, set pkt_with_udp as payload */ | ||
| pkt_with_ip = gnrc_ipv6_hdr_build(pkt_with_udp, &aodv_ipv6_addr_local, | ||
| &addr_send); |
There was a problem hiding this comment.
RREPs to have the wrong source & destination addresses in the IP header (!).
How wrong are they? If they are still sensible addresses I guess you are setting the wrong addresses here. If they are total garbage you might overwrite something accidentaly. My choice of tool for this would be gdb:
watch *<address of first byte in destination or source address>There was a problem hiding this comment.
Exactly, that was what I was thinking. They're not total garbage: the src address is the address that originated the whole route discovery, and the dst address has parts of the suffix of the target of the route discovery, but as a multicast address(so for example ff02::1:ff88:36ed instead of bee2::3068:3cff:fe88:36ed). o.0
so in a topology like this: originator<-A<-B<-target, A receives a RREP packet with the originator as src etc. I'll keep an eye on what I'm feeding gnrc_ipv6_hdr_build ...
|
The same question as last release? The same question as every release. ;-) |
|
:D :D I'd answer "I'll do my very best" but exam season has started, sooooo.. :( |
|
Closing with memo for now. No activity for > 6 month, RFC is not going to happen and original author doesn't have the time to work on it. |
This PR makes AODVv2 ng ready. :) Also, AODVv2 must now be configured to serve a specific interface.