Opened 9 years ago

Closed 6 years ago

Last modified 6 years ago

#953 closed bug (fixed)

Chillispot dies - because of misconfigured RADIUS?

Reported by: Ole Bendik Kvisberg <olekvi@…> Owned by:
Priority: normal Milestone:
Component: fon-network Version: (Gari jr.)
Severity: unknown
Cc: c.j.king@… Hardware: 2.0n (FON2300)


I got a brand new 2.0n and plugged it in and let it do it's first boot things.

When trying to connect to the *public* wlan zone I got no IP address from DHCP. Note: The privat zone is working just great.

After som investigation I found chillispot died during startup because of misconfiguration:

Oct 23 16:52:32 Fonera daemon.err chillispot[2178]: options.c: 311: 
Could not resolve IP address of uamserver: 
https://www.fon.comAppSecurePort/login/gateway/sec/*keyremoved*! [Success]

Note: chillispot says "Success" and dies.

I hacked the init script, removing AppSecurePort? with sed, and now Chillispot is working.

Trying to find out what is going on I installed tcpdump and got:

Vendor  Specific  Attribute  (26),  length:  101  (bogus,  goes  past  end  of  packet)  ....E...q.
.6.....-.T......#.........c.. ..j.n.......&..8.. radiusserver2*secretremoved*...8...uamsecret                *secretremoved*.

from (I have added som newlines for better readability)

I can reproduce this bogus response from radius today as well.

Please see for more information on the topic.

I will gladly supply more debug information if needed.

Attachments (1)

tcpdump-olekvi-fonera-2010-10-25 (1.7 KB) - added by Ole Bendik Kvisberg <olekvi@…> 9 years ago.
tcpdump from radconfig1

Download all attachments as: .zip

Change History (16)

comment:1 Changed 9 years ago by matthijs

  • Cc c.j.king@… added
  • Status changed from new to investigate

#939 is a duplicate of this report.

comment:2 Changed 9 years ago by c.j.king@…

This has since been fixed - a reply from FON support: Response (David) 01/10/2010 12.50 PM Hello We've found a bug that sends the wrong URL to some routers, our developers are working on a solution and is expected that it will be solved during this weekend. Regards FON Customer Care

comment:3 Changed 9 years ago by matthijs

I've pointed the networking team at this issue, perhaps they can find the exact cause of the problem.

In the meanwhile, a few more questions. Could you add the exact contents of your /etc/chilli.conf file here? Also, are you sure the packet you dumped is from I would have expected that packet from or To confirm, could you perhaps run a bigger packet dump on all radius packets and write the full packets to a file? This would need the following tcpdump commandline:

root@Fonera:~# tcpdump -i eth0.2 -s 0 -w /tmp/dump src or dst 1812 or src or dst 1813

I haven't tested this on my Fonera, but the filter works on my normal system. This captures full packets into the file /tmp/dump, so please attach that file here after you finish dumping.

Note that this will not give any output for the dumped packets. To see what has been dumped already, you should be able to run:

root@Fonera:~# tcpdump -r /tmp/dump

which reads in the dumpfile and outputs the contents.

comment:4 Changed 9 years ago by matthijs

  • Status changed from investigate to confirmed

Hmm, I just saw c.j.king's reply. Apparently the real issue is not fixed yet, but the issue can be worked around for existing Fonera's (each Fonera has its own uamserver database entry which can be fixed).

I'll keep you posted when I find out more. For now, just ignore my tcpdump instructions above, I don't think those are relevant anymore.

comment:5 Changed 9 years ago by Ole Bendik Kvisberg <olekvi@…>

First; sorry I didn't see ticket 939.

This is /etc/chilli.conf whithout my patched init script:

root@Fonera:~# cat /etc/chilli.conf 
radiussecret *secretremoved*
uamsecret *secretremoved*
dhcpif eth1
uamserver https://www.fon.comAppSecurePort/login/gateway/sec/d92ec1cd74d5332f5e3b0034a8110c8f

chillispot dies with:

# /etc/init.d/chillispot start
uci: Entry not found
ifconfig: SIOCGIFFLAGS: No such device
iwpriv ra1 set SSID=FON_OBK
chillispot[3543]: options.c: 311: Could not resolve IP address of uamserver: https://www.fon.comAppSecurePort/login/gateway/sec/d92ec1cd74d5332f5e3b0034a8110c8f! [Success]

With my patched init script:

radiussecret *secretremoved*
uamsecret *secretremoved*
dhcpif eth1


chillispot[4358]: options.c: 429: Invalid uamallowed domain or address:! [Success]

but is started and working.


--- /etc/init.d/chillispot	Mon Oct 25 10:28:01 2010
+++ /tmp/chillispot	Mon Oct 25 10:26:40 2010
@@ -81,7 +81,6 @@
 		--wwwbin=/bin/true \
 		--ipup=/bin/true \
 		--ipdown=/bin/true \
-		|sed 's/AppSecurePort//' \
 		> $TMP_C

Your tcpdump filter didn't work. I'm not sure if it's the (limited) tcpdump from openwrt or what.

Any way, a working filter is:

src port 1812 or dst port 1812 or src port 1813 or dst port 1813

This clearly shows the (wrong) data received from as you expected, not as I wrongly wrote in my first response.

PS: I just read your last response after finishing what you asked for (but perhaps don't need) - I'll send it any way in case it may help. I can not find any way to attach a file when replying in Trac (I could when I wrote the new ticket) Please let me know if you want that dump,

Thanks for you speedy reply on this problem guys!

comment:6 Changed 9 years ago by matthijs

Thanks for the info, it confirms what I suspected: The radius server sends the wrong reply. Internally, it's a bit more complicated, since the radius server just sends the contents of the database, but the process that fills the database for new Foneras is apparently a bit more complex (so the real cause has not been found yet).

Anyway, there is an attach file button just below the ticket description, which is a bit of a silly place for it, but well :-)

Changed 9 years ago by Ole Bendik Kvisberg <olekvi@…>

tcpdump from radconfig1

comment:7 Changed 9 years ago by matthijs

The networking team just applied the workaround again, so at least your router should be fine again. Can you confirm this?

I'll leave this ticket open until the real issue is fixed.

comment:8 Changed 9 years ago by anonymous

I'm writing this connected to my FON-public spot after removing my patch in the init script and restarting chillispot, so yes, everything is working on my router now.


comment:9 Changed 9 years ago by Ole Bendik Kvisberg <olekvi@…>

(and I'm mister anonymous ..:)

comment:10 Changed 8 years ago by steven@…

This bug has also been found on the Fonera Simpl :

comment:11 Changed 8 years ago by matthijs

This is something server-side that apparently also affects the SIMPL. The previously mentioned workaround has just been applied again, fixing the problem for 500-some routers.

comment:12 Changed 8 years ago by steven@…

These people also had to "reset" their device to make it remove the broken chilli config file. I read there is a difference between "reset" using the GUI and "reset" using the button on the back.

The latter will reboot the device and thus the wifi service & chillispot service will reinitialise with the changed settings.

the GUI reset will ... reinitialize the settings... but not restart the services with the new settings... perhaps a "reboot" button on the reset page would be welcome I've made a seperate ticket for this : a nice screenshot how it 's presented :

a Factory Defaults ... will still require a "reboot" ... the "OR" gives the people the wrong idea... also when they are checking the altered settings they "think" the device rebooted... it took me a few forum posts to actually convince them of... just "humor" me... reboot the damn device and ignore the fact everything seems "factory reset"... the wifi driver did NOT restart with the "factory reset" configuration :-)

comment:13 follow-up: Changed 8 years ago by anonymous

Hard reset worked for me on firmware and by hard reset i mean HOLDING the
RESET BUTTON on the BACK of the 2.0n for a FULL 30-35 secs

comment:14 in reply to: ↑ 13 Changed 8 years ago by anonymous

Replying to anonymous:

Hard reset worked for me on firmware and by hard reset i mean HOLDING the
RESET BUTTON on the BACK of the 2.0n for a FULL 30-35 secs

Works on firmware also.

comment:15 Changed 6 years ago by matthijs

  • Resolution set to fixed
  • Status changed from confirmed to closed

I suspect this problem has since been fixed on the Fon servers.

If anyone is still seeing this problem, please leave a comment here so we can investigate.

Add Comment

Modify Ticket

as closed The ticket will remain with no owner.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.