RT or RT-N firmware on Asus RT-N16?

Discussion in 'Tomato Firmware' started by rs232, Sep 9, 2012.

  1. rs232

    rs232 Network Guru Member

    Let's see if I learn something new today.
    I've always been using the "RT" version of the firmware for the ASUS RT-N16, but according to shibby's routers compatibility page I could also use the "RT-N". Is this correct?

    What would it be the difference between the two version? Drivers?

  2. mstombs

    mstombs Network Guru Member

    I believe this is correct, Asus original firmware seems to be very similar for the 2 devices, same source just different compile switches. The RT-N has different drivers, perhaps newer but since the RT-N16 can't use the 5GHz dual band probably littlle advantage. The RT-N drivers are much bigger so are not recommended for other RT routers, but the N16 has plenty of flash/ram so this doesn't seem to be an issue for it.
  3. Python46

    Python46 Networkin' Nut Member

    I have used both RT and RT-N versions on my RT-N16 and have found that they both work quite well. About the only functional differences that I have found other than the size of the drivers is that I seem to get a little better throughput, not connect speed, from the RT-N version. Just my two cents worth. ;)
  4. koitsu

    koitsu Network Guru Member

    The only difference between the RT and RT-N versions is a different wireless driver. If you experience throughput problems or anomalies with wifi using RT-N, and the issues go away when switching to RT, please report them in a separate thread.

    I personally use an RT-N16 with the RT-N firmware (specifically tomato-K26USB-1.28.00500.2MIPSR2Toastman-RT-N-VPN.trx) with great success. The only wifi-related adjustment I do is increase the output power from the stock default of 14mW to 100mW.
  5. Elfew

    Elfew Network Guru Member

    Koitsu - what about: set Singapoure and output power to 0... just try! It gives me the best performance and throughput
  6. koitsu

    koitsu Network Guru Member

    Specifically talking about the RT-N16 H/W revision A0 running the firmware version I listed in my previous post:

    Setting output power to 0 does nothing; the next time you go back to the GUI page (or the next time you reboot -- I forget), the value goes back to 14. There is an entirely separate thread on this forum, and it's very long + detailed, describing how the "value of 0 for factory default" is actually a complete misnomer as it varies heavily per wifi chip model, hardware revision of that chip, and driver. After a few weeks of reading I found that a value of 100 was acceptable/permitted (meaning it's not absurdly high and won't upset the FCC if you live in the US), or a value of 75 is also okay.

    Setting country to Singapore, for me, also does absolutely nothing. It does not increase or decrease my throughput, change my noise floor base, or increase or decrease signal strength. Because I live in the United States, I change this value to UNITED STATES. Let's be honest here: the only entity which knows what that wifi driver variable actually does internally is Broadcom: period. It's undocumented. If I had to take a stab at it? I would say it defines what channel frequencies are available in the Channel pulldown under Basic -> Network -> Wireless. Because as I understand it, different countries have different frequency ranges which are permitted for 802.11 traffic. My justification comes from the output of the wl command, which is what controls the underlying wireless driver by Broadcom:

    Return valid channels for the country specified.
    Arg 1 is the country abbreviation
    Arg 2 is the band(a or b)

    Select Country Code for driver operational region
    For simple country setting: wl country <country>
    Where <country> is either a long name or country code from ISO 3166; for example "Germany" or "DE"

    For a specific built-in country definition: wl country <built-in> [<advertised-country>]
    Where <built-in> is a country country code followed by '/' and regulatory revision number.
    For example, "US/3".
    And where <advertised-country> is either a long name or country code from ISO 3166.
    If <advertised-country> is omitted, it will be the same as the built-in country code.

    Use 'wl country list [band(a or b)]' for the list of supported countries

    And here's proof:

    root@gw:/tmp/home/root# wl country list
    root@gw:/tmp/home/root# wl channels_in_country US b
    1 2 3 4 5 6 7 8 9 10 11
    root@gw:/tmp/home/root# wl channels_in_country SG b
    1 2 3 4 5 6 7 8 9 10 11 12 13

    That's the only difference *I* can see between US and Singapore as far as what that GUI option does. SG gets you channels 12 and 13 available (I forget what frequencies those are). Whoop dee doo. Maybe you can use channels 12 or 13 if you have a lot of noise on the common US channels (which I think are 1, 2, 9, and 11?), or there are too many surrounding APs using those existing channels. But then again I wouldn't expect a wifi client to necessarily work with channels 12 and 13, if the client device is sold in the US. Anyway you get my point.

    I ran into this exact situation a month ago helping my neighbour set up his router -- he moved here from Japan, and wireless worked like crap for him. Turns out he was using frequency ranges which generally are used for other things within the US, thus other devices/crap was stomping all over his wireless. Changing his setting to UNITED STATES fixed the problem.

    Anyway, regardless, it's speculation on my part because as I said above, the only entity that knows the truth is Broadcom. The sooner they open the driver code to the public the better -- then someone can actually read it and see what it truly controls. I'm just grasping at straws.

    Furthermore, this is completely outside the topic of the thread.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice