[lwip-users] Connection closing. Packets getting routed to wrong pcb?

[wurzel]

Hi!
I'm using lwip on a MIPS processor in "bare metal" mode, ie using the raw API.
Everything is running in a single thread.

My program first creates several outgoing TCP connections and leaves 
them open, then creates a listening socket and waits for connections on it.  

When I try to telnet to that listening socket, the connection accepts as 
expected,
but as soon as I send my first data packet, the connection is closed due to 
a RST coming from lwip.

I turned on all the TCP debugging and here's the output:

======================= Here's the SYN/SYNACK/ACK from the "telnet" connection:
24: TCP header:
24: +-------------------------------+
24: |    45775      |     6000      | (src port, dest port)
24: +-------------------------------+
24: |           1982095635          | (seq no)
24: +-------------------------------+
24: |           0000000000          | (ack no)
24: +-------------------------------+
24: | 10 |   |000010|      5840     | (hdrlen, flags (SYN
24: ), win)
24: +-------------------------------+
24: |    0x6220     |         0     | (chksum, urgp)
24: +-------------------------------+
24: tcp_input: packed for LISTENing connection.
24: TCP connection request 45775 -> 6000.
24: tcp_parseopt: MSS
24: tcp_parseopt: other
24: tcp_parseopt: other
24: tcp_parseopt: NOP
24: tcp_parseopt: other
24: tcp_enqueue(pcb=0x95e5c8, arg=0x0, len=0, flags=12, apiflags=0)
24: tcp_enqueue: queuelen: 0
24: tcp_enqueue: queueing 6510:6511 (0x12)
24: tcp_enqueue: 1 (after enqueued)
24: tcp_output: snd_wnd 5840, cwnd 1, wnd 1, effwnd 0, seq 6510, ack 6510
24: tcp_output: snd_wnd 5840, cwnd 1, wnd 1, effwnd 0, seq 6510, ack 6510, i 0
24: tcp_output_segment: rtseq 6510
24: tcp_output_segment: 6510:6510
24: TCP header:
24: +-------------------------------+
24: |    45775      |     6000      | (src port, dest port)
24: +-------------------------------+
24: |           1982095636          | (seq no)
24: +-------------------------------+
24: |           0000006511          | (ack no)
24: +-------------------------------+
24: |  5 |   |010000|      5840     | (hdrlen, flags (ACK
24: ), win)
24: +-------------------------------+
24: |    0x5cac     |         0     | (chksum, urgp)
24: +-------------------------------+
24: +-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags ACK
24: -+-+-+-+-+-+-+-+-+-+-+-+-+-+
24: State: SYN_RCVD
24: TCP connection established 45775 -> 6000.
24: I: rmg_accept
24: tcp_receive: window update 5840
24: tcp_receive: slow start cwnd 1461
24: tcp_receive: ACK for 6511, unacked->seqno 6510:6511
24: tcp_receive: removing 6510:6511 from pcb->unacked
24: tcp_receive: queuelen 1 ... 0 (after freeing unacked)
24: tcp_receive: pcb->rttest 0 rtseq 6510 ackno 6511
24: tcp_output: nothing to send (0x0)
24: tcp_output: snd_wnd 5840, cwnd 2920, wnd 2920, seg == NULL, ack 6511
24: State: ESTABLISHED

##### note that the remote port # is 45775 and the socket is now in 
"established"
##### state.  Here's what comes out when I send my first data packet in:

24: TCP header:
24: +-------------------------------+
24: |    45775      |     6000      | (src port, dest port)
24: +-------------------------------+
24: |           1982095636          | (seq no)
24: +-------------------------------+
24: |           0000006511          | (ack no)
24: +-------------------------------+
24: |  5 |   |011000|      5840     | (hdrlen, flags (PSH ACK
24: ), win)
24: +-------------------------------+
24: |    0xcc1e     |         0     | (chksum, urgp)
24: +-------------------------------+
24: tcp_input: packed for LISTENing connection.
24: tcp_listen_input: ACK in LISTEN, sending reset
24: tcp_rst: seqno 6512 ackno 1982095653.

There was no other output between those two cut&pastes that would indicate that
the connection socket had been closed.  Any thoughts?  Any other debugging I can
turn on that will report on the "matching" process for incoming packets versus 
the
open pcbs?  Is there a debug command to dump all the lists of current pcbs
(ie, equivalent of "netstat -ant" on linux)?

                                Thanks,
                                                -wurzel