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. _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
