[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] TCP keeps re-transmitting but no ACK packet after SYN,

From: Sergio R. Caprile
Subject: Re: [lwip-users] TCP keeps re-transmitting but no ACK packet after SYN, SYN+ACK
Date: Fri, 13 Mar 2015 10:25:51 -0300
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

  or install PuTTY.
> Right. That's what I do. With that knownledge however, I think you'd have
> to explain what to do with telnet in this case...

    haha, right, developing web server applications and not knowng HTTP
    either... oh, these kids nowadays... good point Simon, sometimes I
    forget I'm an old man...

Once you connect to the box to port 80, however you do it, you paste (the web server might not wait for you to type) the following

GET / HTTP/1.0<CR><CR>

Anyway, we just wanted to connect here and it served our purposes.

your telnet capture: frames 75 and 173: you are not trying to connect to port 80 but to the telnet port (last time I used M$ stuff, the port number was entered plain text without brackets, as in any other shell in the Un*x world), that explains the RSTs.
Anyway, your PC is ignoring the RST+ACK and I bet that is because of the IP checksum error. Your previous stuff capture (1.4.1) shows IP checksums are correct, so as far as I'm concerned, that is the problem.

OK, summing up:

Web server uses socket API, so it can't be the problem (Simon's statement)
driver + vendor port seem to work OK with (vendor ?) 1.4.1 (you don't say where your 1.4.1 came from). IP checksums are OK
driver + vendor port don't work with git head. IP checksums are bad

My best guesses
1) Are you calculating IP checksums in software and in your hardware (driver)? Please check
2) I remember there were some changes on the checksum functions, perhaps something in your port collides with those changes or exposes a defect in them.
3) Your port can be trashing memory that was not in use by 1.4.1.

My suggestions:
1) Check for this
     #define CHECKSUM_GEN_IP                 1
and also check how your driver initializes the chip for checksums. Setting the above macro to the opposite value might be faster to check...
2 and 3) Check for these anywhere in your port and please post what you find
 * #define LWIP_CHKSUM <your_checksum_routine>
 * Or you can select from the implementations below by defining
 * LWIP_CHKSUM_ALGORITHM to 1, 2 or 3.

I don't know anything but the raw API, so in my case I would use the echo application from the contrib tree..
You need to see what the IP checksum function calculates, compare with what is written in the pcb, and what goes out. One of those three should be wrong.
I would put a breakpoint at the echo and work my way down, but there is probably a closer place to start.

Good hunting.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]