Max. packet length for AT86RF2XX

[PeterKietzmann]

EDIT: The issue was fixed with #3480. However, #3480 limits the maximum payload in a (transceiver-)packet, by keeping the theoretically maximum MAC-header length of 25 Bytes free. Ideally we want a dynamic solution that computes the actual MAC-header length (which may be shorter than 25 Bytes), to fill all packets with payload completely.

OLD: In ng_sixlowpan the max. packet size NETCONF_OPT_MAX_PACKET_SIZE is requested from the hardware device which correlates with the max. fragment size of a 6LoWPAN packet. It is the basis for 6LoWPAN fragmentation, if payloads are too long. In the art86rfxx netdev-driver the device returns the value NG_AT86RF2XX_MAX_PKT_LENGTH (127). In the drivers _send function it is checked if the transceivers max. packet length plus FCS check sequence plus 802.15.4 header length is greater than the transceivers max. fifo size. What I'm saying is: Shouldn't we return the max. packet size minus link layer header lengths to the 6LoWPAN fragmentation? Or do I get confused somewhere between fragmentation, header lengths and the transceivers fifo size?

[miri64]

At least xbee seems to do it the way you describe it, so I guess you are right :D

[PeterKietzmann]

For the record: #3480

[PeterKietzmann]

@OlegHahm I quickly adapted the issue-discription. Can you please read it and check if one understands the problem?

[jnohlgard]

I understand the edited problem statement.

[OlegHahm]

@PeterKietzmann, yes, I think it's comprehensible.

Btw. I discussed yesterday shortly with @authmillenon and we concluded that basically everything except the destination address length should be known to the link layer/transceiver driver.

[PeterKietzmann]

Among others, the function _make_data_frame_hdr checks for the header flags NG_NETIF_HDR_FLAGS_BROADCAST and/or NG_NETIF_HDR_FLAGS_MULTICAST. Is this known by the driver?

[OlegHahm]

@authmillenon, how is the situation in the new (netdev2) driver version?

[miri64]

Nothing yet, but since netdev2 centralizes this, doing this should be quite easy.

[miri64]

But I would vote against doing it in #4646.

[OlegHahm]

But I would vote against doing it in #4646.

Agreed!

[kYc0o]

We leave this issue open until is fully solved?

[miri64]

It's not solved yet, so yes ;-)

[miri64]

Again postponed.

[miri64]

Mhhh… this is more of an enhancement by now, not an issue => postponed.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

@jia200x might be of interest for you?

[jia200x]

yes! Thanks!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[maribu]

ping?

[maribu]

If I understand correctly this goes in the same direction as https://github.com/RIOT-OS/RIOT/issues/19132.

Normally, it is common procedure to close the new issues as duplicates of the old. In this case, I think the new issue is more general and this one a subset of the new issue. Hence, I'd like to close the old one here instead.

Please reopen if you disagree.