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

Re: Mixing and Matching DHCP and static IPs



On Thu, Dec 28, 2017 at 03:31:11PM +0100, Pascal Hambourg wrote:
> Le 28/12/2017 à 13:01, Mark Fletcher a écrit :
> > 
> > Beyond the man pages for DHCPD is
> > there a good reference anyone can recommend for exactly what happens
> > when a DHCP request is made?
> 
> The authoritative sources are the RFCs. Not the easiest to read though.
> However they will only describe what happens on the wire :
> client sends DISCOVER.
> server sends OFFER.
> client sends REQUEST.
> server sends ACK.
> 
> Client messages contain options that the clients requests. Server messages
> contain option values. Now what is done with the option values is up to the
> client.
> 
Thanks. 

> > I'm going to play with static-routes first -- first will have to read up
> > on the difference between a classful and a classless route...
> 
> Classful addressing assumes that the netmask is implicity tied to the
> address. E.g. with private ranges :
> 10.0.0.0 => class A => netmask 255.0.0.0
> 172.17.0.0 => class B => netmask 255.255.0.0
> 192.168.1.0 => class C => netmask 255.255.255.0
> 
> Classless addressing does not assume any implicit relation between the
> address and the netmask, so the netmask must always be explicit.
> 
> Since 192.168.1.0 is class C, the classful netmask matches the actual
> netmask, so it's fine to use static-routes for this subnet.
>

Thank you for this explanation.
 
> > I noticed the connection attempt to the PI arriving first at the
> > firewall, then the firewall sending the AirStation an ICMP redirect.
> 
> As expected. But the Airstation behaves as a router, and IIRC a router may
> ignore ICMP redirect. Even though, an ICMP redirect can be accepted only
> when the suggested address is directly reachable. At the moment, this is not
> the case otherwise the Airstation would not have sent the original packet to
> the firewall.
> 

Right, except that now...

> > So the remainder of the issue becomes, how does one persuade a Buffalo
> > AirStation to properly set its routing table on its WAN side after
> > receiving an IP Address by DHCP? I'll read up about the static-routes
> > next -- got nothing to lose by trying it.
> 
> I do not remember if it has been mentioned, but doesn't the Airstation
> support static IP configuration on its WAN interface ?
> 

Probably. You'd think so, wouldn't you? While poking around again in the 
(Japanese language) web interface attempting to answer this question, I 
stumbled across one button I had not attempted to press before. It was 
labelled in two kanji characters I couldn't translate and the 
English-language manual didn't mention it. When I asked my wife (who is 
Japanese) to translate it her translation was so generic I could make no 
sense of it (this often happens with technical things in Japanese -- 
very vague / generic translations are used. Ancient languages don't lend 
themselves well to technojargon. I can assume Mandarin has the same 
problem). So I thought screw it what's life about and pressed it. The 
AirStation's internet access instantly died a horrible death. 

Panicing only slightly, I pressed the button I had been pressing to 
force the AirStation to dump its configuration and re-approach the DHCP 
server (I'd been alternating this with restarts of the entire 
AirStation). After a suitably long pause, internet connectivity was 
back. And now the AirStation can route directly to the PI, and I can 
roll back my iptables changes on the firewall, and everything works the 
way it is supposed to.

So it turns out that button means "stop jerking Mark around and start 
co-operating", or probably more properly "forget everything you know 
about the world outside your WAN interface, including stuff you don't 
forget when you get shut down and restarted".

So I have finally arrived at the end of this journey with 2 successful 
outcomes -- things are working, and they are working for reasons I 
understand. Thank you Pascal in particular, but also deloptes, Dan P, 
Dan R, Marc, Sven and Paul for your contributions too. Much appreciated 
and I have learned a lot.

Mark


Reply to: