The 8168B (02) NIC works well except that it does not go into promiscuous mode despite advertising itself in that mode after being so directed with ifconfig. Unfortunately, the little box is destined to be an IDS monitor, so that function is essential. The board is an Intel Atom 330 run as x86_64, the nic is internal.
We tried three drivers: the one in the 2.6.18-128.1.10.el5 kernel yields a high count of dropped packets (known problem), and the drivers from Realtek and El Repo. None solve the promiscuous problem (although they fix the funny dropped counter issue).
Apparently the chip has no MII capability either.
Anyone have any idea as how to make this chip do the promiscuous mode thing other than adding another nic card ?
Ben Mohilef wrote:
The 8168B (02) NIC works well except that it does not go into promiscuous mode despite advertising itself in that mode after being so directed with ifconfig. Unfortunately, the little box is destined to be an IDS monitor, so that function is essential. The board is an Intel Atom 330 run as x86_64, the nic is internal.
I presume you are talking about a Atom 230 not a Atom 330, as on the an original Intel board with an Atom 330, the D945GCLF2 you can just use the r8169 driver, on the D945GCLF with an Atom 230 board you need a r8101 driver
Intel D945GCLF2 (Atom 330) * /etc/modprobe.conf
alias scsi_hostadapter ata_piix alias snd-card-0 snd-hda-intel options snd-card-0 index=0 options snd-hda-intel index=0 remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbi$ alias eth0 r8169
* lspci output
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Intel D945GCLF (Atom 230) * /etc/modprobe.conf
alias scsi_hostadapter ata_piix alias snd-card-0 snd-hda-intel options snd-card-0 index=0 options snd-hda-intel index=0 remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbi$ alias eth0 r8101 alias eth1 pegasus
* lspci
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
None solve the promiscuous problem (although they fix the funny dropped counter issue). [...] Anyone have any idea as how to make this chip do the promiscuous mode thing other than adding another nic card ?
If it is an original Intel board D945GCLF with the Atom 230, I suggest downloading the driver from the Intel website http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProductID=2916&am... I compiled the driver manually (at the time elrepo didn't exist) from the Intel website, it has been working fine, and I regularly check my tcpdump, dmesg even states that it enter promiscuous mode and exits
device eth0 entered promiscuous mode device eth0 left promiscuous mode
only thing I did that wasn't in the manual is manually delete the r8169 drivers of my kernel, I did have problem when I didn't do this
It is an D945GCLF2 with a 330.
use the r8169 driver
That driver has issues with the counters, resolved with the ElRepo and Realtek drivers. Ifconfig shows no dropped packets with the latter two drivers.
website, it has been working fine, and I regularly check my tcpdump, dmesg even states that it enter promiscuous mode and exits > device eth0 entered promiscuous mode > device eth0 left promiscuous mode only
The dmesg statement comes from a printk statement in the driver. I modified the driver to force the register to always load rx=AllowMe|AllowAll|AllowBroadcast|AllowMulticast. I surrounded it with printk statements so I know that it is entering and exiting the rx setting. It acts like this variable is never being written to the chip register. Hmmm, I think I need to look at their code some more to make sure they ARE writing to the register.
Despite the kernel messages, the chip does not enter the promiscuous mode. If you have a second box talking to a third address, do you see that TCP traffic in TCPDump. Another way to check it is using iptraf.
Ben Mohilef wrote:
It is an D945GCLF2 with a 330.
use the r8169 driver
That driver has issues with the counters, resolved with the ElRepo and Realtek drivers. Ifconfig shows no dropped packets with the latter two drivers.
website, it has been working fine, and I regularly check my tcpdump, dmesg even states that it enter promiscuous mode and exits > device eth0 entered promiscuous mode > device eth0 left promiscuous mode only
The dmesg statement comes from a printk statement in the driver. I modified the driver to force the register to always load rx=AllowMe|AllowAll|AllowBroadcast|AllowMulticast. I surrounded it with printk statements so I know that it is entering and exiting the rx setting. It acts like this variable is never being written to the chip register. Hmmm, I think I need to look at their code some more to make sure they ARE writing to the register.
Despite the kernel messages, the chip does not enter the promiscuous mode. If you have a second box talking to a third address, do you see that TCP traffic in TCPDump. Another way to check it is using iptraf.
iptraf shows packets, no problems here So I run on two boxes iptraf and ping from on to another box, it shows me the ICMP req and reponse on both boxes Also when I ping from the router, a linksys, it shows me the ICMP
BUT I found the following information : even though bugzilla 452761 (https://bugzilla.redhat.com/show_bug.cgi?id=452761) is solved by kernel 2.6.18-128, bugzilla 474334 (https://bugzilla.redhat.com/show_bug.cgi?id=474334) is only solved in kernel 2.6.18-141, so may need to use a kernel from Don Zickus before you can use them properly http://people.redhat.com/dzickus/el5/
Thanks for the feedback. Problem was not with the chip, problem was a managed switch to which the box was inadvertently connected. Replaced switch with hub, tried with both ElRepo and Realtek drivers, can see TCP packets now from other computers. Labelled data cables better so mistake won't happen again. Nice to know that the switch did exactly what it was supposed to do.
Sorry for the unnecessary noise.
benm
-
Ben Mohilef -
Tosh