search

ntruchsess / arduino_uip

UIPEthernet: A plugin-replacement of the stock Arduino Ethernet library for ENC28J60 shields and breakout boards. Full support for persistent (streaming) TCP-connections and UDP (Client and Server each), ARP, ICMP, DHCP and DNS. Build around Adam Dunkels uIP Stack. Further developed version can be found on https://github.com/UIPEthernet/UIPEthernet
489 stars 212 forks source link

Incorrectly formed TCP packets #97

Open philfreeeu opened 10 years ago

philfreeeu commented 10 years ago

Hi!

Her's another few things.

1) Sometimes (~ one packet of 1000) the packet's body is sent incorrectly. I was sending 16 bytes - 5a425844010300000000000000313730, but the bytes in the packet are different - they are the same as the beginning of TCP packet. But the length of payload is the same - 16 bytes. 2014-10-10-130456_1280x1000_scrot

2) When the library performs an ARP request, for some reasons the same payload of 16 bytes got into the ARP's request. Not sure if this happens always, but here it's making 4 ARP requests and they all have this payload. 2014-10-10-130627_1280x1000_scrot

Thank you very much for your fork on this project!

ntruchsess commented 10 years ago

that is an interesting finding. I'm analysing some of my own logs now and find zero-window-packet followed by packet with incorrect ethernet-checksum. Regarding the statistics: in my test it's 4 occourences in 55000 packets transmittet, but it doesn't seem to be random, as there are no incorrect-checksum-errors that are not preceedet immediatly by a zero-window-packet. Zero-window is send whenever the library runs out of memory-blocks and cannot copy the current incoming packet to safe location. (This is intendet behavior, the following incorrect checksum is not...)

ntruchsess commented 10 years ago

fixed in https://github.com/ntruchsess/arduino_uip/commit/9c58463da8140861e72865ccc73d18893e751ff3

see new release version 1.09

philfreeeu commented 10 years ago

Tried the 9c58463, wrong packet body thing still happening. In this situation previous packet that the library has sent to PC had payload of 91 bytes, and now, when the usual 16 byte payload should have been sent, the lib sends 91 byte payload, that starts from previous packet's IP headers.

2014-10-15-102852_1280x1000_scrot