Connections to F2n 2.3.6 Public Hotspot do not appear in Fon User space

[decodecoding@…]

When a fonero logs in yor F2n hotspot, after some days it should appear in your user space with the connection details. Since 2.3.6, this does no happen while other foneras with other firm version do.

[matthijs]

I think this is because of the issue in #669, so I'm closing this as a duplicate.

[decodecoding@…]

Still unable to get visits to the fon hotspot logged in 2.3.6.1

I know this ticket has been closed but just wanted to let know the issue.

[matthijs]

It seems this is happening to my 2.0n as well. I'll investigate how this process is supposed to work.

[Josemi <josemi@…>]

Same problem here.

[matthijs]

Some debugging recently confirmed that the problem did not occur with 2.0g devices, or 2.0n devices running firmware 2.3.0.0. This suggested that there was a change in the 2.3.6.0 firmware that caused the breakage.

A bit more digging and tcpdumping showed that the MAC address the Fonera sends in the Radius request Called-Station-ID property changed in 2.3.6.0.

In this firmware, the MAC address assignments were changed (to support wifi client mode). In a few other places in the firmware, exceptions were made to keep sending the old MAC address (thinclient, registration procedure). See  http://wiki.fon.com/wiki/Mac_addresses for some details on which MAC addresses were assigned how.

For chillispot, an exception was made to make it send the correct NAS-Identifier. However, the chillispot client uses the MAC address of the public wifi interface as Called-Station-ID. It seems the Router log uses the Called-Station-ID to fill the Router log. I verified this by hacking chillispot to send the "right" MAC address as Called-Station-ID (more specifically, to copy the NAS-Identifier into Called-Station-ID), which made the login show up in the Router log.

From here on, I see two possible solutions:

1. Make my above hack permanent and let chillispot send the MAC address of the wired interface as Called-Station-ID. This is the "right" MAC address from the server's point of view, but it's a bit of a hack (since the current code just takes the MAC address of the interface on which the login attempt is received, which would be changed to something hard-coded).

This could happen in the next firmware release (2.3.7.0), but would not help for existing 2.3.6.x firmwares.

2. Make the Radius servers (or whatever scripts or services at the server side) look at the NAS-Identifier attribute. Using the NAS-Identifier seems more sensible to me in the first place. Also, I suspect that this attribute is correct for all Fonera's and firmware versions, though that might need to be checked.

This fix would make the Router log work for existing firmwares as well.

Right now, we're aiming for fix #2, but due to the holidays and the impact of the change (it affects all Fonera's so the change won't be taken lightly), I'm not sure what the timeframe on the fix will be. I expect this to take a few months at least.

[matthijs]

The Fonera server and networking teams have implemented fix 2 and deployed it into the production environment somewhere last month. Both the router log and the travel log seem to be working again now. Also, log entries from earlier have been restored as well to some extent. Do note that it might take up to several days for new entries to show up in the log.

I'm closing this issue. If you find a configuration in which the issue still occurs, please leave a comment so we can further investigate.