gnrc_dhcpv6_client: configure prefix as compression context on 6LBRs #13485
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
miri64
added
Type: enhancement
miri64
requested review from
cgundogan,
haukepetersen,
jia200x,
leandrolanzieri and
PeterKietzmann
as code owners
miri64
changed the title
benpicco
added
the
CI: ready for build
|
My esp32 does not approve. Upon receiving the lease I get
Some quick printf-debugging reveals |
|
Fixed. We might want to want this in master for |
|
I can confirm that with this the compression context arrives at the nodes now - please squash. This is probably unrelated to this PR, but do you have an idea why the border router might perform so poorly? Propagation of the compression context also took several minutes. Pinging global addresses from the nodes is also very flaky. |
|
@benpicco seems to me that the router advertisements are sent slowly by your upstream router. It might also be that the router discovery tries to sent router solicitations before the WiFi interface is up (due to the timer being started on initialization most likely), so it takes a while until the next one. The dissemination of the context should happen once the network bootstraps (i.e. ones a downstream node receives its router advertisement from the upstream node, which should happen simultaneously with configuring the global address via SLAAC). |
aabadie
added
CI: ready for build
miri64
added
CI: ready for build
For reference: done in #13539 |
|
May I squash? Otherwise I would requeue again. |
|
Squash away! Now with this I wasn't successful yet, but I haven't tried much yet. |
miri64
force-pushed
the
gnrc_dhcpv6/enh/configure-context
branch
from
cf6036a
to
33a6bab
Compare
|
Squashed |
|
@benpicco anything missing now? |
|
I haven't checked yet if this is what was causing the regression on my border router or if it was the amount of active nodes. |
|
Ok so I tried with only one node now: esp32 with esp_wifiborder routernodeIs this what I'm expected to see? at86rf233 instead of esp_wifiborder routernode |
|
On master (with at86rf233): border routernodeSo it looks like this does cause a regression. |
|
btw.: Also with when pinging between nodes. |
|
So what is the problem? I see loss global addresses, but an insufficiently small data set with link-local addresses. Is the loss also occuring when using global addresses globally / with manually set compression contexts? |
insufficiently small data set with link-local addresses
I just ran the plain |
Both cases could be checked on current master:
|
Yup that works reliably.
So with The on the border router I manually do After that, the node does not receive answers from the border router anymore, but still answers to pings from an outside address. I then also run the same Now I enabled I did let it sit for a while, then I pinged But after the next its working again. So maybe that's why the bug is less pronounced with UHCP - the prefix gets refreshed often enough. This is a seriously strange bug. |
Maybe it's related to the |
|
Ah no, we don't have this here... |
|
How do the router advertisements in the WPAN look like? Do they carry the 6CO option? Are the lifetimes configured correctly? What does the |
I just realized I have one of those handy CC2531 USB Dongles that come with a sniffer firmware preinstalled.
|
|
That Screenshot isn't really helpful as I can't see the content of the RA. Can you upload the pcap somewhere? |
|
I haven't enabled 6ctx yet again, but will do. <ramble> In the meantime I noticed something else weird: Only one node gets the global route configured. I have four nodes, a Only the everyone else just has That seems irrelevant though. I've re-flashed all nodes with I've then re-enabled So now I'm waiting for the bug to re-appear while running Wireshark. </ramble> |
|
For more than one node you need a routing protocol like RPL ;-). |
😅👍 |
Even if they are all on the same table?! |
Which table? |
|
If they are all routers they will bootstrap as a mesh. If one of them becomes the upstream for the others at random, the others won't be reachable by the border router ;-). |
|
My desk - they all can reach the border router directly, they are all within a 1m radius of the border router. |
Ah, I thought you meant a forwarding table or something 😅 And yes, the routers bootstrap themselves in a first come first serve manner. |
That would explain a lot of things! I feel like we should add a comment about that to They are all non-routers now and I haven't seen any ping issues yet. Will try again with the esp32 and this patch - I've uploaded the 6ctx.pcapng file with the traffic up to now. |
|
Ok I re-tested on the esp32 as border router with the same nodes (all non-routers) and this patch. Again I see that some nodes can ping global addresses and some can't: When I disable |
Weird bug indeed... the border router is happily advertising the context (see e.g. frame 8), but the node is not accepting the compressed ping request (e.g. frame 18). I'll try to reproduce tomorrow and see if I can debug :-(. |
This was referenced Mar 25, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution description
Same deal as #8576, just for DHCPv6: This adds a 6LoWPAN compression context for the newly configured prefix.
Testing procedure
Compile and run
examples/gnrc_border_routerusingUSE_DHCPV6=1with a DHCPv6 server running on the TAP interface (see example's Makefile)(can be run with one
makeinvocation once #13484 is merged). After the prefix for the 6LoWPAN interface was configured (check withifconfig) a compression context should also be configured (check with6ctx).Issues/PRs references
Follow-up to #13424 and #8576.