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