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 <marcsli...@gmail.com>
> > 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
