Re: Mixing and Matching DHCP and static IPs
- Date: Thu, 28 Dec 2017 00:07:18 +0900
- From: Mark Fletcher <mark27q1@xxxxxxxxx>
- Subject: Re: Mixing and Matching DHCP and static IPs
On Tue, Dec 26, 2017 at 04:33:57PM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 16:05, Mark Fletcher a écrit :
> > At the risk of further advertising my ignorance, 3 as an 8-bit binary is
> > 00000011, and 252 in binary is 11111100, so why doesn't that mask "fit"
> > with that address? (if you'll pardon my poor terminology) Put another
> > way, why do I need to zero out another bit of the mask to make .3 a
> > unicast address?
> The IPv4 protocol specification gives a special meaning to the first and
> last addresses in a subnet. The first address is the "network address" and
> the last address is the "broadcast address". Both are reserved and cannot be
> used as unicast host address.
I never acknowledged this part -- thanks for this explanation, which I
did not previously know. Totally explains why 192.168.1.3 was not
working -- or one reason why, anyway.
In another update -- a couple of developments in the last couple of
hours. First of all Google dug up an English-language manual for my
AirStation -- or at least a model close enough to the one I have to be
useful. Using that I was able to discover a ping tool in the web
interface which I didn't know was there, which lets me ping test from
the Airstation to any address.
The second development was that sometime after changing the IP address
being given to the PI by the DHCP server on the firewall to an address
outside the DHCP allocation range, I accidentally turned off the
firewall machine (or at lesat put it to sleep) while physically moving
it to make room for the PI beside it. After bringing it back up and
leaving my network alone for a bit, I then used the above ping test
feature on the AirStation and -- could ping to 192.168.1.6! A check from
my Stretch desktop inside the AirStation LAN showed that can also now
ping to the PI. This represents major progress.
However, I still cannot ssh from the Stretch desktop to the PI (although
I still CAN ssh from the firewall to the PI, and I can still ssh from
the Stretch desktop to the firewall).
My network had an otherwise quiet moment a few minutes ago, and I was
able to try the ping test and note that, when pinging 192.168.1.1 the
light on the ethernet port on the PI does not flash, as I would expect,
but when pinging to 192.168.1.6 the ethernet ports on both the PI and
the firewall flash. I take this as evidence that what Pascal said might
be happening, is happening -- the AirStation for some reason still
doesn't know it can reach 192.168.1.6 directly and so is sending packets
to 192.168.1.1 for forwarding to 192.168.1.6 -- and the firewall machine
is obliging, but that is only working properly for ping packets and not
for TCP protocols like SSH.
I'm building tcpdump on both the firewall and the PI... If this turns
out to be right I will need to figure out how to manipulate the routing
table of the AirStation. Is it possible for the DHCP server to
communicate static routings to clients? I read that it is but also read
that almost no clients accept that so it is basically useless... True?