Re: [lwip-users] TCP/IP cange in behaviour?

[Valdemar]

I have investigated further into this matter and this is what I found:

After enabling the Nagle algorithm again the server responds with
these 5 blocks and some extra characters when telnet connects.

0 1234567890ABCDEFGHIJKLMNOPQRST
1 1234567890ABCDEFGHIJKLMNOPQRST
2 1234567890ABCDEFGHIJKLMNOPQRST
3 1234567890ABCDEFGHIJKLMNOPQRST
4 1234567890ABCDEFGHIJKLMNOPQRST

These are the number of characters input to tcp_write:

16:11:16,10 tcp_write. Antal: 34
16:11:16,10 tcp_write. Antal: 34
16:11:16,10 tcp_write. Antal: 34
16:11:16,10 tcp_write. Antal: 34
16:11:16,10 tcp_write. Antal: 34
16:11:16,11 tcp_write. Antal: 2
16:11:16,11 tcp_write. Antal: 19
16:11:16,11 tcp_write. Antal: 1
16:11:16,11 tcp_write. Antal: 9
16:11:16,11 tcp_write. Antal: 1

The telnet client (win 2000) displays only the first line of 34 
characters and then stops. The server now doesn't answer to a ping
and UDP-transmission from the server is stopped.

The Wireshark recording shows that there is something wrong with
the next block received. It is too big and contains rubbish after
the text.

Germund Asp




Goldschmidt Simon skrev:
> tcp_write is not the problem (it only enqueues the data for sending). You have 
> to call tcp_output and that is also the point where it doesn't send any more. 
> But since this is no error but intended behaviour instead, no error is returned 
> (and there's no way to return an error: one segment might have been sent and 
> another held back, so you can't really return an error).
>
> It does have to be documented though, that nagel is now on by default for raw 
> api apps. And BTW: the tcp_slowtmr should always send the data after 200 ms, 
> maybe you should check that also...
>
>
> Simon
>
> -----Ursprüngliche Nachricht-----
> Von: address@hidden [mailto:address@hidden Im Auftrag von Valdemar
> Gesendet: Montag, 17. Dezember 2007 11:03
> An: Mailing list for lwIP users
> Betreff: Re: [lwip-users] TCP/IP cange in behaviour?
>
> Hi again
> I went back to my first method of answering telnet commands and disabled the 
> Nagle algoritm and it worked as it did before.
> Many Thanks.
>
> What I said about the stack locking up I could not repeat. Maybe that was in a 
> later stage of my looking for the error.
>
> It would however have been nice to somehow being told why the transmission 
> stopped. Incrementing some error counter or a timeout with an error return from 
> tcp_write.
>
> Germund Asp
>
> address@hidden skrev:
> > It worked 'up to and including CVS 2007-10-08' and after upgrading to 
> > 'CVS 2007-12-05' it doesn't work any more? There's a big gap between 
> > october and december... The only real change in this time span has 
> > been on November 21st (TCP nagle algorithm implemented for raw api 
> > applications). To see if this is your problem you could
> >
> > a) test with a version from November 20th and November 22nd to see if 
> > the problem comes from that change or
> > b) disable the nagle algorithm for your pcb ('pS_pcb->flags |=
> > TF_NODELAY;') - most telnet implementations do this anyway to reduce 
> > delays.
> >
> > If this doesn't help, there could always be a bug somewhere... It does 
> > sound strange that the stack locks up though. To see why that happens, 
> > it would help to turn on debug output and watch the packets on the 
> > cable (using wireshark) - but only if the above 'fixes' don't help.
> >
> > Simon
> >
> >
> > Valdemar schrieb:
> > > Hi
> > > What has happened to the TCP/IP communication?
> > >
> > > In my application I have a telnet server for maintenance reasons. 
> > > This server worked fine up to and including CVS 2007-10-08.
> > > This is how I answered commands from the client:
> > >
> > > Testing  with tcp_sndbuf(pS_pcb) to see if there is buffer-space.
> > > (It always is, the sendbuffer is 10 kbytes.)
> > >
> > > Sending out with tcp_write(pS_pcb,.....).
> > >
> > > And tcp_output(pS_pcb) to send it directly.
> > >
> > > This was repeated until the entire command-answer was sent.
> > >
> > > The number of characters in each transmission was very small, but it 
> > > worked very well. Then I upgraded to CVS 2007-12-05 and it did not 
> > > work any more; the stack locked up after the second call to tcp_write.
> > > No stats showed any errors after the lock-up.
> > >
> > > To make the server work again I had to wait for each call to 
> > > tcp_write to be acknowledged with the number of sent characters 
> > > before calling tcp_write again.
> > >
> > > Is this a change in behaviour or is it just a flaw in my program?
> > > Has anyone else experienced this?
> > >
> > > I am using lwip in an application with an ATMEL AT91R40008 
> > > microcontroller running at 33 MHz and with a RS232 port in a system 
> > > that transfers cnc-programs from a pc to cnc-machines.
> > >
> > > A request: Could someone make the ARP-table and its definition global.
> > > I am displaying the table and don't want to change the lwip code 
> > > after evey update.
> > >
> > > Thanks for a great product.
> > >
> > > Germund Asp
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
>
>
> _______________________________________________
> 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

g3_telnet.pcap
Description: Binary data