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

[security]

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.

jim