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

[Kieran Mansley]

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