Проблема, которую я собираюсь описать, я вижу только тогда, когда запускаю несколько модульных тестов Java. Тем не менее, я уверен, что причина кроется в конфигурации OS-X, а не в Java, поэтому я отправляю сообщения суперпользователю, а не StackOverflow.

У нас есть модульный тест Java, который запускает встроенный сервер, а затем отправляет запросы по адресу http://localhost:9324 . Эти тесты раньше проходили до того, как я перешел на Yosemite, теперь они провалились. Конкретные симптомы и вещи, которые я пробовал:

Разрешение на интерфейс AWDL

Я посмотрел на netstat, чтобы увидеть, что происходит с портом 9324. Нашел это:

localhost:platform oliver$ netstat -tn | grep 9324
tcp6       0      0  fe80::b8d2:8eff:.50602 fe80::b8d2:8eff:.9324  SYN_SENT

поэтому по какой-то причине localhost преобразовывался в адрес IPV6, а ifconfig показывает, что это адрес awdl0 . Небольшой поиск в Google показывает, что это интерфейс, который Apple использует для однорангового обмена. Обратите внимание, что nslookup localhost , dig localhost и dscacheutil -q host -a name localhost all возвращают 127.0.0.1 как и ожидалось. Итак, каким-то образом Java-код выполняет разрешение имен по-другому или что-то в этом роде (так что да, может быть, это вопрос Java)???

Разрешение на внешний адрес

Отключение интерфейса AWDL с помощью sudo ifconfig awdl0 down привело к тому, что код перестал зависать и netstat сообщал в основном правильно выглядящую информацию:

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

но обратите внимание, что по какой-то причине локальный код с использованием адреса localhost достигает 192.168.0.124 , мой внешний IP-адрес и этот код застряли в SYN_SENT и будут зависать и никогда не получат ответ. Обратите внимание, что это не связано с настройками брандмауэра, так как я полностью отключил брандмауэр для этого теста.

В соединении отказано

Несмотря на странное использование внешнего адреса, есть правильно выглядящие соединения, которые, по-видимому, используют зацикливание, но получают ошибки ConnectionRefused от Java. Тем не менее, curl http://localhost:9324 успешно подключается и получает ответ.

Вопрос

Я довольно озадачен. Это может быть проблема с Java, но я подозреваю, что мои настройки OS-X не работают.

О, вот мой /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

Мой /private/etc/resolv.conf идентичен.

/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

и вот вывод, если 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
|источник

2 ответа2

2

Добро пожаловать в мир пост-IPv4. Когда вы используете утилиту, такую как nslookup или dig, по умолчанию возвращается "A" запись. Однако в современных операционных системах и приложениях с поддержкой IPv6 они обычно сначала проверяют наличие записи "AAAA", чтобы узнать, доступен ли ресурс через IPv6, а затем обращаются к ресурсу IPv4.

Итак, в вашей системе есть запись IPv4 и запись IPv6 для localhost , и она почти всегда предпочитает IPv6.

Итак, что вы можете сделать по этому поводу? Ну, у вас есть несколько вариантов. Вы можете удалить запись IPv6 для localhost или полностью отключить IPv6, однако это далеко не идеальное решение, которое скорее "смотрит назад", чем движется вперед.

Вместо этого вам, вероятно, следует убедиться, что ваша служба настроена для работы на IPv6 в дополнение к IPv4. Вам также может потребоваться внести некоторые изменения в правила брандмауэра IPv6, чтобы разрешить службу. Это подготовит вас к будущему, когда IPv6 сместит IPv4 в качестве основного протокола.

|источник
0

Попробуйте сбросить discoveryd , очистить кэш или вернуться к mDNSResponder (преобразователь DNS, предшествующий Yosemite).

Вот как очистить discoveryd кеш:

sudo discoveryutil mdnsflushcache

Возврат к mDNSResponder описан здесь:

Ars Technica OS X обнаружил вернуть

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .