Bug in ethernet module b44.c (2.6.7)

Bug in ethernet module b44.c (2.6.7)

[Miroslav Zubcic]

Hello everyone!

I have Laptop Compaq nx5000 with Linux installed, and this network
card:

-------------------------------------------------------------------
01:0e.0 Ethernet controller: Broadcom Corporation BCM5705M 10/100/1000Base T (rev 02)
        Subsystem: Hewlett-Packard Company: Unknown device 08bc
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at 90080000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
-------------------------------------------------------------------

Motherboard and chipset:

-------------------------------------------------------------------
00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02)
        Subsystem: Hewlett-Packard Company: Unknown device 08bc
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Region 0: Memory at <unassigned> (32-bit, prefetchable)
        Capabilities: [40] #09 [a105]

00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02)
        Subsystem: Hewlett-Packard Company: Unknown device 08bc
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02)
        Subsystem: Hewlett-Packard Company: Unknown device 08bc
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

-------------------------------------------------------------------

I had problems with b44 module on 2.6.6 kernel, but this was resolved
with patch from Pekka Pietikainen on this list, and later merged in
2.6.7 kernel. Thanks Pekka and Jeff.

Meanwhile, I have discovered new bug in this module. When opening raw
socket, network card will stop sending and receiveing packets.

For example, if I start `nmap -v -sS 192.168.1.70'. nmap(1) freezes
and waits forever. While nmap(1) is active (and trying to do it's
job), I cannot do anything on the net. Existing ssh connections are
freezed and unresponsive. If I interrupt nmap, everything comes back
to normal after 1-2 seconds.

Only working mode for nmap(1) is: "nmap -v -sT -P0". This mode will
not freeze broadcom ethernet card.

However, I have found one workaround. If I start tcpdump(8) in one
xterm on eth interface to wait for traffic, and "nmap -v -sS" in other
window, nmap (and all other active or new connections, like ssh, http)
are working without problem. So, if PROMISC is set on interface
(tcpdump will set this flag when started, and remove on interrupt),
everything works as expected. Of course, if I stop tcpdump(8), and
start nmap(1) again, it will not work, and network will be unusable
until I kill nmap(1). In normal mode without nmap(1), that is -
tcp,udp ssh/http/imap/smtp ... there is no visible problems.  dmesg(8)
does not report anything unusual, neither logfiles do.

I hope this is enough info.


-- 
Many men would sooner die then think. In fact they do.
		-- Bertrand Russell

Re: Bug in ethernet module b44.c (2.6.7)

[Denis Vlasenko]

On Monday 02 August 2004 12:02, Miroslav Zubcic wrote:
> I had problems with b44 module on 2.6.6 kernel, but this was resolved
> with patch from Pekka Pietikainen on this list, and later merged in
> 2.6.7 kernel. Thanks Pekka and Jeff.
>
> Meanwhile, I have discovered new bug in this module. When opening raw
> socket, network card will stop sending and receiveing packets.
>
> For example, if I start `nmap -v -sS 192.168.1.70'. nmap(1) freezes
> and waits forever. While nmap(1) is active (and trying to do it's
> job), I cannot do anything on the net. Existing ssh connections are
> freezed and unresponsive. If I interrupt nmap, everything comes back
> to normal after 1-2 seconds.

Provide strace of hung nmap.

> Only working mode for nmap(1) is: "nmap -v -sT -P0". This mode will
> not freeze broadcom ethernet card.
>
> However, I have found one workaround. If I start tcpdump(8) in one
> xterm on eth interface to wait for traffic, and "nmap -v -sS" in other
> window, nmap (and all other active or new connections, like ssh, http)
> are working without problem. So, if PROMISC is set on interface
> (tcpdump will set this flag when started, and remove on interrupt),
> everything works as expected. Of course, if I stop tcpdump(8), and
> start nmap(1) again, it will not work, and network will be unusable
> until I kill nmap(1). In normal mode without nmap(1), that is -
> tcp,udp ssh/http/imap/smtp ... there is no visible problems.  dmesg(8)
> does not report anything unusual, neither logfiles do.

Does just setting promisc with ifconfig or ip tool helps?

> I hope this is enough info.
--
vda

Re: Bug in ethernet module b44.c (2.6.7)

[Miroslav Zubcic]

Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:

> Provide strace of hung nmap.

--------------------------------------
execve("/usr/bin/nmap", ["nmap", "-sS", "192.168.3.1"], [/* 45 vars */]) = 0

[...]

read(3, "Iface\tDestination\tGateway \tFlags"..., 1024) = 640
read(3, "", 1024)                       = 0
close(3)                                = 0
munmap(0x4017d000, 4096)                = 0
socket(PF_INET, SOCK_RAW, IPPROTO_RAW)  = 3
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
socket(PF_INET, SOCK_RAW, IPPROTO_RAW)  = 4
setsockopt(4, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
socket(PF_PACKET, SOCK_RAW, 768)        = 5
ioctl(5, 0x8933, 0xbfffa650)            = 0
ioctl(5, 0x8927, 0xbfffa650)            = 0
ioctl(5, 0x8933, 0xbfffa650)            = 0
bind(5, {sa_family=AF_PACKET, proto=0x03, if3, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0
setsockopt(5, SOL_PACKET, PACKET_ADD_MEMBERSHIP, "\3\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
ioctl(5, 0x8921, 0xbfffa650)            = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
ioctl(6, 0x8915, 0xbfffa4c0)            = 0
ioctl(6, 0x891b, 0xbfffa4c0)            = 0
close(6)                                = 0
setsockopt(5, SOL_SOCKET, 0x1a /* SO_??? */, "r\0\0\0\210\35\r\10", 8) = 0
gettimeofday({1091471189, 938221}, NULL) = 0
setsockopt(4, SOL_IP, IP_HDRINCL, [1], 4) = 0
sendto(4, "E\0\0\34\317\6\0\0003\1\3651\0\0\0\0\300\250\3\1\10\0\376"..., 28, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.3.1")}, 16) =
 28
gettimeofday({1091471189, 938342}, NULL) = 0
setsockopt(3, SOL_IP, IP_HDRINCL, [1], 4) = 0
sendto(3, "E\0\0(t\377\0\0001\6\215u\300\250\3\n\300\250\3\1\214\n"..., 40, 0, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.3.1")}, 16) = 
40
gettimeofday({1091471189, 938429}, NULL) = 0
gettimeofday({1091471189, 938446}, NULL) = 0
gettimeofday({1091471189, 938464}, NULL) = 0
gettimeofday({1091471189, 938483}, NULL) = 0
gettimeofday({1091471189, 938501}, NULL) = 0
select(6, [5], NULL, NULL, {0, 20000})  = 0 (Timeout)
gettimeofday({1091471189, 958183}, NULL) = 0
select(6, [5], NULL, NULL, {0, 20000})  = 0 (Timeout)
gettimeofday({1091471189, 978194}, NULL) = 0
select(6, [5], NULL, NULL, {0, 20000})  = 0 (Timeout)
gettimeofday({1091471189, 998175}, NULL) = 0
select(6, [5], NULL, NULL, {0, 20000})  = 0 (Timeout)
gettimeofday({1091471190, 18172}, NULL) = 0
select(6, [5], NULL, NULL, {0, 20000})  = 0 (Timeout)
gettimeofday({1091471190, 38168}, NULL) = 0

[...]

... and so on and on until interrupted on the console.

[...]

--- SIGINT (Interrupt) @ 0 (0) ---
write(2, "caught SIGINT signal, cleaning u"..., 34) = 34
munmap(0x40017000, 4096)                = 0
exit_group(1)       

--------------------------------------

> Does just setting promisc with ifconfig or ip tool helps?

Yes, 'ifconfig eth0 promisc' works as a workaround. Just like when I
do it indirectly with tcpdump(8).


-- 
Many men would sooner die then think. In fact they do.
		-- Bertrand Russell