Как администратор, меня ужасно беспокоит, когда у меня лично возникают проблемы с сетью, которые я не могу объяснить / расшифровать - возможно, вы, ребята, можете пролить немного света.
Запустив MacBook Air с новейшим воплощением Mac OS X (Mavericks), я иногда сталкиваюсь с проблемами в общественных точках доступа WiFi. По сути, я подключаюсь к определенной точке доступа Wi-Fi, но на самом деле соединение не получается - через него не проходит IP-трафик. Вот что я собрал до сих пор:
В нерабочем случае моя таблица маршрутизации выглядит так:
Shu:~ blitz$ netstat -nr
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
169.254 link#4 UCS 0 0 en0
192.168.182 link#4 UC 0 0 en0
192.168.182 link#4 UCSI 2 0 en0
192.168.182.1 20:4e:7f:8b:36:81 UHLWIir 1 208 en0 992
192.168.182.240 127.0.0.1 UHS 0 0 lo0
192.168.182.255 ff:ff:ff:ff:ff:ff UHLWbI 0 1 en0
Internet6:
Destination Gateway Flags Netif Expire
::1 ::1 UHL lo0
fe80::%lo0/64 fe80::1%lo0 UcI lo0
fe80::1%lo0 link#1 UHLI lo0
fe80::%en0/64 link#4 UCI en0
fe80::1%en0 50:7e:5d:95:45:2 UHLWI en0
fe80::1240:f3ff:fe81:df32%en0 10:40:f3:81:df:32 UHLI lo0
fe80::26ab:81ff:feb9:1b0%en0 24:ab:81:b9:1:b0 UHLWI en0
fe80::5a55:caff:fe53:96e6%en0 58:55:ca:53:96:e6 UHLWI en0
fe80::5e96:9dff:fe70:108a%en0 5c:96:9d:70:10:8a UHLWI en0
ff01::%lo0/32 ::1 UmCI lo0
ff01::%en0/32 link#4 UmCI en0
ff02::%lo0/32 ::1 UmCI lo0
ff02::%en0/32 link#4 UmCI en0
Пинг к локальному маршрутизатору (192.168.182.1) приводит к этому выводу:
shu:~ blitz$ ping 192.168.182.1
PING 192.168.182.1 (192.168.182.1): 56 data bytes
64 bytes from 192.168.182.1: icmp_seq=0 ttl=64 time=3.026 ms
64 bytes from 192.168.182.1: icmp_seq=0 ttl=64 time=3.323 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=1 ttl=64 time=3.147 ms
64 bytes from 192.168.182.1: icmp_seq=1 ttl=64 time=3.227 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=2 ttl=64 time=3.085 ms
64 bytes from 192.168.182.1: icmp_seq=2 ttl=64 time=3.975 ms (DUP!)
И соответствующий tcpdump во время пинга показывает это:
Shu:~ blitz$ sudo tcpdump
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Packet Tap), capture size 65535 bytes
12:59:19.180358 IP 192.168.182.240 > 192.168.182.1: ICMP echo request, id 30483, seq 223, length 64
12:59:19.183449 IP 192.168.182.1 > 192.168.182.240: ICMP echo reply, id 30483, seq 223, length 64
12:59:19.183530 IP 192.168.182.1 > 192.168.182.240: ICMP echo reply, id 30483, seq 223, length 64
12:59:20.181503 IP 192.168.182.240 > 192.168.182.1: ICMP echo request, id 30483, seq 224, length 64
12:59:20.184755 IP 192.168.182.1 > 192.168.182.240: ICMP echo reply, id 30483, seq 224, length 64
12:59:20.184758 IP 192.168.182.1 > 192.168.182.240: ICMP echo reply, id 30483, seq 224, length 64
Теперь, когда соединение работает (что иногда происходит или с другими WiFis), я вижу следующую таблицу маршрутизации:
shu:~ blitz$ netstat -nr
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.1 UGSc 33 5 en0
169.254 link#4 UCS 0 0 en0
192.168.1 link#4 UCS 2 0 en0
192.168.1.1 84:7a:88:66:c5:79 UHLWIir 34 66 en0 1170
192.168.1.150 127.0.0.1 UHS 1 25 lo0
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 0 16 en0
Я предполагаю, что это дублированная строка 192.168.182 в первом netstat - но, во-первых, как она туда попадает, во-вторых, что она делает на самом деле, и в-третьих, как мне от нее избавиться (кроме перезагрузки, которая просто сырая :))