tcpdump on tru64 hangs

[dkt]

Hi

I'ved tried ossc's tcpdump and my self compiled tcpdump 3.8.3 or the current cvs one.

After I typed tcdpump and hangs, it disconnect my current network connection (putty).

What's wrong?

[Venkatesh BL]

If you have 'truss' or 'trace', try to trace the tcpdump process.

[Han Pilmeyer]

What hangs (tcpdump, the system, the connection, the terminal)?

If it's tcpdump, can you ^C it?
If it's tcpdump and you can't ^C it, can you connect to it using this:

dbx -k /vmunix /dev/mem
dbx) set $pid=
dbx) t

Do the "t" a couple of times and see if it changes at all.

[dkt]

I have done this:
enable packetfilter in kernel
pfconfig +c +p -b 255 tu0
tcpdump -n -v -i tu0 icmp

There are icmp traces. But the tcpdump program start slowly.
Sometimes when tcpdmp start, it kills the current ssh (putty) connection which runs the tcpdump. Other ssh connection are not affected.
Sometimes after pressing ^C it kills the current ssh connection.

strace is not supported on Tru64.
alpha-trace from DEC doesn't compile on Tru64 5.1B.
The only trace program avaliable is ladebug.

----------
More info:
----------
I have used 'lan_config -i tu0 -a 1 -s 100 -x 0' to turn on auto-negotiation.
I see this is /var/adm/messages:
Jul 5 19:40:12 tru64 vmunix: tu0: link up: negotiated 100BaseTX: half duplex

Then I turn of the auto-negotiation 'lan_config -i tu0 -a 0 -s 100 -x 0'
This is from /var/adm/messages:
Jul 5 19:55:02 tru64 vmunix: tu0: auto negotiation disabled: selecting 100BaseTX: half duplex

[Han Pilmeyer · Accepted solution]

I'm not sure how easy it is to build tcpdump yourself. Have you tried to see if it's on the freeware CD?

Autonegotiation is notoriously unreliable on tulip network cards. You may want to fix the speed of those interface from the console.

truss can be found in the Extended System V Features subsets (ESVFBIN) on one of the APCD's.

[dkt]

I have a gcc compiler (complied from compaq's cc)
Then I get libpcap and tcpdump source code.
Then I can get tcpdump complied.

I have also tried to extract the libraries and the tcpdump binary from the ossc. But it doesn't help much.

I have the APCD, I will try truss ASAP.

[Michael Schulte zur Sur]

Hi,

if the host is on a switch port make set it the same speed fix too. I use 100full.

greetings,

Michael

[dkt]

The host is on the switch.

I have serious network problem with 100M Full duplex with 21143. Half duplex is much faster for me.

[dkt]

Turn on auto-negotiation solve the disconnection problem.
'lan_config -i tu0 -a 1 -s 100 -x 0'

truss on tcpdump show nothing special.

To my knowledge:
I get network disconnection after ^C tcpdump because: The network interface card is doing someting about autonegoation/link speed/duplex configuration/initalization. This make 1 or 2 seconds network interruption. So the putty session disconnect.

[Michael Schulte zur Sur]

Hi,

can you post ifconfig -Itu0 -s?

thanks,

Michael

[Han Pilmeyer]

Michael: You probably meant "netstat -Itu0 -s", right?

Usually things become more stable with tulip's when you turn OFF autonegotiation, but whatever works is fine with me.

Your ^C of tcpdump explanation might make sense, except that I would expect other SSH connections over the same interface to have the same problem. Which, as you mentioned, is not the case...

[Michael Schulte zur Sur]

Han,

you are right, I was meant to say netstat. I just mix those two.
A pause in the transmission, does this not point to a autsensing port on the switch or if I remember correctly something with spanning tree on the switch side?
I now remember having the same problem in just one instance.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=649686
All other run perfectly with 100full.

Michael

[dkt]

I have run tcpdump and then run netstat:

[root@tru64 /]# netstat -Itu0 -s

tu0 Ethernet counters at Thu Jul 7 15:51:05 2005

72 seconds since last zeroed
64131 bytes received
109165 bytes sent
683 data blocks received
505 data blocks sent
192 multicast bytes received
3 multicast blocks received
1270 multicast bytes sent
10 multicast blocks sent
0 blocks sent, initially deferred
0 blocks sent, single collision
0 blocks sent, multiple collisions
3 send failures, reasons include:
3 carrier sense lost
0 receive failures

[Michael Schulte zur Sur]

Hi,

3 carrier sense lost in 72 seconds?
I suggest, you check your cable.

greetings,

Michael

[dkt]

I think it's the problem of 21143 chipset.

I have no problem with that switch/cables with Intel NIC.

[Han Pilmeyer]

Normally for the tulip's we recommend to fix the speed both at the side of the switch and on the AlphaServer console. Make sure they match. Don't use auto-negotiation.