Date: Thu, 30 Apr 2009 14:56:29 +0300 From: Nikolay Denev <ndenev@gmail.com> To: freebsd-net@freebsd.org Subject: Re: bce(4) sees all incoming frames as 2026 bytes in length Message-ID: <FAC395EB-BEE6-4981-85D2-82ADFC2DF441@gmail.com> In-Reply-To: <a31046fc0904290904x796a7d44ne66514f777d2237f@mail.gmail.com> References: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> <a31046fc0904290659h3c831abcy14318b73c1462068@mail.gmail.com> <2e77fc10904290733m4858172ayd96654f3a9a3a8a@mail.gmail.com> <a31046fc0904290904x796a7d44ne66514f777d2237f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Apr 29, 2009, at 7:04 PM, pluknet wrote:
> 2009/4/29 Niki Denev <ndenev@gmail.com>:
>
>> 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
>
> Ok, now I see. A link level length is 2026 for me too for some sort
> of packets
> (in opposite to proto's len where all is ok).
>
> Mine nic is <Broadcom NetXtreme II BCM5708 1000Base-T (B2)>
> (same as yours).
>
> Looks like a regression.
> I just also tested 7.1-R and it shows expected LL-length.
>
>
> --
> wbr,
> pluknet
I think I got it.
It seems that the mbuf fields m_pkthdr.len and m_len are not updated
to the real packet size pkt_len.
Well, actually they are updated, but only if we have ZERO_COPY_SOCKETS
defined.
After I added this :
m0->m_pkthdr.len = m0->m_len = pkt_len;
at about line 5930 in if_bce.c, the frame length reported by tcpdump
seems correct.
P.S.: I guess this could be the cause for the lagg(4) over bce(4)
problems too?
P.S.2: This fix will probably break the ZERO_COPY_SOCKETS case, but
should be fairly easy to make it a "proper" fix.
Regards,
Niki Denev
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (Darwin)
iEYEARECAAYFAkn5kfAACgkQHNAJ/fLbfrnF6QCcDXOXdWvfpqBIrCIa1ToQjfQy
JeoAn0dtODtxQeKczU7rHoFOiENO7Tfj
=kIvo
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FAC395EB-BEE6-4981-85D2-82ADFC2DF441>