LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   promiscuous mode not working (hub) - can only see broadcast traffic (https://www.linuxquestions.org/questions/linux-networking-3/promiscuous-mode-not-working-hub-can-only-see-broadcast-traffic-322726/)

lardus 05-12-2005 08:57 AM

promiscuous mode not working (hub) - can only see broadcast traffic
 
I'm running fedora core 3 and have set up a second network card to run in promiscuous mode, so that I can run some intrusion detection software. Before I run any fancy software, I'm trying to see traffic using tcpdump, but I have a problem: I can only see broadcast traffic, and not any addressed traffic. The addressed (non-broadcast) traffic is definitely getting to the IDS NIC as it is connected to a simple hub!

My understanding is that the best way to have an IDS NIC is to remove its IP address and run it in promiscuous mode, which is how I have it set up.
This is the output of ifconfig:

[root@islay ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:BF:B1:69:56
inet addr:192.168.1.109 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::250:bfff:feb1:6956/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:569896 errors:0 dropped:0 overruns:0 frame:0
TX packets:334424 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:768748970 (733.1 MiB) TX bytes:34785772 (33.1 MiB)
Interrupt:10 Base address:0x4000

eth1 Link encap:Ethernet HWaddr 00:0E:A6:2C:87:D4
inet6 addr: fe80::20e:a6ff:fe2c:87d4/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:773 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:46380 (45.2 KiB) TX bytes:686 (686.0 b)
Interrupt:5 Base address:0x8800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1753 errors:0 dropped:0 overruns:0 frame:0
TX packets:1753 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2120823 (2.0 MiB) TX bytes:2120823 (2.0 MiB)


eth1 is my IDS NIC. Note that it doesn't have an IP address assigned and that it is in promisc mode, as desired.
However, when I run tcpdump on this interface, all I can see is broadcast traffic:

[root@islay ~]# tcpdump -i eth1
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:45:58.053899 fe80::20e:a6ff:fe2c:87d4 > ff02::2: icmp6: router solicitation
14:46:10.908914 arp who-has 82.108.100.144 (5e:6e:30:01:88:0b) tell 82.108.100.145
14:46:13.886463 arp who-has 82.108.100.144 (01:24:11:5f:00:35) tell 82.108.100.145
14:46:25.357072 arp who-has 82.108.100.150 (c1:58:00:00:ce:95) tell 82.108.100.145
14:47:40.643888 arp who-has 82.108.100.144 (58:86:16:c9:00:50) tell 82.108.100.145

I know for a fact that a lot of traffic is going by the IDS NIC, but none of it is seen by tcpdump, despite promiscuous mode. Any ideas?
The network card is a new one: an SMC EZ 10/100 1244TXv2.0.

thanks
alex

Matir 05-12-2005 09:38 AM

Are you SURE it's only a dumb hub? There are some products labelled as hubs that actually do have some switching circuitry inside.

lardus 05-12-2005 10:36 AM

Good point. I'm pretty sure it is indeed just a hub.. it's the Linksys 10/100 5-port hub (model EFAH05W).

At one point I connected another computer directly to the IDS machine (via crossover cable) and tried pinging random addresses and did other traffic causing things from the other machine, and again, the IDS didn't see any of this traffic, but it did see some broadcast traffic from the otehr machine (netbios requests). So I'm pretty certain that the problem is the NIC not seeing the traffic somehow (or perhaps a driver?)

thanks for your reply!
alex

Matir 05-12-2005 10:49 AM

Running ifconfig, does it show the interface to be in promisc mode?

lardus 05-12-2005 10:54 AM

Hi Matir

see my original post:

>th1 Link encap:Ethernet HWaddr 00:0E:A6:2C:874
>net6 addr: fe80::20e:a6ff:fe2c:87d4/64 Scope:Link
>UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
^^^^^^^


thanks
alex

Matir 05-12-2005 01:43 PM

Oops, sorry, I somehow missed that. Try giving that interface an IP and pinging it and seeing if it can at least see that traffic.

lardus 05-13-2005 04:44 AM

Ah! Good idea there! I gave eth1 a new unused static IP addr, and ran tcpdump -vv -i eth1 while pinging it, and guess what.... I can't see the pings! Only some broadcast traffic. (The machine doing the pinging is getting replies btw so the ping is getting through)
So the problem isn't promiscuous mode, it's something else.... tcpdump can't even see traffic addressed directly to that NIC!

ta,
alex

lardus 05-13-2005 04:54 AM

Btw, when I was doing tcpdump on eth1 with a static address assigned, I also ran tcpdump with prmiscuous mode *disabled* (-p option) just to see if that made any difference: it didn't, I still couldn't see my pings going to that interface.

alex

lardus 05-13-2005 06:41 AM

A little note: I am running tcpdump as root; I know that running it as non-superuser can cause problems.

lardus 05-13-2005 07:22 AM

and some more info... running tcpdump on eth0 works fine, I can see a whole load of traffic. Also have tried two different physical NICs for eth1 with same problem that I can't see non-broadcast traffic...

Matir 05-13-2005 10:05 PM

I am wondering if this could somehow be related to the driver or chipset on eth1. What kind of cards have you tried? And what kind of card is eth0?

lardus 05-16-2005 04:22 AM

I don't have access to the machine currently, will check what hardware eth1 is shortly.
However, earlier on I tried reversing the network cards - so that eth0 was the new network card, and eth1 was the old card, and then I had the problem still that tcpdump wouldn't work on eth1 and then *would* work on eth0, which is the new hardware. So that seems to indicate that it's not the hardware or chipset or driver which is at issue, just that there is something that makes eth0 work for tcpdump and eth1 not. Something to do with the order?


All times are GMT -5. The time now is 04:26 AM.