Re: [lwip-users] transfer stucks when snd_wnd is less than TCP_MSS

[Vlad]

I've just discovered that in case of vmware lwip receives window increase ack 
only when remote side closes connection. In this example remote side timeout 
== 60 secs.

===> session starts

13:24:53.366829 IP local > remote: S 6515:6515(0) win 20480 <mss 1460>
13:24:53.582126 IP remote > local: S 3676916023:3676916023(0) ack 6516 win 
64240 <mss 1460>
13:24:53.684210 IP remote > local: S 3676916023:3676916023(0) ack 6516 win 
64240 <mss 1460>
13:24:53.781476 IP local > remote: P 1:240(239) ack 1 win 20480
13:24:53.781546 IP remote > local: . ack 240 win 64240
13:24:53.782911 IP local > remote: . ack 1 win 20480
13:24:53.890692 IP local > remote: . 240:1700(1460) ack 1 win 20480
13:24:53.890815 IP local > remote: . 1700:3160(1460) ack 1 win 20480
13:24:53.891907 IP remote > local: . ack 1700 win 64240
13:24:53.891948 IP remote > local: . ack 3160 win 64240
13:24:53.989968 IP local > remote: . 3160:4620(1460) ack 1 win 20480
13:24:53.990077 IP local > remote: . 4620:6080(1460) ack 1 win 20480
13:24:53.990205 IP local > remote: . 6080:7540(1460) ack 1 win 20480
13:24:53.990275 IP local > remote: . 7540:9000(1460) ack 1 win 20480
13:24:53.990859 IP remote > local: . ack 4620 win 64240
[....]
13:24:54.430849 IP local > remote: P 76280:77740(1460) ack 1 win 20480
13:24:54.430879 IP remote > local: . ack 77740 win 2140
13:24:54.431328 IP local > remote: P 77740:79200(1460) ack 1 win 20480
13:24:54.431360 IP remote > local: . ack 79200 win 680
[.... here connection hangs .... waiting ]
13:25:58.971821 IP remote > local: FP 1:1(0) ack 79200 win 64240    <=== 
remote side just closed connection and lwip tells me this and starts to send 
enqueued packets
13:25:58.990663 IP local > remote: P 79200:80660(1460) ack 2 win 20479
13:25:58.990798 IP local > remote: P 80660:82120(1460) ack 2 win 20479
13:25:58.990860 IP local > remote: P 82120:82160(40) ack 2 win 20479
13:25:58.990932 IP local > remote: P 82160:83620(1460) ack 2 win 20479
13:25:58.991002 IP local > remote: P 83620:85080(1460) ack 2 win 20479
13:25:58.991071 IP local > remote: P 85080:86540(1460) ack 2 win 20479
13:25:58.991140 IP local > remote: P 86540:88000(1460) ack 2 win 20479
13:25:58.991210 IP local > remote: P 88000:89460(1460) ack 2 win 20479
13:25:58.991279 IP local > remote: P 89460:90920(1460) ack 2 win 20479
13:25:58.991349 IP local > remote: P 90920:92380(1460) ack 2 win 20479
13:25:58.991419 IP local > remote: P 92380:93840(1460) ack 2 win 20479
13:25:58.991490 IP local > remote: P 93840:95300(1460) ack 2 win 20479
13:25:58.991560 IP local > remote: P 95300:96760(1460) ack 2 win 20479
13:25:58.991629 IP local > remote: P 96760:98220(1460) ack 2 win 20479
13:25:58.991700 IP local > remote: P 98220:99680(1460) ack 2 win 20479
13:25:58.992191 IP remote > local: . ack 80660 win 64240
13:25:58.992231 IP remote > local: . ack 82120 win 64240
13:25:58.992242 IP remote > local: . ack 82160 win 64240
13:25:58.992254 IP remote > local: . ack 83620 win 64240
13:25:58.992267 IP remote > local: . ack 85080 win 64240
13:25:58.992280 IP remote > local: . ack 86540 win 64240
13:25:58.992292 IP remote > local: . ack 88000 win 64240
13:25:58.992305 IP remote > local: . ack 89460 win 64240
13:25:58.992317 IP remote > local: . ack 90920 win 64240
13:25:58.992330 IP remote > local: . ack 92380 win 64240
13:25:58.992342 IP remote > local: . ack 93840 win 64240
13:25:58.992354 IP remote > local: . ack 95300 win 64240
13:25:58.992367 IP remote > local: . ack 96760 win 64240
13:25:58.992378 IP remote > local: . ack 98220 win 64240
13:25:58.992391 IP remote > local: . ack 99680 win 64240
[.....]

in non-vmware machine i receives window-increasing ack packets quickly and 
transferring continues.

On Friday 09 March 2007 12:46, Kieran Mansley wrote:
> On Fri, 2007-03-09 at 12:36 +0200, Vlad wrote:
> > On Friday 09 March 2007 12:21, Kieran Mansley wrote:
> > > If anything other than the remote end is sending ACKs for the packets
> > > you send, it's a seriously dodgy piece of kit and breaks TCP
> > > assumptions.
> >
> > vmware hub is masquerading device, i.e. in fact it can sent acks to me
> > without remote end permission.
>
> Are you sure about that?  It seems very unlikely to me that VMware would
> do such a thing, and as I understand it IP masquerading doesn't normally
> involve the intermediate sending ACKs.  I've asked a VMware expert if
> they know of anything like this in VMware, and he doesn't, and agrees it
> would be a very bad thing.
>
> > > > at "hang" moment vmware hub sent acks for near 1000000 bytes (within
> > > > 1-2 seconds ) sent (sent window starts with big value - near 60000
> > > > and decreases down to small value).
> > > > but at real eth interface (on 192.168.0.2 - real machine with vmware
> > > > installed) i see ack's only for 80-90kb. and send window size doesn't
> > > > grow more than 137 bytes.
> > >
> > > If something closes the window, and then doesn't later advertise more
> > > window space, as you describe, it's broken.
> >
> > vmware hub increases send window because it connected on 1gb virtual
> > link, which excludes packet losts possibility.
>
> There is no such thing as a link without the possibility of packet loss,
> but this is not your problem.  You need to investigate why it does not
> advertise more window space after the connection gets stuck.
>
> Again!  This is not an lwIP problem.  lwIP is doing the right thing.
>
> Kieran
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users