Softap_research_basic_tech

1. OSI网络分层参考模型

  网络协议设计者不应当设计一个单一、巨大的协议来为所有形式的通信规定完整的细节,而应把通信问题划分成多个小问题,然后为每一个小问题设计一个单独的协议。这样做使得每个协议的设计、分析、时限和测试比较容易。协议划分的一个主要原则是确保目标系统有效且效率高。为了提高效率,每个协议只应该注意没有被其他协议处理过的那部分通信问题;为了主协议的实现更加有效,协议之间应该能够共享特定的数据结构;同时这些协议的组合应该能处理所有可能的硬件错误以及其它异常情况。为了保证这些协议工作的协同性,应当将协议设计和开发成完整的、协作的协议系列(即协议族),而不是孤立地开发每个协议。

  在网络历史的早期,国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)共同出版了开放系统互联的七层参考模型。一台计算机操作系统中的网络过程包括从应用请求(在协议栈的顶部)到网络介质(底部) ,OSI参考模型把功能分成七个分立的层次。图2.1表示了OSI分层模型。

  ┌─────┐

  │ 应用层 │←第七层

  ├─────┤

  │ 表示层 │

  ├─────┤

  │ 会话层 │

  ├─────┤

  │ 传输层 │

  ├─────┤

  │ 网络层 │

  ├─────┤

  │数据链路层│

  ├─────┤

  │ 物理层 │←第一层

  └─────┘ 

  OSI七层参考模型

  OSI模型的七层分别进行以下的操作:

  第一层:物理层

  负责最后将信息编码成电流脉冲或其它信号用于网上传输。它由计算机和网络介质之间的实际界面组成,可定义电气信号、符号、线的状态和时钟要求、数据编码和数据传输用的连接器。如最常用的RS-232规范、10BASE-T的曼彻斯特编码以及RJ-45就属于第一层。所有比物理层高的层都通过事先定义好的接口而与它通话。如以太网的附属单元接口(AUI),一个DB-15连接器可被用来连接层一和层二。

  第二层:数据链路层

  通过物理网络链路提供可靠的数据传输。不同的数据链路层定义了不同的网络和协议特征,其中包括物理编址、网络拓扑结构、错误校验、帧序列以及流控。物理编址(相对应的是网络编址)定义了设备在数据链路层的编址方式;网络拓扑结构定义了设备的物理连接方式,如总线拓扑结构和环拓扑结构;错误校验向发生传输错误的上层协议告警;数据帧序列重新整理并传输除序列以外的帧;流控可能延缓数据的传输,以使接收设备不会因为在某一时刻接收到超过其处理能力的信息流而崩溃。数据链路层实际上由两个独立的部分组成,介质存取控制(Media Access Control,MAC)和逻辑链路控制层(Logical Link Control,LLC)。MAC描述在共享介质环境中如何进行站的调度、发生和接收数据。MAC确保信息跨链路的可靠传输,对数据传输进行同步,识别错误和控制数据的流向。一般地讲,MAC只在共享介质环境中才是重要的,只有在共享介质环境中多个节点才能连接到同一传输介质上。IEEE MAC规则定义了地址,以标识数据链路层中的多个设备。逻辑链路控制子层管理单一网络链路上的设备间的通信,IEEE 802.2标准定义了LLC。LLC支持无连接服务和面向连接的服务。在数据链路层的信息帧中定义了许多域。这些域使得多种高层协议可以共享一个物理数据链路。

  第三层:网络层

  负责在源和终点之间建立连接。它一般包括网络寻径,还可能包括流量控制、错误检查等。相同MAC标准的不同网段之间的数据传输一般只涉及到数据链路层,而不同的MAC标准之间的数据传输都涉及到网络层。例如IP路由器工作在网络层,因而可以实现多种网络间的互联。

  第四层:传输层

  向高层提供可靠的端到端的网络数据流服务。传输层的功能一般包括流控、多路传输、虚电路管理及差错校验和恢复。流控管理设备之间的数据传输,确保传输设备不发送比接收设备处理能力大的数据;多路传输使得多个应用程序的数据可以传输到一个物理链路上;虚电路由传输层建立、维护和终止;差错校验包括为检测传输错误而建立的各种不同结构;而差错恢复包括所采取的行动(如请求数据重发),以便解决发生的任何错误。传输控制协议(TCP)是提供可靠数据传输的TCP/IP协议族中的传输层协议。

  第五层:会话层

  建立、管理和终止表示层与实体之间的通信会话。通信会话包括发生在不同网络应用层之间的服务请求和服务应答,这些请求与应答通过会话层的协议实现。它还包括创建检查点,使通信发生中断的时候可以返回到以前的一个状态。

  第六层:表示层

  提供多种功能用于应用层数据编码和转化,以确保以一个系统应用层发送的信息可以被另一个系统应用层识别。表示层的编码和转化模式包括公用数据表示格式、性能转化表示格式、公用数据压缩模式和公用数据加密模式。

  公用数据表示格式就是标准的图像、声音和视频格式。通过使用这些标准格式,不同类型的计算机系统可以相互交换数据;转化模式通过使用不同的文本和数据表示,在系统间交换信息,例如ASCII(American Standard Code for Information Interchange,美国标准信息交换码);标准数据压缩模式确保原始设备上被压缩的数据可以在目标设备上正确的解压;加密模式确保原始设备上加密的数据可以在目标设备上正确地解密。

  表示层协议一般不与特殊的协议栈关联,如QuickTime是Applet计算机的视频和音频的标准,MPEG是ISO的视频压缩与编码标准。常见的图形图像格式PCX、GIF、JPEG是不同的静态图像压缩和编码标准。

  第七层:应用层

  最接近终端用户的OSI层,这就意味着OSI应用层与用户之间是通过应用软件直接相互作用的。注意,应用层并非由计算机上运行的实际应用软件组成,而是由向应用程序提供访问网络资源的API(Application Program Interface,应用程序接口)组成,这类应用软件程序超出了OSI模型的范畴。应用层的功能一般包括标识通信伙伴、定义资源的可用性和同步通信。因为可能丢失通信伙伴,应用层必须为传输数据的应用子程序定义通信伙伴的标识和可用性。定义资源可用性时,应用层为了请求通信而必须判定是否有足够的网络资源。在同步通信中,所有应用程序之间的通信都需要应用层的协同操作。

  OSI的应用层协议包括文件的传输、访问及管理协议(FTAM) ,以及文件虚拟终端协议(VIP)和公用管理系统信息(CMIP)等。

2. TCP/IP分层模型

  TCP/IP分层模型(TCP/IP Layening Model)被称作因特网分层模型(Internet Layering Model)、因特网参考模型(Internet Reference Model)。

  ┌────────┐┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┐

  │        ││D│F│W│F│H│G│T│I│S│U│ │

  │        ││N│I│H│T│T│O│E│R│M│S│其│

  │第四层,应用层 ││S│N│O│P│T│P│L│C│T│E│ │

  │        ││ │G│I│ │P│H│N│ │P│N│ │

  │        ││ │E│S│ │ │E│E│ │ │E│它│

  │        ││ │R│ │ │ │R│T│ │ │T│ │

  └────────┘└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘

  ┌────────┐┌─────────┬───────────┐

  │第三层,传输层 ││   TCP   │    UDP    │

  └────────┘└─────────┴───────────┘

  ┌────────┐┌─────┬────┬──────────┐

  │        ││     │ICMP│          │

  │第二层,网间层 ││     └────┘          │

  │        ││       IP            │

  └────────┘└─────────────────────┘

  ┌────────┐┌─────────┬───────────┐

  │第一层,网络接口││ARP/RARP │    其它     │

  └────────┘└─────────┴───────────┘

       TCP/IP四层参考模型 

  TCP/IP协议被组织成四个概念层,其中有三层对应于ISO参考模型中的相应层。ICP/IP协议族并不包含物理层和数据链路层,因此它不能独立完成整个计算机网络系统的功能,必须与许多其他的协议协同工作。

  TCP/IP分层模型的四个协议层分别完成以下的功能:

  第一层:网络接口层

  包括用于协作IP数据在已有网络介质上传输的协议。实际上TCP/IP标准并不定义与ISO数据链路层和物理层相对应的功能。相反,它定义像地址解析协议(Address Resolution Protocol,ARP)这样的协议,提供TCP/IP协议的数据结构和实际物理硬件之间的接口。

  第二层:网间层

  对应于OSI七层参考模型的网络层。本层包含IP协议、RIP协议(Routing Information Protocol,路由信息协议),负责数据的包装、寻址和路由。同时还包含网间控制报文协议(Internet Control Message Protocol,ICMP)用来提供网络诊断信息。

  第三层:传输层

  对应于OSI七层参考模型的传输层,它提供两种端到端的通信服务。其中TCP协议(Transmission Control Protocol)提供可靠的数据流运输服务,UDP协议(Use Datagram Protocol)提供不可靠的用户数据报服务。

  第四层:应用层

  对应于OSI七层参考模型的应用层和表达层。因特网的应用层协议包括Finger、Whois、FTP(文件传输协议)、Gopher、HTTP(超文本传输协议)、Telent(远程终端协议)、SMTP(简单邮件传送协议)、IRC(因特网中继会话)、NNTP(网络新闻传输协议)等

 

PS:CCNP中写的ARP和RARP都属于网络层,中国网络工程师教程写的ARP属于数据链路层

<think>我们正在处理一个KeyError: 'mPassphrase'错误,该错误出现在softap wifi_softap_test.py文件中。根据错误类型,这通常意味着在字典中尝试访问一个不存在的键。我们需要检查代码中是否有使用'mPassphrase'这个键的地方,并确认该键是否在字典中存在。 根据提供的引用,我们注意到在初始化AP的配置时,使用了结构体`wifi_config_t`,其中`.ap`字段是一个结构体,包含了`ssid`、`password`、`authmode`等字段。在引用[1]和[3]中,我们设置密码时使用的是`password`字段,并没有出现`mPassphrase`。 然而,错误发生在`wifi_softap_test.py`,这是一个Python文件,而引用的代码是C语言。因此,我们需要考虑Python代码中可能使用了不同的键名。 由于没有提供具体的Python代码,我们可以推测:在Python测试脚本中,可能有一个字典用于配置AP,其中应该包含一个键来表示密码,而该键可能被命名为`'mPassphrase'`。但是,在配置字典中可能没有正确设置这个键,或者拼写不一致。 根据错误信息,我们尝试访问字典中键为`'mPassphrase'`的项,但是这个键不存在。可能的原因有: 1. 在创建字典时,键名拼写错误,比如写成了`'passphrase'`、`'mPassphrase'`(注意大小写)等。 2. 在设置字典时,遗漏了`'mPassphrase'`键。 在引用[3]中,C代码中密码的字段名为`password`,但在Python测试脚本中,可能使用了不同的命名约定。 建议检查`wifi_softap_test.py`中创建配置字典的部分,确保存在键`'mPassphrase'`。例如,可能是这样的: ```python config = { 'ssid': 'HelloBug', 'mPassphrase': '12345678', # 确保这里使用的是'mPassphrase',并且后面访问时也是同样的键名 ... } ``` 另外,也要检查访问该字典的代码行,确认是否确实使用了`'mPassphrase'`这个字符串(注意大小写)。 如果没有找到明显的拼写错误,那么可能是测试框架期望的配置字典中包含这个键,但实际测试代码中没有提供。在这种情况下,需要根据测试框架的要求,在字典中添加这个键。 由于我们没有具体的Python代码,只能给出一般性的建议。 **总结步骤:** 1. 打开`wifi_softap_test.py`文件。 2. 查找`KeyError`发生的行(错误信息会提示行号)。 3. 检查该行访问字典的键名是否与定义字典时的键名一致。 4. 如果字典中没有`'mPassphrase'`键,则添加它,并赋予正确的密码值。 5. 如果字典中已有该键,检查拼写(包括大小写)是否完全一致。 如果问题仍然存在,请提供具体的代码片段以便进一步分析。 相关问题: 1. 如何调试Python中的KeyError错误? 2. 在ESP32的WiFi SoftAP配置中,密码字段在C语言和Python测试脚本中分别是什么? 3. 如何确保Python字典键名的一致性以避免KeyError?</think>### KeyError 'mPassphrase' 分析 根据您提供的错误信息和代码引用,`KeyError: 'mPassphrase'` 错误发生在 `softap wifi_softap_test.py` 文件中,这通常表示代码尝试访问字典中不存在的键。结合 ESP-IDF 的 WiFi 配置逻辑,以下是可能的原因和解决方案: --- ### 原因分析 1. **配置字段名称不匹配** 在 ESP-IDF 的 WiFi 配置结构体 `wifi_config_t` 中,AP 模式的密码字段是 `password`(如引用[1][3]所示),而非 `mPassphrase`。 错误可能源于: ```python # 错误示例(Python测试脚本) config = { 'mPassphrase': '12345678' # 错误字段名 } ``` 2. **认证模式不兼容** 当使用 `WIFI_AUTH_OPEN` 模式时(引用[1]),系统不会检查密码字段。若测试脚本在开放模式下仍尝试读取密码字段,可能触发此错误。 3. **测试脚本版本问题** `wifi_softap_test.py` 可能是旧版测试脚本,使用了已弃用的字段名(如 `mPassphrase` 而非标准 `password`)。 --- ### 解决方案 1. **修正字段名称** 将测试脚本中的 `mPassphrase` 统一改为 `password`: ```python # 修改后(Python测试脚本) ap_config = { 'ssid': 'HelloBug', 'password': '12345678', # 正确字段名 'authmode': WIFI_AUTH_WPA2_PSK } ``` 2. **检查认证模式** 确保在开放认证模式(`WIFI_AUTH_OPEN`)下不访问密码字段: ```python if ap_config['authmode'] != WIFI_AUTH_OPEN: pwd = ap_config['password'] # 仅在需要时访问 ``` 3. **更新测试脚本** 检查 ESP-IDF 版本并更新测试脚本: ```bash git submodule update --init components/esp_wifi # 更新WiFi组件 ``` --- ### 关键代码参考 1. C 语言配置结构(引用[1][3]): ```c wifi_config_t wifi_config = { .ap = { .ssid = "HelloBug", .password = "12345678", // 正确字段名 .authmode = WIFI_AUTH_WPA2_PSK } }; ``` 2. Python 测试脚本应保持一致: ```python # 正确示例 self.ap_if.config( ssid='HelloBug', password='12345678', # 使用password而非mPassphrase authmode=network.AUTH_WPA2_PSK ) ``` --- ### 验证步骤 1. 在测试脚本中全局替换 `'mPassphrase'` → `'password'` 2. 运行测试并检查日志: ```bash pytest wifi_softap_test.py -v ``` 3. 确认输出中不再出现 `KeyError` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值