Re: Vlan and DHCP
basti writes: > Whats wrong there? > Can someone put me in the wright direction? Must you use kea-dhcp? I researched a similar situation (I think, I'm not 100% from your description) and dnsmasq as DHCP server can handle this.
Vlan and DHCP
Hello, maybe a bit off topic. The goal is to have a central DHCP/DNS server for multiple IP ranges in the same network. - LAN has 192.168.30.0/24 - guest should have 10.10.10.0/24 At the moment LAN and guest has different interfaces but i have to change this. A new wifi repeater / AP is needed, that have to had both, LAN and guest. The wifi repeater has openwrt so that should work, to have multiple SSID's and vlan I try to get dhcp working with vlan/macvlan. I have configures kea-dhcp with multiple ranges on multiple interfaces. But the dhcp request is seen on both, the lan and the macvlan interface and the macvlan interface send the wrong address. A similar problem is there https://gitlab.isc.org/isc-projects/kea/-/issues/1117 Whats wrong there? Can someone put me in the wright direction? Best regards
Re: DHCP Problem
On Mon, 4 Dec 2023 05:55:50 +0100 wrote: > Wait a sec: before the clients get an answer from the DHCP server, > they don't have any route (at least not for the network in question), > so it doesn't make sense poking at them with ip route and things. > They send their request to the local network's segment broadcast > address. As I understand things, that's true of the first request a client makes, say, at boot. After that, the client knows which machine it got its last lease from and can query directly. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: DHCP Problem
On Sun, Dec 03, 2023 at 12:30:53PM -0700, Charles Curley wrote: > I am installing a new router which seems to work well so far. > > I have changed the DHCP server to use the new router's address, and shut > the server down and restarted it. Existing clients insist on using the > old router anyway. Is there any way to goose clients into using the new > one short of manually using the ip route command? Wait a sec: before the clients get an answer from the DHCP server, they don't have any route (at least not for the network in question), so it doesn't make sense poking at them with ip route and things. They send their request to the local network's segment broadcast address. What's possibly happening is that your old DCHP server is still up and running and faster than your new one, so its answers come in first. Cheers -- t signature.asc Description: PGP signature
Re: DHCP Problem, but where
On Sun, 3 Dec 2023 22:32:59 -0500 Jeffrey Walton wrote: > The "restart your dhcp clients" may have a sharp edge. Sometimes the > clients have a touch of resiliency or hardening added so they contact > their original dhcp server, and not a [possibly] rogue server setup by > an unknowing developer or attacker. In the past, you used to have to > reboot Microsoft clients to get them to use the new dhcp server. I > don't know Linux behavior. > > But if the problem is, dhcp clients are using the old dhcp server or > old dhcp lease info, then I would try to reboot a client if the > service restart did not help. I think the ISC dhclient (which is what I use here) does try to return to its original server. Rather than reboot anything, I simply stopped the DHCP server on that machine. Apparently clients then started back at the beginning. Shortening the lease time accelerates that process. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: DHCP Problem
On Sun, 3 Dec 2023 12:30:53 -0700 Charles Curley wrote: > I am installing a new router which seems to work well so far. > > I have changed the DHCP server to use the new router's address, and > shut the server down and restarted it. Existing clients insist on > using the old router anyway. Is there any way to goose clients into > using the new one short of manually using the ip route command? > > OK, stupid mistake of the week. The frustrating problem was that the clients kept getting the old router's IP address. This was for the simple reason that I had managed to not change the value of the "option routers" entry for the subnet. Doh! I have fixed that. Never be afraid to recheck your own work. I did shorten the lease times and that has accelerated the changeover. I didn't need to restart all the client's leases. Two days hence I'll change them back. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: DHCP Problem, but where
On Sun, Dec 3, 2023 at 9:57 PM jeremy ardley wrote: > > > On 4/12/23 05:18, Geert Stappers wrote: > > That triggered me to ask "Has the DHCP server been restarted?" > > > The default behaviour of most dhcp clients when they can't connect to a > dhcp server is to maintain the settings from any previous lease. > > A second default behaviour is for clients to not request new dhcp until > their existing dhcp lease has expired. > > To make sure a new dhcp setting is taken by all clients you need to > > - reconfigure your dhcp server > > - restart your dhcp server > > - check your dhcp server logs for any problems > > - restart your dhcp clients > > - check your client dhcp logs to see if the new lease info has been taken. > > There can be problems where a client with a specific MAC address > requests a specific ip address based on a previous lease but the server > is unwilling or unable to allocate that address to that MAC. This can be > checked in the server and client logs. It may also require flushing the > server lease tables and client configs so they can both start out > completely fresh. The "restart your dhcp clients" may have a sharp edge. Sometimes the clients have a touch of resiliency or hardening added so they contact their original dhcp server, and not a [possibly] rogue server setup by an unknowing developer or attacker. In the past, you used to have to reboot Microsoft clients to get them to use the new dhcp server. I don't know Linux behavior. But if the problem is, dhcp clients are using the old dhcp server or old dhcp lease info, then I would try to reboot a client if the service restart did not help. (I saw a similar attack happen as an undergrad at the University of Maryland. Someone in the CS department setup a Linux server with Kerberos running. Workstations got answers from the rogue server and got [useless] tickets granted, and the [useless] tickets could not be used for authenticating to other services on the UMBC network. It was an intermittent problem, and it took a couple of weeks to straighten it out). Jeff
Re: goose DHCP clients to new address Was: DHCP Problem
On Sun, 3 Dec 2023 17:18:23 -0500 Jeffrey Walton wrote: > I don't know about Linux clients, but in the past, Windows clients > used to try to connect to the previous DHCP server for its lease info. > If the old DHCP server is still available (on the old router?), then > the client may be getting the lease info from the old server. To avoid > the problem, we disconnected the old server from the network. I did shut down both the old server and its failover peer. Clients I haven't mucked with are now asking for leases from the new server. Dec 03 14:55:48 issola dhcpd[24072]: failover peer failover-partner: I move from startup to communications-interrupted Dec 03 15:09:46 issola dhcpd[24072]: DHCPREQUEST for 192.168.100.45 from ec:28:d3:7a:6a:76 via enp1s0 Dec 03 15:09:46 issola dhcpd[24072]: DHCPACK on 192.168.100.45 to ec:28:d3:7a:6a:76 via enp1s0 Dec 03 15:40:50 issola dhcpd[24072]: DHCPREQUEST for 192.168.100.45 from ec:28:d3:7a:6a:76 via enp1s0 Dec 03 15:40:50 issola dhcpd[24072]: DHCPACK on 192.168.100.45 to ec:28:d3:7a:6a:76 via enp1s0 But that guy is still pointing toward the old router. > > You should probably just perform a hard cut-over. Shutdown the old > router, stand up the new router. After the hard cutover, force clients > to renew their leases (or wait until they do it on their own). And if > things go sideways, undo the change. I may yet do that. The change will consist of pulling the Ethernet cable between the old router and its upstream connection. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: goose DHCP clients to new address Was: DHCP Problem
On Sun, Dec 3, 2023 at 4:51 PM Charles Curley wrote: > > On Sun, 3 Dec 2023 22:14:51 +0100 > Geert Stappers wrote: > > > I assume that the previous router is disconnected from the LAN. > > No. Until I solve this problem (and a few others), I will have clients > using the old router. > > > The DHCProtocol has "release" for such goosing. > > At DHCPclient do "stop DHCP", over the wire goes DHCPRELEASE [0] > > The DHCPclient should forget ( "release" ) previous settings. > > At DHCPclient do "start DHCP", client should get fresh config, > > including the setting for the fresh router. > > I'm not sure how to do this. I did run on a client > > dhclient -r > dhclient > > I observed no changes. > > The -r causes dhclient to release its lease. Invoking dhclient again > should then obtain a new lease. I don't know about Linux clients, but in the past, Windows clients used to try to connect to the previous DHCP server for its lease info. If the old DHCP server is still available (on the old router?), then the client may be getting the lease info from the old server. To avoid the problem, we disconnected the old server from the network. You should probably just perform a hard cut-over. Shutdown the old router, stand up the new router. After the hard cutover, force clients to renew their leases (or wait until they do it on their own). And if things go sideways, undo the change. > > If that is already done, provide information to enable further help. > > Such as name of the DHCP client program and DHCP lease time. > > I am using whatever is standard on Debian Bullseye and Bookworm. > > root@hawk:/etc# pre dhc > isc-dhcp-client 4.4.1-2.3+deb11u2 amd64 > isc-dhcp-common 4.4.1-2.3+deb11u2 amd64 > root@hawk:/etc# > > root@tiassa:~# pre dhc > isc-dhcp-client 4.4.3-P1-2 amd64 > isc-dhcp-common 4.4.3-P1-2 amd64 > root@tiassa:~# > > The client's name is dhclient. > > default-lease-time 86400; # 24 hours > max-lease-time 172800;# 48 hours > > I think for the purposes of experimentation I will shorten those to > half an hour and one hours respectively. Jeff
Re: goose DHCP clients to new address Was: DHCP Problem
On Sun, 3 Dec 2023 22:14:51 +0100 Geert Stappers wrote: > I assume that the previous router is disconnected from the LAN. No. Until I solve this problem (and a few others), I will have clients using the old router. > The DHCProtocol has "release" for such goosing. > At DHCPclient do "stop DHCP", over the wire goes DHCPRELEASE [0] > The DHCPclient should forget ( "release" ) previous settings. > At DHCPclient do "start DHCP", client should get fresh config, > including the setting for the fresh router. I'm not sure how to do this. I did run on a client dhclient -r dhclient I observed no changes. The -r causes dhclient to release its lease. Invoking dhclient again should then obtain a new lease. > > > If that is already done, provide information to enable further help. > Such as name of the DHCP client program and DHCP lease time. I am using whatever is standard on Debian Bullseye and Bookworm. root@hawk:/etc# pre dhc isc-dhcp-client 4.4.1-2.3+deb11u2 amd64 isc-dhcp-common 4.4.1-2.3+deb11u2 amd64 root@hawk:/etc# root@tiassa:~# pre dhc isc-dhcp-client 4.4.3-P1-2 amd64 isc-dhcp-common 4.4.3-P1-2 amd64 root@tiassa:~# The client's name is dhclient. default-lease-time 86400; # 24 hours max-lease-time 172800;# 48 hours I think for the purposes of experimentation I will shorten those to half an hour and one hours respectively. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: DHCP Problem, but where
On Sun, 3 Dec 2023 22:18:22 +0100 Geert Stappers wrote: > Has the DHCP server been restarted? Yes. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: DHCP Problem, but where
On 4/12/23 05:18, Geert Stappers wrote: That triggered me to ask "Has the DHCP server been restarted?" The default behaviour of most dhcp clients when they can't connect to a dhcp server is to maintain the settings from any previous lease. A second default behaviour is for clients to not request new dhcp until their existing dhcp lease has expired. To make sure a new dhcp setting is taken by all clients you need to - reconfigure your dhcp server - restart your dhcp server - check your dhcp server logs for any problems - restart your dhcp clients - check your client dhcp logs to see if the new lease info has been taken. There can be problems where a client with a specific MAC address requests a specific ip address based on a previous lease but the server is unwilling or unable to allocate that address to that MAC. This can be checked in the server and client logs. It may also require flushing the server lease tables and client configs so they can both start out completely fresh.
Re: DHCP Problem
On Sun, 3 Dec 2023 20:56:20 +0100 Marco Moock wrote: > Did you check with a sniffer that the answer from the DHCP includes > the new router address? Not with a sniffer, but I did check the lease file. Neither the router address nor the various lease times changed. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: DHCP Problem, but where
On Sun, Dec 03, 2023 at 04:03:39PM -0500, Henning Follmann wrote: > > On Dec 3, 2023, at 14:31, Charles Curley wrote: > > > > I am installing a new router which seems to work well so far. > > > > I have changed the DHCP server to use the new router's address, and shut > > the server down and restarted it. Existing clients insist on using the > > old router anyway. Is there any way to goose clients into using the new > > one short of manually using the ip route command? > > > > > > Did you flush the old leases from /var/lib/dhcpd ? > Just changing the config is not enough. That triggered me to ask "Has the DHCP server been restarted?" Groeten Geert Stappers -- Silence is hard to parse
goose DHCP clients to new address Was: DHCP Problem
On Sun, Dec 03, 2023 at 12:30:53PM -0700, Charles Curley wrote: > I am installing a new router which seems to work well so far. I assume that the previous router is disconnected from the LAN. > I have changed the DHCP server to use the new router's address, and shut > the server down and restarted it. Existing clients insist on using the > old router anyway. Is there any way to goose clients into using the new > one short of manually using the ip route command? The DHCProtocol has "release" for such goosing. At DHCPclient do "stop DHCP", over the wire goes DHCPRELEASE [0] The DHCPclient should forget ( "release" ) previous settings. At DHCPclient do "start DHCP", client should get fresh config, including the setting for the fresh router. If that is already done, provide information to enable further help. Such as name of the DHCP client program and DHCP lease time. Oh, DHCP lease time: What lease time is the DHCP server providing? Groeten Geert Stappers [0] https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_message_types -- Silence is hard to parse
Re: DHCP Problem
> On Dec 3, 2023, at 14:31, Charles Curley > wrote: > > I am installing a new router which seems to work well so far. > > I have changed the DHCP server to use the new router's address, and shut > the server down and restarted it. Existing clients insist on using the > old router anyway. Is there any way to goose clients into using the new > one short of manually using the ip route command? > > Did you flush the old leases from /var/lib/dhcpd ? Just changing the config is not enough. -H
Re: DHCP Problem
Am 03.12.2023 um 12:30:53 Uhr schrieb Charles Curley: > I have changed the DHCP server to use the new router's address, and > shut the server down and restarted it. Existing clients insist on > using the old router anyway. Is there any way to goose clients into > using the new one short of manually using the ip route command? Did you check with a sniffer that the answer from the DHCP includes the new router address? As long as the lease time of the old lease the route may stay in the routing table.
DHCP Problem
I am installing a new router which seems to work well so far. I have changed the DHCP server to use the new router's address, and shut the server down and restarted it. Existing clients insist on using the old router anyway. Is there any way to goose clients into using the new one short of manually using the ip route command? -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Bullseye (Debian11) doesn't renew dhcp lease
On 23.03.2023 09:36, h...@hanswkraus.com wrote:
Hi,
a pc with a plain vanilla Debian11 doesn't renew the dhcp lease
automatically, I have to do it per hand (systemctl stop ifup@$1.service
&& systemctl start ifup@$1.service).
The "/var/lib/dhcp/dhclient.lan0.leases" file:
===
default-duid "\000\001\000\001+\255\242Y|\020\311\235\007\"";
lease {
interface "lan0";
fixed-address 172.23.139.11;
option subnet-mask 255.255.248.0;
option dhcp-lease-time 7200;
option routers 172.23.136.1;
option dhcp-message-type 5;
option dhcp-server-identifier 172.23.136.1;
option domain-name-servers 172.23.136.1;
option domain-name "kraush.home.arpa";
renew 3 2023/03/22 21:43:33;
rebind 3 2023/03/22 22:28:58;
expire 3 2023/03/22 22:43:58;
}/etc/systemd/network/10-board-1G.link
lease {
interface "lan0";
fixed-address 172.23.139.11;
option subnet-mask 255.255.248.0;
option routers 172.23.136.1;
option dhcp-lease-time 7200;
option dhcp-message-type 5;
option domain-name-servers 172.23.136.1;
option dhcp-server-identifier 172.23.136.1;
option domain-name "kraush.home.arpa";
renew 4 2023/03/23 09:02:59;
rebind 4 2023/03/23 09:51:21;
expire 4 2023/03/23 10:06:21;
}
===
I don't run network manager, the configuration files:
/etc/systemd/network/10-board-1G.link ==
# RJ45, 1G, on board
[Match]
MACAddress=7c:10:c9:9d:07:22
[Link]
Name=lan0
===
/etc/network/interfaces.d/lan0
# /etc/network/interfaces.d/lan0
auto lan0
allow-hotplug lan0
iface lan0 inet dhcp
iface lan0 inet6 dhcp
===
Any help appreciated, Hans
By the way: this is a secondary IP connection. The primary one has a
valid_lft "forever" and with that I don't have any problems.
Bullseye (Debian11) doesn't renew dhcp lease
Hi,
a pc with a plain vanilla Debian11 doesn't renew the dhcp lease
automatically, I have to do it per hand (systemctl stop ifup@$1.service
&& systemctl start ifup@$1.service).
The "/var/lib/dhcp/dhclient.lan0.leases" file:
===
default-duid "\000\001\000\001+\255\242Y|\020\311\235\007\"";
lease {
interface "lan0";
fixed-address 172.23.139.11;
option subnet-mask 255.255.248.0;
option dhcp-lease-time 7200;
option routers 172.23.136.1;
option dhcp-message-type 5;
option dhcp-server-identifier 172.23.136.1;
option domain-name-servers 172.23.136.1;
option domain-name "kraush.home.arpa";
renew 3 2023/03/22 21:43:33;
rebind 3 2023/03/22 22:28:58;
expire 3 2023/03/22 22:43:58;
}/etc/systemd/network/10-board-1G.link
lease {
interface "lan0";
fixed-address 172.23.139.11;
option subnet-mask 255.255.248.0;
option routers 172.23.136.1;
option dhcp-lease-time 7200;
option dhcp-message-type 5;
option domain-name-servers 172.23.136.1;
option dhcp-server-identifier 172.23.136.1;
option domain-name "kraush.home.arpa";
renew 4 2023/03/23 09:02:59;
rebind 4 2023/03/23 09:51:21;
expire 4 2023/03/23 10:06:21;
}
===
I don't run network manager, the configuration files:
/etc/systemd/network/10-board-1G.link ==
# RJ45, 1G, on board
[Match]
MACAddress=7c:10:c9:9d:07:22
[Link]
Name=lan0
===
/etc/network/interfaces.d/lan0
# /etc/network/interfaces.d/lan0
auto lan0
allow-hotplug lan0
iface lan0 inet dhcp
iface lan0 inet6 dhcp
===
Any help appreciated, Hans
Re: dhcp-proxy con dnsmasq
El 2023-01-20 a las 14:28 +0100, trujo escribió: > El jue, 19-01-2023 a las 20:38 +0100, Camaleón escribió: > > El 2023-01-19 a las 13:49 +0100, trujo escribió: > > > > > Estoy intentando ponerlo en marcha (con debian estable). > > > la red en la que esta recibe ipes desde un relay situado en el > > > conmutador. > > > Si en el servidor DHCP pongo la opción 66 (next-server) parece > > > funcionar, si no no funciona. > > > no deberia dar este parametro el proxy-dhcp. > > > mi configuración: > > > port=0 > > > log-dhcp > > > dhcp-no-override > > > enable-tftp > > > dhcp-range=192.168.53.21,proxy > > > dhcp-boot=terminales/bootcode.bin,192.168.53.4,192.168.53.4 > > > interface=red-pxe > > > dhcp-option=66,"192.168.53.4" > > > > > > Si desactivo el dhcp-relay no funciona en absoluto, ¿no deberia > > > funcionar?, ¿donde se le dice cual es el servidor al que debe > > > pedirle > > > la ip? > > > > Hum... así a bote pronto el único valor que no veo definido en la > > configuración es el directorio raíz del servidor TFTP («tftp-root»), > > pero no sé hasta qué punto puede afectar al tener definida la opción > > de > > next-server, no he trabajado nunca con dnsmasq :-? > > > > Echa un vistazo a la wiki de Archlinux que siempre explican de forma > > didáctica cómo configurar cada uno de los servicios que admite > > dnsmasq: > > > > https://wiki.archlinux.org/title/dnsmasq > > > > En cualquier caso, revisa el registro de dnsmaq para ver qué hace > > exactamente el demonio y por qué falla en cada caso (p. ej., cuando > > defines la opción «66» y cuando no). > > > > > Se me olvido copiarlo, pero el problema no es ese el problema, es que > no funciona. > Lo monto en consola para poder depurarlo: > # dnsmasq -d -C /etc/dnsmasq.d/ipxe > dnsmasq: started, version 2.85 DNS disabled > dnsmasq: opciones de compilación: IPv6 GNU-getopt DBus no-UBus i18n > IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC > loop-detect inotify dumpfile > dnsmasq-dhcp: DHCP, proxy on subnet 192.168.53.1 > dnsmasq-dhcp: DHCP, sockets bound exclusively to interface red-pxe > dnsmasq-tftp: TFTP root está /srv/tftp/terminales > dnsmasq-dhcp: 2554010389 available DHCP subnet: > 192.168.53.1/255.255.255.0 > dnsmasq-dhcp: 2554010389 vendor class: PXEClient:Arch:0:UNDI:002001 Si se queda ahí, quizá lo que falle es la carga del PXE, que no lo detecte correctamente y tengas que forzar de alguna manera que lo reconozca para poder iniciar los clientes ligeros. PXE : dnsmasq dhcp proxy not answering [SOLVED] https://bbs.archlinux.org/viewtopic.php?id=254774 Que es básicamente lo que recomienda el artículo de la wiki de Archlinux (apartado de configuración para el servidor PXE). > No llega a arrabcar, si añado en el servidor de DHCP principal, es que > lo que no quiero hacer la opción 66 > En el cliente se ve: > IP-Config: Complete: > device=eth0, hwaddr:xx:xx:xx:xx:xx:xx, ipaddr=192.168.53.13, > mask=255.255.255.0,gw=192.168.53.1 > host=192.168.53.13, domain=ea.ea.ea.ea.ea, nis-domain=(none) > boorserver=0.0.0.0, rootserver=0.0.0.0, rootpath= > nameserver0=8.8.8.8, nameserver1=xxx.xxx.xxx > > > Es decir toma los datos dados por el DHCP principal, > Si desactivo el dhcp-relay del conmutador y hago que dnsmasq actue como > relay añadiendo la linea: > dhcp-relay=192.168.53.4,10.xxx.xxx.xxx > > > # dnsmasq -d -C /etc/dnsmasq.d/ipxe > dnsmasq: started, version 2.85 DNS disabled > dnsmasq: opciones de compilación: IPv6 GNU-getopt DBus no-UBus i18n > IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC > loop-detect inotify dumpfile > dnsmasq-dhcp: DHCP, proxy on subnet 192.168.53.1 > dnsmasq-dhcp: DHCP relay from 192.168.53.4 to 10.xxx.xxx.xxx > dnsmasq-tftp: TFTP root está /srv/tftp/terminales > > Pero el resto es igual, es decir el relay funciona pero el proxy no. > La pagina de Arch que me has dicho ya la habia mirado antes y no aporta > nada, solo que mire en el fichero "/var/lib/misc/dnsmasq.leases" para > ver los arrendamiento, pero ese fichero esta vacío. > > Lo único que no controlo bien es la linea: > dhcp-range=192.168.53.1,proxy > He probado a poner el GW (1), el servidor (192.168.53.4) o una de las > direcciones arrendadas (13), pero el resultado es siempre el mismo, no > funciona ¿De qué tipo de clientes ligeros se trata? Quizá requieran algún tipo de parámetro o configuración concreto, de ahí que forzando la opción 66 se cargue el bootloader y los clientes detecten sin problemas el servidor dnsmasq. Saludos, -- Camaleón
Re: dhcp-proxy con dnsmasq
El jue, 19-01-2023 a las 20:38 +0100, Camaleón escribió: > El 2023-01-19 a las 13:49 +0100, trujo escribió: > > > Estoy intentando ponerlo en marcha (con debian estable). > > la red en la que esta recibe ipes desde un relay situado en el > > conmutador. > > Si en el servidor DHCP pongo la opción 66 (next-server) parece > > funcionar, si no no funciona. > > no deberia dar este parametro el proxy-dhcp. > > mi configuración: > > port=0 > > log-dhcp > > dhcp-no-override > > enable-tftp > > dhcp-range=192.168.53.21,proxy > > dhcp-boot=terminales/bootcode.bin,192.168.53.4,192.168.53.4 > > interface=red-pxe > > dhcp-option=66,"192.168.53.4" > > > > Si desactivo el dhcp-relay no funciona en absoluto, ¿no deberia > > funcionar?, ¿donde se le dice cual es el servidor al que debe > > pedirle > > la ip? > > Hum... así a bote pronto el único valor que no veo definido en la > configuración es el directorio raíz del servidor TFTP («tftp-root»), > pero no sé hasta qué punto puede afectar al tener definida la opción > de > next-server, no he trabajado nunca con dnsmasq :-? > > Echa un vistazo a la wiki de Archlinux que siempre explican de forma > didáctica cómo configurar cada uno de los servicios que admite > dnsmasq: > > https://wiki.archlinux.org/title/dnsmasq > > En cualquier caso, revisa el registro de dnsmaq para ver qué hace > exactamente el demonio y por qué falla en cada caso (p. ej., cuando > defines la opción «66» y cuando no). > > Saludos, > Se me olvido copiarlo, pero el problema no es ese el problema, es que no funciona. Lo monto en consola para poder depurarlo: # dnsmasq -d -C /etc/dnsmasq.d/ipxe dnsmasq: started, version 2.85 DNS disabled dnsmasq: opciones de compilación: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile dnsmasq-dhcp: DHCP, proxy on subnet 192.168.53.1 dnsmasq-dhcp: DHCP, sockets bound exclusively to interface red-pxe dnsmasq-tftp: TFTP root está /srv/tftp/terminales dnsmasq-dhcp: 2554010389 available DHCP subnet: 192.168.53.1/255.255.255.0 dnsmasq-dhcp: 2554010389 vendor class: PXEClient:Arch:0:UNDI:002001 No llega a arrabcar, si añado en el servidor de DHCP principal, es que lo que no quiero hacer la opción 66 En el cliente se ve: IP-Config: Complete: device=eth0, hwaddr:xx:xx:xx:xx:xx:xx, ipaddr=192.168.53.13, mask=255.255.255.0,gw=192.168.53.1 host=192.168.53.13, domain=ea.ea.ea.ea.ea, nis-domain=(none) boorserver=0.0.0.0, rootserver=0.0.0.0, rootpath= nameserver0=8.8.8.8, nameserver1=xxx.xxx.xxx Es decir toma los datos dados por el DHCP principal, Si desactivo el dhcp-relay del conmutador y hago que dnsmasq actue como relay añadiendo la linea: dhcp-relay=192.168.53.4,10.xxx.xxx.xxx # dnsmasq -d -C /etc/dnsmasq.d/ipxe dnsmasq: started, version 2.85 DNS disabled dnsmasq: opciones de compilación: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile dnsmasq-dhcp: DHCP, proxy on subnet 192.168.53.1 dnsmasq-dhcp: DHCP relay from 192.168.53.4 to 10.xxx.xxx.xxx dnsmasq-tftp: TFTP root está /srv/tftp/terminales Pero el resto es igual, es decir el relay funciona pero el proxy no. La pagina de Arch que me has dicho ya la habia mirado antes y no aporta nada, solo que mire en el fichero "/var/lib/misc/dnsmasq.leases" para ver los arrendamiento, pero ese fichero esta vacío. Lo único que no controlo bien es la linea: dhcp-range=192.168.53.1,proxy He probado a poner el GW (1), el servidor (192.168.53.4) o una de las direcciones arrendadas (13), pero el resultado es siempre el mismo, no funciona
dhcp-proxy con dnsmasq
Estoy intentando ponerlo en marcha (con debian estable). la red en la que esta recibe ipes desde un relay situado en el conmutador. Si en el servidor DHCP pongo la opción 66 (next-server) parece funcionar, si no no funciona. no deberia dar este parametro el proxy-dhcp. mi configuración: port=0 log-dhcp dhcp-no-override enable-tftp dhcp-range=192.168.53.21,proxy dhcp-boot=terminales/bootcode.bin,192.168.53.4,192.168.53.4 interface=red-pxe dhcp-option=66,"192.168.53.4" Si desactivo el dhcp-relay no funciona en absoluto, ¿no deberia funcionar?, ¿donde se le dice cual es el servidor al que debe pedirle la ip?
RE: IP por DHCP dejó de funcionar en Debian "bullseye" [RESUELTO - Por ahora...]
Hola, Con el kernel 5.10.0-16 tuve varios problemas. Lo instalé Debian 11 en 3 Hp Proliant DL3810 G7 con 64ram, en uno me dió problemas luego de una actu del kernel... Hice mvarias pruebas y no se solucionaba hasta que opté por bajar e instalar 5.16.0-0.bpo.3-amd64, por ahora no tengo problemas y los que tenía se solucionaron. Sldos, Marcelo.- -Mensaje original- De: JavierDebian [mailto:javier.debian.bb...@gmail.com] Enviado el: lunes, 22 de agosto de 2022 18:06 Para: debian-user-spanish@lists.debian.org Asunto: Re: IP por DHCP dejó de funcionar en Debian "bullseye" [RESUELTO - Por ahora...] El 19/8/22 a las 03:45, Camaleón escribió: > El 2022-08-18 a las 21:59 -0300, JavierDebian escribió: > >> Buenas noches. >> >> Me ha pasado algo extraño. >> Debian 11 "bullseye" con kernel 5.10.0-16-amd64. >> Network-manager prohibido en el sistema, lo odio porque hace lo que quiere. >> Computadora que funciona desde hace 6 años con configuración de red >> por DHCP automática, configurado "a mano" por interfaces. >> resolvconf corriendo como demonio. >> >> Hace un par de días, se puso remolona para tomar dirección IP. >> Reiniciado el enrutador y el equipo un par de veces, lo achaqué a >> problemas del enrutador o del servicio provisto por mi ISP, un CISCO >> Technicolor DPC3848VE DOCSIS 3.0, empresa Flow/Personal/Fibertel Argentina. > > El problema de tener el servidor de DHCP en equipos restringidos > (routers, switches o dispositivos integrados) es que apenas permiten > depurar los errores en caso de presentarse problemas. > >> Hoy hizo lo mismo; intenté la solución anterior y no hubo caso. >> Cambié cable de conexión, sin éxito. >> "¿Será la placa de red?" >> Arranqué Windows desde otra partición; conexión impecable, no es ni >> el cable ni la placa ni el enrutador. >> Arranco un SystemRescueCD, y toma la dirección sin problemas. >> Vuelvo a Debian, no toma dirección IP. >> Levanto una máquina VirtualBox en Debian que corre un Win7 con la red >> en modo puente... toma la dirección sin inconvenientes >> >> Configuro la red en forma manual, con IP fija y todo a mano >> Funciona sin inconvenientes. >> >> Vuelvo atrás, a configurar por DHCP automático; no funciona, pero >> sólo en Debian 11. >> Cambio a kernel 5.10.0-13, no sea que el kernel nuevo tenga algún >> problema, aún siendo "stable"; sigue sin funcionar. >> >> Ahora estoy en modo IP estático, funcionando sin problemas... salvo >> que no puedo volver a DHCP dinámico, porque no funciona. >> >> Para usar la máquina, no me afecta, pero... NO ME GUSTA QUE EL >> SISTEMA HAGA COSAS QUE NO DEBERÍA HACER, O NO HAGA LO QUE SÍ. >> >> Seguiré investigando. >> >> Si a alguno le pasó algo así, escucho sugerencias. > > Yo probaría lo siguiente: > > 1. Fuerza la renovación de la IP, a ver si el Cisco le asigna otra > nueva y se puede configurar el adaptador de red sin problemas. > > Dependiendo de qué cliente dhcp uses (hoy en día me pierdo con tantas > opciones: systemd, dhclient, network-manager...) tendrás que hacer una > cosa u otra para renovar los datos del adaptador: > > Linux Force DHCP Client (dhclient) to Renew IP Address > https://www.cyberciti.biz/faq/howto-linux-renew-dhcp-client-ip-address > / > > 2. A modo de prueba, y si te resulta posible, configura otro servidor > o sistema (router/switch) como servidor DHCP (desconecta el Cisco de > la red para evitar conflictos) a ver si el Debian 11 puede > configurarse preguntando a otro servidor. > > 3. Revisa los registros para ver qué puede estar fallando (syslog, > journalctl) o intenta configurar el adpatador de red desde línea de > órdenes (con dhclient -v...) para ver si tienes más información del > problema, recibes un timeout, etc... > > Saludos, > Tomando en cuenta las indicaciones de Camaleón, procedí a: 1 - Eliminar resolvconf, avahi-autoipd, isc-dhcp-client-ddns e isc-dhcp-client. O sea, todo lo que tenga que ver con manejos automágicos de redes, excepto systemd, por supuesto... (network-manager está prohibido en mi sistema). 2 - Reinstalar resolvconf e isc-dhcp-client. 3 - Reconfigurar nuevamente /etc/interfaces para dirección IP por DHCP. 4 - Reiniciar el equipo. Mágicamente, funciona. Ayer pasó lo mismo en otra máquina que tiene mi hija en su habitación; empezó a no resolver IP. Y ayer, justamente, fue "día de actualización de la PC de la niña". Me huelo a alguna actualización o instalación de algo (?) que desbarató algo otro (?). Gracias. JAP
Re: IP por DHCP dejó de funcionar en Debian "bullseye" [RESUELTO - Por ahora...]
El lun, 22 ago 2022 a la(s) 16:22, Yoel Villarreal (yoe...@nauta.cu) escribió: > > Quizás no fue algo "roto". Quizás fue que no leímos el changelog. El top posting no es lindo Y yo tampoco leí el change log. ¿Qué dice que cambió? Saludos, Antonio Galicia Eram quod es, eris quod sum --
Re: IP por DHCP dejó de funcionar en Debian "bullseye" [RESUELTO - Por ahora...]
El 22 de agosto de 2022 5:06:57 p. m. JavierDebian escribió: El 19/8/22 a las 03:45, Camaleón escribió: El 2022-08-18 a las 21:59 -0300, JavierDebian escribió: Buenas noches. Me ha pasado algo extraño. Debian 11 "bullseye" con kernel 5.10.0-16-amd64. Network-manager prohibido en el sistema, lo odio porque hace lo que quiere. Computadora que funciona desde hace 6 años con configuración de red por DHCP automática, configurado "a mano" por interfaces. resolvconf corriendo como demonio. Hace un par de días, se puso remolona para tomar dirección IP. Reiniciado el enrutador y el equipo un par de veces, lo achaqué a problemas del enrutador o del servicio provisto por mi ISP, un CISCO Technicolor DPC3848VE DOCSIS 3.0, empresa Flow/Personal/Fibertel Argentina. El problema de tener el servidor de DHCP en equipos restringidos (routers, switches o dispositivos integrados) es que apenas permiten depurar los errores en caso de presentarse problemas. Hoy hizo lo mismo; intenté la solución anterior y no hubo caso. Cambié cable de conexión, sin éxito. "¿Será la placa de red?" Arranqué Windows desde otra partición; conexión impecable, no es ni el cable ni la placa ni el enrutador. Arranco un SystemRescueCD, y toma la dirección sin problemas. Vuelvo a Debian, no toma dirección IP. Levanto una máquina VirtualBox en Debian que corre un Win7 con la red en modo puente... toma la dirección sin inconvenientes Configuro la red en forma manual, con IP fija y todo a mano Funciona sin inconvenientes. Vuelvo atrás, a configurar por DHCP automático; no funciona, pero sólo en Debian 11. Cambio a kernel 5.10.0-13, no sea que el kernel nuevo tenga algún problema, aún siendo "stable"; sigue sin funcionar. Ahora estoy en modo IP estático, funcionando sin problemas... salvo que no puedo volver a DHCP dinámico, porque no funciona. Para usar la máquina, no me afecta, pero... NO ME GUSTA QUE EL SISTEMA HAGA COSAS QUE NO DEBERÍA HACER, O NO HAGA LO QUE SÍ. Seguiré investigando. Si a alguno le pasó algo así, escucho sugerencias. Yo probaría lo siguiente: 1. Fuerza la renovación de la IP, a ver si el Cisco le asigna otra nueva y se puede configurar el adaptador de red sin problemas. Dependiendo de qué cliente dhcp uses (hoy en día me pierdo con tantas opciones: systemd, dhclient, network-manager...) tendrás que hacer una cosa u otra para renovar los datos del adaptador: Linux Force DHCP Client (dhclient) to Renew IP Address https://www.cyberciti.biz/faq/howto-linux-renew-dhcp-client-ip-address/ 2. A modo de prueba, y si te resulta posible, configura otro servidor o sistema (router/switch) como servidor DHCP (desconecta el Cisco de la red para evitar conflictos) a ver si el Debian 11 puede configurarse preguntando a otro servidor. 3. Revisa los registros para ver qué puede estar fallando (syslog, journalctl) o intenta configurar el adpatador de red desde línea de órdenes (con dhclient -v...) para ver si tienes más información del problema, recibes un timeout, etc... Saludos, Tomando en cuenta las indicaciones de Camaleón, procedí a: 1 - Eliminar resolvconf, avahi-autoipd, isc-dhcp-client-ddns e isc-dhcp-client. O sea, todo lo que tenga que ver con manejos automágicos de redes, excepto systemd, por supuesto... (network-manager está prohibido en mi sistema). 2 - Reinstalar resolvconf e isc-dhcp-client. 3 - Reconfigurar nuevamente /etc/interfaces para dirección IP por DHCP. 4 - Reiniciar el equipo. Mágicamente, funciona. Ayer pasó lo mismo en otra máquina que tiene mi hija en su habitación; empezó a no resolver IP. Y ayer, justamente, fue "día de actualización de la PC de la niña". Me huelo a alguna actualización o instalación de algo (?) que desbarató algo otro (?). Gracias. JAP Quizás no fue algo "roto". Quizás fue que no leímos el changelog. Enviado con Aqua Mail para Android https://www.aqua-mail.com
Re: IP por DHCP dejó de funcionar en Debian "bullseye" [RESUELTO - Por ahora...]
El 19/8/22 a las 03:45, Camaleón escribió: El 2022-08-18 a las 21:59 -0300, JavierDebian escribió: Buenas noches. Me ha pasado algo extraño. Debian 11 "bullseye" con kernel 5.10.0-16-amd64. Network-manager prohibido en el sistema, lo odio porque hace lo que quiere. Computadora que funciona desde hace 6 años con configuración de red por DHCP automática, configurado "a mano" por interfaces. resolvconf corriendo como demonio. Hace un par de días, se puso remolona para tomar dirección IP. Reiniciado el enrutador y el equipo un par de veces, lo achaqué a problemas del enrutador o del servicio provisto por mi ISP, un CISCO Technicolor DPC3848VE DOCSIS 3.0, empresa Flow/Personal/Fibertel Argentina. El problema de tener el servidor de DHCP en equipos restringidos (routers, switches o dispositivos integrados) es que apenas permiten depurar los errores en caso de presentarse problemas. Hoy hizo lo mismo; intenté la solución anterior y no hubo caso. Cambié cable de conexión, sin éxito. "¿Será la placa de red?" Arranqué Windows desde otra partición; conexión impecable, no es ni el cable ni la placa ni el enrutador. Arranco un SystemRescueCD, y toma la dirección sin problemas. Vuelvo a Debian, no toma dirección IP. Levanto una máquina VirtualBox en Debian que corre un Win7 con la red en modo puente... toma la dirección sin inconvenientes Configuro la red en forma manual, con IP fija y todo a mano Funciona sin inconvenientes. Vuelvo atrás, a configurar por DHCP automático; no funciona, pero sólo en Debian 11. Cambio a kernel 5.10.0-13, no sea que el kernel nuevo tenga algún problema, aún siendo "stable"; sigue sin funcionar. Ahora estoy en modo IP estático, funcionando sin problemas... salvo que no puedo volver a DHCP dinámico, porque no funciona. Para usar la máquina, no me afecta, pero... NO ME GUSTA QUE EL SISTEMA HAGA COSAS QUE NO DEBERÍA HACER, O NO HAGA LO QUE SÍ. Seguiré investigando. Si a alguno le pasó algo así, escucho sugerencias. Yo probaría lo siguiente: 1. Fuerza la renovación de la IP, a ver si el Cisco le asigna otra nueva y se puede configurar el adaptador de red sin problemas. Dependiendo de qué cliente dhcp uses (hoy en día me pierdo con tantas opciones: systemd, dhclient, network-manager...) tendrás que hacer una cosa u otra para renovar los datos del adaptador: Linux Force DHCP Client (dhclient) to Renew IP Address https://www.cyberciti.biz/faq/howto-linux-renew-dhcp-client-ip-address/ 2. A modo de prueba, y si te resulta posible, configura otro servidor o sistema (router/switch) como servidor DHCP (desconecta el Cisco de la red para evitar conflictos) a ver si el Debian 11 puede configurarse preguntando a otro servidor. 3. Revisa los registros para ver qué puede estar fallando (syslog, journalctl) o intenta configurar el adpatador de red desde línea de órdenes (con dhclient -v...) para ver si tienes más información del problema, recibes un timeout, etc... Saludos, Tomando en cuenta las indicaciones de Camaleón, procedí a: 1 - Eliminar resolvconf, avahi-autoipd, isc-dhcp-client-ddns e isc-dhcp-client. O sea, todo lo que tenga que ver con manejos automágicos de redes, excepto systemd, por supuesto... (network-manager está prohibido en mi sistema). 2 - Reinstalar resolvconf e isc-dhcp-client. 3 - Reconfigurar nuevamente /etc/interfaces para dirección IP por DHCP. 4 - Reiniciar el equipo. Mágicamente, funciona. Ayer pasó lo mismo en otra máquina que tiene mi hija en su habitación; empezó a no resolver IP. Y ayer, justamente, fue "día de actualización de la PC de la niña". Me huelo a alguna actualización o instalación de algo (?) que desbarató algo otro (?). Gracias. JAP
Re: IP por DHCP dejó de funcionar en Debian "bullseye"
El 2022-08-18 a las 21:59 -0300, JavierDebian escribió: > Buenas noches. > > Me ha pasado algo extraño. > Debian 11 "bullseye" con kernel 5.10.0-16-amd64. > Network-manager prohibido en el sistema, lo odio porque hace lo que quiere. > Computadora que funciona desde hace 6 años con configuración de red por DHCP > automática, configurado "a mano" por interfaces. > resolvconf corriendo como demonio. > > Hace un par de días, se puso remolona para tomar dirección IP. Reiniciado el > enrutador y el equipo un par de veces, lo achaqué a problemas del enrutador > o del servicio provisto por mi ISP, un CISCO Technicolor DPC3848VE DOCSIS > 3.0, empresa Flow/Personal/Fibertel Argentina. El problema de tener el servidor de DHCP en equipos restringidos (routers, switches o dispositivos integrados) es que apenas permiten depurar los errores en caso de presentarse problemas. > Hoy hizo lo mismo; intenté la solución anterior y no hubo caso. > Cambié cable de conexión, sin éxito. > "¿Será la placa de red?" > Arranqué Windows desde otra partición; conexión impecable, no es ni el cable > ni la placa ni el enrutador. > Arranco un SystemRescueCD, y toma la dirección sin problemas. > Vuelvo a Debian, no toma dirección IP. > Levanto una máquina VirtualBox en Debian que corre un Win7 con la red en > modo puente... toma la dirección sin inconvenientes > > Configuro la red en forma manual, con IP fija y todo a mano > Funciona sin inconvenientes. > > Vuelvo atrás, a configurar por DHCP automático; no funciona, pero sólo en > Debian 11. > Cambio a kernel 5.10.0-13, no sea que el kernel nuevo tenga algún problema, > aún siendo "stable"; sigue sin funcionar. > > Ahora estoy en modo IP estático, funcionando sin problemas... salvo que no > puedo volver a DHCP dinámico, porque no funciona. > > Para usar la máquina, no me afecta, pero... NO ME GUSTA QUE EL SISTEMA HAGA > COSAS QUE NO DEBERÍA HACER, O NO HAGA LO QUE SÍ. > > Seguiré investigando. > > Si a alguno le pasó algo así, escucho sugerencias. Yo probaría lo siguiente: 1. Fuerza la renovación de la IP, a ver si el Cisco le asigna otra nueva y se puede configurar el adaptador de red sin problemas. Dependiendo de qué cliente dhcp uses (hoy en día me pierdo con tantas opciones: systemd, dhclient, network-manager...) tendrás que hacer una cosa u otra para renovar los datos del adaptador: Linux Force DHCP Client (dhclient) to Renew IP Address https://www.cyberciti.biz/faq/howto-linux-renew-dhcp-client-ip-address/ 2. A modo de prueba, y si te resulta posible, configura otro servidor o sistema (router/switch) como servidor DHCP (desconecta el Cisco de la red para evitar conflictos) a ver si el Debian 11 puede configurarse preguntando a otro servidor. 3. Revisa los registros para ver qué puede estar fallando (syslog, journalctl) o intenta configurar el adpatador de red desde línea de órdenes (con dhclient -v...) para ver si tienes más información del problema, recibes un timeout, etc... Saludos, -- Camaleón
IP por DHCP dejó de funcionar en Debian "bullseye"
Buenas noches. Me ha pasado algo extraño. Debian 11 "bullseye" con kernel 5.10.0-16-amd64. Network-manager prohibido en el sistema, lo odio porque hace lo que quiere. Computadora que funciona desde hace 6 años con configuración de red por DHCP automática, configurado "a mano" por interfaces. resolvconf corriendo como demonio. Hace un par de días, se puso remolona para tomar dirección IP. Reiniciado el enrutador y el equipo un par de veces, lo achaqué a problemas del enrutador o del servicio provisto por mi ISP, un CISCO Technicolor DPC3848VE DOCSIS 3.0, empresa Flow/Personal/Fibertel Argentina. Hoy hizo lo mismo; intenté la solución anterior y no hubo caso. Cambié cable de conexión, sin éxito. "¿Será la placa de red?" Arranqué Windows desde otra partición; conexión impecable, no es ni el cable ni la placa ni el enrutador. Arranco un SystemRescueCD, y toma la dirección sin problemas. Vuelvo a Debian, no toma dirección IP. Levanto una máquina VirtualBox en Debian que corre un Win7 con la red en modo puente... toma la dirección sin inconvenientes Configuro la red en forma manual, con IP fija y todo a mano Funciona sin inconvenientes. Vuelvo atrás, a configurar por DHCP automático; no funciona, pero sólo en Debian 11. Cambio a kernel 5.10.0-13, no sea que el kernel nuevo tenga algún problema, aún siendo "stable"; sigue sin funcionar. Ahora estoy en modo IP estático, funcionando sin problemas... salvo que no puedo volver a DHCP dinámico, porque no funciona. Para usar la máquina, no me afecta, pero... NO ME GUSTA QUE EL SISTEMA HAGA COSAS QUE NO DEBERÍA HACER, O NO HAGA LO QUE SÍ. Seguiré investigando. Si a alguno le pasó algo así, escucho sugerencias. Gracias. JAP
Re: Alternatives to ISC dhcp-client ?
john doe writes: [...] >> > > You might be better off asking this on the appropriate mailing list! :) I asked: https://lists.freedesktop.org/archives/systemd-devel/2022-May/047889.html My impressions: 1. Scripts called by dhcp client are "BAD THING" (according to systemd developers) - and systemd-networkd will not handle it 2. systemd-networkd lacks of some functionality I need, and I doubt it will have (bridge without interfaces, partial nat and so on) So for now I will use isc-dhcp-client until it will be impossible. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Re: SUCESSFUL INSTALL - was [Discovering DHCP hostname during original system installation]
On 2022-06-02, David Wright wrote: > >> I still owe David a response to his last post. > > No need. The above clears up the point made in the body of your OP, > and I have nothing more to add on the Subject line, as what I've > already posted pretty much exhausts my knowledge of DHCP. People do usually suggest that you don't put your question in the Subject line but rather in the body. Of course, "Discovering DHCP hostname during original system installation" isn't a question, either (not that I understand what the dhcp hostname could possibly have to do with anything if it was indeed one). > Cheers, David. > >
Re: SUCESSFUL INSTALL - was [Discovering DHCP hostname during original system installation]
On Thu 02 Jun 2022 at 08:53:12 (-0500), Richard Owlett wrote: > On 05/31/2022 08:13 AM, Richard Owlett wrote: > > I'm using firmware-11.3.0-amd64-netinst.iso to install Debian onto > > a Lenovo T510 [Thinkpad]. > > > > I know the netinstaller works on this laptop as I have done a > > successful install when within range of of local library's wifi > > and the installer is successfully detecting multiple local wifi > > sources. > > > > I am doing a fresh install from home using an Alcatel Linkzone to > > connect to my T-mobile account. I have had no problems doing this > > with standard netinstallers. > > > > After an install over library wifi the system had no problem > > connecting to the internet via the Linkzone. > > This is just a status report. > The above referenced installer *WILL* work when the target machine is > connected to the internet via an Alcatel Linkzone. > > The failed installs were evidently triggered by the immediately > previous Linkzone usage history. So it would appear that these unsupported statements: . it effectively reacts as a traditional modem . The Alcatel [with WiFi disabled] is physically plugged into a USB port. To the unsophisticated user there is no way to distinguish it from a modem which has auto-dialed a specific server. have been contradicted by observation. > I still owe David a response to his last post. No need. The above clears up the point made in the body of your OP, and I have nothing more to add on the Subject line, as what I've already posted pretty much exhausts my knowledge of DHCP. Cheers, David.
SUCESSFUL INSTALL - was [Discovering DHCP hostname during original system installation]
On 05/31/2022 08:13 AM, Richard Owlett wrote: I'm using firmware-11.3.0-amd64-netinst.iso to install Debian onto a Lenovo T510 [Thinkpad]. I know the netinstaller works on this laptop as I have done a successful install when within range of of local library's wifi and the installer is successfully detecting multiple local wifi sources. I am doing a fresh install from home using an Alcatel Linkzone to connect to my T-mobile account. I have had no problems doing this with standard netinstallers. After an install over library wifi the system had no problem connecting to the internet via the Linkzone. Help please. TIA This is just a status report. The above referenced installer *WILL* work when the target machine is connected to the internet via an Alcatel Linkzone. The failed installs were evidently triggered by the immediately previous Linkzone usage history. I should be able to write a test procedure to prove/disprove my theory. The decades spent in hardware testing gave me practice in procedure writing. [I just don't have much software background.] I hope to have the procedure written and proven by early next week. I still owe David a response to his last post.
Re: Discovering DHCP hostname during original system installation
On Wed 01 Jun 2022 at 06:32:07 (-0500), Richard Owlett wrote: > On 05/31/2022 11:20 PM, David Wright wrote: > > On Tue 31 May 2022 at 14:00:51 (-0500), Richard Owlett wrote: > > > On 05/31/2022 11:13 AM, David Wright wrote: > > > > On Tue 31 May 2022 at 08:13:57 (-0500), Richard Owlett wrote: > [ … ] There is also an unwarranted > assumption that I resemble a "normal" Debian user. If I'm the one who's meant to be assuming, nothing could be further from the truth. > Though of late I've > tended to use a particular machine - I have a half dozen available. > > The the _current_ install process is on a machine explicitly dedicated > to learning by experimentation. It has had at least a dozen full > installs from scratch - no more than 3 coexisting at a time. Yes, that's why I presumed that any firmware requirement could be supplied by yourself, from one of your installations at the very least. > I religiously avoid any networking of my personal machines. > Up to this current experiment I have avoided any intentional use of > WiFi. This has been made easier by the majority of my machines > requiring non-free drivers. Again, the OP never made any mention of this. > I tried to succinctly state MY topic in the Subject line. > When The DHCP auto-detection during install fails, > "How do I manually discover DHCP [server] hostname(s)?" Ah, now, I recognise /that/ as a question. > > Is that fair, and am I correct in pointing out that you still haven't > > stated how the laptop is connected to the internet, > > The Alcatel [with WiFi disabled] is physically plugged into a USB port. > To the unsophisticated user there is no way to distinguish it from a > modem which has auto-dialed a specific server. > > > but that it's not > > with a cat5 cable. > As stated in this post the particular machine is dedicated to > EXPERIMENTATION. The goal of the experimentation is to be able to > describe how the Debian installation process could simultaneously be > simpler and more versatile. [Decades in engineering support (hardware > not software) informs me that is not easy ;] Yes, but all too often, we are given a tiny glimpse of your experiment, and then expected to supply fixes and reading lists precisely relevant to whatever your experiment is meant to be doing. > Did I succeed at all? This time. Well, the way I would tackle this problem is to run dhcp_probe on the interface name given by ip a, from which I'd get a dotted quad, like 192.168.1.1. Then I'd run host 192.168.1.1 and would get a result like 1.1.168.192.in-addr.arpa domain name pointer www.routerlogin.com. I think in your case you'd probably get mobile.hotspot—perhaps. I'm not sure what use that is to you. You can get that domain out of the instruction manual. IIRC my router answers to the example I gave, but I always use the hostname that I set up in my /etc/hosts, because I have two routers from the same manufacturer, so www.routerlogin.com would be ambiguous. Or I can use the dotted quads themselves, ….1 and ….2. But that's all in aid of logging in and configuring them, not for when I'm asking them (one, actually) for DHCP service. AFAIK, the hostname of a DHCP server is not particularly useful to you, in that the negotiations are commenced by the client broadcasting over the link, to which the server should respond. (I take it you're not trying to run a DHCP server yourself on one of your machines.) In all the joints in all the towns in all the world, I don't recall ever finding out what the hostnames of their DHCP servers were. But I know nothing about how these negotiations take place on your USB connection. Do you see them progressing, or failing, in your daemon.log, as I do? (ToD Host) dhclient[531]: DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 12 (ToD Host) sh[531]: DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 12 (ToD Host) dhclient[531]: DHCPOFFER of 192.168.1.14 from 192.168.1.1 (ToD Host) sh[531]: DHCPOFFER of 192.168.1.14 from 192.168.1.1 (ToD Host) sh[531]: DHCPREQUEST for 192.168.1.14 on enp3s0 to 255.255.255.255 port 67 (ToD Host) dhclient[531]: DHCPREQUEST for 192.168.1.14 on enp3s0 to 255.255.255.255 port 67 (ToD Host) dhclient[531]: DHCPACK of 192.168.1.14 from 192.168.1.1 (ToD Host) sh[531]: DHCPACK of 192.168.1.14 from 192.168.1.1 (ToD Host) avahi-daemon[568]: Joining mDNS multicast group on interface enp3s0.IPv4 with address 192.168.1.14. (ToD Host) avahi-daemon[568]: New relevant interface enp3s0.IPv4 for mDNS. (ToD Host) avahi-daemon[568]: Registering new address record for 192.168.1.14 on enp3s0.IPv4. Cheers, David.
Re: Discovering DHCP hostname during original system installation
On Wed 01 Jun 2022 at 06:32:07 -0500, Richard Owlett wrote: [...] > As stated in this post the particular machine is dedicated to > EXPERIMENTATION. The goal of the experimentation is to be able to describe > how the Debian installation process could simultaneously be simpler and more > versatile. [Decades in engineering support (hardware not software) informs > me that is not easy ;] Perhaps it is not too easy, but that could be because d-i is already versatile enough to accomodate changes. Making it simpler? Have you any suggestions after carrying out your recent experimental regime? -- Brian
Re: Discovering DHCP hostname during original system installation
On 05/31/2022 02:00 PM, Richard Owlett wrote: *SNIP* I am doing a fresh install from home using an Alcatel Linkzone to connect to my T-mobile account. I have had no problems doing this with standard netinstallers. ? That seems to be a new interpretation of the thread: https://lists.debian.org/debian-user/2021/10/msg00571.html From reading https://lists.debian.org/debian-user/2021/10/msg00603.html in that thread, I don't think so. That thread referred ti a standard [i.e. free] netinst iso. This case is using the non-free firmware. I will have to carefully read the entire thread to see if it has point(s) in common. I've a dozen more posts to (re)read in the thread. I'm beginning to suspect appreciation of comments about "CDC Ethernet" will be key. [Especially posts by Tixy] I've at least a dozen web references marked for "CDC Ethernet". I have information overload. Suspect meaningful comprehension will take a couple of days ;/ More later.
Re: Discovering DHCP hostname during original system installation
On 05/31/2022 11:20 PM, David Wright wrote:
On Tue 31 May 2022 at 14:00:51 (-0500), Richard Owlett wrote:
On 05/31/2022 11:13 AM, David Wright wrote:
On Tue 31 May 2022 at 08:13:57 (-0500), Richard Owlett wrote:
I'm using firmware-11.3.0-amd64-netinst.iso to install Debian onto a
Lenovo T510 [Thinkpad].
✓
I know the netinstaller works on this laptop as I have done a
successful install when within range of of local library's wifi and
the installer is successfully detecting multiple local wifi sources.
Which netinstaller?
The one *STATED* in the first sentence!
Demonstrative pronouns help.
Yep. I realized that as soon as I read your reply ;{
My writing skills have been a problem since school days back in 50's.
In the next paragraph, you use the term "standard
netinstaller". Does this mean one without firmware?
Of course!
Ok, usually called official here. /My/ standard installer is a firmware
one, as the official ones are a waste of download bandwidth for me.
They only work for a couple of my machines.
I am doing a fresh install from home using an Alcatel Linkzone to
connect to my T-mobile account. I have had no problems doing this with
standard netinstallers.
? That seems to be a new interpretation of the thread:
https://lists.debian.org/debian-user/2021/10/msg00571.html
From reading
https://lists.debian.org/debian-user/2021/10/msg00603.html in that
thread, I don't think so.
The key sentence in that post is:
"I just discovered that one of my problems [selecting a Grub menu
entry resulting in an infinite loop until Linkzone unplugged]
had been solved at Debian 10.7 or earlier."
That thread referred to a standard [i.e.
free] netinst iso. This case is using the non-free firmware. I will
have to carefully read the entire thread to see if it has point(s) in
common.
Well, if you have successfully installed at /home/ using the /Alcatel/
and with an /official installer/, then the same success is expected
with the firmware installer, whose difference is just extra packages
in the pool.
I had assumed so [but *not* known]. That's why I quoted the significant
sentence from the sub-thread above. Sometime circa Squeeze or later
there appears to have been a subtle change in how/when[?] a fully
installed Debian initializes a connected intelligent USB device [i.e.
the Alcatel]. I don't have enough background to say more.
What's unsaid here is /how/ you use your Alcatel Linkzone to connect.
As I use it daily - it effectively reacts as a traditional modem [the
wifi aspect disabled].
Well, disabling wifi (not revealed in your OP) was what gave problems
that caused you to post here in the past.
*NO*!
You are assuming commonality of hardware/software/goals/other over the
last decade that simply does not exist. There is also an unwarranted
assumption that I resemble a "normal" Debian user. Though of late I've
tended to use a particular machine - I have a half dozen available.
The the _current_ install process is on a machine explicitly dedicated
to learning by experimentation. It has had at least a dozen full
installs from scratch - no more than 3 coexisting at a time.
I religiously avoid any networking of my personal machines.
Up to this current experiment I have avoided any intentional use of
WiFi. This has been made easier by the majority of my machines requiring
non-free drivers.
The third paragraph in this
thread's OP implies that these problems have been overcome, and that
the current thread might be something about official vs firmware
rather than, say wifi vs ethernet in the normal scenario, or wifi vs
some sort of ?USB link in your case.
No ;/
I tried to succinctly state MY topic in the Subject line.
When The DHCP auto-detection during install fails,
"How do I manually discover DHCP hostname(s)?"
Is that fair, and am I correct in pointing out that you still haven't
stated how the laptop is connected to the internet,
The Alcatel [with WiFi disabled] is physically plugged into a USB port.
To the unsophisticated user there is no way to distinguish it from a
modem which has auto-dialed a specific server.
but that it's not
with a cat5 cable.
After an install over library wifi the system had no problem
connecting to the internet via the Linkzone.
/
So what's your question? And if it's meant to be the Subject line,
I don't see any relationship with the rest of the post.
My entire problem is in the context of running the installer.
Yes, I know you have a problem. And "install" is in the Subject line,
and peppered throughout the OP. Saying you have an installation
problem is not a question. It's the old "What did you expect/observe"
and "Why did they differ".
My question is why are you trying to install it again?
As stated in this post the particular machine is dedicated to
EXPERIMENTATION. The goal of the experimentation is to be able to
describ
Re: Discovering DHCP hostname during original system installation
On Tue 31 May 2022 at 14:00:51 (-0500), Richard Owlett wrote: > On 05/31/2022 11:13 AM, David Wright wrote: > > On Tue 31 May 2022 at 08:13:57 (-0500), Richard Owlett wrote: > > > I'm using firmware-11.3.0-amd64-netinst.iso to install Debian onto a > > > Lenovo T510 [Thinkpad]. > > > > ✓ > > > > > I know the netinstaller works on this laptop as I have done a > > > successful install when within range of of local library's wifi and > > > the installer is successfully detecting multiple local wifi sources. > > > > Which netinstaller? > > The one *STATED* in the first sentence! Demonstrative pronouns help. > > In the next paragraph, you use the term "standard > > netinstaller". Does this mean one without firmware? > > Of course! Ok, usually called official here. /My/ standard installer is a firmware one, as the official ones are a waste of download bandwidth for me. They only work for a couple of my machines. > > > I am doing a fresh install from home using an Alcatel Linkzone to > > > connect to my T-mobile account. I have had no problems doing this with > > > standard netinstallers. > > > > ? That seems to be a new interpretation of the thread: > > https://lists.debian.org/debian-user/2021/10/msg00571.html > > From reading > https://lists.debian.org/debian-user/2021/10/msg00603.html in that > thread, I don't think so. That thread referred ti a standard [i.e. > free] netinst iso. This case is using the non-free firmware. I will > have to carefully read the entire thread to see if it has point(s) in > common. Well, if you have successfully installed at /home/ using the /Alcatel/ and with an /official installer/, then the same success is expected with the firmware installer, whose difference is just extra packages in the pool. > > What's unsaid here is /how/ you use your Alcatel Linkzone to connect. > > As I use it daily - it effectively reacts as a traditional modem [the > wifi aspect disabled]. Well, disabling wifi (not revealed in your OP) was what gave problems that caused you to post here in the past. The third paragraph in this thread's OP implies that these problems have been overcome, and that the current thread might be something about official vs firmware rather than, say wifi vs ethernet in the normal scenario, or wifi vs some sort of ?USB link in your case. Is that fair, and am I correct in pointing out that you still haven't stated how the laptop is connected to the internet, but that it's not with a cat5 cable. > > > After an install over library wifi the system had no problem > > > connecting to the internet via the Linkzone. > > / > > So what's your question? And if it's meant to be the Subject line, > > I don't see any relationship with the rest of the post. > > My entire problem is in the context of running the installer. Yes, I know you have a problem. And "install" is in the Subject line, and peppered throughout the OP. Saying you have an installation problem is not a question. It's the old "What did you expect/observe" and "Why did they differ". > > My question is why are you trying to install it again? > > 'Cause I want a very different OS configuration. This Thinkpad is a > test-bed machine. > > > And if your > > problem, whatever it is, is to do with the firmware version (I can't > > see why extra packages would trip anything up), why do you need it: > > you've already got all those packages at home anyway. > > HUH? ?? ??? If you're installing with a firmware netinst, it has the firmware in it. If you're installing with an official netinst, you've got the firmware packages in one of the firmware netinsts that you've used in the past. If the laptop has another installation of Debian in a different partition, then the firmware it needs is going to be in that partition's /lib/firmware. Judging from the likelihood that you've installed Debian more times than any other regular on the list, I reckon you can find the firmware for your machines whenever you need to. That point clarified, I still don't see a hint of a question, particularly one that bears any relevance to the Subject line. Cheers, David.
Re: Discovering DHCP hostname during original system installation
On 05/31/2022 11:13 AM, David Wright wrote: On Tue 31 May 2022 at 08:13:57 (-0500), Richard Owlett wrote: I'm using firmware-11.3.0-amd64-netinst.iso to install Debian onto a Lenovo T510 [Thinkpad]. ✓ I know the netinstaller works on this laptop as I have done a successful install when within range of of local library's wifi and the installer is successfully detecting multiple local wifi sources. Which netinstaller? The one *STATED* in the first sentence! In the next paragraph, you use the term "standard netinstaller". Does this mean one without firmware? Of course! I am doing a fresh install from home using an Alcatel Linkzone to connect to my T-mobile account. I have had no problems doing this with standard netinstallers. ? That seems to be a new interpretation of the thread: https://lists.debian.org/debian-user/2021/10/msg00571.html From reading https://lists.debian.org/debian-user/2021/10/msg00603.html in that thread, I don't think so. That thread referred ti a standard [i.e. free] netinst iso. This case is using the non-free firmware. I will have to carefully read the entire thread to see if it has point(s) in common. What's unsaid here is /how/ you use your Alcatel Linkzone to connect. As I use it daily - it effectively reacts as a traditional modem [the wifi aspect disabled]. After an install over library wifi the system had no problem connecting to the internet via the Linkzone. / So what's your question? And if it's meant to be the Subject line, I don't see any relationship with the rest of the post. My entire problem is in the context of running the installer. My question is why are you trying to install it again? 'Cause I want a very different OS configuration. This Thinkpad is a test-bed machine. And if your problem, whatever it is, is to do with the firmware version (I can't see why extra packages would trip anything up), why do you need it: you've already got all those packages at home anyway. HUH? ?? ??? Cheers, David.
Re: Discovering DHCP hostname during original system installation
On Tue 31 May 2022 at 08:13:57 (-0500), Richard Owlett wrote: > I'm using firmware-11.3.0-amd64-netinst.iso to install Debian onto a > Lenovo T510 [Thinkpad]. ✓ > I know the netinstaller works on this laptop as I have done a > successful install when within range of of local library's wifi and > the installer is successfully detecting multiple local wifi sources. Which netinstaller? In the next paragraph, you use the term "standard netinstaller". Does this mean one without firmware? > I am doing a fresh install from home using an Alcatel Linkzone to > connect to my T-mobile account. I have had no problems doing this with > standard netinstallers. ? That seems to be a new interpretation of the thread: https://lists.debian.org/debian-user/2021/10/msg00571.html What's unsaid here is /how/ you use your Alcatel Linkzone to connect. > After an install over library wifi the system had no problem > connecting to the internet via the Linkzone. So what's your question? And if it's meant to be the Subject line, I don't see any relationship with the rest of the post. My question is why are you trying to install it again? And if your problem, whatever it is, is to do with the firmware version (I can't see why extra packages would trip anything up), why do you need it: you've already got all those packages at home anyway. Cheers, David.
Discovering DHCP hostname during original system installation
I'm using firmware-11.3.0-amd64-netinst.iso to install Debian onto a Lenovo T510 [Thinkpad]. I know the netinstaller works on this laptop as I have done a successful install when within range of of local library's wifi and the installer is successfully detecting multiple local wifi sources. I am doing a fresh install from home using an Alcatel Linkzone to connect to my T-mobile account. I have had no problems doing this with standard netinstallers. After an install over library wifi the system had no problem connecting to the internet via the Linkzone. Help please. TIA
Re: Alternatives to ISC dhcp-client ?
Dan Ritter writes: > The package name is udhcpc. Yes, and it's very cool. Well, poorly documented so it was a little hard to understand. Mostly my problem was the script it wants to run for various events and how to fix that to do the stuff I need and not do stuff that messes up my network setup. But in my case udhcpc seems to be the only DHCP client that will talk to the LTE module in my router, others just balk and whine.
Re: Alternatives to ISC dhcp-client ?
On 2022-05-08 11:19:33 +0800, Jeremy Ardley wrote: > Of note: Using systemd-networkd you should not use NetworkManager or > networking services. I think both use the ISC dhcp client And what about NetworkManager users? Note: it has its own internal DHCP client, but it is not robust on buggy networks: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933930 And the dhclient hooks are not run: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966618 So I don't use it. In particular, in my /etc/dhcp/dhclient.conf isc-dhcp-client configuration file, I have prepend domain-name-servers 127.0.0.1; to be able to use the local nameserver preferably (the nameservers provided by the DHCP server are still needed on networks that filter UDP). -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Alternatives to ISC dhcp-client ?
On 5/8/2022 6:33 PM, Kamil Jońca wrote: Kamil Jońca writes: [...] But systemd-networkd also has a huge number of configuration options that may do what you want anyway https://www.freedesktop.org/software/systemd/man/systemd.network.html Hm. Can you create bridge without ports with systemd-networkd? i.e. Another question. Can I pass option during interface up/down? For example, in my if-up*/if-down* scripts I have code for replacing (or not!) default route when needed.[1] Then I can execute something like: --8<---cut here---start->8--- ifup wlan0 -o replacedefaultroute=on --8<---cut here---end--->8--- how I can achieve this with networkctl (or other systemd tool)? Moreover https://gitlab.com/craftyguy/networkd-dispatcher/-/issues/61 So my migration probes are not very promising :/ I take into account that I have some habits and some thing should be done completely different way[2]. But for now I even don't know if some things can be achieved. You might be better off asking this on the appropriate mailing list! :) -- John Doe
Re: Alternatives to ISC dhcp-client ?
Kamil Jońca writes: [...] >> >> But systemd-networkd also has a huge number of configuration options >> that may do what you want anyway >> >> https://www.freedesktop.org/software/systemd/man/systemd.network.html > > Hm. Can you create bridge without ports with systemd-networkd? > i.e. > Another question. Can I pass option during interface up/down? For example, in my if-up*/if-down* scripts I have code for replacing (or not!) default route when needed.[1] Then I can execute something like: --8<---cut here---start->8--- ifup wlan0 -o replacedefaultroute=on --8<---cut here---end--->8--- how I can achieve this with networkctl (or other systemd tool)? Moreover https://gitlab.com/craftyguy/networkd-dispatcher/-/issues/61 So my migration probes are not very promising :/ I take into account that I have some habits and some thing should be done completely different way[2]. But for now I even don't know if some things can be achieved. KJ [1] in man systemd.network I found --8<---cut here---start->8--- [DHCPV4] UseRoutes= --8<---cut here---end--->8--- but I am not sure if this is about default routes or only classless static routes [2] - I had to spent some time to "properly" translate my iptables rules/scripts to nftables ones (using sets and maps instead simple iptables -I ... nad iptables -D ... command). -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Re: Alternatives to ISC dhcp-client ?
On Sun, May 08, 2022 at 04:09:27PM +0200, Oliver Schoede wrote: Alternatively there's dhcpcd5, Be careful with this one unless you have a simple network configuration--by default it will attempt to get addresses on all interfaces that don't have them, not only ones you set to dhcp in /etc/network/interfaces
Re: Alternatives to ISC dhcp-client ?
On Sun, 8 May 2022 09:20:25 -0400 Dan Ritter wrote: > Stefan Monnier wrote: > > Rick Thomas [2022-05-07 19:47:57] wrote: > > > According to the ISC webpage: > > >> ISC has ended development on the ISC DHCP client as of early > > >> 2022. This client implementation is no longer maintained and > > >> should not be used in production any longer. > > > Can anybody recommend a good replacement? > > > > Depends on your needs, but `busybox` provides a dhcp client that's > > good enough for the most common situations. > > > The package name is udhcpc. > > -dsr- > Right, it's not (yet?) tagged for provides/dhcp-client but at home would probably do the trick for me, too. Alternatively there's dhcpcd5, which is tagged and also specifically mentioned on the ISC's eom-page, though apparently a much broader solution. I'll be using the legacy one until it's actually removed from Debian and then switch to whatever is recommended, if anything and provided it's not networkd. Oliver https://roy.marples.name/projects/dhcpcd
Re: Alternatives to ISC dhcp-client ?
Stefan Monnier wrote: > Rick Thomas [2022-05-07 19:47:57] wrote: > > According to the ISC webpage: > >> ISC has ended development on the ISC DHCP client as of early 2022. > >> This client implementation is no longer maintained and should not be > >> used in production any longer. > > Can anybody recommend a good replacement? > > Depends on your needs, but `busybox` provides a dhcp client that's good > enough for the most common situations. The package name is udhcpc. -dsr-
Re: Alternatives to ISC dhcp-client ?
On 2022-05-08 at 07:06, Rick Thomas wrote: > On Sat, May 7, 2022, at 7:47 PM, Rick Thomas wrote: > >> According to the ISC webpage: >> >>> ISC has ended development on the ISC DHCP client as of early >>> 2022. This client implementation is no longer maintained and >>> should not be used in production any longer. >> >> Can anybody recommend a good replacement? Does anybody know what >> the Debian PTBs are planning for this? >> >> Thanks! Rick > > Does anybody know what the Debian developers plan to do about this > change of policy by ISC? I have a feeling it's going to be a problem > that will have to be faced reasonably soon. I remember reading a discussion on debian-devel recent-ish-ly which could be relevant. I haven't reviewed it in detail at the moment, but I think https://lists.debian.org/debian-devel/2021/09/msg00407.html would be a good starting point for anyone who does want to review it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Alternatives to ISC dhcp-client ?
On Sat, May 7, 2022, at 7:47 PM, Rick Thomas wrote: > According to the ISC webpage: > >> ISC has ended development on the ISC DHCP client as of early 2022. >> This client implementation is no longer maintained and should not be >> used in production any longer. > > Can anybody recommend a good replacement? > Does anybody know what the Debian PTBs are planning for this? > > Thanks! > Rick Does anybody know what the Debian developers plan to do about this change of policy by ISC? I have a feeling it's going to be a problem that will have to be faced reasonably soon. Rick
Re: Alternatives to ISC dhcp-client ?
Jeremy Ardley writes: > On 8/5/22 3:19 pm, Kamil Jońca wrote: >> I cannot see if systemd-networkd can run scripts[1] after change in >> lease. Am I missing something? >> > The top answer below is a partial answer to your question. > > https://unix.stackexchange.com/questions/469716/systemd-networkd-run-script-after-dhcp-client-aqcuires-new-address You mean: "I couldn't get networkd-dispatcher to respond to dhcp changes on Ubuntu Server 20.04, but[...] " :) ? Yes. I know that this is two year old, but I did not found anything newer with answer. > > But systemd-networkd also has a huge number of configuration options > that may do what you want anyway > > https://www.freedesktop.org/software/systemd/man/systemd.network.html Hm. Can you create bridge without ports with systemd-networkd? i.e. --8<---cut here---start->8--- iface qemu inet static dns-search myquemudomain address 192.168.1.1 netmask 255.255.255.0 bridge_ports none #part which I was not able to achieve --8<---cut here---end--->8--- I still have situation described in https://lists.debian.org/debian-user/2022/02/msg00118.html I simply try to look for migration, but it seems that most of testing I will have to do by myself. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Re: Alternatives to ISC dhcp-client ?
On 8/5/22 2:27 pm, Rick Thomas wrote: Thanks! Rick PS: I'll also do the IPv6 part, because I'm interested in that too. One word of caution moving away from ISC dhcp client is that any possibility of it being started by the networking daemon will result in very bad behaviour if you have any left-over lease files - whether or not you have dhcp set in your /etc/network.interfaces file In that case, the dhcp server will be spammed many times a second by dhclient. I'll amend my blog post to stop the networking service, kill any dhclient processes, and then erase any dhclient lease files rm -f /var/lib/dhcp/dhclient* -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: Alternatives to ISC dhcp-client ?
On 8/5/22 3:19 pm, Kamil Jońca wrote: I cannot see if systemd-networkd can run scripts[1] after change in lease. Am I missing something? The top answer below is a partial answer to your question. https://unix.stackexchange.com/questions/469716/systemd-networkd-run-script-after-dhcp-client-aqcuires-new-address But systemd-networkd also has a huge number of configuration options that may do what you want anyway https://www.freedesktop.org/software/systemd/man/systemd.network.html -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: Alternatives to ISC dhcp-client ?
Jeremy Ardley writes: [...] > > You can just use systemd-networkd as an IPv4 dhcp client. I cannot see if systemd-networkd can run scripts[1] after change in lease. Am I missing something? KJ [1] similar to /etc/dhcp/dhclient*hooks.d -- http://wolnelektury.pl/wesprzyj/teraz/
Re: Alternatives to ISC dhcp-client ?
On 5/8/2022 5:24 AM, Rick Thomas wrote: On Sat, May 7, 2022, at 8:14 PM, Jeremy Ardley wrote: On 8/5/22 10:47 am, Rick Thomas wrote: ISC has ended development on the ISC DHCP client as of early 2022. This client implementation is no longer maintained and should not be used in production any longer. Can anybody recommend a good replacement? I presently use systemd-networkd which provides its own DHCP v4 and v6 clients, and servers if you want. In my network my dual homed router acts as a dhcp client to the ISP and gets an IPv4 address and is delegated an IPv6 /56 range. You can just use systemd-networkd as an IPv4 dhcp client. Jeremy Is systemd-networkd automatically installed by Debian? I ask because my "testing" and "stable" systems all show isc-dhcp-client as installed and running. For a regular installation of Debian, yes. -- John Doe
Re: Alternatives to ISC dhcp-client ?
On Sat, May 7, 2022, at 9:37 PM, Jeremy Ardley wrote: > On 8/5/22 11:27 am, Rick Thomas wrote: >> Thanks for the heads up! >> Can you describe in detail what one needs to do in order to switch over? >> I.e. what to remove, what to install? What to configure? > > This is a recent blogpost of mine showing a more complex installation > including IPv6 delegation. If you just do the bits that refer to IPv4 it > should still work. > > https://jeremyardley.blogspot.com/2022/04/configuring-systemd-networkd-with.html > Jeremy Thanks! Rick PS: I'll also do the IPv6 part, because I'm interested in that too.
Re: Alternatives to ISC dhcp-client ?
On 8/5/22 11:27 am, Rick Thomas wrote: Thanks for the heads up! Can you describe in detail what one needs to do in order to switch over? I.e. what to remove, what to install? What to configure? This is a recent blogpost of mine showing a more complex installation including IPv6 delegation. If you just do the bits that refer to IPv4 it should still work. https://jeremyardley.blogspot.com/2022/04/configuring-systemd-networkd-with.html -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: Alternatives to ISC dhcp-client ?
On Sat, May 7, 2022, at 8:19 PM, Jeremy Ardley wrote: > On 8/5/22 11:14 am, Jeremy Ardley wrote: >> >> >> You can just use systemd-networkd as an IPv4 dhcp client. >> >> > > Of note: Using systemd-networkd you should not use NetworkManager or > networking services. I think both use the ISC dhcp client > > Of further note, I moved to systemd-networkd precisely because the ISC > dhcp client was badly behaved, and no-one at ISC seemed interested in > fixing it. Thanks for the heads up! Can you describe in detail what one needs to do in order to switch over? I.e. what to remove, what to install? What to configure? Thanks! Rick
Re: Alternatives to ISC dhcp-client ?
On Sat, May 7, 2022, at 8:14 PM, Jeremy Ardley wrote: > On 8/5/22 10:47 am, Rick Thomas wrote: >> ISC has ended development on the ISC DHCP client as of early 2022. >>> This client implementation is no longer maintained and should not be >>> used in production any longer. >> Can anybody recommend a good replacement? >> > > I presently use systemd-networkd which provides its own DHCP v4 and v6 > clients, and servers if you want. > > In my network my dual homed router acts as a dhcp client to the ISP and > gets an IPv4 address and is delegated an IPv6 /56 range. > > You can just use systemd-networkd as an IPv4 dhcp client. > Jeremy Is systemd-networkd automatically installed by Debian? I ask because my "testing" and "stable" systems all show isc-dhcp-client as installed and running. Thanks! Rick
Re: Alternatives to ISC dhcp-client ?
On 8/5/22 11:14 am, Jeremy Ardley wrote: You can just use systemd-networkd as an IPv4 dhcp client. Of note: Using systemd-networkd you should not use NetworkManager or networking services. I think both use the ISC dhcp client Of further note, I moved to systemd-networkd precisely because the ISC dhcp client was badly behaved, and no-one at ISC seemed interested in fixing it. -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: Alternatives to ISC dhcp-client ?
On 8/5/22 10:47 am, Rick Thomas wrote: ISC has ended development on the ISC DHCP client as of early 2022. This client implementation is no longer maintained and should not be used in production any longer. Can anybody recommend a good replacement? I presently use systemd-networkd which provides its own DHCP v4 and v6 clients, and servers if you want. In my network my dual homed router acts as a dhcp client to the ISP and gets an IPv4 address and is delegated an IPv6 /56 range. You can just use systemd-networkd as an IPv4 dhcp client. -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Alternatives to ISC dhcp-client ?
According to the ISC webpage: > ISC has ended development on the ISC DHCP client as of early 2022. > This client implementation is no longer maintained and should not be > used in production any longer. Can anybody recommend a good replacement? Does anybody know what the Debian PTBs are planning for this? Thanks! Rick
Re: Quel(s) serveur(s) DHCP pour 250 LAN de petite taille (/28) ?
Salut, Un extrait de "apt search dhcp" : isc-dhcp-relay/oldstable,now 4.4.1-2+deb10u1 amd64 [installed] ISC DHCP relay daemon isc-dhcp-server/oldstable 4.4.1-2+deb10u1 amd64 ISC DHCP server for automatic IP address assignment Lancé sur le relais DHCP qui est mon mini-routeur. Sur la machine serveur DHPC, c'est l'autre qui tourne : isc-dhcp-server. Viser quelque chose de plus complet peut cependant aider. Le mot clé "IPAM" pour IP Address Management dans google devrait t'indiquer des logiciels plus complets pour la gestion de tous ces réseaux. Sinon en jouant avec la configuration offerte par l'isc-dhcp-server et son mot clé "include" tu devrais pouvoir découper ta configuration pour avoir un fichier par réseau par exemple plutôt qu'avoir à modifier un seul gros fichier avec tes 250 réseaux. Le sam. 12 mars 2022 à 18:13, NoSpam a écrit : > Bonjour > > Le 11/03/2022 à 12:48, Olivier a écrit : > > Bonjour, > > > > Je souhaite mettre en place sur une machine Bullseye, un service DHCP > > traitant 250 réseaux locaux de petite taille (/28 soit 16 adresses) > > mais chacun avec 1 ou 2 machines connectées, au maximum. > > > > 1. Qui a déjà mis en oeuvre ce type de chose ? Avec quels composants ? > > Quel retour d'expérience ? > > > > 2. Je connais le serveur DHCP d'ISC. J'ai l'habitude de lister les > > interfaces sur lesquelles il écoute > > en complétant la ligne INTERFACESv4 du fichier /etc/default/interfaces. > > Existe-t-il une autre façon de fournir la liste des interfaces ? > > > > 3. Suggestions ? Conseils ? > > dnsmasq. Et passer en ipv6 ... > > -- > Daniel > >
Re: Quel(s) serveur(s) DHCP pour 250 LAN de petite taille (/28) ?
Bonjour Le 11/03/2022 à 12:48, Olivier a écrit : Bonjour, Je souhaite mettre en place sur une machine Bullseye, un service DHCP traitant 250 réseaux locaux de petite taille (/28 soit 16 adresses) mais chacun avec 1 ou 2 machines connectées, au maximum. 1. Qui a déjà mis en oeuvre ce type de chose ? Avec quels composants ? Quel retour d'expérience ? 2. Je connais le serveur DHCP d'ISC. J'ai l'habitude de lister les interfaces sur lesquelles il écoute en complétant la ligne INTERFACESv4 du fichier /etc/default/interfaces. Existe-t-il une autre façon de fournir la liste des interfaces ? 3. Suggestions ? Conseils ? dnsmasq. Et passer en ipv6 ... -- Daniel
Re: Quel(s) serveur(s) DHCP pour 250 LAN de petite taille (/28) ?
Très intéressant ! Je n'y a avais pas pensé du tout ! Dans mon labo, le serveur DHCP fait office de routeur mais sur l'implémentation cible, il est possible que ce rôle soit confié à une machine tierce. Dans les 2 cas, il faudra savoir configurer en masse les réseaux et les relais DHCP. Le ven. 11 mars 2022 à 14:43, Erwan David a écrit : > > Le 11/03/2022 à 12:48, Olivier a écrit : > > Bonjour, > > > > Je souhaite mettre en place sur une machine Bullseye, un service DHCP > > traitant 250 réseaux locaux de petite taille (/28 soit 16 adresses) > > mais chacun avec 1 ou 2 machines connectées, au maximum. > > > > 1. Qui a déjà mis en oeuvre ce type de chose ? Avec quels composants ? > > Quel retour d'expérience ? > > > > 2. Je connais le serveur DHCP d'ISC. J'ai l'habitude de lister les > > interfaces sur lesquelles il écoute > > en complétant la ligne INTERFACESv4 du fichier /etc/default/interfaces. > > Existe-t-il une autre façon de fournir la liste des interfaces ? > > Plutôt que d'avoir ton serveur avec une interface dans chacun de tes 250 > réseaux, tu peux utiliser un relais dhcp (par exemple sur le ou les > touteurs qui relient tes réseaux) C'est plus simple puisque ton serveur > DHCP n'a qu'une uinterface. Le relais lui envoie l'adresse de > l'interface qui a reçu la reqêute et ton serveur trouve le pool > correspondant. > > C'est très simple à mettre en place >
Re: Quel(s) serveur(s) DHCP pour 250 LAN de petite taille (/28) ?
On Friday 11 March 2022 12:48:54 Olivier wrote: > Je souhaite mettre en place sur une machine Bullseye, un service DHCP > traitant 250 réseaux locaux de petite taille (/28 soit 16 adresses) > mais chacun avec 1 ou 2 machines connectées, au maximum. > 1. Qui a déjà mis en oeuvre ce type de chose ? Avec quels composants ? > Quel retour d'expérience ? > 2. Je connais le serveur DHCP d'ISC. J'ai l'habitude de lister les > interfaces sur lesquelles il écoute > en complétant la ligne INTERFACESv4 du fichier /etc/default/interfaces. > Existe-t-il une autre façon de fournir la liste des interfaces ? > 3. Suggestions ? Conseils ? Hello, Entre autres, il faut bien calculer les numéros de netmask, (segmentation des réseaux et sous réseaux) qui ne sera plus 255.255.255.0, selon ce que l'on veut, souvent l'imperméabilisation des réseaux entre eux (sécurité, interdire l'accès à des sous-réseaux). Bonne soirée. A. Valmer
Re: Quel(s) serveur(s) DHCP pour 250 LAN de petite taille (/28) ?
Le 11/03/2022 à 12:48, Olivier a écrit : Bonjour, Je souhaite mettre en place sur une machine Bullseye, un service DHCP traitant 250 réseaux locaux de petite taille (/28 soit 16 adresses) mais chacun avec 1 ou 2 machines connectées, au maximum. 1. Qui a déjà mis en oeuvre ce type de chose ? Avec quels composants ? Quel retour d'expérience ? 2. Je connais le serveur DHCP d'ISC. J'ai l'habitude de lister les interfaces sur lesquelles il écoute en complétant la ligne INTERFACESv4 du fichier /etc/default/interfaces. Existe-t-il une autre façon de fournir la liste des interfaces ? Plutôt que d'avoir ton serveur avec une interface dans chacun de tes 250 réseaux, tu peux utiliser un relais dhcp (par exemple sur le ou les touteurs qui relient tes réseaux) C'est plus simple puisque ton serveur DHCP n'a qu'une uinterface. Le relais lui envoie l'adresse de l'interface qui a reçu la reqêute et ton serveur trouve le pool correspondant. C'est très simple à mettre en place
Quel(s) serveur(s) DHCP pour 250 LAN de petite taille (/28) ?
Bonjour, Je souhaite mettre en place sur une machine Bullseye, un service DHCP traitant 250 réseaux locaux de petite taille (/28 soit 16 adresses) mais chacun avec 1 ou 2 machines connectées, au maximum. 1. Qui a déjà mis en oeuvre ce type de chose ? Avec quels composants ? Quel retour d'expérience ? 2. Je connais le serveur DHCP d'ISC. J'ai l'habitude de lister les interfaces sur lesquelles il écoute en complétant la ligne INTERFACESv4 du fichier /etc/default/interfaces. Existe-t-il une autre façon de fournir la liste des interfaces ? 3. Suggestions ? Conseils ? Slts
Re: systemd/dhcp v. ntpd
On 2/17/22, Tim Woodall wrote: >>> It's on my todo list, along with ntp, to move to something else... >> >> I've seen references to chrony and ntpsec as replacements. > > ntpsec is supposed to be an almost drop in replacement. If I'm interpreting the popcon pages right, ntpsec 228 users chrony4686 users ntp 47485 users I'd much rather let someone else debug ntpsec. ntp has been around for ages, so while it might be hard to change I'm guessing most of the bugs have been fixed by now. If you haven't seen it, the "The future of src:ntp" thread on debian-devel is worth a read. tl-dr: https://www.coreinfrastructure.org/blogs/securing-network-time/ If I wanted to replace whatever timekeeping software that comes with systemd and _didn't_ want ntp, I'd pick chrony. Regards, Lee
Re: systemd/dhcp v. ntpd
On Wed, 16 Feb 2022, Lee wrote: On 2/12/22, Tim Woodall wrote: On Wed, 9 Feb 2022, Lee wrote: Any idea what the chances are of getting an enhancement request for the dhcp client to add an ignore option; that says not use the option given by the dhcp server? isc-dhcp-client? zero. https://www.isc.org/dhcp/ The client and relay portions of ISC DHCP are no longer maintained. *sigh* https://ftp.isc.org/isc/dhcp/4.4.3b1/dhcp-4.4.3b1-RELNOTES NOTE: The client and relay components are now End-Of-Life. 4.4.3 is the final release for those components. How does one figure out what the replacement dhcp client software is going to be? I'll probably try dhcpcd5. I have vague memories of using it before, don't recall why I changed (probably dhcpcd in those days) It's on my todo list, along with ntp, to move to something else... I've seen references to chrony and ntpsec as replacements. ntpsec is supposed to be an almost drop in replacement.
Re: systemd/dhcp v. ntpd
On 2/12/22, Tim Woodall wrote: > On Wed, 9 Feb 2022, Lee wrote: > >> Any idea what the chances are of getting an enhancement request for >> the dhcp client to add an >> ignore option; >> that says not use the option given by the dhcp server? >> > isc-dhcp-client? zero. > > https://www.isc.org/dhcp/ > > The client and relay portions of ISC DHCP are no longer maintained. *sigh* https://ftp.isc.org/isc/dhcp/4.4.3b1/dhcp-4.4.3b1-RELNOTES NOTE: The client and relay components are now End-Of-Life. 4.4.3 is the final release for those components. How does one figure out what the replacement dhcp client software is going to be? > It's on my todo list, along with ntp, to move to something else... I've seen references to chrony and ntpsec as replacements. Regards, Lee
Re: systemd/dhcp v. ntpd
On Wed, 9 Feb 2022, Lee wrote: Any idea what the chances are of getting an enhancement request for the dhcp client to add an ignore option; that says not use the option given by the dhcp server? isc-dhcp-client? zero. https://www.isc.org/dhcp/ The client and relay portions of ISC DHCP are no longer maintained. It's on my todo list, along with ntp, to move to something else...
Re: systemd/dhcp v. ntpd
On Wed, Feb 09, 2022 at 11:00:14AM -0500, Lee wrote: > *sigh* naturally I picked the "move it somewhere else" option that > won't prevent an upgrade from re-creating the file. Missing config files will not be reinstalled, unless you call dpkg with the "--force-confmiss" option. You should be fine.
Re: systemd/dhcp v. ntpd
On Wed, Feb 09, 2022 at 10:49:34AM -0500, Lee wrote: > >> My first thought was telling the machine to ignore the NTP server > >> address handed out via DHCP. Maybe there's a way to do that, but I > >> couldn't figure out how :( > > > > supercede ntp-servers "..." in dhclient.conf should do it for you. > > > > The option was helpfully provided by dhclient.conf(5). > > I tried not giving it a value - ie > supersede ntp-servers ; > > didn't work. Apparently one _has_ to give it a value. Yup. But you know which NTP servers you want this host to use, do you? > >> >> I tried changing /etc/dhcp/dhclient.conf to request just > >> >> request subnet-mask, broadcast-address, routers, > >> >> interface-mtu, > >> >> rfc3442-classless-static-routes ; > >> >> > >> >> and systemd still restarted ntpd with only the dhcp supplied ntp > >> >> server address ... which is this machine, so all the configured ntp > >> >> servers went away :( > > > > And that merely stopped dhclient from asking DHCP server to provide > > "ntp-server" option. What it cannot stop is DHCP server providing > > "ntp-server" option anyway. > > > > ISC dhclient simply lacks the option to ignore certain options in DHCP > > reply. It can supercede them though. > > The way I read the man page, supercede requires a value. One can say that too. > I can't just say ignore what the DHCP server gives me, I have to say > use instead of what the DHCP server gives me ... and there is > no value, it's several pool & server lines that I don't want > replaced. Changing DHCP client is an option too. > >> >> I then tried telling network manager to just get an ip address & > >> >> subnet mask from dhcp. And still systemd fucked up the ntpd config > >> >> > >> >> What finally worked was editing /usr/lib/ntp/ntp-systemd-wrapper to > >> >> remove ' NTPD_OPTS="$NTPD_OPTS -u $UGID" ' > >> > > >> > Huh? You're saying that removing the "-u $UGID" option made it "work"? > >> > And that it "didn't work" with -u being passed? > > > > Changing the contents of /etc/dhcp/dhclient-exit-hooks.d/ntp would make > > it more friendly for the purpose of the future updates. > > Changing it or moving it to another, clearly not supposed to be > invoked, directory? Removing this hook should be sufficient. Even better - add "exit 0" to the beginning. Reco
Re: systemd/dhcp v. ntpd
On Wed, Feb 09, 2022 at 11:00:14AM -0500, Lee wrote: > Any idea what the chances are of getting an enhancement request for > the dhcp client to add an > ignore option; > that says not use the option given by the dhcp server? apt install dhcpcd5 It can do this, it is called "nooption ntp_servers" Reco
Re: systemd/dhcp v. ntpd
On 2/9/22, Greg Wooledge wrote: > On Wed, Feb 09, 2022 at 05:44:25PM +0300, Reco wrote: >> Hi. >> >> On Wed, Feb 09, 2022 at 09:05:51AM -0500, Lee wrote: >> > On 2/8/22, Greg Wooledge wrote: >> > > On Tue, Feb 08, 2022 at 02:43:02PM -0500, Lee wrote: >> > >> How to tell systemd to leave the ntpd config alone? >> > > >> > > What makes you think the two are connected in any way? >> > >> > $ grep "Network Time Service" syslog >> > Feb 6 12:06:48 spot systemd[1]: Stopping Network Time Service... >> > Feb 6 12:06:48 spot systemd[1]: Stopped Network Time Service. >> > Feb 6 12:06:48 spot systemd[1]: Starting Network Time Service... >> > Feb 6 12:06:48 spot systemd[1]: Started Network Time Service. >> > Feb 6 12:09:25 spot systemd[1]: Stopping Network Time Service... >> > Feb 6 12:09:25 spot systemd[1]: Stopped Network Time Service. >> > Feb 6 12:09:25 spot systemd[1]: Starting Network Time Service... >> > Feb 6 12:09:25 spot systemd[1]: Started Network Time Service. >> > Feb 6 12:22:53 spot systemd[1]: Stopping Network Time Service... >> > Feb 6 12:22:53 spot systemd[1]: Stopped Network Time Service. >> > Feb 6 12:22:53 spot systemd[1]: Starting Network Time Service... >> > Feb 6 12:22:53 spot systemd[1]: Started Network Time Service. >> > ... etc >> > >> > every time I connect or disconnect from a wifi network. >> >> Or it could mean that dhclient hook merely asks systemd to restart ntpd >> service. See /etc/dhcp/dhclient-exit-hooks.d/ntp. > > What a disaster. The number of moving parts here is just staggering. > > OK, now we know that the real culprit is in fact Debian's concept of > how a DHCP client should behave. Let's try to track down all of the > pieces and figure out what the *best* answers are. > > The first piece, we now know, is the /etc/dhcp/dhclient-exit-hooks.d/ntp > script. We can see that this creates a temporary file, writes a new NTP > configuration into it, moves it to /run/ntp.conf.dhcp and then asks the > system to restart ntpd. > > The second piece is the /etc/init.d/ntp script (SURPRISE! sysv-rc still > lives!). Here we see this bit of conspiracy: > > if [ -e /run/ntp.conf.dhcp ]; then > NTPD_OPTS="$NTPD_OPTS -c /run/ntp.conf.dhcp" > fi > > If /run/ntp.conf.dhcp exists, then it's used preferentially over the > system's *real* ntp.conf file. So, the DHCP hook generates this fake > config file, and then the sysv-rc script sees it and decides to use it. > > AND SOMEONE THOUGHT THIS KLUDGE WAS A GOOD IDEA!! exactly :( Any idea what the chances are of getting an enhancement request for the dhcp client to add an ignore option; that says not use the option given by the dhcp server? > So, this gives us at least two points of attack. You could edit the DHCP > hook script, and stop it from creating the fake config file. Or, you > could edit the sysv-rc script and stop it from *respecting* the fake > config file. > > The question, I suppose, is which one of these is less likely to be > overwritten if the ntp package is updated. But they are both listed in > /var/lib/dpkg/info/ntp.conffiles so they should both survive a package > update. (You'll be asked whether to keep the existing file, etc.) *sigh* naturally I picked the "move it somewhere else" option that won't prevent an upgrade from re-creating the file. Thanks Lee
Re: systemd/dhcp v. ntpd
On 2/9/22, Reco wrote: > Hi. > > On Wed, Feb 09, 2022 at 09:05:51AM -0500, Lee wrote: >> On 2/8/22, Greg Wooledge wrote: >> > On Tue, Feb 08, 2022 at 02:43:02PM -0500, Lee wrote: >> >> How to tell systemd to leave the ntpd config alone? >> > >> > What makes you think the two are connected in any way? >> >> $ grep "Network Time Service" syslog >> Feb 6 12:06:48 spot systemd[1]: Stopping Network Time Service... >> Feb 6 12:06:48 spot systemd[1]: Stopped Network Time Service. >> Feb 6 12:06:48 spot systemd[1]: Starting Network Time Service... >> Feb 6 12:06:48 spot systemd[1]: Started Network Time Service. >> Feb 6 12:09:25 spot systemd[1]: Stopping Network Time Service... >> Feb 6 12:09:25 spot systemd[1]: Stopped Network Time Service. >> Feb 6 12:09:25 spot systemd[1]: Starting Network Time Service... >> Feb 6 12:09:25 spot systemd[1]: Started Network Time Service. >> Feb 6 12:22:53 spot systemd[1]: Stopping Network Time Service... >> Feb 6 12:22:53 spot systemd[1]: Stopped Network Time Service. >> Feb 6 12:22:53 spot systemd[1]: Starting Network Time Service... >> Feb 6 12:22:53 spot systemd[1]: Started Network Time Service. >> ... etc >> >> every time I connect or disconnect from a wifi network. > > Or it could mean that dhclient hook merely asks systemd to restart ntpd > service. See /etc/dhcp/dhclient-exit-hooks.d/ntp. That's certainly better :) mkdir /etc/dhcp/dhclient-exit-hooks.d.NOT mv /etc/dhcp/dhclient-exit-hooks.d/ntp /etc/dhcp/dhclient-exit-hooks.d.NOT/ntp disconnect / connect wifi and 'ntpq -p' still shows most servers with a reach value of 377 (ie. ntpd isn't being restarted :) >> My first thought was telling the machine to ignore the NTP server >> address handed out via DHCP. Maybe there's a way to do that, but I >> couldn't figure out how :( > > supercede ntp-servers "..." in dhclient.conf should do it for you. > > The option was helpfully provided by dhclient.conf(5). I tried not giving it a value - ie supersede ntp-servers ; didn't work. Apparently one _has_ to give it a value. >> >> I tried changing /etc/dhcp/dhclient.conf to request just >> >> request subnet-mask, broadcast-address, routers, >> >> interface-mtu, >> >> rfc3442-classless-static-routes ; >> >> >> >> and systemd still restarted ntpd with only the dhcp supplied ntp >> >> server address ... which is this machine, so all the configured ntp >> >> servers went away :( > > And that merely stopped dhclient from asking DHCP server to provide > "ntp-server" option. What it cannot stop is DHCP server providing > "ntp-server" option anyway. > > ISC dhclient simply lacks the option to ignore certain options in DHCP > reply. It can supercede them though. The way I read the man page, supercede requires a value. I can't just say ignore what the DHCP server gives me, I have to say use instead of what the DHCP server gives me ... and there is no value, it's several pool & server lines that I don't want replaced. >> >> I then tried telling network manager to just get an ip address & >> >> subnet mask from dhcp. And still systemd fucked up the ntpd config >> >> >> >> What finally worked was editing /usr/lib/ntp/ntp-systemd-wrapper to >> >> remove ' NTPD_OPTS="$NTPD_OPTS -u $UGID" ' >> > >> > Huh? You're saying that removing the "-u $UGID" option made it "work"? >> > And that it "didn't work" with -u being passed? > > Changing the contents of /etc/dhcp/dhclient-exit-hooks.d/ntp would make > it more friendly for the purpose of the future updates. Changing it or moving it to another, clearly not supposed to be invoked, directory? Either way - I agree, changing /etc/dhcp/dhclient-exit-hooks.d/ntp is the better method. Thanks Lee
Re: systemd/dhcp v. ntpd
On Wed, Feb 09, 2022 at 05:44:25PM +0300, Reco wrote: > Hi. > > On Wed, Feb 09, 2022 at 09:05:51AM -0500, Lee wrote: > > On 2/8/22, Greg Wooledge wrote: > > > On Tue, Feb 08, 2022 at 02:43:02PM -0500, Lee wrote: > > >> How to tell systemd to leave the ntpd config alone? > > > > > > What makes you think the two are connected in any way? > > > > $ grep "Network Time Service" syslog > > Feb 6 12:06:48 spot systemd[1]: Stopping Network Time Service... > > Feb 6 12:06:48 spot systemd[1]: Stopped Network Time Service. > > Feb 6 12:06:48 spot systemd[1]: Starting Network Time Service... > > Feb 6 12:06:48 spot systemd[1]: Started Network Time Service. > > Feb 6 12:09:25 spot systemd[1]: Stopping Network Time Service... > > Feb 6 12:09:25 spot systemd[1]: Stopped Network Time Service. > > Feb 6 12:09:25 spot systemd[1]: Starting Network Time Service... > > Feb 6 12:09:25 spot systemd[1]: Started Network Time Service. > > Feb 6 12:22:53 spot systemd[1]: Stopping Network Time Service... > > Feb 6 12:22:53 spot systemd[1]: Stopped Network Time Service. > > Feb 6 12:22:53 spot systemd[1]: Starting Network Time Service... > > Feb 6 12:22:53 spot systemd[1]: Started Network Time Service. > > ... etc > > > > every time I connect or disconnect from a wifi network. > > Or it could mean that dhclient hook merely asks systemd to restart ntpd > service. See /etc/dhcp/dhclient-exit-hooks.d/ntp. What a disaster. The number of moving parts here is just staggering. OK, now we know that the real culprit is in fact Debian's concept of how a DHCP client should behave. Let's try to track down all of the pieces and figure out what the *best* answers are. The first piece, we now know, is the /etc/dhcp/dhclient-exit-hooks.d/ntp script. We can see that this creates a temporary file, writes a new NTP configuration into it, moves it to /run/ntp.conf.dhcp and then asks the system to restart ntpd. The second piece is the /etc/init.d/ntp script (SURPRISE! sysv-rc still lives!). Here we see this bit of conspiracy: if [ -e /run/ntp.conf.dhcp ]; then NTPD_OPTS="$NTPD_OPTS -c /run/ntp.conf.dhcp" fi If /run/ntp.conf.dhcp exists, then it's used preferentially over the system's *real* ntp.conf file. So, the DHCP hook generates this fake config file, and then the sysv-rc script sees it and decides to use it. AND SOMEONE THOUGHT THIS KLUDGE WAS A GOOD IDEA!! So, this gives us at least two points of attack. You could edit the DHCP hook script, and stop it from creating the fake config file. Or, you could edit the sysv-rc script and stop it from *respecting* the fake config file. The question, I suppose, is which one of these is less likely to be overwritten if the ntp package is updated. But they are both listed in /var/lib/dpkg/info/ntp.conffiles so they should both survive a package update. (You'll be asked whether to keep the existing file, etc.)
Re: systemd/dhcp v. ntpd
On Wed, 9 Feb 2022 09:05:51 -0500 Lee wrote: > 2nd thought was telling the DHCP server to not hand out an NTP server > address to this one machine, but that's another damnifi know how to. If you are running isc-dhcp-server, look for "option ntp-servers" in /etc/dhcp/dhcpd.conf. Another way to do it is to have the time server get its ip address from /etc/network/interfaces, so it ignores DHCP. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: systemd/dhcp v. ntpd
Hi. On Wed, Feb 09, 2022 at 09:05:51AM -0500, Lee wrote: > On 2/8/22, Greg Wooledge wrote: > > On Tue, Feb 08, 2022 at 02:43:02PM -0500, Lee wrote: > >> How to tell systemd to leave the ntpd config alone? > > > > What makes you think the two are connected in any way? > > $ grep "Network Time Service" syslog > Feb 6 12:06:48 spot systemd[1]: Stopping Network Time Service... > Feb 6 12:06:48 spot systemd[1]: Stopped Network Time Service. > Feb 6 12:06:48 spot systemd[1]: Starting Network Time Service... > Feb 6 12:06:48 spot systemd[1]: Started Network Time Service. > Feb 6 12:09:25 spot systemd[1]: Stopping Network Time Service... > Feb 6 12:09:25 spot systemd[1]: Stopped Network Time Service. > Feb 6 12:09:25 spot systemd[1]: Starting Network Time Service... > Feb 6 12:09:25 spot systemd[1]: Started Network Time Service. > Feb 6 12:22:53 spot systemd[1]: Stopping Network Time Service... > Feb 6 12:22:53 spot systemd[1]: Stopped Network Time Service. > Feb 6 12:22:53 spot systemd[1]: Starting Network Time Service... > Feb 6 12:22:53 spot systemd[1]: Started Network Time Service. > ... etc > > every time I connect or disconnect from a wifi network. Or it could mean that dhclient hook merely asks systemd to restart ntpd service. See /etc/dhcp/dhclient-exit-hooks.d/ntp. > My first thought was telling the machine to ignore the NTP server > address handed out via DHCP. Maybe there's a way to do that, but I > couldn't figure out how :( supercede ntp-servers "..." in dhclient.conf should do it for you. The option was helpfully provided by dhclient.conf(5). > >> I tried changing /etc/dhcp/dhclient.conf to request just > >> request subnet-mask, broadcast-address, routers, > >> interface-mtu, > >> rfc3442-classless-static-routes ; > >> > >> and systemd still restarted ntpd with only the dhcp supplied ntp > >> server address ... which is this machine, so all the configured ntp > >> servers went away :( And that merely stopped dhclient from asking DHCP server to provide "ntp-server" option. What it cannot stop is DHCP server providing "ntp-server" option anyway. ISC dhclient simply lacks the option to ignore certain options in DHCP reply. It can supercede them though. > >> I then tried telling network manager to just get an ip address & > >> subnet mask from dhcp. And still systemd fucked up the ntpd config > >> > >> What finally worked was editing /usr/lib/ntp/ntp-systemd-wrapper to > >> remove ' NTPD_OPTS="$NTPD_OPTS -u $UGID" ' > > > > Huh? You're saying that removing the "-u $UGID" option made it "work"? > > And that it "didn't work" with -u being passed? Changing the contents of /etc/dhcp/dhclient-exit-hooks.d/ntp would make it more friendly for the purpose of the future updates. Reco
Re: systemd/dhcp v. ntpd
On 2/8/22, Greg Wooledge wrote: > On Tue, Feb 08, 2022 at 02:43:02PM -0500, Lee wrote: >> How to tell systemd to leave the ntpd config alone? > > What makes you think the two are connected in any way? $ grep "Network Time Service" syslog Feb 6 12:06:48 spot systemd[1]: Stopping Network Time Service... Feb 6 12:06:48 spot systemd[1]: Stopped Network Time Service. Feb 6 12:06:48 spot systemd[1]: Starting Network Time Service... Feb 6 12:06:48 spot systemd[1]: Started Network Time Service. Feb 6 12:09:25 spot systemd[1]: Stopping Network Time Service... Feb 6 12:09:25 spot systemd[1]: Stopped Network Time Service. Feb 6 12:09:25 spot systemd[1]: Starting Network Time Service... Feb 6 12:09:25 spot systemd[1]: Started Network Time Service. Feb 6 12:22:53 spot systemd[1]: Stopping Network Time Service... Feb 6 12:22:53 spot systemd[1]: Stopped Network Time Service. Feb 6 12:22:53 spot systemd[1]: Starting Network Time Service... Feb 6 12:22:53 spot systemd[1]: Started Network Time Service. ... etc every time I connect or disconnect from a wifi network. Right after systemd[1]: Starting Network Time Service... comes ntpd[43320]: ntpd 4.2.8p15@1.3728-o Wed Sep 23 11:46:38 UTC 2020 (1): Starting ntpd[43320]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /run/ntp.conf.dhcp -u 117:124 /run/ntp.conf.dhcp starts off with # This file was copied from /etc/ntp.conf with the server options changed # to reflect the information sent by the DHCP server. Any changes made # here will be lost at the next DHCP event. Edit /etc/ntp.conf instead. # NTP server entries received from DHCP server server iburst is the NTP server for the local network, so replacing all the pool and server addresses in the ntp config with it's own ip address is a problem. My first thought was telling the machine to ignore the NTP server address handed out via DHCP. Maybe there's a way to do that, but I couldn't figure out how :( 2nd thought was telling the DHCP server to not hand out an NTP server address to this one machine, but that's another damnifi know how to. > Under bullseye, if the ntp package (which supplies the ntpd program) is > installed, then systemd-timesyncd is removed. The two packages will not > coexist. > > Under some older versions of Debian (I'm not sure when it changed exactly), > they can coexist, but the systemd-timesyncd service is configured not to > run if /usr/sbin/ntpd exists and is executable. > > Either way, if ntp(d) is installed, systemd will not do anything regarding > time synchronization or NTP. The syslog messages say otherwise. >> I tried changing /etc/dhcp/dhclient.conf to request just >> request subnet-mask, broadcast-address, routers, >> interface-mtu, >> rfc3442-classless-static-routes ; >> >> and systemd still restarted ntpd with only the dhcp supplied ntp >> server address ... which is this machine, so all the configured ntp >> servers went away :( > > This is too vague. What are you actually seeing? This machine is the ntp server for other machines on the local network. I have multiple wifi networks, so I'd prefer to keep the wifi connection using DHCP. The problem seems to be 1. the DHCP server hands out an NTP server as part of the info 2. this machine does not ignore the ntp server info in the dhcp reply 3. systemd restarts ntpd with a "-c /run/ntp.conf.dhcp" parameter. That file has only the one dhcp supplied ntp server in the config. Normally 'ntpq -p' shows lots of servers. After connecting to the wifi network, and before changing /usr/lib/ntp/ntp-systemd-wrapper, an 'ntpq -p' showed only one server, this machine, and the status was .. I don't remember exactly what, but something clearly broken For all the other machines on the local net that are using DHCP, the default DHCP request info in /etc/dhcp/dhclient.conf is good. But this machine is the DNS and NTP server, so the only DHCP info it should accept is the ip address, mask & default gateway. But I don't know how to make that happen :( > unicorn:~$ ps auxw | grep ntpd > ntp 758 0.0 0.0 74696 3896 ?Ssl Feb04 0:14 > /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 107:112 > greg 290127 0.0 0.0 6244 2404 pts/0S+ 15:04 0:00 grep > ntpd After connecting to a wifi network the ntpd process had "-c /run/ntp.conf.dhcp" after the "-g" > The ntpd program (service) isn't started with an NTP server address as > an argument. The configuration is all in files. yes, the file is /run/ntp.conf.dhcp It starts off with # This file was copied from /etc/ntp.conf with the server options changed # to reflect the information sent by the DHCP server. I don't know how to tell the DHCP server to _not_ include the ntp server address in the dhcp info sent to just this one machine. The DH
Re: systemd/dhcp v. ntpd
On Tue, Feb 08, 2022 at 02:43:02PM -0500, Lee wrote: > How to tell systemd to leave the ntpd config alone? What makes you think the two are connected in any way? Under bullseye, if the ntp package (which supplies the ntpd program) is installed, then systemd-timesyncd is removed. The two packages will not coexist. Under some older versions of Debian (I'm not sure when it changed exactly), they can coexist, but the systemd-timesyncd service is configured not to run if /usr/sbin/ntpd exists and is executable. Either way, if ntp(d) is installed, systemd will not do anything regarding time synchronization or NTP. > I tried changing /etc/dhcp/dhclient.conf to request just > request subnet-mask, broadcast-address, routers, > interface-mtu, > rfc3442-classless-static-routes ; > > and systemd still restarted ntpd with only the dhcp supplied ntp > server address ... which is this machine, so all the configured ntp > servers went away :( This is too vague. What are you actually seeing? unicorn:~$ ps auxw | grep ntpd ntp 758 0.0 0.0 74696 3896 ?Ssl Feb04 0:14 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 107:112 greg 290127 0.0 0.0 6244 2404 pts/0S+ 15:04 0:00 grep ntpd The ntpd program (service) isn't started with an NTP server address as an argument. The configuration is all in files. unicorn:~$ grep -e ^server -e ^pool /etc/ntp.conf pool 0.debian.pool.ntp.org iburst pool 1.debian.pool.ntp.org iburst pool 2.debian.pool.ntp.org iburst pool 3.debian.pool.ntp.org iburst Are you claiming that systemd has somehow modified your /etc/ntp.conf file? What change did it make? What does your ntp.conf file look like now, after the change? > I then tried telling network manager to just get an ip address & > subnet mask from dhcp. And still systemd fucked up the ntpd config > > What finally worked was editing /usr/lib/ntp/ntp-systemd-wrapper to > remove ' NTPD_OPTS="$NTPD_OPTS -u $UGID" ' Huh? You're saying that removing the "-u $UGID" option made it "work"? And that it "didn't work" with -u being passed? Why would that be the case? Is there a file or directory on you system that has the wrong ownership? What errors were you getting in your logs?
systemd/dhcp v. ntpd
How to tell systemd to leave the ntpd config alone? I had everything working with a static ethernet config and then decided I wanted a media server for my ROKU. My understanding is the DLNA server has to be on the same subnet as the ROKU, so I joined my PC to the wlan ... and broke the ntpd service running on the PC :( I tried changing /etc/dhcp/dhclient.conf to request just request subnet-mask, broadcast-address, routers, interface-mtu, rfc3442-classless-static-routes ; and systemd still restarted ntpd with only the dhcp supplied ntp server address ... which is this machine, so all the configured ntp servers went away :( I then tried telling network manager to just get an ip address & subnet mask from dhcp. And still systemd fucked up the ntpd config What finally worked was editing /usr/lib/ntp/ntp-systemd-wrapper to remove ' NTPD_OPTS="$NTPD_OPTS -u $UGID" ' What's the more correct way to tell systemd to leave my ntpd config alone? Thanks Lee
Re: DHCP and search list for DNS domains
On Fri 21 Jan 2022 at 13:57:47 (+0100), Steve Keller wrote: > AFAIK, some of my client hosts have only resolvconf, others use some > systemd stuff, since the man page for resolvconf is actually the > man page for resolvectl which also refers to systemd-resolved. The man page for /package/ resolvconf is man 8 resolvconf, not man resolvconf. $ dpkg -L resolvconf or whatever the package is, can be useful here. Cheers, David.
Re: DHCP and search list for DNS domains
"Markus Schönhaber" wrote: > > AFAICS, there is no option in DHCP to provide the search list. > > From dhcp-options(5): > > >option domain-search domain-list; > > > > The domain-search option specifies a ´search list´ of Domain > > Names to be used by the client to locate not-fully-qualified do‐ > > main names. The difference between this option and historic use > > of the domain-name option for the same ends is that this option > > is encoded in RFC1035 compressed labels on the wire. For exam‐ > > ple: > > > >option domain-search "example.com", "sales.example.com", > > "eng.example.com"; Oops, I must have overseen it. I've read the man pages but probably I only read dhcpd(8) and dhcpd.conf(5), but missed dhcp-options(5). Thanks, Steve
Re: DHCP and search list for DNS domains
On Fri, 21 Jan 2022 13:57:47 +0100 Steve Keller wrote: > With DHCP I can tell a host the DNS server and the domain name of the > network, which is then stored to /etc/resolv.conf. But how can I add > a list a domain names that should be searched when resolving a host > name? root@chaffee:~# grep -i search /etc/dhcp/dhcpd.conf option domain-search "domain0", "domain1", "domain2"; root@chaffee:~# -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: DHCP and search list for DNS domains
21.01.22, 13:57 +0100, Steve Keller: With DHCP I can tell a host the DNS server and the domain name of the network, which is then stored to /etc/resolv.conf. But how can I add a list a domain names that should be searched when resolving a host name? AFAICS, there is no option in DHCP to provide the search list. From dhcp-options(5): option domain-search domain-list; The domain-search option specifies a ´search list´ of Domain Names to be used by the client to locate not-fully-qualified do‐ main names. The difference between this option and historic use of the domain-name option for the same ends is that this option is encoded in RFC1035 compressed labels on the wire. For exam‐ ple: option domain-search "example.com", "sales.example.com", "eng.example.com"; -- Regards mks
DHCP and search list for DNS domains
With DHCP I can tell a host the DNS server and the domain name of the network, which is then stored to /etc/resolv.conf. But how can I add a list a domain names that should be searched when resolving a host name? AFAICS, there is no option in DHCP to provide the search list. So the questions is, is there a way to configure locally in the client host a search list that is added to /etc/resolv.conf? Say, for example, my domain domain is foo.bar.org and the DHCP server configuration has option domain-name "foo.bar.org"; option domain-name-servers ns.foo.bar.org; but I want bar.org also in the DNS domain search list, so I can ping host to get host.bar.org. That is, in /etc/resolv.conf there should be domain foo.bar.org search foo.bar.org bar.org nameserver AFAIK, some of my client hosts have only resolvconf, others use some systemd stuff, since the man page for resolvconf is actually the man page for resolvectl which also refers to systemd-resolved. Steve
SOLVED: how to set fixed virtual-ethernet MAC address in VM while still doing DHCP?
In message <https://lists.debian.org/debian-user/2021/12/msg00606.html>
I wrote:
> I have a virtual machine (VM) running Debian 10.10.0 ("Buster") x86-64,
> running in an OpenBSD 7.0 host (using the OpenBSD 'vmm' VM monitor).
[[...]]
> my question is, how can I set a fixed virtual-ethernet MAC address
> in Debian and still have the system use DHCP for IPv4 network configuration?
In message <https://lists.debian.org/debian-user/2021/12/msg00607.html>,
Dan Ritter replied:
> OpenBSD's VM infrastructure owns the virtual hardware.
>
> vm "tux" {
> enable
> memory 97G
> owner jthorn
> disk "/var/vmm/tux.qcow2" format qcow2
> interface tap {
> switch "uplink_veb420"
> lladdr fe:ee:bb:d1:c8:01
> }
> }
>
> In your interface config for the VM, set the lladdr.
I'm pleased to report that Dan's solution works perfectly! That is,
(contrary to my misunderstanding) the host (OpenBSD) owns BOTH ends of
the virtual network and can set the MAC address seen by the guest (Debian).
Stay safe and COVID-free, everyone, -- Jonathan
firewalld : quand le service dhcp est-il nécessaire ?
Bonjour, Je découvre firewalld et sa configuration. Celle-ci comprend, si j'ai bien compris, un paramètre nommé services qui correspond à une liste de couples port-protocole autorisés entre un membre d'une zone et la machine qui héberge firewalld (équivalent de INPUT dans le vocabulaire IPTables). Quand j'installe un serveur ISC-DHCP sur la machine hébergeant firewalld, la configuration ci-après semble suffisante pour que des clients (connectés par l'interface ens9) récupèrent une adresse. # firewall-cmd --info-zone=internal internal (active) target: default icmp-block-inversion: no interfaces: ens9 sources: services: dhcpv6-client mdns samba-client ssh ports: protocols: forward: no masquerade: yes forward-ports: source-ports: icmp-blocks: rich rules: J'avais vaguement en tête que "les échanges DHCP ne pouvaient pas être contrôlés par IPTables car le DHCP utilise nécessairement des raw sockets qui contournent les moyens utilisés par IPTables pour appliquer des règles. Est-ce toujours le cas avec nftables/firewalld ? Quand le service dhcp est-il nécessaire ? Quel test (pas trop compliqué) me permettrait de répondre moi-même à cette question ? Slts
Re: how to set fixed virtual-ethernet MAC address in VM while still doing DHCP?
Jonathan Thornburg wrote:
> I have a virtual machine (VM) running Debian 10.10.0 ("Buster") x86-64,
> running in an OpenBSD 7.0 host (using the OpenBSD 'vmm' VM monitor).
...
> So, my question is, how can I set a fixed virtual-ethernet MAC address
> in Debian and still have the system use DHCP for IPv4 network configuration?
OpenBSD's VM infrastructure owns the virtual hardware.
vm "tux" {
enable
memory 97G
owner jthorn
disk "/var/vmm/tux.qcow2" format qcow2
interface tap {
switch "uplink_veb420"
lladdr fe:ee:bb:d1:c8:01
}
}
In your interface config for the VM, set the lladdr.
-dsr-
how to set fixed virtual-ethernet MAC address in VM while still doing DHCP?
I have a virtual machine (VM) running Debian 10.10.0 ("Buster") x86-64,
running in an OpenBSD 7.0 host (using the OpenBSD 'vmm' VM monitor).
The Debian VM's (IPv4) network connectivity to the host (which is configured
to forward selected network traffic to/from the outside world as appropriate)
is configured via the VM's /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug enp0s2
iface enp0s2 inet dhcp
This works fine: the VM has a (virtual) network interface enp0s2 whose
IP address is assigned by the host via DHCP. (The host OpenBSD vmm provides
a DHCP server for this purpose, and the hosts's networking configuration
uses the DHCP-assigned IP addresses to keep track of different VMs.)
The resulting network configuration is this:
tux# ifconfig enp0s2
enp0s2: flags=4163 mtu 1500
inet 100.64.2.3 netmask 255.255.255.254 broadcast 100.64.2.3
inet6 fe80::fce1:bbff:fed1:5246 prefixlen 64 scopeid 0x20
ether fe:e1:bb:d1:52:46 txqueuelen 1000 (Ethernet)
RX packets 2 bytes 684 (684.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tux#
(As is evident from the ifconfig output, there is also an IPv6 address
assigned to the interface, but I'm not using IPv6 here.)
My problem is that by default, Debian randomizes the (virtual) ethernet
MAC address of enp0s2 each time I reboot the virtual machine, and this
breaks the license manager for some commercial site-licensed software
(Maple) I'm running in the virtual machine.
So, I'd like to disable Debian's virtual-ethernet MAC address randomization
and set a fixed virtual-ethernet MAC address for enp0s2, while still using
DHCP to configure Debian's IPv4 networking. (I emphasize that the fixed
ethernet MAC address I want to set is that of the Debian enp0s2
virtual-interface, NOT that of the OpenBSD host's virtual-interface.)
According to Debian's man 5 interfaces, what I want should be be easy:
just append the line
hwaddress ether fe:e1:01:02:03:04
at the end of /etc/network/interfaces. If I do this I do indeed get
enp0s2's (virtual) ethernet MAC address set as I desire... *but* Debian
doesn't configure IPv4 networking on this interface:
tux# ifconfig enp0s2
enp0s2: flags=4163 mtu 1500
inet6 fe80::fce1:bbff:fed1:283 prefixlen 64 scopeid 0x20
ether fe:e1:bb:d1:02:83 txqueuelen 1000 (Ethernet)
RX packets 4 bytes 168 (168.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 107 bytes 32568 (31.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tux#
I have also tried changing the last line of /etc/network/interfaces to
iface enp0s2 inet dhcp hwaddress fe:e1:bb:d1:02:83
but this gets me a DHCP-configured network interface with a randomized
virtual-ethernet MAC address, i.e., Debian ignores my attempt to set a
fixed virtual-ethernet MAC address is ignored.
I have also tried appending the line
pre-up ifconfig enp0s2 hw ether f1:e1:01:02:03:04
to /etc/network/interfaces. This sets the virtual-ethernet MAC address
ok, but once again enp0s2 doesn't get an IP address.
So, my question is, how can I set a fixed virtual-ethernet MAC address
in Debian and still have the system use DHCP for IPv4 network configuration?
I would strongly prefer a command-line (non-GUI) solution, as running
anything GUI on the VM would require ssh over a working network to the
VM, and right now that's somewhat lacking.
Thanks,
--
-- "Jonathan Thornburg [remove color- to reply]"
on the west coast of Canada, eh?
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
Re: DHCP server for other site
On 12/10/2021 6:45 PM, Bonno Bloksma wrote:
Hi,
I want to move my DHCP servers to my datacenter as I am going to shut down the
hypervisor hosts on some locations.
[...]
And as that is the only interface for the VM the dhcp software wil fail to
start.
So my solution was to add a few lines to the config
shared-network datacenter.tio.nl {
subnet 10.0.1.0 netmask 255.255.254.0 {
}
}
Is this the recommended way or is there a better way? I want to keep one dhcp
server per location and not have one dhcp server for all locations. That helps
a lot with keeping the configs manageable. ;-)
And an update. It seems this dhcp server is reacting to requests on the local
network even though there is no config to do so.
I see DHCPINFORM and DHCPACK lines for the local 10.0.1.0 network.
Why is that happening? Is it just parroting what the other authoritative dhcp
server is sending on the network?
Mabey because leases on some clients has not been renewed.
--
John Doe
RE: DHCP server for other site
Hi,
> I want to move my DHCP servers to my datacenter as I am going to shut down
> the hypervisor hosts on some locations.
[...]
> And as that is the only interface for the VM the dhcp software wil fail to
> start.
> So my solution was to add a few lines to the config
> shared-network datacenter.tio.nl {
> subnet 10.0.1.0 netmask 255.255.254.0 {
> }
> }
> Is this the recommended way or is there a better way? I want to keep one dhcp
> server per location and not have one dhcp server for all locations. That
> helps a lot with keeping the configs manageable. ;-)
And an update. It seems this dhcp server is reacting to requests on the local
network even though there is no config to do so.
I see DHCPINFORM and DHCPACK lines for the local 10.0.1.0 network.
Why is that happening? Is it just parroting what the other authoritative dhcp
server is sending on the network?
Bonno Bloksma
senior systeembeheerder
DHCP server for other site
Hi,
I want to move my DHCP servers to my datacenter as I am going to shut down the
hypervisor hosts on some locations.
If I just move the VM running the isc-dhcp-server software to the DC and change
the ip of the VM then I get a warning when I try to start the dhcp software
Dec 8 16:12:12 lingro dhcpd[546]: No subnet declaration for ens192 (10.0.1.21).
Dec 8 16:12:12 lingro dhcpd[546]: ** Ignoring requests on ens192. If this is
not what
Dec 8 16:12:12 lingro dhcpd[546]:you want, please write a subnet
declaration
[]
And as that is the only interface for the VM the dhcp software wil fail to
start.
So my solution was to add a few lines to the config
shared-network datacenter.tio.nl {
subnet 10.0.1.0 netmask 255.255.254.0 {
}
}
Is this the recommended way or is there a better way? I want to keep one dhcp
server per location and not have one dhcp server for all locations. That helps
a lot with keeping the configs manageable. ;-)
Bonno Bloksma
isc-dhcp-server and use-host-decl-names
I run two dhcpd servers on my LAN with failover and DDNS updates. In the
past I have set certain machines up with fixed addresses and host
names, like so:
host dragonw
{
option host-name "dragonw";
hardware ethernet ee:ee:ee:ee:ee:ee;
fixed-address iii.iii.ii.i;
ddns-hostname dragonw;
}
However, if I understand the man page for dhcpd.conf correctly, I can
get rid of both the ddns-hostname and host-name declarations by
enclosing the host declaration in a group which has use-host-decl-names
on, like so:
ignore client-updates;
group {
use-host-decl-names on;
host dragonw
{
hardware ethernet ee:ee:ee:ee:ee:ee;
fixed-address iii.iii.ii.i;
}
}
However, at least three cases since I made that change, dhcp has used
another name, which I guess is the name requested by the host.
What am I missing?
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
Policy-based routing sur une interface virtuelle configurée par DHCP
Bonjour, Je souhaite mettre en place un serveur sous Bullseye, "auto-configurable faisant office de double passerelle réseau vers Internet". Par auto-configurable, j'entends ici que: 1.les 2 interfaces WAN se configurent pas DHCP, 2. je veux éviter d'avoir à scripter le client DHCP lire et réutiliser les adresses reçues. Le serveur possède une seule interface Ethernet physique. Sur cette interface physique, on définit 3 interfaces virtuelles (VLAN): - une première vers le LAN - une seconde vers Internet. - une troisième vers Internet. Le serveur est connecté à un commutateur lui-même connecté au LAN et aux 2 boxes des opérateurs fonctionnant en mode bridge. LAN ---| | Internet Box1 - Commutateur - Serveur | Internet Box2 -| J'arrive à configurer l'interface vers Box2 en utilisant les adresses fournies par le 2ème opérateur mais je n'arrive pas à la configurer en n'utilisant que le nom de l'interface virtuelle utilisée. Qui a déjà résolu quelque chose d'analogue ? Voici ce que j'obtiens: - la 3ème interface se nomme ens3.125 - dans mon labo, elle reçoit l'adresse 192.168.33.240/24 d'une passerelle en 192.168.33.1 - le serveur est une VM KVM - je teste avec une commande équivalente à ssh foo@192.168.33.240 - ce qui marche ip rule flush table2 ip rule add from 192.168.33.0/24 lookup table2 - ce qui ne marche pas: ip rule flush table2 ip rule add iif ens3.125 lookup table2 ip rule add oif ens3.125 lookup table2 Quand ça ne marche pas j'observe que: - la demande SSH est bien reçue sur l'interface ens3.125 et que la réponse est émise via la 2ème interface. J'ai pensé que le problème venait du fait que les 3 interfaces virtuelles partageait la même adresse MAC. J'ai fourni une adresse factice (ip link add link ens3 name ens3.125 address 00:0c:29:ed:ff:ff type vlan id 125) à la 3ème interface sans plus de succès. J'ai aussi essayé le marquage via nftables sans succès, pour l'instant car je maîtrise mal les outils de nftables add rule ip mangle prerouting iifname "ens3.125" counter meta mark set 0x2 ip rule flush table2 ip rule add fwmark 2 lookup table2 Je suis un peu a cours d'idées. Slts
USB CDC-NCM device failed obtain dhcp address
Hi, I've got a USB device which is known by the system as a cdc-ncm adapter. The USB device should assign a specified IP for the adapter however it fails to receive an IP. The system is a Debian Buster 10.3 amd64. The USB device was also connected to a Raspberry Pi with Raspbian Stretch and I found that the cdc-ncm adapter receives the IP address expected. Any suggestions how I can fix it on Buster? BR Saeed
Re: timedatectl DHCP NTP Server
On Thu, 4 Feb 2021 22:16:12 +0100 basti wrote: > As I can see now timedatectl seems *not* > using the NTP Server provide by DHCP. I have configure a NTP server > in LAN. Are you using NetworkManager? Out of the box, it does not pick up the relevant information from the dhcp client. There are scripts out there to handle that for ntp. If you are using systemd-timesyncd, you will want this: https://charlescurley.com/blog/posts/2021/Feb/14/networkmanager.time/ -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
RE: ISC-DHCP server number of active leases
Hi Dan / list, >> I am running multiple isc-dhcp servers on Debian Linux. >> I have several sites with multiple networks and I use the isc-dhcp-server to >> hand out ip numbers in the various network segments. In most of the networks >> I have more then enough free ip numbers all the time. >> However, in some networks I KNOW I regularly hand out far more then 50% of >> the assigned ip numbers and I have set the default and max-lease-time low >> enough to free up ip numbers asap. >> So far so good, I have had no problems this year but... we are growing and >> people have more mobile devices so I want to know HOW CLOSE I am to running >> out of free dhcp leases. >> >> Which tool can help me getting insight in the number of active dhcp leases. >> It would be really great if it gave insight including a history of when how >> many ip numbers were in use at any given time segment. >> That would show me whether I am getting close to saturation at any given >> moment in the day. > apt install dhcpd-pools That seems to do a lot of what I want, however our current monitoring tool can do stuff a lot easier if it were accessible via SNMP. It seems there is a tool that can help https://github.com/ohitz/dhcpd-snmp It is a perl script that I somehow need to hook into the net-snmp tool. Has anyone even done this on a Debian machine, I have not used SNMP on a Debian machine before and have yet to read all the documentation as to how I can install a perl script as an extention. Anyone who can help, please do so. What do I need to focus on at first? Bonno Bloksma
