-
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
Max. packet length for AT86RF2XX #3086
Comments
At least |
For the record: #3480 |
@OlegHahm I quickly adapted the issue-discription. Can you please read it and check if one understands the problem? |
I understand the edited problem statement. |
@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. |
Among others, the function |
@authmillenon, how is the situation in the new (netdev2) driver version? |
Nothing yet, but since netdev2 centralizes this, doing this should be quite easy. |
But I would vote against doing it in #4646. |
Agreed! |
We leave this issue open until is fully solved? |
It's not solved yet, so yes ;-) |
Again postponed. |
Mhhh… this is more of an enhancement by now, not an issue => postponed. |
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. |
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. |
@jia200x might be of interest for you? |
yes! Thanks! |
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. |
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. |
ping? |
If I understand correctly this goes in the same direction as #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. |
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 than25
Bytes), to fill all packets with payload completely.OLD:
In
ng_sixlowpan
the max. packet sizeNETCONF_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 valueNG_AT86RF2XX_MAX_PKT_LENGTH (127)
. In the drivers_send
function it is checked if the transceivers max. packet length plusFCS
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?
The text was updated successfully, but these errors were encountered: