Discussion:
oversize frame
Michael T. Davis
2013-11-08 16:09:59 UTC
Permalink
I'm running NetBSD v6.1.2 configured on a packet filtering bridge
with IP Filter (ipf -V reports "v4.1.34 (400)", as packaged with this
particular NetBSD release). The kernel has been modified to enable GATEWAY
and BRIDGE_IPF. I have a largely identical system running under NetBSD 5.1
without issues. On the NetBSD-6 system, the internal interface is seen as...

wm1 at pci1 dev 5 function 0: Intel i82541PI 1000BASE-T Ethernet (rev. 0x05)
wm1: interrupting at ioapic0 pin 17
wm1: 32-bit 33MHz PCI bus
wm1: 64 word (6 address bits) MicroWire EEPROM
wm1: Ethernet address 00:0e:0c:82:a6:77
igphy1 at wm1 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0
igphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto

...per dmesg. This and wm0 (the external interface, same hardware)
comprise the bridge endpoints, and an IP address is bound to wm1 for
"remote" management. The MTU for both interfaces is set as 1500
(the default).

Every so often, the NetBSD-6 kernel reports...

Nov 8 09:44:17 fw /netbsd: wm1: discarding oversize frame (len=1518)

It only ever cites wm1 and the length is always 1518. Since the MTU for
this interface is set to 1500, doesn't this mean that another system
attached to that interface is generating an invalid packet, presumably
due to a mis-configuration? If so, how does one pin down the miscreant
system? Can this be accomplished directly from the firewall? FWIW,
most of the installation sets are loaded, except for compiler support,
and the kernel is (otherwise) based on GENERIC. (Kernel [re]building
is done on another system.)

Thanks,
Mike
Aaron J. Grier
2014-03-27 05:35:43 UTC
Permalink
(necromancing old threads...)
Post by Michael T. Davis
Every so often, the NetBSD-6 kernel reports...
Nov 8 09:44:17 fw /netbsd: wm1: discarding oversize frame (len=1518)
It only ever cites wm1 and the length is always 1518. Since the MTU
for this interface is set to 1500, doesn't this mean that another
system attached to that interface is generating an invalid packet,
presumably due to a mis-configuration?
FWIW I see this on nfe on my sunfire x2200m2. the nfe is attached by a
vlan, but vlan packets are 1504 bytes -- 1518 seems a very strange
number.
--
Aaron J. Grier | "Not your ordinary poofy goof." | ***@poofygoof.com
David Young
2014-03-27 14:06:35 UTC
Permalink
Post by Aaron J. Grier
(necromancing old threads...)
Post by Michael T. Davis
Every so often, the NetBSD-6 kernel reports...
Nov 8 09:44:17 fw /netbsd: wm1: discarding oversize frame (len=1518)
It only ever cites wm1 and the length is always 1518. Since the MTU
for this interface is set to 1500, doesn't this mean that another
system attached to that interface is generating an invalid packet,
presumably due to a mis-configuration?
FWIW I see this on nfe on my sunfire x2200m2. the nfe is attached by a
vlan, but vlan packets are 1504 bytes -- 1518 seems a very strange
number.
I recognize the number, here is how I think it comes about: 6-byte
destination MAC + 6-byte source MAC + 2-byte outer ethertype (VLAN) +
2-byte VLAN tag + 2-byte inner ethertype + 1500 MTU = 1518 bytes.

Dave
--
David Young
***@pobox.com Urbana, IL (217) 721-9981
Andy Ruhl
2014-03-27 17:51:36 UTC
Permalink
Post by David Young
I recognize the number, here is how I think it comes about: 6-byte
destination MAC + 6-byte source MAC + 2-byte outer ethertype (VLAN) +
2-byte VLAN tag + 2-byte inner ethertype + 1500 MTU = 1518 bytes.
So a general question then: What diagnostics does NetBSD provide for
this? I assume since it's being discarded by the interface, tcpdump
would never show it? Is there a way to dump raw ethernet frames from
that interface? I'm a noob in this regard, I've only ever looked at
tcpdump or wireshark stuff.

Probably some social engineering is in order.... If this is indeed
VLAN tagging, it might not be that hard to find out who is doing it.

Andy

Loading...