Das Problem, das ich gleich beschreiben werde, sehe ich nur, wenn ich einige Java-Unit-Tests ausführe. Ich bin mir jedoch ziemlich sicher, dass die Ursache an der OS-X-Konfiguration und nicht an Java liegt, daher poste ich an den Superuser und nicht an StackOverflow.
Wir haben einen Java-Unit-Test, der einen eingebetteten Server startet und dann Anfragen an in at stellt http://localhost:9324. Diese Tests waren vor meinem Upgrade auf Yosemite erfolgreich, jetzt schlagen sie fehl. Spezifische Symptome und Dinge, die ich versucht habe:
Auflösen zur AWDL-Schnittstelle
Ich habe mir netstat angesehen, um zu sehen, was Port 9324 belastete. Dabei habe ich Folgendes gefunden:
localhost:platform oliver$ netstat -tn | grep 9324
tcp6 0 0 fe80::b8d2:8eff:.50602 fe80::b8d2:8eff:.9324 SYN_SENT
also aus irgendeinem Grund wurde localhost in eine IPV6-Adresse aufgelöst und ifconfigzeigt, dass es die Adresse von ist awdl0. Ein bisschen googeln zeigt, dass dies die Schnittstelle ist, die Apple für Peer-to-Peer-Sharing verwendet. Beachten Sie nslookup localhost, dass dig localhostund dscacheutil -q host -a name localhostalle 127.0.0.1wie erwartet zurückgegeben werden. Also macht der Java-Code die Namensauflösung irgendwie anders oder so (also ja, vielleicht ist das eine Java-Frage)???
Auflösen in externe Adresse
Durch das Ausschalten der AWDL-Schnittstelle sudo ifconfig awdl0 downblieb der Code nicht mehr hängen und netstat meldete im Wesentlichen korrekt aussehende Informationen:
tcp4 0 0 192.168.0.124.52137 192.168.0.124.9324 SYN_SENT
tcp4 0 0 127.0.0.1.9324 127.0.0.1.52135 ESTABLISHED
tcp4 0 0 127.0.0.1.52135 127.0.0.1.9324 ESTABLISHED
Beachten Sie jedoch, dass aus irgendeinem Grund der lokale Code, der eine localhostAdresse verwendet, trifft 192.168.0.124, meinexternIP-Adresse und dieser Code bleibt SYN_SENThängen und erhält nie eine Antwort. Beachten Sie, dass dies nicht an den Firewall-Einstellungen liegt, da ich die Firewall für diesen Test vollständig deaktiviert habe.
Verbindung abgelehnt
Trotz der seltsamen Verwendung der externen Adresse gibt es Verbindungen, die scheinbar korrekt aussehen und den Loopback verwenden, aber ConnectionRefusedJava-Fehler erhalten. curl http://localhost:9324Die Verbindung wird jedoch erfolgreich hergestellt und es wird eine Antwort erhalten.
Frage
Ich bin ziemlich ratlos. Das könnte ein Java-Problem sein, aber ich vermute, dass mein OS-X-Netzwerk-Setup irgendwie kaputt ist.
Oh, hier ist meine /etc/resolv.conf:
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 10.1.10.1
nameserver 2001:558:feed::1
nameserver 2001:558:feed::2
Meine /private/etc/resolv.conf ist identisch.
/etc/hosts lautet:
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
und hier ist die Ausgabe, wenn ifconfig -a:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=1<PERFORMNUD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 3c:15:c2:da:29:0c
nd6 options=1<PERFORMNUD>
media: autoselect (<unknown type>)
status: inactive
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=60<TSO4,TSO6>
ether 72:00:04:0f:34:70
media: autoselect <full-duplex>
status: inactive
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=60<TSO4,TSO6>
ether 72:00:04:0f:34:71
media: autoselect <full-duplex>
status: inactive
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
ether 0e:15:c2:da:29:0c
media: autoselect
status: inactive
awdl0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> mtu 1452
ether ba:d2:8e:05:03:6c
nd6 options=1<PERFORMNUD>
media: autoselect
status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=63<RXCSUM,TXCSUM,TSO4,TSO6>
ether 3e:15:c2:ad:9e:00
Configuration:
id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
ipfilter disabled flags 0x2
member: en1 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 5 priority 0 path cost 0
member: en2 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 6 priority 0 path cost 0
nd6 options=1<PERFORMNUD>
media: <unknown type>
status: inactive
en5: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=23<RXCSUM,TXCSUM,TSO4>
ether 00:24:9b:0f:3c:02
inet6 fe80::224:9bff:fe0f:3c02%en5 prefixlen 64 scopeid 0xc
inet 192.168.0.50 netmask 0xffffff00 broadcast 192.168.0.255
inet6 2601:1c0:c901:980e:224:9bff:fe0f:3c02 prefixlen 64 autoconf
inet6 2601:1c0:c901:980e:4041:88e9:46e8:a893 prefixlen 64 autoconf temporary
nd6 options=1<PERFORMNUD>
media: autoselect (1000baseT <full-duplex,flow-control,energy-efficient-ethernet>)
status: active
Antwort1
Willkommen in der Welt nach IPv4. Wenn Sie ein Dienstprogramm wie nslookup oder dig verwenden, wird standardmäßig ein „A“-Eintrag zurückgegeben. Moderne Betriebssysteme und Anwendungen mit aktiviertem IPv6 suchen jedoch normalerweise zuerst nach einem „AAAA“-Eintrag, um festzustellen, ob die Ressource über IPv6 verfügbar ist, bevor auf eine IPv4-Ressource zurückgegriffen wird.
Was also passiert ist, dass Sie sowohl einen IPv4-Eintrag als auch einen IPv6-Eintrag haben fürlokaler Hostauf Ihrem System und es wird fast immer IPv6 bevorzugen.
Was können Sie also dagegen tun? Nun, Sie haben mehrere Möglichkeiten. Sie können den IPv6-Eintrag entfernen fürlokaler Hostoder deaktivieren Sie IPv6 vollständig. Dies ist jedoch keine ideale Lösung und bedeutet eher einen „Blick zurück“ als einen Fortschritt.
Stattdessen sollten Sie sicherstellen, dass Ihr Dienst so konfiguriert ist, dass er zusätzlich zu IPv4 auch auf IPv6 ausgeführt wird. Möglicherweise müssen Sie auch einige Anpassungen an Ihren IPv6-Firewallregeln vornehmen, um den Dienst zuzulassen. So sind Sie für die Zukunft gerüstet, wenn IPv6 IPv4 als Mainstream-Protokoll verdrängt.
Antwort2
Versuchen Sie, den Cache zurückzusetzen discoverydoder zu leeren oder zu mDNSResponder (dem DNS-Resolver vor Yosemite) zurückzukehren.
So leeren Sie den discoverydCache:
sudo discoveryutil mdnsflushcache
Die Rückkehr zum mDNSResponder wird hier beschrieben: