staging.inyokaproject.org

So kleiner Nachtrag.... komm grade nach Hause, und starte das Notebook.... patsch gleiches Problem. Bekomme keine IPv4. Gehe zum Ubuntu Server und pinge web.de an, das klappt, der läuft also noch. Dann hab ich die IP manuell eingetragen auf dem Notebook, und auch den DNS manuell.... dann geht es. Der Ubuntu Server mit DHCP hat also ne Verbindung zur Vodafone Station, aber ist nicht in der Lage ne IP zuzuweisen weil die Vodafone Station vielleicht den Weg vergisst. Ich habe die Lease Zeit hochgesetzt und den dnsmasq Dienst neu gestartet.

Aber was ändert sich wenn ich die Vodafone-Station stromlos mache und wieder starte. Warum geht es dann, und warum werden die Abstände zwischen dem Ausschalten immer kürzer? Nachdem ich die Vodafone Station resettet hab lief sie Wochenlang. Vorher war das gleiche Verhalten. Und jetzt geht es wieder los. Und es endet dann wohl darin das auch nach einem Neustart nichts mehr geht.

gnude schrieb:

Der Ubuntu Server mit DHCP hat also ne Verbindung zur Vodafone Station, aber ist nicht in der Lage ne IP zuzuweisen weil die Vodafone Station vielleicht den Weg vergisst.

Was meinst Du mit "weil die Vodafone Station vielleicht den Weg vergisst"? Warum willst Du nicht schauen/testen ob dein Laptop (als DHCP-Client) zum Zeitpunkt des Problems auch den UDP-Port des DHCP-Servers (auf dem Ubuntu-Server) erreichen kann? Wie das geht hat man dir doch gezeigt. Starte auf dem Server:

sudo tcpdump -c 30 -vvveni any udp port 67

und mach vom laptop einen Portscan:

sudo nmap -sU -e wlp3s0 <IP-Adresse-Server> -p67

EDIT:

Hast Du die lease-Datei auf dem laptop gelöscht?

Schau mal auf dem DHCP-Server nach, wie viele und welche IP-Adressen aus seinem DHCP-Pool, z. Zt. noch gültig zugewiesen (d. h. besetzt) sind.

Auf dem Client....

14:32:09.798772 wlp3s0 B   ifindex 4 9a:75:f1:c8:12:0c ethertype IPv4 (0x0800), length 336: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 316)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 9a:75:f1:c8:12:0c, length 288, xid 0x3446b52d, secs 127, Flags [none] (0x0000)
	  Client-Ethernet-Address 9a:75:f1:c8:12:0c
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Discover
	    Client-ID (61), length 7: ether 9a:75:f1:c8:12:0c
	    MSZ (57), length 2: 1500
	    Vendor-Class (60), length 15: "android-dhcp-10"
	    Parameter-Request (55), length 11: 
	      Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
	      MTU (26), BR (28), Lease-Time (51), RN (58)
	      RB (59), Vendor-Option (43), Unknown (108)
	    END (255), length 0
	    PAD (0), length 0
14:32:58.790362 wlp3s0 Out ifindex 4 84:3a:4b:55:a3:7c ethertype IPv4 (0x0800), length 340: (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 320)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 84:3a:4b:55:a3:7c, length 292, xid 0xa388da98, secs 838, Flags [none] (0x0000)
	  Client-Ethernet-Address 84:3a:4b:55:a3:7c
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Discover
	    Client-ID (61), length 7: ether 84:3a:4b:55:a3:7c
	    Parameter-Request (55), length 17: 
	      Subnet-Mask (1), Time-Zone (2), Domain-Name-Server (6), Hostname (12)
	      Domain-Name (15), MTU (26), BR (28), Classless-Static-Route (121)
	      Default-Gateway (3), Static-Route (33), YD (40), YS (41)
	      NTP (42), Unknown (119), Classless-Static-Route-Microsoft (249), Unknown (252)
	      RP (17)
	    MSZ (57), length 2: 576
	    Requested-IP (50), length 4: 192.168.178.169
	    Hostname (12), length 8: "thinkpad"
	    END (255), length 0

gnude schrieb:

Auf dem Client....

	    Requested-IP (50), length 4: 192.168.178.169

Was der Client will und vom Server verlangt, wissen wir inzwischen. Kommt das beim Server auch an? Warum reagiert der Server nicht darauf?

EDIT:

Sorge auf dem Client dafür, dass dieser die IP 192.168.178.169 nicht mehr explizit will/verlangt und das vom Server nimmt, was er von dort bekommt.

Kurzes Update, ich habe mal feste IP Adressen vergeben und heute morgen um 9.50 kippte das IPv4 auf dem Notbook wieder weg, Habe dann Wifi kurz aus und an geschaltet und dann klappte es wieder.

Auszug aus dem Log auf dem Notebook

Nov 24 09:53:29 thinkpad rtkit-daemon[1161]: Supervising 8 threads of 5 processes of 1 users.
Nov 24 09:53:29 thinkpad rtkit-daemon[1161]: Supervising 8 threads of 5 processes of 1 users.
Nov 24 09:53:33 thinkpad systemd-resolved[884]: Using degraded feature set TCP instead of UDP for DNS server 2a02:908:1d16:10e0:10:18ff:feec:6
4bc.
Nov 24 09:53:46 thinkpad systemd-resolved[884]: Using degraded feature set UDP instead of TCP for DNS server 2a02:908:1d16:10e0:10:18ff:feec:6
4bc.
Nov 24 09:53:51 thinkpad systemd-resolved[884]: Using degraded feature set UDP instead of TCP for DNS server 192.168.178.39.
Nov 24 09:53:54 thinkpad systemd-resolved[884]: Using degraded feature set TCP instead of UDP for DNS server 192.168.178.39.
Nov 24 09:53:57 thinkpad systemd-resolved[884]: Using degraded feature set TCP instead of UDP for DNS server 2a02:908:1d16:10e0:10:18ff:feec:6
4bc.
Nov 24 09:54:04 thinkpad rtkit-daemon[1161]: Supervising 8 threads of 5 processe
s of 1 users.
Nov 24 09:54:08 thinkpad kernel: [12244.828127] DMAR: DRHD: handling fault status reg 2
Nov 24 09:54:08 thinkpad kernel: [12244.828144] DMAR: [DMA Write NO_PASID] Request device [00:02.0] fault addr 0xb52e8000 [fault reason 0x05] PTE Write access is not set
Nov 24 09:54:04 thinkpad rtkit-daemon[1161]: Supervising 8 threads of 5 processes of 1 users.
Nov 24 09:54:11 thinkpad systemd-resolved[884]: Using degraded feature set UDP instead of TCP for DNS server 2a02:908:1d16:10e0:10:18ff:feec:64bc.
Nov 24 09:54:14 thinkpad wpa_supplicant[934]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-30 noise=9999 txrate=117000
Nov 24 09:54:19 thinkpad systemd-resolved[884]: Using degraded feature set TCP instead of UDP for DNS server 2a02:908:1d16:10e0:10:18ff:feec:64bc.
Nov 24 09:54:29 thinkpad systemd-resolved[884]: Using degraded feature set UDP instead of TCP for DNS server 192.168.178.39.
Nov 24 09:54:32 thinkpad systemd-resolved[884]: Using degraded feature set TCP instead of UDP for DNS server 192.168.178.39.
Nov 24 09:54:35 thinkpad systemd-resolved[884]: Using degraded feature set UDP instead of TCP for DNS server 2a02:908:1d16:10e0:10:18ff:feec:64bc.
Nov 24 09:54:43 thinkpad systemd-resolved[884]: Using degraded feature set TCP instead of UDP for DNS server 2a02:908:1d16:10e0:10:18ff:feec:64bc.
Nov 24 09:54:57 thinkpad systemd-resolved[884]: Using degraded feature set UDP instead of TCP for DNS server 2a02:908:1d16:10e0:10:18ff:feec:64bc.
Nov 24 09:55:02 thinkpad systemd-resolved[884]: Using degraded feature set UDP instead of TCP for DNS server 192.168.178.39.

gnude schrieb:

ich habe mal feste IP Adressen vergeben und heute morgen um 9.50 kippte das IPv4 auf dem Notbook wieder weg, Habe dann Wifi kurz aus und an geschaltet und dann klappte es wieder.

D. h. es war nur das IPv4 am wlan-Interface weg und die wifi-Verbindung per IPv6 zum Wlan-Router hat weiter problemlos funktioniert?

lubux schrieb:

gnude schrieb:

ich habe mal feste IP Adressen vergeben und heute morgen um 9.50 kippte das IPv4 auf dem Notbook wieder weg, Habe dann Wifi kurz aus und an geschaltet und dann klappte es wieder.

D. h. es war nur das IPv4 am wlan-Interface weg und die wifi-Verbindung per IPv6 zum Wlan-Router hat weiter problemlos funktioniert?

So wie ich es beurteilen kann ja. Aber IPv6 geht ja immer....

gnude schrieb:

So wie ich es beurteilen kann ja. Aber IPv6 geht ja immer....

OK, dann muss man suchen/schauen, warum dein Notebook auch bei einer festen IPv4-Adresse, so plötzlich auf das IPv4 verzichtet.

Versuch mal temporär mit einem statischen arp-cache-Eintrag für den Router (gateway) und einem cronjob mit einem arping alle 2 Minuten auf den Router:

sudo apt install iputils-arping
sudo dpkg --configure -a

sudo arp -i wlp3s0 -d <IPv4-Adresse-WLAN-Router>   # siehe "arp -a"
sudo arp -i wlp3s0 -s <IPv4-Adresse-WLAN-Router> <richtige-MAC-Adresse-WLAN-Router>
arp -a

in die /etc/crontab folgende Zeile eintragen und speichern:

*/2 *    * * * root /usr/bin/arping -q -c 3 -w 10 -b -f -I wlp3s0 -s <IPv4-Adresse-wlan-Interface-Notebook> <IPv4-Adresse-Router> > /dev/null 2>&1

Testen auf dem Notebook:

sudo tcpdump -c 20 -vvveni wlp3s0 arp and host <IPv4-Adresse-Router>

Kleiner Nachtrag, bin noch nicht dazu gekommen die Befehle auszuführen. Aber heute war folgendes: Einige Geräte hab ich per feste IP eingehängt. Dann klappt es. Es geht wohl wirklich um den DHCP Part und nicht den DNS Teil.

Mein Smartphone (mit Whatsapp und Threema) kommt per DHCP. Ich war unterwegs, komme wieder und das Wifi Zeichen erscheint. Aber er hat wieder nur ne IPv6 Adresse. Web-Threema auf dem Notebook geht nicht weil er das Smartphone nicht findet. Wenn ich Wifi am Smartphone ausschalte und Mobile Daten nehme geht es. Habe dnsmasq beendet, dann die /var/lib/misc/dnsmasq.leases geleert um zu gucken wer sich anmeldet. Am Smartphone Wifi aktiviert... er bekommt keinen Eintrag in die Leases Datei. Nur IPv6. Dann hab ich Wifi am Smartphone deaktiviert, die Vodafone-Box neu gestartet und das gleiche nochmal. Und zack... bekommt er in der /var/lib/misc/dnsmaq.leases nen Eintrag und ne IPv4 Adresse. Und Web-Threema geht auch wieder. Also muss ich echt die Vodafone-Box neu starten und dann vergibt der DHCP Server wieder die Adressen. Am Server selbst hab ich nichts geändert, nur die Vodafone Box neu gestartet. Hat die nen Arp-Cache der voll läuft? Ich finde interessant das die Abstände zwischen den ZWangs-Neustarts kürzer werden. Wenn ich die jetzt komplett resette und neu einrichte wird sie wieder Wochenlang laufen. Was ändert sich nach einem Reset der Box und Neuinstallation und dem Ausschalten? Warum geht es nach dem Ausschalten nur kurz?

DHCP hat ja eine Lease-Zeit. Wenn diese sehr groß ist kann der Pool an verfügbaren Adressen leer sein. prüfe das. Dann kann die Implementierung ind er Box fehlerhaft sein, sodass z.B. abgelaufene Leases nicht mehr neu vergeben werden, obwohl es erlaubt wäre.

gnude schrieb:

Habe dnsmasq beendet, dann die /var/lib/misc/dnsmasq.leases geleert um zu gucken wer sich anmeldet. Am Smartphone Wifi aktiviert... er bekommt keinen Eintrag in die Leases Datei.

Du sollst ja die lease-Datei bei den Clients löschen und nicht beim dnsmasq. Damit die Clients nicht mehr wissen welche IP-Adresse sie mal hatten und das nehmen was sie vom DHCP-Server bekommen.

DJKUhpisse schrieb:

DHCP hat ja eine Lease-Zeit. Wenn diese sehr groß ist kann der Pool an verfügbaren Adressen leer sein. prüfe das. Dann kann die Implementierung ind er Box fehlerhaft sein, sodass z.B. abgelaufene Leases nicht mehr neu vergeben werden, obwohl es erlaubt wäre.

Die Anzahl der IP Adressen für den Adresspool betragen 100, aber es sind nur 10-15 vergeben. Das kam mir auch in den Sinn aber daran liegt es nicht. Die Box selbst vergibt die DHCP Adressen ja nicht mehr da ich das über dnsmasq auf dem Server machen lasse. Die Bos stellt nur das Wifi zur Verfügung und fungiert als Gateway. Der DHCP und DNS Server ist Ubuntu-Server in der VM mit einer festen IP.

lubux schrieb:

gnude schrieb:

Habe dnsmasq beendet, dann die /var/lib/misc/dnsmasq.leases geleert um zu gucken wer sich anmeldet. Am Smartphone Wifi aktiviert... er bekommt keinen Eintrag in die Leases Datei.

Du sollst ja die lease-Datei bei den Clients löschen und nicht beim dnsmasq. Damit die Clients nicht mehr wissen welche IP-Adresse sie mal hatten und das nehmen was sie vom DHCP-Server bekommen.

Wie kann ich bei einem Android den Lease löschen?

gnude schrieb:

Kleiner Nachtrag, bin noch nicht dazu gekommen die Befehle auszuführen.

BTW: Wann kommst Du dazu, vom Server die Ausgabe von:

sudo tcpdump -c 30 -vvveni any udp port 67

zu zeigen, wenn im Problemfall ein Client vom DHCP-Server eine IPv4-Adresse zugewiesen oder bestätigt haben will und das nicht klappt bzw. nicht funktioniert? Erreicht in dem Fall, der Client den DHCP-Server überhaupt bzw. ist es (warum auch immer) so, dass der DHCP-Server lediglich nicht antwortet (den Client ignoriert)?

EDIT:

https://debianforum.de/forum/viewtopic.php?p=1314529#p1314529