[lwip-users] Unexpected ERR_ABRT on data transfers

[RCube]

Hello, 

I'm using lwIP in an attempt to set up a simple webserver. (Initially it is
only expected to support GET requests and can assume no Keep-Alive or
pipelining is used) As a base I used the HTTP Server based on the TCP Raw
api written by Adam Dunkels himself.
(http://cvs.savannah.gnu.org/viewvc/lwip/contrib/apps/httpserver_raw/)

Initially it seemed to work well. I have now however tested it with bigger
pages (A simple page consisting of 7 images totalling a couple of MB in
size) and there are some errors I can not explain. I managed to pinpoint to
problem to errors I receive in my error callback. I receive the error
ERR_ABRT (Connection aborted) at times I don't expect it.

When a client connects initially it requests '/' and my server sends the
index.html file. This goes fine. After that, the client sets up multiple
connections to requests the images described in the file. (One for each
file)

Like in the example code, I use a state object that contains the data to
send for each client. Data for sending gets send (in single writes) in the
receive callback (after succesfully parsing a request) and from there on I
do it after ACK'ing and in my polling callback. 

On the first couple of requests the error callback is triggered with the
error code mentioned earlier (ERR_ABRT). As a result the image is not
displayed on the page. I have no idea why this happens or how I could
determine the exact cause of this though.

A specific scenario of the situation I could describe as follows
(chronological order):

accept PCB 0x60101b8 -> "GET /" -> Gets send, and the connection is closed
by my server.

accept PCB 0x6010108 -> GET /images/4.jpg -> 2800 bytes are sent as the send
function is called at the end of the receive callback.
accept PCB 0x60101b8 -> GET /images/3.jpg -> 2800 bytes are sent as the send
function is called at the end of the receive callback.
accept PCB 0x6010058 -> GET /images/5.jpg -> 2800 bytes are sent as the send
function is called at the end of the receive callback.
accept PCB 0x600ffa8 -> GET /images/6.jpeg-> 2800 bytes are sent as the send
function is called at the end of the receive callback.

The error call-back gets called with ERR_ABRT. Based on what's to follow
this will be for client with PCB 0x6010108.

sent callback (ACK) for pcb 0x60101b8 -> More data is send.
sent callback (ACK) for pcb 0x6010058 -> More data is send.
sent callback (ACK) for pcb 0x600ffa8 -> More data is send.


accept PCB 0x600fef8 -> GET /images/8.jpg -> 2800 bytes are sent as the send
function is called at the end of the receive callback.
accept PCB 0x6010108 -> GET /images/7.jpg -> 2800 bytes are sent as the send
function is called at the end of the receive callback.

The error call-back gets called with ERR_ABRT. Based on what's to follow
this will be for client with PCB 0x60101b8.

sent callback (ACK) for pcb 0x6010058 -> More data is send.
sent callback (ACK) for pcb 0x600ffa8 -> More data is send.
sent callback (ACK) for pcb 0x600fef8 -> More data is send.
sent callback (ACK) for pcb 0x6010108 -> More data is send.


accept PCB 0x60101b8 (Note: addr is reused, it was aborted earlier) -> GET
/images/9.jpg -> 2800 bytes send

The error call-back gets called with ERR_ABRT. Based on what's to follow
this will be for client with PCB 0x6010058.

sent callback (ACK) for pcb 0x600ffa8 -> More data is send.
sent callback (ACK) for pcb 0x600fef8 -> More data is send.
sent callback (ACK) for pcb 0x6010108 -> More data is send.
sent callback (ACK) for pcb 0x60101b8 -> More data is send.

accept PCB 0x6010058 (Note: addr is reused, it was aborted earlier) -> GET
/images/10.jpg -> 2800 bytes send

sent callback (ACK) for pcb 0x600ffa8 -> More data is send.
sent callback (ACK) for pcb 0x600fef8 -> More data is send.
sent callback (ACK) for pcb 0x6010108 -> More data is send.
sent callback (ACK) for pcb 0x60101b8 -> More data is send.
sent callback (ACK) for pcb 0x6010058 -> More data is send.

After this the ACK, send, ACK, send repeats until everything is send, as
expected. No more aborts.


I tried to determine what goes wrong by looking at wireshark's capture, but
unfortunately I cannot extract much from it myself. Looking at the events
above, The PCB with address 0x6010108 seems to get the first ERR_ABRT. When
filtering my trace on this specific PCB I am left with the following
(192.168.1.192 is the webserver running lwIP, 192.168.1.64 is my desktop):



80223   314.576573000   192.168.1.64    192.168.1.192   TCP     66      55011 > 
http [SYN]
Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1

80231   314.577215000   192.168.1.192   192.168.1.64    TCP     60      http > 
55011 [SYN,
ACK] Seq=0 Ack=1 Win=2048 Len=0 MSS=1400

80233   314.577235000   192.168.1.64    192.168.1.192   TCP     54      55011 > 
http [ACK]
Seq=1 Ack=1 Win=64400 Len=0

80234   314.577301000   192.168.1.64    192.168.1.192   HTTP    381     GET 
/images/4.jpg
HTTP/1.1 

80240   314.645906000   192.168.1.192   192.168.1.64    TCP     1454    [TCP 
segment of a
reassembled PDU]

80241   314.646678000   192.168.1.192   192.168.1.64    TCP     1454    [TCP 
segment of a
reassembled PDU]

80242   314.646695000   192.168.1.64    192.168.1.192   TCP     54      55011 > 
http [ACK]
Seq=328 Ack=2801 Win=64400 Len=0

80256   314.787278000   192.168.1.192   192.168.1.64    TCP     60      http > 
55011 [RST,
ACK] Seq=2801 Ack=328 Win=2048 Len=0

80257   314.787279000   192.168.1.192   192.168.1.64    TCP     60      http > 
55011 [RST,
ACK] Seq=2802 Ack=328 Win=2048 Len=0


Does anyone know what may cause these connection aborts and/or how I could
prevent this? 

Thanks in advance, 

RCube

-- 
View this message in context: 
http://old.nabble.com/Unexpected-ERR_ABRT-on-data-transfers-tp34452439p34452439.html
Sent from the lwip-users mailing list archive at Nabble.com.