Linux内核-arp协议

Linux内核-arp协议,第1张

从ip_finish_output2到dev_queue_xmit路径:

http://www.bluestep.cc/linux%e5%91%bd%e4%bb%a4arping-%e7%bd%91%e7%bb%9c%e7%ae%a1%e7%90%86-%e9%80%9a%e8%bf%87%e5%8f%91%e9%80%81arp%e5%8d%8f%e8%ae%ae%e6%8a%a5%e6%96%87%e6%b5%8b%e8%af%95%e7%bd%91%e7%bb%9c/

arp协议

(1).硬件类型:

硬件地址类型,该字段值一般为ARPHRD_ETHER,表示以太网。

(2).协议类型:

表示三层地址使用的协议,该字段值一般为ETH_P_IP,表示IP协议

(3)硬件地址长度,以太网MAC地址就是6;

(4)协议地址长度,IP地址就是4;

(5) *** 作码

常见的有四种,arp请求,arp相应,rarp请求,rarp相应。

(6)发送方硬件地址与IP地址,(7)目标硬件地址与目标IP地址。

arp头数据结构:

arp模块的初始化函数为arp_init(),这个函数在ipv4协议栈的初始化函数inet_init()中被调用。

1.初始化arp表arp_tbl

2.注册arp协议类型;

3.建立arp相关proc文件,/proc/net/arp;

4.注册通知事件

一个neigh_table对应一种邻居协议,IPv4就是arp协议。用来存储于邻居协议相关的参数、功能函数、邻居项散列表等。

一个neighbour对应一个邻居项,就是一个arp条目

邻居项函数指针表,实现三层和二层的dev_queue_xmit()之间的跳转。

用来存储统计信息,一个结构实例对应一个网络设备上的一种邻居协议。

注册arp报文类型 :dev_add_pack(&arp_packet_type)

就是把arp_packet_type添加到ptype_base哈希表中。

注册新通知事件的时候,在已经注册和UP的设备上,会调用一次这个通知事件。

设备事件类型:

创建一个邻居项,并将其添加到散列表上,返回指向该邻居项的指针。

tbl:待创建的邻居项所属的邻居表,即arp_tbl;

pkey:三层协议地址(IP地址)

dev:输出设备

want_ref:??

创建邻居项

1.设置邻居项的类型

2.设置邻居项的ops指针

3.设置邻居项的output函数指针

调用dst_link_failure()函数向三层报告错误,当邻居项缓存中还有未发送的报文,而该邻居却无法访问时被调用。不懂。

用来发送arp请求,在邻居项状态定时器处理函数中被调用。

neigh:arp请求的目的邻居项

skb:缓存在该邻居项中的待发送报文,用来获取该skb的源ip地址。

将得到的硬件源、目的地址,IP源、目的地址等作为参数,调用arp_send()函数创建一个arp报文并将其输出。

创建及发送arp报文

创建arp报文,填充字段。

发送arp报文

用来从二层接收并处理一个arp报文。这个函数中就是做了一些参数检查,然后调用arp_process()函数。

neigh_event_ns

neigh_update

这个函数的作用就是更新邻居项硬件地址和状态。分支比较多。

neigh_update_notify

代理arp(proxy arp),通常像路由器这样的设备才使用,用来代替处于另一个网段的主机回答本网段主机的arp请求。

感觉代码ARP好像没啥用呀。

网络主机发包的一般过程:

1.当目的IP和自己在同一网段时,直接arp请求该目的IP的MAC。

2.当目的IP和自己不再同一网段时,arp请求默认网关的MAC。

https://www.cnblogs.com/taitai139/p/12336554.html

https://www.cnblogs.com/Widesky/p/10489514.html

当主机没有默认网关的时候,arp请求别的网段的报文,到达路由器后,本来路由器是要隔离广播的,把这个arp请求报文给丢弃,这样就没法通信了。当路由器开启arp proxy后,路由器发现请求的目的IP在其他网段,就自己给主机回复一个arp响应报文,这样源主机就把路由器的MAC当成目的IP主机对应的MAC,可以通信了。这样可能会造成主机arp表中,多个IP地址都对应于路由器的同一个MAC地址。

可以使用arping命令发送指定IP的arp请求报文。

写完了发现这个老妹写的arp代理文章蛮好的,不过她好像是转载的。

分析/验证对比常见局域网服务发现协议在Windows/Linux/Mac等不同系统下的支持和表现

在使用不同系统的智能硬件时,如常见的树莓派/Openwrt路由器/Debian/Fedora/Windows/Mac等系统是,系统间相互发现以及

网络共享本应是系统的基础服务,无需用户过多参与.不过现实旺旺和理想之间的差距让我们惊讶,不同系统相互之间的发现以及

共享并没有那么轻松.

开发的硬件设备无法在常见系统的网络邻居正确的现实出来,实在是很丧气的事情.

那么,就系统来看看局域网服务发现协议在不同系统上的支持及表现.

想要访问局域网网络里面的设备,远没有应有的轻松. 每次新装系统或者设备入网,总是有这样或者那样的问题,哎,我的服务器啊,你在哪里.

先看看最简单和常用的ping工具,这么简单和实用的工具,简单的搜索竟然有 三千八百万 条记录

大名鼎鼎的树莓派,用起来想来应该更简单一些,可事实往往触目惊心,仅仅是ping通的问题,也有 三百万 的记录

![pdnas-raspberry-pi-ping]]( https://upload-images.jianshu.io/upload_images/14465021-53d02e74e1936079.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240 )

再来看看最常见的文件共享服务,也有 两千万 之巨

这都2120年了,为什么这么常见的服务还有这么多为问题呢.

干货放前面 各系统网络邻居正常工作的协议汇总:

Linux和Macos比较相似,但是实现起来还是有明显的差异,下文会具体描述.

Windows一如既往的走在自己的路上,网络邻居发现协议自搞一套.

Web Services Dynamic Discovery (WS-Discovery) WS-Discovery

下图是此协议的抓包

此协议和UPnP极其相似,都是基于SSDP协议衍生的XML表达的,如果不支持此协议,则无法在Windows10 的网络邻居里面显示为PC,无法直接点击访问共享.

支持此协议后,Windows10的网络邻居里面会在计算机类型的里面显示设备.

UPnP 是早期路由器常用的协议,目前从不同系统的验证来看,仅有Windows默认在文件浏览器里面支持,Ubuntu和MacOS都需要单独配置或者应用程序才能浏览.

这个协议目前各种路由器基本都能支持,不过其安全问题频出,作用并不明显.

此协议在Windows系列里面基本都能支持,会在网络邻居里面显示出设备的信息.

MAC整体表现和Linux比较接近,双方使用的协议也是类似,只是在细节处理上有些区别.

mDNS 协议本身应用比较广泛,MAC比较早就支持.在Mac新版本里面,网络邻居默认可以发现mDNS设备.

因为历史原因,早期的AFP协议升级后已经没有开源协议可以完美支持,因此使用avahi的mDNS服务时,如果还使能了AFP业务的话,MAC会显示为大问号.

使用配置好的服务文件,MAC可以正常显示设备

在调试过程中,还看到了网络邻居显示为PC的图标,有知道显示为这个图标的条件的小伙伴吗?

Server Message Block SMB 是MS家

的协议,奇怪吧:<>

Samba是*nix系统上的一个SMB协议的实现,是早期为了和Windows兼容文件共享而做的功能.目前MAC已经全面放弃自己的AFP协议转而投向SMB协议.

设备仅支持SMB协议而没有mDSN协议辅助的话,MAC也可以识别此系统,不过会显示为超级古老的图标.

Ubuntu系统的网络邻居可以自动发现mDNS服务并展示为不同的图标. 在Ubuntu 20.04里面,除去图标的不同,还增加了每个服务的描述.

同样的,Ubuntu系统天然支持SMB协议,但是SMB协议需要mDNS协议的支撑,否则无法显示在网络邻居里面.

除去前面流行并且工作的协议外,还有一些曾经使用但是已经废弃或者即将废弃的协议,在设备设计时,如果考虑兼容性,也同时需要支持.

SSDP是一个基础协议,UPnP以及WS-Discovery 都是基于这个协议来实现的.

Apple Filing Protocol AFP

Apple家的私有协议,开源有 netatalk 实现. AFP升级加密后,netatalk也不能和新版本的MAC兼容.

苹果已经全面投向SMB的怀抱,AFP基本上可以忽略了.

Network Basic Input/Output System NetBIOS 这个是Windows 9x/Me/XP等早期系统支持的名称解析协议,

类似于mDNS,新的Windows 10已经不建议支持此协议.

Link-Local Multicast Name Resolution LLMNR , 这个也是和mDNS竞争的失败者,主要聚焦于局域网的名称解析,可以直接忽略了.


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/7266721.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-03
下一篇 2023-04-03

发表评论

登录后才能评论

评论列表(0条)

保存