tcpdump, nmap hangs on VLAN interface

razoumovsky_denis · March 3, 2015, 9:17am

Hi all!

Does anybody face the problem: ‘dead’ hangs of network programs while working via VLAN interface?
I modernize two systems to work via VLAN (opensuse 11.4 & 13.1) instead of ordinary ethernet interfaces.
So there are phisycal Iface (eth0 for example @11.4) unassined any IP:

eth0      Link encap:Ethernet  HWaddr 00:25:90:2B:63:CE
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:276607620 errors:0 dropped:7 overruns:0 frame:0
          TX packets:124310991 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:308506792247 (294215.0 Mb)  TX bytes:168232009243 (160438.5 Mb)
          Memory:fafe0000-fb000000

and VLAN iface over it:

eth0.30   Link encap:Ethernet  HWaddr 00:25:90:2B:63:CE
          inet addr:172.xx.xx.xx  Bcast:172.xx.xx.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:87138550 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57989973 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:297055438537 (283294.1 Mb)  TX bytes:164650586334 (157023.0 Mb)

There is no problem with data interchange via the VLAN iface.
But while I start

tcpdump -nti eth0.30

or

nmap -O 172.xx.xx.yy

I get completely hanged terminal session (I use PuTTY terminal).
Moreover, the process started does not receives any SIGNAL - nor -HUP, -TERM, -9 and still stays in memory until reboot

  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
30549 ?        D      0:00     10   747 40176 13460  0.0 nmap -O 172.xx.xx.yy

While there were no VLAN ifaces at all, both sniffer and portscanner worked fine
The situation is repeated both on opensuse 11.4 server and on opensuse 13.1 server.

versions of packets:
@opensuse11.4
nmap Version: 5.21-6.1 Arch: x86_64
tcpdump Version: 4.1.1-4.1 Arch: x86_64

@opensuse 13.1
nmap Version: 6.40-2.1.3 Arch: x86_64
tcpdump Version: 4.4.0-2.4.1 Arch: x86_64

How to tackle it?

Thanks in advance for any idea

tsu2 · March 8, 2015, 1:41am

Don’t know for sure about your situation, but a couple observations…

You should strongly consider upgrading 11.4 which is so far out of support that the machine is likely vulnerable. Although I believe the tcpdump and nmap commands are so basic chances they aren’t problems, newer versions should perform better.
Do you have any way of accessing these machines directly instead of over a network connection? Although not a certain issue, in general I try to avoid doing anything that might cause a circular process (never ending). You can at least surround your problem by eliminating this as a cause. If it is an issue, then there are various solutions.

TSU

razoumovsky_denis · March 10, 2015, 4:21pm

Hello, tsu2

Thanks for the interest to the problem.

thanks, 11.4 machine does its job, it’s enough.
yes, I can access the machines via console. If I have got your message correctly, you mean the ‘tcpdump’ started from the network terminal depends on the terminal connetcion itself? No, it is not the issue - the programs started from the real console don’t answer.

tsu2 · March 11, 2015, 3:53pm

I meant that you need to be careful accessing any machine <and> running an app that may be capturing the same network connection. So, the console connection should be either direct physical access, a serial connection or a different network connection.

TSU