You are viewing a single comment's thread.

view the rest of the comments →

0
0

[–] rivalarrival ago  (edited ago)

The problem wasn't the IP address; the problem was the routing. Unfortunately, I learned this in Linux. I know I could make these configurations in a Windows machine, but offhand, I don't know the commands to make it happen.

I'll try to explain. Not knowing your level of understanding, please don't be insulted if I'm going to slow, and please ask for more details if I'm going to fast.

The router is functioning as a NAT gateway. This means the the router has a public internet address, and it has a private internet address. Any traffic addressed to it from either side, it attempts to relay from one network to the other.

I'll assume that you're trying to use addresses in 192.168.1.x, and your router is at 192.168.1.1. I don't want to get into the details about subnetting right now. I'll mention that the subnet mask for this setup is 255.255.255.0, which basically means that the router is only going to listen to private network traffic coming from a node with an IP address of 192.168.1.x. It doesn't know what to do with traffic from any other addresses, so it just ignores it. We'll be using this netmask of 255.255.255.0 throughout. Subnetting is very useful for more complex configurations, but for right now, all you need to know is to use 255.255.255.0 throughout.

Let's also assume we have a server at 192.168.1.10. We'll assume it's already properly configured before we get started.

Now, let's add a terminal to the network. We'll assume that there is no automatic configuration because we're trying to learn basic networking functionality. We plug in the terminal, the lights on the NIC light up. You try to ping www.google.com. You get an error. You try to ping 8.8.8.8 (google's DNS servers; an easy to remember address on the public internet that should always respond to us). You get an error. You try to ping 192.168.1.1. You get an error. We don't yet have an IP address on our private network, so we can't reach anything at all. Even our own router is ignoring us.

So, we go ahead and set an IP address. 192.168.1.100 is our new terminal.

We ping www.google.com. Error. We ping 8.8.8.8. Error. We ping 192.168.1.1. Success. We ping 192.168.1.10. Success.

Our terminal has an acceptable private IP address, and it can talk to other nodes on our network. But, it doesn't know how to reach the internet. It doesn't know which node it should send traffic to if it wants that traffic relayed to the internet. We have to tell our terminal which node on our network is the gateway router. On our terminal, we set a default gateway of 192.168.1.1.

Now, we ping www.google.com. Error. We ping 8.8.8.8. Success. We ping 192.168.1.1. Success. We ping 192.168.1.10. Success.

Now our terminal knows where the router is, so it can send traffic to IP addresses on the internet. But, we couldn't reach www.google.com. We need to teach our terminal where it can translate domain names (www.google.com) into IP addresses. We do this by setting our DNS servers. Here, we have a couple options. If we set our DNS servers to 192.168.1.1, our router will (probably) forward them to our ISP's DNS servers. Alternatively, we can set them to any DNS server we know of on the internet. There are numerous public DNS servers out there. Google happens to have a couple very easy to remember servers, and my ISP does naughty things with DNS, so I set my primary to 8.8.8.8 and a secondary to 8.8.4.4. But, to keep things simple, let's just set our DNS servers to our ISP's servers. We log into our router's page, look up the servers our ISP issued to it, and set our terminal to use the same ones.

We repeat our pings. Finally, success on all of them. We're finally on the internet.

There's got to be an easier way, and there is: DHCP. We turn on DHCP, and the moment we plug in the cable, our terminal starts broadcasting on the network: "Here I am! Who am I? Here I am! Who am I?" Our router listens for that broadcast announcement and says "Welcome to the neighborhood, here's your address, here's my address - you can use that to get to the internet - and here's the address of a couple DNS servers." DHCP does everything we just did. DHCP makes it a hell of a lot easier to get that default configuration in the future, but it's also going to screw us up in a minute, and we need to know what it's doing so we can fix this problem ourselves.

Now, we're trying to add a new network interface to our system, our wifi card. At the level we're talking about, setting the SSID is the same thing as plugging in an ethernet cable, and our hotspot is just another router. Alternatively, we plug the hotspot into the terminal via USB. USB, wifi, network cable, they all look the same at the level we're talking about.

We may or may not have an issue here. If both our router and our hotspot are trying to use the same subnet (192.168.1.x), our terminal won't know which network interface to use to reach anything. It's like you and I agreeing to meet at 123 Main St without specifying whether we're talking about Cleveland or Miami. I think this might have been part of the problem you were having. The simplest solution is to use different private addresses for the two networks. We'll assume that the wireless hotspot has been configured to use 192.168.2.x.

Whether we do it or it's done for us with DHCP, we start our network configuration. We get an IP address (and netmask) from our hotspot/router. Now we can talk to any machine on our hotspot's subnet. (the only other machine on this network is the hotspot router itself, but if we had multiple terminals connected to the hotspot, we'd be able to reach them)

Now we run into a problem. We already have a default gateway configured from when we setup our first NIC. Our hotspot/router gives us a second gateway. Our terminal basically says "Thanks. If that other gateway disappears for some reason, I'll keep you in mind and send traffic your way."

Our hotspot/router gives us new DNS addresses. Again, our terminal says "Thanks. If our existing DNS addresses don't work, we'll give you a call."

We think everything is great. We've got two internet connections. We think everything is going to be great. So, we test an ISP outage by unplugging the external network from our primary router.

We ping www.google.com, expecting everything to work.

Request timed out. Request timed out. Request timed out.

What's happening is that our router is disconnected from the internet, but it's still connected to our wired network. Our terminal can still see our router, and it has been told that our router is the default gateway, so it keeps sending traffic to it. We've got a perfectly good hotspot connected to the internet, but our terminal knows that it can reach our main router, so it just assumes that you're making a request for an address that doesn't exist. It doesn't realize that our router can't reach the internet, it thinks we're stupid for asking for things that don't exist.

Our router isn't aware of the hotspot at all, so it can't tell our terminal to try using a different connection. Our router can't configure our terminal via DHCP because our router doesn't know that another connection exists. Same problem with our hotspot.

Now, we get to the solution you and I agreed upon: have the router connect to both the wired ISP and the hotspot. The router can tell our terminal that it will take care of everything, and if our primary ISP fails, it will silently switch over to the backup until the primary has been reconnected.

Your boss chooses a different option: he connects the terminal to the hotspot directly. He sets the router and the hotspot to different networks. Any time we go looking for anything in 192.168.1.x, it sends that traffic over the wired connection. Any time we go looking for anything in 192.168.2.x, it sends that traffic over the wireless connection. If we're trying to reach anything else, it attempts to send it over the default gateway. So, we merely need to come up with a way for the client to set the gateway he wants. Windows can't do this directly, but we could teach the client to do it, or put together a script to check if we have internet connectivity, and switch our gateway configuration as needed, or find a dedicated program that could do all of this for us.