WRT54G with WL in and Local ports out..

Using Google look for "Wireless Bridge" without quotes.

fundamentalism, fundamentally wrong.

Reply to
Rico
Loading thread data ...

Hi,

In my house I have a WRT54G router and I wonder if my neighbour can purchase another WRT54G and have it connect to my WRT wirelessly? Normally the WRT has a wired LAN port as 'input' (internet) and WL ans Local ports as 'outputs' but in this case I need it to be the contrary (WL in) and the 4 local LAN ports as output for the local net.

Is this possible with this device. If yes, how do I do this...?

best regards

Tor

Reply to
Tor Tveitane

All ports are both in and out. The ports are: LAN== Local Area Network WLAN== Wireless Local Area Network WAN== Wide Area Network

Reply to
Teddybare

Yes, sorta. The WRT54G supports WDS (wireless distribution service) which will allow it to simultaneously act as an access point (for local clients) and a transparent bridge (for your neighbors connections). He can plug a PC directly into the LAN ports on his WRT54G and get connectivity to your WRT54G. His WAN port is not connected to anything. The only possible problem is that wireless thruput, for his wireless clients will be cut in half by the store and forward (simplex) nature of the WDS repeater.

Please do me a favour and do NOT rename the function of the ports. They are the WAN (wide area network) and the LAN (local area network) ports. Trying to figure out which is "in" or "out" at any given time in any given topology, will surely cause frustration and possibly premature balding.

formatting link
(10 pages)

Reply to
Jeff Liebermann

That can get (very) complex, but yes it can be done. You'll need to install third party firmware (Sveasoft or HyperWRT), which allows telneting into the router and changing configuration in ways not available via the web interface. The wrt54g is a little Linux box, which means it has horrendous flexibility. Of course learning how to use it is another thing... :-)

What you want to do can be done in at least two ways. If you set up subnetting with your local wired LAN on one subnet, your wireless LAN on another, *and* your neighbors similar networks assigned to even different subnets, then what you want to do can be accomplished strictly with routing on the two wrt54g units.

The trick to it is routing certain subnets to the WAN port as opposed to the LAN/Wireless ports (i.e., if your LAN is all

192.168.0.x, you mask off 192.168.0.x and route everything through the neighbor's wrt54g to the WAN port instead of the LAN ports). It requires that 1) you be the only one with admin access to the router, and 2) his network not use any 192.168.0.x addresses via the wrt54g.

If for some reason you cannot assign such networks, if you cannot trust the neighbor not to hack the wrt54g (relatively easily done with physical access), or if you just want a more technically interesting solution... The actual equipment inside the wrt54G consists of a linux system with two ethernet interfaces, one of which is connected to the WAN and one of which is connected to a bridge through a switch that supports vlan's. Out of the box anything sent to the wireless also goes to all of the LAN wired ports, and the Linux firewall software only affects packets forwarded between the LAN/Wireless ports and the WAN port. That can all be reconfigured.

It is possible to establish a vlan for each individual port plus the wireless, and use the firewall to segregate traffic between any of them, all based on any level of complexity you are willing to conjure up!

I'm not sure that even the routing solution is trivial enough to learn if Unix systems administration isn't something you are already familiar with (it's one that I've actually done), and I'm positive that reconfiguring the internal hardware is only for the most intrepid hardware hackers (I've read about how it works and understand it, but haven't tried doing anything serious even though I'm doing several other things that also required figuring out how to change nvram and make use of what is there).

If you want to try either method, I'll be happy to provide some URL's with good information and provide a few pointers that will get you at least started in the right direction.

Reply to
Floyd L. Davidson

But taking advantage of that is the only thing that *does* make it easy! Route all of the wireless traffic for a subnet you want to protect to the WAN port... and it is bannished for

*your* LAN!

You should have also tried what I'd described to you earlier, using routing. It works rather well, and actually is simple. Or at least for somebody who is comfortable doing Unix systems admin, and can figure out how to make such routing persistent across restarts and power failures on the WRT54G, neither of which are necessarily easy skills to acquire over a weekend.

Reply to
Floyd L. Davidson

"Jeff Liebermann" skrev i melding news: snipped-for-privacy@4ax.com...

OK, good news thanks ;-)

I promise. Sorry about that :-|

Now a second question: I also use windows filesharing on my wlan. Does it exist a way with the WRT to block windows filesharing information ports from certain MAC or IP addresses so my neighbours don't even see any of mine computer shares or printers when opening network neighborhood in Windows...?

regards

Tor

Reply to
Tor Tveitane

Floyd Davidson answered the question in detail. My turn to try a simple explanation of why it can't be (easily) done. (It's usually the other way around, where I deliver the overly complex and obfuscated answers).

WDS and all wireless is bridging. Bridging is ISO layer 2 protocol. The wireless bridges know nothing about IP addresses, which is on ISO layer 3. To do layer 3 filtering, blocking, routing, and such by IP address, you need a router. The problem is that the router in your neighbors WDS wireless bridge is not in the circuit. Because the WAN port is not used, there's no path for the router to do its thing.

However, methinks there be an easier way. The stock Linksys firmware has a feature they call "AP Isolation". It's on the bottom of the advanced wireless settings page. It really should be called "Client Isolation". What it does is prevent *ANY* packets from going between wireless clients. I use it in my neighborhood WLAN to keep the peer-to-peer game networks under control.

See:

formatting link
my latest rant on the topic.

The problem is that I have no clue what this will do in a WDS environment. I also haven't bothered to see if it will isolate the wireless clients from the wired clients. It will also probably prevent you from using your own wireless Windoze networking LAN. I can probably test it for you, but I plan to spend my weekend under the hood of my truck doing repairs instead.

Well, so much for simple...

Reply to
Jeff Liebermann

I did. Read the above URL. I tried it and it worked as you described. It would properly route IP traffic. However, the original problem was different. It was to isolate wireless customers at a coffee-shop or hotel wireless LAN. The "AP protection" setting in the stock Linksys firmware took care of that without any routing.

The problem I was faced with (different issue) is that routing wouldn't do anything for non-IP wireless traffic. I was dealing with a bunch of gamers running NETBEUI over IP that the IP router didn't touch. They could care less if they went to the internet with their traffic. All they wanted was to connect to each other using the WRT54G as their private repeater. My available wireless bandwidth was zero when they were on.

Chuckle. Be nice. Do a search on the web and usenet for my name and SCO Unix, especially in comp.unix.sco.misc. Google groups shows 3500 of my postings, almost all answers to tech questions, starting about

1985 with Xenix 2.0. There's even some Unix humor. Methinks that qualifies as more than a weekends worth of study. I also edited an awful SCO Unix book (never again). I haven't done much with SCO Unix since they became politically incorrect.

I'll confess that I'm not terribly proficient with iptables, but can do well enough with the older ipchains (or if I can remember ipfwadm). I've been really lazy these days and use Firewall Builder. Most of my current remote office systems use VPN's which avoid many routing issues. I'm also marginally functional with Cisco IOS from the command line. As for admin skill, I've done quite a bit in the past with assorted SNMP tools (MRTG, RRDTool, Nagios, OpenNMS, etc) in setting up monitoring at ISP's and corporate LAN's. I'm not sure that counts as admin experience. I haven't done much of that in the last 5 years. For a nominal fee, I'll send you an autographed copy of my resume (after I write one), suitable for framing.

You're correct about one item. I didn't or couldn't figure out how to make the routes persistent. Probably by editing rc_startup. I wanted to tinker and didn't want to deal with undoing my mistakes. It's the same way with Cisco. I don't run: copy running_config to startup_config until I've tested the hell out of my running configuration and am sure it's worth saving. If I completely mangle the running config it's very easy to recover.

Thanks to Google, the proper incantation is probably something like: nvram set rc_startup="/sbin/route add..." or something similar. Am I close? Do I get a prize?

Reply to
Jeff Liebermann

That doesn't make sense to me. Is NETBEUI over IP an example of non-IP traffic? I would have thought that would be routed... Or do you mean NETBEUI over Ethernet? (I've never messed with any of the non-IP protocols.)

I haven't looked at either the switch or the bridge in the WRT54G to see what can be done as far as protocol restrictions.

You need not preen Jeff... I was *not* talking about you.

The average reader in this newsgroup, to whom my comments are addressed, is almost certainly using MS Windows, and probably has *no* background in systems admin for even that environment, much less something as different as Linux is from Windows.

You obviously have the background and won't find it difficult to come up with the various conceptual models needed to implement just about anything that strikes your fancy. (And I'd be silly to think that I'm going to educate you... even if I did find something you don't know. ;-)

Yep. Two ways to do it that I know of.

The first one is to make an appropriate file on another system, and then go to the "Administration->Diagnostics" web page of the WRT54G, and insert it into the command input window. Instead of clicking on the "run" box next to it, go down to the bottom of the window and click on the "startup file" box. (I'm not looking at the web page, and the quoted titles may be a bit different than what I'm listing here from memory.)

What that actually does is write to the nvram "rc_startup" variable, and sets the entire text of the file equal to that variable. When the system boots it dumps the value of that variable into a file named /tmp/.rc_startup (/tmp is a ramdisk).

The second way is to create a working file in /tmp, using vi or any other suitable means (e.g., tftp it from another system). then do "nvram set rc_startup=$(cat /tmp/foo)", where the working file is /tmp/foo. On the next boot, that will be found in /tmp/.rc_startup.

Another trick that is really nice is to put things into the startup file that create /tmp/.profile, /tmp/host, and /tmp/resolv.conf files. The last two are symlinked to the /etc directory, so whatever is in them will be useful.

(I need to try diddling with nvram, or download the source code, and see if there is an appropriate nvram variable name for those files, the same as with .rc_startup. That would be easier.)

My WRT54G's boot up with a handy ~/.profile for the root user that even uses color in the prompt, and provides a few useful aliases to do complex commands with simple names. It also sets the current date and time when the system boots. And having canonical host names in /etc/hosts certainly makes a number of things much easier to do.

With the WRT54G's you can of course just set everything to whatever you like, using manual commands from the shell command line, and if it gets hosed... just reseat the power plug, let it reboot, and it's back to where it started.

Close enough for government work!

Are you aware that you can add *any* variable to nvram that you like? You can then use your own nvram variable names to change what the init script does, or whatever...

Of course playing with nvram is kinda dangerous, because dead WRT54G's aren't shaped well to be useful as either a door stop or a boat anchor.

Reply to
Floyd L. Davidson

Argh. I screwed up. I was so used to scribbling NETBIOS over IP (which is Microsloth networking) that I did the same with NETBEUI. NETBEUI is a non-routeable alternative to IP originally supplied by MS before they discovered the internet. Another common alternative protocol is Novell's IPX/SPX. NETBEUI will work very nicely between wireless clients, but will not go through the router to/from the internet. There are some security benefits to doing this, but I was fighting the local gamers.

I'm crushed. I thought we were talking about my favorite topic, me. Bummer.

Well, which would be better? Teach the average user Unix/Linux from the command line, or switch to an all GUI Microsoft embedded operating system such as Embedded XP or CE? I can just see the resultant router product. Runs at the speed of a dialup modem, costs 4 times the Linux based product, displays a EULA every time it boots, lots security holes, weekly firmware security updates, and crashes any time one tries to do something useful. However, it would have a cool looking logo sticker.

I have a small number of customers running Samba on various Linux mutations as replacements for Windoze servers. I've found that if I can teach the user some basic command line stuff, and teach them vi (vim, vedit, elvis, pico, or other editors), I can usually get them functional in a Linux environment. The basics of login, logout, find program, find file, get help, exit safely, etc are fairly easily taught.

Thanks. I didn't know you could do that. I'm so used to hacking from the command line that I don't usually look at the GUI tools.

Clever. Can I use the "set" or "env" shell commands to make temporary changes for testing?

Sounds good. On other Unix boxes (mostly SCO), I've had difficulties issuing route add commands in various rc scripts before the IP stack was loaded and ready. I found that I had to tack the route add commands at the end of all the startup scripts, sometimes preceded with a sleep delay to insure that it works every time. Is there a similar problem with Satori or can I just stick the route add commands anywhere?

I'll see if I can find something on the order in which the startup scripts load. In theory, almost any script will work, but I prefer to use whatever loads last.

Hmmm... I guess I should do the same thing and move my .bashrc or ..kshrc working environment into the startup script. There's quite a few one letter commands and aliases that I've become addicted to using. Incidentally, I'm now wasting my weekend moving web sites around to a new hosting service. This one offers SSH2 command line access. It's been many years since I've been able to remotely re-arrange a hosted web site from the command line and it sure makes everything easy for me.

Well, I once flunked a security clearance so there will probably be no government work for me. Too many relatives in the wrong places.

Nice. I didn't know that works. I'll play with it when I get my WRT54G back from loan. Tweaking shell and environment variables makes testing much easier.

I've recovered two of them for friends using:

formatting link
wana try playing with the JTAG port which should also give me additional recovery abilities.
formatting link
reason is that I have some 900Mhz radios with RS-232 interfaces and some packet radio TNC's that I want to interface to additional ports on the router. If I can get the JTAG port to play serial port and run PPP, I can use these devices. I already do this using:
formatting link
it would be nice to have it all in one box (on a pole).

Reply to
Jeff Liebermann

What the OP uses is not significant (other than perhaps how it relates to what the OP might or might not have experience at).

The WRT54G runs Linux. There is a great deal that can be done from a Linux command line that is not available via the web interface, but with the Linksys firmware you have *only* the web interface.

There is no telnet on the WRT54G. That is why third party firmware is needed. HyperWRT is sort of minimal. Sveasoft's Sartori is freely available, but lacks documentation or support. Sveasoft's "free but not free" Alchemy costs a few bucks, includes documentation, but cannot be redistributed without losing access to upgrades and other support. (For most people the Sveasoft business model presents no problem, and they just buy a product at use it. Others object to the moral corruption of the GPL, as they see it, and refuse to buy it.)

I use Satori firmware, but have no problem with others buying support/documentation etc. for Alchemy.

None of which is useful if you don't have a telnet daemon running on the WRT54G! However, that's only the simple part. The complexity comes after you get telnet'd into the router and discover some configuration parameter that you can change to get what you want. At that point you of course want to make it a permanent change, such that the router can be rebooted without needing to telnet into it again and reconfiguring it manually.

That gets complex, and if you aren't familiar with unix admin it isn't likely something you'll do on your own.

Reply to
Floyd L. Davidson

The OP's on Windows, so what's wrong [1] with using its builtin telnet client? Also, there are several excellent free telnet clients, PuTTY springs to mind as one that I've used for several years.

Chris

[1] On second thoughts, I don't want to know. 25 line VT220 anyone? Sigh.
Reply to
chris-usenet

To geta command line interface on the WRT54G you have to install third party firmware... several versions are available and they all have a telnetd installed. I mentioned Sveasoft and HyperWRT as the two most popular sources of such firmware.

Reply to
Floyd L. Davidson

Ah. Misunderstood that bit. (Couldn't see why a GNU/Linux based piece of firmware wouldn't have used telnet for its CLI.) Thanks for the clarification.

Hmm. Now you're still confusing. You say there's no telnet service on the box, yet you talk about telneting [ugh] into it.

Chris :-)

Reply to
chris-usenet

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.