IPV6 unter Sid: "ping: sendmsg: Operation not permitted"

[eggy]

Aus irgendnem komischen Grund mag nen relativ frisch installiertes sid kein ipv6:

Code: Alles auswählen

# ping6 localhost
PING localhost(localhost (::1)) 56 data bytes
ping: sendmsg: Operation not permitted

ip(6)tables sagt, keine Regeln und alle Policies auf ACCEPT, daran liegts also nicht.
ip a sagt ::1 sei an lo gebunden: lo hat inet6 ::1/128 scope host.
Namensauflösung localhost zu ::1 funktioniert ebenfalls.
Der Eintrag aus der /etc/hosts wird genommen. Kommentier ich die v6 Einträge dort aus, geht ein ping auf localhost ganz nomal auf die 127.0.0.1. Netzwerk via v4 ist komplett ok.
Nur ping auf v6 will anscheinend nicht. Ich bin grad etwas ratlos. Wo könnte ich noch suchen?

[mat6937]

Aus irgendnem komischen Grund mag nen relativ frisch installiertes sid kein ipv6:

Code: Alles auswählen

# ping6 localhost
PING localhost(localhost (::1)) 56 data bytes
ping: sendmsg: Operation not permitted

Wie sind die Ausgaben von:

Code: Alles auswählen

which ping6 ping
ls -la $(which ping6)
ping -c 3 localhost

?

[schwedenmann]

Hallo


versuchs mal mit
ping -c3 ip6-localhost


mfg
schwedenmann

[mat6937]

versuchs mal mit
ping -c3 ip6-localhost

BTW: Mit "ping" wird ip6-localhost auf die IPv4-Adresse 127.0.0.1 aufgelöst und mit "ping6" wird ip6-localhost auf die IPv6-Adresse ::1 aufgelöst.

[eggy]

Danke erstmal für die Hilfsversuche.

Namensauflösung funktioniert wie gesagt wunderbar.
localhost löst bei vorhandenem v6-Eintrag in der /etc/hosts auf die ::1 auf, wenn dieser Eintrag nicht vorhanden ist, auf die 127.0.0.1.
Das ist ok so und gewollt und richtig.

ping6 ist hier nen Link auf ping. Falls es ne Rolle spielt (sollte es nicht) es handelt sich um ping aus iputils-ping. Seit 2015 gilt für die lt /usr/share/doc/iputils-ping/NEWS.Debian.gz:

As of 3:20150815-1, the ping and ping6 commands are unified in a single
binary that can communicate with targets of either address family. In
order to force the use of a specific address family, you need to either
pass the argument -4 or -6 on the command line, or call the program via
one of the ping4 or ping6 names.

Eh jetzt Nachfragen kommen: ja, auch mit -6 Flag gibts die genannte Fehlermeldung.

Dass Ping nicht geht, scheint mir auch nur Sympton und nicht Ursache zu sein. Andere Dienste die auf v6 Kommunikation bestehen, lassen sich ebenfalls nicht starten. Würde zum ursprünglichen Verdacht in Richtung iptables passen, da ist aber nichts.

[mat6937]

ping6 ist hier nen Link auf ping.

OK. Wie sind dann die Ausgaben von:

Code: Alles auswählen

ls -la $(which ping)
ping -c 3 localhost

?

EDIT:

Hast Du diese Probleme mit Diensten die auf v6 Kommunikation bestehen, auch sofort nach dem (re)booten?

[eggy]

Reboot hilft auch nicht.

Code: Alles auswählen

# ls -la $(which ping)
-rwxr-xr-x 1 root root 65272 Aug  3  2018 /bin/ping

# ping -c 3 localhost
PING localhost(localhost (::1)) 56 data bytes
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

--- localhost ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 32ms

... wie bereits oben beschrieben: es wird das ping aus iputils-ping benutzt. Ob mit -c3 oder im Endlosmodus spielt keine Rolle.

[KP97]

Auf meinem Sid läuft das.
Ich poste mal die Einträge zum vergleichen:
/etc/hosts

127.0.0.1 MB
127.0.1.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

ping6 localhost

root@MB:/home/MB# ping6 localhost
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.083 ms
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.084 ms
64 bytes from localhost (::1): icmp_seq=4 ttl=64 time=0.084 ms
^C
--- localhost ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 67ms
rtt min/avg/max/mdev = 0.019/0.067/0.084/0.029 ms

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever

Vielleicht hast Du an anderer Stelle ipv6 abgeschaltet und nicht mehr dran gedacht?

[eggy]

Vielleicht hast Du an anderer Stelle ipv6 abgeschaltet und nicht mehr dran gedacht?

Nee, leider nicht.

[mat6937]

Code: Alles auswählen

# ping -c 3 localhost
PING localhost(localhost (::1)) 56 data bytes
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

--- localhost ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 32ms

Warum löst der ping (nicht der ping6) den localhost nicht auf 127.0.0.1 auf? ... sondern auf ::1?

Mit ping auf localhost sollte doch ein v4-Ping gemacht werden. Wie sind die Ausgaben von:

Code: Alles auswählen

ip a
ifconfig lo
cat /etc/hosts

?

[eggy]

Warum löst der ping (nicht der ping6) den localhost nicht auf 127.0.0.1 auf? ... sondern auf ::1?

Mit ping auf localhost sollte doch ein v4-Ping gemacht werden.

Das ist schon ok so, und ich will ja auch ipv6.
Siehe /etc/gai.conf

Es spielt komischerweise aber auch keine Rolle, welche Karte/n ne IPv6 Adresse bekommen hat, und ob die statisch vergeben sind oder automatisch. Alles schon durchgetestet.

Was in der /etc/hosts Datei steht, hat auch keinen negativen Einfluss.
"ping6 ::1" bringt ja ebenfalls die genannte Fehlermeldung. Damit scheiden alle Fehler, die durch ne kaputte Namenauflösung ins Spiel kommen könnten, schonmal aus und damit ist auch /etc/hosts raus.

Was mich wundert: auf nem praktisch baugleichen sid funktioniert alles wie gewünscht. Auch die Einträge von KP97 weichen nicht bedeutend ab. Daher bin ich inzwischen fast soweit das unberechtigterweise auf "random Hardwarebug" zu schieben und die Kiste einfach zu "v4 only" zu erklären.

[mat6937]

Damit scheiden alle Fehler, die durch ne kaputte Namenauflösung ins Spiel kommen könnten, schonmal aus und damit ist auch /etc/hosts raus.

Es geht nicht (nur) um die Namensauflösung, sondern darum, dass ping bzw. ping6 erkennen sollte ob es eine IPv4- oder eine IPv6-Adresse ist. Z. B.:

Code: Alles auswählen

:~ $ ping -c 3 ::1
ping: unknown host ::1

Code: Alles auswählen

:~ $ ping6 -c 3 127.0.0.1
unknown host

[eggy]

Kanns sein, dass Du nen anderes ping hast? Aus inetutils-ping evtl? Oder nicht auf sid?

Auf nem "problemlosen" sid mit ping aus iputils-ping siehts hier so aus:

Code: Alles auswählen

$ ping -c 3 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.060 ms 
[...]

und

Code: Alles auswählen

$ ping6 -c 3 127.0.0.1
ping: 127.0.0.1: Die Adressfamilie für Hostnamen wird nicht unterstützt

Wie gesagt, dass mit der Namensauflösung kannst Du ignorieren, das soll so sein. Das Problem ist nen komplett anderes.

[dufty2]

rumg**gle sagt, könnte evtl. nf_conntrack Limitierung sein, halt mal mittels
# dmesg
Ausschau halten.
Andernfalls mal mit
# strace ping -c 3 ::1
gucken, ob sich was finden lässt.

[mat6937]

..., könnte evtl. nf_conntrack Limitierung sein, ...

Ist das dann auch sofort nach dem booten schon limitiert?

[dufty2]

..., könnte evtl. nf_conntrack Limitierung sein, ...

Ist das dann auch sofort nach dem booten schon limitiert?

Das Limit wird beim Booten gesetzt, vgl. auch
https://www.kernel.org/doc/Documentatio ... sysctl.txt

Auf einem 1 GB-Kistchen:
# cat /proc/sys/net/netfilter/nf_conntrack_max
32768
# sysctl net.netfilter.nf_conntrack_count

Ob er gleich nach dem Booten mit DDoS vollbombadiert wird?
Wer weiss, was auf seiner Kiste vorgeht ...
Deshalb auch der strace-Vorschlag.

[eggy]

Heute nochmal getestet, auch direkt nach dem Boot gehts nicht.

Der Hinweis war aber trotzdem super . Längeres Bootfolgen betrachten hat zu "versuchen wirs doch mal mit nem ganz ganz alten Kernel - irgendwann ging das doch mal" geführt und mit anderen Kerneln tuts komischerweise problemlos (wobei mir aber sicher bin, ich hätte das letzte Woche schon versucht). Falls ich die Tage noch ne Gelegenheit zum Testen bekomme, werd ich mal schauen, ob nen Reinstall vom aktuellen Kernel was bringt. Aber erstmal läuft alles wieder rund und am liebsten würd ich die Kiste auch nicht nochmal anfassen wollen.
Also DANKE nochmal!

[bluestar]

Vielleicht liegt es ja auch an den nftables (https://wiki.debian.org/nftables), das würde zumindest damit d'accord gehen, dass ein älterer Kernel funktioniert, weil dort nft noch nicht vorhanden ist.

[mat6937]

... mit nem ganz ganz alten Kernel - ...

Wie sind mit dem alten und mit dem neuen Kernel, die Ausgaben von:

Code: Alles auswählen

cat /proc/sys/net/netfilter/nf_conntrack_max
sysctl net.netfilter.nf_conntrack_count

?

[eggy]

Kann ich nicht sagen, hab keinen Remotezugriff auf die Kiste.
Daran dürfte es aber nicht liegen, wenn es ne eigene config Änderung gewesen wäre, sollte es sich auch auf andere Kernel ausgewirkt haben. Und dass es kein Problem der Standardconfig des aktuellen Kernels ist, sieht man ja daran, dass die andere Kiste artig ist.
Mein "best guess" zur Zeit: da ist einfach mal nen Bit in den Modulen für v6 im "alten aktuellen" Kernel gekippt aka die Platte hat nen Schuss weg. Allerdings war aus der Richtung auch nichts in den entsprechenden Logs / Monitoring zu sehn. Nuja. Mal abwarten.

[mat6937]

Und dass es kein Problem der Standardconfig des aktuellen Kernels ist, ...

Ja, aber vielleicht ist es ja auch kein Problem der Standardconfig des neuen Kernels. Deshalb wäre m. E. ein Vergleichen dieser Werte interessant.