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
Implement support for jumbo frames #105
Comments
Just tested with tap interface and the server example. Once the mtu on the interface is changed (let's say to 5000) I can send and receive 5000 bytes long frames. Do you require any additional testing? |
What happens if you set the MTU to be over 9000? At some point it clashes with |
works OK (MTU is set to 65500 (max I can set on my OS) and I allocated appropriately sized buffers). Interface settings:
When I send a UDP packet 65000 bytes long, it is both received by the server and returned. However, for some reason the socket buffer isn't cleared - because when I send a second packet of the same size, I get Haven't tested with UDP |
Basically, the problem is: using jumbo frames with 802.3 or 802.1Q on the same medium is ambiguous, and it's not clear how this should be resolved. I'm leaning to rejecting all jumbo frames as invalid by default, unless explicitly enabled by a switch. |
I agree. I ll add an explicit feature switch to enable/disable frames with MTU > 1500 |
Looking at it more: the captured jumbo frames from wireshark have the Ethernet type set correctly (let's say Ipv4) - even for a frame 65k bytes long. Since smoltcp doesn't even try to interpred EtherType field as length, I don't think there is anything to be done here. If the hardware doesn't support MTU > 1500, then the packet is dropped, but if it does (like with the tap device) there is no harm in processing jumbo frames. Of course, large frames can be only received if the hardware supports it, and if it does we should process them. If we add this "jumbo frame switch" we have to validate the payload length against some MTU specified for the ethernet interface and possibly throw an error if is exceeded (or fragment the frame). What do you think? |
Ah, I guess mtu is already part of the device capabilities so disregard that. Still - is it necessary to drop large packets? |
This is the relevant capability: https://github.com/m-labs/smoltcp/blob/master/src/phy/mod.rs#L198 |
Consider what happens if you receive a 802.1Q packet. |
It will have EtherType 0x8100, which can't be a length since it's > 1536, so the length is unknown based on the header and the end of the frame is signalled by Ethernet's existing end-of-frame signalling (loss of carrier or physical-layer-specific signalling). What am I missing? |
Hm, you're right. That was a year ago so I no longer remember the context. I might have just made a mistake. |
OK, glad I wasn't missing something obvious - I did a little bit of testing and it seems like |
Jumbo frames should Just Work by now, if someone finds they don't please open a new issue. |
I'm not sure if this even needs any work besides testing that it actually works, but right now I don't know what's the status of them.
The text was updated successfully, but these errors were encountered: