We have just had a number of SMs develop the same fault.
The issue manifested as a failure for the SM to bring up it’s PPPoE session following a reboot, often but not exclusively after being converted from Bridge mode to NAT mode.
I believe the issue is to do with LUID allocation by the AP. What I am seeing for a bridged unit with working PPPoE session is the following:
0A:00:3E:xx:xx:xx has LUID of 011
3A:00:3E:xx:xx:xx has LUID of 011
4A:00:3E:xx:xx:xx has LUID of 011
On an SM which fails to bring up a session after reboot I see the following (on AP):
0A:00:3E:yy:yy:yy has LUID of 010
3A:00:3E:yy:yy:yy has LUID of 236
4A:00:3E:yy:yy:yy has LUID of 236
In both cases the Statistics → Data Channel tab on the SM shows the 0A:00:3E… LUID (eg 010)
A reboot of the SM does not resolve this (even a prolonged power-off of ~1 hour), instead the old LUID (eg 010) remains constant but the new LUID (eg 236) does change
In order to resolve this I moved the SMs to a different sector where immediately the PPPoE session came up.
This does not affect bridged units and it does not affect new connections to an AP.
It does not appear to be affected by uptime of the AP (affected APs with 5, 8 and 16 days uptime).
It does appear to be resolved by rebooting the AP but I have not tested this in current case as AP has >120 active unaffected clients. An AP with uptime of 5 days does not show this issue with any SM which have uninterrupted sessions since first connection.
All APs and SMs are running v20.0.1
We have no APs running below v20.0.1 to compare against.
The issue was not seen before upgrade to v20.0.1 (we skipped v20.0)
This has affected SMs connected to both 450i and 450m APs