[Solved] Get both a dhcp and a fixed IP on the same iface

[javeree]

I have an interface that gets assigned an ip address (and related info such as dns servers) by dhcp.
In addition, I want to add a fixed IP address to the same interface. After the interface is brought up using /etc/init.d/net.eth0 start, I can manually add an fixed IP address:

Code: Select all

 sudo ip a add 192.168.0.30 dev eth0

I want to do that automatically every time the interface is brought up, but I fail to get the right settings in /etc/conf.d/net.eth0

I tried:

Code: Select all

config_eth0="dhcp"
config_eth0_0="192.168.0.30 netmask 255.255.255.0"

and

Code: Select all

config_eth0="dhcp
192.168.0.30"

but neither works. In both cases, I only get the dhcp assigned address.

[Anon-E-moose]

Code: Select all

config_eth0="192.168.0.30 netmask 255.255.255.0 broadcast 192.168.0.255"
routes_eth0="default via 192.168.0.1"

I have dhcp turned off on the router for a subset of it's range, that way I can assign what address I want.

[John R. Graham]

According to /usr/share/doc/netifrc-0.7.8-r1/net.example.bz2, the correct syntax for that option would use CIDR-style addresses, so, for example:

Code: Select all

config_eth0="dhcp 192.168.0.30/24 192.168.0.31/24"

Edit to say I didn't realize that ifconfig didn't show all configured IP addresses. Running ip a shows that they're all present.

- John

[Hu]

Forcing a mixed mode like this seems like the wrong solution. Why does the system need a specific fixed IP address? Can you configure the DHCP server with a reservation to ensure it issues that address to this system?

As a workaround, you could use the netifrc postup hook to run your ip addr add command.

[John R. Graham]

See my correction above. It works. No work-around needed.

Also, I can kind-of think of a good reason to do this. If you want to receive all of the information you can about the network from DHCP (e.g., gateway, NTP server, and DNS addresses) but for some reason you need a static IP address, this approach minimizes the amount of information you need to manage in more than one place.

- John

[sMueggli]

What is the use case of this configuration?

Are the DHCP address and the fixed IP address in the same network or in different networks?

[javeree]

@John R. Graham

You provided the correct solution:

Code: Select all

config_eth0="dhcp 192.168.0.30/24 192.168.0.31/24"

and you were correct about the use case. Using dhcp allows me to receive network information from my ISP.
In addition I have an nginx server running with a website and some reverse proxying. It is also used for certbot. That server binds to port 80.

Further I have a radio/amplifier that used to get a list of webstations from the internet, but that free service became subscription based. Instead I am now using YCast https://github.com/milaq/YCast to provide my webstations, but that service also MUST run on port 80.

The easiest solution for solving the conflict is to assign a separate IP address for it.

[sMueggli]

You should check that the fixed IP addresses are not in the DHCP range. Otherwise you might get some surprises sooner or later.

Why don't you use the nginx which is listening on port 80 to reverse proxy also your webstation?

And you could use VLANs. You could then separate the webstation traffic from "sensitive" traffic.

[javeree]

@sMueggli:

I know, I made sure I have an IP address out of the dhcp range.
VLANs are not possible, as I can't set that in the Yamaha amplifier. Only the IP address can be set.
I tried using nginx as a reverse proxy, but for some reason, I could not get that to work. Possibly it has something to do with the fact that dnsmasq 'hijacks' the url that the amplifiers is looking for and provides the local IP instead. I did not go into detail with wireguard to analyse the API and find the root cause, but chose this solution that was much simpler and works.

[John R. Graham]

VLAN support doesn't typically exist in endpoint IoT equipment. If your consumer-grade network infrastructure supports it (some does; most dosen't), it'll be part of the configuration of your router and (if present) switch.

- John

[Ralphred]

the correct solution:

Code: Select all

config_eth0="dhcp 192.168.0.30/24 192.168.0.31/24"

Just as a point of interest, netifrc accepts config_eth0 and routes_eth0 across multiple lines, so

Code: Select all

config_eth0="dhcp
192.168.0.30 netmask 255.255.255.0 broadcast 192.168.0.255
192.168.0.31 netmask 255.255.255.0 broadcast 192.168.0.255"

would also work, though this is more useful with routes when trying to set a static/fallback default gateway in both ipv4 and ipv6 stacks.

[grknight]

the correct solution:

Code: Select all

config_eth0="dhcp 192.168.0.30/24 192.168.0.31/24"

Just as a point of interest, netifrc accepts config_eth0 and routes_eth0 across multiple lines, so

Code: Select all

config_eth0="dhcp
192.168.0.30 netmask 255.255.255.0 broadcast 192.168.0.255
192.168.0.31 netmask 255.255.255.0 broadcast 192.168.0.255"

would also work, though this is more useful with routes when trying to set a static/fallback default gateway in both ipv4 and ipv6 stacks.

Internally, this is just converted back into CIDR /24 by default. It will skip a processing step to do the first suggested solution.
Multiple lines are much more useful in route lines than addresses in most cases.

[JustAnother]

Suppose one wanted (netifrc) to use dhcpcd with a request address, then assign a second static address (same subnet) and then send an inform message to tell dhcpcd that the static address is in use.
Is that possible?

[b11n]

Suppose one wanted (netifrc) to use dhcpcd with a request address, then assign a second static address (same subnet) and then send an inform message to tell dhcpcd that the static address is in use.
Is that possible?

Short answer: No, that's not the way you do it.

That's not the purpose of the DHCPINFORM message. It is used to get for getting information for the client, but not for informing the server of a statically assigned address. If you're already obtaining a lease through the normal means, then DHCPINFORM won't get you anything you haven't already got from that lease.

DHCP servers are usually smart enough not to lease an address that already seems to be in use, often with a salty error message, but AFAIK there's no mechanism for telling a DHCP server you've helped yourself to an address from its lease pool.

Best practice is to configure the DHCP server with a sensible range of IPs, and never statically assign addresses from that range. Alternatively, an IP can be reserved on the DHCP server to get a behaviour similar to static addressing, but the client still obtains the address by the usual DHCP means, not static assignment.

[JustAnother]

Thanks for responding. I'm a little confused here. From the man page of dhcpcd.conf:

request [address]
Request the address in the DHCP DISCOVER message. There is no guarantee this is the address the DHCP server will actually give. If no address is given then the first address currently assigned to the interface is used.

inform [address[/cidr[/broadcast_address]]]
Behaves like request as above, but sends a DHCP INFORM instead of DISCOVER/REQUEST. This does not get a lease as such, just notifies the DHCP server of the address in use. You should also include the optional cidr network number in case the address is not already configured on the interface. dhcpcd remains running and pretends it has an infinite lease. dhcpcd will not de-configure the interface when it exits. If dhcpcd fails to contact a DHCP server then it returns a failure instead of falling back on IPv4LL.

Are you possibly referring to an INFORM message from the server?
The above seem to say that there is an INFORM message from a dhcp client (dhcpcd) that does tip off the server that an address is in use.

I'm no expert in any of this. I just want to be confused on a higher level.

Edit: from rfc 2131:

DHCPINFORM - Client to server, asking only for local configuration
parameters; client already has externally configured
network address.

So now I am confused.

[b11n]

So now I am confused.

I don't blame you, the wording is confusing.

From RFC2131 3.4, which you've already found:

If a client has obtained a network address through some other means (e.g., manual configuration), it may use a DHCPINFORM request message to obtain other local configuration parameters.
.…
The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.

Now, nothing in this forbids a DHCP server from inferring a DHCPINFORM as indicating an address from its pool it should not lease, and there may be DHCP servers that do this (as I said earlier, even without any explicit indication, they may quickly ping an address before handing our a lease for it).

The takeaway from this is that DHCPINFORM is not provided as a mechanism for notifying the server of anything, and the dhcpcd man page is misleading on this point, IMO.

edit: for the sake of transparency, the author of dhcpcd thinks I'm incorrect, at least at this point in time. I'm happy to be proved wrong, but right now it looks to me like a case of

A lie told often enough becomes the truth

[UberLord]

Hi! I'm upstream

You have to inform the DHCP server the address you have configured so it knows which address to send the reply to.
The ACK to DHCPINFORM is unicast, not broadcast.

Also the clue is in the wording - DHCPINFORM - INFORMs the server of the address you are using.
In DHCPv6 the wording is changed to INFORMATIONREQUEST which is as you describe - just for the wrong protocol.