I've already started a technical support with Buffalo, but I decided to ask here too, just in case anybody else thinks there is a technical reason this won't work, because it may also be the router.

Very basic idea of this network:

[router1]
|
|
[Bufalo Bridge]
|
|
[Router]
|
[Linkstation Live]


This is the desired network diagram, not the actual anymore, because it works another way for now, or in case it won't do what I want.

The buffalo bridge is like a special type of wireless card, that seems to work well overall. It lets all the other PCs be free of wireless cards, and it connects them to one wireless card via a switch, basically. So there is basically a switch between the first and second router. There are no wires connecting the first router with the second router, but it's connected via a wireless link. The second router is a D-Link DIR-615.

The Linkstation Live works on the LAN side of the second router when plugged in OK, but when it's plugged in to the LAN, but it doesn't work on the second side of the WAN side when plugged in there. I can try simple things like forwarding a port to the webserver of the Linkstation, and nothing works from the outside of the second router. I'm trying to isolate whether this is D-Link's problem or Buffalo's problem. The router "seems" to be blocking the Linkstation, but I can't tell for sure. My best guess is either Buffalo's only accepting connections from the same subnet, or the Linkstation is too slow and the router times out, thus it blocks when configured right. Is one of these the case? Is something else the matter? Also, when I do the same test with ftp, the message says the connection with the server was reset. That might help too.

Have you segmented the default IP assignments for all of the network devices?

The default IP range for most of these devices is 192.168.0.1, etc.

If you use DHCP on all the devices then they will assign duplicate IP addresses to their connected devices. So I would suggest that you assign one of your devices as the master DHCP authority device and turn off DHCP in all of the subordinate devices.

If that does not work then you can try assigning static IPs to all of your devices.

Here is a link to help you understand what I written above.

http://tldp.org/HOWTO/archived/IP-Su...working-3.html

Thanks, but there's been no problems right now with DHCP, unless the Buffalo Linkstation doesn't like it, or something, and only says it's supported. All the IP subnet defaults that devices give off are changed though, for example, Linksys routers typically come configured to give off the 192.168.1.0 subnet range. We've got the first router giving off 1.1.1.0 subnet, and the second router gives off 2.1.1.0 subnet.

All the IPs are typically given off from DHCP. However, all addresses are also reserved, so each device always has the same address. Only "guest" devices would get a truely dynamic IP, but there still DHCP. Only a few troublesome devices are actually fully static. That is the Buffalo Bridge, and the WAN of the second router. But those devices are still set up to give the same static IP in DHCP as they are statically given, so there normally shouldn't ever be any IP conflicts at all, and there weren't.

Thanks, but there's been no problems right now with DHCP, unless the Buffalo Linkstation doesn't like it, or something, and only says it's supported. All the IP subnet defaults that devices give off are changed though, for example, Linksys routers typically come configured to give off the 192.168.1.0 subnet range. We've got the first router giving off 1.1.1.0 subnet, and the second router gives off 2.1.1.0 subnet.

All the IPs are typically given off from DHCP. However, all addresses are also reserved, so each device always has the same address. Only "guest" devices would get a truely dynamic IP, but there still DHCP. Only a few troublesome devices are actually fully static. That is the Buffalo Bridge, and the WAN of the second router. But those devices are still set up to give the same static IP in DHCP as they are statically given, so there normally shouldn't ever be any IP conflicts at all, and there weren't. From what I've been told, this is the recomended way to go, too. You're typically supposed to have one DHCP server for each subnet, and we do. Each one of our DHCP servers are in the routers. We've got 2 running. One runs on the 1.1.1.0 subnet, and the other runs on the 2.1.1.0 subnet.

Oops! posted twice!

OK lets try something different have you captured any network traffic to see if there are collisions and timeouts between the network segments?

Also since this is a wireless to wired set up have you investigated any outside "noise" interference such as light fixtures, household appliances, a neighbor with a wireless network that competes with yours?

OK. I've never done this before, but that sounds like a right step. Let's start with the simpler, connections and timeouts. You would use what I've heard of, a packet capturer, right? If so, whats a free one you know of (price)? And it captures both, right?

Well snort comes to mind..You should try Ping, Traceroute, Netstat and NSlookup first because they are probably already installed on your systems.

Here is a link to the utilities:

http://sectools.org/

Ping gets to the device from one subnet, but because of NAT, does not reach from the 1.1.1.0 subnet to the 2.1.1.0 subnet. Ping from the router to that device works well. It works completly as expected in the 1.1.1.0 subnet. Traceroute or tracrt would not work I know because if NAT is enabled the 1.1.1.0 network doesn't know enough about the 2.1.1.0 network. If ping doesn't get through, then tracert wouldn't get through.

nslookup won't work, because DNS is a work in progress to get it exactly how I want it. nslookup tends to fail, even if ping to the host names work though, from past experience. I had DNS working somewhat before internally, but nslookup always failed unless I specifically told it which DNS server to use.

netstat is easy enough to use, I think, but what's the function of it? This I've never used until now.

We are looking for Time to Live (TTL)values and dropped packets which will tell us if a specific node or segment is slow or blocked.

Where is your NAT within your network? Can you move it closer to the Wan side? Can you turn it off?

Netstat is short of network status you can run this from each node to get output for that nodes status on the network.

Also I noticed that you are splitting the IP front part of the address. Only A class IPs can do this. You are using a C class IP so you have to split the IP in the very last part of the address.

Correct= 1.192.168.255

Incorrect= 2.192.168.1

You an also try wireshark formerly known a ethereal to see what is happening on your network.

What I decided to do, in the interest of my time, was move it to the first subnet, configure it completely as if it should be there, at least for now, on my machine, and then move it back to where I had it to do the tests, and then see where I go from there. I know it works enough to be the best I can do in the first subnet though.

I'm also looking into no NAT for some or all second routers as a possibllity too, if all else fails. So if you don't already, I'd set the thing to automatically e-mail you when there are replies on this thread. That way when I move it over and complete the first test again now, you'll see the results without checking often. It'd get annoying otherwise. I still need to figure it out, but I'm willing to look into other possibillities like this one though, which is why I'm putting it there for now.