DHCP per Linux-Server: Notebook bekommt IP, Samsung Fernseher nicht
Hallo,
auf einem Linux-Router läuft dhcpd, in der /etc/dhcp/dhcpd.conf ist die zu vergebende Rage definiert:
Wenn ich mit per Notebook an den eth4 anschließe, bekomme ich sofort eine IP zugewiesen und komme ins Internet. Wenn ich einen Samsung-Fernseher, eine Playstation oder Fritzbox (via WAN im Modus anschließe, bekommen diese kein Netz. Kabel/Dose kann als Problem ausgeschlossen werden, da alle Geräte incl. Notebook am gleichen Patchkabel getestet werden.
Im Syslog des Routers finde ich die Geräte im Minutentakt:
May 16 16:33:27 router dhcpd[177785]: DHCPDISCOVER from 70:b1:xx:xx:xx:bc via eth4
May 16 16:33:28 router dhcpd[177785]: DHCPOFFER on 192.168.5.53 to 70:b1:xx:xx:xx:bc (Samsung) via eth4
May 16 16:31:39 router dhcpd[177785]: DHCPDISCOVER from 78:c8:xx:xx:xx:dd via eth4
May 16 16:31:39 router dhcpd[177785]: DHCPOFFER on 192.168.5.51 to 78:c8:xx:xx:xx:dd via eth4
May 16 16:52:53 router dhcpd[177785]: DHCPDISCOVER from 98:9b:xx:xx:xx:c3 (fritz.box) via eth4
May 16 16:52:54 router dhcpd[177785]: DHCPOFFER on 192.168.5.52 to 98:9b:xx:xx:xx:c3 (fritz.box) via eth4
Warum nehmen diese Geräte die DHCP-Offer nicht an, das Notebook aber schon?
auf einem Linux-Router läuft dhcpd, in der /etc/dhcp/dhcpd.conf ist die zu vergebende Rage definiert:
subnet 192.168.5.0 netmask 255.255.255.0 {
interface eth4;
pool {
deny dynamic bootp clients;
range 192.168.5.50 192.168.5.250;
default-lease-time 3600;
max-lease-time 7200;
}
option routers 192.168.5.1;
option domain-name-servers 8.8.8.8;
}Wenn ich mit per Notebook an den eth4 anschließe, bekomme ich sofort eine IP zugewiesen und komme ins Internet. Wenn ich einen Samsung-Fernseher, eine Playstation oder Fritzbox (via WAN im Modus anschließe, bekommen diese kein Netz. Kabel/Dose kann als Problem ausgeschlossen werden, da alle Geräte incl. Notebook am gleichen Patchkabel getestet werden.
Im Syslog des Routers finde ich die Geräte im Minutentakt:
May 16 16:33:27 router dhcpd[177785]: DHCPDISCOVER from 70:b1:xx:xx:xx:bc via eth4
May 16 16:33:28 router dhcpd[177785]: DHCPOFFER on 192.168.5.53 to 70:b1:xx:xx:xx:bc (Samsung) via eth4
May 16 16:31:39 router dhcpd[177785]: DHCPDISCOVER from 78:c8:xx:xx:xx:dd via eth4
May 16 16:31:39 router dhcpd[177785]: DHCPOFFER on 192.168.5.51 to 78:c8:xx:xx:xx:dd via eth4
May 16 16:52:53 router dhcpd[177785]: DHCPDISCOVER from 98:9b:xx:xx:xx:c3 (fritz.box) via eth4
May 16 16:52:54 router dhcpd[177785]: DHCPOFFER on 192.168.5.52 to 98:9b:xx:xx:xx:c3 (fritz.box) via eth4
Warum nehmen diese Geräte die DHCP-Offer nicht an, das Notebook aber schon?
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672907
Url: https://administrator.de/forum/dhcp-per-linux-server-notebook-bekommt-ip-samsung-fernseher-nicht-672907.html
Ausgedruckt am: 06.06.2025 um 01:06 Uhr
4 Kommentare
Neuester Kommentar
tcpdump Mitschnitt des DHCP Traffics machen und hier posten ...
Monitor DHCP Traffic with tcpdump
Und zu Debug-Zwecken erst mal jegliche AccessList Anweisung (deny ...) aus dem Pool raus nehmen bzw. auskommentieren.
Monitor DHCP Traffic with tcpdump
Und zu Debug-Zwecken erst mal jegliche AccessList Anweisung (deny ...) aus dem Pool raus nehmen bzw. auskommentieren.
1
Ist das der ISC DHCP Server?
Eine korrekte Konfig kannst du u.a. hier nachlesen. (Die VLAN Segmente kannst du dir wegdenken).
Wie oben schon gesagt ist ein tcpdump Trace am Server (tcpdump port 67 or 68) sehr hilfreich um zu sehen was genau mit der TV Adressbergabe passiert.
ISC solltest du auf längere Sicht nicht mehr verwenden sondern den neuen KEA weil der ISC nicht mehr weiter entwickelt wird.
<OT> Google DNS zu verwenden machen heute nichtmal mehr Dummies. Die Gründe kennst du als guter Admin auch selber...
Normal verwendet man immer den lokalen Router wenn der DNS Caching anbietet wie es in der Regel alle Router und Firewalls machen. Ansonsten vertrauenswürdigere DNS Server die nicht deine privaten Daten öffentlich vermarkten.
https://privacy-handbuch.de/handbuch_93d.htm
https://www.heise.de/news/Quad9-Datenschutzfreundliche-Alternative-zum-G ...
Wenn man denn meint unbedingt US DNS Server nutzen zu müssen.
Falls von Interesse hier einmal eine einfache KEA DHCP Konfig:
Eine korrekte Konfig kannst du u.a. hier nachlesen. (Die VLAN Segmente kannst du dir wegdenken).
Wie oben schon gesagt ist ein tcpdump Trace am Server (tcpdump port 67 or 68) sehr hilfreich um zu sehen was genau mit der TV Adressbergabe passiert.
ISC solltest du auf längere Sicht nicht mehr verwenden sondern den neuen KEA weil der ISC nicht mehr weiter entwickelt wird.
<OT> Google DNS zu verwenden machen heute nichtmal mehr Dummies. Die Gründe kennst du als guter Admin auch selber...
Normal verwendet man immer den lokalen Router wenn der DNS Caching anbietet wie es in der Regel alle Router und Firewalls machen. Ansonsten vertrauenswürdigere DNS Server die nicht deine privaten Daten öffentlich vermarkten.
https://privacy-handbuch.de/handbuch_93d.htm
https://www.heise.de/news/Quad9-Datenschutzfreundliche-Alternative-zum-G ...
Wenn man denn meint unbedingt US DNS Server nutzen zu müssen.
Falls von Interesse hier einmal eine einfache KEA DHCP Konfig:
{
"Dhcp4": {
// Interfaces where the server listens: [ "eth1" ]
"interfaces-config": {
"interfaces": [ "eth1" ]
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/tmp/dhcp4.leases"
},
"authoritative": true,
"valid-lifetime": 28800,
"reservations-global": true,
"reservations-in-subnet": false,
"option-data": [
{
"name": "domain-name-servers",
"data": "192.168.5.1"
},
{
"name": "domain-name",
"data": "meinnetz.internal"
},
{
"name": "time-servers",
"data": "192.168.5.1"
}
],
"subnet4": [
{
"subnet": "192.168.5.0/24",
"pools": [ { "pool": "192.168.5.50 - 192.168.5.250" } ],
"option-data": [
{
"name": "routers",
"data": "192.168.5.1"
}
]
}
],
"reservations": [
// MAC address reservation
{
"hw-address": "00:23:7a:3f:05:23",
"ip-address": "192.168.5.11"
// "hostname": "Winserver"
}
],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/tmp/kea-dhcp4.log",
"maxver": 10
}
],
"severity": "INFO"
}
]
}
} 
Moin,
Nachdem in den Logs steht, das ein dhcpoffer erfolgt, würde ich per tcpdump/wireshark schauen, ob das auch wirklich über die Leitung geht und was drinsteht.
Testweise könnte man auch irgendeinen Billigrouter aus dem nächsten Baumarkt oder einen mikrotik herx für 20 Euro holen und schauen, ob es damit funktioniert. Dann kann man mit tcpdimp/wireshark bachschauen, ob und wie die Datenpakete sich unterscheiden.
lks
Nachdem in den Logs steht, das ein dhcpoffer erfolgt, würde ich per tcpdump/wireshark schauen, ob das auch wirklich über die Leitung geht und was drinsteht.
Testweise könnte man auch irgendeinen Billigrouter aus dem nächsten Baumarkt oder einen mikrotik herx für 20 Euro holen und schauen, ob es damit funktioniert. Dann kann man mit tcpdimp/wireshark bachschauen, ob und wie die Datenpakete sich unterscheiden.
lks
1
Danke für eure Tipps. Es ist ein ISC DHCP-Server. Nach ca. einem Tag ließen sich die restlichen Geräte dann auch per DHCP konfigurieren. Ich werde mittefirstig Richtung KEA migrieren.
1
