-
Notifications
You must be signed in to change notification settings - Fork 2k
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.
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
udp: fix wrong usage of pkt pointer #3918
Conversation
I don't see how this is different from the current situation :-/. Can you explain to me? If I see it correctly, due to https://github.com/RIOT-OS/RIOT/pull/3918/files#diff-a743a0dcf90d0eb32c837f1a047918c1L106 the current code is equivalent to your code. |
@@ -130,9 +130,9 @@ static void _receive(gnrc_pktsnip_t *pkt) | |||
port = (uint32_t)byteorder_ntohs(hdr->dst_port); | |||
|
|||
/* send payload to receivers */ | |||
if (!gnrc_netapi_dispatch_receive(GNRC_NETTYPE_UDP, port, pkt)) { | |||
if (!gnrc_netapi_dispatch_receive(GNRC_NETTYPE_UDP, port, udp)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's just this line that did the hard fault.. need to test if the other lines are necessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems to be just this line that breaks the current state. But I don't think this is really a solution here... I think you intented to send the payload to the listener and not the udp snip itself. This is what I changed here now. pktdump confirms, it begins printing with the udp snip instead of the payload. So the actual problem may be somewhere else .. maybe in pktdump?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What no! The listener is supposed to get the whole packet, not just the payload. And you are not sending the payload, you are sending the UDP header... at least when the meaning of the variables is still the same as it was.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(confirmed by my packet dump
1442859872.171887;m3-9;> udp send fe80::3432:4833:46d5:9d12 1337 hey
1442859872.172833;m3-9;PKTDUMP: data received:
1442859872.173814;m3-9;~~ SNIP 0 - size: 8 byte, type: NETTYPE_UDP (4)
1442859872.174802;m3-9; src-port: 1337 dst-port: 1337
1442859872.174906;m3-9; length: 11 cksum: 0x45664
1442859872.177047;m3-9;~~ SNIP 1 - size: 40 byte, type: NETTYPE_IPV6 (2)
1442859872.177160;m3-9;traffic class: 0x00 (ECN: 0x0, DSCP: 0x00)
1442859872.177850;m3-9;flow label: 0x00000
1442859872.178827;m3-9;length: 11 next header: 17 hop limit: 64
1442859872.179832;m3-9;source address: fe80::3432:4833:46d5:9d12
1442859872.180833;m3-9;destination address: fe80::3432:4833:46d5:9d12
1442859872.181832;m3-9;~~ PKT - 2 snips, total size: 48 byte
1442859872.182815;m3-9;Success: send 40 byte to fe80::3432:4833:46d5:9d12:1337
where is the payload? ;-))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well in current master it is the payload (pktsnip of type undef). I think this this is what is actually right. And I believe the solution that I presented here is wrong :/
I can however confirm that the node no longer crashes (the packet buffer still contains (technically legal) some stuff however):
Someone an idea what this stuff might be? |
(This is not related to this PR) |
ACK and go when travis goes 🔔 |
please see my inline comment |
(ACK revoked if that wasn't clear) |
Can we close this? #3925 seems to fix it. |
closed in favour of #3925 |
This PR fixes the hard fault described in #3815. @authmillenon can you verify?