bce(4) sees all incoming frames as 2026 bytes in length

[Niki Denev]

On Wed, Apr 29, 2009 at 4:59 PM, pluknet <pluknet at gmail.com> wrote:
> 2009/4/29 Nikolay Denev <ndenev at gmail.com>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello,
>>
>> I have the following problem with the new bce(4) driver on a 7.2-PRERELEASE
>> from a few days ago.
>> When I run tcpdump on the bce interface on the machine, all incoming frames
>> are shown as 2026 in size,
>> but on the sending machine tcpdump reports that it's sending frames of the
>> correct size.
>> This looks very strange because I don't have enabled Jumbo Frames on this
>> bce interface , and it is still with it's default MTU of 1500 bytes.
>> When I tried to capture the packets, they are zero padded to the 2026 frame
>> size. The checksums are correct, so I suspect a driver bug?
>>
>> P.S.: I experience this problem on several machines with bce interfaces, and
>> on all of them tcpdump sees all incoming frames with length of 2026 bytes.
>
> hi.
>
> Please, give us more details. What is your network card model ?
> Share ifconfig, dmesg...
> I have a similar setup, except the frame size - mine are with expected values.
>
> --
> wbr,
> pluknet
>

Hi,

Here is one of the cards that have this problem :

bce1: <Broadcom NetXtreme II BCM5708 1000Base-T (B2)> mem
0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3
bce1: Ethernet address: 00:22:19:xx:xx:xx
bce1: [ITHREAD]
bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C
(0x04040105); Flags( MFW MSI )

bce1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=1bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4>
	ether 00:22:19:xx:xx:xx
	inet 10.18.2.1 netmask 0xffffff00 broadcast 10.18.2.255
	media: Ethernet autoselect (1000baseTX <full-duplex>)
	status: active

And here is a tcpdump that shows the problem :

16:27:32.593808 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype IPv4
(0x0800), length 2026: (tos 0x0, ttl 64, id 45347, offset 0, flags
[none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo
request, id 13578, seq 36, length 64
16:27:32.593817 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 18415, offset 0, flags
[none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo
reply, id 13578, seq 36, length 64
16:27:33.596569 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype IPv4
(0x0800), length 2026: (tos 0x0, ttl 64, id 45349, offset 0, flags
[none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo
request, id 13578, seq 37, length 64
16:27:33.596575 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 18421, offset 0, flags
[none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo
reply, id 13578, seq 37, length 64
16:27:34.599332 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype IPv4
(0x0800), length 2026: (tos 0x0, ttl 64, id 45351, offset 0, flags
[none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo
request, id 13578, seq 38, length 64
16:27:34.599338 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 18427, offset 0, flags
[none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo
reply, id 13578, seq 38, length 64
16:27:35.545001 00:22:19:yy:yy:yy > 01:00:5e:00:00:05, ethertype IPv4
(0x0800), length 2026: (tos 0xc0, ttl 1, id 45353, offset 0, flags
[none], proto OSPF (89), length 68) 10.18.2.2 > 224.0.0.5: OSPFv2,
Hello, length: 48
16:27:35.545062 00:22:19:xx:xx:xx > 01:00:5e:00:00:05, ethertype IPv4
(0x0800), length 82: (tos 0xc0, ttl 1, id 18432, offset 0, flags
[none], proto OSPF (89), length 68) 10.18.2.1 > 224.0.0.5: OSPFv2,
Hello, length: 48

There is nothing special about the setup, a few machines connected to
a gigabit switch, and some of them have
cross connects. I'm seeing this on all bce(4) interfaces, regardless
of what they are connected to (other bce(4) interface, or GigE
switch).

--
Regards,
Niki