Results 1 to 4 of 4

Thread: tcpdump, nmap hangs on VLAN interface

  1. #1

    Default tcpdump, nmap hangs on VLAN interface

    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:
    Code:
    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:
    Code:
    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
    Code:
    tcpdump -nti eth0.30
    or
    Code:
    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
    Code:
      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

  2. #2
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    10,952
    Blog Entries
    2

    Default Re: tcpdump, nmap hangs on VLAN interface

    Don't know for sure about your situation, but a couple observations...
    1. 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.
    2. 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

  3. #3

    Default Re: tcpdump, nmap hangs on VLAN interface

    Hello, tsu2

    Thanks for the interest to the problem.
    1. thanks, 11.4 machine does its job, it's enough.
    2. 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.

  4. #4
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    10,952
    Blog Entries
    2

    Default Re: tcpdump, nmap hangs on VLAN interface

    Quote Originally Posted by razoumovsky_denis View Post
    Hello, tsu2

    Thanks for the interest to the problem.
    1. thanks, 11.4 machine does its job, it's enough.
    2. 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.
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •