Skip to content

gnrc_sixlowpan_iphc: allow address compression for non-IEEE802.15.4#10521

Merged
haukepetersen merged 2 commits intoRIOT-OS:masterfrom
miri64:gnrc_sixlowpan_iphc/fix/non-ieee802154-support
Dec 7, 2018
Merged

gnrc_sixlowpan_iphc: allow address compression for non-IEEE802.15.4#10521
haukepetersen merged 2 commits intoRIOT-OS:masterfrom
miri64:gnrc_sixlowpan_iphc/fix/non-ieee802154-support

Conversation

@miri64
Copy link
Copy Markdown
Member

@miri64 miri64 commented Nov 29, 2018

Contribution description

This should allow @haukepetersen to use NimBLE with GNRC's 6Lo ;-).

Testing procedure

Run GNRC on top of NimBLE. IPv6 address compression should not break the addresses anymore ;-). If someone wants to revive #4861 that would also be an option for testing.

Issues/PRs references

Depends on #10500 and #10520.

gnrc_netif/gnrc_sixlowpan_iphc BLE capability

@miri64 miri64 requested a review from haukepetersen November 29, 2018 21:50
@miri64 miri64 added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: network Area: Networking labels Nov 29, 2018
@miri64 miri64 added the State: waiting for other PR State: The PR requires another PR to be merged first label Nov 30, 2018
@miri64 miri64 force-pushed the gnrc_sixlowpan_iphc/fix/non-ieee802154-support branch from 4bbdfec to b7600f2 Compare December 5, 2018 15:12
@miri64
Copy link
Copy Markdown
Member Author

miri64 commented Dec 5, 2018

Rebased to current master and dependencies

@haukepetersen
Copy link
Copy Markdown
Contributor

changes are valid and code looks good. Will test now with NimBLE and see if it does the job :-)

@miri64 miri64 force-pushed the gnrc_sixlowpan_iphc/fix/non-ieee802154-support branch from b7600f2 to 0099171 Compare December 6, 2018 15:05
@miri64
Copy link
Copy Markdown
Member Author

miri64 commented Dec 6, 2018

Rebased to current #10520 for your convenience ;-)

@haukepetersen
Copy link
Copy Markdown
Contributor

thx

@miri64 miri64 force-pushed the gnrc_sixlowpan_iphc/fix/non-ieee802154-support branch from 0099171 to 93da3bc Compare December 6, 2018 15:27
@miri64
Copy link
Copy Markdown
Member Author

miri64 commented Dec 6, 2018

@haukepetersen I saw you dance your happy dance because of this PR. Does that mean you ACK :-D?

@haukepetersen
Copy link
Copy Markdown
Contributor

I am happy, that is true. So two-way ping between two NimBLE nodes worked as expected. But I just also tried to assign each node some random global address (affe::1 and affe::2), but with that they were not able to ping each other, although the default route was set correctly (nib route -> affe::/64 dev #9).

If this is not related to this PR, then you have my ACK. But I'd like to confirm this first...

@miri64
Copy link
Copy Markdown
Member Author

miri64 commented Dec 6, 2018

I am happy, that is true. So two-way ping between two NimBLE nodes worked as expected. But I just also tried to assign each node some random global address (affe::1 and affe::2), but with that they were not able to ping each other, although the default route was set correctly (nib route -> affe::/64 dev #9).

If this is not related to this PR, then you have my ACK. But I'd like to confirm this first...

Your route does not resolve to a link-local address, just an interface ;-). So yes, it's unrelated to this PR.

@haukepetersen
Copy link
Copy Markdown
Contributor

but any idea how to approach the issue? Seems like the neighbor discovery is not quite working 'correctly'?! Or is there any configuration I might have missed?

Copy link
Copy Markdown
Contributor

@haukepetersen haukepetersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the issue pointed out is not realted to this PR -> happy ACK!

@miri64
Copy link
Copy Markdown
Member Author

miri64 commented Dec 6, 2018

but any idea how to approach the issue? Seems like the neighbor discovery is not quite working 'correctly'?! Or is there any configuration I might have missed?

This is normal behavior. How should the neighbor discovery know which node is the route for a certain prefix? It just knows that a prefix was assigned to an interface, so the route for that prefix must be through that interface, but it doesn't know if the interface is P2P or broadcast or anything. For anything beyond that a routing protocol is required.

@miri64 miri64 added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Dec 6, 2018
@miri64 miri64 force-pushed the gnrc_sixlowpan_iphc/fix/non-ieee802154-support branch from 93da3bc to 7e31c1b Compare December 6, 2018 20:50
@miri64
Copy link
Copy Markdown
Member Author

miri64 commented Dec 6, 2018

Rebased to current #10520 just to see if there are more issues in that PR

@miri64
Copy link
Copy Markdown
Member Author

miri64 commented Dec 6, 2018

Nope, except for static warnings about the state of this PR, Murdock is happy :-)

@miri64 miri64 force-pushed the gnrc_sixlowpan_iphc/fix/non-ieee802154-support branch from 7e31c1b to a7e3791 Compare December 7, 2018 12:04
@miri64
Copy link
Copy Markdown
Member Author

miri64 commented Dec 7, 2018

Rebase to current #10520

@haukepetersen haukepetersen removed the State: waiting for other PR State: The PR requires another PR to be merged first label Dec 7, 2018
@haukepetersen haukepetersen added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Dec 7, 2018
@haukepetersen
Copy link
Copy Markdown
Contributor

dependencies are merged, re-triggered Murdock

@haukepetersen
Copy link
Copy Markdown
Contributor

all green -> lets go

@haukepetersen haukepetersen merged commit a24f669 into RIOT-OS:master Dec 7, 2018
@miri64 miri64 deleted the gnrc_sixlowpan_iphc/fix/non-ieee802154-support branch December 7, 2018 15:00
@aabadie aabadie added this to the Release 2019.01 milestone Dec 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants