In article <20151119105018.gq23...@caravaggio.net.espci.fr>, <jean-jacques.p...@espci.fr> wrote: >-=-=-=-=-=- > >Hi, > >I submit the attached patch to your consideration for inclusion >(possibly with amendments) to the kernel source. > >It deals with an old issue raised on the port-xen ML on the 2008/06/21 >(http://mail-index.netbsd.org/port-xen/2008/06/21/msg003915.html). > >* Summary: >Where VLAN interfaces are required in a domU, Ethernet frames (sent and >received) on these interfaces are limited to a 1496 bytes MTU, because >xennet interface does not currently support the VLAN_MTU capability. > >Furthermore, the frame size check on dom0's xen interface does not >account for the possibility of an extended MTU for VLAN traffic and does >not support the capability either. > >This patch adds the VLAN_MTU capability to these interfaces. In >particular, the frame size check takes ETHER_VLAN_ENCAP_LEN into >consideration *if the capability is enabled*. > >Where a VLAN interface is attached to such interfaces, the VLAN_MTU >capability will be enabled. Most probable use for this configuration is >on the domU side. On the dom0 side, however, xen interfaces are usually >members of a bridge interface. > >This patch also modifies the bridge interface in order to enable the >VLAN_MTU capability on interfaces added to the bridge and to disable >this capability on interfaces removed from the bridge, only if they do >not already deal with VLAN traffic as the result of another >configuration. > >This does not actually change the traffic processing operations on the >bridge side (but may on the member interface side as a result of the >capability being enabled), because a bridge interface sets promiscuous >mode on member interfaces. In this mode, received frames bigger than >member interface's configured MTU actually get through; this is why >tcpdump can show frames that are actually dropped by normal >(non-promiscuous) receiving routines on the interface. > >* Background: >This patch was developped to address MTU issues on a wireless LAN >infrastructure, where multiple SSIDs (currently eduroam and eduspot) and >management traffic are each mapped on a different VLAN, as is often >mandatory while dealing with enterprise class access-points. Tagged VLAN >traffic is then bridged to a domU which acts as the wireless LAN >gateway. Alternatives involved a mix of DHCP interface-mtu option >(ignored by many clients), MSS clamping, RADIUS framed-mtu property and >kernel tcp.mss_ifmtu state and still could not resolve issues with some >traffics. > >We've been using a first version of this patch since Oct 29, and current >version since Nov. 16.
Thanks, I applied your changes to -current. Can you please test? Best, christos
