# Kea-dhcp4-server n'écoute pas sur le port 67 (bootps)

**URL:** <https://www.debian-fr.org/t/kea-dhcp4-server-necoute-pas-sur-le-port-67-bootps/89188>\
**Category:** Support Debian\
**Tags:** dhcp\
**Created:** [Novembre 19, 2023, 9:10 UTC](https://www.debian-fr.org/t/kea-dhcp4-server-necoute-pas-sur-le-port-67-bootps/89188 "2023-11-19T21:10:09Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![libresurf](https://www.debian-fr.org/user_avatar/www.debian-fr.org/libresurf/32/5259_2.png) [@libresurf](https://www.debian-fr.org/u/libresurf)\
**Post date:** [Novembre 19, 2023, 9:10 UTC](https://www.debian-fr.org/t/kea-dhcp4-server-necoute-pas-sur-le-port-67-bootps/89188/1 "2023-11-19T21:10:09Z")

</div>

Bonjour,

Sous **Debian 12 bookworm** , j’ai installé le paquet _kea_ pour configurer un serveur DHCP.  
Le paquet _kea_ est un méta-paquet qui installe automatiquement _kea-dhcp4-server_ et _kea-dhcp6-server_.

Voici ma configuration de _/etc/kea/kea-dhcp4.conf_ :

```
{
"Dhcp4": {
    "interfaces-config": {
        "interfaces": [
              "enP1p1s0"
        ]
    },
    "control-socket": {
        "socket-type": "unix",
        "socket-name": "/run/kea/kea4-ctrl-socket"
    },
    "lease-database": {
        "type": "memfile",
        "lfc-interval": 3600,
        "persist": true,
        "name": "/var/lib/kea/kea-leases4.csv"
    },
    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "unwarned-reclaim-cycles": 5
    },
    "renew-timer": 900,
    "rebind-timer": 1800,
    "valid-lifetime": 28800,
    "option-data": [
        {
            "name": "domain-name-servers",
            "data": "192.0.2.252, 192.0.2.253"
        }
    ],
    "subnet4": [
        {
            "subnet": "192.0.2.0/24",
            "pools": [{ "pool": "192.0.2.1 - 192.0.2.199" }],
            "option-data": [
                {
                    "name": "routers",
                    "data": "192.0.2.254"
                }
            ]
        }
    ],
    "loggers": [
    {
        "name": "kea-dhcp4",
        "output_options": [
            {
                "output": "/var/log/kea/kea-dhcp4.log",
                "maxsize": 1048576,
                "maxver": 10
            }
        ],
        "severity": "INFO",
        "debuglevel": 0
    }
  ]
}
}

```

et celle de _/etc/kea/kea-dhcp6.conf_ :

```
{
"Dhcp6": {
    "interfaces-config": {
        "interfaces": [
                      "enP1p1s0"
        ]
    },
    "control-socket": {
        "socket-type": "unix",
        "socket-name": "/run/kea/kea6-ctrl-socket"
    },
    "lease-database": {
        "type": "memfile",
        "lfc-interval": 3600,
        "persist": true,
        "name": "/var/lib/kea/kea-leases6.csv"
    },
    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "unwarned-reclaim-cycles": 5
    },
    "renew-timer": 1000,
    "rebind-timer": 2000,
    "preferred-lifetime": 3000,
    "valid-lifetime": 28800,
    "option-data": [
        {
            "name": "dns-servers",
            "data": "2001:db8:192:0::252, 2001:db8:192:0::253"
        }
    ],
    "subnet6": [
        {
            "subnet": "2001:db8:192:0::/64",
            "pools": [{ "pool": "2001:db8:192:0::1 - 2001:db8:192:0::199" }]
        }
    ],
    "loggers": [
    {
        "name": "kea-dhcp6",
        "output_options": [
            {
                "output": "/var/log/kea/kea-dhcp6.log",
                "maxsize": 1048576,
                "maxver": 10
            }
        ],
        "severity": "INFO",
        "debuglevel": 0
    }
  ]
}
}

```

J’utilise _systemd_ pour gérer le lancement de kea-dhcp4-server et de kea-dhcp6-server :

```
# systemctl restart kea-dhcp4-server.service
# systemctl restart kea-dhcp6-server.service

```

Mon problème est que _kea-dhcp4-server_ n’écoute pas sur le port 67 (bootps) les requêtes des futurs clients DHCP.  
Alors que _kea-dhcp6-server_, lui écoute bien sur le port 547 (dhcp6-server) pour l’Ipv6 !

Voici la sortie de _ss_ :

```
root@server:/etc/kea# ss -lup
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process                                           
UNCONN 0 0 192.168.0.19%enP2p1s0:bootpc 0.0.0.0:* users:(("systemd-network",pid=289,fd=18))        
UNCONN 0 0 127.0.0.1:53001 0.0.0.0:* users:(("kea-dhcp-ddns",pid=1567,fd=13))         
UNCONN 0 0 [fe80::146c:dfff:feb9:9df0]%enP2p1s0:dhcpv6-client [::]:* users:(("systemd-network",pid=289,fd=21))        
UNCONN 0 0 [fe80::1494:98ff:fea9:d341]%enP1p1s0:dhcpv6-server [::]:* users:(("kea-dhcp6",pid=3431,fd=15))             
UNCONN 0 0 [ff02::1:2]%enP1p1s0:dhcpv6-server [::]:* users:(("kea-dhcp6",pid=3431,fd=16))

```

Savez-vous quel est le problème ?  
Merci à vous.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Novembre 19, 2023, 10:45 UTC](https://www.debian-fr.org/t/kea-dhcp4-server-necoute-pas-sur-le-port-67-bootps/89188/2 "2023-11-19T22:45:46Z")

</div>

Ton serveur écoute sur le port 68 (bootpc)  
Peut tu nous donner un `ip a` s’il te plait? si ton interface enp2P1s0 est en DHCP, c’est pour ça que ton serveur ne démarre pas. Car le client écoute sur le port 68.  
Un serveur DHCP ne peut pas être définit sur une interface en DHCP.

---

<div class="post-metadata">

**Author:** ![libresurf](https://www.debian-fr.org/user_avatar/www.debian-fr.org/libresurf/32/5259_2.png) [@libresurf](https://www.debian-fr.org/u/libresurf)\
**Post date:** [Novembre 20, 2023, 8:30 UTC](https://www.debian-fr.org/t/kea-dhcp4-server-necoute-pas-sur-le-port-67-bootps/89188/3 "2023-11-20T20:30:33Z")

</div>

Bonjour @Zargos,

Voici la sortie de la commande _ip a_ :

```
root@server:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enP2p1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 16:6c:df:b9:9d:f0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.19/24 metric 10 brd 192.168.0.255 scope global dynamic enP2p1s0
       valid_lft 26866sec preferred_lft 26866sec
    inet6 2a01:e0a:26:d3a0::46af:ab1/128 scope global dynamic noprefixroute 
       valid_lft 45185sec preferred_lft 45185sec
    inet6 fe80::146c:dfff:feb9:9df0/64 scope link 
       valid_lft forever preferred_lft forever
3: enP1p1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 16:94:98:a9:d3:41 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.254/24 brd 192.168.2.255 scope global enP1p1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::1494:98ff:fea9:d341/64 scope link 
       valid_lft forever preferred_lft forever

```

J’ai oublié de préciser, la machine est un [NanoPi R5C](https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R5C) avec deux cartes réseaux :

- Port WAN sur interface enP2p1s0, qui est paramétrée pour obtenir son adresse IP par DHCP. Donc, c’est logique que cette interface écoute sur le port 68 (bootpc);
- Port LAN sur interface enP1p1s0, dont l’adresse IPv4 est paramétrée en dur et qui sert de serveur DHCP pour le réseau qui lui sera connecté.

Les deux interfaces sont paramétrées par Systemd.

Voici le fichier de configuration du port WAN (_/etc/systemd/network/10-ethernet-WAN.network_):

```
[Match]
Name=enP2p1s0

[Network]
DHCP=yes

[DHCP]
UseDomains=yes
RouteMetric=10

```

Voici le fichier de configuration du port LAN (_/etc/systemd/network/15-ethernet-LAN.network_):

```
[Match]
Name=enP1p1s0

[Network]
Address=192.168.2.254/24

```

Cette configuration est volontairement très minimaliste pour être sur que _Systemd_ n’interfère pas avec le serveur _kea-dhcp._

Voici la sortie de _networkctl list_ :

```
root@server:~# networkctl 
IDX LINK TYPE OPERATIONAL SETUP     
  1 lo loopback carrier unmanaged
  2 enP2p1s0 ether routable configured
  3 enP1p1s0 ether routable configured

3 links listed.
```

---

<div class="post-metadata">

**Author:** ![libresurf](https://www.debian-fr.org/user_avatar/www.debian-fr.org/libresurf/32/5259_2.png) [@libresurf](https://www.debian-fr.org/u/libresurf)\
**Post date:** [Novembre 20, 2023, 9:55 UTC](https://www.debian-fr.org/t/kea-dhcp4-server-necoute-pas-sur-le-port-67-bootps/89188/4 "2023-11-20T21:55:34Z")

</div>

Si je modifie le fichier de configuration du port LAN ( _/etc/systemd/network/15-ethernet-LAN.network_ ) en rajoutant une section DHCPServer :

```
[Match]
Name=enP1p1s0

[Network]
Address=192.168.2.254/24
DHCPServer=true

[DHCPServer]
ServerAddress=192.168.2.254/24

```

alors c’est le serveur DHCP de _Systemd_ qui se lance, ce que je ne veux pas !

```
root@server:~# ss -lup
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process                                                                                      
UNCONN 0 0 127.0.0.1:53001 0.0.0.0:* users:(("kea-dhcp-ddns",pid=508,fd=13))                                                     
UNCONN 0 0 0.0.0.0%enP1p1s0:bootps 0.0.0.0:* users:(("systemd-network",pid=608,fd=25))                                                   
UNCONN 0 0 192.168.0.19%enP2p1s0:bootpc 0.0.0.0:* users:(("systemd-network",pid=608,fd=18))                                                   
UNCONN 0 0 [fe80::146c:dfff:feb9:9df0]%enP2p1s0:dhcpv6-client [::]:* users:(("systemd-network",pid=608,fd=21))                                                   

```

et je perds le _kea-dhcp6_ que j’avais auparavant !!!

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Novembre 20, 2023, 10:29 UTC](https://www.debian-fr.org/t/kea-dhcp4-server-necoute-pas-sur-le-port-67-bootps/89188/5 "2023-11-20T22:29:50Z")

</div>

En fait tu n’as pas compris.  
Ton serveur DHCP fourni les adresse sur le réseau 192.168.0.0/24 sur l’interface WAN. L’interface correspondante doit être statique, elle ne peut pas être dynamique.  
De plus, il faut que le routeur entre 192.168.0.0/24 et 192.0.2.0/24 dispose de la fonctionnalité de relay DHCP.  
Par ailleurs, juste pour savoir, c’est une plateforme de tests? car 192.0.0.0 est un segment IP réservée par l’agence de gestion des adresses IP et non attribuée en tant qu’IP publique ou privée.

---

<div class="post-metadata">

**Author:** ![libresurf](https://www.debian-fr.org/user_avatar/www.debian-fr.org/libresurf/32/5259_2.png) [@libresurf](https://www.debian-fr.org/u/libresurf)\
**Post date:** [Novembre 22, 2023, 7:54 UTC](https://www.debian-fr.org/t/kea-dhcp4-server-necoute-pas-sur-le-port-67-bootps/89188/6 "2023-11-22T19:54:57Z")

</div>

Bonjour @Zargos ,  
Merci pour ton retour.

Je vais commencer par ça :

> [@Zargos](#):
>
> Par ailleurs, juste pour savoir, c’est une plateforme de tests? car 192.0.0.0 est un segment IP réservée par l’agence de gestion des adresses IP et non attribuée en tant qu’IP publique ou privée.

Oui, c’est une plateforme de test avec un réseau privé.

Ensuite :

> [@](#):
>
> En fait tu n’as pas compris.  
> Ton serveur DHCP fourni les adresse sur le réseau 192.168.0.0/24 sur l’interface WAN. L’interface correspondante doit être statique, elle ne peut pas être dynamique.  
> De plus, il faut que le routeur entre 192.168.0.0/24 et 192.0.2.0/24 dispose de la fonctionnalité de relay DHCP.

J’ai mis du temps à comprendre ce que tu voulais dire… Je pense que j’ai compris.  
La RFC 1918 définit le bloc d’adresses 192.168.0.0/16 (masque de sous réseau 192.168.255.255) qui englobe le sous-réseau que je voulais définir 192.168.2.0/24 (masque de sous réseau 192.168.2.255).  
Du coup, si ma box internet fournit un serveur DHCP qui gère tout le réseau 192.168.0.0/16, je ne peux pas définir le sous-réseau 192.168.2.0/24 de manière autonome et c’est pour ça que le serveur _kea-dhcp4-server_ ne se lance pas.

Malheureusement, je n’ai pas vraiment «&nbsp;complètement&nbsp;» la main sur le serveur DHCP de ma box internet, donc je ne sais pas quelle est l’étendue du réseau qu’elle prend en compte.  
Du coup, j’ai changé mon fusil d’épaule et modifié l’adresse de réseau de mon interface LAN en 10.0.0.0/8.

Voici la nouvelle configuration de _etc/systemd/network/15-ethernet-LAN.network_ :

```
[Match]
Name=enP1p1s0

[Network]
Address=10.0.0.254/8

```

et celle de _/etc/kea/kea-dhcp4.conf_ :

```
{
"Dhcp4": {
    "interfaces-config": {
        "interfaces": [
              "enP1p1s0"
        ]
    },
    "control-socket": {
        "socket-type": "unix",
        "socket-name": "/run/kea/kea4-ctrl-socket"
    },
    "lease-database": {
        "type": "memfile",
        "lfc-interval": 3600,
        "persist": true,
        "name": "/var/lib/kea/kea-leases4.csv"
    },
    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "unwarned-reclaim-cycles": 5
    },
    "renew-timer": 900,
    "rebind-timer": 1800,
    "valid-lifetime": 28800,
    "option-data": [
        {
            "name": "domain-name-servers",
            "data": "10.0.0.252, 10.0.0.253"
        }
    ],
    "subnet4": [
        {
            "subnet": "10.0.0.0/8",
            "pools": [{ "pool": "10.0.0.1 - 10.0.0.199" }],
            "option-data": [
                {
                    "name": "routers",
                    "data": "10.0.0.254"
                }
            ]
        }
    ],
    "loggers": [
    {
        "name": "kea-dhcp4",
        "output_options": [
            {
                "output": "/var/log/kea/kea-dhcp4.log",
                "maxsize": 1048576,
                "maxver": 10
            }
        ],
        "severity": "INFO",
        "debuglevel": 0
    }
  ]
}
}

```

**et ça marche !** 😃 👍

Voici la sortie de la commande _ss -lup_ :

```
root@server:~# ss -lup
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process                                          
UNCONN 0 0 127.0.0.1:53001 0.0.0.0:* users:(("kea-dhcp-ddns",pid=505,fd=13))         
UNCONN 0 0 10.0.0.254:bootps 0.0.0.0:* users:(("kea-dhcp4",pid=506,fd=15))             
UNCONN 0 0 192.168.0.19%enP2p1s0:bootpc 0.0.0.0:* users:(("systemd-network",pid=289,fd=10))       
UNCONN 0 0 [fe80::146c:dfff:feb9:9df0]%enP2p1s0:dhcpv6-client [::]:* users:(("systemd-network",pid=289,fd=23))       

```

**Le serveur kea-dhcp4-server est bien lancé !** et je confirme qu’il fonctionne car il attribue une adresse IP 10.0.0.1 au premier client qui se connecte.

Maintenant, le problème se pose pour _kea-dhcp6-server_ qui n’est pas opérationnel.  
Et là se pose certainement le problème du relais DHCP (mais en IPv6) dont tu parles.  
Il faut que j’explore cette piste…
