Re: Mixing and Matching DHCP and static IPs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark Fletcher wrote:
> On Tue, Dec 26, 2017 at 01:05:03PM +0100, Pascal Hambourg wrote:
>> Le 26/12/2017 à 12:33, Dan Purgert a écrit :
>> >
>> > > Now 192.168.1.1 is the default gateway the firewall supplies the
>> > > AirStation (ie it supplies itself as the gateway) when the AirStation
>> > > makes a DHCP request, and I'm guessing that is why I can reach
>> > > 192.168.1.1 from inside the LAN (ie the LAN side of the AirStation). I
>> > > am wondering if the AirStation somehow doesn't know that it can reach
>> > > 192.168.1.3 directly, which I would expect it to since it is plugged
>> > > into the same switch as it and 192.168.1.1 -- and if so, how I would
>> > > persuade it to know that?
>>
>> Being plugged to the same switch is not enough. The routing table must also
>> contain a direct route to the destination.
>
> Thank you for confirmation of this. I suspected as much, but didn't have
> any facts, and if that is the case then this is almost certainly what is
> wrong, because I recognise I did nothing to tell the AirStation about
> this. Now I just need to figure out the best way to get that information
> into the AirStation's routing tables, preferably in a way that will
> survive reboots of the various machines involved -- perhaps the DHCP
> settings changes I've already been pointed at will have the effect of
> doing so. I've been battling a totally unrelated printing problem today
> but will advise as soon as I have tried that.
If the airstation is getting its IP address via DHCP, you don't have to
give it any further routing information for the 192.168.1.0 subnet. It
was provided all of that information by the DHCP server itself.
The airstation's routing table will look something like this:
0.0.0.0/0 via 192.168.1.1, via eth0 ("WAN", whatever)
192.168.1/0 is directly connected, eth0 ("WAN", whatever)
>> Maybe I missed something but I read no evidence in the OP's posts
>> that the netmask on the Airstation WAN side is actually /24. If for
>> instance the mask was set to /30 instead, 192.168.1.3 would be
>> considered by the Airstation as a broadcast address and would explain
>> why it does not work.
>>
> The netmask is 255.255.255.252. I just tried changing it to 248, ie
> zeroing out one more bit, but that did not help. (changed it by changing
> the netmask supplied by the firewall's DHCP server and then checking in
> the AirStation's web interface that the netmask had indeed changed).
This is the absolute most key piece of information that was required to
help troubleshoot your problem ...
255.255.255.252 is /30, meaning you only had two usable addresses
(192.168.1.1, and 192.168.1.2 -- 192.168.1.3 was the broadcast. Strange
that you could ssh from the firewall device to this IP address, but no
matter).
Switch everything - airstation, upstream firewall, rpi, anything else to
/29 (255.255.255.248), and restart their relevant interfaces. Don't
forget to update any iptables rules, etc. that may have triggered on the
netmask.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJaQmR3AAoJEI4R3fMSeaKBBtEH/2leUCp7olulBfNWCFpdRxmB
vH7gwM3p79bPzrIc7lp4v18OHA3NYn2SNXEl6eSsj1pbbibDt+bkCzMiegDrtjg8
0NBrmr4PL/QbUBUzEkbbm6SeZazSRcu033uOHxLJu1JAUD/6C89c2DjhEzPMnvyP
FK6nTfTnfdLs65XTuH+O96R6WgIPRL8ijWTpl47LGPD7vrTwrb211GYCnfiqeKX+
lNarnIcKZFYdkMuP94I9lPVSe+7Tj6YIlRKmALfzaUTTpfLa7UyRO2j4cJ50caRS
UzBGsC+ITdiOVXw9U6vLm3r6DHQ8kGkBz9kGvyuD04T4vvJ6BHcHM4Gk3JnPkx4=
=WOxz
-----END PGP SIGNATURE-----
--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
Reply to: