Code: Alles auswählen
ping -4 1.2.3.4
Nachtrag:
Sollte so sein, wie oben vermutet. [1] [2] [3]
Code: Alles auswählen
ping -4 1.2.3.4
Code: Alles auswählen
ping: socket: Die Adressfamilie wird von der Protokollfamilie nicht unterstützt
Code: Alles auswählen
socket: Die Operation ist nicht erlaubt
Code: Alles auswählen
# ls -l /bin/ping
-rwxr-xr-x 1 root root 80176 2. Feb 2021 /bin/ping
# /sbin/getcap /bin/ping
Failed to get capabilities of file '/bin/ping' (Operation not supported)
wanne hat geschrieben:Es gibt aber genug, die wie du aus Ideologie oder Sicherheitsgrüden IPv6 möglichst gewaltsam abschalten
Geht's auch weniger unterstellend und beleidigend?wanne hat geschrieben:Volltrottel [...], die zuerst IPv6 verkrüppeln und sich dann über die Folgen wundern
Mein Einwurf bezog sich nur auf dein ursprüngliches Problem zur nicht unterstützten Protokollfamilie, als pragmatische „Lösung“ ohne Ursachensuche. Ich geb zu, die restlichen Beiträge vorhin nur überflogen zu haben.fischig hat geschrieben:06.08.2021 13:21:13Wenn ich die Kommentare hinter JTHs Links verstanden habe, ist das für das Kommando ping auch so gewollt?
Nein, das ping auf einem von zwei möglichen Wegen (setcap, setuid) für unpreviligierte Benutzer extra Rechte bekommt, ist sicher nicht soo neu. Siehe dazu das Ende von wannes letztem Beitrag.fischig hat geschrieben:06.08.2021 13:21:13Beim Benutzer kommt:[…]Code: Alles auswählen
socket: Die Operation ist nicht erlaubt
Frage: ist das neu in bullseye?
Vermutlich fehlt dir auch da in deinem Selbstbaukernel etwas relevantes – obwohl die Capabilities laut man capabilities seit Kernel 2.6.33 ohne extra CONFIG_sowieso immer eingebaut sein sollen. Stecke da aber nicht im Detail drin, klinke mich hier wieder aus.fischig hat geschrieben:06.08.2021 13:21:13(alter Zustand, also Selbstbau-Kern 5.10 ohne ipv6)Code: Alles auswählen
# /sbin/getcap /bin/ping Failed to get capabilities of file '/bin/ping' (Operation not supported)
Das ist nicht beleidigend sondern entspricht einfach den Tatsachen.
Das war ich, weil getcap zwar unter /sbin liegt aber problemlos als normaler User funktionieren sollte.Kleine Frage am Rande, Du schreibst /sbin/getcap. Die getcap Kommandos hast Du als root abgesetzt (und falls ja, mit "su" oder "su-")?
Für mich sieht das nach einem ähnlichen Problem aus wie zuvor. Debian prüft zwar ab, ob libcap2 und Abhängigkeiten vorhanden sind. Rechnet aber natürlich nicht mit einem Kernel, der das nicht kann. – Wie gesagt: Seit 2.6.33 ist das überall drin. Irgend wann verlassen sich die Leute drauf.fischig hat geschrieben:06.08.2021 13:21:13
(alter Zustand, also Selbstbau-Kern 5.10 ohne ipv6)Code: Alles auswählen
# ls -l /bin/ping -rwxr-xr-x 1 root root 80176 2. Feb 2021 /bin/ping # /sbin/getcap /bin/ping Failed to get capabilities of file '/bin/ping' (Operation not supported)
Vermutlich apt-get install linux-image-amd64? – Ich muss natürlich wieder raten, weil du mir noch immer kein uname -a gegeben hast.aber dann sollte mir jemand Tipps geben, wie ich in der gegebenen Situation zu einem bootfähigen Standard-Kern kommen könnte.
Wenn ich doch nochmal mitgrübeln darf: Deinem Kernel fehlen vielleicht erweiterte Dateiattribute: Can't get or set file capabilities.fischig hat geschrieben:06.08.2021 13:21:13(alter Zustand, also Selbstbau-Kern 5.10 ohne ipv6)Code: Alles auswählen
# /sbin/getcap /bin/ping Failed to get capabilities of file '/bin/ping' (Operation not supported)
Sollte das auf der alten Maschine (TP X31) nicht eher linux-image-686 sein?wanne hat geschrieben:Vermutlich apt-get install linux-image-amd64?
Code: Alles auswählen
# uname -a
Linux x31 5.10.26-x31.0 #5.10.26 SMP PREEMPT Sat Mar 27 22:07:33 CET 2021 i686 GNU/Linux
weder noch: direkt als root, eingeloggt auf tty1.eggy hat geschrieben: Du schreibst /sbin/getcap. Die getcap Kommandos hast Du als root abgesetzt (und falls ja, mit "su" oder "su-
Wenn ich das richtig sehe – ich finde die Zusammenhänge mancher CONFIG_* nicht leicht nachzuschlagen – wären hier die CONFIG_<filesystem>_FS_SECURITY und (außer bei ext4) CONFIG_<filesystem>_FS_XATTR notwendig, damit getcap/setcap auf dem jeweiligen Dateisystem funktioniert.
Erst mal vielen herzlichen Dank! Das scheint's gewesen zu sein.JTH hat geschrieben:Wenn ich das richtig sehe [...] wären hier die CONFIG_<filesystem>_FS_SECURITY und (außer bei ext4) CONFIG_<filesystem>_FS_XATTR notwendig
Code: Alles auswählen
# /sbin/getcap /bin/ping
/bin/ping cap_net_raw=ep
Jut.
Da möchte ich dich an ein entsprechendes Forum verweisen Ne, Scherz beiseite:fischig hat geschrieben:06.08.2021 22:53:46Ich habe nur noch eine andere i386-Maschine, aber die ist mit devuan beowulf ~ Debian buster bestückt.
iputils-ping hängt erst seit einer Version nach Buster hart von libcap2-bin ab. Vorher war es nur ein Recommends und ist vielleicht auf deinem einen System daher nicht installiert. In letzterem Fall fällt das iputils-ping-Paket auf setuid zurück. Könntest du mit einem ls -l /bin/ping mal nachgucken. Statt einem x taucht dann ein s in den Dateiberechtigungen auf.fischig hat geschrieben:06.08.2021 22:53:46Erklären, wie's zustande kekommen ist, kann ich mir's nicht.
Code: Alles auswählen
# ls -l /bin/ping
-rwsr-xr-x 1 root root 72096 Jan 14 2020 /bin/ping
Code: Alles auswählen
something went wrong (500)
Tät ich ja glatt zusätzlich.Da möchte ich dich an ein entsprechendes Forum verweisen
Um das nochmal klar zu stellen: Das hat nicht gegen fischig gezielt, der Probleme hat und die Lösen will. Und ich dachte eigentlich, dass der das auch versteht. Ich ärgere mich aber über Entwickler, die ihre selbst produzierten Probleme zu denen anderer erklären.
Für das in der Überschrift ja. Die Fehlermeldung wird bleiben.Für die Problemlösung war es ja wohl irrelevant - richtig?
Am Ende musst du das selber wissen. Am ende macht IPv6 den Kernel wirklich fetter und IPv4 abschalten ist defakto keine Option (Man könnte NAT64 oder ähnliche Konstrukte fahren... Wollen tut man das sicher nicht.). Ich muss selbst zugeben dass ich noch nen AP mit 4.14? Kernel und deaktiviertem IPv6 rum fahren habe, weil ich das anders leider wirklich nicht in die 2MiB-Flash rein bekomme und neue Hardware kaufen ist mir dann doch zu schade...sind wannes diesbezüglichen Überlegungen in der Sache ja nicht von der Hand zu weisen.
Dann hätt'ste mich schon etwas deutlicher separieren müssen.wanne hat geschrieben:Und ich dachte eigentlich, dass der das auch versteht.
Code: Alles auswählen
/sbin/getcap /bin/ping
Code: Alles auswählen
setcap cap_net_raw=ep /bin/ping
Vermutlich fehlt dir auch da in deinem Selbstbaukernel etwas Relevantes – obwohl die Capabilities laut man capabilities seit Kernel 2.6.33 ohne extra CONFIG_sowieso immer eingebaut sein sollen.
Wenn ping jetzt funktioniert wie erwartet, wird es wohl so okay sein. Ansonsten fällt mir direkt kein offensichtlicher Grund ein, warum das manuelle setcap notwendig war. Solange der während des Upgrades laufende Kernel die notwendigen Configs eingebaut hatte, wird das setcap auch beim Paketupgrade von iputils-ping ausgeführt.