Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

wifi redirected login page "The address isn't valid"

  • 9 replies
  • 7 have this problem
  • Last reply by hupili

more options

I just got the latest ZTE Open, with FFOS_V1.0.0B02 . There are several wifi SSIDs in my university operate like this: first connect to AP without authentication; visit any web page; get redirected to the web login page; after authentication, can communicate with other sites. It turns out none of them works. Firefox complains "The address isn't valid" when get redirected. My other devices work find with those SSIDs.

Also note that 802.1x is not supported yet.

Get wifi connection is the first thing to do. Then I can try update the system and install apps. It's frustrating to get stuck at the very beginning. Please advise what should I try...

All Replies (9)

more options

hello hupili, can you navigate to the authentication page of that university network (that is shown on other devices) by typing in that address on firefox os manually or by creating a bookmark for future use?

there is active development ongoing in order to implement support for WPA enterprise - this should land in firefox os version 1.3.
for a related question also see

more options

philipp, thanks for the advise.

The authentication URL looks like the following on other devices:


My FFOS can get the right (at least looks similar) URL. Only differences are the port, challenge, etc. FFOS complains to the above URL that "The address isn't valid".

more options

hm, the address looks well-formed so i'm not sure why this would fail. i don't have a firefox os device myself where i can test it, maybe there is a general issue with urls like http://address:port? is this site loading normally on your phone:

more options

I can open the metalib4 URL on FFOS.

Could it be the problem of URL too long?

more options

Try forgetting the network and reconnecting. Also, try navigating to

You may get the word success the first you visit but try refreshing - also, do you have a strong Wi-Fi connection when you are connected to the network?

more options

feer56, thanks for the suggestion.

Just tried forgetting the network and reconnect. It results in the same problem.

I'm in a position with strong wi-fi signal. My other devices can connect and show full signal strength.

For , I'm not clear what it does. Here's the test results:

  * Without 3G, only wifi physically connected to an AP. When visit that page, it redirects to the "https://192.168.xx.xx:4990/www/login.chi?xxxx" one shown above. 
  * With 3G, disable wifi. I can get "success" when first visiting that page and after refreshing.
more options

BTW, that wifi I'm testing uses coova .

more options

If you can talk to the admin of the network there is comment in the bug below that might be start to allow a WPA Supplicant config:[]

Please keep track of that for the integration of that into the product, more feedback on it the better.

This is the link to the error codes when trying to connect with the long url []

This is a test to see if it is the length of the url, it worked for me, but not sure if it varies[]

Modified by guigs

more options

sorry, I can not follow the above tips at present. I'll try to come back later.

Here's a test at the same place with a wifi using

Other devices can reach the authentication page with one minor glitch complaining the HTTPS certificate is invalid. On FFOS:


Try to type anything in the address bar. Firefox composes a Google search URL and following is the response:

   XML Parsing Error: no element found
   Location: about:blank
   Line Number 1, Column 1:


Refresh the page, still the above result


Try to type something else in the address bar. Firefox composes another Google search URL and following is the response:

"The address isn't valid"

When it complains, the address bar shows the Google search URL, which is apparently valid. Observing this, I guess the original problem may be:

  * The URL ("address"?) is actually valid
  * The response contains something FF can not parse