My Router Runs Linux
April 25, 2013 at 1:11 PM #582
Interesting discovery the other day. I was trying to configure some settings on my home wifi router, a Netgear WPN824N, when someone in a forum mentioned being able to change a setting using the iptables command through telnet (telnet is for remote command line access and iptables controls the Linux firewall). I knew that a few home routers used Linux internally but I was under the impression most didn’t because their hardware specs where too low. Besides I couldn’t imagine a consumer router providing telnet access. Well sure enough I checked and telnet appeared to be running on my router but any attempt to connect and the connection was immediately closed. I search further online and it appeared I needed to use a Netgear utility which sends a “magic” telnet packet to the router which enables telnet access. Since the Netgear tool is only for Windows I found this site which has reverse engineered versions of the tool. I decided to try the python version. Amazingly it worked, I was suddenly staring at a root prompt for my router. I explored the device for a few minutes and was amazed how much it appeared to rely on free software. HostAP was running (Linux tool for creating an wireless access point). The wifi and internal ethernet devices were bridged using the same tools I was used to using on other Linux machines. I even found scripts indicating that much of the software came from the DD-WRT project. DD-WRT is an open-source replacement firmware for many consumer routers. It appears DD-WRT did such a good job that the manufacturers are now designing their factory firmware based on it. Finally I used an iptables command and enabled the feature I was looking for. Unfortunately any manually entered firewall rules seem to be overwritten every couple minutes. Also, the filesystem is squashfs (compressed, read-only) so any changes will require me to prepare a completely new copy of the filesystem. Still, cool to know this level of openness is there for anyone who wants to take advantage of it.
April 25, 2013 at 4:29 PM #585
- This topic was modified 4 years, 10 months ago by Christian.
Nice stuff, Christian. Thanks!April 25, 2013 at 9:19 PM #590
Just be aware that when you enable that telnet access, it is available to both the LAN side and the WAN side of the router. At least one Netgear router I used did that. That means the bad boys can have fun with your system, should they stumble across it.
I like to run my internet connection in “stealth” mode as much as possible. Just the fact you have an open port on the WAN side will invite all kinds of abuse.April 25, 2013 at 10:48 PM #591
Believe me HotDawg, that was first on my mind. Several posts I read said it would only be on the LAN side. As soon as I gained access I quickly checked and couldn’t access it from the WAN side.
The telnet interface isn’t very useful on the WPN824N. People with other consumer Netgear routers were complaining that their settings wouldn’t survive a reboot. Mine only lasted minutes! I think I found the script that “refreshes” the firewall. I could add my firewall rules there except the system has no editor. I’d have to do something fancy with splitting the file in order to add a line.
The reason I was messing with all this was my new apartment doesn’t have phone jacks where I need them to be. My desktop, server and voip gateway need to go on one side of the room but the AT&T modem needs to be plugged into the phone jack on the other side. I can’t run a wire between them so I added a wifi card to the server. I’ve been messing with two options. What it looks like I’ll be doing will be bridging the server’s wireless and wired cards in order to provide access to the wired clients on that side. What I was hoping to do was simply route from the wired subnet to the wireless. That worked fine internally but the wired machines couldn’t get internet access. Using telnet I was able to verify the subnet that the router is on is the only one getting NATed. Packets from the wired subnet pass right through to the WAN and since they’re private IPs I don’t expect they’ll be coming back anytime soon. Using telnet I was able to fix this temporarily and watched with amazement as the whole system worked the way I wanted it too. Unfortunately that was short lived. Now I need to look into creating the bridge. Wish me luck.April 26, 2013 at 12:56 AM #592
OK. Glad you didn’t have that telnet access open to the world 🙂
If I understand it correctly, you are using the server really as a second router to do NAT between the wired side and the wireless? If so, that may be your problem. You really want everything to be running on one subnet, so so the WPN824N can do it’s job on the NAT. I don’t know what OS you run on the server, but certainly if Linux, you should be able to bridge the two ethernet cards (wired and wireless) together. If you have to do some type of NAT in the server, then maybe have your two subnets adjacent to each other, and open the router up to include both in one subnet? (Just thinking on this.)
I ended up getting some of the powerline ethernet adapters here, for a different reason — but a pair of those would connect the router over to the other side of the room. Then a switch (or hub) could fan that out for what you need to connect. The ones I got were by TrendNet, and when Newegg has them on sale they usually run about $40 for a pair. I know there are other brands out there also, but can’t speak for how well they work.
If your server is running Windoze, have you looked at their internet sharing function? That might do what you are looking for, but then again it might give you the problems you have now.
And (finally) when you telnet into the WPN824N, can you mount an external drive or folder using NFS? Then you could modify files outside the router using the editor of your choice.April 26, 2013 at 2:50 AM #594
At first I had the [Linux] server configured without NAT. This was nice as I could easily communicate between subnets. However I did end up adding SNAT so I could get internet access from my desktop on the wired network.
I’ve found that most docs showing a wired-wireless bridge assume that the ethernet card connects to upstream and so the wireless card is acting as an access point. Since I’m trying to do the opposite, it makes things more difficult. Here’s someone who’s trying to do the same thing as me. Note that no solution is offered.
One question I have is what mode should the wireless card be in? I initially tried managed (client) mode since this is what works without the bridge. It might still be the right way but I don’t know things need to look in /etc/network/interfaces. Using master (AP) mode is wrong since I’m trying to connect to an AP. WDS looks promising. So does something called 4addr.
Good tip about using NFS to edit files. That might be available. I have a feeling the filesystem is read-only though. I’m sure I could modify the router if needed and I might mess with it some day just for fun but for now having a single internal subnet seems like it will be the simpler solution.
I’m in no rush. While double NATing isn’t ideal, it’s working well enough for now.April 26, 2013 at 1:19 PM #600
Well, it’s been awhile since I played with something similar. I think in Linux, you could probably set both the wired and wireless cards to promiscuous mode, and let them just echo what they hear out the other one. I will take a look at the link you provided and see what it offers.
I’m not sure if your WPN824N can operate in adhoc mode. I looked at my WNDR3400 and didn’t see any provision for that. Another area you might look at in your router is setting up a static route, so everything on your LAN is dumped out to your ISP (the gateway address address).
Is WRT-DD available for your router? If so, so might try loading that up and you could set your forwarding rules like you want there.April 28, 2013 at 3:34 AM #633
OK. I got the bridge working and learned way more than I ever wanted to about wifi.
The wifi specs define up to 4 mac address fields to identify the wireless transmitter, wireless receiver, plus the sender and destination. For the common case involving an access point and multiple clients, only 3 of the four fields are needed since the wireless receiver and destination are the same. To get bridging to work requires a wifi card which supports 4-address mode. My new Atheros-based card just happened to support it. Here’s the procedure I used.
First, I had to “recreate” the device because it was the only example I could find of setting “4addr on”. Using “iw” is new to me so I’m hoping I’ll figure out the syntax that lets me set 4addr on an existing device.
iw phy phy0 interface del wlan0 iw phy phy0 interface add wlan0 type managed 4addr on
Then I invoked wpa_supplicant with the “-b br0 option” to support bridging.
wpa_supplicant -D wext -b br0 -c /etc/wpa_supplicant.conf -i wlan0
Now I’m associated to the access point but neither wlan0 or eth0 should have an IP address at this point.
Next I added wlan0 to my existing bridge.
brctl addif br0 wlan0
Now adding eth0,
brctl addif br0 eth0
Even though most docs say the br0 will have the mac address of the first device added, for some reason it switches when adding eth0 so I have to manually change it back,
ifconfig br0 hw ether <mac of wlan0>
Now I configure my IP address on br0. At this point I can ping the router and google but I’m not quite done. There’s still a limitation of my Netgear access point. As described here, it will not accept traffic with a mac address other than that of the associated wifi card. I used the ebtables solution described on that page and suddenly my wired desktop can connect through the bridge on the server.
It’s probably not a true bridge because ebtables is performing some kind of layer 2 NATing but I’m able to connect from a wireless computer to my wired desktop without needing to setup port forwarding so I think it’s a little better than a layer 3 NAT setup.
Even though I tested it, I’m still not sure if everything is correct. I continue to receive kernel messages such as “wlan0: received packet with own address as source address”. I have a feeling upgrading the kernal might suppress these.
Now I just need to work on getting this automated with “ifup”. If I discover something seriously wrong such as this causing my wifi card to overheat and catch on fire, I’ll let you know.April 28, 2013 at 7:33 PM #658
Many thanks! What a wealth of information. I am on the verge of getting into something sort of similar. A Linux box (Slackware 12.1), connected back via wireless, and a MS-DOS machine slaved off the Linux box. Both of these will be running headless. I certainly will be keeping your information in mind!
You must be logged in to reply to this topic.