Re: [lwip-users] tcp_connect is aborted

[Chris Frost]

On Fri, Dec 03, 2004 at 03:59:04PM +0100, Leon Woestenberg wrote:
> Is there someone who uses the current loopif code and can comment on this?

Thanks for your thoughts Kieran and Leon. I've looked a little more into
why trying to connect over the loopback interface fails, but haven't made
any substantial progress. I have enabled debugging output since I last
posted, and was curious if anyone had any additional suggestions from the
below?

Unchanged from my last email, I'm attempting to send a data over the
loopback iface in a simple, non-threaded lwip setup. Below is the
debug output, where I have enabled debug output for NETIF, PBUF, INET,
IP, RAW, MEM, SYS, TCP, TCP_INPUT, and SLIP (I'm not using slip
here). DBG_TYPES_ON is DBG_ON. I have also disabled a LWIP_DEBUGF in
inet.c:97 (inet_chksum_pseudo()'s for loop), it seemed to pass a null
pointer.


netif_set_ipaddr: netif address being changed
netif: IP address of interface netif: netmask of interface netif: GW address of 
interface netif: added interface lo IP addr 127.0.0.1 netmask 255.0.0.0 gw 
127.0.0.1
netif: setting default interface lo
tcp_bind: bind to port 100
tcp_connect to port 100
pbuf_alloc(length=4)
pbuf_alloc(length=4) == 0x816be8
pbuf_header: old 0x816c30 new 0x816c1c (20)
[[[ repeat begins here ]]]
lwip_chksum(0x816c1c, 24)
inet: chksum: no odd byte
inet_chksum_pseudo(): pbuf chain lwip_chksum()=f710
pbuf_header: old 0x816c1c new 0x816c08 (20)
lwip_chksum(0x816c08, 20)
inet: chksum: no odd byte
ip_output_if: lo0
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |        44     | (v, hl, tos, len)
+-------------------------------+
|        0      |010|       0   | (id, flags, offset)
+-------------------------------+
|  255  |    6  |    0xfb4b     | (ttl, proto, chksum)
+-------------------------------+
|  127  |    0  |    0  |    1  | (src)
+-------------------------------+
|    1  |    0  |    0  |  127  | (dest)
+-------------------------------+
netif->output()pbuf_alloc(length=44)
pbuf_alloc(length=44) == 0x816c3c
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
[[[ repeat ends here ]]]
[[[ the repeat section is outputed 5 times ]]]
tcp_slowtmr: max SYN retries reached
tcp_pcb_purge
tcp_pcb_purge: data left on ->unacked
pbuf_free(0x816be8)
pbuf_free: deallocating 0x816be8
err(arg=0x00000000, err=ERR_ABRT)
tcp_slowtmr: no active pcbs


The last line is then outputed evermore.
Does this happen to give insights to anyone?


While having loopback would be nice down the road, my main interest in
getting loopback working is as a stepping stone to using slip or ppp.
Eventually in a multithreaded environment, but for now using only a
single thread and the raw api. So if the above doesn't show much, it
sounds like a good next step is trying to bring slip up. I looked
through the list archives but didn't see much on slip, so was curious
if anyone had any pointers to past findings/uses of slipif?

I'm planning on removing slipif's polling loop and instead executing
this loop one step at a time from within my application's main loop,
that also calls lwip's timer functions. Is there anything I should watch out
for here?

(Right now I have what I hope is a good implementation of the
sio_[open|senc|recv] functions, and do see some data spit out of the
serial port, but I've not yet done the work necessary to connect the
serial port with another computer running a slip server. I'm doing most
of my development in a hardware emulator, so I need to first write a
tty-to-tty connector.)


thanks again,
-- 
Chris Frost  |  <http://www.frostnet.net/chris/>
-------------+----------------------------------
Public PGP Key:
   Email address@hidden with the subject "retrieve pgp key"
   or visit <http://www.frostnet.net/chris/about/pgp_key.phtml>