A nasty io-net bug

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
while we have situation when we can’t use some port anymore. The same
server on different port continues to serve requests just fine but any
attempt to connect to port which have been in use for a while (week or
more) ends up with timeout. So far it happened with inetd and httpd.

Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
one, below commands from another console). At the same time ‘telnet
127.0.0.1 24’ works just fine. The first telnet eventually says
‘connection timedout’…

pidin | grep telnet

136798241 1 bin/telnetd 19r SIGWAITINFO
142790692 1 bin/telnet 10r REPLY 294924

pidin | grep 294924

294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
294924 2 o-net/x86/o/io-net 17r RECEIVE 1
294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
294924 4 o-net/x86/o/io-net 21r RECEIVE 3
294924 5 o-net/x86/o/io-net 21r RECEIVE 6
294924 6 o-net/x86/o/io-net 21r RECEIVE 9
294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
294924 10 o-net/x86/o/io-net 17r RECEIVE 1
294924 11 o-net/x86/o/io-net 17r RECEIVE 1
294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
294924 14 o-net/x86/o/io-net 17r RECEIVE 1

cat /proc/ipstats

Ttcpip Sep 24 2000 19:57:39

verbosity level 0
ip checksum errors: 0
udp checksum errors: 0
tcp checksum errors: 0

packets sent: 9570945
packets received: 10178301

en1 : addr 192.168.1.1 netmask 255.255.255.0 up
en0 : addr 203.8.22.36 netmask 255.255.255.0 up
lo0 : addr 127.0.0.1 netmask 255.0.0.0 up

DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254

TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
rcv
0
TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
rcv
0
TCP 0.0.0.0.21 LISTEN
TCP 0.0.0.0.8080 LISTEN
TCP 0.0.0.0.80 LISTEN
TCP 203.8.22.36.9000 LISTEN
TCP 0.0.0.0.9999 LISTEN
TCP 0.0.0.0.5010 LISTEN
TCP 0.0.0.0.5009 LISTEN
TCP 0.0.0.0.5008 LISTEN
TCP 0.0.0.0.5007 LISTEN
TCP 0.0.0.0.5005 LISTEN
TCP 0.0.0.0.5004 LISTEN
TCP 0.0.0.0.5003 LISTEN
TCP 0.0.0.0.5002 LISTEN
TCP 0.0.0.0.5006 LISTEN
TCP 0.0.0.0.5001 LISTEN
TCP 0.0.0.0.24 LISTEN
TCP 0.0.0.0.19 LISTEN
TCP 0.0.0.0.13 LISTEN
TCP 0.0.0.0.9 LISTEN
TCP 0.0.0.0.7 LISTEN
TCP 0.0.0.0.561 LISTEN
TCP 0.0.0.0.560 LISTEN
TCP 0.0.0.0.559 LISTEN
TCP 0.0.0.0.558 LISTEN
TCP 0.0.0.0.557 LISTEN
TCP 0.0.0.0.23 LISTEN
TCP 0.0.0.0.37 LISTEN
UDP 0.0.0.0.514 > 0.0.0.0.0
UDP 0.0.0.0.7 > 0.0.0.0.0
UDP 0.0.0.0.9 > 0.0.0.0.0
UDP 0.0.0.0.13 > 0.0.0.0.0
UDP 192.168.1.1.10000 > 192.168.1.2.10000
UDP 0.0.0.0.19 > 0.0.0.0.0
UDP 0.0.0.0.37 > 0.0.0.0.0
UDP 192.168.1.1.8000 > 192.168.1.2.8000
UDP 192.168.1.1.8001 > 192.168.1.2.8001
UDP 192.168.1.1.8002 > 192.168.1.2.8002
UDP 192.168.1.1.8003 > 192.168.1.2.8003
UDP 192.168.1.1.8004 > 192.168.1.2.8004
UDP 192.168.1.1.8005 > 192.168.1.2.8005
UDP 192.168.1.1.8006 > 192.168.1.2.8006
UDP 192.168.1.1.8007 > 192.168.1.2.8007
UDP 192.168.1.1.8008 > 192.168.1.2.8008
UDP 192.168.1.1.8009 > 192.168.1.2.8009
UDP 192.168.1.1.8010 > 0.0.0.0.0
UDP 192.168.1.1.8011 > 0.0.0.0.0
UDP 192.168.1.1.8012 > 192.168.1.2.8012
UDP 192.168.1.1.8013 > 192.168.1.2.8013
UDP 192.168.1.1.8014 > 192.168.1.2.8014
UDP 192.168.1.1.8015 > 192.168.1.2.8015
UDP 203.8.22.36.6500 > 0.0.0.0.0
UDP 203.8.22.36.2161 > 203.8.22.17.32792
UDP 203.8.22.36.162 > 203.8.22.17.32791
UDP 0.0.0.0.930 > 145.1.197.1.2049

Any ideas? What other info do you guys need?

  • Igor
2

What, nobody has any clue?
Sean and Xtang are you here?

Igor Kovalenko wrote:

I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
while we have situation when we can’t use some port anymore. The same
server on different port continues to serve requests just fine but any
attempt to connect to port which have been in use for a while (week or
more) ends up with timeout. So far it happened with inetd and httpd.

Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
one, below commands from another console). At the same time ‘telnet
127.0.0.1 24’ works just fine. The first telnet eventually says
‘connection timedout’…

pidin | grep telnet

136798241 1 bin/telnetd 19r SIGWAITINFO
142790692 1 bin/telnet 10r REPLY 294924

pidin | grep 294924

294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
294924 2 o-net/x86/o/io-net 17r RECEIVE 1
294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
294924 4 o-net/x86/o/io-net 21r RECEIVE 3
294924 5 o-net/x86/o/io-net 21r RECEIVE 6
294924 6 o-net/x86/o/io-net 21r RECEIVE 9
294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
294924 10 o-net/x86/o/io-net 17r RECEIVE 1
294924 11 o-net/x86/o/io-net 17r RECEIVE 1
294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
294924 14 o-net/x86/o/io-net 17r RECEIVE 1

cat /proc/ipstats

Ttcpip Sep 24 2000 19:57:39

verbosity level 0
ip checksum errors: 0
udp checksum errors: 0
tcp checksum errors: 0

packets sent: 9570945
packets received: 10178301

en1 : addr 192.168.1.1 netmask 255.255.255.0 up
en0 : addr 203.8.22.36 netmask 255.255.255.0 up
lo0 : addr 127.0.0.1 netmask 255.0.0.0 up

DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254

TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
rcv
0
TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
rcv
0
TCP 0.0.0.0.21 LISTEN
TCP 0.0.0.0.8080 LISTEN
TCP 0.0.0.0.80 LISTEN
TCP 203.8.22.36.9000 LISTEN
TCP 0.0.0.0.9999 LISTEN
TCP 0.0.0.0.5010 LISTEN
TCP 0.0.0.0.5009 LISTEN
TCP 0.0.0.0.5008 LISTEN
TCP 0.0.0.0.5007 LISTEN
TCP 0.0.0.0.5005 LISTEN
TCP 0.0.0.0.5004 LISTEN
TCP 0.0.0.0.5003 LISTEN
TCP 0.0.0.0.5002 LISTEN
TCP 0.0.0.0.5006 LISTEN
TCP 0.0.0.0.5001 LISTEN
TCP 0.0.0.0.24 LISTEN
TCP 0.0.0.0.19 LISTEN
TCP 0.0.0.0.13 LISTEN
TCP 0.0.0.0.9 LISTEN
TCP 0.0.0.0.7 LISTEN
TCP 0.0.0.0.561 LISTEN
TCP 0.0.0.0.560 LISTEN
TCP 0.0.0.0.559 LISTEN
TCP 0.0.0.0.558 LISTEN
TCP 0.0.0.0.557 LISTEN
TCP 0.0.0.0.23 LISTEN
TCP 0.0.0.0.37 LISTEN
UDP 0.0.0.0.514 > 0.0.0.0.0
UDP 0.0.0.0.7 > 0.0.0.0.0
UDP 0.0.0.0.9 > 0.0.0.0.0
UDP 0.0.0.0.13 > 0.0.0.0.0
UDP 192.168.1.1.10000 > 192.168.1.2.10000
UDP 0.0.0.0.19 > 0.0.0.0.0
UDP 0.0.0.0.37 > 0.0.0.0.0
UDP 192.168.1.1.8000 > 192.168.1.2.8000
UDP 192.168.1.1.8001 > 192.168.1.2.8001
UDP 192.168.1.1.8002 > 192.168.1.2.8002
UDP 192.168.1.1.8003 > 192.168.1.2.8003
UDP 192.168.1.1.8004 > 192.168.1.2.8004
UDP 192.168.1.1.8005 > 192.168.1.2.8005
UDP 192.168.1.1.8006 > 192.168.1.2.8006
UDP 192.168.1.1.8007 > 192.168.1.2.8007
UDP 192.168.1.1.8008 > 192.168.1.2.8008
UDP 192.168.1.1.8009 > 192.168.1.2.8009
UDP 192.168.1.1.8010 > 0.0.0.0.0
UDP 192.168.1.1.8011 > 0.0.0.0.0
UDP 192.168.1.1.8012 > 192.168.1.2.8012
UDP 192.168.1.1.8013 > 192.168.1.2.8013
UDP 192.168.1.1.8014 > 192.168.1.2.8014
UDP 192.168.1.1.8015 > 192.168.1.2.8015
UDP 203.8.22.36.6500 > 0.0.0.0.0
UDP 203.8.22.36.2161 > 203.8.22.17.32792
UDP 203.8.22.36.162 > 203.8.22.17.32791
UDP 0.0.0.0.930 > 145.1.197.1.2049

Any ideas? What other info do you guys need?

  • Igor
3

Hi,

It seems Ok on normal TCP/IP stack :wink:
Here you have a transcript :wink:

telnet 127.0.0.1

Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
login: root
Password:
05/31/01 16:48:47 on /dev/ttyp2
Last login: 05/31/01 16:48:14 on /dev/ttyp2
edit the file .profile if you want to change your environment.
To start the Photon windowing environment, type “ph”.

pidin | grep telnet

4419617 1 usr/sbin/telnetd 10r SIGWAITINFO
5038115 1 usr/bin/telnet 10r SIGWAITINFO
5042212 1 usr/sbin/telnetd 10r SIGWAITINFO

perhaps, the reason is tiny stack…

Igor Kovalenko wrote:

I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
while we have situation when we can’t use some port anymore. The same
server on different port continues to serve requests just fine but any
attempt to connect to port which have been in use for a while (week or
more) ends up with timeout. So far it happened with inetd and httpd.

Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
one, below commands from another console). At the same time ‘telnet
127.0.0.1 24’ works just fine. The first telnet eventually says
‘connection timedout’…

pidin | grep telnet

136798241 1 bin/telnetd 19r SIGWAITINFO
142790692 1 bin/telnet 10r REPLY 294924

pidin | grep 294924

294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
294924 2 o-net/x86/o/io-net 17r RECEIVE 1
294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
294924 4 o-net/x86/o/io-net 21r RECEIVE 3
294924 5 o-net/x86/o/io-net 21r RECEIVE 6
294924 6 o-net/x86/o/io-net 21r RECEIVE 9
294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
294924 10 o-net/x86/o/io-net 17r RECEIVE 1
294924 11 o-net/x86/o/io-net 17r RECEIVE 1
294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
294924 14 o-net/x86/o/io-net 17r RECEIVE 1

cat /proc/ipstats

Ttcpip Sep 24 2000 19:57:39

verbosity level 0
ip checksum errors: 0
udp checksum errors: 0
tcp checksum errors: 0

packets sent: 9570945
packets received: 10178301

en1 : addr 192.168.1.1 netmask 255.255.255.0 up
en0 : addr 203.8.22.36 netmask 255.255.255.0 up
lo0 : addr 127.0.0.1 netmask 255.0.0.0 up

DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254

TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
rcv
0
TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
rcv
0
TCP 0.0.0.0.21 LISTEN
TCP 0.0.0.0.8080 LISTEN
TCP 0.0.0.0.80 LISTEN
TCP 203.8.22.36.9000 LISTEN
TCP 0.0.0.0.9999 LISTEN
TCP 0.0.0.0.5010 LISTEN
TCP 0.0.0.0.5009 LISTEN
TCP 0.0.0.0.5008 LISTEN
TCP 0.0.0.0.5007 LISTEN
TCP 0.0.0.0.5005 LISTEN
TCP 0.0.0.0.5004 LISTEN
TCP 0.0.0.0.5003 LISTEN
TCP 0.0.0.0.5002 LISTEN
TCP 0.0.0.0.5006 LISTEN
TCP 0.0.0.0.5001 LISTEN
TCP 0.0.0.0.24 LISTEN
TCP 0.0.0.0.19 LISTEN
TCP 0.0.0.0.13 LISTEN
TCP 0.0.0.0.9 LISTEN
TCP 0.0.0.0.7 LISTEN
TCP 0.0.0.0.561 LISTEN
TCP 0.0.0.0.560 LISTEN
TCP 0.0.0.0.559 LISTEN
TCP 0.0.0.0.558 LISTEN
TCP 0.0.0.0.557 LISTEN
TCP 0.0.0.0.23 LISTEN
TCP 0.0.0.0.37 LISTEN
UDP 0.0.0.0.514 > 0.0.0.0.0
UDP 0.0.0.0.7 > 0.0.0.0.0
UDP 0.0.0.0.9 > 0.0.0.0.0
UDP 0.0.0.0.13 > 0.0.0.0.0
UDP 192.168.1.1.10000 > 192.168.1.2.10000
UDP 0.0.0.0.19 > 0.0.0.0.0
UDP 0.0.0.0.37 > 0.0.0.0.0
UDP 192.168.1.1.8000 > 192.168.1.2.8000
UDP 192.168.1.1.8001 > 192.168.1.2.8001
UDP 192.168.1.1.8002 > 192.168.1.2.8002
UDP 192.168.1.1.8003 > 192.168.1.2.8003
UDP 192.168.1.1.8004 > 192.168.1.2.8004
UDP 192.168.1.1.8005 > 192.168.1.2.8005
UDP 192.168.1.1.8006 > 192.168.1.2.8006
UDP 192.168.1.1.8007 > 192.168.1.2.8007
UDP 192.168.1.1.8008 > 192.168.1.2.8008
UDP 192.168.1.1.8009 > 192.168.1.2.8009
UDP 192.168.1.1.8010 > 0.0.0.0.0
UDP 192.168.1.1.8011 > 0.0.0.0.0
UDP 192.168.1.1.8012 > 192.168.1.2.8012
UDP 192.168.1.1.8013 > 192.168.1.2.8013
UDP 192.168.1.1.8014 > 192.168.1.2.8014
UDP 192.168.1.1.8015 > 192.168.1.2.8015
UDP 203.8.22.36.6500 > 0.0.0.0.0
UDP 203.8.22.36.2161 > 203.8.22.17.32792
UDP 203.8.22.36.162 > 203.8.22.17.32791
UDP 0.0.0.0.930 > 145.1.197.1.2049

Any ideas? What other info do you guys need?

  • Igor

–
BR, Andrej

4

Have you tried to give it a long run? Seems to me that if stack was
problem then all ports would be stuck not just one…

  • igor

“Andrej Timchenko” <andrej.timchenko@nokia.com> wrote in message
news:3B164CDE.A04B69AC@nokia.com…

Hi,

It seems Ok on normal TCP/IP stack > :wink:
Here you have a transcript > :wink:

telnet 127.0.0.1

Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
login: root
Password:
05/31/01 16:48:47 on /dev/ttyp2
Last login: 05/31/01 16:48:14 on /dev/ttyp2
edit the file .profile if you want to change your environment.
To start the Photon windowing environment, type “ph”.

pidin | grep telnet

4419617 1 usr/sbin/telnetd 10r SIGWAITINFO
5038115 1 usr/bin/telnet 10r SIGWAITINFO
5042212 1 usr/sbin/telnetd 10r SIGWAITINFO

perhaps, the reason is tiny stack…

Igor Kovalenko wrote:

I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
while we have situation when we can’t use some port anymore. The same
server on different port continues to serve requests just fine but any
attempt to connect to port which have been in use for a while (week or
more) ends up with timeout. So far it happened with inetd and httpd.

Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
one, below commands from another console). At the same time ‘telnet
127.0.0.1 24’ works just fine. The first telnet eventually says
‘connection timedout’…

pidin | grep telnet

136798241 1 bin/telnetd 19r SIGWAITINFO
142790692 1 bin/telnet 10r REPLY 294924

pidin | grep 294924

294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
294924 2 o-net/x86/o/io-net 17r RECEIVE 1
294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
294924 4 o-net/x86/o/io-net 21r RECEIVE 3
294924 5 o-net/x86/o/io-net 21r RECEIVE 6
294924 6 o-net/x86/o/io-net 21r RECEIVE 9
294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
294924 10 o-net/x86/o/io-net 17r RECEIVE 1
294924 11 o-net/x86/o/io-net 17r RECEIVE 1
294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
294924 14 o-net/x86/o/io-net 17r RECEIVE 1

cat /proc/ipstats

Ttcpip Sep 24 2000 19:57:39

verbosity level 0
ip checksum errors: 0
udp checksum errors: 0
tcp checksum errors: 0

packets sent: 9570945
packets received: 10178301

en1 : addr 192.168.1.1 netmask 255.255.255.0 up
en0 : addr 203.8.22.36 netmask 255.255.255.0 up
lo0 : addr 127.0.0.1 netmask 255.0.0.0 up

DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254

TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
rcv
0
TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
rcv
0
TCP 0.0.0.0.21 LISTEN
TCP 0.0.0.0.8080 LISTEN
TCP 0.0.0.0.80 LISTEN
TCP 203.8.22.36.9000 LISTEN
TCP 0.0.0.0.9999 LISTEN
TCP 0.0.0.0.5010 LISTEN
TCP 0.0.0.0.5009 LISTEN
TCP 0.0.0.0.5008 LISTEN
TCP 0.0.0.0.5007 LISTEN
TCP 0.0.0.0.5005 LISTEN
TCP 0.0.0.0.5004 LISTEN
TCP 0.0.0.0.5003 LISTEN
TCP 0.0.0.0.5002 LISTEN
TCP 0.0.0.0.5006 LISTEN
TCP 0.0.0.0.5001 LISTEN
TCP 0.0.0.0.24 LISTEN
TCP 0.0.0.0.19 LISTEN
TCP 0.0.0.0.13 LISTEN
TCP 0.0.0.0.9 LISTEN
TCP 0.0.0.0.7 LISTEN
TCP 0.0.0.0.561 LISTEN
TCP 0.0.0.0.560 LISTEN
TCP 0.0.0.0.559 LISTEN
TCP 0.0.0.0.558 LISTEN
TCP 0.0.0.0.557 LISTEN
TCP 0.0.0.0.23 LISTEN
TCP 0.0.0.0.37 LISTEN
UDP 0.0.0.0.514 > 0.0.0.0.0
UDP 0.0.0.0.7 > 0.0.0.0.0
UDP 0.0.0.0.9 > 0.0.0.0.0
UDP 0.0.0.0.13 > 0.0.0.0.0
UDP 192.168.1.1.10000 > 192.168.1.2.10000
UDP 0.0.0.0.19 > 0.0.0.0.0
UDP 0.0.0.0.37 > 0.0.0.0.0
UDP 192.168.1.1.8000 > 192.168.1.2.8000
UDP 192.168.1.1.8001 > 192.168.1.2.8001
UDP 192.168.1.1.8002 > 192.168.1.2.8002
UDP 192.168.1.1.8003 > 192.168.1.2.8003
UDP 192.168.1.1.8004 > 192.168.1.2.8004
UDP 192.168.1.1.8005 > 192.168.1.2.8005
UDP 192.168.1.1.8006 > 192.168.1.2.8006
UDP 192.168.1.1.8007 > 192.168.1.2.8007
UDP 192.168.1.1.8008 > 192.168.1.2.8008
UDP 192.168.1.1.8009 > 192.168.1.2.8009
UDP 192.168.1.1.8010 > 0.0.0.0.0
UDP 192.168.1.1.8011 > 0.0.0.0.0
UDP 192.168.1.1.8012 > 192.168.1.2.8012
UDP 192.168.1.1.8013 > 192.168.1.2.8013
UDP 192.168.1.1.8014 > 192.168.1.2.8014
UDP 192.168.1.1.8015 > 192.168.1.2.8015
UDP 203.8.22.36.6500 > 0.0.0.0.0
UDP 203.8.22.36.2161 > 203.8.22.17.32792
UDP 203.8.22.36.162 > 203.8.22.17.32791
UDP 0.0.0.0.930 > 145.1.197.1.2049

Any ideas? What other info do you guys need?

  • Igor

–
BR, Andrej

5

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

What, nobody has any clue?
Sean and Xtang are you here?

Sean is on vercation so I tried to give it a shoot, but not get too far.

Igor, if you can get a tcpdump on the faild (timed out) tcp link,
it might confirm me something.

Your pidin output and “cat /proc/ipstats” seems not match. I see
only one “telnet” process, and one “telnetd” process. I guess that’s
“localhost.3701 <-> localhost.24”, so where is the “telnet” for
“localhost.xxxx <-> localhost.23” (the timedout one).

I would like a pidin output before the telnet timeout, cause I
want to confirm if telneted started or not.

I assume that telnet is not finished it’s 3-way hand-shack, (this
is where I want to see a tcpdump to confirm) but look at small
stack code that only way it can fail is low memory. I don’t
think you are in that satuation.

I am still in dark, and without too much luck to reproduce it
here.

-xtang

Igor Kovalenko wrote:

I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
while we have situation when we can’t use some port anymore. The same
server on different port continues to serve requests just fine but any
attempt to connect to port which have been in use for a while (week or
more) ends up with timeout. So far it happened with inetd and httpd.

Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
one, below commands from another console). At the same time ‘telnet
127.0.0.1 24’ works just fine. The first telnet eventually says
‘connection timedout’…

pidin | grep telnet

136798241 1 bin/telnetd 19r SIGWAITINFO
142790692 1 bin/telnet 10r REPLY 294924

pidin | grep 294924

294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
294924 2 o-net/x86/o/io-net 17r RECEIVE 1
294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
294924 4 o-net/x86/o/io-net 21r RECEIVE 3
294924 5 o-net/x86/o/io-net 21r RECEIVE 6
294924 6 o-net/x86/o/io-net 21r RECEIVE 9
294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
294924 10 o-net/x86/o/io-net 17r RECEIVE 1
294924 11 o-net/x86/o/io-net 17r RECEIVE 1
294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
294924 14 o-net/x86/o/io-net 17r RECEIVE 1

cat /proc/ipstats

Ttcpip Sep 24 2000 19:57:39

verbosity level 0
ip checksum errors: 0
udp checksum errors: 0
tcp checksum errors: 0

packets sent: 9570945
packets received: 10178301

en1 : addr 192.168.1.1 netmask 255.255.255.0 up
en0 : addr 203.8.22.36 netmask 255.255.255.0 up
lo0 : addr 127.0.0.1 netmask 255.0.0.0 up

DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254

TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
rcv
0
TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
rcv
0
TCP 0.0.0.0.21 LISTEN
TCP 0.0.0.0.8080 LISTEN
TCP 0.0.0.0.80 LISTEN
TCP 203.8.22.36.9000 LISTEN
TCP 0.0.0.0.9999 LISTEN
TCP 0.0.0.0.5010 LISTEN
TCP 0.0.0.0.5009 LISTEN
TCP 0.0.0.0.5008 LISTEN
TCP 0.0.0.0.5007 LISTEN
TCP 0.0.0.0.5005 LISTEN
TCP 0.0.0.0.5004 LISTEN
TCP 0.0.0.0.5003 LISTEN
TCP 0.0.0.0.5002 LISTEN
TCP 0.0.0.0.5006 LISTEN
TCP 0.0.0.0.5001 LISTEN
TCP 0.0.0.0.24 LISTEN
TCP 0.0.0.0.19 LISTEN
TCP 0.0.0.0.13 LISTEN
TCP 0.0.0.0.9 LISTEN
TCP 0.0.0.0.7 LISTEN
TCP 0.0.0.0.561 LISTEN
TCP 0.0.0.0.560 LISTEN
TCP 0.0.0.0.559 LISTEN
TCP 0.0.0.0.558 LISTEN
TCP 0.0.0.0.557 LISTEN
TCP 0.0.0.0.23 LISTEN
TCP 0.0.0.0.37 LISTEN
UDP 0.0.0.0.514 > 0.0.0.0.0
UDP 0.0.0.0.7 > 0.0.0.0.0
UDP 0.0.0.0.9 > 0.0.0.0.0
UDP 0.0.0.0.13 > 0.0.0.0.0
UDP 192.168.1.1.10000 > 192.168.1.2.10000
UDP 0.0.0.0.19 > 0.0.0.0.0
UDP 0.0.0.0.37 > 0.0.0.0.0
UDP 192.168.1.1.8000 > 192.168.1.2.8000
UDP 192.168.1.1.8001 > 192.168.1.2.8001
UDP 192.168.1.1.8002 > 192.168.1.2.8002
UDP 192.168.1.1.8003 > 192.168.1.2.8003
UDP 192.168.1.1.8004 > 192.168.1.2.8004
UDP 192.168.1.1.8005 > 192.168.1.2.8005
UDP 192.168.1.1.8006 > 192.168.1.2.8006
UDP 192.168.1.1.8007 > 192.168.1.2.8007
UDP 192.168.1.1.8008 > 192.168.1.2.8008
UDP 192.168.1.1.8009 > 192.168.1.2.8009
UDP 192.168.1.1.8010 > 0.0.0.0.0
UDP 192.168.1.1.8011 > 0.0.0.0.0
UDP 192.168.1.1.8012 > 192.168.1.2.8012
UDP 192.168.1.1.8013 > 192.168.1.2.8013
UDP 192.168.1.1.8014 > 192.168.1.2.8014
UDP 192.168.1.1.8015 > 192.168.1.2.8015
UDP 203.8.22.36.6500 > 0.0.0.0.0
UDP 203.8.22.36.2161 > 203.8.22.17.32792
UDP 203.8.22.36.162 > 203.8.22.17.32791
UDP 0.0.0.0.930 > 145.1.197.1.2049

Any ideas? What other info do you guys need?

  • Igor
6

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:9f9dml$ia8$2@nntp.qnx.com…

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
What, nobody has any clue?
Sean and Xtang are you here?

Sean is on vercation so I tried to give it a shoot, but not get too far.

Igor, if you can get a tcpdump on the faild (timed out) tcp link,
it might confirm me something.

Your pidin output and “cat /proc/ipstats” seems not match. I see
only one “telnet” process, and one “telnetd” process. I guess that’s
“localhost.3701 <-> localhost.24”, so where is the “telnet” for
“localhost.xxxx <-> localhost.23” (the timedout one).

Actually that one ‘telnet’ process is the one timing out, and it was to port
23. I’m really sure about that because I played with this situation a lot.
Yes I guess that’s why outputs were out of sync sorry about that. The
ESTABLISHED connection on port 24 corresponded to another telnet session
which worked just fine.

I would like a pidin output before the telnet timeout, cause I
want to confirm if telneted started or not.

If you can take my word, it was not started. That was obvious thing for me
to check…

I assume that telnet is not finished it’s 3-way hand-shack, (this
is where I want to see a tcpdump to confirm) but look at small
stack code that only way it can fail is low memory. I don’t
think you are in that satuation.

I am still in dark, and without too much luck to reproduce it
here.

It is hard to reproduce when you want it but happens every once in a while.
I knew this whole thing would not make much sense. Honestly I don’t think
problem is either in the stack or io-net. Notice the thread in io-net which
is sitting on b036bb50 condvar. That is condvar used by resmgr library to
lock attributes… You might want to talk to thomasf, he is chasing a
problem very similar to this with a client getting stuck on pipe right now
(and I had such problem with pipe too). You might also want to talk to
jgarvey because both me and him saw similar problem with clients getting
stuck on devb drivers… and he believes that condvar somehow gets
unbalanced for a mysterious reason.

That condvar was involved in all those cases. Problem must be somewhere in
common place. With resmgr library or even deeper in libc or in kernel. May
be if you all guys get together and get some kernel dude too you might
finally pull it. I’m trying to tell various people about this problem for
over a year and almost noone listened so far. Noone just wants to believe it
exists…

Good hunting

  • igor

-xtang

Igor Kovalenko wrote:

I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
while we have situation when we can’t use some port anymore. The same
server on different port continues to serve requests just fine but any
attempt to connect to port which have been in use for a while (week or
more) ends up with timeout. So far it happened with inetd and httpd.

Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
one, below commands from another console). At the same time ‘telnet
127.0.0.1 24’ works just fine. The first telnet eventually says
‘connection timedout’…

pidin | grep telnet

136798241 1 bin/telnetd 19r SIGWAITINFO
142790692 1 bin/telnet 10r REPLY 294924

pidin | grep 294924

294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
294924 2 o-net/x86/o/io-net 17r RECEIVE 1
294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
294924 4 o-net/x86/o/io-net 21r RECEIVE 3
294924 5 o-net/x86/o/io-net 21r RECEIVE 6
294924 6 o-net/x86/o/io-net 21r RECEIVE 9
294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
294924 10 o-net/x86/o/io-net 17r RECEIVE 1
294924 11 o-net/x86/o/io-net 17r RECEIVE 1
294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
294924 14 o-net/x86/o/io-net 17r RECEIVE 1

cat /proc/ipstats

Ttcpip Sep 24 2000 19:57:39

verbosity level 0
ip checksum errors: 0
udp checksum errors: 0
tcp checksum errors: 0

packets sent: 9570945
packets received: 10178301

en1 : addr 192.168.1.1 netmask 255.255.255.0 up
en0 : addr 203.8.22.36 netmask 255.255.255.0 up
lo0 : addr 127.0.0.1 netmask 255.0.0.0 up

DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254

TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
rcv
0
TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
rcv
0
TCP 0.0.0.0.21 LISTEN
TCP 0.0.0.0.8080 LISTEN
TCP 0.0.0.0.80 LISTEN
TCP 203.8.22.36.9000 LISTEN
TCP 0.0.0.0.9999 LISTEN
TCP 0.0.0.0.5010 LISTEN
TCP 0.0.0.0.5009 LISTEN
TCP 0.0.0.0.5008 LISTEN
TCP 0.0.0.0.5007 LISTEN
TCP 0.0.0.0.5005 LISTEN
TCP 0.0.0.0.5004 LISTEN
TCP 0.0.0.0.5003 LISTEN
TCP 0.0.0.0.5002 LISTEN
TCP 0.0.0.0.5006 LISTEN
TCP 0.0.0.0.5001 LISTEN
TCP 0.0.0.0.24 LISTEN
TCP 0.0.0.0.19 LISTEN
TCP 0.0.0.0.13 LISTEN
TCP 0.0.0.0.9 LISTEN
TCP 0.0.0.0.7 LISTEN
TCP 0.0.0.0.561 LISTEN
TCP 0.0.0.0.560 LISTEN
TCP 0.0.0.0.559 LISTEN
TCP 0.0.0.0.558 LISTEN
TCP 0.0.0.0.557 LISTEN
TCP 0.0.0.0.23 LISTEN
TCP 0.0.0.0.37 LISTEN
UDP 0.0.0.0.514 > 0.0.0.0.0
UDP 0.0.0.0.7 > 0.0.0.0.0
UDP 0.0.0.0.9 > 0.0.0.0.0
UDP 0.0.0.0.13 > 0.0.0.0.0
UDP 192.168.1.1.10000 > 192.168.1.2.10000
UDP 0.0.0.0.19 > 0.0.0.0.0
UDP 0.0.0.0.37 > 0.0.0.0.0
UDP 192.168.1.1.8000 > 192.168.1.2.8000
UDP 192.168.1.1.8001 > 192.168.1.2.8001
UDP 192.168.1.1.8002 > 192.168.1.2.8002
UDP 192.168.1.1.8003 > 192.168.1.2.8003
UDP 192.168.1.1.8004 > 192.168.1.2.8004
UDP 192.168.1.1.8005 > 192.168.1.2.8005
UDP 192.168.1.1.8006 > 192.168.1.2.8006
UDP 192.168.1.1.8007 > 192.168.1.2.8007
UDP 192.168.1.1.8008 > 192.168.1.2.8008
UDP 192.168.1.1.8009 > 192.168.1.2.8009
UDP 192.168.1.1.8010 > 0.0.0.0.0
UDP 192.168.1.1.8011 > 0.0.0.0.0
UDP 192.168.1.1.8012 > 192.168.1.2.8012
UDP 192.168.1.1.8013 > 192.168.1.2.8013
UDP 192.168.1.1.8014 > 192.168.1.2.8014
UDP 192.168.1.1.8015 > 192.168.1.2.8015
UDP 203.8.22.36.6500 > 0.0.0.0.0
UDP 203.8.22.36.2161 > 203.8.22.17.32792
UDP 203.8.22.36.162 > 203.8.22.17.32791
UDP 0.0.0.0.930 > 145.1.197.1.2049

Any ideas? What other info do you guys need?

  • Igor
7

“Igor Kovalenko” <kovalenko@home.com> wrote in message
news:9fa0eh$b0p$1@inn.qnx.com…

“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:9f9dml$ia8$> 2@nntp.qnx.com> …
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
What, nobody has any clue?
Sean and Xtang are you here?

Sean is on vercation so I tried to give it a shoot, but not get too far.

Igor, if you can get a tcpdump on the faild (timed out) tcp link,
it might confirm me something.

Your pidin output and “cat /proc/ipstats” seems not match. I see
only one “telnet” process, and one “telnetd” process. I guess that’s
“localhost.3701 <-> localhost.24”, so where is the “telnet” for
“localhost.xxxx <-> localhost.23” (the timedout one).


Actually that one ‘telnet’ process is the one timing out, and it was to
port
23. I’m really sure about that because I played with this situation a lot.
Yes I guess that’s why outputs were out of sync sorry about that. The
ESTABLISHED connection on port 24 corresponded to another telnet session
which worked just fine.

To make it little clearer… the ‘telnetd’ process corresponds to still
active connection on port 24 from another host (127.6.68.16). Another
session (from localhost to localhost on port 24) I probably closed between
doing snapshots of ipstats and pidin so you can just ignore that line of
ipstats because it is irrelevant.

I would like a pidin output before the telnet timeout, cause I
want to confirm if telneted started or not.


If you can take my word, it was not started. That was obvious thing for me
to check…

I assume that telnet is not finished it’s 3-way hand-shack, (this
is where I want to see a tcpdump to confirm) but look at small
stack code that only way it can fail is low memory. I don’t
think you are in that satuation.

What I suspect is that handshake indeed was not completed and telnetd was
not started because telnet process never got any reply from io-net even for
first phase of the handshake. The reason why io-net did not reply is
probably because attribute structure corresponding to port 23 is locked
forever. I’d suspect that one of attempts to signal the condvar gets lost
(someone forgot to lock a mutex) or may be some condvar_wait() gets
unblocked by a signal (someone forgot to wrap it into loop for signal
safety). That is if problem is with libc, which is easier case.

Of course it is also possible that somehow somewhere there’s a race
condition in kernel so the operation of unblocking from condvar and locking
the mutex back is not really as atomic as it should be. Then a wrong guy
gets mutex locked when someone unblocks from condvar and that would easily
give you situation like this…

Of course I’m just guessing, I’m even more in the dark than you are without
sources :wink:

  • Igor
8

beg my pardon, but I attended course, so came up back just today… I’ll
try, but I don’t have any clue how to make a “long run test” … any
ideas? you can call me +358(40)5245692 (Helsinki, TZ=MSK-1) or mail to
silpol@yahoo.com (please, don’t use “official” mail which is in header
of this mail)

Igor Kovalenko wrote:

Have you tried to give it a long run? Seems to me that if stack was
problem then all ports would be stuck not just one…

  • igor

“Andrej Timchenko” <> andrej.timchenko@nokia.com> > wrote in message
news:> 3B164CDE.A04B69AC@nokia.com> …
Hi,

It seems Ok on normal TCP/IP stack > :wink:
Here you have a transcript > :wink:

telnet 127.0.0.1

Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
login: root
Password:
05/31/01 16:48:47 on /dev/ttyp2
Last login: 05/31/01 16:48:14 on /dev/ttyp2
edit the file .profile if you want to change your environment.
To start the Photon windowing environment, type “ph”.

pidin | grep telnet

4419617 1 usr/sbin/telnetd 10r SIGWAITINFO
5038115 1 usr/bin/telnet 10r SIGWAITINFO
5042212 1 usr/sbin/telnetd 10r SIGWAITINFO

perhaps, the reason is tiny stack…

Igor Kovalenko wrote:

I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
while we have situation when we can’t use some port anymore. The same
server on different port continues to serve requests just fine but any
attempt to connect to port which have been in use for a while (week or
more) ends up with timeout. So far it happened with inetd and httpd.

Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
one, below commands from another console). At the same time ‘telnet
127.0.0.1 24’ works just fine. The first telnet eventually says
‘connection timedout’…

pidin | grep telnet

136798241 1 bin/telnetd 19r SIGWAITINFO
142790692 1 bin/telnet 10r REPLY 294924

pidin | grep 294924

294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
294924 2 o-net/x86/o/io-net 17r RECEIVE 1
294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
294924 4 o-net/x86/o/io-net 21r RECEIVE 3
294924 5 o-net/x86/o/io-net 21r RECEIVE 6
294924 6 o-net/x86/o/io-net 21r RECEIVE 9
294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
294924 10 o-net/x86/o/io-net 17r RECEIVE 1
294924 11 o-net/x86/o/io-net 17r RECEIVE 1
294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
294924 14 o-net/x86/o/io-net 17r RECEIVE 1

cat /proc/ipstats

Ttcpip Sep 24 2000 19:57:39

verbosity level 0
ip checksum errors: 0
udp checksum errors: 0
tcp checksum errors: 0

packets sent: 9570945
packets received: 10178301

en1 : addr 192.168.1.1 netmask 255.255.255.0 up
en0 : addr 203.8.22.36 netmask 255.255.255.0 up
lo0 : addr 127.0.0.1 netmask 255.0.0.0 up

DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254

TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
rcv
0
TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
rcv
0
TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
rcv
0
TCP 0.0.0.0.21 LISTEN
TCP 0.0.0.0.8080 LISTEN
TCP 0.0.0.0.80 LISTEN
TCP 203.8.22.36.9000 LISTEN
TCP 0.0.0.0.9999 LISTEN
TCP 0.0.0.0.5010 LISTEN
TCP 0.0.0.0.5009 LISTEN
TCP 0.0.0.0.5008 LISTEN
TCP 0.0.0.0.5007 LISTEN
TCP 0.0.0.0.5005 LISTEN
TCP 0.0.0.0.5004 LISTEN
TCP 0.0.0.0.5003 LISTEN
TCP 0.0.0.0.5002 LISTEN
TCP 0.0.0.0.5006 LISTEN
TCP 0.0.0.0.5001 LISTEN
TCP 0.0.0.0.24 LISTEN
TCP 0.0.0.0.19 LISTEN
TCP 0.0.0.0.13 LISTEN
TCP 0.0.0.0.9 LISTEN
TCP 0.0.0.0.7 LISTEN
TCP 0.0.0.0.561 LISTEN
TCP 0.0.0.0.560 LISTEN
TCP 0.0.0.0.559 LISTEN
TCP 0.0.0.0.558 LISTEN
TCP 0.0.0.0.557 LISTEN
TCP 0.0.0.0.23 LISTEN
TCP 0.0.0.0.37 LISTEN
UDP 0.0.0.0.514 > 0.0.0.0.0
UDP 0.0.0.0.7 > 0.0.0.0.0
UDP 0.0.0.0.9 > 0.0.0.0.0
UDP 0.0.0.0.13 > 0.0.0.0.0
UDP 192.168.1.1.10000 > 192.168.1.2.10000
UDP 0.0.0.0.19 > 0.0.0.0.0
UDP 0.0.0.0.37 > 0.0.0.0.0
UDP 192.168.1.1.8000 > 192.168.1.2.8000
UDP 192.168.1.1.8001 > 192.168.1.2.8001
UDP 192.168.1.1.8002 > 192.168.1.2.8002
UDP 192.168.1.1.8003 > 192.168.1.2.8003
UDP 192.168.1.1.8004 > 192.168.1.2.8004
UDP 192.168.1.1.8005 > 192.168.1.2.8005
UDP 192.168.1.1.8006 > 192.168.1.2.8006
UDP 192.168.1.1.8007 > 192.168.1.2.8007
UDP 192.168.1.1.8008 > 192.168.1.2.8008
UDP 192.168.1.1.8009 > 192.168.1.2.8009
UDP 192.168.1.1.8010 > 0.0.0.0.0
UDP 192.168.1.1.8011 > 0.0.0.0.0
UDP 192.168.1.1.8012 > 192.168.1.2.8012
UDP 192.168.1.1.8013 > 192.168.1.2.8013
UDP 192.168.1.1.8014 > 192.168.1.2.8014
UDP 192.168.1.1.8015 > 192.168.1.2.8015
UDP 203.8.22.36.6500 > 0.0.0.0.0
UDP 203.8.22.36.2161 > 203.8.22.17.32792
UDP 203.8.22.36.162 > 203.8.22.17.32791
UDP 0.0.0.0.930 > 145.1.197.1.2049

Any ideas? What other info do you guys need?

  • Igor

–
BR, Andrej

–
BR, Andrej

9

This sounds like a bug that was fixed in patch B.
There was a case where dup syns on a listen socket
could cause the listenwait counter to wrap around.
Subsequent syns would then be ignored.

-seanb


In article <3B14027B.B610D0@motorola.com> you wrote:
: I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
: while we have situation when we can’t use some port anymore. The same
: server on different port continues to serve requests just fine but any
: attempt to connect to port which have been in use for a while (week or
: more) ends up with timeout. So far it happened with inetd and httpd.

: Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
: one, below commands from another console). At the same time ‘telnet
: 127.0.0.1 24’ works just fine. The first telnet eventually says
: ‘connection timedout’…

: # pidin | grep telnet

: 136798241 1 bin/telnetd 19r SIGWAITINFO
: 142790692 1 bin/telnet 10r REPLY 294924

: # pidin | grep 294924

: 294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
: 294924 2 o-net/x86/o/io-net 17r RECEIVE 1
: 294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
: 294924 4 o-net/x86/o/io-net 21r RECEIVE 3
: 294924 5 o-net/x86/o/io-net 21r RECEIVE 6
: 294924 6 o-net/x86/o/io-net 21r RECEIVE 9
: 294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
: 294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
: 294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
: 294924 10 o-net/x86/o/io-net 17r RECEIVE 1
: 294924 11 o-net/x86/o/io-net 17r RECEIVE 1
: 294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
: 294924 14 o-net/x86/o/io-net 17r RECEIVE 1

: # cat /proc/ipstats

: Ttcpip Sep 24 2000 19:57:39

: verbosity level 0
: ip checksum errors: 0
: udp checksum errors: 0
: tcp checksum errors: 0

: packets sent: 9570945
: packets received: 10178301

: en1 : addr 192.168.1.1 netmask 255.255.255.0 up
: en0 : addr 203.8.22.36 netmask 255.255.255.0 up
: lo0 : addr 127.0.0.1 netmask 255.0.0.0 up

: DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
: DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
: DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
: DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254

: TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
: rcv
: 0
: TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
: rcv
: 0
: TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
: rcv
: 0
: TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
: rcv
: 0
: TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
: rcv
: 0
: TCP 0.0.0.0.21 LISTEN
: TCP 0.0.0.0.8080 LISTEN
: TCP 0.0.0.0.80 LISTEN
: TCP 203.8.22.36.9000 LISTEN
: TCP 0.0.0.0.9999 LISTEN
: TCP 0.0.0.0.5010 LISTEN
: TCP 0.0.0.0.5009 LISTEN
: TCP 0.0.0.0.5008 LISTEN
: TCP 0.0.0.0.5007 LISTEN
: TCP 0.0.0.0.5005 LISTEN
: TCP 0.0.0.0.5004 LISTEN
: TCP 0.0.0.0.5003 LISTEN
: TCP 0.0.0.0.5002 LISTEN
: TCP 0.0.0.0.5006 LISTEN
: TCP 0.0.0.0.5001 LISTEN
: TCP 0.0.0.0.24 LISTEN
: TCP 0.0.0.0.19 LISTEN
: TCP 0.0.0.0.13 LISTEN
: TCP 0.0.0.0.9 LISTEN
: TCP 0.0.0.0.7 LISTEN
: TCP 0.0.0.0.561 LISTEN
: TCP 0.0.0.0.560 LISTEN
: TCP 0.0.0.0.559 LISTEN
: TCP 0.0.0.0.558 LISTEN
: TCP 0.0.0.0.557 LISTEN
: TCP 0.0.0.0.23 LISTEN
: TCP 0.0.0.0.37 LISTEN
: UDP 0.0.0.0.514 > 0.0.0.0.0
: UDP 0.0.0.0.7 > 0.0.0.0.0
: UDP 0.0.0.0.9 > 0.0.0.0.0
: UDP 0.0.0.0.13 > 0.0.0.0.0
: UDP 192.168.1.1.10000 > 192.168.1.2.10000
: UDP 0.0.0.0.19 > 0.0.0.0.0
: UDP 0.0.0.0.37 > 0.0.0.0.0
: UDP 192.168.1.1.8000 > 192.168.1.2.8000
: UDP 192.168.1.1.8001 > 192.168.1.2.8001
: UDP 192.168.1.1.8002 > 192.168.1.2.8002
: UDP 192.168.1.1.8003 > 192.168.1.2.8003
: UDP 192.168.1.1.8004 > 192.168.1.2.8004
: UDP 192.168.1.1.8005 > 192.168.1.2.8005
: UDP 192.168.1.1.8006 > 192.168.1.2.8006
: UDP 192.168.1.1.8007 > 192.168.1.2.8007
: UDP 192.168.1.1.8008 > 192.168.1.2.8008
: UDP 192.168.1.1.8009 > 192.168.1.2.8009
: UDP 192.168.1.1.8010 > 0.0.0.0.0
: UDP 192.168.1.1.8011 > 0.0.0.0.0
: UDP 192.168.1.1.8012 > 192.168.1.2.8012
: UDP 192.168.1.1.8013 > 192.168.1.2.8013
: UDP 192.168.1.1.8014 > 192.168.1.2.8014
: UDP 192.168.1.1.8015 > 192.168.1.2.8015
: UDP 203.8.22.36.6500 > 0.0.0.0.0
: UDP 203.8.22.36.2161 > 203.8.22.17.32792
: UDP 203.8.22.36.162 > 203.8.22.17.32791
: UDP 0.0.0.0.930 > 145.1.197.1.2049

: Any ideas? What other info do you guys need?

: - Igor

10

Sean Boudreau a écrit :

This sounds like a bug that was fixed in patch B.
There was a case where dup syns on a listen socket
could cause the listenwait counter to wrap around.
Subsequent syns would then be ignored.

-seanb

In article <> 3B14027B.B610D0@motorola.com> > you wrote:
: I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
: while we have situation when we can’t use some port anymore. The same
: server on different port continues to serve requests just fine but any
: attempt to connect to port which have been in use for a while (week or
: more) ends up with timeout. So far it happened with inetd and httpd.

: Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
: one, below commands from another console). At the same time ‘telnet
: 127.0.0.1 24’ works just fine. The first telnet eventually says
: ‘connection timedout’…

: # pidin | grep telnet

: 136798241 1 bin/telnetd 19r SIGWAITINFO
: 142790692 1 bin/telnet 10r REPLY 294924

: # pidin | grep 294924

: 294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
: 294924 2 o-net/x86/o/io-net 17r RECEIVE 1
: 294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
: 294924 4 o-net/x86/o/io-net 21r RECEIVE 3
: 294924 5 o-net/x86/o/io-net 21r RECEIVE 6
: 294924 6 o-net/x86/o/io-net 21r RECEIVE 9
: 294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
: 294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
: 294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
: 294924 10 o-net/x86/o/io-net 17r RECEIVE 1
: 294924 11 o-net/x86/o/io-net 17r RECEIVE 1
: 294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
: 294924 14 o-net/x86/o/io-net 17r RECEIVE 1

: # cat /proc/ipstats

: Ttcpip Sep 24 2000 19:57:39

: verbosity level 0
: ip checksum errors: 0
: udp checksum errors: 0
: tcp checksum errors: 0

: packets sent: 9570945
: packets received: 10178301

: en1 : addr 192.168.1.1 netmask 255.255.255.0 up
: en0 : addr 203.8.22.36 netmask 255.255.255.0 up
: lo0 : addr 127.0.0.1 netmask 255.0.0.0 up

: DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
: DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
: DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
: DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254

: TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
: rcv
: 0
: TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
: rcv
: 0
: TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
: rcv
: 0
: TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
: rcv
: 0
: TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
: rcv
: 0
: TCP 0.0.0.0.21 LISTEN
: TCP 0.0.0.0.8080 LISTEN
: TCP 0.0.0.0.80 LISTEN
: TCP 203.8.22.36.9000 LISTEN
: TCP 0.0.0.0.9999 LISTEN
: TCP 0.0.0.0.5010 LISTEN
: TCP 0.0.0.0.5009 LISTEN
: TCP 0.0.0.0.5008 LISTEN
: TCP 0.0.0.0.5007 LISTEN
: TCP 0.0.0.0.5005 LISTEN
: TCP 0.0.0.0.5004 LISTEN
: TCP 0.0.0.0.5003 LISTEN
: TCP 0.0.0.0.5002 LISTEN
: TCP 0.0.0.0.5006 LISTEN
: TCP 0.0.0.0.5001 LISTEN
: TCP 0.0.0.0.24 LISTEN
: TCP 0.0.0.0.19 LISTEN
: TCP 0.0.0.0.13 LISTEN
: TCP 0.0.0.0.9 LISTEN
: TCP 0.0.0.0.7 LISTEN
: TCP 0.0.0.0.561 LISTEN
: TCP 0.0.0.0.560 LISTEN
: TCP 0.0.0.0.559 LISTEN
: TCP 0.0.0.0.558 LISTEN
: TCP 0.0.0.0.557 LISTEN
: TCP 0.0.0.0.23 LISTEN
: TCP 0.0.0.0.37 LISTEN
: UDP 0.0.0.0.514 > 0.0.0.0.0
: UDP 0.0.0.0.7 > 0.0.0.0.0
: UDP 0.0.0.0.9 > 0.0.0.0.0
: UDP 0.0.0.0.13 > 0.0.0.0.0
: UDP 192.168.1.1.10000 > 192.168.1.2.10000
: UDP 0.0.0.0.19 > 0.0.0.0.0
: UDP 0.0.0.0.37 > 0.0.0.0.0
: UDP 192.168.1.1.8000 > 192.168.1.2.8000
: UDP 192.168.1.1.8001 > 192.168.1.2.8001
: UDP 192.168.1.1.8002 > 192.168.1.2.8002
: UDP 192.168.1.1.8003 > 192.168.1.2.8003
: UDP 192.168.1.1.8004 > 192.168.1.2.8004
: UDP 192.168.1.1.8005 > 192.168.1.2.8005
: UDP 192.168.1.1.8006 > 192.168.1.2.8006
: UDP 192.168.1.1.8007 > 192.168.1.2.8007
: UDP 192.168.1.1.8008 > 192.168.1.2.8008
: UDP 192.168.1.1.8009 > 192.168.1.2.8009
: UDP 192.168.1.1.8010 > 0.0.0.0.0
: UDP 192.168.1.1.8011 > 0.0.0.0.0
: UDP 192.168.1.1.8012 > 192.168.1.2.8012
: UDP 192.168.1.1.8013 > 192.168.1.2.8013
: UDP 192.168.1.1.8014 > 192.168.1.2.8014
: UDP 192.168.1.1.8015 > 192.168.1.2.8015
: UDP 203.8.22.36.6500 > 0.0.0.0.0
: UDP 203.8.22.36.2161 > 203.8.22.17.32792
: UDP 203.8.22.36.162 > 203.8.22.17.32791
: UDP 0.0.0.0.930 > 145.1.197.1.2049

: Any ideas? What other info do you guys need?

: - Igor

Oups! Igor would run patch A! Strange!
Alain.

11

Where was the bug? Tiny stack or elsewhere?
We are running last version of OEM Neutrino 2.11, which is older than patch
B. Would be nice if that problem already fixed but the would reason you
described explain why telnet is stuck in REPLY-blocked state? Looks like it
is stuck in connect() call. Should not it fail right away as if port is not
being listened at all if SYNs are ignored?

Thanks,

  • Igor

“Sean Boudreau” <seanb@qnx.com> wrote in message
news:9finj2$fi3$1@nntp.qnx.com…

This sounds like a bug that was fixed in patch B.
There was a case where dup syns on a listen socket
could cause the listenwait counter to wrap around.
Subsequent syns would then be ignored.

-seanb


In article <> 3B14027B.B610D0@motorola.com> > you wrote:
: I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
: while we have situation when we can’t use some port anymore. The same
: server on different port continues to serve requests just fine but any
: attempt to connect to port which have been in use for a while (week or
: more) ends up with timeout. So far it happened with inetd and httpd.

: Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
: one, below commands from another console). At the same time ‘telnet
: 127.0.0.1 24’ works just fine. The first telnet eventually says
: ‘connection timedout’…

: # pidin | grep telnet

: 136798241 1 bin/telnetd 19r SIGWAITINFO
: 142790692 1 bin/telnet 10r REPLY 294924

: # pidin | grep 294924

: 294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
: 294924 2 o-net/x86/o/io-net 17r RECEIVE 1
: 294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
: 294924 4 o-net/x86/o/io-net 21r RECEIVE 3
: 294924 5 o-net/x86/o/io-net 21r RECEIVE 6
: 294924 6 o-net/x86/o/io-net 21r RECEIVE 9
: 294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
: 294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
: 294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
: 294924 10 o-net/x86/o/io-net 17r RECEIVE 1
: 294924 11 o-net/x86/o/io-net 17r RECEIVE 1
: 294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
: 294924 14 o-net/x86/o/io-net 17r RECEIVE 1

: # cat /proc/ipstats

: Ttcpip Sep 24 2000 19:57:39

: verbosity level 0
: ip checksum errors: 0
: udp checksum errors: 0
: tcp checksum errors: 0

: packets sent: 9570945
: packets received: 10178301

: en1 : addr 192.168.1.1 netmask 255.255.255.0 up
: en0 : addr 203.8.22.36 netmask 255.255.255.0 up
: lo0 : addr 127.0.0.1 netmask 255.0.0.0 up

: DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
: DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
: DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
: DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254

: TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
: rcv
: 0
: TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
: rcv
: 0
: TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
: rcv
: 0
: TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
: rcv
: 0
: TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
: rcv
: 0
: TCP 0.0.0.0.21 LISTEN
: TCP 0.0.0.0.8080 LISTEN
: TCP 0.0.0.0.80 LISTEN
: TCP 203.8.22.36.9000 LISTEN
: TCP 0.0.0.0.9999 LISTEN
: TCP 0.0.0.0.5010 LISTEN
: TCP 0.0.0.0.5009 LISTEN
: TCP 0.0.0.0.5008 LISTEN
: TCP 0.0.0.0.5007 LISTEN
: TCP 0.0.0.0.5005 LISTEN
: TCP 0.0.0.0.5004 LISTEN
: TCP 0.0.0.0.5003 LISTEN
: TCP 0.0.0.0.5002 LISTEN
: TCP 0.0.0.0.5006 LISTEN
: TCP 0.0.0.0.5001 LISTEN
: TCP 0.0.0.0.24 LISTEN
: TCP 0.0.0.0.19 LISTEN
: TCP 0.0.0.0.13 LISTEN
: TCP 0.0.0.0.9 LISTEN
: TCP 0.0.0.0.7 LISTEN
: TCP 0.0.0.0.561 LISTEN
: TCP 0.0.0.0.560 LISTEN
: TCP 0.0.0.0.559 LISTEN
: TCP 0.0.0.0.558 LISTEN
: TCP 0.0.0.0.557 LISTEN
: TCP 0.0.0.0.23 LISTEN
: TCP 0.0.0.0.37 LISTEN
: UDP 0.0.0.0.514 > 0.0.0.0.0
: UDP 0.0.0.0.7 > 0.0.0.0.0
: UDP 0.0.0.0.9 > 0.0.0.0.0
: UDP 0.0.0.0.13 > 0.0.0.0.0
: UDP 192.168.1.1.10000 > 192.168.1.2.10000
: UDP 0.0.0.0.19 > 0.0.0.0.0
: UDP 0.0.0.0.37 > 0.0.0.0.0
: UDP 192.168.1.1.8000 > 192.168.1.2.8000
: UDP 192.168.1.1.8001 > 192.168.1.2.8001
: UDP 192.168.1.1.8002 > 192.168.1.2.8002
: UDP 192.168.1.1.8003 > 192.168.1.2.8003
: UDP 192.168.1.1.8004 > 192.168.1.2.8004
: UDP 192.168.1.1.8005 > 192.168.1.2.8005
: UDP 192.168.1.1.8006 > 192.168.1.2.8006
: UDP 192.168.1.1.8007 > 192.168.1.2.8007
: UDP 192.168.1.1.8008 > 192.168.1.2.8008
: UDP 192.168.1.1.8009 > 192.168.1.2.8009
: UDP 192.168.1.1.8010 > 0.0.0.0.0
: UDP 192.168.1.1.8011 > 0.0.0.0.0
: UDP 192.168.1.1.8012 > 192.168.1.2.8012
: UDP 192.168.1.1.8013 > 192.168.1.2.8013
: UDP 192.168.1.1.8014 > 192.168.1.2.8014
: UDP 192.168.1.1.8015 > 192.168.1.2.8015
: UDP 203.8.22.36.6500 > 0.0.0.0.0
: UDP 203.8.22.36.2161 > 203.8.22.17.32792
: UDP 203.8.22.36.162 > 203.8.22.17.32791
: UDP 0.0.0.0.930 > 145.1.197.1.2049

: Any ideas? What other info do you guys need?

: - Igor

12

Igor Kovalenko <kovalenko@home.com> wrote:
: Where was the bug? Tiny stack or elsewhere?o

Tiny stack.

: We are running last version of OEM Neutrino 2.11, which is older than patch
: B. Would be nice if that problem already fixed but the would reason you
: described explain why telnet is stuck in REPLY-blocked state? Looks like it
: is stuck in connect() call. Should not it fail right away as if port is not
: being listened at all if SYNs are ignored?

No. The connect() will retry until the timeout. If the stack sent back
a RST segment, then yes it would fail right away. A RST shouldn’t be sent
in this case because this is usually a transient condition and the retries
are desired.

-seanb

: Thanks,
: - Igor

: “Sean Boudreau” <seanb@qnx.com> wrote in message
: news:9finj2$fi3$1@nntp.qnx.com…
:>
:> This sounds like a bug that was fixed in patch B.
:> There was a case where dup syns on a listen socket
:> could cause the listenwait counter to wrap around.
:> Subsequent syns would then be ignored.
:>
:> -seanb
:>
:>
:> In article <3B14027B.B610D0@motorola.com> you wrote:
:> : I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
:> : while we have situation when we can’t use some port anymore. The same
:> : server on different port continues to serve requests just fine but any
:> : attempt to connect to port which have been in use for a while (week or
:> : more) ends up with timeout. So far it happened with inetd and httpd.
:>
:> : Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
:> : one, below commands from another console). At the same time ‘telnet
:> : 127.0.0.1 24’ works just fine. The first telnet eventually says
:> : ‘connection timedout’…
:>
:> : # pidin | grep telnet
:>
:> : 136798241 1 bin/telnetd 19r SIGWAITINFO
:> : 142790692 1 bin/telnet 10r REPLY 294924
:>
:> : # pidin | grep 294924
:>
:> : 294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
:> : 294924 2 o-net/x86/o/io-net 17r RECEIVE 1
:> : 294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
:> : 294924 4 o-net/x86/o/io-net 21r RECEIVE 3
:> : 294924 5 o-net/x86/o/io-net 21r RECEIVE 6
:> : 294924 6 o-net/x86/o/io-net 21r RECEIVE 9
:> : 294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
:> : 294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
:> : 294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
:> : 294924 10 o-net/x86/o/io-net 17r RECEIVE 1
:> : 294924 11 o-net/x86/o/io-net 17r RECEIVE 1
:> : 294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
:> : 294924 14 o-net/x86/o/io-net 17r RECEIVE 1
:>
:> : # cat /proc/ipstats
:>
:> : Ttcpip Sep 24 2000 19:57:39
:>
:> : verbosity level 0
:> : ip checksum errors: 0
:> : udp checksum errors: 0
:> : tcp checksum errors: 0
:>
:> : packets sent: 9570945
:> : packets received: 10178301
:>
:> : en1 : addr 192.168.1.1 netmask 255.255.255.0 up
:> : en0 : addr 203.8.22.36 netmask 255.255.255.0 up
:> : lo0 : addr 127.0.0.1 netmask 255.0.0.0 up
:>
:> : DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
:> : DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
:> : DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
:> : DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254
:>
:> : TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd 0
:> : rcv
:> : 0
:> : TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd 0
:> : rcv
:> : 0
:> : TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd 0
:> : rcv
:> : 0
:> : TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd 0
:> : rcv
:> : 0
:> : TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd 0
:> : rcv
:> : 0
:> : TCP 0.0.0.0.21 LISTEN
:> : TCP 0.0.0.0.8080 LISTEN
:> : TCP 0.0.0.0.80 LISTEN
:> : TCP 203.8.22.36.9000 LISTEN
:> : TCP 0.0.0.0.9999 LISTEN
:> : TCP 0.0.0.0.5010 LISTEN
:> : TCP 0.0.0.0.5009 LISTEN
:> : TCP 0.0.0.0.5008 LISTEN
:> : TCP 0.0.0.0.5007 LISTEN
:> : TCP 0.0.0.0.5005 LISTEN
:> : TCP 0.0.0.0.5004 LISTEN
:> : TCP 0.0.0.0.5003 LISTEN
:> : TCP 0.0.0.0.5002 LISTEN
:> : TCP 0.0.0.0.5006 LISTEN
:> : TCP 0.0.0.0.5001 LISTEN
:> : TCP 0.0.0.0.24 LISTEN
:> : TCP 0.0.0.0.19 LISTEN
:> : TCP 0.0.0.0.13 LISTEN
:> : TCP 0.0.0.0.9 LISTEN
:> : TCP 0.0.0.0.7 LISTEN
:> : TCP 0.0.0.0.561 LISTEN
:> : TCP 0.0.0.0.560 LISTEN
:> : TCP 0.0.0.0.559 LISTEN
:> : TCP 0.0.0.0.558 LISTEN
:> : TCP 0.0.0.0.557 LISTEN
:> : TCP 0.0.0.0.23 LISTEN
:> : TCP 0.0.0.0.37 LISTEN
:> : UDP 0.0.0.0.514 > 0.0.0.0.0
:> : UDP 0.0.0.0.7 > 0.0.0.0.0
:> : UDP 0.0.0.0.9 > 0.0.0.0.0
:> : UDP 0.0.0.0.13 > 0.0.0.0.0
:> : UDP 192.168.1.1.10000 > 192.168.1.2.10000
:> : UDP 0.0.0.0.19 > 0.0.0.0.0
:> : UDP 0.0.0.0.37 > 0.0.0.0.0
:> : UDP 192.168.1.1.8000 > 192.168.1.2.8000
:> : UDP 192.168.1.1.8001 > 192.168.1.2.8001
:> : UDP 192.168.1.1.8002 > 192.168.1.2.8002
:> : UDP 192.168.1.1.8003 > 192.168.1.2.8003
:> : UDP 192.168.1.1.8004 > 192.168.1.2.8004
:> : UDP 192.168.1.1.8005 > 192.168.1.2.8005
:> : UDP 192.168.1.1.8006 > 192.168.1.2.8006
:> : UDP 192.168.1.1.8007 > 192.168.1.2.8007
:> : UDP 192.168.1.1.8008 > 192.168.1.2.8008
:> : UDP 192.168.1.1.8009 > 192.168.1.2.8009
:> : UDP 192.168.1.1.8010 > 0.0.0.0.0
:> : UDP 192.168.1.1.8011 > 0.0.0.0.0
:> : UDP 192.168.1.1.8012 > 192.168.1.2.8012
:> : UDP 192.168.1.1.8013 > 192.168.1.2.8013
:> : UDP 192.168.1.1.8014 > 192.168.1.2.8014
:> : UDP 192.168.1.1.8015 > 192.168.1.2.8015
:> : UDP 203.8.22.36.6500 > 0.0.0.0.0
:> : UDP 203.8.22.36.2161 > 203.8.22.17.32792
:> : UDP 203.8.22.36.162 > 203.8.22.17.32791
:> : UDP 0.0.0.0.930 > 145.1.197.1.2049
:>
:> : Any ideas? What other info do you guys need?
:>
:> : - Igor

13

As far as I can see from code, connect() is linear function and does not
retry anything except for “autoconnect” mode (which does not apply).
Basically connect() is _devctl() which I presume is MsgSend(). Apparently
that MsgSend() does not return before timeout.

That should mean the stack keeps retrying on behalf of clients hoping to
REPLY when ready? Just curious, how do you do that? Loop inside devctl
handler or put client into blocked list and schedule periodic retry by
another thread?

thanks,

  • igor

“Sean Boudreau” <seanb@qnx.com> wrote in message
news:9fj5h0$ovj$1@nntp.qnx.com…

Igor Kovalenko <> kovalenko@home.com> > wrote:
: Where was the bug? Tiny stack or elsewhere?o

Tiny stack.

: We are running last version of OEM Neutrino 2.11, which is older than
patch
: B. Would be nice if that problem already fixed but the would reason you
: described explain why telnet is stuck in REPLY-blocked state? Looks like
it
: is stuck in connect() call. Should not it fail right away as if port is
not
: being listened at all if SYNs are ignored?

No. The connect() will retry until the timeout. If the stack sent back
a RST segment, then yes it would fail right away. A RST shouldn’t be sent
in this case because this is usually a transient condition and the retries
are desired.

-seanb

: Thanks,
: - Igor

: “Sean Boudreau” <> seanb@qnx.com> > wrote in message
: news:9finj2$fi3$> 1@nntp.qnx.com> …
:
:> This sounds like a bug that was fixed in patch B.
:> There was a case where dup syns on a listen socket
:> could cause the listenwait counter to wrap around.
:> Subsequent syns would then be ignored.
:
:> -seanb
:
:
:> In article <> 3B14027B.B610D0@motorola.com> > you wrote:
:> : I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
:> : while we have situation when we can’t use some port anymore. The same
:> : server on different port continues to serve requests just fine but
any
:> : attempt to connect to port which have been in use for a while (week
or
:> : more) ends up with timeout. So far it happened with inetd and httpd.
:
:> : Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
:> : one, below commands from another console). At the same time ‘telnet
:> : 127.0.0.1 24’ works just fine. The first telnet eventually says
:> : ‘connection timedout’…
:
:> : # pidin | grep telnet
:
:> : 136798241 1 bin/telnetd 19r SIGWAITINFO
:> : 142790692 1 bin/telnet 10r REPLY 294924
:
:> : # pidin | grep 294924
:
:> : 294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
:> : 294924 2 o-net/x86/o/io-net 17r RECEIVE 1
:> : 294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
:> : 294924 4 o-net/x86/o/io-net 21r RECEIVE 3
:> : 294924 5 o-net/x86/o/io-net 21r RECEIVE 6
:> : 294924 6 o-net/x86/o/io-net 21r RECEIVE 9
:> : 294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
:> : 294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
:> : 294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
:> : 294924 10 o-net/x86/o/io-net 17r RECEIVE 1
:> : 294924 11 o-net/x86/o/io-net 17r RECEIVE 1
:> : 294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
:> : 294924 14 o-net/x86/o/io-net 17r RECEIVE 1
:
:> : # cat /proc/ipstats
:
:> : Ttcpip Sep 24 2000 19:57:39
:
:> : verbosity level 0
:> : ip checksum errors: 0
:> : udp checksum errors: 0
:> : tcp checksum errors: 0
:
:> : packets sent: 9570945
:> : packets received: 10178301
:
:> : en1 : addr 192.168.1.1 netmask 255.255.255.0 up
:> : en0 : addr 203.8.22.36 netmask 255.255.255.0 up
:> : lo0 : addr 127.0.0.1 netmask 255.0.0.0 up
:
:> : DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
:> : DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
:> : DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
:> : DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254
:
:> : TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd
0
:> : rcv
:> : 0
:> : TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd
0
:> : rcv
:> : 0
:> : TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd
0
:> : rcv
:> : 0
:> : TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd
0
:> : rcv
:> : 0
:> : TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd
0
:> : rcv
:> : 0
:> : TCP 0.0.0.0.21 LISTEN
:> : TCP 0.0.0.0.8080 LISTEN
:> : TCP 0.0.0.0.80 LISTEN
:> : TCP 203.8.22.36.9000 LISTEN
:> : TCP 0.0.0.0.9999 LISTEN
:> : TCP 0.0.0.0.5010 LISTEN
:> : TCP 0.0.0.0.5009 LISTEN
:> : TCP 0.0.0.0.5008 LISTEN
:> : TCP 0.0.0.0.5007 LISTEN
:> : TCP 0.0.0.0.5005 LISTEN
:> : TCP 0.0.0.0.5004 LISTEN
:> : TCP 0.0.0.0.5003 LISTEN
:> : TCP 0.0.0.0.5002 LISTEN
:> : TCP 0.0.0.0.5006 LISTEN
:> : TCP 0.0.0.0.5001 LISTEN
:> : TCP 0.0.0.0.24 LISTEN
:> : TCP 0.0.0.0.19 LISTEN
:> : TCP 0.0.0.0.13 LISTEN
:> : TCP 0.0.0.0.9 LISTEN
:> : TCP 0.0.0.0.7 LISTEN
:> : TCP 0.0.0.0.561 LISTEN
:> : TCP 0.0.0.0.560 LISTEN
:> : TCP 0.0.0.0.559 LISTEN
:> : TCP 0.0.0.0.558 LISTEN
:> : TCP 0.0.0.0.557 LISTEN
:> : TCP 0.0.0.0.23 LISTEN
:> : TCP 0.0.0.0.37 LISTEN
:> : UDP 0.0.0.0.514 > 0.0.0.0.0
:> : UDP 0.0.0.0.7 > 0.0.0.0.0
:> : UDP 0.0.0.0.9 > 0.0.0.0.0
:> : UDP 0.0.0.0.13 > 0.0.0.0.0
:> : UDP 192.168.1.1.10000 > 192.168.1.2.10000
:> : UDP 0.0.0.0.19 > 0.0.0.0.0
:> : UDP 0.0.0.0.37 > 0.0.0.0.0
:> : UDP 192.168.1.1.8000 > 192.168.1.2.8000
:> : UDP 192.168.1.1.8001 > 192.168.1.2.8001
:> : UDP 192.168.1.1.8002 > 192.168.1.2.8002
:> : UDP 192.168.1.1.8003 > 192.168.1.2.8003
:> : UDP 192.168.1.1.8004 > 192.168.1.2.8004
:> : UDP 192.168.1.1.8005 > 192.168.1.2.8005
:> : UDP 192.168.1.1.8006 > 192.168.1.2.8006
:> : UDP 192.168.1.1.8007 > 192.168.1.2.8007
:> : UDP 192.168.1.1.8008 > 192.168.1.2.8008
:> : UDP 192.168.1.1.8009 > 192.168.1.2.8009
:> : UDP 192.168.1.1.8010 > 0.0.0.0.0
:> : UDP 192.168.1.1.8011 > 0.0.0.0.0
:> : UDP 192.168.1.1.8012 > 192.168.1.2.8012
:> : UDP 192.168.1.1.8013 > 192.168.1.2.8013
:> : UDP 192.168.1.1.8014 > 192.168.1.2.8014
:> : UDP 192.168.1.1.8015 > 192.168.1.2.8015
:> : UDP 203.8.22.36.6500 > 0.0.0.0.0
:> : UDP 203.8.22.36.2161 > 203.8.22.17.32792
:> : UDP 203.8.22.36.162 > 203.8.22.17.32791
:> : UDP 0.0.0.0.930 > 145.1.197.1.2049
:
:> : Any ideas? What other info do you guys need?
:
:> : - Igor

14

well… I tried… 3 telnet sessions:

  1. “run-forever” cycled script with echoeing and fetching env.variables
    (30 min) - no problem
  2. manual - typing keyboard just for you :wink: (10-15 min) - no problem
  3. a custom testing tool to open telnet and play in (no way to give it
    away, even don’t ask)… (45 min) - no problem

RTP, patch - at least B :wink: NORMAL IP stack.

–
BR, Andrej

15

Igor Kovalenko <kovalenko@home.com> wrote:
: As far as I can see from code, connect() is linear function and does not
: retry anything except for “autoconnect” mode (which does not apply).
: Basically connect() is _devctl() which I presume is MsgSend(). Apparently
: that MsgSend() does not return before timeout.

: That should mean the stack keeps retrying on behalf of clients hoping to
: REPLY when ready? Just curious, how do you do that? Loop inside devctl
: handler or put client into blocked list and schedule periodic retry by
: another thread?

The later. It’s all event driven. The reception of the SYN/ACK for the
connect()'s SYN causes the reply to be sent (the connect() returns). Usually
this happens with no retries. If retries do happen, they’re off a timer thread.

-seanb


: thanks,
: - igor

: “Sean Boudreau” <seanb@qnx.com> wrote in message
: news:9fj5h0$ovj$1@nntp.qnx.com…
:> Igor Kovalenko <kovalenko@home.com> wrote:
:> : Where was the bug? Tiny stack or elsewhere?o
:>
:> Tiny stack.
:>
:> : We are running last version of OEM Neutrino 2.11, which is older than
: patch
:> : B. Would be nice if that problem already fixed but the would reason you
:> : described explain why telnet is stuck in REPLY-blocked state? Looks like
: it
:> : is stuck in connect() call. Should not it fail right away as if port is
: not
:> : being listened at all if SYNs are ignored?
:>
:> No. The connect() will retry until the timeout. If the stack sent back
:> a RST segment, then yes it would fail right away. A RST shouldn’t be sent
:> in this case because this is usually a transient condition and the retries
:> are desired.
:>
:> -seanb
:>
:> : Thanks,
:> : - Igor
:>
:> : “Sean Boudreau” <seanb@qnx.com> wrote in message
:> : news:9finj2$fi3$1@nntp.qnx.com…
:> :>
:> :> This sounds like a bug that was fixed in patch B.
:> :> There was a case where dup syns on a listen socket
:> :> could cause the listenwait counter to wrap around.
:> :> Subsequent syns would then be ignored.
:> :>
:> :> -seanb
:> :>
:> :>
:> :> In article <3B14027B.B610D0@motorola.com> you wrote:
:> :> : I’m not sure if it is io-net or TCP stack (tiny) bug. Every once in a
:> :> : while we have situation when we can’t use some port anymore. The same
:> :> : server on different port continues to serve requests just fine but
: any
:> :> : attempt to connect to port which have been in use for a while (week
: or
:> :> : more) ends up with timeout. So far it happened with inetd and httpd.
:> :>
:> :> : Here is example with telnet (attempt ‘telnet 127.0.0.1’ from console
:> :> : one, below commands from another console). At the same time ‘telnet
:> :> : 127.0.0.1 24’ works just fine. The first telnet eventually says
:> :> : ‘connection timedout’…
:> :>
:> :> : # pidin | grep telnet
:> :>
:> :> : 136798241 1 bin/telnetd 19r SIGWAITINFO
:> :> : 142790692 1 bin/telnet 10r REPLY 294924
:> :>
:> :> : # pidin | grep 294924
:> :>
:> :> : 294924 1 o-net/x86/o/io-net 10r SIGWAITINFO
:> :> : 294924 2 o-net/x86/o/io-net 17r RECEIVE 1
:> :> : 294924 3 o-net/x86/o/io-net 18r CONDVAR b036bb50
:> :> : 294924 4 o-net/x86/o/io-net 21r RECEIVE 3
:> :> : 294924 5 o-net/x86/o/io-net 21r RECEIVE 6
:> :> : 294924 6 o-net/x86/o/io-net 21r RECEIVE 9
:> :> : 294924 7 o-net/x86/o/io-net 17f CONDVAR 8053d20
:> :> : 294924 8 o-net/x86/o/io-net 18f CONDVAR 8082010
:> :> : 294924 9 o-net/x86/o/io-net 19f CONDVAR 8052ac8
:> :> : 294924 10 o-net/x86/o/io-net 17r RECEIVE 1
:> :> : 294924 11 o-net/x86/o/io-net 17r RECEIVE 1
:> :> : 294924 12 o-net/x86/o/io-net 18f CONDVAR 808208c
:> :> : 294924 14 o-net/x86/o/io-net 17r RECEIVE 1
:> :>
:> :> : # cat /proc/ipstats
:> :>
:> :> : Ttcpip Sep 24 2000 19:57:39
:> :>
:> :> : verbosity level 0
:> :> : ip checksum errors: 0
:> :> : udp checksum errors: 0
:> :> : tcp checksum errors: 0
:> :>
:> :> : packets sent: 9570945
:> :> : packets received: 10178301
:> :>
:> :> : en1 : addr 192.168.1.1 netmask 255.255.255.0 up
:> :> : en0 : addr 203.8.22.36 netmask 255.255.255.0 up
:> :> : lo0 : addr 127.0.0.1 netmask 255.0.0.0 up
:> :>
:> :> : DST: 192.168.1.0 NETMASK: 255.255.255.0 GATEWAY: en1
:> :> : DST: 203.8.22.0 NETMASK: 255.255.255.0 GATEWAY: en0
:> :> : DST: 127.0.0.0 NETMASK: 255.0.0.0 GATEWAY: lo0
:> :> : DST: 0.0.0.0 NETMASK: 0.0.0.0 GATEWAY: 203.8.22.254
:> :>
:> :> : TCP 127.0.0.1.24 > 127.0.0.1.3701 ESTABLISHED snd
: 0
:> :> : rcv
:> :> : 0
:> :> : TCP 203.8.22.36.24 > 173.6.68.16.32904 ESTABLISHED snd
: 0
:> :> : rcv
:> :> : 0
:> :> : TCP 203.8.22.36.3111 > 203.8.22.43.2959 ESTABLISHED snd
: 0
:> :> : rcv
:> :> : 0
:> :> : TCP 127.0.0.1.3701 > 127.0.0.1.24 ESTABLISHED snd
: 0
:> :> : rcv
:> :> : 0
:> :> : TCP 203.8.22.36.9000 > 203.8.22.43.2920 ESTABLISHED snd
: 0
:> :> : rcv
:> :> : 0
:> :> : TCP 0.0.0.0.21 LISTEN
:> :> : TCP 0.0.0.0.8080 LISTEN
:> :> : TCP 0.0.0.0.80 LISTEN
:> :> : TCP 203.8.22.36.9000 LISTEN
:> :> : TCP 0.0.0.0.9999 LISTEN
:> :> : TCP 0.0.0.0.5010 LISTEN
:> :> : TCP 0.0.0.0.5009 LISTEN
:> :> : TCP 0.0.0.0.5008 LISTEN
:> :> : TCP 0.0.0.0.5007 LISTEN
:> :> : TCP 0.0.0.0.5005 LISTEN
:> :> : TCP 0.0.0.0.5004 LISTEN
:> :> : TCP 0.0.0.0.5003 LISTEN
:> :> : TCP 0.0.0.0.5002 LISTEN
:> :> : TCP 0.0.0.0.5006 LISTEN
:> :> : TCP 0.0.0.0.5001 LISTEN
:> :> : TCP 0.0.0.0.24 LISTEN
:> :> : TCP 0.0.0.0.19 LISTEN
:> :> : TCP 0.0.0.0.13 LISTEN
:> :> : TCP 0.0.0.0.9 LISTEN
:> :> : TCP 0.0.0.0.7 LISTEN
:> :> : TCP 0.0.0.0.561 LISTEN
:> :> : TCP 0.0.0.0.560 LISTEN
:> :> : TCP 0.0.0.0.559 LISTEN
:> :> : TCP 0.0.0.0.558 LISTEN
:> :> : TCP 0.0.0.0.557 LISTEN
:> :> : TCP 0.0.0.0.23 LISTEN
:> :> : TCP 0.0.0.0.37 LISTEN
:> :> : UDP 0.0.0.0.514 > 0.0.0.0.0
:> :> : UDP 0.0.0.0.7 > 0.0.0.0.0
:> :> : UDP 0.0.0.0.9 > 0.0.0.0.0
:> :> : UDP 0.0.0.0.13 > 0.0.0.0.0
:> :> : UDP 192.168.1.1.10000 > 192.168.1.2.10000
:> :> : UDP 0.0.0.0.19 > 0.0.0.0.0
:> :> : UDP 0.0.0.0.37 > 0.0.0.0.0
:> :> : UDP 192.168.1.1.8000 > 192.168.1.2.8000
:> :> : UDP 192.168.1.1.8001 > 192.168.1.2.8001
:> :> : UDP 192.168.1.1.8002 > 192.168.1.2.8002
:> :> : UDP 192.168.1.1.8003 > 192.168.1.2.8003
:> :> : UDP 192.168.1.1.8004 > 192.168.1.2.8004
:> :> : UDP 192.168.1.1.8005 > 192.168.1.2.8005
:> :> : UDP 192.168.1.1.8006 > 192.168.1.2.8006
:> :> : UDP 192.168.1.1.8007 > 192.168.1.2.8007
:> :> : UDP 192.168.1.1.8008 > 192.168.1.2.8008
:> :> : UDP 192.168.1.1.8009 > 192.168.1.2.8009
:> :> : UDP 192.168.1.1.8010 > 0.0.0.0.0
:> :> : UDP 192.168.1.1.8011 > 0.0.0.0.0
:> :> : UDP 192.168.1.1.8012 > 192.168.1.2.8012
:> :> : UDP 192.168.1.1.8013 > 192.168.1.2.8013
:> :> : UDP 192.168.1.1.8014 > 192.168.1.2.8014
:> :> : UDP 192.168.1.1.8015 > 192.168.1.2.8015
:> :> : UDP 203.8.22.36.6500 > 0.0.0.0.0
:> :> : UDP 203.8.22.36.2161 > 203.8.22.17.32792
:> :> : UDP 203.8.22.36.162 > 203.8.22.17.32791
:> :> : UDP 0.0.0.0.930 > 145.1.197.1.2049
:> :>
:> :> : Any ideas? What other info do you guys need?
:> :>
:> :> : - Igor
:>