O problema que estou prestes a descrever só vejo quando executo alguns testes de unidade Java. No entanto, tenho certeza de que a causa é a configuração do OS-X, não do Java, então estou postando para o superusuário e não para o StackOverflow.
Temos um teste de unidade Java que inicia um servidor incorporado e, em seguida, faz solicitações em at http://localhost:9324. Esses testes costumavam passar antes de eu atualizar para o Yosemite, agora eles falham. Sintomas específicos e coisas que tentei:
Resolvendo para interface AWDL
Olhei no netstat para ver o que estava atingindo a porta 9324. Encontrei isto:
localhost:platform oliver$ netstat -tn | grep 9324
tcp6 0 0 fe80::b8d2:8eff:.50602 fe80::b8d2:8eff:.9324 SYN_SENT
então, por algum motivo, o localhost estava resolvendo para um endereço IPV6 e ifconfigmostra que é o endereço de awdl0. Uma pequena pesquisa no Google mostra que essa é a interface que a Apple usa para compartilhamento ponto a ponto. Observe que nslookup localhost, dig localhoste dscacheutil -q host -a name localhosttodos retornam 127.0.0.1conforme o esperado. Então, de alguma forma, o código Java está resolvendo o nome de maneira diferente ou algo assim (então sim, talvez seja uma questão de Java)???
Resolvendo para endereço externo
Desligar a interface AWDL sudo ifconfig awdl0 downfez com que o código parasse de travar e o netstat relatasse informações de aparência basicamente corretas:
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
mas observe que, por algum motivo, o código local usando um localhostendereço está atingindo 192.168.0.124, meuexternoendereço IP e esse código está preso SYN_SENTe irá travar e nunca obter uma resposta. Observe que isso não se deve às configurações do firewall, pois desativei completamente o firewall para este teste.
Ligação recusada
Apesar do uso estranho do endereço externo, existem conexões de aparência correta que parecem usar o loopback, mas recebem ConnectionRefusederros do Java. No entanto, curl http://localhost:9324conecta-se com sucesso e obtém uma resposta.
Pergunta
Estou muito perplexo. Isso pode ser um problema de Java, mas suspeito que minha configuração de rede do OS-X esteja interrompida de alguma forma.
Ah, aqui está meu /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
Meu /private/etc/resolv.conf é idêntico.
/etc/hosts é:
##
# 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
e aqui está a saída if 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
Responder1
Bem-vindo ao mundo pós-IPv4. Quando você usa um utilitário como nslookup ou dig, o padrão é retornar um registro “A”. No entanto, com sistemas operacionais e aplicativos modernos habilitados para IPv6, eles normalmente verificarão primeiro se há um registro "AAAA" para ver se o recurso está disponível em IPv6 antes de recorrer a um recurso IPv4.
Então o que está acontecendo é que você tem uma entrada IPv4 e uma entrada IPv6 parahost localno seu sistema e quase sempre preferirá o IPv6.
Então o que você pode fazer sobre isso? Bem, você tem várias opções. Você pode remover a entrada IPv6 parahost localou desabilitar totalmente o IPv6, no entanto, esta é uma solução nada ideal e, na verdade, está "olhando para trás" em vez de avançar.
Em vez disso, você provavelmente deve certificar-se de que seu serviço esteja configurado para ser executado em IPv6 além de IPv4. Talvez você também precise fazer alguns ajustes nas regras do firewall IPv6 para permitir o serviço. Isso prepara você para o futuro, quando o IPv6 substituir o IPv4 como protocolo principal.
Responder2
Tente redefinir discoverydou liberar seu cache ou reverter para mDNSResponder (o resolvedor de DNS pré-Yosemite).
Veja como liberar o discoverydcache:
sudo discoveryutil mdnsflushcache
A reversão para mDNSResponder é descrita aqui: