[结论]
当协议失效的时候,skb会挂载arp的neigt的一个链表上,然后直接返回了,相当于数据包发下了,当arp收到数据包去修复neigh的目的地址的时候,会把之前所有的neihe中等待的skb全部都往下刷到网卡队列中去;
当协议没生效的时候,skb会直接刷到网卡的队列中去;
-----------
网卡多ｉｐ
为什么一张网卡要多个ｉｐ，测试？
当我把自己的机器的地址设置成192.168.199.1时，发现主机上不了网了，那这个时候我的手机应该也上不了网才对！但是我的手机竟然上得了，这个时候是怎么完成的呢？这在网络端是做了什么优化吗这是？
我把自己的电脑假装成网关，这应该就能抓到所有的包才对吧，但是并没有！手机上网依然顺溜，
ｗｉｆｉ协议是上来的时候，我是怎么发现网关的地址
【电脑上来是怎么联网的？】
网关地址如果不配置的话，那么就是默认的这个网段然后最后加１，默认的网关地址，如果一上来连ｉｐ地址都没有，怎么确定自己的ｉｐ地址呢？这就是ｄｈｃｐ协议吗？
ａｒｐ协议貌似是个附属的协议，是一个在局域网中执行的协议，ａｒｐ协议应该是作用在ｉｐ层的协议
ａｒｐ是地址解析协议，这个地址是解析ｍａｃ地址
arp协议是在哪里触发，在组包组到哪个程度的时候会出发呀？ｔｃｐ->ip->在ip层话会查找ip地址,然后填充mac地址,在ip层的时候会查找路由,然后发出ARP[我们个,我们能抓到所有的网络包吗?]
最关键的函数是arp_send,这
[root@buildroot ~]# dmesg | grep -A 50 arp [ 8.351259] arp_send------------ [ 8.351842] ffff88007fc03678 [ 8.352272] ffffffff8171154f ffff88007c981af0 0000000000000000 [ 8.354623] ffff88007c1c0200 ffff88007fc036f8 ffffffff81711edf ffff88007c981af0 [ 8.355168] 0000000000000000 0000000000000000 ffffffff8117c4ce ffffffff816744b4 [ 8.355168] Call Trace: [ 8.355168] <IRQ> [ 8.355168] [<ffffffff8171154f>] arp_send_dst.part.2+0x4f/0x80 [ 8.355168] [<ffffffff81711edf>] arp_solicit+0xff/0x280 [ 8.355168] [<ffffffff8117c4ce>] ? kmem_cache_alloc+0x17e/0x1c0 [ 8.355168] [<ffffffff816744b4>] ? skb_clone+0x54/0xa0 [ 8.355168] [<ffffffff81673abe>] ? __skb_clone+0x2e/0x130 [ 8.355168] [<ffffffff816934b2>] neigh_probe+0x42/0x60 所以这里是个同步的过程 [ 8.355168] [<ffffffff8169610a>] __neigh_event_send+0x19a/0x230 [ 8.355168] [<ffffffff81696de2>] neigh_resolve_output+0x122/0x1b0 ------> 就是在这里把arp包给发送出去了v
dst_neigh_output [ 8.355168] [<ffffffff816e1aa7>] ip_finish_output2+0x1a7/0x300 [ 8.355168] [<ffffffff816e347f>] ip_finish_output+0x12f/0x1e0 [ 8.355168] [<ffffffff816e3f0e>] ip_output+0xae/0xc0 [ 8.355168] [<ffffffff816e3350>] ? ip_fragment.constprop.5+0x80/0x80 [ 8.355168] [<ffffffff816e36b5>] ip_local_out+0x35/0x40 [ 8.355168] [<ffffffff816e3808>] ip_build_and_send_pkt+0x148/0x1c0 [ 8.355168] [<ffffffff817036ea>] tcp_v4_send_synack+0x5a/0xa0 [ 8.355168] [<ffffffff816e99e8>] ? inet_csk_reqsk_queue_hash_add+0x78/0xa0 [ 8.355168] [<ffffffff816f4210>] tcp_conn_request+0x8b0/0x9a0 [ 8.355168] [<ffffffff816ccc85>] ? tcp_packet+0xac5/0x11c0 [ 8.355168] [<ffffffff81702bf3>] tcp_v4_conn_request+0x53/0x60 [ 8.355168] [<ffffffff816f8af4>] tcp_rcv_state_process+0x194/0xd60 [ 8.355168] [<ffffffff81318d7b>] ? security_sock_rcv_skb+0x3b/0x50 [ 8.355168] [<ffffffff81701254>] tcp_v4_do_rcv+0x64/0x210 [ 8.355168] [<ffffffff81704485>] tcp_v4_rcv+0xc15/0xcd0 [ 8.355168] [<ffffffff816de11f>] ip_local_deliver_finish+0x6f/0x1a0 [ 8.355168] [<ffffffff816de7b5>] ip_local_deliver+0xc5/0xd0 [ 8.355168] [<ffffffff816de0b0>] ? inet_del_offload+0x40/0x40 [ 8.355168] [<ffffffff816de3eb>] ip_rcv_finish+0x19b/0x350 [ 8.355168] [<ffffffff816dea8e>] ip_rcv+0x2ce/0x370 [ 8.355168] [<ffffffff816de250>] ? ip_local_deliver_finish+0x1a0/0x1a0 [ 8.355168] [<ffffffff816851ea>] __netif_receive_skb_core+0x34a/0xa20 [ 8.355168] [<ffffffff817095b8>] ? tcp4_gro_receive+0x118/0x1c0 [ 8.355168] [<ffffffff81718dc7>] ? inet_gro_receive+0x1f7/0x250 [ 8.355168] [<ffffffff81687bcd>] __netif_receive_skb+0x1d/0x60 [ 8.355168] [<ffffffff81687c3d>] netif_receive_skb_internal+0x2d/0x90 [ 8.355168] [<ffffffff81688882>] napi_gro_receive+0xd2/0x120 [ 8.355168] [<ffffffff81533081>] e1000_clean_rx_irq+0x191/0x510 [ 8.355168] [<ffffffff81531e80>] e1000_clean+0x250/0x890 [ 8.355168] [<ffffffff8168998a>] net_rx_action+0x1fa/0x340 [ 8.355168] [<ffffffff81880a99>] __do_softirq+0x89/0x294 [ 8.355168] [<ffffffff81058fc0>] irq_exit+0xb0/0xc0 [ 8.355168] [<ffffffff81880854>] do_IRQ+0x54/0xd0 [ 8.355168] [<ffffffff8187ee7f>] common_interrupt+0x7f/0x7f
在arp表项失效的当下,这个时候如果发来一个数据包,数据包此时是没有目的地址的,那么这个时候是把数据包给丢掉呢?还是等arp表都回来了再发送,也就是说是个同步的操作.
第一次会返回,但是紧接着第二次就会回来,打印出来栈看一下数据是从哪里来的,是收到了arp的数据,是收到了, 收到了一个arp数据包, 然后这个数据包会导致
910 [ 10.269541] [<ffffffff8169628f>] neigh_resolve_output+0x7f/0x260 911 [ 10.269541] [<ffffffff81696a43>] neigh_update+0x5d3/0x700 neigh_update直接调用了neigh_resolve_output 912 [ 10.269541] [<ffffffff817118bf>] arp_process+0x1ef/0x6c0 913 [ 10.269541] [<ffffffff816de1e0>] ? inet_del_offload+0x40/0x40 914 [ 10.269541] [<ffffffff816de51b>] ? ip_rcv_finish+0x19b/0x350 915 [ 10.269541] [<ffffffff81711f00>] arp_rcv+0x150/0x180 916 [ 10.269541] [<ffffffff816de380>] ? ip_local_deliver_finish+0x1a0/0x1a0 917 [ 10.269541] [<ffffffff816851ea>] __netif_receive_skb_core+0x34a/0xa20 918 [ 10.269541] [<ffffffff817096e8>] ? tcp4_gro_receive+0x118/0x1c0 919 [ 10.269541] [<ffffffff81718f17>] ? inet_gro_receive+0x1f7/0x250 920 [ 10.269541] [<ffffffff81687bcd>] __netif_receive_skb+0x1d/0x60 921 [ 10.269541] [<ffffffff81687c3d>] netif_receive_skb_internal+0x2d/0x90 922 [ 10.269541] [<ffffffff81688882>] napi_gro_receive+0xd2/0x120 923 [ 10.269541] [<ffffffff81533081>] e1000_clean_rx_irq+0x191/0x510 924 [ 10.269541] [<ffffffff81531e80>] e1000_clean+0x250/0x890 925 [ 10.269541] [<ffffffff81083881>] ? cpu_load_update+0xe1/0x150 926 [ 10.269541] [<ffffffff8168998a>] net_rx_action+0x1fa/0x340 927 [ 10.269541] [<ffffffff81880c59>] __do_softirq+0x89/0x294 928 [ 10.269541] [<ffffffff81058fc0>] irq_exit+0xb0/0xc0 929 [ 10.269541] [<ffffffff81880a14>] do_IRQ+0x54/0xd0 930 [ 10.269541] [<ffffffff8187f03f>] common_interrupt+0x7f/0x7f