1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

no wifi with android and tomato

Discussion in 'Tomato Firmware' started by Projectoras, Jul 25, 2013.

  1. Projectoras

    Projectoras Serious Server Member

    Hello to all!
    I have a 3500L v1 router with Tomato Firmware v1.28.7481 MIPSR2Sandwich K26 USB VPN-NOCAT (Toastman's build). The problem I am facing is that I cannot connect my android tablet through wifi. The tablet can see the ssid but it doesn't connect.I tried to change the channels,security and encryption from router settings,but still no luck. Also in the past I managed to connect devices like laptop,iphone with wifi, but I could never connect an android device (I tried 2 tablets and 1 android phone).
    Any ideas?
    Thank you in advance!
     
  2. leandroong

    leandroong Addicted to LI Member

    Probably, MAC filter is enabled.
     
  3. Marcel Tunks

    Marcel Tunks Networkin' Nut Member

    I've heard other people complain about this with HTC devices. Planning to investigate one instance this weekend. No MAC filter, other Android and windows based devices connecting fine. Suspect it's a setting issue on the client...
     
  4. leandroong

    leandroong Addicted to LI Member

    For addl info, Shibby FW v110, Iphone 3Gs and SGTAB2-GTP3113 connected w/out any issues.
     
  5. Projectoras

    Projectoras Serious Server Member

    Thank you for your help!
    I don't have mac filter and all other devices can easily connect.The problem is android os. I don't know what else to try...
     
  6. koitsu

    koitsu Network Guru Member

    I'd recommend sticking with no MAC filter and no encryption. If it works, great. Next: keep MAC filter disabled, and enable WEP 64, see if that works. If so, try WEP 128, see if that works. If so, move to WPA Personal (AES please, don't bother with TKIP) and see if that works. If so, move to WPA2 Personal (again AES) and see if that works. Also worth taking note of what the wireless client's MAC address is on the router (I have on occasion seen devices which claim their MAC is xxx but what a remote device sees is xxx+1, and this has to do with the device having two MACs and the manufacturer printing the wrong one on the label :p).

    Basically the approach is to take one step at a time and see if you can figure out where the problem starts. Once you figure that out, make note of it, use the last-working method, and enable MAC filter (if desired) and see if that's where issues begin.

    P.S. -- I run tomato-K26USB-1.28.0502.8MIPSR2Toastman-RT-N-Ext.trx on my RT-N16 and my girlfriend's Android-based phone has no problem using my wireless connection (WPA2 Personal + AES + no MAC filter).
     
  7. leandroong

    leandroong Addicted to LI Member

    Well, my samging galaxy tab2 is connected, which is an android OS. I suggest that you try Shibby FW.
    My wifi security is WPA2, AES, no broadcast
     
  8. Monk E. Boy

    Monk E. Boy Network Guru Member

    Oops, nevermind... though if broadcasts are disabled on his router, enabling them would be a good first step.
     
  9. Projectoras

    Projectoras Serious Server Member

    After many experiments with encryption the problem solved.It wasn't the encryption but the ssid: I had written a name with the copyright symbol © and android could not recognize it...:D
    I would like to thank you all for your suggestions!
     
  10. koitsu

    koitsu Network Guru Member

    Interesting. I just got done skimming the 802.11 IEEE specification (circa 2007), and no where in the specification does it define actual character set limitations used by the SSID/BSSID itself -- the term they use repeatedly is "octet string", but they never actually define what that means. Another wonderful example of crappy specifications... :)

    Anyway, Cisco and some other vendors require the SSID be made up of ASCII characters (e.g. each byte must be between 0x20 and 0x7e); "extended" ASCII characters (including letters like Swedish ö, or French ÿ) are therefore not permitted to be entered on those APs. Likewise, DD-WRT actually limits the range to 0x20-0x7e as well (supposedly it will pop up an error saying "SSID have illegal ascii code" if you try to enter in other ranges).

    Symbols like the copyright symbol © can/will also vary in their encoding; that could be written in UTF-8, UTF-16, or possibly some other code page (CP437 comes to mind but it doesn't have it -- just using it as an example) -- I'm not going to examine every code page/locale on this planet to see which have support for this outside of Unicode.

    So while the official standard is vague to the point of being stupid, the bottom line is that to remain fully compatible with all devices (both APs and clients alike), only use ASCII characters in your SSID, otherwise you're asking for trouble. Do not use extended ASCII or any other encoding.
     
  11. Elfew

    Elfew Addicted to LI Member

    So, it would be good limit ssid name in Tomato too, am I right?!
     
  12. koitsu

    koitsu Network Guru Member

    It's too late to do anything about it in Tomato, if you ask me. There are absolutely people out there who have non-ASCII characters in their SSIDs -- they probably don't even reside or exist on this forum -- so by changing the permitted semantics at this point, you would be breaking their wireless configuration/setup, and they wouldn't know until manually hooking up an Ethernet cable, visiting the GUI, and hoping that something in the GUI would tell them "Your wireless SSID doesn't conform with what we feel is best". Then they would probably show up on this forum complaining about the change, how they had to hook up an Ethernet cable just to find out about that, etc...

    A similar situation/example with Tomato is the storage of the authentication password to log into the web GUI, stored in NVRAM variable http_passwd. People here mentioned they wanted it encrypted, because DD-WRT does it, and the approach was "change the code to encrypt it -- done". Except there's no way to declare if the string in http_passwd is already encrypted or not, so there's effectively no way to "cleanly" upgrade to an encrypted string; likewise if the person needed to roll back to an earlier firmware they'd have a GUI they could no longer log into (unless they happened to know what the DES/MD5 hash/string was itself, e.g. "your password isn't abc123 any more, it's 36a29ee5d16a6d4cfa1e6a66bb97e8d6"). The only solution that was proposed would be to use two NVRAM variables, and while the idea initially appears sound, but you can see there's concern over the model as well. All of this is discussed in that thread, and it went no where (as expected). I should note that I do support the idea of storing the password encrypted, but there is no "clean" upgrade path that also "cleanly" supports rollback.
     
  13. Elfew

    Elfew Addicted to LI Member

    Ssid problem should be solved, at least add note into gui under ssid box... It is a minimum change
     
  14. koitsu

    koitsu Network Guru Member

    Adding a note to the right of the SSID input box is about the only thing one could do that retains existing compatibility/doesn't break anything.

    Text that reads "(for compatibility with all devices, use only ASCII characters!)" should suffice.
     
    Elfew likes this.
  15. koitsu

    koitsu Network Guru Member

    Below is an attachment (git diff) that implements exactly what I said (with a slight wording change for width reasons); a simple 1-line change. This is against branch Toastman-RT-N, but can probably to Shibby et al as well. Warning: I have not tested this change, but it should work given existing/example code.
     

    Attached Files:

    Toastman, Monk E. Boy and Elfew like this.
  16. Elfew

    Elfew Addicted to LI Member

    Thank you!
     

Share This Page