-
Notifications
You must be signed in to change notification settings - Fork 8
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
Driver splits UDP packets larger than 730 bytes #13
Comments
Ciao @juhaylinen, |
I was browsing a little bit around in the Internet regarding the question of maximum UDP size and found the following (which more or less summarizes this page regarding datagram size):
So, it seems as if your test is going beyond what the respective standard RFCs require. |
@SeppoTakalo can you comment on max UDP payload size? |
From IETF Official Internet Protocol Standards and section Internet Standards go to: RFC1122 - Requirements for Internet Hosts - Communication Layers: 3.3.2 Reassembly
As a Ethernet connected device, you must be able to receive packets as big as can fit into one ethernet frame. SHOULD be greater than or equal to the MTU of the connected network And Ethernet MTU is 1500. The limit 576 is something that ALL technologies must be able to handle. And it should be considered when writing UDP applications. It is written into IETF's Best Current Practice: Unicast UDP Usage Guidelines for Application Designers: 3.2. Message Size Guidelines |
Also this splitting breaks the meaning of the datagram protocol.
The word datagram is poorly defined, but always assumed to be one complete frame.
|
What about Wi-Fi, is it the same size, etc.?
"Assumed" by whom?
Does this - in your opinion - mean that @juhaylinen's UDP test application is going beyond what is actually guaranteed by the standards? |
@SeppoTakalo, considering the last paragraph of my previous post, do you think we can close this issue? |
No, we should not immediately close this. This is seriously violating RFCs Regarding the MTU, for Ethernet and Wi-Fi it is 1500. Therefore it should be assumed that device should be able to handle that sized packets. By using payload size 1200 we are not going over these limits. (IPv6 header 40 bytes, IPv4 20 bytes, UDP header 8 bytes. Total 1248). This splitting of UDP payload is not allowed by any Internet standard. If device is not capable of operating over some specific limit, it should just drop the datagram and return ICMP error code. Payload should never be fragmented. The fragmentation and reassembly should never be visible on the user API. For IPv6, we should always be able to expect 1280 packets to work. For IPv4, we are recommended to to Path MTU discovery if we go over 576, however all modern devices are currently capable of handling frame sizes required by IPv6. I'm unsure of whether this limitation is coming from the driver implementation, or from the device itself. However, it should be studied whether it can be fixed in the driver. |
It's a limitation of the module FW, so it can not be fixed in the driver. Pls. let me know how you wish to proceed! |
OK. So this is similar limitation than the #11 For TCP, it should not be so much visible. I believe the device adjusts its TCP MSS accordingly. So this would only be visible on UDP where datagrams are handed to the application layer. |
I have added a point regarding this issue to the Known limitations section in |
@SeppoTakalo, what do you think, can we close the issue now? |
Closing the issue. |
Based on the discussion, isn't a firmware update a must? |
The Wifi chip is in end-of-life status
So don't expect FW updates. |
The issue exists in the latest FW version 3.6 (released on June 21) |
If I send UDP datagram with size 1000 to echo server and try to receive the datagram back, recvfrom() call returns packet size 730 bytes and consecutive call returns 270 bytes. The recvfrom() call should return complete datagram but the driver seems to split UDP packets.
You can use the example code from issue #12 to experiment. Just increase the buffer size to 1000 bytes (#define BUF_SIZE 1000).
Board: NUCLEO_F401RE
Shield: IDW01M1
Compiler: GCC_ARM
Driver version: v1.1.8
Not sure if this can be fixed since there seems to be some kind of FW limitation
https://github.com/ARMmbed/wifi-x-nucleo-idw01m1/blob/master/SPWFSAxx.cpp#L540
The text was updated successfully, but these errors were encountered: