kernel: HTB: dequeue bug (8), report it please ! kernel: htb*g j=8484601 kernel: htb*r7 m=0 kernel: htb*r6 m=0 kernel: htb*r5 m=0 kernel: htb*r4 m=0 kernel: htb*r3 m=0 kernel: htb*r2 m=0 kernel: htb*r1 m=0 kernel: htb*r0 m=0 kernel: htb*c10099 m=0 t=-161985 c=-56255 pq=8484601 df=49152 ql=14 pa=80 f: kernel: htb*c10010 m=2 t=365995 c=9162 pq=0 df=60000000 ql=0 pa=0 f: kernel: htb*c10002 m=2 t=9480 c=9072 pq=0 df=0 ql=0 pa=0 f: kernel: htb*c10020 m=2 t=1529601 c=84950 pq=0 df=2187264 ql=0 pa=0 f: kernel: htb*c10030 m=2 t=768000 c=48174 pq=0 df=60000000 ql=0 pa=0 f: kernel: htb*c10040 m=2 t=1536000 c=88149 pq=0 df=60000000 ql=0 pa=0 f: kernel: htb*c10051 m=2 t=1528801 c=84550 pq=0 df=13516800 ql=0 pa=0 f: kernel: htb*c10041 m=2 t=1531201 c=85750 pq=0 df=60000000 ql=0 pa=0 f: kernel: htb*c10050 m=2 t=768000 c=9191 pq=0 df=60000000 ql=0 pa=0 f: kernel: htb*c10042 m=2 t=1536000 c=88149 pq=0 df=60000000 ql=0 pa=0 f: kernel: htb*c10060 m=2 t=379201 c=9072 pq=0 df=0 ql=0 pa=0 f: iproute2-ss020116 kernel 2.4.21 -- Sergey Smirnov _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Dear lartc, I have a TCP/IP server connecting to a GPRS PDA. Unfortuntatelly GPRS seems unstable, and for this reason or another, a interupt to the TCP/IP connection (like switching the clinet off suddenly) does not terminate the TCP/IP connection. It can still be seen in ''netstat'', and a test by the application shows it present. It may time out after about 40 minutes. My real problem is a call to ''write'' in non-blocking mode returns success when the other end of the TCP/IP connection is not there. Does any member know a reference to where I can test for the reply TCP/IP ''ACK'' packet for this write call, and therefore timeout and terminate the connection? Thanks in advance, Ben Clewett. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Tue, Jul 29, 2003 at 08:56:24AM +0000, Ben Clewett wrote:> Dear lartc, > > I have a TCP/IP server connecting to a GPRS PDA. > > Unfortuntatelly GPRS seems unstable, and for this reason or another, a > interupt to the TCP/IP connection (like switching the clinet off > suddenly) does not terminate the TCP/IP connection. It can still be > seen in ''netstat'', and a test by the application shows it present. It > may time out after about 40 minutes. > > My real problem is a call to ''write'' in non-blocking mode returns > success when the other end of the TCP/IP connection is not there. > > Does any member know a reference to where I can test for the reply > TCP/IP ''ACK'' packet for this write call, and therefore timeout and > terminate the connection?You can try using the ioctl TIOCOUTQ, see socket(7). Although this manpage states otherwise, at least on 2.4.21 and newer it returns the number of unacked bytes. Implement a select-loop, and see if the value of this ioctl changes. If not, close the connection, and the kernel should handle the rest. VrGr, -- Jasper Spaans http://jsp.vs19.net/contact/ <== Het bedrijf van de appelcomputer is niet ==> <== verantwoordelijk voor de omzettingsprecisie. ==> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Jasper, Thanks. This works absolutelly perfectly! I found that simply waiting for the TIOCOUTQ to fall to zero gives a perfect indication of data having been sent correctly, and if not, that the connection is stale. I have put this into a: while (test) sleep(1); But this waists time. With a ping of 300ms being common, a sleep of 1000ms is way to much to check every send, so I can only check agregates of sending. Would anybody know of a better method? Ben Jasper Spaans wrote:> On Tue, Jul 29, 2003 at 08:56:24AM +0000, Ben Clewett wrote: > >>Dear lartc, >> >>I have a TCP/IP server connecting to a GPRS PDA. >> >>Unfortuntatelly GPRS seems unstable, and for this reason or another, a >>interupt to the TCP/IP connection (like switching the clinet off >>suddenly) does not terminate the TCP/IP connection. It can still be >>seen in ''netstat'', and a test by the application shows it present. It >>may time out after about 40 minutes. >> >>My real problem is a call to ''write'' in non-blocking mode returns >>success when the other end of the TCP/IP connection is not there. >> >>Does any member know a reference to where I can test for the reply >>TCP/IP ''ACK'' packet for this write call, and therefore timeout and >>terminate the connection? > > > You can try using the ioctl TIOCOUTQ, see socket(7). Although this manpage > states otherwise, at least on 2.4.21 and newer it returns the number of > unacked bytes. > > Implement a select-loop, and see if the value of this ioctl changes. If not, > close the connection, and the kernel should handle the rest. > > > VrGr,_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/