Hardware: WRT54GL
Coova Firmware: CoovaAP Firmware v1.0 beta.2
I really like your easy to use hotspot firmware but I am having a very strange bug that I need some help with. I get a whole bunch of log entries in my radius log that look like this.
Thu Nov 9 17:12:38 2006 : Auth: Login incorrect: [username/s\312\307\210\232{T\205q](}\233LI\\] (from client locationname 4 cli XX-XX-XX-XX-XX-XX)
I get this using the original hotspotlogin.cgi, a version rewritten with custom HTML and a version I wrote in PHP. All three UAM server login scripts produce the same results.
The odd thing is the userurl seems to change when this happens. For example, my home page is google. I open the browser and everything looks fine in the querystring, the userurl is still google. I try to login and it fails creating a log entry like the one above. The interesting thing is the userurl is now something comepletely different, in my case it became a toshiba phone home URL that my laptop sends to check for driver updates. When I logged in the second time it works but I am sent
In another example a user I was helping failed and created a log entry like above and then the second login works but they are taken to a windows update download of a .cab file.
I have verified by writing to a log file that the users are typing in the correct login and password.
On a side note I have reconfigured one of my other test routers to use openwrt whiterussion RC6 and installed the chill package from from the openwrt repository and it does not seem to have the same problem.
Any ideas?
I really want to use the coova AP firmware because it is so easy to setup the chillispot software and to backup the settings unlike the standard openwrt whiterussian RC6 with the chilli package installed. It also does not have the chilli-query feature which is extremely nice. I eagerly await a reply and hopefully you will have some insight into this problem. So far nobody on the chillispot forums has responded to my pleas for assisatance.
Re: Strange bug
I tried in vain last night to create an ipkg from the SVN version. I was unable to create the ipkg, not sure what I am doing wrong. I got it to compile on my gentoo linux server but this is not where I need it installed.
Re: Strange bug
Yeah, I was... and it should behave better in the next version. That will be coming out here soon. In the meantime, you are welcome to test the svn version.
Re: Strange bug
Any chance you were able to reproduce this error? I am needing to find a solution to this problem as soon as possible and I am hoping that the newer version of the coova firmware and coova chilli that you mentioned was coming soon in another post will fix my problem. I would be willing to beta test this if you have a newer ipkg I can install or beta firmware.
As it stands right now the coova firmware is unusable by me due to this problem. I don't seem to have this problem when running the chilli daemon from the official openwrt package. It does not appear that the openwrt version does not contain the chilli_query functionality which I find very usefull for troubleshooting connections. So it's a trade-off, a more stable chilli daemon with no reporting which is very difficult to troubleshoot or a quirky coova chilli daemon with the very nice hotspot status functionality. So far I have leaned towards the coova chilli despite it's problems for me.
Re: Strange bug
The radius shared secret is good because it works sometimes and for some users they never get a problem. In the past when the radius secret is incorrect I get an error that the client is unknown.
I think it has to be a problem with the challenge being reset. If you need access to one of my routers and my radius server i'm sure that could be arranged.
Re: Strange bug
hmm... that sort of error in the radius log usually means a bad radius shared secret. regarding the switching of your initial request url, that is not uncommon as it is sometimes hard to know what URL is "user selected" and which are caused by other programs sending http requests for updates, etc.
a possibility is that your session's "challenge" is being reset by those non-user requests (while the user is trying to log in). I will take a look and try to reproduce it.