Web lists-archives.com

Re: Mixing and Matching DHCP and static IPs

On Tue, Dec 26, 2017 at 02:30:27PM -0500, Dan Ritter wrote:
> On Mon, Dec 25, 2017 at 08:25:52PM -0600, Paul Johnson wrote:
> > On Mon, Dec 25, 2017 at 10:49 AM, Marc Auslander <marcslists@xxxxxxxxx>
> > wrote:
> > 
> Sample dhcpd config for a static IP assignment:
> host thatonemachine {
>  hardware ethernet d0:ee:fb:13:5e:a6;
>  fixed-address;
> }
> You can read the ethernet MAC address on the machine in question
> with 
> ip l | grep ether

Thanks very much for this, saved me a Google search. I have done this, 
replacing the mac address with the MAC address of the PI and the 
fixed-address with . Then I built the client part of the 
dhcp package on the PI and verified it can now get its IP address by 
DHCP from the firewall's DHCP server. Rebooted after moving the old 
ifconfig config file out of the way to eradicate any trace of the old 
fixed IP. The PI now correctly and reliably gets the IP from the 
firewall DHCP server.

Oh and I also checked the netmask of the 192.168.1.x LAN on all 3 
machines. Everywhere was using /24 or except the DHCP 
server config (and the AirStation, which was doing what it was told by 
the DHCP server). Fixed the DHCP server to and nudged the 
AirStation to update accordingly.

Unfortunately, I still can't communicate with the PI from inside the 
AirStation's LAN.

So, the AirStation reports an IP address of (on what it 
considers the WAN side), netmask

On the PI (relevant part only shown, MAC elided)
# ip address
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
       valid_lft forever preferred_lft forever

# ip route (this is the whole output)
default via dev eth0 dev eth0 proto kernel scope link src

On the firewall (relevant part only, with MACs elided):
# ip address
4: enp0s20u3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet brd scope global enp0s20u3
       valid_lft forever preferred_lft forever
    inet6 xxxx::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

# ip route
default via xxx.xxx.xxx.1 dev enp3s0  proto dhcp  src xxx.xxx.xxx.3  metric 1024 dev enp0s20u3  proto kernel  scope link  src 
xxx.xxx.xxx.0/22 dev enp3s0  proto kernel  scope link  src xxx.xxx.xxx.3 
xxx.xxx.xxx.1 dev enp3s0  proto dhcp  scope link  src xxx.xxx.xxx.3  metric 1024

enp3s0 is the device name of the external-facing interface, which gets 
its IP address by DHCP from the ISP and has had no problems at any 

And the firewall's DHCP configuration, nicked from the LFS build 
instructions and customised a little bit (and now including the config 
to fix the IP for the PI):

# Begin /etc/dhcp/dhcpd.conf

# Use this to enble / disable dynamic dns updates globally.
ddns-update-style none;

# option definitions common to all supported networks...
option domain-name-servers,;
# the above are ISP-provided DNS servers and I want to eliminate dependency
# on them eventually

default-lease-time 86400;
max-lease-time 86400;

# This is a very basic subnet declaration.
subnet netmask {
  option routers;

host nameserver {
   hardware ethernet b8:27:eb:cd:87:e8;

# End /etc/dhcp/dhcpd.conf

I tried changing the fixed IP address in the above DHCP conf to, ie outside the range of what DHCP would otherwise allocate; 
the PI did indeed pick up the new IP address but it made no difference.

On a machine running Stretch inside the wired part of the AirStation's 
LAN (wired and wireless are the same subnet), this machine has IP

$ ping
PING ( 56(84) bytes of data.
<long pause>
--- ping statistics ---
14 packets transmitted, 0 received, 100% packet loss, time 13300ms

$ ssh
<Long Pause>

$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=63 time=0.670 ms
64 bytes from icmp_seq=2 ttl=63 time=0.599 ms
64 bytes from icmp_seq=3 ttl=63 time=0.596 ms
64 bytes from icmp_seq=4 ttl=63 time=0.649 ms

$ ssh
mark@'s password:


and finally from -- the firewall:
$ ssh
mark@'s password:

If I type the password I can log in.

I'd really like to be able to see the routing table on the AirStation. 

Next steps are to build tcpdump for the firewall and the PI and see what 
running it there while trying to communicate with the PI tells me, and 
while it is building I will do some Googling to see if there is a way to 
get the AirStation to show me its routing table. Nothing is obvious from 
the web interface.

I have arranged the switch and the PI so I can see their ethernet ports 
from where I am sitting at the keyboard and when I run the pings to the 
PI from the Stretch machine inside the AirStation LAN I don't see any 
flickering of the lights (it's hard to be precise because the connection 
between firewall and AirStation is carrying all internet traffic to and 
from my network so it's never quiet for long), on the other hand when I 
ping the firewall from the same machine I see a regular flickering of 
the relevant lights on the switch corresponding to the pings. So it 
really feels like the pings are not getting through the AirStation, as 
opposed to getting out and then getting lost. Still I will build tcpdump 
and see what it tells me.