@business_kid is right about having a diagram would help getting your question answered much more quickly; since having to imagine all that from description alone is cumbersome and error-prone. But regarding the scenario, I have personally been in about the same network situation as you described before; so I don't think that "the whole idea is crazy" at all.
From your description, I figured that your "normal" network situation looks like this:
Code:
+---------+
| Hotspot |-----------------------------------------------------> Internet
+---------+ via ISP 1
(localnet) 192.168.43.1/24
_--^^--_ wlan0
_--_ 192.168.43.66/24
+---------+ +--------+
| Host A |---------------------------------| Router |----------> Internet
+---------+ eth0 (localnet) +--------+ via ISP 2
192.168.0.17/16 192.168.0.1/16 |
|
+---------+ |
| Host B |--------------------------------------+
+---------+ eth0
192.168.0.15/16
But one day, your connection to ISP 2 went kaput, and you were left with:
Code:
+---------+
| Hotspot |-----------------------------------------------------> Internet
+---------+ via ISP 1
(localnet) 192.168.43.1/24
_--^^--_ wlan0
_--_ 192.168.43.66/24
+---------+ +--------+
| Host A |---------------------------------| Router |
+---------+ eth0 (localnet) +--------+
192.168.0.17/16 192.168.0.1/16 |
|
+---------+ |
| Host B |--------------------------------------+
+---------+ eth0
192.168.0.15/16
And in this emergency situation,
Host A was still able to get to the Internet;
but you would like Host B to have Internet access too, by having
Host A share its connection; hence what you tried on your original post.
But here comes the first confusing part:
Quote:
Originally Posted by mfoley
I'd like HOSTB to connect to the Internet, obviously routing through HOSTA.
|
Quote:
Originally Posted by mfoley
When ROUTER sputters to life every so often, HOSTB can at least collect email.
|
I found that it is
very unlikely (at least in typical small home & office configuration) that
ISP 2-side maintenance would make the
Router itself become completely unavailable for localnet LAN use. And even
if that was true, it would be nigh impossible to do both things you wished to do at the same time in that case anyway; without additional hardware that is.
So I suspect that by "
ROUTER is down for the time being due to ISP maintenace" and "
ROUTER sputters to life every so often"; you didn't actually mean the
Router itself, but you meant the
connection between the
Router and
ISP 2-- and the
Router (hardware) itself was actually fine.
The second confusing part is:
Quote:
Originally Posted by mfoley
Pinging yahoo.com gives:
Code:
# ping yahoo.com
PING yahoo.com (74.6.231.21) 56(84) bytes of data.
From 192.168.0.17 (192.168.0.17) icmp_seq=1 Destination Host Unreachable
From 192.168.0.17 (192.168.0.17) icmp_seq=2 Destination Host Unreachable
with /etc/resolv.conf set to 192.168.43.1, I don't get why it's trying to connect via the 192.168.0.17 interface. Why is it not using 192.168.43.1? |
Was what you quoted being `ping` running on
Host A itself? Or was it a `ping` running on
Host B? From the flow of your description, I'm going to assume that was running on
Host A.
-----
If there was one glaring thing that looked very suspicious here however, it would be the subnet masks.
You shown that you configured
Host A to use one 255.255.0.0 subnet, and another 255.255.255.0 subnet, but with the same prefix (192.168.x.x); so they overlapped and clashed:
- 192.168.0.17 netmask 255.255.0.0: means subnet address range of 192.168.0.0 ~ 192.168.255.255
- 192.168.43.66 netmask 255.255.255.0: means subnet address range of 192.168.43.0 ~ 192.168.43.255
^ See that both address ranges overlap?
So when
Host A tried to send something to the Internet (which it had to send via default gateway 192.168.43.1) it got confused as it saw gateway address belonging to both ranges, and it happened to choose the first one to send the data to: through `eth0`. Obviously, it was the opposite way from the one that actually went to the Internet; so you didn't get to the Internet that day.
^ That's likely the reason why you got an ICMP error reported from 192.168.0.17 (eth0) side; because
Host A had sent ARP probe out on `eth0`, and didn't find any host with 192.168.43.1 address.
So the first part of the fix is
you have to configure Host A's `eth0` interface to use a subnet mask of 255.255.255.0 , rather than 255.255.0.0 that you have used. If things gone according to the plan,
Host A would be able to access the Internet again after applying this step.
Once the Internet access on
Host A got restored, then you should at least re-confirm the proper connectivity between
Host A and
Host B once before continuing, by running `ping 192.168.0.17` on
Host B. If that succeeded, then you could proceed to the connection sharing part.
On the connection sharing side of
Host A, I could see following issues:
- Linux kernel wouldn't do inter-host routing by default; you have to enable certain specific sysctl configuration first.
- Once you did that, the `iptables --append FORWARD --in-interface eth0 -j ACCEPT` is usually unnecessary.
- When NAT'ing (i.e. `-j MASQUERADE`), you should also specify who (i.e. which source addresses) you're going to perform NAT for as well; to prevent it from applying NAT to wrong kinds of traffic.
So as the second part of the fix, I would suggest replacing your set of
Host A configuration commands with the following:
Code:
sysctl -w net.ipv4.ip_forward=1
iptables --table nat --append POSTROUTING --source 192.168.0.0/24 --out-interface wlan0 -j MASQUERADE
On the
Host B side, I saw following issue:
- Host A doesn't run a DNS server; so you have to make Host B use Hotspot's DNS server directly.
- Host B used 255.255.0.0 subnet mask; which prevents it from being able to use Hotspot's DNS server.
So the third and last part of the fix, I would suggest that you apply the following changes to
Host B to:
- Use static IP address 192.168.0.15, subnet mask 255.255.255.0 (there are three 255s), default gateway 192.168.0.17 (i.e. Host A's `eth0` side).
- Make its `resolv.conf` to point to 192.168.43.1 (i.e. the Hotspot).
Once applied, you would have to test IP-level Internet connectivity first, without relying on DNS: by having
Host B ping some known Internet host IP address, like running `ping 8.8.8.8` . If that succeeded, then you can test it in combination with DNS lookup, by running something like `ping gnu.org` there.
If these all went well, then you should be able to access the Internet from
Host B now.
Emergency tethering of the entire LAN to a Wi-Fi AP
