bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2

[security]

security wrote:
> Jung-uk Kim wrote:
>   
>> On Tuesday 18 November 2008 01:01 pm, security wrote:
>>   
>>     
>>> I'm building a WAN emulation box based on 7.1-beta2-ipfw and
>>> dummynet. The config is basically a router-on-a-stick.  The server
>>> (FBSD rtr) has two nics which connect to two different switches,
>>> but both switch ports are in the same untagged interconnected vlan.
>>>  All the other test boxes in the network are also in the same vlan,
>>> but broken into different nets.  The different nets are spread
>>> across the two nics as primary and alias ip address in different
>>> nets.  I've been getting "bursts" (maybe 8-20 at a time) of the
>>> discard frame messages.  Mostly on bce1 but I've seen them on bce0
>>> also. bce1 is probably the busier of the 2 currently. As a shot in
>>> the dark, I disabled polling system wide and the messages seemed to
>>> have stopped.
>>>     
>>>       
>> Please try the latest driver from RELENG_7.  The following commit 
>> seems interesting:
>>
>> http://svn.freebsd.org/viewvc/base?view=revision&revision=184826
>>
>> Jung-uk Kim
>>
>>   
>>     
>>> thanks
>>> jim
>>>
>>>
>>> kernel: bce1: discard frame w/o leading ethernet header (len
>>> 4294967292 pkt len 4294967292)
>>>
>>> ipfw/dummynet/pipes are being used to rate limit traffic by src/dst
>>> ip address.
>>>
>>> The FreeBSD box uses the broadcom bcm5706s gigE interfaces.
>>> class=0x020000 card=0x310c103c chip=0x16aa14e4 rev=0x02 hdr=0x00. 
>>> Based on some readings, I've got the following mods in place:
>>> i386 sources running on a 2 x dual core athalon64 cpus, 4 cores
>>> active. 8gig of mem available, but only 4 in use
>>> kernel
>>> i486 and i586 commented out
>>> nfs options commented out
>>> fbsd 4 and 5 commented out
>>> hz=1000
>>> ipfirewall
>>> ipfirewall_default_to accept
>>> dummynet
>>> eisa commented out as well as the older nics
>>>
>>> sysctl settings
>>> kern.polling.enable=1 (setting this to 0 seems to fix the problem,
>>> but leaves the cpu's busier)
>>> kern.ipc.maxsockbuf=16777216 (not sure this helps much in the case
>>> of a rtr) net.inet.ip.forwarding=1
>>> net.inet..tcp.sendbuf_auto=1
>>> net.inet..tcp.sendbuf_max=16777216
>>> net.inet..tcp.recvbuf_auto=1
>>> net.inet..tcp.recvbuf_max=16777216
>>> net.inet.tcp.rfc1323=1
>>> net.link.ether.inet.log_arp_wrong_iface=0 (to suppress the arp
>>> messages)
>>>     
>>>       
> I'm running the new driver now.  It's logging Ierrs on the <Link#n> of
> "netstat -I bcen -a" @ about 1-2 per second.  I don't *think* it was
> doing that under the original driver, but I couldn't swear to it, and it
> would be difficult to revert right now to check.  The errors seem
> unrelated to traffic generated by ping repeat count or payload size. 
> Might these be the ARP on the wrong iface errors I'm suppressing ?  Ping
> isn't complaining about any dropped packets and I'm not seeing any drops
> or collision stats.
>   
to reply to my own post, I dumped the sysctl values for the bce
devices.  These errors are L2Filter drops and I suspect they're from
oversize >1500 ethernet frames.  Not sure whats generating them yet.

jim