Anyhow habe ich bei mir bei der FB das Problem dass ich die IPV6 DNS LUA im Adverticement nicht ändern kann. Trage ich was neues ein und klicke Bestätigen erscheint entweder sofort oder nach dem Wechsel auf eine Seite und Wiederaufruf der Änderungsseite die LUA der FB
BTW: Kannst Du PiHole nicht so konfigurieren, dass die ULA der FritzBox ignoriert wird (... oder nur für/bei "fritz.box" berücksichtigt wird), so dass es nicht erforderlich ist, die ULA in deiner FritzBox zu ändern?
Irgendwo muss die ja herkommen....
BTW: Der TE hat in seinem Beitrag #1 u. a. auch geschrieben:
in raspi-config ist keine SSID eingetragen.
OK, ... evtl. hat der TE die SSID schon im Imager eingetragen und das zwischendurch vergessen?
In seinem Wlan-Router hätte der TE aber (auch) nachschauen können, ob eine Wlan-Verbindung zustande gekommen ist.
Leider ist aber bei ausgeschaltetem Adverticement kein ping auf IPV6 Adressen möglich da das IPV6 Default GW ja mit diesem an die Clients gesendet wird.
Auf Linux-Clients an der FB mit aktivem RA, könntest Du versuchen, mit z. B. rdnssd PiHole als v6-DNS-Server zu konfigurieren bzw. zu benutzen:
Description: Daemon zur Ermittlung rekursiver IPv6-DNS-Server
rdnssd konfiguriert automatisch rekursive DNS-Server in IPv6-Netzwerken
unter Verwendung von ICMPv6 Neighbor Discovery (RFC 5006) und kann die
Konfiguration des DNS-Auflösers (/etc/resolv.conf) entsprechend
aktualisieren.
apt show rdnssdWoher soll Trixie wissen womit es sich verbinden soll und woher kommen die Zugangsdaten fürs WLAN?
Wenn man (nur) eine Kabel-Verbindung zwischen dem Lan-Interface und dem Router (DHCP-Server) herstellt bzw. herstellen will, sollte Trixie schon wissen, dass _nur_ dem Lan-Interface eine IP-Adresse (per DHCP) zugewiesen werden muss.
Eine WLAN-Verbindung ist absichtlich nicht konfiguriert, d. h. es gibt in Trixie keine Konfig-Datei (auch nicht über den Imager) die Zugangsdaten fürs WLAN enthalten könnte.
BTW: Ein richtiger Erkenntnisgewinn wäre, hier zu zeigen, wie das wlan0-Interface ohne WLAN-Verbindung (d. h. nur via LAN-Interface), zusätzlich zum LAN-Interface per DHCP zugewiesen bekommen hat.
Gibt es denn im Netz keine Seite, die nur per IPv6 erreichbar ist?
Z. B.:
ipv6.ident.me
loopsofzen.ukScheint so als bräuchte ich dazu ein Plugin im FF.
Warum? Man kann doch in fast jedem Browser, direkt konfigurieren welche DNS-Server (oder gleichwertig) benutzt werden sollen.
Man könnte mit dem Browser auch einen dnsleak-Test machen, um zu sehen, zu welchen DNS-Server welcher Zugang (IPv4 und IPv6) benutzt wird. Und mit tcpdump (oder gleichwertig) kann man dann sehen/sniffen, ob der Browser eine IPv4- oder eine IPv6-Verbindung (nach der erfolgten Namensauflösung) zur entsprechenden Homepage herstellt.
Was passiert wenn Du in deinem Browser nur die IPv4-Adresse deines PiHole konfigurierst (für DNS) und der Browser, Namensauflösung für AAAA- und A-Record benötigt und auch via PiHole (IPv4) machen kann? Stellt der Browser dann eine IPv6-Verbindung her?
Nur wenn ein A Record abgefragt wird geht das über pi-hole und unbound. Oder habe ich da was falsch verstanden
Welche Verbindung (IPv4 oder/und IPv6) benutzt wird, sollte unabhängig vom abgefragten Record sein.
Dafür gibt es ja auch die jeweiligen Optionen -4 bzw -6 bei den Tools wie z.B. bei route, dig et al. Soweit ich mich erinnere bezog sich die Reihenfolge von AAAA und dann A Record Suche auf den Browser sowie andere Tools, nicht auf die dns query tools.
Ich habe ja absichtlich diese Optionen nicht benutzt (... und "per default" geschrieben). Was macht das jeweilige Tool, wenn man ihm nicht explizit sagt, dass es eine IPv4- oder eine IPv6-Verbindung benutzen soll?
Die aktuellen Browser (& Co.) sind so programmiert/konzipiert, dass sie IPv6 bevorzugen, was ja auch richtig bzw. OK ist. Die Koexistenz von IPv4 und IPv6 wird so schnell nicht vorbei sein, aber sie ist und bleibt temporär.
Meinst Du AAAA statt IPV6 und A statt IPV4? ... oder Zugriff via "-6" vor dem Zugriff via "-4" (... wegen den "happy eyeballs")?
Was ein dns query liefert, ist vom Tool bzw. der Anwendung das/die die Anfrage macht, abhängig. Z. B. per default von dig und host:
:~$ dig heise.de +short @1.1.1.1
193.99.144.80vs.
:~$ host heise.de 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
heise.de has address 193.99.144.80
heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
heise.de mail is handled by 30 mx03.hornetsecurity.com.
heise.de mail is handled by 20 mx02.hornetsecurity.com.
heise.de mail is handled by 10 mx01.hornetsecurity.com.
heise.de mail is handled by 40 mx04.hornetsecurity.com.EDIT:
BTW: Funktioniert jetzt:
ping6 -c 3 2a02:2e0:3fe:1001:302::
# und
mtr -6nr -c 1 2a02:2e0:3fe:1001:302::?
EDIT 2:
Ob btw. default route (v6-gateway) für IPv6 gesetzt/konfiguriert ist, kann man z. B. auch mit:
ip -6 r g 2a02:2e0:3fe:1001:302::anzeigen lassen.
Jetzt frage ich mich ob das eigentlich notwendig ist oder es auch ausreicht IPV4 bei pi-hole und unbound zu nutzen.
Ja, Zugang nur via IPv4 zum PiHole ist ausreichend. Damit kann jede erforderliche Namensauflösung (... die im Zuge der Koexistenz von IPv4 und/mit IPv6 benötigt wird) gemacht werden. Z. B.:
dig -4 aaaa heise.de +short @<IP-Adresse-PiHole> # oder gleichwertigJa, nur dass im Beitrag #2 mit arpscan, (noch) nicht das Tool sondern der Vorgang (Scannen mit dem arp-Protokoll) gemeint war. Der Rest der Diskussion war dann so, dass der TE sich nicht die Mühe gemacht hat, "arp-scan" richtig zu benutzen:
arp-scan und liefert für arp-scan --interface=wlan0 ...
nicht zu gebrauchen, ...
EDIT:
Alternative tools:
:~# netdiscover -i eth0 -P -c 2 -r 192.168.178.0/24 | awk '/Hosts/ { print $5,$6,$7 }'
4 Hosts found.:~# nmap -e eth0 -PR -sn 192.168.178.0/24 | awk '/hosts/ { print $6,$7,$8 }'
(4 hosts up)... solltet ihr lieber erklären warum es nicht funktioniert wenn das Kabel gesteckt wird.
Das ist im Beitrag #16 (siehe oben) schon gemacht worden. Z. B.:
Wenn Du das Kabel steckst, bekommt das eth0-Interface eine IP-Adresse (... und leider auch eine default route und das auch noch mit besserer metric) zugewiesen. Das liegt an deiner fehlerhaften Konfiguration.
¹) Kann man an dem Bild "kein Kabel gesteckt" sehen, hier steht beim Interface die IP und der Status "DOWN", ...
Ich kann auf dem Bild "ohne Kabel", beim eth0-Interface, die IP-Adresse nicht sehen.
BTW: Wenn ich eine feste IP-Adresse konfiguriere, wird diese IP-Adresse auch ohne gestecktes Kabel (mit "ip a") immer gesehen bzw. gezeigt, denn ich benutze immer die Optionen:
ConfigureWithoutCarrier=true
IgnoreCarrierLoss=yes
RequiredForOnline=noGebe ich statt dessen "https://drucker.lan" ein funktioniert es. Warum geht dies nur über HTTPS?
Ist nur der Port 443 oder auch der Port 80 erreichbar?
nc -zv drucker.lan 80
nc -zv drucker.lan 443... in den einstellungen als manuelle/feste IP eingestellt ist (siehe Bild)
...
Aber ich dachte, man bekäme hier evtl. Hilfestellung bei der Fehlerbehebung.
Ich kenne bzw. benutze raspi-config (wenn es das ist) nicht.
Ich benutze nur systemd-networkd (in Linux) und dort wo systemd-networkd (warum auch immer) nicht funktioniert, benutze ich Scripte mit ip & Co.
Alternative mit fping:
:~$ fping -aq -r 1 -g 192.168.178.0/24 2>/dev/null | wc -l
5EDIT:
Vom Ergebnis (hier 5) muss 1 abgezogen werden (für die benutzung im Script), weil fping auch die eigene IP-Adresse pingt.
LAN: 192.168.0.XXX -> feste IP, kein DHCP im Netz
Das stimmt lt. deinen Ausgaben, nicht. Ohne Kabel hat das LAN-Interface (eth0) keine IP-Adresse.
Wenn Du das Kabel steckst, bekommt das eth0-Interface eine IP-Adresse (... und leider auch eine default route und das auch noch mit besserer metric) zugewiesen. Das liegt an deiner fehlerhaften Konfiguration.
Hat jemand was brauchbares?
Hier ein Beispiel:
:~# arp-scan -q -P 4 -I eth0 192.168.178.0/24 | grep -i responded | awk {'print $12,$13'}
4 responded:~# arp-scan -q -P 4 -I eth0 192.168.179.0/24 | grep -i responded | awk {'print $12,$13'}
1 responded:~# arp-scan -q -P 4 -I eth0 192.168.174.0/24 | grep -i responded | awk {'print $12,$13'}
0 respondedBTW:
:~ % pkg search scan
arp-scan-1.10.0 ARP scanning and fingerprinting tool
arpscan-0.5_1 Simple arp scanner