sixlowpan: various fixes to sixlowpan_print() function #9585
Conversation
miri64
added
Type: bug
Destination address compression is all in the least significant nibble of that byte in the IPHC header [[1]]. [1]: https://tools.ietf.org/html/rfc6282#section-3.1.1
We had bad experiences with those in the past when used with newlib-nano ;-)
miri64
force-pushed
the
sixlowpan/fix/print
branch
from
9f81667
to
c6d4605
Compare
| printf("datagram size: %" PRIu16 "\n", | ||
| (uint16_t) (byteorder_ntohs(hdr->disp_size) & SIXLOWPAN_FRAG_SIZE_MASK)); | ||
| printf("tag: 0x%" PRIu16 "\n", byteorder_ntohs(hdr->tag)); | ||
| printf("datagram size: %u\n", |
There was a problem hiding this comment.
I'm not sure dropping the inttypes defines is a good idea.
There were only problems with PRIu8, right?
Maybe instead of making our code not use ten year old C standard headers because of misbehaviour of newlib nano, we should try to fix or work around the problem. Maybe we can inject our own inttypes.h for newlib-nano builds...
There was a problem hiding this comment.
I'm not sure either, but the output formatting is broken in this function anyways (0x prefix for decimal numbers?)
There was a problem hiding this comment.
Where is this issue referenced with inttypes.h macros ?
cladmi
added
the
CI: ready for build
|
Ping? |
There was a problem hiding this comment.
Maybe instead of making our code not use ten year old C standard headers because of misbehaviour of newlib nano, we should try to fix or work around the problem. Maybe we can inject our own inttypes.h for newlib-nano builds...
that's a good point 👍 and your proposed solution sounds also nice. We should tackle this issue separately from this PR, though. There are a lot of places that might need adjustment after such a workaround is in place.
ACK
| @@ -201,15 +200,15 @@ void sixlowpan_print(uint8_t *data, size_t size) | |||
| puts("reserved"); | |||
| break; | |||
|
|
|||
| case 0x10: | |||
| case 0x01: | |||
cgundogan
added
CI: ready for build
|
Backport provided in #9629 |
PR RIOT-OS#9585 changed the output for the dump slightly, so now this test is failing. This fixes that and should also fix some issues from the 2017.07 release tests.
PR RIOT-OS#9585 changed the output for the dump slightly, so now this test is failing. This fixes that and should also fix some issues from the 2017.07 release tests.
tests: gnrc_sixlowpan: fix expect for #9585
PR RIOT-OS#9585 changed the output for the dump slightly, so now this test is failing. This fixes that and should also fix some issues from the 2017.07 release tests. (cherry picked from commit c289ccc)
…-print tests: gnrc_sixlowpan: fix expect for #9585 [backport 2018.07]
PR RIOT-OS#9585 changed the output for the dump slightly, so now this test is failing. This fixes that and should also fix some issues from the 2017.07 release tests.
PR RIOT-OS#9585 changed the output for the dump slightly, so now this test is failing. This fixes that and should also fix some issues from the 2017.07 release tests.
Contribution description
While working with 6Lo more closely again for #8511, I noticed some bugs in the
sixlowpan_print()function.Issues/PRs references
None