Hello. I have a problem with sending data through TCP server from PIC32 custome board (192.168.5.11) to PC (192.168.5.10). Communication works fine when sending small amount of data or at max speed with no other tasks in PIC. Problem is when I try to insert some additional tasks to the PIC uC, an it looks like this: Can someone explain me what can cause that behavior? PS. Sorry for my english :) asked 27 Mar '17, 00:23  ENRO |
One Answer:
That's a very interesting capture. The server sends MSS 536 in the SYN/ACK packet, but sends 1460 bytes packets - that doesn't make any sense (if it says it can only do 536, it should only receive and send 536 bytes at max). My guess is that this leads to trouble. I would recommend doing a simultaneous capture at client and server at the same time (and not on the client or server, but using TAPs or SPAN ports), to check what really happens. It looks like the packets may have been modified in flight - maybe some middle box is messing with the packets. answered 27 Mar '17, 04:21  Jasper ♦♦ You're right. I didn't noticed that. There is no middle box. The server is implemented on PIC32 embedded processor - it's my modification od Microchip MLA stack. I could make a mistake when porting the code. At least now i know where to start looking for error. Thank you. (27 Mar '17, 04:45) ENRO Okay, it was just that the server sends a TTL of 100 which is very unusual - normal start values are 64, 128 or 255. So I guessed there is something in between :-) (27 Mar '17, 04:46) Jasper ♦♦ TTL = 100 may be unusual, but it should normally work. Changing the MSS didn't work. A have just read that each direction of data flow can use a different MSS. Any other ideas? (27 Mar '17, 05:06) ENRO 1 You're right, TTL 100 is not a problem. And while it's true that both directions can advertise different MSS values, it is wise for both to honor the lower of the values - simply because exceeding that value will lead to packets being unable to pass without fragmentation. What seems to be a problem is that all of your server packets have incorrect CRCs, and if you captured on the client they should be okay. My guess is that those packets are dropped because the checksum is bad. You need to fix your CRC calculation, is my guess :-) (27 Mar '17, 05:39) Jasper ♦♦ Exactly. I just started to writing a comment when saw your message. I also think it is the cause of error. Thank you :) (27 Mar '17, 05:43) ENRO 1 Problem solved :) There was no error with calculating CRC, only with data copy (CRC was calculated for entire package, but I copied max 960 bytes of TCP data). Thanks for help :) (28 Mar '17, 00:20) ENRO showing 5 of 6 show 1 more comments |
can you please upload the capture?
I's another capture with the same error: https://www.cloudshark.org/captures/8eb9b677dd97