Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

IPHC/NHC broken #4462

Closed
cgundogan opened this issue Dec 10, 2015 · 60 comments · Fixed by #4507
Closed

IPHC/NHC broken #4462

cgundogan opened this issue Dec 10, 2015 · 60 comments · Fixed by #4507
Assignees
@miri64
Labels
Area: network Area: Networking Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Type: question The issue poses a question regarding usage of RIOT
Milestone
Release 2015.12

Comments

@cgundogan
Copy link
Member

Following setup:
Linux <-> gnrc_border_router example (N1) <-> microcoap_server example (N2)

I am able to ping N2 from linux, but I am not able to make CoAP requests.
If I disable iphc with ifconfig x -iphc on N1 and N2, then I can do CoAP requests (with Copper) from Linux <-> N2.

I have no time to investigate further right now. Can anyone confirm this behavior? @kaspar030 didn't you state something similar on IRC yesterday?
@cgundogan cgundogan added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Type: question The issue poses a question regarding usage of RIOT labels Dec 10, 2015
@cgundogan cgundogan added the Area: network Area: Networking label Dec 10, 2015
@kaspar030
Copy link
Contributor

@kaspar030 didn't you state something similar on IRC yesterday?

Yep, exactly the same. Wireshark shows a garbled CoAP reply arriving in Linux. Disabling iphc makes it work.

@OlegHahm
Copy link
Member

Can someone check with TFTP or simple netcat? Should be affected, too. But I saw it working while reviewing the NHC PR.

On 10 December 2015 18:32:53 CET, Kaspar Schleiser notifications@github.com wrote:

@kaspar030 didn't you state something similar on IRC yesterday?

Yep, exactly the same. Wireshark shows a garbled CoAP reply arriving in
Linux. Disabling iphc makes it work.

Reply to this email directly or view it on GitHub:
#4462 (comment)

Join the RIOT
http://www.riot-os.org

@miri64
Copy link
Member

miri64 commented Dec 11, 2015

Was this problem apparent before #4189 got merged?

@OlegHahm
Copy link
Member

Before this problem, NHC wouldn't work at all. Since IPHC (including NHC) is enabled per default on Linux, no UDP connection between RIOT and Linux did work.

@kaspar030
Copy link
Contributor

Isn't IPHC sixlowpan specific?

@OlegHahm
Copy link
Member

Yes.

@OlegHahm
Copy link
Member

Ah, ah, I see. I meant no UDP connection over 802.15.4 link layer.

@kaspar030
Copy link
Contributor

Ok, I got that right. In the setup above, linux <-> 6lr is using IPv6 over ethernet. Seems like 6lr doesn't unpack IPHC stuff correctly when handing it to plain IPv6.

@miri64
Copy link
Member

miri64 commented Dec 11, 2015

Since the issue is only with UDP traffic and this behavior wasn't appearent with our 2015.09 tests, I strongly suspect that NHC is the problem.

@jfischer-no
Copy link
Contributor

@cgundogan Can you please comment USEMODULE += gnrc_sixlowpan_iphc_nhc out and test again?

@cgundogan
Copy link
Member Author

I can confirm that Linux (netcat) -> N2 (posix udp server) works with iphc. N2 -> Linux doesn't work. This is however a completely different problem (_implicit_bind fails because gnrc_conn6_set_local_addr returns false, regardless whether iphc is enabled or disabled)

Nevertheless, CoAP ping/discovery is broken with iphc enabled and works when iphc is disabled. "Normal" udp traffic (induced with netcat) does seem to work with and without iphc enabled.

@cgundogan
Copy link
Member Author

UDP traffic (posix example - single hop) between two RIOT nodes seems to be broken when iphc is enabled. Disabling iphc on the sending node fixes the problem. (samr21-xpro)

@cgundogan
Copy link
Member Author

@jfischer-phytec-iot with DISABLE_MODULE += gnrc_sixlowpan_iphc_nhc CoAP works without disabling iphc manually via the ifconfig command

@miri64
Copy link
Member

miri64 commented Dec 13, 2015

Maybe related to #4397?

@OlegHahm OlegHahm added this to the Release 2015.12 milestone Dec 14, 2015
@miri64 miri64 mentioned this issue Dec 15, 2015
Merged
@miri64
Copy link
Member

miri64 commented Dec 18, 2015

Found another issue, that might cause this: Currently IPv6 assumes for forwarding, that nothing is between the IPv6 header and the payload for the pktsnip reversal (https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/gnrc_ipv6.c#L824). This is not the case with NHC, since UDP will be between the two. Did not go into it in-depth and did not have a fix yet.

@miri64 miri64 mentioned this issue Dec 18, 2015
Merged
@cgundogan
Copy link
Member Author

not fixed

@cgundogan cgundogan reopened this Dec 22, 2015
@OlegHahm
Copy link
Member

Good catch, thanks

@jfischer-no
Copy link
Contributor

Have wireshark running while testing #4485 (comment), as I see it, the Border Router does not perform NHC decoding.

riot-node -> riot-6lo
rnode-to-r6lo

riot-6lo -> linux
6lo-to-linux

@miri64
Copy link
Member

miri64 commented Dec 22, 2015

is it a linux br or a riot br?

@jfischer-no
Copy link
Contributor

riot br (riot-6lo - (over tun) -> linux host)

@jfischer-no
Copy link
Contributor

@authmillenon Oh no, opposite, riot-6lo makes nhc encoding for slip-iface, or?

@cgundogan
Copy link
Member Author

my setup is: linux (tunslip) <=> gnrc_boarder_example with gnrc_udp module <=> coap example

@cgundogan
Copy link
Member Author

also testing with samr21

@cgundogan
Copy link
Member Author

and with #4485 merged

@miri64
Copy link
Member

miri64 commented Dec 22, 2015

no, the node (microcoap) sends encoded udp, the 6lo needs nhc to decode it.

Yes, but the border router doesn't need the UDP module, because it only forwards. It does need NHC however to decode properly for SLIP/Ethernet traffic. So the dependency between NHC module and the UDP module must not be.

@jfischer-no
Copy link
Contributor

Yes, but the border router doesn't need the UDP module, because it only forwards. It does need NHC however to decode properly for SLIP/Ethernet traffic. So the dependency between NHC module and the UDP module must not be.

agree, but it exist

#ifdef MODULE_GNRC_UDP
            case NHC_UDP_ID:
                payload_offset = iphc_nhc_udp_decode(pkt, dec_hdr, payload_offset);
                break;
#endif

@jfischer-no
Copy link
Contributor

@cgundogan have the same test setup

b398941 gnrc_udp: fix false assumed packet order
c2d9342 gnrc_sixlowpan: Fix IPHC/NHC packet order problem
b7a7578 Merge pull request #4507 from authmillenon/gnrc_ipv6/fix/no-order-assumptions
83649dd Merge pull request #4531 from Yonezawa-T2/gnrc_avoid_infinite_loop
34974ab Merge pull request #4534 from Yonezawa-T2/gnrc_off_by_1_overrun
5b4ef43 Merge pull request #4532 from Yonezawa-T2/gnrc_safe_no_routers
08ba1f8 gnrc_ipv6_netif: fixed buffer overrun
fe0e58d gnrc_sixlowpan_nd: fixed crash when there are no routers
9108d27 sixlowpan: fixed infinite loop
2d8f6f8 Merge pull request #4500 from haukepetersen/fix_doc_samd21
1ac9a0d Merge pull request #4480 from authmillenon/doc/enh/creating-modules
b5f5f83 doc: add page about creating modules

@cgundogan
Copy link
Member Author

I just did a clean setup and removed all my custom debug statements and merged #4485 again: the same hard fault

@cgundogan
Copy link
Member Author

BTW: I use the copper firefox plugin to do a CoAP ping. When issueing that CoAP ping, the 6lr crashes

@jfischer-no
Copy link
Contributor

ok, I use libcoap and coap-client coap://[affe::d173:4e02:71af:600a]/riot/board

@cgundogan
Copy link
Member Author

current status: with gnrc_udp compiled into the boarder router, the 6lr node crashes for me when I use any kind of CoAP traffic over the 6lbr. I use samr21-xpros for both nodes. @jfischer-phytec-iot uses a samr21-xpro for the 6lbr and a phynode for the 6lr and his 6lr does not crash when using CoAP traffic.

@cgundogan
Copy link
Member Author

(on master + #4485)

This was referenced Dec 22, 2015
Merged
Merged
@jfischer-no
Copy link
Contributor

I have found an other bug in iphc_nhc_udp_encode...

@cgundogan
Copy link
Member Author

I have found an other bug in iphc_nhc_udp_encode...

enlighten us please

@jfischer-no
Copy link
Contributor

wip

@miri64
Copy link
Member

miri64 commented Dec 23, 2015

But #4485 fixed @kaspar030's and @cgundogan's issue?

@miri64
Copy link
Member

miri64 commented Dec 23, 2015

@jfischer-phytec-iot can you at least sketch out a bug description so we can assess the severity for the release?

@cgundogan
Copy link
Member Author

But #4485 fixed @kaspar030's and @cgundogan's issue?

Nope, it didn't fix @kaspar030's and my issue.

@jfischer-no
Copy link
Contributor

I need 20-40 Minutes for a PR, i hope ...

There is also an possible overflow in gnrc_pktbuf_realloc_data, is it known?

@miri64
Copy link
Member

miri64 commented Dec 23, 2015

Afaik no.

@jfischer-no jfischer-no mentioned this issue Dec 23, 2015
Closed
@jfischer-no
Copy link
Contributor

@cgundogan can you please test #4544 ?

@miri64 miri64 mentioned this issue Dec 23, 2015
Merged
@kaspar030 kaspar030 mentioned this issue Jan 4, 2016
Merged
@jnohlgard
Copy link
Member

@cgundogan did you test #4544 ?

@miri64
Copy link
Member

miri64 commented Mar 2, 2016

Maybe #4935 will also help ;-).

@miri64
Copy link
Member

miri64 commented Apr 19, 2016

This issue is fixed.

@miri64 miri64 closed this as completed Apr 19, 2016
@miri64
Copy link
Member

miri64 commented Apr 19, 2016

(with merging of #5232)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@miri64 miri64

Labels
Area: network Area: Networking Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Type: question The issue poses a question regarding usage of RIOT
Projects
None yet
Milestone
Release 2015.12
Development

Successfully merging a pull request may close this issue.

gnrc_ipv6: make no pre-assumption about any marked headers miri64/RIOT
6 participants
@jnohlgard @miri64 @cgundogan @OlegHahm @kaspar030 @jfischer-no