summaryrefslogtreecommitdiff
path: root/drivers/dkms/ipoe/debian
diff options
context:
space:
mode:
authorDenys Fedoryshchenko <denys.f@collabora.com>2026-09-09 11:05:56 +0300
committerDenys Fedoryshchenko <denys.f@collabora.com>2026-09-09 11:05:56 +0300
commit1c7856294d9eeb138a8e4b2d80fc2f48033a6de1 (patch)
tree33c31c71e5e2577a0f8efff4e71f364184951640 /drivers/dkms/ipoe/debian
parentc414f0a725a16cbd4c7063ff221dabb420b96df5 (diff)
downloadaccel-ppp-1c7856294d9eeb138a8e4b2d80fc2f48033a6de1.tar.gz
accel-ppp-1c7856294d9eeb138a8e4b2d80fc2f48033a6de1.zip
tests: give the veth pair fixed MAC addresses
The tests create the veth pair with 'ip link add ... type veth peer name ...' and let the kernel pick random hardware addresses, then start accel-pppd right away. On distributions where systemd-udevd rewrites the address of a freshly created veth (MACAddressPolicy in its .link rules, seen on Ubuntu 22.04) this is a race: accel-pppd reads the address of the interface it serves once, at startup, and when udev wins it advertises an address the interface no longer has. Discovery still completes - the client copies the advertised address into its kernel PPPoE session as the peer address - but from then on the two ends disagree about it, no PPP frame is exchanged in either direction, and the session dies on LCP timeouts. Every PPPoE session test can fail this way; test_pppoe_ccp_ipcp_race failed 8 times out of 12 runs in one qemu Ubuntu-22.04 job. Create the pair with fixed, locally administered addresses derived from the name the pair already gets, so udev has nothing to change. The same job passes 12 out of 12 with this. This only removes the trigger in the tests. accel-pppd not following the address of the interface it serves is tracked in #363 and needs a fix of its own.
Diffstat (limited to 'drivers/dkms/ipoe/debian')
0 files changed, 0 insertions, 0 deletions