-=Kernel-Error=-

IT-Blog von Sebastian van de Meer

Schlagwort: IPv6 (Seite 3 von 4)

Ping6 funktioniert nicht auf fe80-Adresse: Fehlerbehebung

15. November 2013 / / Keine Kommentare

Ja, die liebe fe80 Adressen! Wer schon mal ganz unbedarft folgendes in seine Konsole hämmert:

$ ping6 fe80::20c:42ff:fe72:2ba6
connect: Invalid argument

Wundert sich sicher im ersten Moment über die freche Antwort: „connect: Invalid argument“. ABER das ist absolut richtig. Denn wenn man mehrere Netzwerkkarten in seinem Rechner verbastelt hat, dann hat man ebenfalls mehrere fe80 link local Adressen. Nämlich mindestens eine pro Netzwerkkarte. Damit sollte es jetzt schon klingeln, hm? Noch nicht? Na woher soll das Paket den bitte wissen über welche der Netzwerkkarten es denn den Weg zur angepingten Adresse nehmen soll?!?!? Genau überhaupt nicht! Daher muss das Interface welches als „Ausgang“ genutzt werden soll immer mit angegeben werden.

$ ping6 fe80::20c:42ff:fe72:2ba6%eth0
PING fe80::20c:42ff:fe72:2ba6%eth0(fe80::20c:42ff:fe72:2ba6) 56 data bytes
64 bytes from fe80::20c:42ff:fe72:2ba6: icmp_seq=1 ttl=64 time=0.323 ms
--- fe80::20c:42ff:fe72:2ba6%eth0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.323/0.323/0.323/0.000 ms

Unter Linux gibt man einfach %NIC-Name an und unter Windows einfach %NIC-ID:

C:\>ping -6 fe80::20c:42ff:fe72:2ba6%3

Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6%3 mit 32 Bytes Daten:
Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms
Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms

Ping-Statistik für fe80::20c:42ff:fe72:2ba6%3:
Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\>

Wobei ich die Meldung eines Microsoft Windows doch schnell etwas verwirrend finde. Denn hier gibt es nur die Rückmeldung dass das Zielnetz nicht erreichbar ist. Was ja im Grunde korrekt ist, nur grenzt es leider den Fehler nicht so schön ein!

C:\>ping -6 fe80::20c:42ff:fe72:2ba6

Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6 mit 32 Bytes Daten:

Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.

Ping-Statistik für fe80::20c:42ff:fe72:2ba6:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),

C:\>

Japp, so einfach kann es sein.

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

IPv6 ICMP Redirect erklärt: „rt6_redirect: source isn’t a valid nexthop“

24. Oktober 2013 / / Keine Kommentare

Man stolpert irgendwann über diese Meldung im Kernel-Log:

rt6_redirect: source isn't a valid nexthop for redirect target
Illustration eines IPv6-Netzwerks mit Kernel-Logmeldung „rt6_redirect: source isn't a valid nexthop for redirect target“. Ein ICMPv6-Redirect verweist fälschlich von einer Link-Local-Adresse auf eine globale IPv6-Adresse als Next Hop, was vom System abgelehnt wird.

Gerne im Zusammenhang mit IPv6, gerne dann, wenn man glaubt, eigentlich alles richtig gemacht zu haben. Routing stimmt. Neighbors sehen gut aus. Und trotzdem meckert der Kernel.

Die Kurzfassung: Der Linux-Kernel hat ein ICMPv6 Redirect bekommen und lehnt es ab, weil der vorgeschlagene Next Hop aus seiner Sicht kein gültiger First Hop ist.

Worum geht es überhaupt?

ICMPv6 Redirects (Typ 137) sind Teil von Neighbor Discovery. Ein Router sagt damit zu einem Host sinngemäß:

„Für dieses Ziel gibt es einen besseren ersten Hop als mich.“

Wichtig: erster Hop. Nicht irgendein Router irgendwo, sondern ein direkt erreichbarer Nachbar auf dem Link.

Ein Redirect enthält deshalb zwei zentrale Informationen:

  • das Target (Zieladresse, für die das Redirect gilt)
  • den Better Next Hop

Und jetzt kommt der Teil, den viele Implementierungen (und Admins) gerne unterschätzen:
Der Host muss diesem Vorschlag nicht glauben.

Was Linux hier tatsächlich prüft

Linux ist bei Redirects ziemlich streng. Zu Recht. Redirects sind ein beliebtes Einfallstor für Unsinn und Angriffe.

Bevor der Kernel ein Redirect akzeptiert, prüft er u. a.:

  • stammt das Redirect von einem Router, den ich bereits als Router kenne?
  • liegt der vorgeschlagene Next Hop auf demselben Link?
  • ist dieser Next Hop als Neighbor bekannt bzw. grundsätzlich auflösbar?
  • passt das Ganze zur bestehenden Routing-Entscheidung?

Und genau hier schlägt diese Logmeldung zu.

Der Kernel schaut auf den Better Next Hop im Redirect und stellt fest:

„Diese Adresse kann für dieses Ziel kein gültiger Next Hop sein.“

Dann wird das Redirect verworfen. Keine neue Route. Kein Update. Nur diese Meldung.

Der Klassiker: Global statt Link-Local

In der Praxis sieht man das oft in Setups, in denen Router ihre Default-Route oder interne Routen nicht sauber über Link-Local-Adressen aufbauen.

Beispiel (vereinfacht):

default via 2001:db8:1::1 dev eth0

Sieht harmlos aus. Funktioniert auch meistens. Aber:
IPv6 erwartet, dass Router auf einem Link über ihre Link-Local-Adresse angesprochen werden.

Korrekt wäre also eher:

default via fe80::1 dev eth0

Was passiert nun?

Der Router verschickt ein Redirect und trägt als „Better Next Hop“ seine globale Adresse ein (z. B. 2001:db8:1::1).
Der Host bekommt das Redirect, prüft es – und sagt:

„Moment. Dieser Next Hop ist kein gültiger direkt erreichbarer Neighbor für dieses Ziel.“

Und genau dann landet diese Meldung im Log.

Wichtig:
Das Problem ist nicht primär, dass die Adresse global ist.
Das Problem ist, dass der Kernel den vorgeschlagenen Next Hop nicht als legitimen First Hop auf diesem Link akzeptiert.

Link-Local ist der Normalfall. Alles andere muss extrem gut begründet sein – und ist es fast nie.

Ein Blick auf die Nachbartabelle hilft

Wenn man wissen will, warum der Kernel das Redirect ablehnt, lohnt sich ein Blick in die Neighbor-Daten:

ip -6 neigh show

Oder gezielter:

ip -6 route get 2001:db8:dead:beef::1

Wenn der vorgeschlagene Next Hop dort nicht als sinnvoller Neighbor auftaucht, ist die Sache im Prinzip entschieden.
Kein Neighbor → kein gültiger Next Hop → Redirect wird verworfen.

Warum das kein Bug ist

Die Meldung klingt erstmal nach kaputtem Routing. Ist es aber meistens nicht.

Im Gegenteil:
Der Kernel verhält sich exakt so, wie es das Protokoll vorsieht. Redirects sind Hinweise, keine Befehle. Und Linux nimmt diese Hinweise nur an, wenn sie sauber in das bestehende Neighbor- und Routing-Modell passen.

Das schützt unter anderem vor:

  • falschen Router-Konfigurationen
  • kaputten RA-Setups
  • Bridge-/VM-Konstrukten mit „kreativem“ IPv6
  • trivialen Redirect-Spoofing-Angriffen

Fazit

Die Meldung

rt6_redirect: source isn't a valid nexthop for redirect target

bedeutet nicht „IPv6 kaputt“.
Sie bedeutet: Ein Router hat ein Redirect geschickt, das aus Sicht des Hosts keinen gültigen Next Hop beschreibt.

In der Praxis ist das fast immer ein Hinweis auf:

  • Default- oder interne Routen ohne Link-Local-Next-Hop (siehe auch IPv6 ULA und Adresspriorisierung)
  • Router, die globale Adressen in Redirects verwenden
  • Setups, in denen Neighbor Discovery und Routing nicht sauber zusammenpassen

Oder anders gesagt:
Der Kernel ist hier nicht pingelig. Er ist vorsichtig. Und das ist gut so.

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

IPv6 Prefix Delegation: FritzBox und MikroTik

27. Juli 2013 / / Keine Kommentare

Prefix Delegation per DHCPv6 ist nichts Neues. Dass eine FritzBox das bietet, war mir aber neu. Vielleicht unterschätze ich das Teil?

Ich bekomme ein /48 zugeteilt, die FritzBox bietet die — nicht weiter konfigurierbare — Möglichkeit, ein /62 per Prefix Delegation an einen weiteren Router im Netzwerk weiterzugeben.

Ich habe also meinen MikroTik über den DHCPv6-Client mit einem Prefix füttern lassen. Der MikroTik arbeitet als Hotspot und Trenner fürs WLAN. Nun schiebt dieser das per Prefix Delegation zugewiesene /64 auch ins WLAN durch.

Damit ist im WLAN über die FritzBox und den MikroTik auch IPv6 angekommen. An der FritzBox lässt sich kaum etwas hinsichtlich Netzwerk konfigurieren — ist halt alles zielgruppengerecht. Aber hier hat mich die Kiste von AVM überrascht.

Fragen? Einfach melden.

IPv6 – Neighbor Discovery – Openindiana – Solaris 11 – Opensolaris

17. Februar 2013 / / Keine Kommentare

Veraltet: Dieser Beitrag bezieht sich auf IPv6 Neighbor Discovery unter Solaris/OpenIndiana. Das Konzept (NDP statt ARP) gilt weiterhin, die gezeigten Befehle sind aber Solaris-spezifisch. Unter Linux: ip -6 neigh show.

Damit IPv4 im Ethernet funktioniert braucht man das ARP (Address Resolution Protocol) als Unterbau. Denn sonst würden die IPv4 Pakete ja ihren Weg nicht zur richtigen Netzwerkkarte finden. ARP und IPv4 sind dabei völlig unabhängige Protokolle, sie arbeiten nur seit Jahrzenhten Hand in Hand. Das vergessen viele schnell.

Möchte man also nun herausfinden welche MAC Adresse das System (im gleichen Ethernet-Netzwerk) hat, mit welchem man sich gerade unterhält… Ja, dann bemüht man das ARP.

Unter Linux:

$ arp
Address                  HWtype  HWaddress           Flags Mask            Iface
errorgrab.kernel-error.  ether   00:ff:c9:05:01:c7   C                     enp2s0
wurstsuppe.kernel-error. ether   50:ff:5d:85:73:48   C                     enp2s0

Unter Openindiana/Solaris 11:

$ arp -a
Net to Media Table: IPv4
Device   IP Address               Mask      Flags      Phys Addr
------ -------------------- --------------- -------- ---------------
rge0   router.kernel-error      255.255.255.255          00:ff:42:72:2b:a6
rge0   192.168.1.31         255.255.255.255          00:ff:b0:ae:0b:eb
rge0   sebastian-solaris.kernel-error 255.255.255.255 SPLA     80:ff:73:4a:38:c7
rge0   all-routers.mcast.net 255.255.255.255 S        01:ff:5e:00:00:02

Bei IPv6 schaut es nun etwas anders aus. Man könnte sagen, hier wurde ARP direkt mit in IPv6 integriert. Es findet sich im Neighbor Discovery wieder. Möchte man hier seine „Nachbarn“ sehen klappt es so:

Unter Linux:

$ ip -6 neigh show
fe80::1 dev enp2s0 lladdr 50:ff:5d:85:73:48 router STALE
fe80::2ff:c9ff:fe05:1c7 dev enp2s0 lladdr 00:ff:c9:05:01:c7 router REACHABLE

Unter Openindiana/Solaris 11:

$ netstat -pf inet6

Net to Media Table: IPv6
 If   Physical Address    Type      State      Destination/Mask
----- -----------------  ------- ------------ ---------------------------
rge0  33:33:ff:00:00:01  other   REACHABLE    ff02::1:ff00:1             
rge0  00:ff:42:72:2b:a6  dynamic REACHABLE    router.kernel-error
rge0  33:33:00:00:00:01  other   REACHABLE    ff02::1                    
rge0  33:33:00:01:00:02  other   REACHABLE    ff02::1:2                  
rge0  33:33:ff:00:00:06  other   REACHABLE    ff02::1:ff00:6             
rge0  33:33:ff:10:98:82  other   REACHABLE    ff02::1:ff10:9882          
rge0  33:33:ff:ad:7a:dd  other   REACHABLE    ff02::1:ffad:7add          
rge0  33:33:ff:00:00:11  other   REACHABLE    ff02::1:ff00:11            
rge0  33:33:00:00:00:16  other   REACHABLE    ff02::16                   
rge0  46:ff:91:30:98:3d  dynamic REACHABLE    2001:7d8:8001:0:ffff:bdb9:6810:9882
rge0  80:ff:73:4a:38:c7  local   REACHABLE    sebastian-solaris.kernel-error
rge0  80:ff:73:4a:38:c7  local   REACHABLE    fe80::ffff:73ff:fe4a:38c7  
rge0  00:ff:42:72:2b:a6  dynamic REACHABLE    fe80::fff:42ff:fe72:2ba6   
rge0  33:33:ff:4a:38:c7  other   REACHABLE    ff02::1:ff4a:38c7

Früher war es mit dem ARP „einfacher“. Zumindest musste man sich nur einen Befehl merken und dann halt die für das jeweilige Betriebsystem nötigen Schalter herausfinden. Mit IPv6 ist es nun mit in die jeweiligen IP-Tools gewandert. Ich halte es für sauberer auch wenn man sich nun nicht mehr mit den Befehlt „arp“ behelfen kann.

BSD und ihre Ableger nutzen „ndp„.
Bei Linux verschwindet alles in den iproute2-Tools mit dem Befehl: „ip“ (ifconfig, route, usw. usw…. alles im Tool ip)
Microsoft wirft alles in „netsh„.
Unixbasierendes hält sich ans gute alte „netstat„.

Also bis dahin…

IPv6 / Default Route / DNS /DHCP

18. Oktober 2012 / / Keine Kommentare
Nun arbeite ich schon seit einigen Jahren, privat wie im Berufsleben, mit IPv6. Was mir bei vielen Schulungen, Einführungen, Netzumstellungen usw… auffällt ist dass es vielen Admins schwer fällt zu verstehen wie der Client nun an seine Netzwerkkonfiguration kommt. Da in der letzten Zeit immer mehr Fragen zu dem Thema bei mir landen (scheinbar müssen viele jetzt noch „auf den letzten Drücker“ IPv6 lernen), versuche ich es hier mal grob aufzuschlüsseln. Im Grunde ist es ganz einfach: –    Bei IPv6 verteilt der DHCPv6 Server keine Default Route, das macht der Router! –    Der DHCPv6 kann DNS Server, NTP-Server usw. verteilen und für eine automatische Eintragung des Clients am DNS Server sorgen. Er kann natürlich auch zusätzliche IPv6 Adressen verteilen. –    Der Router verteilt sein Präfix per RA (Router Advertisment).       o    Der Client kümmert sich um die Generierung einer IP-Adresse.       o    Im RA kann der Client aufgefordert werden einen DHCPv6 Server nach weiteren Informationen zu fragen.       o    Im RA kann ein DNS Server an den Client übergeben werden (RDNSS) Erst einmal ist also für eine vollständige Autokonfiguration des Clients kein DHCPv6 Server mehr nötig. Denn der Client hat immer und direkt eine IPv6 Adresse vom scope link (fe80:….). Diese Adresse hat der Client sobald er einen Netzwerklink hat und wird aus der eigenen MAC-Adresse per EUI (Extended Unique Identifier) erstellt. Nun sendet der Client im einfachsten Fall ein RS (Router Solicitation) an die Multicast Adresse, auf welche ALLE Router hören, ins Netzwerk (ff02::2). Der Router antwortet dann mit einem RA und übermittelt dem Client das IPv6-Präfix. Der Client baut dann aus diesem Präfix und EUI wieder eine Adresse vom scope global. Sowie bei aktivierten Privacy Extensions eine gewürfelte Adresse. Der Client hat nun mindestens zwei IPv6 Adressen bei aktivierten Privacy Extensions sogar bereits drei IPv6 Adressen, sowie eine Default Route über den Router welcher uns den RA verpasst hat. Ist am Router die Option RDNSS gesetzt wird dem Client zum Präfix auch noch ein DNS Server übergeben. Dieses ~verstehen~ leider noch nicht alle Clients. Damit wäre der Client schon in der Lage vollständig am „Internetleben“ teil zu nehmen. Ist am Router das Other Config Flag gesetzt, wird der Client angewiesen einen DHCPv6 Server nach weiteren Einstellungen/Informationen zu fragen. Nun kommt der DHCPv6 Server ins Spiel. Wird dieser vom Client nach weiteren Einstellungen/Informationen gefragt wird er die gewünschten Informationen an den Client übermitteln. Was nicht bedeutet dass der Client damit eine weitere IPv6 Adresse bekommen muss. Es ist auch möglich nur wins, ntp, dns usw.. an die Client zu übermitteln. Der Client muss dazu über einen DHCPv6-Client verfügen. Dieser ist bisher noch nicht bei allen Clientsystemen per Default vorhanden bzw. aktiviert! Natürlich kann man seinen DHCPv6 Server auch so konfigurieren dass er zusätzlich noch eine dritte bzw. vierte (oder mehr) IPv6 Adresse an den Client übermittelt. Damit wäre der DHCPv6-Server zusätzlich in der Lage diese IPv6 Adressen einem DNS Server bekannt zu machen. Wie auch beim Thema NAT bei IPv6 gibt es Vorschläge dem DHCPv6 Server wieder die Option Route zu spendieren, ich denke es ist nicht nötig / sinnvoll… Hier kann man sich streiten! Die Idee bei IPv6 möglichst viel Arbeit auf den Client zu verlagern ergibt meist erst auf den zweiten Blick Sinn. Bei IPv4 war es bisher so dass der Client als erstes ins Netzwerk herumbrüllt ob den ein DHCP Server da ist, dann gab es einen regen Austausch zwischen diesen Systemen und am Ende hatte der Client alle seine Informationen. Denkt man aber nun daran dass im größten IPv4 Netzausbei maximal (24^2)-2 Hostadressen herausspringen und beim IPv6 im kleinsten Netzausbau minimal (64^2)-2 Hostadressen herausspringen… Ja dann ahnt man schon, wenn sich hier ein Router noch ums Popo abwischen kümmern muss, dann ist nicht mehr viel mit Netzwerk. Noch Fragen? Dann fragen….

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

Unser RIPE ist bald wirklich alle: Einblick in die Erschöpfung der IPv4-Adressen

11. September 2012 / / Keine Kommentare

RIPE ist in Sachen IPv4 Adressen nun soweit leer dass sie nun auf ein „erweitertes“ Vergabeverfahren wechseln. Soll bedeuten dass nun ganz super streng (bla bla bla) kontrolliert wird warum und wo die Adresse hingeht und ob die auch wirklich gebraucht wird…..

Wie auch immer! Damit man sich besonders gut anschauen kann was noch übrig ist gibt es von den Jungs selbst eine kleine Grafik (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph).

Dass ich ein großer Freund davon bin, mal endlich mit IPv6 aus dem Arsch zu kommen, muss ich ja keinem mehr erzählen. Wenn ich mir andere Hochrechnungen anschaue (http://www.potaroo.net/tools/ipv4/index.html) dann haben wir aktuelle noch bis zum 24.09.2012 (das ändert sich noch mal) IPv4 Adressen.

Ja ja… IPv4 ist ab dem Tag nicht tot (Dualstack für die nächsten Jahre..) und unsere Provider und Hoster haben auch noch Reserven. Zusätzlich kann man ab dem Moment beginnen seine IPv4 Adressen zu verkaufen *lach*…..  AAAABBBER, warum der ganze Stress? Warum nicht einfach mal mit IPv6 beschäftigen? Nein nein, ich meine wirklich beschäftigen, nicht nur so tun als ob.

Siehe auch: IPv4-Adressen sind aufgebraucht

Fragen? Einfach melden.

Ejabberd Dualstack IPv4 und IPv6

7. Mai 2012 / / Keine Kommentare

Wie so oft führen viele Wege nach Rom. Damit Ejabberd auf der IPv4 und den IPv6 Adressen gleichzeitig lauscht hat sich für mich folgender als gut erwiesen:

In der Konfigurationsdatei: /etc/ejabberd/ejabberd.cfg

Im Abschnitt Listening Ports einfach in die Portkonfiguration inet4 sowie inet6 aufnehmen:

{5222, ejabberd_c2s, [
                        inet4,
                        inet6,
                        {access, c2s},
                        {shaper, c2s_shaper},
                        {max_stanza_size, 65536},
                        %%zlib,
                        starttls, {certfile, "/etc/ejabberd/ejabberd.pem"}
                       ]},

Schon arbeitet Ejabberd mit beiden:

# netstat -an|grep 5222
tcp6       0      0 :::5222                 :::*                    LISTEN     
tcp6       0      0 *:5222                 *:*                    LISTEN    


Ach ja, Ejabberd Version ist gerade: 2.1.5

Fragen? Einfach melden.

Wechsel von Openfire zu Ejabberd

7. Mai 2012 / / Keine Kommentare

Ich betreibe nun schon seit…. Oha…. Seit langem 🙂 einen eigenen Jabber-Server.

Jetzt ist das Teil alles andere als ein großes System mit mehreren tausend Usern. Er wird genutzt von der Familie, ein paar Freunden und Bekannten. Mehr sollte und soll es auch nie werden. Vor knapp zwei Jahren habe ich auf Openfire gesetzt. Openfire bietet eine recht ausgereifte klickibunti Oberfläche. Leider kamen in der letzten Zeit immer mal wieder nervige Bugs hinzu.  

Zum einen ist kein Paket für meine Umgebung dabei. Also muss ich das Ding immer von Hand reinwursten. Dann hat es mich einiges an Überzeugungsarbeit gekostet das Openfire nicht als root laufen will, wer will schon Software als root ausführen? Dann waren da noch ein paar Bugs bezüglich SSL in der Server zu Server Kommunikation und diesen nervigen Dialback errors…..  Nun scheint die aktuelle Version: 3.7.1 sowie auch das nightly build 2011-12-21 ein Problem mit IPv6 und DNS zu haben. So genau bin ich auch jetzt nicht dahinter gekommen.  

Wie auch immer!
Das Kraken – IM Gateway scheint leicht eingeschlafen zu sein, Openfire selbst ist in seiner Weiterentwicklung auch etwas seltsam. Vielleicht hat das Projekt geforkt und ich habe es verpasst? Ist ja auch schon vorgekommen, zuletzt verpasste ich StarOffice zu OpenOffice (peinlich peinlich). Da mir nun drei mal ein Bug bei Openfire so vor das Scheinbein getreten hat, dass keine nutzbare Funktion von Jabber übergeblieben ist (zumindest so wie ich sie mir vorstellen, also mit IPv6 und Verschlüsselung. Habe ich mich dazu entschieden zu Ejabberd zu wechseln.

Ejabberd hat fertige Pakete für meine Umgebung im Repository. Somit kann ich auch auf einfache Sicherheitsupdates hoffen. Transporter für ICQ / MSN… sind selbstverständlich überhaupt kein Problem und da Facebook (Familie ihr wisst schon….) direkt per Jabber erreichbar ist, ist alles gut 🙂

Meine paar Konten habe ich recht schnell aus Openfire und in Ejabberd bekommen. Nun läuft mein Messanger also über Ejabberd.

2012.05.03 13:40:26 org.jivesoftware.openfire.session.LocalOutgoingServerSession - Error authenticating domain with remote server: domain.org
java.lang.NumberFormatException: For input string: "4860:4860::8888"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Integer.parseInt(Integer.java:458)
    at java.lang.Integer.parseInt(Integer.java:499)
    at com.sun.jndi.dns.DnsClient.<init>(DnsClient.java:105)
    at com.sun.jndi.dns.Resolver.<init>(Resolver.java:44)
    at com.sun.jndi.dns.DnsContext.getResolver(DnsContext.java:553)
    at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:413)
    at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:213)
    at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:121)
    at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:109)
    at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:123)
    at org.jivesoftware.openfire.net.DNSUtil.srvLookup(DNSUtil.java:199)
    at org.jivesoftware.openfire.net.DNSUtil.resolveXMPPDomain(DNSUtil.java:131)
    at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSession(LocalOutgoingServerSession.java:269)
    at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain(LocalOutgoingServerSession.java:167)
    at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPacket(OutgoingSessionPromise.java:261)
    at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(OutgoingSessionPromise.java:238)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑