Mac OS X 某些热点问题

Mac OS X 某些热点问题

作为一名管理员,当我个人遇到无法解释/破译的网络问题时,我会感到非常烦恼——也许你们可以提供一些启示。

使用装有最新版本 Mac OS X (Mavericks) 的 MacBook Air 时,我有时会遇到公共 WiFi 热点问题。基本上,我连接到某个 WiFi 热点,但实际上没有连接 - 没有 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

对本地路由器进行 ping 操作(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!)

ping 过程中相应的 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

现在,当连接正常时(有时可以正常连接,或者与其他 WiFi 连接时也可以正常连接),我会看到以下路由表:

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

我猜测它是第一个 netstat 中的重复192.168.182行 - 但首先,它是怎么到那里的,其次它到底是做什么的,第三我该如何摆脱它(除了重新启动,这很粗鲁:))

相关内容