On Tue, Jan 8, 2019 at 11:51 PM Stephen Hemminger <step...@networkplumber.org> wrote: > On Tue, 8 Jan 2019 23:10:04 +0100 > Ian Kumlien <ian.kuml...@gmail.com> wrote: > > On Sun, Jan 6, 2019 at 11:21 PM Ian Kumlien <ian.kuml...@gmail.com> wrote: > > > > > > [Sorry for the repost, screwed up the netdev address...] > > > > > > Hi, > > > > > > Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s. > > > > > > My firewall (which also runs the dhcpd) runs VM:s and it does this by > > > having physical > > > interfaces attached to bridges - which the VM:s in turn attach to. > > > > > > Since 4.20 the VM:s can't use DHCP, it's odd since the requests are > > > seen - a response is sent but > > > it never enters the interface attached to the bridge. > > > > > > Basically: > > > VM vnet2: -> br0 -> eno2 -> switch -> eno1 (dhcpd) > > > dhcpd eno1 -> siwtch and... gone. > > > > > > Any clues? > > > > > > All the nics are handled by ixgbe > > > > So, doing similar tests at work with other drivers works - could it be > > related to the mac address filter that was added? > > I don't *really* use VF:s though... (can't really find anything else atm) > > > > Will try to test, but the VM:s on this machine is in use. > > The default MAC address of the bridge device is the first device assigned > to the bridge. Remember most VF interfaces will only allow single MAC address > and no promiscious mode.
Yeah, I'm not running any VF:s and it just seems like the responses are dropped somewhere when looking at "git log v4.19...v4.20 drivers/net/ethernet/intel/ixgbe/" nothing else really stands out... The machine is also running NAT for my home network and all of that works just fine... I started with tcpdump, prooving that packets reached all the way outside but replies never made it, reboorting with 4.19.13 resulted in replies appearing in the tcpdump. I don't quite know where to look - and what can i do to test - i tried disabling all offloading (due to the UDP offloading changes) but nothing helped... Ideas? Patches? ;)