diff options
| author | Denys Fedoryshchenko <denys.f@collabora.com> | 2026-09-09 11:05:56 +0300 |
|---|---|---|
| committer | Denys Fedoryshchenko <denys.f@collabora.com> | 2026-09-09 11:05:56 +0300 |
| commit | 1c7856294d9eeb138a8e4b2d80fc2f48033a6de1 (patch) | |
| tree | 33c31c71e5e2577a0f8efff4e71f364184951640 /tests/common/accel_pppd_process.py | |
| parent | c414f0a725a16cbd4c7063ff221dabb420b96df5 (diff) | |
| download | accel-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 'tests/common/accel_pppd_process.py')
0 files changed, 0 insertions, 0 deletions
