[–] rivalarrival 0 points 1 point 1 point (+1|-0) ago (edited ago)
My boss wants the POS to use the wireless USBs
Reading on it, I'm pretty sure that Windows 7 isn't capable of doing dual wan with failover by itself: you'd need some kind of routing software to do what you want with the POS terminal, or you'll have to teach the client how to do a manual failover when needed. I strongly recommend against this approach.
I am trying to convince him to turn the routers Wifi on and have that connect to the hotspot itself as a redundancy.
I think you've got the right idea with this one. This will greatly reduce configuration problems now, and in the future when that client needs to replace that POS terminal, or add other machines. Unfortunately I don't think that router is capable of functioning in wifi client mode, at least not with the stock firmware. I think your best bet would be convincing the client to purchase a dual wan capable router that can operate as a wifi client, connecting it to both the wired ISP and the wifi hotspot, and configuring it in failover mode.
One of the reasons this might not be a good option is the distance from the router to the jetpack, and/or the signal in the building isn't the greatest unless he has the Jetpack downstairs near a window for best reception.
You can use a wifi router capable of client mode to connect to the jetpack, and an ethernet cable from that router back to the dual-wan router.
[–] AhavatOlam [S] ago
We didn't want to buy any extra equipment unless it came down to it, my boss took over and set his IP address to static, which allowed the POS terminal to gain internet access during our outage test. I apologize if that was a step I should have taken, I am very new to IT and still learning tips and tricks to getting things done. Thank you so much for your reply. I will keep your suggestion(s) available in case of failure. Thank you again rivalarrival!
[–] 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.
[–] Gawbles 0 points 1 point 1 point (+1|-0) ago
Normally if they have a cellular hotspot, they just need to connect to it via wireless. I'm not sure the problem. If they need to have internet via the router and network connection that's a different story. They would need an access point/firewall/router than can switch traffic when needed. I'd recommend a watchguard if they're on a budget.
[–] AhavatOlam [S] ago
So I wanted to follow up. The boss ended up taking over and he solved the issue by setting a static IP address on the computers. The DNS was set to 8.8.8.8 and 8.8.4.4.
Thanks for all your help.
[–] ogn3rd 0 points 2 points 2 points (+2|-0) ago
It sounds like you have multiple issues. 1) wifi signal penetration 2)broadband to 4G failover. How do you plan to failover between broadband and 4G? Cradlepoint and Teltonika makes devices that are capable of auto-failover between the 2.