(Gelöst) DHCP sehr langsam

Bordi

Hallo

Ich rätsle noch rum. Seit kurzem dauert es beim Bezug der IP etwas länger. Der Zeitpunkt vom erst auftreten (02/15/18) fällt gleich mit dem Upgrade auf 2.4.3, einem angekündigten iNet-Unterbruch seitens des Dienstleisters, so-wie auf die DNSSEC Aktivierung seitens TLD-Host. Wobei letzteres Zeitlich am besten passt. Die Zeitabstände bis zum Netzwerkkontakt sind unterschiedlich, jedoch lang und scheinen unabhängig von der Anbindung (Cable/Wireless). Damit ihr euch diesbezüglich mal was vorstellen könnt: Mit dem Mac über WLAN geht es mit unter 1min am schnellsten. Hingegen musste die PS4 an die Leine, und selbst so darf der Netzwerk-Test nicht gestartet werden da er ansonsten wegen Zeitüberschreitung fehlschlägt. Bis sie ihre IP aus dem nichts erhält, können schon mal 15min vergehen. Ich rufe nach dem einschalten meistens die Netzwerkinformationen auf und geh Kaffee trinken. Wobei ich hinterher -wegen der Zeitüberschreitung- manuell ins PSN einloggen muss. Die durchschnittliche Dauer für einen Verbindungsaufbau beträgt bei der Mehrheit der übrigen Clients 2-3 Minuten. Je nach Gerät sind die Werte recht zuverlässig. Bei meinem Notebook meist auf die Sekunde genau 3 Minuten. Steht die Verbindung mal, wirkt sie recht flink und stabil. ???
Ich hatte ursprünglich eine ultrakurze Standard Lease-Zeit eingerichtet. Musste dies jedoch ändern (ist jetzt auf Werkseinstellung). Die Einstellungen am DHCP blieben soweit unverändert. Alle meine Clients genießen eine statische Zuordnung, die Range die der DHCP absuchen muss halte ich absichtlich kurz (2 IP's, x.x.x.100 - x.x.x.112).

Ich hoffe nun dass ihr damit was anfangen könnt, wenn nicht kann ich weitere infos nachreichen.

Hoffe derzeit nur das es bald wieder rennt wie es sollte. :-\

renegade

Nur ein kurzer Gedanke:
Kannst Du ausschließen, dass keine IP doppelt vergeben ist?
Sei es durch statische oder vlt dass ein Client den Lease einfach erneuert. (wird ja immer nach der Halbwertszeit der Leasedauer probiert.)

Bordi

Ja das kann ich. Die statischen vergaben sind nicht doppelt, und die 2 IPs welche dynamisch vergeben werden idr ungenutzt (da für neugeräte).

Birke

gibt es denn einträge im system-log unter dhcp?
läuft der dhcp-dienst denn auch (unter status/services)? starte den da sicherheitshalber mal neu, vielleicht hängt der nur etwas.

Bordi

In den logs steht eigentlich nichts sonderbares, bis auf eines..```
1.pool.ntp.org: temporary name server failure

Etwas weiter in den logs unter NTP dan dies```
Apr 5 14:50:28	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:49:23	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:48:19	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:47:13	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:46:09	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:45:02	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:43:57	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:42:53	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:41:47	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:40:43	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:39:36	ntpd	88852	error resolving pool 1.pool.ntp.org: hostname nor servname provided, or not known (8)
Apr 5 14:38:31	ntpd	88852	...
```???
Der neustart hat nichts ergeben.

JeGr

Dann läuft/löst der DNS nicht richtig (auf). Ansonsten gäbe es ja kein Problem mit 1.pool.ntp.org. Was eigentlich ziemlich sofort mit sowas wie

Nicht autorisierende Antwort:
Name: 1.pool.ntp.org
Addresses: 185.183.156.211
178.63.9.110
212.18.3.18
46.163.88.246

aufgelöst werden sollte. Also vielleicht mal den Resolver und die DNSe unter Sys/General prüfen.

Vielleicht hat auch der Resolver ein Problem so dass der DHCP keine Einträge dort platzieren kann und deshalb ausgebremst wird.

Bordi

Dann hat die DNSSEC Umstellung schuld. Ich bin nun von Quad9 auf Cloudflare und habe die Konfiguration wie HIER beschrieben vorgenommen. Die Konfiguration vom Resolver ist jetzt wie folgt```
<unbound><port>53</port>
<active_interface>lan</active_interface>
<outgoing_interface>wan</outgoing_interface>
<system_domain_local_zone_type>transparent</system_domain_local_zone_type> <custom_options>c2VydmVyOgpmb3J3YXJkLXpvbmU6Cm5hbWU6ICIuIgpmb3J3YXJkLXNzbC11cHN0cmVhbTogeWVzCmZvcndhcmQtYWRkcjogMS4xLjEuMUA4NTMKZm9yd2FyZC1hZGRyOiAxLjAuMC4xQDg1MwpzZXJ2ZXI6aW5jbHVkZTogL3Zhci91bmJvdW5kL3BmYl9kbnNibC4qY29uZg==</custom_options>
<hosts>..</hosts>

<msgcachesize>4</msgcachesize>
<outgoing_num_tcp>10</outgoing_num_tcp>
<incoming_num_tcp>10</incoming_num_tcp>
<edns_buffer_size>4096</edns_buffer_size>
<num_queries_per_thread>512</num_queries_per_thread>
<jostle_timeout>200</jostle_timeout>
<cache_max_ttl>86400</cache_max_ttl>
<cache_min_ttl>0</cache_min_ttl>
<infra_host_ttl>900</infra_host_ttl>
<infra_cache_numhosts>10000</infra_cache_numhosts>
<unwanted_reply_threshold>disabled</unwanted_reply_threshold>
<log_verbosity>1</log_verbosity>

<enable></enable>

<dnsrecordcache></dnsrecordcache>
<use_caps></use_caps></unbound>

In den custom_options steht```
server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853
server:include: /var/unbound/pfb_dnsbl.*conf

In den log's von DHCP und NTP habe ich bisher nichts ungewöhnliches finden können. Nach einem DNSBL Reload von pfBlockerNG blieb eine Meldung übrig```
[ DNSBL_WaLLy3KsTrackingTelemetryLists - tyzbit ] Download FAIL [ 04/05/18 15:47:17 ]

Im allgemeinen surft es sich noch etwas hakelig, insbesondere die PS4 will nicht (auch nicht über Kabel).

JeGr

Nimm mal den Custom Options Block raus. Es gibt einige Reports, die sagen dass der DNS over TLS Kram derart lahm ist, dass sie Timeouts etc. bekommen und deshalb das DNS hinten wie vorne nicht funktioniert. Einfach mal 1.1.1.1 und 1.0.0.1 als normale DNS Forwarder rein und damit testen, statt via 853 DNSoverTLS.

Bordi

Mach ich.. ;)

Hast du ne Ahnung was dies bedeuten könnte```
Apr 5 16:54:12 radvd 52113 sendmsg: Permission denied
Apr 5 16:54:06 radvd 52113 sendmsg: Permission denied
Apr 5 16:53:59 radvd 52113 sendmsg: Permission denied
Apr 5 16:53:53 radvd 52113 sendmsg: Permission denied
Apr 5 16:53:43 radvd 52113 sendmsg: Permission denied
Apr 5 16:53:37 radvd 52113 sendmsg: Permission denied
Apr 5 16:53:29 radvd 52113 sendmsg: Permission denied
Apr 5 16:53:23 radvd 52113 sendmsg: Permi

Die Meldung rennt in den logs endlos (unter System>Routing) ???

NACHTRAG: Hab das so eingerichtet und die beiden Dienste neu gestartet. Hab dann die PS4 gestartet - keine Verbindung.  Nach etwas warten fan ich in den Netzwerkinfos die IPs, und hab den Test gestartet - ein Fehlschuss. Aber in den logs von pfS fand ich ..

Apr 5 17:08:49 dhcpd DHCPACK on PS4 to MAC via lagg0
Apr 5 17:08:49 dhcpd DHCPREQUEST for PS4 (pfS) from MAC via lagg0
Apr 5 17:08:49 dhcpd DHCPOFFER on PS4 to MAC via lagg0
Apr 5 17:08:49 dhcpd DHCPDISCOVER from MAC via lagg0

Vermute ich falsch wen ich davon ausgehe das was am Resolver ist was die PS4 nicht verträgt?

2\. NACHTRAG: Ich lag wohl falsch. Egal ob PS4 oder TV, WLAN oder LAN. Wenn ich die Netzwerkkonfiguration am Gerät fest eingebe flutscht es auf anhieb. Dies auch dann wenn ich die IP der Firewall als Primärerer DNS angebe, und auch wenn die DNS über TLS geht. https://www.netgate.com/blog/dns-over-tls-with-pfsense.html
Daher denke ich mal dass meine Annahme das der Resolver bez die DNSSEC Umstellung schuld sein könnte falsch ist. Deutlich warscheinlicher scheint mir das am DHCP was nicht stimmt. Allerdings wüsste ich nicht wass.  :-[ In den log's unter System > Routing gesehen das so oder ähnlich aussah ..
[code]syntax error in /var/etc/radvd.conf, line 9
??? Zum reckonstuieren fand ich bisher aber noch keine Zeit. Ich melde mich wieder wen ich soweit bin.  ;)
Bis dahin gut Nacht  ;D

 **3\. NACHTRAG:** Guten Morgen :D Anschliessen an den letzten Post von Gestern konnte ich die Fehlermeldung in _Status > Systemprotokollierung > System > Routing_ rekonstruieren.

Apr 6 08:30:54 radvd 52113 sendmsg: Permission denied
Apr 6 08:30:44 radvd 52113 resuming normal operation
Apr 6 08:30:44 radvd 52113 sendmsg: Permission denied
Apr 6 08:30:44 radvd 52113 invalid all-zeros prefix in /var/etc/radvd.conf, line 9
Apr 6 08:30:44 radvd 52113 attempting to reread config file
Apr 6 08:30:34 radvd 52113 sendmsg: Permission denied
Apr 6 08:30:24 radvd 52113 resuming normal operation
Apr 6 08:30:24 radvd 52113 sendmsg: Permission denied
Apr 6 08:30:24 radvd 52113 invalid all-zeros prefix in /var/etc/radvd.conf, line 9
Apr 6 08:30:24 radvd 52113 attempting to reread config file
Apr 6 08:30:18 radvd 52113 sendmsg: Permission denied
Apr 6 08:30:08 radvd 52113 sendmsg: Permission denied
Apr 6 08:29:58 radvd 52113 resuming normal operation
Apr 6 08:29:58 radvd 52113 sendmsg: Permission denied
Apr 6 08:29:58 radvd 52113 invalid all-zeros prefix in /var/etc/radvd.conf, line 9
Apr 6 08:29:58 radvd 52113 attempting to reread config file
Apr 6 08:29:55 radvd 52113 sendmsg: Permission denied
Apr 6 08:29:50 radvd 52113 sendmsg: Permission denied
Apr 6 08:29:41 radvd 52113 sendmsg: Permission denied
Die Meldung erscheint im Zusammenhang von TV / PS4 und dem Anfordern der IP (DHCP). Ich hab die Datei nachgeschlagen..

Automatically Generated, do not edit

Generated config for dhcp6 delegation from wan on lan

interface lagg0 {
AdvSendAdvert on;
MinRtrAdvInterval 5;
MaxRtrAdvInterval 10;
AdvLinkMTU 1500;
AdvOtherConfigFlag on;
prefix ::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
DNSSL meinetdl.lan { };
};
..soweit richtig gezählt und davon ausgehen das die erste linie mit der 0 beziffert wird, steht in linie 9
AdvOnLink on;

Jemand eine Idee? Ich kenne mich damit nicht so aus, und suche noch. Nur eines weiss ich bestimmt: Ich arbeite mit IPv4 und habe IPv6 derzeit noch ausgeschlossen.

JeGr

Ich denke eher ist ist die Zeile

AdvAutonomous on;

denn Line 9 wird normalerweise von der Ausführung gezählt und die # Zeilen zählen nicht.

Anyway RADVD ist der Route Daemon von IPv6 bzw. DHCP6. Da wird also dein Problem mit den Logmeldungen her kommen, also ggf. mal in den DHCP6 Server reinschauen und/oder den ganz abklemmen und v6 mal nur stateless announcen. Ansonsten den DHCP4 und Resolver mal neu starten.

Apr 5 17:08:49 dhcpd DHCPACK on PS4 to MAC via lagg0
Apr 5 17:08:49 dhcpd DHCPREQUEST for PS4 (pfS) from MAC via lagg0
Apr 5 17:08:49 dhcpd DHCPOFFER on PS4 to MAC via lagg0
Apr 5 17:08:49 dhcpd DHCPDISCOVER from MAC via lagg0

Das war auf jeden Fall ein völlig normaler und gültiger Handshake. Ist dann eher die Frage ob die PS4 daraufhin eine IP angenommen hat und mit welchen zusätzlichen Daten. Evtl. auch mal den DHCP4 prüfen, was der als DNS etc. rausgibt oder ob da nichts drinsteht und die Sense daher dann automatisch sich da reinschreibt. Ansonsten könnte es sein, dass sie irgendwelche anderen DNSe aus System/General da reinpinselt oder ganz durcheinander kommt, weil du die Forwarder und Co ja eben komplett mit deiner Custom Config für 1.1.1.1 überschreibst. Also notfalls in die DNS Felder vom DHCP mal manuell die IP der Sense reinschreiben, damit da der Automatismus nichts Grütziges macht.

Bordi

@JeGr:

..oder den ganz abklemmen und v6 mal nur stateless announcen. ..

Gibt es dafür ein Workaround? Denn eigentlich dürfte IPv6 nicht aktiv sein. :o ??? ???

@JeGr:

Das war auf jeden Fall ein völlig normaler und gültiger Handshake. Ist dann eher die Frage ob die PS4 daraufhin eine IP angenommen hat und mit welchen zusätzlichen Daten. ..

Nein eine IP hat sie nicht bekommen. Aber die frage was sie erhalten hat erscheint mir hinsichtlich RADVD recht spannend. :-\

..

Heureka ich hab's! 8)

Der Verweis auf IPv6/RADVD war super. Hinterher ist ja alles einfacher. So auch hier: Wo kein Interface da kein Traffik. Auf Opt2 war nichts, aber irgendwie hat sich bei WAN der IPv6 Konfigurationstyp DHCP6 und bei Opt1 "Ermittle Schnittstelle" eingeschlichen. Letzteres ist für ein LAGG über Opt1,Opt2 wohl nicht ganz optimal. ;D DHCP6, der Gateway waren zwar off, und so konfiguriert das keine lokalen IPv6 DNS-Einträge für LAN-Interfaces generiert werden, dass hat aber nicht daran gehindert pausenlos IPv6 ICMP zu senden und zu blocken. Nachdem ich alle Interfaces auf IPv6 Konfigurationstyp "keine" gesetzt habe, hatten sich sämtliche vorherigen Probleme erübrigt.

Über DNSSEC & DNS über TLS [kann ich berichten das es recht gut funktioniert, und zumindest Cloudflare’s DNS service kaum bremst. Ich erfuhr eher den Eindruck einer minimalen Beschleunigung. Das kann aber mit Quad9 ganz anders sein. Nebst dem möchte ich anmerken dass sich das System erst Einpendeln muss. ;)

Vielen Dank, ihr ward mir eine grosse Hilfe. 8)](kann ich berichten das es recht gut funktioniert, und zumindest Cloudflare’s DNS service kaum bremst. Ich erfuhr eher den Eindruck einer minimalen Beschleunigung. Das kann aber mit Quad9 ganz anders sein. Nebst dem möchte ich anmerken dass sich das System erst Einpendeln muss. ;)<br /><br />Vielen Dank, ihr ward mir eine grosse Hilfe. 8)<br /><br />)