Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade
From: Robert Brown (eli_at_typhoon.xnet.com)
Date: 12/28/03
- Previous message: mnow: "Re: Update boot problem"
- In reply to: Harry Hoffman: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Next in thread: Robert Brown: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Reply: Robert Brown: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: redhat-list@redhat.com Date: Sun, 28 Dec 2003 01:05:22 -0600 (CST)
Harry Hoffman writes:
> Wait a sec. You are seeing this same behavior on other boxes? Are they all the
> same setup? (i.e. RH9->with newest kernel).
Same kernel on all boxes: 2.4.20-27.9, as of 12/23/03 or 12/24/03, I
forget which.
Since it is now officially the week between Christmas and New Years, I
have the firewall only doing masquerading, so the servers are not
visible from the internet. Its a good time to fool around with the
network. From that perspective, this couldn't have happened at a
better time.
Also, I have the flu, which makes it harder to think than usual. So
wash your hands thoroughly after reading this email. ;-(
> If the machines are different, in regards to os/patch level, then that would
> seem to indicate that the software isn't the issue.
No, they are the same, and promiscuous mode worked on all of them
before, and now it doesn't.
> Don't know if this pertains to your situtation but it may prove useful:
> http://www.ethereal.com/lists/ethereal-users/200302/msg00247.html
So what is your point? All that I got from that url was that some guy
was having trouble using promiscuous mode on a windoze box.
Coincidently, he was using a very similar hub to the ones I am using
in the 100baseT legs of my network, the difference being he was using
the 5 port model, whereas I am using the 8 port version. However, I
am still using the same 10baseT hub I have used for about 5 years for
the wild side of my network -- where the bridge to the internet is
located -- and I can't sniff that either.
> In terms of the nic settings are they reporting the correct duplex (even though
> you've set it it may not be taking...perhaps changes to the new modules?)
> What does mii-tool/ethtool report?
Very interesting!
[root@jonah root]# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0xffffffff (-1)
Link detected: yes
[root@jonah root]#
Why does it say "Duplex: Full"? I forced it to half in
/etc/modules.conf:
alias eth0 8139too
alias eth1 8139too
alias eth2 8139too
options 8139too 0x100,0x100,0x10
I guess I can manually override this using ethtool:
[root@jonah root]# ethtool -s eth0 duplex half
[root@jonah root]# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0xffffffff (-1)
Link detected: yes
[root@jonah root]#
Nope! That doesn't work. :-(
Try turning off autonegotiation first. Good! Now I can get it to
stay in half duplex.
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0xffffffff (-1)
Link detected: yes
I guess I will have to script ethtool calls into /etc/rc.d/rc.local to
force these NICs to behave the way I want them to. Here is the way
the NICs look right now:
[root@jonah root]# for i in 0 1 2 ; do ethtool eth$i ; done
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0xffffffff (-1)
Link detected: yes
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0xffffffff (-1)
Link detected: yes
Settings for eth2:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0xffffffff (-1)
Link detected: no
[root@jonah root]#
Unfortunately, ethtool does not show anything regarding promiscuous
mode setting.
And even after forcing the NIC into half duplex mode, it still doesn't
see any packets not addressed to itself or broadcast.
> Are the cards all the same? Are they plugged into different hubs (you've
> probably already answered this, sorry)?
>From /etc/sysconfig/hwconf to the best of kudzu's knowledge:
-
class: NETWORK
bus: PCI
detached: 0
device: eth
driver: 8139too
desc: "Realtek|RTL-8139/8139C/8139C+"
vendorId: 10ec
deviceId: 8139
subVendorId: 1799
subDeviceId: 5000
pciType: 1
-
class: NETWORK
bus: PCI
detached: 0
device: eth
driver: 8139too
desc: "D-Link System Inc|RTL8139 Ethernet"
vendorId: 1186
deviceId: 1300
subVendorId: 1186
subDeviceId: 1301
pciType: 1
-
class: NETWORK
bus: PCI
detached: 0
device: eth
driver: 8139too
desc: "Realtek|RTL-8139/8139C/8139C+"
vendorId: 10ec
deviceId: 8139
subVendorId: 1799
subDeviceId: 5000
pciType: 1
-
Each NIC is plugged into a different hub. eth0 is the addressable
one; it is on the LAN. eth1 is on the DMZ, and eth2 is on the WILD.
-- -------- "And there came a writing to him from Elijah" [2Ch 21:12] -------- R. J. Brown III rj@elilabs.com http://www.elilabs.com/~rj voice 859 567-7311 Elijah Laboratories Inc. P. O. Box 166, Warsaw KY 41095 fax 859 567-7311 ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------ -- redhat-list mailing list unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
- Previous message: mnow: "Re: Update boot problem"
- In reply to: Harry Hoffman: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Next in thread: Robert Brown: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Reply: Robert Brown: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
