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

[Vlad]

On Friday 09 March 2007 12:21, Kieran Mansley wrote:
> On Fri, 2007-03-09 at 11:59 +0200, Vlad wrote:
> > I forgot to say - lwip are in vmware. I.e. network structure are
> > following:
> >
> > lwip (in vmware) <--- 1gb virtual vmware network ----> virtual vmware hub
> > <-vmware network driver-> 192.168.0.2 (my real machine) <---- 1gb
> > ethernet ----> linux router <----128k adsl ----> internet <----> linux
> > server
>
> I think you win a prize for most complex network setup using lwIP!

:)

>
> > seems that vmware hub responses very fast with ack-s before packets
> > really have sent.
>
> 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.

i've just tried to run my program on 'real' (not vmware) windows computer 
(with same xp sp2 and connected to same hub as my test computer with linux) 
and it works without problems., transferring 10mb to test linux computer 
without errors event with stress-test loaded internet interface. seems that 
problem in lwip- vmware masquerading hub compatibility. BUT again, windows 
tcp/ip stack works fine in this situation, and i dont know why :(

>
> > 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.

> > BUT, windows tcp/ip stack works fine in same virtual machine. seems that
> > problem in lwip.
>
> lwIP is doing the right thing.  The only thing we could do differently
> is fragment and send one more packet (which would be less than one MSS),
> but then we'd be in the same situation as before but with no available
> window rather than almost no available window, and still waiting for
> more space.  The connection can't progress until lwIP gets a window
> update from the remote end, so it is not lwIP that is at fault.
>