Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #190260 > unrolled thread

Re: Mixing and Matching DHCP and static IPs

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Mixing and Matching DHCP and static IPs Marc Auslander <marcslists@gmail.com> - 2017-12-25 17:50 +0100
    Re: Mixing and Matching DHCP and static IPs Sven Hartge <sven@svenhartge.de> - 2017-12-25 18:00 +0100
      Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-26 02:00 +0100
    Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-26 02:00 +0100
    Re: Mixing and Matching DHCP and static IPs Paul Johnson <baloo@ursamundi.org> - 2017-12-26 03:30 +0100
      Re: Mixing and Matching DHCP and static IPs Dan Ritter <dsr@randomstring.org> - 2017-12-26 20:40 +0100
        Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-27 12:40 +0100

#190260 — Re: Mixing and Matching DHCP and static IPs

The safest way to fix an ip address in a dhcp served network is to tell
the dhcp server to associate that address with the mac of the unit.  The
address should be outside the dhcp range you set up.  I normall pin down
all my connected devices that way, leaving the dhcp assignment for
guests etc.  I've never seen a router which didn't support this.

[toc] | [next] | [standalone]

#190261

Marc Auslander <marcslists@gmail.com> wrote:

> The safest way to fix an ip address in a dhcp served network is to tell
> the dhcp server to associate that address with the mac of the unit.  The
> address should be outside the dhcp range you set up.  I normall pin down
> all my connected devices that way, leaving the dhcp assignment for
> guests etc.  

The technical term of this is "DHCP reservation".

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#190267

On Mon, Dec 25, 2017 at 05:53:42PM +0100, Sven Hartge wrote:
> Marc Auslander <marcslists@gmail.com> wrote:
> 
> > The safest way to fix an ip address in a dhcp served network is to tell
> > the dhcp server to associate that address with the mac of the unit.  The
> > address should be outside the dhcp range you set up.  I normall pin down
> > all my connected devices that way, leaving the dhcp assignment for
> > guests etc.  
> 
> The technical term of this is "DHCP reservation".
> 

Thanks Sven, that will help me find documentation on doing this with dhcpd.

Mark

[toc] | [prev] | [next] | [standalone]

#190265

On Mon, Dec 25, 2017 at 11:49:17AM -0500, Marc Auslander wrote:
> The safest way to fix an ip address in a dhcp served network is to tell
> the dhcp server to associate that address with the mac of the unit.  The
> address should be outside the dhcp range you set up.  I normall pin down
> all my connected devices that way, leaving the dhcp assignment for
> guests etc.  I've never seen a router which didn't support this.
> 

Thanks, this sounds like a plan. Would doing so be likely to change the 
routing information clients get about how to reach other clients on the 
same subnet? It would SEEM that the problem boils down to 192.168.1.2 
(AirStation) not knowing how to route to 192.168.1.3 (PI), when there is 
no router required here, they can talk directly...

I'll try it anyway. Thanks.

Mark

[toc] | [prev] | [next] | [standalone]

#190271

[Multipart message — attachments visible in raw view] — view raw

On Mon, Dec 25, 2017 at 10:49 AM, Marc Auslander <marcslists@gmail.com>
wrote:

> The safest way to fix an ip address in a dhcp served network is to tell
> the dhcp server to associate that address with the mac of the unit.  The
> address should be outside the dhcp range you set up.  I normall pin down
> all my connected devices that way, leaving the dhcp assignment for
> guests etc.  I've never seen a router which didn't support this.
>
>
Or, just tell the DHCP server that you want a specific MAC address to
always be assigned to a specific IP address.  It doesn't matter if it's in
or out of the assignment range, then, or whether or not the unit in
question understands DHCP or is configured manually on it's end; the DHCP
server will not assign another client to that IP.  Though for ease of
dealing with static assignments, I personally find it much simpler to do it
all at the DHCP server end only if the client end speaks DHCP, just in the
off chance I need to change the network configuration later.

[toc] | [prev] | [next] | [standalone]

#190324

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@gmail.com>
> wrote:
> 
> > The safest way to fix an ip address in a dhcp served network is to tell
> > the dhcp server to associate that address with the mac of the unit.  The
> > address should be outside the dhcp range you set up.  I normall pin down
> > all my connected devices that way, leaving the dhcp assignment for
> > guests etc.  I've never seen a router which didn't support this.
> >
> >
> Or, just tell the DHCP server that you want a specific MAC address to
> always be assigned to a specific IP address.  It doesn't matter if it's in
> or out of the assignment range, then, or whether or not the unit in
> question understands DHCP or is configured manually on it's end; the DHCP
> server will not assign another client to that IP.  Though for ease of
> dealing with static assignments, I personally find it much simpler to do it
> all at the DHCP server end only if the client end speaks DHCP, just in the
> off chance I need to change the network configuration later.


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

-dsr-

[toc] | [prev] | [next] | [standalone]

#190335

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@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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web