-
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
gnrc_sixlowpan_iphc: refactor sending for #8511 #9485
gnrc_sixlowpan_iphc: refactor sending for #8511 #9485
Conversation
Also ping @A-Paul. I think this could be interesting regarding GHC. |
*/ | ||
void gnrc_sixlowpan_multiplex_by_size(gnrc_pktsnip_t *pkt, | ||
size_t orig_datagram_size, | ||
gnrc_netif_t *netif, |
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.
const gnrc_netif_t *netif,
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.
Mh... while in the current version of the code netif
isn't changed, I can see a future version where netif
is provided as to a _send()
function which then again would require casting.
*/ | ||
bool gnrc_sixlowpan_iphc_encode(gnrc_pktsnip_t *pkt); | ||
void gnrc_sixlowpan_iphc_send(gnrc_pktsnip_t *pkt, void *ctx, unsigned page); |
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.
const void *ctx,
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.
This is not what is proposed in #8511 and we also shouldn't restrict the use of ctx
within the execution path (examples were ctx
is changed exist enough throughout the current code-base).
hm, there's a weird behavior, using |
@cgundogan can you tell me which assertion is hit, please? |
strike that. I don't receive assertions anymore. I rebased this PR to current master to include the page change. However, with |
strike that also |
With this PR:
|
@cgundogan Ok... I'm not in a condition to debug at the moment though :-/ |
@cgundogan can you maybe check if something went wrong in https://github.com/RIOT-OS/RIOT/pull/9485/files#diff-e87e12a912a7eb2cbb8a16f4ebeccabaR315 or if it even is executed, please. |
I switched to a local setup to debug, using a samr instead of the iotlabs. I again get an assertion hit here on the sending node. This is what I used:
it's executed and the if body is skipped to go directly to here |
@cgundogan can you see if the last commit fixes the issue (and if the sniffer still is able to recognize it). Not sure anymore if the 6Lo uncompressed dispatch is counted to the original datagram size or not in fragmentation (if not reception shouldn't work anymore now). |
@cgundogan I reverted the last commit and removed the bogus assertion instead. Of course the 6Lo-frame can be larger than the original IPv6 datagram, since you saw yourself that with deactivated compression, the uncompressed dispatch is prepended (one additional byte). This should also fix the off-by-one issue you reported to me offline. |
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.
Issue is fixed. Please squash. ACK!
This refactors sending/encoding part of `gnrc_sixlowpan_iphc` to the more layered approach modeled in RIOT-OS#8511. Since the reception part is already was pretty complicated to refactor, I decided to divide send and receive up into separate changes.
7e3c21f
to
80322cb
Compare
During the review of RIOT-OS#9485 [we found out][1] that an assertion in this function was invalid. However, the documentation on this assertion wasn't removed on that. This fixes that. [1] RIOT-OS#9485 (comment)
During the review of RIOT-OS#9485 [we found out][1] that an assertion in this function was invalid. However, the documentation on this assertion wasn't removed on that. This fixes that. [1] RIOT-OS#9485 (comment)
During the review of RIOT-OS#9485 [we found out][1] that an assertion in this function was invalid. However, the documentation on this assertion wasn't removed on that. This fixes that. [1] RIOT-OS#9485 (comment)
During the review of RIOT-OS#9485 [we found out][1] that an assertion in this function was invalid. However, the documentation on this assertion wasn't removed on that. This fixes that. [1] RIOT-OS#9485 (comment)
Contribution description
This refactors sending/encoding part of
gnrc_sixlowpan_iphc
to themore layered approach modeled in #8511. Since the reception part is
already was pretty complicated to refactor, I decided to divide send
and receive up into separate changes.
Testing
To test I used the
ping6
andudp {send|server}
server commandtests/gnrc_udp
with different packet sizes, and also with IPHC (de-)activated withifconfig 6 -iphc
onsamr21-xpro
. I also tested several compile configurations with the following patch (and commenting out the correspondingiphc
/frag
lines):(just resolves the dependency)
Issues/PRs references
Related to but independent of #9484.
Adapts IPHC reception for #8511.