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
