[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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?

Mark


Reply to: