ubuntuusers.de

Zeitweise(!) habe ich Probleme mit der Internetverbindung, hatten wir hier ja schon diskutiert. Es könnte ein DNS-Problem sein.

Mir fiel auf, dass der Network-Manager bei den Verbindungsinformationen einen DNS-Server anzeigt, der es eigentlich nicht sein sollte, nämlich die IP-Adresse des AP. Ich verbinde mich zu einem Openwrt-AP, dh ich könnte da was verkonfiguriert oder zu konfigurieren vergessen haben, wenn ja, dann ist es kompliziert und versteckt und Openwrt ist hier nicht Thema.

Aus den Openwrt-Konfigurationen:

grep -r -i dns /etc/config/
/etc/config/dhcp:config dnsmasq
/etc/config/dhcp:	option ednspacket_max '1232'
/etc/config/luci:	option dns 'openwrt.org'
/etc/config/ucitrack:	option init dnsmasq
/etc/config/network:	list dns '192.168.178.1'

Da steht also die Fritzbox bzgl. dns.

Mich würde jetzt interessieren, wie ich abfrage von welchem DHCP-Server die IP-Adresse kommt und wodurch der DNS-Server bestimmt ist. Trage ich im Networkmanager einen zusätzlichen DNS-Server ein, dann steht da nach einem Neustart was anderes als eingegeben drinnen.

Habe ich zB "192.168.18.1,8,8,8,8" eingegeben, dann ist die lokale FB nach dem Neustart weg und nur mehr der Google-Server da. Die Problematik tritt aber nicht regelmäßig auf. Ich setze gerade einige Router mit neuer FW auf und da ist es nicht auszuschließen, dass ich was vergesse, weil es dann ja funktioniert.

glaskugel schrieb:

Mich würde jetzt interessieren, wie ich abfrage von welchem DHCP-Server die IP-Adresse kommt und wodurch der DNS-Server bestimmt ist.

Starte:

sudo dhcpdump -i <richtiges-Interface>

(richtiges-Interface anpassen und ohne spitze Klammern).
und führe danach aus:

sudo nmap -sU -p 67 --script=broadcast-dhcp-discover

Schau dir danach die Ausgaben von dhcpdump und von nmap genau an.
glaskugel schrieb:

Die Problematik tritt aber nicht regelmäßig auf.

Namensauflösung wird ja mittlerweile auch via DoH, via DoT und was weiß ich alles, gemacht und ist teilweise auch durch hardcodierung implementiert.
Du könntest mit einem geeigneten dns-leak-Test (für ipv4 und für ipv6) probieren.

EDIT:

BTW: Wenn der dhcp-Server und das gateway zu diesem dhcp-Server schon bekannt sind, kannst Du mit z. B. dhcping testen/schauen, wie/ob dieser dhcp-Server auf ein DHCPINFORM reagiert und mit welchen Informationen er antwortet:

sudo dhcping -iV -c <IP-Client> -g <IP-gateway> -s <IP-DHCP-Server>

IP-gateway gibt es mit:

ip r g <IP-DHCP-Server>

Trage ich im Networkmanager einen zusätzlichen DNS-Server ein, dann steht da nach einem Neustart was anderes als eingegeben drinnen.

Du musst in dem Fall dem Networkmanager auch sagen, dass er per DHCP nur noch die LAN-IP vom Router holen soll und nicht mehr den DNS.

Also ich weiß jetzt definitiv, dass der neue Openwrt-Router nicht richtig konfiguriert ist.

Interessanterweise gibt es bei mehreren Handys nicht die geringsten Probleme bei diesem AP und das Handy zeigt auch den gewünschten DHCP-Server und DNS-Server, nämlich beide Male die Fritzbox, als eingestellt an. der Ubuntu PC zeigt aber den AP als DHCP-Server und DNS-Server an.

Ich denke verschiedene DNS-Server sind nicht das Problem, letztlich kommt ja doch die FB zum Zug, aber doppelte DHCP-Server ist gar nicht gut. Es sind 3 Router beteiligt, 1xFB, 2xOpenwrt. Bei 1 Openwrt ist DHCP nicht aktiviert. Nur weil am Handy mit dem AP alles problemlos ist, bedeutet es noch lange nicht, dass es richtig konfiguriert ist 😉 Ich ging davon aus, dass bei den Standardwerten in Openwrt DHCP aktiviert werden muss, aber es ist umgekehrt.

Eure Befehle sehe ich mir später an, wenn ich Openwrt besser konfiguriert habe.

Also ich weiß jetzt definitiv, dass der neue Openwrt-Router nicht richtig konfiguriert ist.

Aber auch nur in der Theorie. Es ist ja logisch, dass bei 2 aktivem DHCP-Servern die IP-Adressenvergabe durcheinander kommt. Daher erscheint es ja sinnvoll, den DHCP-Bereich grundsätzlihc außer bei der FB zu deaktivieren. Mache ich das, dann gibt es keine funktionierende Internetverbindung mehr. Aktiviere ich nur bei 1 Bridge DHCP, dann ist nach einiger Zeit Internet möglich.

Handys funktionieren tendenziell viel besser als der Ubuntu PC, Wenn sich ein Handy am WIfi-AP anmeldet, dann sollte doch kein Unterschied sein, wenn sich der Ubunut-PC am Wifi-AP anmeldet, oder? Es gibt 1 Handy-Modell, das kann sich nur an 1 AP anmelden, an allen an allen anderen nicht. Während sich andere Handys überall anmelden können.

$ sudo traceroute 192.168.178.1 # vom Ubuntu PC
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
 1  _gateway (192.168.178.1)  2.270 ms  6.692 ms  7.023 ms

Das hilft mir nicht, theoretisch sollte es so sein:

• 192.168.178.108 Ubuntu PC

• 192.168.178.53 AP, wo sich er Ubuntu PC anmeldet, gibt nur Wifi, keine Ethernetverbindung

• 192.168.178.55 Router, wo sich der Wifi-AP anmeldet

• 192.168.178.1 DSL-Fritzbox, die via Ethernet zum Router verbunden ist.

Das würde ich gerne abfragen.

$ sudo route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    600    0        0 wlp2s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp2s0
192.168.178.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0

Was ist denn 169.254.0.0 ?

Wenn ich vom Ubuntu-PC .108 den AP .53 pinge, dann können das Minuten lang sehr lange Ping Zeiten zeigen und interessanterweise ist der Ping auf den Router .55 ein ganz klein wenig besser.

Also den Weg, den das Signal intern nimmt, wäre schon interessant zu wissen.

1

nmcli d show  <iface>

Beispiel bei mir:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

~$ nmcli d show  enp3s0
GENERAL.DEVICE:                         enp3s0
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         9C:6B:00:12:2C:73
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (verbunden)
GENERAL.CONNECTION:                     Kabelgebundene Verbindung 1
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/1
WIRED-PROPERTIES.CARRIER:               an
IP4.ADDRESS[1]:                         192.168.3.30/24
IP4.GATEWAY:                            192.168.3.1
IP4.ROUTE[1]:                           dst = 192.168.3.0/24, nh = 0.0.0.0, mt = 100
IP4.ROUTE[2]:                           dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.ROUTE[3]:                           dst = 0.0.0.0/0, nh = 192.168.3.1, mt = 100
IP4.DNS[1]:                             8.8.8.8
IP6.ADDRESS[1]:                         fe80::23db:169:xxxx:xxxx/64
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 1024

DNS Server ist bei mir in der Fritzbox auf 8.8.8.8 gesetzt und alle Geräte im Netz nutzen dies.

glaskugel schrieb:

Was ist denn 169.254.0.0 ?

Eine definierte Route in das LL-Subnetz, weil das Interface durch Autokonfiguration, sich eine LL-IP-Adresse aus diesem Subnetz zugewiesen hat. Wenn man das nicht will bzw. so eine LL-IP-Adresse nicht braucht, kann man das durch Konfiguration, verhindern.

glaskugel schrieb:

Wenn ich vom Ubuntu-PC .108 den AP .53 pinge, dann können das Minuten lang sehr lange Ping Zeiten zeigen und interessanterweise ist der Ping auf den Router .55 ein ganz klein wenig besser.

Wie ist auf dem Ubuntu-PC .108, die Ausgabe von:

arp -av

? Wie lange dauert der arping, von .108 auf den AP .53?

Zuerst danke für deine Geduld und, dass du mit der Situation nicht aufgibst.

Das ist aber jetzt gerade ein ausgezeichneter Zustand:

$ sudo arping -c 20 -I wlp2s0 192.168.178.53

ARPING 192.168.178.53 from 192.168.178.136 wlp2s0
Unicast reply from 192.168.178.53 [64:...:80]  2.183ms
Unicast reply from 192.168.178.53 [64:...:80]  1.488ms
Unicast reply from 192.168.178.53 [64:...:80]  1.255ms
Unicast reply from 192.168.178.53 [64:...:80]  1.666ms
Unicast reply from 192.168.178.53 [64:...:80]  3.515ms
Unicast reply from 192.168.178.53 [64:...:80]  1.345ms
Unicast reply from 192.168.178.53 [64:...:80]  1.756ms
Unicast reply from 192.168.178.53 [64:...:80]  6.555ms
Unicast reply from 192.168.178.53 [64:...:80]  5.207ms
Unicast reply from 192.168.178.53 [64:...:80]  1.781ms
Unicast reply from 192.168.178.53 [64:...:80]  2.433ms
Unicast reply from 192.168.178.53 [64:...:80]  1.362ms
Unicast reply from 192.168.178.53 [64:...:80]  1.644ms
Unicast reply from 192.168.178.53 [64:...:80]  1.457ms
Unicast reply from 192.168.178.53 [64:...:80]  1.659ms
Unicast reply from 192.168.178.53 [64:...:80]  1.602ms
Unicast reply from 192.168.178.53 [64:...:80]  1.402ms
Unicast reply from 192.168.178.53 [64:...:80]  3.725ms
Unicast reply from 192.168.178.53 [64:...:80]  2.097ms
Unicast reply from 192.168.178.53 [64:...:80]  1.484ms
Sent 20 probes (1 broadcast(s))
Received 20 response(s)

Während der Ping oben schon recht gut war, findet arp nur einen Teil der vorhandenen Geräte.

$ sudo arp -av
X1860-K1M.lan (192.168.178.53) auf 64:...:80 [ether] auf wlp2s0
? (192.168.178.131) auf 00:...:59 [ether] auf wlp2s0
? (192.168.178.56) auf <unvollständig> auf wlp2s0
? (192.168.178.1) auf 74:...:f7 [ether] auf wlp2s0
Einträge: 4   Ignoriert: 0   Gefunden: 4

Nach langer Zeit kommt 1 Gerät dazu, sind gefühlt um die 20 Geräte, die im Netz sind.

$ sudo arp -av
_gateway (192.168.178.53) auf 64:...:80 [ether] auf wlp2s0
8d2242a3-...-662156dcaf4c.fritz.box (192.168.178.131) auf 00:...:59 [ether] auf wlp2s0
MD89295.fritz.box (192.168.178.30) auf 4c:...:cf [ether] auf wlp2s0
? (192.168.178.56) auf <unvollständig> auf wlp2s0
fritz.box (192.168.178.1) auf 74:...:f7 [ether] auf wlp2s0
Einträge: 5   Ignoriert: 0   Gefunden: 5

192.168.178.56 ist ein Router, der kurz im Netz war, ist wieder weg, dürfte aus dem Cache angezeigt werden.

So jetzt kann ich gerade wieder nicht posten bzw. im Forum browsen, ging ja gerade.

Es fällt auf das .55 nicht gefunden wird, das ist der Router, der mit der FB verbunden wird. Ohne dem fehlt der Weg ins Internet. Also verständlich, dass ich nicht posten kann, nur warum wurde der .55 verloren?

Nach ca. 2 Minuten kann ich posten, nachdem ich die Antwort hier abbrach und neu auf Antworten ging.

glaskugel schrieb:

..., findet arp nur einen Teil der vorhandenen Geräte.

Welche Geräte werden mit arp-scan gefunden:

sudo arp-scan -I wlp2s0 192.168.178.0/24

?

BTW: arp sucht nicht, arp zeigt nur den Inhalt des arp-cache.

$ sudo arp-scan -I wlp2s0 192.168.178.0/24
Interface: wlp2s0, type: EN10MB, MAC: bc:...:ac, IPv4: 192.168.178.136
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.178.53	64:...:80	(Unknown)

ping 192.168.178.1
From 192.168.178.136 icmp_seq=237 Destination Host Unreachable
From 192.168.178.136 icmp_seq=238 Destination Host Unreachable

.136 ist ein AV-Receiver im Standbye.

Kann man irgendwie herausfinden, ob IP-Adressen doppelt vergeben sind. Warum da 136 im Spiel ist, keine Ahnung.

Ergänzung.

In der Fritzbox-Geräteliste ist es etwas chaotisch. Es sind zwar ungenutzte Geräte, aber da gibt es welche ohne IP und wenn man in die Details geht, dann ist da die 136 hinterlegt. Auch mit der .53 ist nicht alles nachvollziehbar. Ich habe hoffentlich die .53 und .136 gelöscht und die FB neu gestartet. Ein spezielles Handy-Modell kann sich aber noch immer nicht verbinden.

Ich habe den AP mit .53 neu geflasht und einen weitern AP mit .52 (gleiches Modell wie 53) konfiguriert. Ganz sauber (schnell) läuft es nach Neustart nicht, aber viel besser als die letzten Stunden. Ich warte beim 1. Mal nur ein paar Sekunden bis die Webseite gezeigt wird und dann ist es normal schnell, dh die Seite sofort da.

glaskugel schrieb:

In der Fritzbox-Geräteliste ist es etwas chaotisch. Es sind zwar ungenutzte Geräte, aber da gibt es welche ohne IP und wenn man in die Details geht, dann ist da die 136 hinterlegt. Auch mit der .53 ist nicht alles nachvollziehbar. Ich habe hoffentlich die .53 und .136 gelöscht und die FB neu gestartet.

Wenn Du die FritzBox bzgl. bekannte/unbekannte/ungenutzte Geräte _richtig_ aufräumen willst und Du weißt was Du tust, dann geht das in dem Du der FritzBox ein anderes Subnetz zuweist, die FritzBox rebootest. Nach dem reboot export- und support-Dateien erstellst und in diesen Text-Dateien, mit der Suchfunktion schaust ob "Ordnung herrscht". Wenn ja, kannst Du danach wieder das Subnetz 192.168.178.0/24 konfigurieren.
Diese Vorgehensweise ist aber nur dann sinnvoll wenn Du eine einzige FritzBox benutzt. Wenn Du in deinem W/LAN noch andere AVM-FritzBoxen (oder gleichwertig) als AP/Repeater/etc. hast, wird es nichts bringen bzw. schwierig sein "aufzuräumen".

glaskugel schrieb:

$ sudo arp-scan -I wlp2s0 192.168.178.0/24
Interface: wlp2s0, type: EN10MB, MAC: bc:...:ac, IPv4: 192.168.178.136
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.178.53	64:...:80	(Unknown)

D.h. 192.168.178.136 ist die IP-Adresse Deines Rechners, wenn WLAN benutzt wird.

ping 192.168.178.1
From 192.168.178.136 icmp_seq=237 Destination Host Unreachable
From 192.168.178.136 icmp_seq=238 Destination Host Unreachable

.136 ist ein AV-Receiver im Standbye.

Wenn das so sein soll, dann ist diese Adresse doppelt vergeben.

Kann man irgendwie herausfinden, ob IP-Adressen doppelt vergeben sind.

Du bist bereits dabei.

Warum da 136 im Spiel ist, keine Ahnung.

Vermutlich hast Du diese Adresse bei einem Gerät lokal manuell vergeben, aber vergessen, sie im zentralen DHCP-Server der Fritzbox zu sperren.

[…] In der Fritzbox-Geräteliste ist es etwas chaotisch.

Vermutlich: Nein. Richtig dagegen: Du hast durch Fehlbedienung Chaos im Netz und siehst in der Fritzbox davon ein unvollständiges Bild.

Räume auf! Dazu:

1. Trenne alle Geräte von ihrer Stromversorgung (d.h. schalte sie aus) bis auf einen Bedienrechner mit einer IP-Adresse (z.B. 169.254.x.y/16) außerhalb des Bereiches des DHCP-Servers in der Fritzbox und die Fritzbox selber. Dazu den Bedienrechner auf „nur link local“ konfigurieren.

2. Lösche in der Fritzbox alle Adresszuweisungen per DHCP.

3. Schalte die Fritzbox aus.

4. Konfiguriere dann den Bedienrechner auf DHCP und nur DHCP und starte ihn neu.

5. Schalte die Fritzbox ein.

6. Kontrolliere, ob der Bedienrechner im Netzwerk richtig funktioniert und in der Fritzbox richtig dargestellt wird.

7. Schalte die anderen Geräte eines nach dem anderen, also einzeln wieder ein und kontrolliere, ab dieses Gerät im Netzwerk richtig funktioniert und in der Fritzbox richtig dargestellt wird. Beginne mit den WLAN-Relaisstationen. Ich kenne keinen guten Grund, für die Geräte im Netz der Fritzbox etwas anderes zu verwenden als DHCP. Natürlich sollte man in der Fritzbox jede erstmalig vergebene Adresse als exklusiv für das jeweilige Gerät markieren und damit fest vergeben.

Wenn das so sein soll, dann ist diese Adresse doppelt vergeben.

Ich muss jetzt mal schauen, wie ich die Geräte in der Fritzbox lösche. Da gibt es seinerseits nicht aktive Geräte, die ich nicht löschen kann und im aktiven Bereich sind 2-3 (schwankend) Geräte, die keine IP haben und auch nicht gelöscht werden können.

Das sind geschätz 50-100 Geräte aus der Familie, die es da gibt. Unmöglich alle gleichzeitig zu deaktivieren. Großes Problem ist, wenn ich da nur eine MAC-Adresse sehe, was das für ein Gerät ist, damit ich dieses ausschalten kann.

Ich habe normalerweise ein Schema für die manuell eingegebenen IP-Adressen, zB die Access-Points und Router sind zwischen .51 und .59. Handys sind nicht fest vorgegeben, sonst funktioniert das nur zu Hause. Aber Handys haben eine IP in der FB eingegeben, das funktioniert normalerweise.

Warum die feste IP-Adresse des AV-Receivers mit der festen IP des PCs durcheinander kommt, ist gar nicht klar. Da müsste die FB doch eine IP nehmen, die per DHCP definiert wird. Aber egal, ich brauche Geduld und muss herausfinden welche Geräte, da aktiv sind, jedenfalls sind das nicht laufend benutzte oder eben welche an die man nicht denkt, weil doppelt vergeben.

Ich habe jetzt über die Mac-Adressne-Suche bei https://www.heise.de/netze/tools/mac/ herausgefunden, da spukt eine Waschmaschine herum, die sollte eigentlich im Gastnetz sein und das PC-Netz überhaupt nicht beeinflussen.

Sieht schon viel besser aus, aber 1 unbekanntes Gerät ohne IPv4-Adresse hält sich hartnäckig. Die Fritzbox zeigt allerdings eine IPv6-Adresse mit der ich nichts anfangen kann.

$ ping -c1 -6 google.com
PING google.com(prg02s12-in-x0e.1e100.net (2a00:1450:4014:80b::200e)) 56 data bytes
64 bytes from prg03s11-in-x0e.1e100.net (2a00:1450:4014:80b::200e): icmp_seq=1 ttl=120 time=41.2 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 41.188/41.188/41.188/0.000 ms

Also grundsätzlich kann ich IPv6 pingen.

$ ping fe80::....:32a0
PING fe80::....:32a0(fe80::....:32a0) 56 data bytes

Die Fritzbox nennt das Gerät PC-52-....-A0, wobei ich das als Mac-Adresse (mit : statt - und ohne PC) nicht finden kann.

Ergänzung:

Nach einem Neustart der FB ist dieses seltsame Gerät weg. Scheint so, dass die FB überhaupt nicht aktuell bei den Geräten ist. WIe früher schon diskutiert ist .53 mit .55 Ohne Kabel verbunden. Internet funktioniert nach ca. 30 Sek. flüssig, aber die FB meint .55 ist nicht aktiv.

Zur Zeit zeigt die FB nur bekannte Geräte an. Einige zwar nicht mit Hostnamen, aber das dauert manchmal einige Zeit / Tage bis der angezeigt wird.

Ich muss jetzt mal beobachten, wie was funktioniert und ob die Geräte weiter in der FB plausibel sind.

Gerade wieder geschaut, jetzt sind 3 Geräte ohne IP da.

Schau dir danach die Ausgaben von dhcpdump und von nmap genau an.

Da verwende ich gerade AP .58, .53 mag zur Zeit gar nicht, Destination Host Unreachable. .58 fällt mir nichts auf, alles flott. Handy sieht sowohl den AP, ein Netzwerkscan am Handy zeigt die .53

$ sudo dhcpdump -i wlp2s0
  TIME: 2023-12-01 04:59:18.080
    IP: 192.168.178.109 (bc:....:ac) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
    OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 469e2129
  SECS: 0
 FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: de:....:fe:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         1 (DHCPDISCOVER)
OPTION:  55 ( 64) Parameter Request List    252 (MSFT - WinSock Proxy Auto Detect)
					      1 (Subnet mask)
					      2 (Time offset)
					      3 (Routers)
					      4 (Time server)
					      5 (Name server)
					      6 (DNS server)
					      7 (Log server)
					      8 (Cookie server)
					      9 (LPR server)
					     10 (Impress server)
					     11 (Resource location server)
					     12 (Host name)
					     13 (Boot file size)
					     14 (Merit dump file)
					     15 (Domainname)
					     16 (Swap server)
					     17 (Root path)
					     18 (Extensions path)
					     19 (IP forwarding)
					     20 (Non-local source routing)
					     21 (Policy filter)
					     22 (Maximum datagram reassembly size)
					     23 (Default IP TTL)
					     24 (Path MTU aging timeout)
					     25 (Path MTU plateau table)
					     26 (Interface MTU)
					     27 (All subnets local)
					     28 (Broadcast address)
					     29 (Perform mask discovery)
					     30 (Mask supplier)
					     31 (Perform router discovery)
					     32 (Router solicitation)
					     33 (Static route)
					     34 (Trailer encapsulation)
					     35 (ARP cache timeout)
					     36 (Ethernet encapsulation)
					     37 (TCP default TTL)
					     38 (TCP keepalive interval)
					     39 (TCP keepalive garbage)
					     40 (NIS domain)
					     41 (NIS servers)
					     42 (NTP servers)
					     43 (Vendor specific info)
					     44 (NetBIOS name server)
					     45 (NetBIOS datagram distribution server)
					     46 (NetBIOS node type)
					     47 (NetBIOS scope)
					     48 (X Window System font server)
					     49 (X Window System display server)
					     50 (Request IP address)
					     51 (IP address leasetime)
					     52 (Option overload)
					     53 (DHCP message type)
					     54 (Server identifier)
					     55 (Parameter Request List)
					     56 (Message)
					     57 (Maximum DHCP message size)
					     58 (T1)
					     59 (T2)
					     60 (Vendor class identifier)
					     61 (Client-identifier)
					     67 (Bootfile name)
					     66 (TFTP server name)
					    
OPTION:  51 (  4) IP address leasetime      1 (1s)
---------------------------------------------------------------------------

  TIME: 2023-12-01 04:59:18.184
    IP: 192.168.178.1 (74:....:f7) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
    OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 469e2129
  SECS: 0
 FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 192.168.178.30
SIADDR: 192.168.178.1
GIADDR: 0.0.0.0
CHADDR: de:....:fe:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         2 (DHCPOFFER)
OPTION:  54 (  4) Server identifier         192.168.178.1
OPTION:  51 (  4) IP address leasetime      864000 (1w3d)
OPTION:  58 (  4) T1                        432000 (5d)
OPTION:  59 (  4) T2                        756000 (1w1d18h)
OPTION:   1 (  4) Subnet mask               255.255.255.0
OPTION:   3 (  4) Routers                   192.168.178.1
OPTION:   6 (  4) DNS server                192.168.178.1
OPTION:  15 (  9) Domainname                fritz.box
OPTION:  26 (  2) Interface MTU             1500
OPTION:  28 (  4) Broadcast address         192.168.178.255
OPTION:  42 (  4) NTP servers               192.168.178.1
---------------------------------------------------------------------------

$ sudo nmap -sU -p 67 --script=broadcast-dhcp-discover
Starting Nmap 7.80 ( https://nmap.org ) at 2023-12-01 04:59 CET
Pre-scan script results:
| broadcast-dhcp-discover: 
|   Response 1 of 1: 
|     IP Offered: 192.168.178.30
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 192.168.178.1
|     IP Address Lease Time: 10d00h00m00s
|     Renewal Time Value: 5d00h00m00s
|     Rebinding Time Value: 8d18h00m00s
|     Subnet Mask: 255.255.255.0
|     Router: 192.168.178.1
|     Domain Name Server: 192.168.178.1
|     Domain Name: fritz.box
|     Interface MTU: 1500
|     Broadcast Address: 192.168.178.255
|_    NTP Servers: 192.168.178.1
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.51 seconds

Ich seh da immer nur die FB.

Ob ich im folgenden immer die richten IP-Adressen verwende, ist mir nicht klar.

$ ip r g 192.168.178.1
192.168.178.1 dev wlp2s0 src 192.168.178.109 uid 1000 
    cache 

$ sudo dhcping -iV -c 192.168.178.109 -g 192.168.178.1 -s 192.168.178.1
setup
inform
packet 247 bytes
01 01 06 00 98 5d 69 65 00 00 00 00 c0 a8 b2 6d 
00 00 00 00 00 00 00 00 c0 a8 b2 01 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63 
35 01 08 37 01 01 ff 
op: 1
htype: 1
hlen: 6
hops: 0
xid: 985d6965
secs: 0
flags: 0
ciaddr: 192.168.178.109
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 192.168.178.1
chaddr: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
sname : .
fname : .
option 53 DHCP message type
	DHCP message type: 8 (DHCPINFORM)
option 55 
no answer
close

Ich bin jetzt gerade über AP .58 angemeldet. Wie frage ich ab, ob ich von dort eine IP-Adresse via DHCP bekommen könnte?

$ ip r g 192.168.178.58
192.168.178.58 dev wlp2s0 src 192.168.178.109 uid 1000 
    cache