On Wed, Jun 5, 2019 at 12:27 AM Steinar H. Gunderson <steinar+ker...@gunderson.no> wrote: > > On Tue, Jun 04, 2019 at 09:31:42PM -0700, Cong Wang wrote: > >> This works fine for large packets, but the system in the other end > >> drops smaller packets, such as ARP requests and small ICMP pings. > > Is the other end Linux too? > > Yes and no. The other end is Linux with Open vSwitch, which sends the packet > on to a VM. The VM is an appliance which I do not control, and while the > management plane runs Linux, the data plane is as far as I know implemented > in userspace.
Hmm, sounds like openvswitch should pad the packets in this scenario, like hardware switches padding those on real wires. > > The appliance itself can also run EoGRE directly, but I haven't gotten it to > work. > > > If the packet doesn't go through any real wire, it could still be accepted > > by Linux even when it is smaller than ETH_ZLEN, I think. > > Yes, but that's just Linux accepting something invalid, no? It doesn't mean > it should be sending it out. Well, we can always craft our own ill-formatted packets, right? :) Does any standard say OS has to drop ethernet frames shorter than the minimum? > > > Some hardware switches pad for ETH_ZLEN when it goes through a real wire. > > All hardware switches should; it's a 802.1Q demand. (Some have traditionally > been buggy in that they haven't added extra padding back when they strip the > VLAN tag.) If so, so is the software switch, that is openvswitch? > > > It is still too early to say it is a bug. Is this a regression? > > I haven't tried it with earlier versions; I would suspect it's not a > regression. Good to know. Thanks.
