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 192.168.0.64;
> }
> 
> 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 192.168.1.3 . 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 255.255.255.0 except the DHCP 
server config (and the AirStation, which was doing what it was told by 
the DHCP server). Fixed the DHCP server to 255.255.255.0 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 192.168.1.2 (on what it 
considers the WAN side), netmask 255.255.255.0.

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 192.168.1.3/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever

# ip route (this is the whole output)
default via 192.168.1.1 dev eth0 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3




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 192.168.1.1/24 brd 192.168.1.255 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 
192.168.1.0/24 dev enp0s20u3  proto kernel  scope link  src 192.168.1.1 
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 
stage.

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 14.193.100.8,14.193.100.40;
# 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 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.2 192.168.1.3;
  option routers 192.168.1.1;
}

host nameserver {
   hardware ethernet b8:27:eb:cd:87:e8;
   fixed-address 192.168.1.3;
}


# End /etc/dhcp/dhcpd.conf

I tried changing the fixed IP address in the above DHCP conf to 
192.168.1.6, 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 
192.168.11.2:

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

$ ssh 192.168.1.3
<Long Pause>
<Ctrl-C>
$

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

$ ssh 192.168.1.1
mark@192.168.1.1's password:

$

and finally from 192.168.1.1 -- the firewall:
$ ssh 192.168.1.3
mark@192.168.1.3'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.

Mark