lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.1.10.0810311012160.12764@bizon.gios.gov.pl>
Date:	Fri, 31 Oct 2008 11:04:13 +0100 (CET)
From:	Krzysztof Oledzki <ole@....pl>
To:	netdev@...r.kernel.org
cc:	auke-jan.h.kok@...el.com, jesse.brandeburg@...el.com
Subject: e1000 kills IPMI on 82541GI (Dell PE1425SC) + small 2.6.27
 regression

Hello,

I have started implementing IPMI on my servers and there is some 
inconvenience with e1000+82541GI (Dell PE1425SC).

With older kernels IPMI works if there are no vlans attached to primary 
interface. Adding vlans breaks it as e1000 driver enables VLAN filter and 
it somehow interferences with IPMI.

(no vlans):
# ethtool -d eth0|grep -i vlan
       VLAN mode:                         disabled
       VLAN filter:                       disabled

(vlans):
# ethtool -d eth0|grep -i vlan
       VLAN mode:                         enabled
       VLAN filter:                       enabled

However, I found that using a workaround by adding the IPMI vlan to the OS 
restores the functionality. Very ugly but works.

So, it is OK with no-vlan-enabled hosts and with vlan-enabled with the 
above workaround, but still - it is a ugly workaround: IPMI is 
non-functional until OS *properly* initializes network configuration, 
which may never happen.

Everything becomes much more complicated with more recent kernels (2.6.27 
for example), where vlan filter is now enabled unconditionally and I have 
to add the dummy IPMI vlan also on no-vlan-enabled hosts to make it 
working. That makes it really confusing.

So, is it possible to fix this? For example to change the driver to read 
IPMI vlan id and add it to vlan filter regardless of current OS 
configuration? Or maybe it is possible to prevent IPMI from interferencing 
with the current driver's state?

Best regards,

 				Krzysztof Olędzki

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ