Re: [lwip-users] TCP causing out of mem pool [RAW]

[Chris_S]

IE6.0.2800

But since you asked, I just tried FF as well.  It causes lwIP to crash
quicker.
By crash I mean stuck in DAbort.  On the 2nd page refresh.

It appears FF is trying to load the "favicon.ico".
My HTTPd returns the 404 correctly, 1st page load is fine.
But on the 2nd page load, locks up.

Really don't know why.  Another wierdness yet to trace.

Here's a trace below.  I put a ping set in between 1st/2nd page refresh
loads.



No.     Time        Source                Destination           Protocol
Info
      1 0.000000    00:bd:33:02:64:24     Intel_6b:36:37        ARP
192.168.2.1 is at 00:bd:33:02:64:24
      2 0.000284    Intel_6b:36:37        Broadcast             ARP      Who
has 192.168.2.1?  Tell 192.168.2.10
      3 0.000692    192.168.2.10          192.168.2.1           TCP
netview-aix-10 > http [SYN] Seq=0 Win=25200 Len=0 MSS=1460
      4 0.001094    192.168.2.1           192.168.2.10          TCP
http > netview-aix-10 [SYN, ACK] Seq=0 Ack=1 Win=2048 Len=0 MSS=1460
      5 0.001190    192.168.2.10          192.168.2.1           TCP
netview-aix-10 > http [ACK] Seq=1 Ack=1 Win=25200 Len=0
      6 0.003696    192.168.2.10          192.168.2.1           HTTP     GET
/ HTTP/1.1
      7 0.007103    192.168.2.1           192.168.2.10          TCP
[TCP segment of a reassembled PDU]
      8 0.175167    192.168.2.10          192.168.2.1           TCP
netview-aix-10 > http [ACK] Seq=460 Ack=1461 Win=25200 Len=0
      9 0.177123    192.168.2.1           192.168.2.10          TCP
[TCP segment of a reassembled PDU]
     10 0.177173    192.168.2.1           192.168.2.10          HTTP
HTTP/1.0 200 OK  (text/html)
     11 0.177253    192.168.2.10          192.168.2.1           TCP
netview-aix-10 > http [ACK] Seq=460 Ack=1639 Win=25023 Len=0
     12 0.177613    192.168.2.10          192.168.2.1           TCP
netview-aix-10 > http [FIN, ACK] Seq=460 Ack=1639 Win=25023 Len=0
     13 0.198404    192.168.2.10          192.168.2.1           TCP
netview-aix-11 > http [SYN] Seq=0 Win=25200 Len=0 MSS=1460
     14 0.198685    192.168.2.1           192.168.2.10          TCP
http > netview-aix-10 [ACK] Seq=1639 Ack=461 Win=1588 Len=0
     15 0.698600    192.168.2.1           192.168.2.10          TCP
http > netview-aix-11 [SYN, ACK] Seq=0 Ack=1 Win=2048 Len=0 MSS=1460
     16 0.699063    192.168.2.10          192.168.2.1           TCP
netview-aix-11 > http [ACK] Seq=1 Ack=1 Win=25200 Len=0
     17 0.700242    192.168.2.10          192.168.2.1           HTTP     GET
/img/sics.gif HTTP/1.1
     18 0.703700    192.168.2.1           192.168.2.10          TCP
[TCP segment of a reassembled PDU]
     19 0.876175    192.168.2.10          192.168.2.1           TCP
netview-aix-11 > http [ACK] Seq=366 Ack=824 Win=24377 Len=0
     20 0.878115    192.168.2.1           192.168.2.10          HTTP
HTTP/1.0 200 OK  (GIF89a)
     21 0.878208    192.168.2.10          192.168.2.1           TCP
netview-aix-11 > http [ACK] Seq=366 Ack=825 Win=24377 Len=0
     22 0.883913    192.168.2.10          192.168.2.1           TCP
netview-aix-11 > http [FIN, ACK] Seq=366 Ack=825 Win=24377 Len=0
     23 0.884192    192.168.2.1           192.168.2.10          TCP
http > netview-aix-11 [ACK] Seq=825 Ack=367 Win=1682 Len=0
     24 14.828291   192.168.2.10          192.168.2.255         NBNS
Name query NB LX700<00>
     25 14.828315   192.168.2.1           192.168.2.10          NBNS
Name query response NB 192.168.2.1
     26 14.850563   192.168.2.10          192.168.2.1           ICMP
Echo (ping) request
     27 14.850567   192.168.2.1           192.168.2.10          ICMP
Echo (ping) reply
     28 15.838335   192.168.2.1           192.168.2.10          ICMP
Echo (ping) reply
     29 15.838810   192.168.2.10          192.168.2.1           ICMP
Echo (ping) request
     30 16.841606   192.168.2.10          192.168.2.1           ICMP
Echo (ping) request
     31 16.841611   192.168.2.1           192.168.2.10          ICMP
Echo (ping) reply
     32 17.841322   192.168.2.1           192.168.2.10          ICMP
Echo (ping) reply
     33 17.841592   192.168.2.10          192.168.2.1           ICMP
Echo (ping) request
     34 26.001498   192.168.2.10          192.168.2.1           TCP
proshare-mc-1 > http [SYN] Seq=0 Win=25200 Len=0 MSS=1460
     35 26.001503   192.168.2.1           192.168.2.10          TCP
http > proshare-mc-1 [SYN, ACK] Seq=0 Ack=1 Win=2048 Len=0 MSS=1460
     36 26.001561   192.168.2.10          192.168.2.1           TCP
proshare-mc-1 > http [ACK] Seq=1 Ack=1 Win=25200 Len=0
     37 26.005979   192.168.2.10          192.168.2.1           HTTP     GET
/ HTTP/1.1
     38 28.917572   192.168.2.10          192.168.2.1           HTTP
[TCP Retransmission] GET / HTTP/1.1
     39 32.056530   192.168.2.10          192.168.2.1           TCP
proshare-mc-1 > http [FIN, ACK] Seq=460 Ack=1 Win=25200 Len=0
     40 34.926195   192.168.2.10          192.168.2.1           HTTP
[TCP Retransmission] GET / HTTP/1.1
     41 46.943371   192.168.2.10          192.168.2.1           HTTP
[TCP Retransmission] GET / HTTP/1.1







> Chris, are you using FireFox?  I read somewhere that FireFox opens a
> connection for each item on a WEB page, whereas IE doesn't.  I've seen
other
> people complain that embedded WEB servers can't handle all of the
connection
> attempts with FireFox.
>
> Bill
>
> >-----Original Message-----
> >From: address@hidden
> >[mailto:address@hidden On
> >Behalf Of Chris_S
> >Sent: Tuesday, July 28, 2009 7:41 AM
> >To: Mailing list for lwIP users
> >Subject: Re: [lwip-users] TCP causing out of mem pool [RAW]
> >
> >TCP dies after that.  This is a real problem.
> >
> >I tried changing TCP_MSL from 60000 to 6000,
> >and it sure had an effect.  I saw some TCB blocks being reallocated,
> >but again after more refreshes it finally crashed the CPU and went to
> >restart.
> >
> >I had KEEPALIVE turned ON, and tried it OFF, still the same.
> >
> >I noticed an old bug 24830 that seems like the same thing.
> >Not fixed yet, says v1.4
> >
> >I'm just mystified how people get this RAW working with this kind of a
> >problem.
> >Are there some special settings in lwipopts.h to deal with this?
> >Is this something I can bandaid in my HTTPd?    Is that what people do?
> >
> >Chris.
> >
> >
> >
> >
> >> On Tue, 2009-07-28 at 04:03 -0700, Chris_S wrote:
> >> > > > Obviously the TCP PCB is never being freed.
> >> > > > So what routine is suppose to do this?
> >> > >
> >> > > They're probably all in the TIME_WAIT state.  This is correct.
> >They'll
> >> > > get freed once they leave TIME_WAIT and go to CLOSED.
> >> > >
> >> > > Kieran
> >> >
> >> > So when do they go to CLOSED?
> >> > I waited minutes and the TCP pile keeps building.
> >> > I closed my browser window, opened another,
> >> > and the TCP still keeps piling up.
> >> >
> >> > Not happening.  When do they get freed?
> >>
> >> 2 * TCP_MSL is the default timeout I think.
> >>
> >> However, I think we try and recycle PCBs from TIME_WAIT when we try to
> >> alloc and there isn't one available.  I wonder if the message you're
> >> seeing is just the "I failed to find a free one" and then the
> >following
> >> line of code gets one from TIME_WAIT and everything is OK.  Do you
> >> actually see anything go wrong, or is it just the message that you
> >don't
> >> like?
> >
> >
> >
> >_______________________________________________
> >lwip-users mailing list
> >address@hidden
> >http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>