Home › Forums › Open-Source Software › CoovaChilli Development

Nanostation2 with CoovaChilli firmware reboots to defaults if chilli auto start is enabled

Sat, 01/02/2010 - 18:53 — mother

Hi all,

I'm having a BIG problem with getting a couple of Nanostation2 to work in a captive portal environment. Aside from compilation issues which I resolved, I now find that if I check the 'Start on boot' checkbox, the router reboots back to all its default configuration values, including the IP back to 192.168.1.20, etc. There is NO way I can expect my client to manually start coova-chilli every time the router reboots, does anyone have any suggestions to fix this? I have to deliver the routers on Monday, so this is pretty urgent.

Cheers,

Mike

‹ Coova-chilli 1.2.0 svn271 debug mode chilli_radconfig use ›
Sat, 01/02/2010 - 19:43 — david

I wouldn't exactly call it

I wouldn't exactly call it Coova firmware; rather it is coovachilli enabled UBNT SDK firmware. From the ubnt.com forums, it seems the SDK images do not create the configuration partition and you should always TFTP the original firmware and then upgrade to an SDK version using the web ui.

Sat, 01/02/2010 - 21:55 — mother

David, agreed, it was a case

David, agreed, it was a case of semantics, it's UBNT firmware with the coovachilli add-on compiled in. Do you mean that every time a new custom image from the SDK is uploaded, -first- one has to TFTP the original firmware? What I did was update from the original firmware as it came with the NS2, through the web interface, to the one I compiled. I then made a couple of changes to the redirect HTML (it looks tiny on iPhone/iPod, so I'm trying to detect that using JS and applying webkit CSS tags), re-compiled, and uploaded via TFTP. So, I went Original -> Custom as-is (via web) -> Custom with changes (via TFTP). Can you point me to the UBNT forum topics dealing with this?

Regards, and thanks,

Mike

Sat, 01/02/2010 - 22:14 — david

I believe this thread,

I believe this thread, http://www.ubnt.com/forum/showthread.php?t=1893 though I don't instantly see which posting it was... the issue, I believe, was with your tftp of the custom firmware. From my understanding, the tftp method reformats the mtd and the bin must create all partitions - the SDK image does not do this. If you only upgrade the custom image using the web interface, you are fine.

Sun, 01/03/2010 - 04:32 — mother

Thanks for that link. It

Thanks for that link. It seems the problem is linked to the configuration of memory boundaries, and the fix for v3.5 SDK is not yet clear. So far, I have been able to recover to a working state by flashing the original UBNT firmware to the NS2 via TFTP, which created the cfg area correctly. I then flashed the custom FW via browser, and it maintained the cfg area correctly after flash & reboot.

Now, when I tried to enable 'Start on boot' again, the NS2 became totally unresponsive. By that I mean that it didn't start wireless (no SSID was being broadcast at all), and LAN was not responding, neither on the default IP nor the one I had configured it on. After flashing the original firmware over TFTP again, it's strange that it maintained the modified networking settings.

Flashing the custom FW via browser again turned the NS2 into a 'brick' once more. Finally, I re-flashed original, and reset to factory via browser, and then flashed again the custom FW, which now loads OK. I have not dared try the 'Start on boot' again, and I'm thinking about writing a cron-fired PHP script on the RADIUS server which grabs the services.cgi page via curl, checks if Hotspot is running, and if not, gets the 'Start' URL. It's very very dirty, but it may work while a solution to this mess is found.

Cheers,

Mike