Re: Mixing and Matching DHCP and static IPs
Le 26/12/2017 à 15:50, Dan Purgert a écrit :
Pascal Hambourg wrote:
Le 26/12/2017 à 12:33, Dan Purgert a écrit :
[...]
Sounds like perhaps the airstation is blocking client devices from
talking to "bogus" network addresses. This is generally a feature of
consumer gear to stop you from trying to ask the internet for
information about a RFC1918 address (as they are private / not routable
on the internet).
What do you mean by "ask the internet for information about a RFC1918
address" ? Sending an IP packet is not asking the internet for any
information.
No, but if you don't know how to get somewhere (e.g. 192.168.1.0/24 from
192.168.11.0/24), you "ask" your gateway for assistance in getting the
packet to its intended destination.
The host does not really "ask" anything to the router ("gateway" is
deprecated). It justs sends the packet to it. Also, from its routing
table it knows how to get to the destination : through the router. What
happens beyond the router is irrelevant to the host as long as the
packet is forwarded to the destination in the end.
E.g. the following routing table :
default via 192.168.0.1 dev eth0 proto static
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.238
does not mean "I don't know how to route anything else than
192.168.0.0/24". It means "192.168.0.0/24 is directly reachable, and all
the rest is reachable through the router at 192.168.0.1.
Now, since RFC1918 space is not routable on the internet, and consumer
gear is meant to be "easy", some assumptions are made - such that "no,
they'll never want to use this to talk to an upstream RFC1918 network,
so we can safely block it and keep them from asking ISP gateways for
networks that don't actually exist".
This assumption seems wrong. ISP networks use RFC1918 addresses, and
such devices may be used on private networks
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.
That could also be possible, but I made the assumption that it was the
"default(tm)" subnet from a generic residential gateway device. Also,
since he can apparently ssh into the rpi from whatever the firewall
device is, it is not likely to be a broadcast address.
But the Air-station may be misled by a wrong DHCP netmask into believing
that 192.168.1.3 is a broadcast address.
Reply to: