求助：ARM设置静态IP后，若MAC地址变动，则无法被电脑ping通
各位大侠，小弟有个问题困扰了几天了。我一批板子，每个ARM都预先把MAC地址烧入了，每个ARM的MAC是顺序增加的，而且惟一的
每个板子生产的时候都预先烧入了kernel和rootfs
rootfs的启动脚本里面已经
ifconfig eth0 up
ifconfig eth0 192.168.1.1
route add default gw 192.168.1.1 了
但用电脑ping板子却ping不通,
若用板子往外ping一下，不管是ping网关，电脑，或者外网，之后
再用电脑ping板子就行了
我有用uboot，若setenv ethaddr 00:00:40:00:00:01 ，这样不停地在一个ARM上面改MAC，新改的MAC有很大机率没法ping通，
让板子往外ping一下，就又OK了，
我在ARM板子上跑了tcpdump，抓了一下包，如下，但我对网络不是太了解，希望有大侠能够帮我一下
我觉得好像是路由器没有登记我的板子的IP和MAC，若是用dhcpc动态的IP就不会有此问题
========================================================================================
板子和电脑接到单独的一个路由器上
板子换新的MAC后，上电，电脑ping板子
root@freescale ~$ tcpdump 电脑ping板子，拼不通
device eth0 entered promiscuous mode
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
00:00:12.943436 IP 192.168.1.100 > 192.168.1.200: icmp 40: echo request seq 1280
00:00:17.845898 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 282
00:00:17.862472 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 300
00:00:17.878450 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 354
00:00:17.895079 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 346
00:00:17.912698 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 276
00:00:17.928575 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 318
00:00:17.945328 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 350
00:00:17.962660 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 296
00:00:17.978406 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 348
00:00:17.995073 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 342
00:00:18.345385 IP 192.168.1.100 > 192.168.1.200: icmp 40: echo request seq 1536
00:00:23.845296 IP 192.168.1.100 > 192.168.1.200: icmp 40: echo request seq 1792
00:00:29.345233 IP 192.168.1.100 > 192.168.1.200: icmp 40: echo request seq 2048
00:00:37.845464 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 282
00:00:37.861242 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 300
00:00:37.877469 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 354
00:00:37.894833 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 346
00:00:37.911313 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 276
00:00:37.927633 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 318
00:00:37.944639 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 350
00:00:37.961327 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 296
00:00:37.977482 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 348
00:00:37.994478 IP 192.168.1.1.1025 > 239.255.255.250.1900: UDP, length: 342
24 packets captureddevice eth0 left promiscuous mode
24 packets received by filter
0 packets dropped by kernel
root@freescale ~$ ping 192.168.1.1 板子ping一下网关，通了，
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=8.233 ms
--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 8.233/8.233/8.233 ms
root@freescale ~$ tcpdump 电脑ping一下板子，也通了
device eth0 entered promiscuous mode
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
00:00:50.611240 IP 192.168.1.100 > 192.168.1.200: icmp 40: echo request seq 2304
00:00:50.620072 arp who-has 192.168.1.100 tell 192.168.1.200
00:00:50.620239 arp reply 192.168.1.100 is-at 20:6a:8a:3d:72:53
00:00:50.620274 IP 192.168.1.200 > 192.168.1.100: icmp 40: echo reply seq 2304
00:00:51.610470 IP 192.168.1.100 > 192.168.1.200: icmp 40: echo request seq 2560
00:00:51.610528 IP 192.168.1.200 > 192.168.1.100: icmp 40: echo reply seq 2560
00:00:52.610549 IP 192.168.1.100 > 192.168.1.200: icmp 40: echo request seq 2816
00:00:52.610575 IP 192.168.1.200 > 192.168.1.100: icmp 40: echo reply seq 2816
00:00:53.610457 IP 192.168.1.100 > 192.168.1.200: icmp 40: echo request seq 3072
00:00:53.610479 IP 192.168.1.200 > 192.168.1.100: icmp 40: echo reply seq 3072
10 packets captureddevice eth0 left promiscuous mode
10 packets received by filter
0 packets dropped by kernel
本文来自：我爱研发网(**) - R&D大本营
详细出处：http://www.**/bbs/dispbbs.asp?boardid=122&id=260621&star=1#893751 大部分系统都会缓存一些MAC地址（ARP缓存），否则每次要把IP转换为MAC地址发送时都查一次，那么网络估计连1Mbps也达不到。
你说的修改之后大部分不通，是因为外部电脑的ARP缓存还没有更新，你用ARM的IP地址访问它时发送的以太网帧DA是原来的MAC地址，ARM不接收它；而偶尔通了是因为ARP缓存超时重新查询了。
至于用ARM先ping一下电脑就通了，就更好理解了，电脑收到ARM的ARP包之后，会更新它的ARP缓存，再访问就可以会使用更新后的正确MAC地址。
注意MAC地址要是合法的，bytes的bit0必须为0。
页:
[1]