[SOLVED] captive portal reports mac address change for sessions

[brobinsonus]

We have random ending of captive portal sessions, mostly from Android devices.  The captive portal log shows a message of "captiveportal: mac address changed fro session [session ID]".  No further information is provided and we cannot determine what is causing the captive portal to report the mac address has changed as it certainly has not.

It is not a critical issue, but certainly annoying to those that have it happen.  Any help would be appreciated.

[martain-vf]

I experience the same behavior, but it's hard to reproduce  :-\

i have patched the cp-background-process.py file to get some more logging on what goes wrong

[martain-vf]

in cp-background-process.py i replaced line 147 with:

Code Select Expand


syslog.syslog(syslog.LOG_NOTICE, "mac address (current:%s db:%s) changed for session %s" % (current_arp['mac'], db_client['macAddress'], db_client['sessionId'))


i now get log entries like:

Code Select Expand


OPNsense captiveportal: mac address (current:(incomplete) db:40:74:3a:24:da:9e) changed for session neHPP8N/vyZWxb9d2XgI0w==


looks like something is wrong with the value in current_arp['mac'] as the value is "incomplete"

I have not searched yet where it's should be set...

note: since i replaced line 147 the users aren't complaining anymore  ::)

[martain-vf]

The (incomplete) seems to come from the output of arp -an that sometimes occurs?
in the interfaces/list_arp.py file line 60 it's removed from the output which is used to display the arp table under interface diagnostics...

this is not the case in the CaptivePortal/lib/arp.py which is used in the captive portal

[AdSchellevis]

The arp entries probably got expired after some time of inactivity and then are requested again, but not known yet.... hence the (incomplete).
Captive portal should ignore those entries, we should only invalidate the session if another host is using the same mac address.

This fix should solve it:

Code Select Expand

https://github.com/opnsense/core/commit/0227b1231bc42574fa130749a72189fc62853d5e


In case you like to try, use opnsense-patch:

Code Select Expand

opnsense-patch 0227b1231


[martain-vf]

was thinking the same this morning underway to work, that it probably was the arp cache that cleans out the entries (after 20 min validated and not in use, as described in the arp man page)

you could also use the dhcp lease file to check the arp mappings, but then again the captive portal does not necessarily run the dhcp server...

I've successfully applied the patch and will let you know if things go awry

Tnx for the quick fix  ;)