On Mon, Jan 14, 2019 at 01:46:09PM +0200, Nikolay Aleksandrov wrote: > On 13/01/2019 15:59, Zahari Doychev wrote:
[...] > > How well was this set tested ? It breaks connectivity between bridge and > members when vlans are used. The host generated packets going out of the > bridge > have mac_len = 0. > > E.g.: > # tcpdump -e -n -i vnet2 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on vnet2, link-type EN10MB (Ethernet), capture size 262144 bytes > 17:47:08.824208 00:01:52:54:00:04 > 00:01:08:00:06:04, ethertype 802.1Q > (0x8100), length 32: vlan 25, p 0, ethertype 0x5eba, > 0x0000: c0a8 6401 0000 0000 0000 c0a8 6402 ..d.........d. > 17:47:09.848492 00:01:52:54:00:04 > 00:01:08:00:06:04, ethertype 802.1Q > (0x8100), length 32: vlan 25, p 0, ethertype 0x5eba, > 0x0000: c0a8 6401 0000 0000 0000 c0a8 6402 ..d.........d. > > Headers are messed up. This is br0 with pvid 25 and vnet2 with vlan 25 tagged. > You'll probably have to reset mac_len in bridge's xmit function. > Thanks I will look into this. I have done most of tests with PC with two nics and two other hosts conntected to each of the interfaces. > The potentially affected cases will need to be carefully considered, as > you've noted, > since this change is dangerous. Please also run all bridge selftests and make > sure > they all pass. Giving more details about which cases you've considered and how > this set was tested in the commit log would be very helpful. > Thanks for pointing to the selftests. I will run them. These are the tests part of the kselftest correct? Regards, Zahari > Thanks, > Nik > >
