My network has both wired and wireless segments, all in a single RFC1918 class B block, 172.24/16. Using Linksys WRT54's, Sveasoft Talisman firmware and WDS, I achieved the following topology:
mobile hosts
|
wireless "router"------wired hosts
|
wireless "router"------gateway-------wired hosts
|
wireless "router"------wired hosts
|
mobile hosts
where the vertical links are 802.11g wireless, and the horizontal links are wired Ethernet. The gateway has two interfaces, one to the Internet over a DSL bridge, and the other to a switch connected to a wireless router and various wired hosts. The gateway is my DHCP/DNS server, as well as my NAT-ing firewall (which apparently doesn't meet the WHR-HP-G300N's auto-detect criterion for being a "router"). The other two wireless routers communicated with the one attached to the gateway using WDS.
What was valuable to me about this setup was that:
a) All the machines on the network see each other and communicate freely over sssh, http, smtp, rsync, etc.
b) All the machines get their IP addresses from a single DHCP server.
c) The administrative interfaces of all three wireless routers were visible from an administrative desktop, on the gateway's ethernet segment.
I'm trying to reconstruct this topology and recapture those 3 areas of functionality using 802.11n with three WHR-HP-G300Ns, all running the 1.82 firmware. Has anyone successfully done this (are there any BuffaloTech engineers or DD-WRT gurus out there?)
That's the crux of my problem. Any solution that satisfies those 3 criteria would be fine. If you are technical and like puzzles, read on for many more details and partial problems. If not, stop now before your eyes glaze over;). You've been warned.
The best I have been able to do is configure one WHR-HP-G300N as a router and then setup WDS w/ the other two as slaves, then, when WDS is working, flip the hardware switch on the master to make it into a bridge. Sadly, this falls woefully short of two of my three criteria.
b) apparently works, most of the time, at least for the non-network devices. It does, alas, inevitably eventually fail.
As for c), I can almost always see the admin UI on one of the slave WHR-HP-G300Ns from its (LAN) ethernet ports, and sometimes from elsewhere on the network, using the IP address assigned by the DHCP server. The other slave, configured as closely as human frailty allows to identically, is rarely visible from its ethernet ports and never over the network. Most disturbingly, the master, in bridge mode is almost never visible, even from its own ethernet ports, be they the LAN ports or the "Internet" port. Deceptively, the very first time I got the whole lash-up to work, I could see each WHR-HP-G300N's admin UI from its respective ethernet ports, and they were in fact using the IP addresses from the DHCP server. That functionality decayed with time, and has never completely returned, either after simple reboots or even complete fresh re-configs.
a), which is the most important criterion, is satisfied more frequently than c), and less often than b). It too, suffers regularly from the same sort of creeping bit rot I mentioned above. This could be a symptom of the unknown root cause of the WHR-HP-G300Ns not passing DHCP packets and failing b), but with c) un-met, I can't adequately collect diagnostics from the WHR-HP-G300Ns. I have made two potentially useful observations:
1) Some of the Sony media gadgets on the wired segment served by one of the slaves sometimes fall back to RFC3927 link-local addresses, i.e. zero-conf IPs in the 169.254/16 block, a state which persists through reboots of the machines themselves, but is corrected by rebooting the slave WHR-HP-G300N to which it is attached. I presume that the slave is decaying into a state of not passing DHCP packets, but I can't rule out a failure of WDS or anything else. Needless to say, useful dignostics on the Sony gear is simply not implemented.
2) To wireless machines, there appear to be 3 SSIDs, contrary to my expectation that there would be only one. Connecting to the slaves works at the 802.11 link layer, but not at the TCP/IP layer. Connecting to the master SSID works, but the bit-rate of the connection fluctuates wildly (maybe a feature of 802.11n on two channels?), and inevitably fails after a period of hours to days. Rebooting the TCP/IP stack on a lost machine sometimes works (sounds like a problem on the machine itself), but often requires a reboot of the machine (in which case multiple wireless machines will have lost their connections) to reconnect. I have yet to see a lost wireless connection which requires a reboot of a WHR-HP-G300N to restore, unlike the wired connections!
I have also tried leaving the master as a router, and letting it assign DHCP IPs of its own (doubling the pain of DHCP administration on the network as a whole). Unfortunately the "NAT" on the WHR-HP-G300N is actually PAT, Port Address Translation. In other words, it requires that I give the WHR-HP-G300N one or more unused virtual IP addresses to use on its "Internet" port and then use the admin UI to match each port I want to communicate with on a client machine with the IP it is getting from the WHR-HP-G300N with a specific port and a particular virtual IP address. To me, NAT would map virtual IPs in the 172.24/16 block to to IPs in the WHR-HP-G300N's DHCP range in a one-to-one fashion, and ports would implicitly map unchanged. While extremely tedious for my circumstances, PAT would be doable, but, alas I cannot get it to work for ssh, the most important protocol to me, even after configuring machines on either side of the WHR-HP-G300N to use a non-standard port, on the chance that the WHR-HP-G300N is listening on port 22 exclusively for its own purposes. At least getting PAT to work reliably is essential for any router mode solution. Getting true NAT to work would be great. The best solution would, nonetheless, allow me to only need to administer a single DHCP server on what is really a pretty simple network.
Another possible solution, setting the WHR-HP-G300N's hardware auto-detect switch to automatic, would be available if someone could tell me how a WHR-HP-G300N detects another router on the ethernet segment of its "Internet" port. I'm confident that I could configure the gateway to satisfy the WHR-HP-G300N's router detection, since, being a dinosaur, I was building networks in the days when routers were implemented in software on general purpose machines and I built the gateway from scratch myself (so it provides more features and flexibility than any consumer networking appliance I'm aware of).
A final curiosity is that the master WHR-HP-G300N (in bridge mode) continues to multicast (deprecated) SSDP packets to 239.255.255.250 using the 192.168.11.100 IP address, even when I can see that it is using IP addresses on its interfaces in the 172.24/16 block from the DHCP server, either from the admin UI, if it happens to be visible, or by rebooting as a router. I first detected this in my firewall egress filter logs, but the wireshark packet sniffer confirms that the SSDP packets are reaching both the wired and wireless clients of the slave WHR-HP-G300Ns, and that the multicasting WHR-HP-G300N is still unicasting packets with the correct 172.24/16 source addresses in their IP headers. Sometimes one of the slave WHR-HP-G300Ns will get into the act as well, multicasting SSDP packets to 239.255.255.250 using the 192.168.11.100, too(!), causing a Dish Network satellite converter on its ethernet segment to send frequent SYN packets to 192.168.11.100 which go unanswered. I can distinguish the WHR-HP-G300Ns by their MAC addresses, even when they don't respond to pings (which I have turned on in the admin UI at setup time). When the particular slave (albeit the one less inclined to show its admin UI to its ethernet ports) is multicasting SSDP packets, I can never see its admin UI, but wireless continues to work, as does assignment of IPs to clients from the DHCP server on the gateway. I have not observed more than one WHR-HP-G300N multicasting SSDP at the same time, but haven't captured more than a few minutes at a time of the packet stream with wireshark. I also have no clue why the master's SSDP packets don't incite the Dish box to SYN with 192.168.11.100.
If you've stayed with me this long, any insight whatsoever into any of these issues would be a help to improving my troublesome solution. I wish that any of these symptoms were deterministically reproducible, but they aren't. All that I know is they inevitably occur sooner or later.
