6416 Tor firmware suggestions

I am currently using a Gl.iNet 6416 with Tor firmware 1.3.

I have some questions, and suggestions for future development:

  1. I am having trouble connecting to the Tor network. Using the OpenWRT SSID works fine, but the Tor SSID or LAN port don’t connect to internet. Even after more than 10 minutes no connection with the Tor network seems to be established. Rebooting the router doesn’t seem to change anything. Yesterday it worked fine. Any ideas?

  2. I was wondering if there were any plans to include an option to use pre- and self-configured Tor bridges and pluggable transports via GUI in future updates. Tor Brower Bundle allows for this. Using naked Tor attracts a lot of unwanted attention. This is a major issue for anyone using Tor to avoid FVEY or consorts from looking all too closely.

  3. If I’m correct the router connects to the Tor network by one permanent circuit for all traffic. This seems to be a serious downgrade of the anonymity level. Using the Tor Browser Bundle and changing tabs frequently limits this damage somewhat (though at the expense of speed because traffic is routed through Tor twice) but this is not possible for all non-browser traffic. Is it at all possible to configure different circuits for different applications for example, and/or to configure the router so that it re-circuits its connection regularly? If not, are there plans to implement these options in future updates?

  4. It would be great if it would be more n00b-friendly to configure the router as a wifi repeater through Tor. I figure most people using this firmware to genuinely stay anonymous do not use a PORTAL device at home, where they can plug in their ethernet cable or configure one main router. You’d rather use it on the move, with a 3G-USB modem or - when it is impossible to acquire 3G cards anonymously - connecting to a lot of different public wifi networks. A GUI option that just requires a few clicks would be a huge advantage.

  5. Is it possible to provide a firmware download with OpenPGP signature for verification, to provide extra security?

I am asking/suggesting all of this because I am testing these routers to possibly serve as part of an easy to use foolproof security&anonymity package for an organisation I’m working for. For this reason it should not only address the above issues out-of-the-box but also be easy to use (basically quick setup to access public wifi through Tor + easy selection of bridges and/or pluggable transports). Your version of PORTAL comes closest to this setup but sadly I’m too much of an amateur to address the remaining issues myself.

In any case, thanks for the great hard- and firmware. Seems to do what it should and very promising for further development.


  1. It would be interesting to have an option to randomly spoof the routers MAC address at each boot (or, alternatively, automatically clone the connected device’s MAC). Since ISPs receive MAC info this kind of beats the effort to stay anonymous, which is after all the whole point of using Tor firmware.
  1. Sometimes the Tor process is killed for some reason. If you can ssh to the router to check if the process is live.

  2. We are working with some experts to develop a dedicated Tor firmware.

  3. Actually I don’t know if what you said is true or not. Doesn’t the tor routing change dynamically??

  4. Yes. This should be do in the dedicated tor firmware.

  5. Yes, if we publish dedicated Tor firmware with the expert.

  6. Yes. This is possible. Doesn’t this void IEEE, or FCC rules?

Wow, I did not expect that many positive responses, thanks :slight_smile:

To come back to you:

  1. I think that might indeed have been the problem, it’s up and running now so no problem anymore.

  2. I might have been mistaken yes - I’ll take a look at it by having it running for a couple of hours and see if it changes.

  3. As far as I know MAC spoofing does not violate any rules as long as you do not do so in order to commit a crime (e.g. identity theft). Many routers already have a MAC cloning option built in (but without the option to produce one randomly). As long as you do not do anything illegal it is a legitimate way to protect your privacy. In any case, if you decide to develop this, be sure the first 24 bits are chosen from existing (and ideally the most popular) OUIs. If not one might end up with an impossible MAC address which is even more suspicious. These forum discussions provide a good basis to work on: OpenWrt Forum Archive and OpenWrt Forum Archive . Let me know what you decide to do with this :slight_smile:


Any idea yet when that dedicated firmware should be ready for download?

Circuit per tab is not necessarily a feature - it depends on your tor use case. If you’re using gl-inet solely to prevent leaks this will improve anonymity. If you are using gl-inet to provide extra isolation in case someone hacks the machine that is connected to gl-inet, then circuit-per-tab defeats this purpose. Why? To be able to spawn circuit-per-tab torbrowser needs to have access to tor control port (which is quite a sensitive port, btw). So you need to expose the control port to the machine with torbrowser. If your machine has been pwned, the attacker can simply access the control port and expose you etc.

With this firmware it’s actually quite easy to enable this feature (circuit-per-tab), you just need some reconfiguration:

  1. You need to expose direct socks proxy port to tor lan network (on for wifi and for lan port). This is because torbrowser needs direct connection to tor socks proxy. I would enable this by default in tor firmware, since it’s really useful for other purposes like connecting via ssh to hidden services etc. In default setup iptables reroutes every packet to port 9040 - we need to make exception for port 9050 like this:

Goto p0rtal.lan -> luci -> network -> firewall -> Custom Rules tab and prepend those lines to the body of enable_transparent_tor() function:

iptables -t nat -A PREROUTING -i wlan0 -p tcp -d --dport 9050 -j RETURN

iptables -t nat -A PREROUTING -i eth1 -p tcp -d --dport 9050 -j RETURN

Save and reboot the router. This will make connecting to and possible. Now we need to configure tor to spawn a socks5 proxy to listen there. Open p0rtal.lan and goto “Editor”. Edit the /etc/tor/torrc file and add lines:

SocksPort 9050



Reboot (or if you have ssh access you can simply restart tor: /etc/init.d/tor stop && sleep 3 && /etc/init.d/tor start - sleep is helpfull, since sometimes tor stops slowly and newly spawned instance can’t bind to port).

Now you have direct access to tor socks5 proxy port. Let’s check if it works. Install torbrowser-bundle on linux (no idea how to make it behave on other OS’es - don’t use them if you want to be anonymous anyways :stuck_out_tongue_winking_eye: well, maybe bsd is ok, but win and osx, well ;)). Now we need to tell torbrowser not to start it’s own tor instance locally and instead use external socks5 proxy for operation. You need to pass additional environment vars to torbrowser-launcher, like this (note: if you’re using the wired connections make sure to pass as TOR_SOCKS_HOST):


If everything went smoothly torbrowser should start and connect the usual way. If you get connection refused errors you must have goofed up somewhere :stuck_out_tongue_winking_eye:

Now, this is still single-circuit connection, we need to perform the same thing for tor control port and add to iptables:

iptables -t nat -A PREROUTING -i wlan0 -p tcp -d --dport 9051 -j RETURN

iptables -t nat -A PREROUTING -i eth1 -p tcp -d --dport 9051 -j RETURN

Edit torrc config and add a lines:

ControlPort 9051



Restart tor and try torbrowser with additional env variables (add them to the command line I shown above):


Note: remove the TOR_SKIP_CONTROLPORTTEST - it tells torbrowser to… skip control port test (surprise, surprise!).

Note: this is suboptimal - you should add some authentication to tor control port, consult torrc or manpages (or google) for info how to add this. In my opinion the setup with exposed control port is less secure, but like I said - people have various use cases :wink: happy drug shopping or hacking or whatever your nefarious activities over tor are (let me guess… freedom fighting? ;P).

Cheers, Nobody.

Tor is killed by oom-killer - this setup has borderline memory (~5 mb free ram when tor is up and running), pity the SOC can’t handle 128MB, this would make tor experience much smoother. Nevertheless GL-INET is still awesome (best price to value ratio IMO).

Do you guys mind sharing the buildroot configs for tor firmware on Github? There are some nobodies that could review and contribue :wink:

EDIT: btw. on AR150 tor fw is much more stable (and even seems faster), no idea why.

Hi Roel,

Maybe this project is interesting for you:


The NetAidKit is a pocket size, USB powered router that connects everything to everything, designed specifically for non-technical users. The easy to use web interface will allow you to connect the NetAidKit to a wireless or wired network and share that connection with your other devices, such as a phone, laptop or tablet.

Once the NetAidKit is connected to a wireless or wired network, you can make it connect to a Virtual Private Network or the anonymising Tor network at the click of a button. Any devices connected to the NetAidKit will use these extra security features automatically, without needing to configure each of the devices separately.

The NetAidKit was designed for regular people and requires no technical expertise whatsoever to use.


@noboday, by saying on GL-AR150, Tor is stable, which router do you compare with?

GL-MT300A is with 128M RAM by default. Hope it works better.