CN111586199B - 无线接入设备及其数据处理方法 - Google Patents

Abstract

本公开涉及一种无线接入设备，包括：筛选单元，筛选来自客户设备和DHCP服务器的DHCP报文；解析单元，解析所筛选出的DHCP报文，确定报文DHCP报文类型；以及报文封装单元，在解析单元确定DHCP报文为来自DHCP服务器的要约报文和响应报文并且不包含DNS信息时，通过将所述DHCP服务器要约报文和响应报文中的源信息替换为所述无线接入设备自身的地址信息并增加DNS信息，从而将所述DHCP服务器要约报文重新封装成新的DHCP服务器要约报文和响应报文，以及通过将来自客户设备针对所述新DHCP服务器要约报文的DHCP请求报文中的源信息替换为DHCP服务器的地址信息以及删除DNS信息，从而将所述客户设备DHCP请求报文重新封装成新的客户设备DHCP请求报文。

Description

无线接入设备及其数据处理方法

技术领域

本公开涉及无线通信领域，尤其涉及一种无线接入设备及其数据处理方法。

背景技术

DHCP是Dynamic Host Configuration Protoco的缩写，顾名思义就是动态主机地址配置协议，在一个完整的网络拓扑中应有DHCP客户设备，DHCP服务器两个端点。客户设备存在于用户域中，通过DHCP协议，从服务器获取动态的不固定的IP地址。DHCP服务器通过租约概念负责客户设备提供某一网段或多网段IP地址池中地址。当租约到期客户设备释放该地址以待服务器做再次分配，同时有些服务器也担负分配DNS服务器地址、域名、网关地址的任务，但是有些DHCP服务器并不担负分配DNS服务器地址、域名、网关地址的任务。

DHCP客户设备通过和DHCP服务器的交互通讯以获得IP地址租约。为了从DHCP服务器获得一个IP地址，在标准情况下DHCP客户设备和DHCP服务器之间会进行四次通讯。DHCP协议通讯在服务器端使用端口UDP 67和在客户设备使用端口UDP 68进行通讯，UDP68端口用于客户设备请求，UDP67用于服务器响应，并且大部分DHCP协议通讯使用广播进行。通常DHCP客户设备和DHCP服务器的四次通讯过程依次为DHCP客户设备发起DHCP DISCOVER广播消息、DHCP服务器发起DHCPOFFER广播消息、DHCP客户设备发起DHCPREQUEST广播消息以及DHCP服务器发起DHCPACK广播消息。

但是，在DHCP服务器上没有配置DNS时，那么DHCP OFFER要约报文中不会携带DNS信息。最终导致某些需要校验DNS信息的客户设备无法连接无线网络，例如苹果设备，因为iOS系统会校验DNS，如果要约报文中没有的DNS信息将无法接入网络)，或者导致有些设备无法正常上网，例如一些笔记本或安卓设备能连接到玩过，但是对于很多网站、APP，这些设备都无法正常访问和使用。无论是上面那种情况，都会影响用户网络体验。

对于提供网络接入的接入设备而言，无法要求提供服务的网站、服务器或APP修改其DNS配置，因此，人们希望在接入设备处进行一些改进，以便能够客户设备在任何情况下都能够顺畅接入网络，因此需要一种能够在服务器、网站或APP没有配置DNS信息的情况下也能够顺畅接入这些网络的接入设备。

发明内容

为了解决上述现有技术中的如上问题之一，根据本公开的一个方面，提供了一种无线接入设备，包括：筛选单元，筛选来自客户设备和DHCP服务器的DHCP报文；解析单元，解析所筛选出的DHCP报文，确定报文DHCP报文类型；以及报文封装单元，在解析单元确定DHCP报文为来自DHCP服务器的要约报文或响应报文并且不包含DNS信息时，通过将所述DHCP服务器要约报文和响应报文中的源信息替换为所述无线接入设备自身的地址信息并增加DNS信息，从而将所述DHCP服务器要约报文和响应报文重新封装成新的DHCP服务器要约报文和响应报文，以及通过将来自客户设备针对所述新DHCP服务器要约报文的DHCP请求报文中的目的地地址信息替换为DHCP服务器的地址信息以及删除DNS信息，从而将所述客户设备DHCP请求报文重新封装成新的客户设备DHCP请求报文。

根据本公开的无线接入设备，还包括：存储单元，用于存储缓存表，所述缓存表在解析单元确定DHCP报文为客户设备广播报文时至少记录所述广播报文中的源MAC地址、目的MAC地址以及状态标志；以及更新单元，在解析单元确定DHCP报文为针对所述客户设备广播报文的不包含DNS信息的DHCP服务器要约报文时，将所述DHCP服务器要约报文中的目的地信息在缓存表中对应的客户设备的状态标志修改为代理状态。

根据本公开的无线接入设备，其中所述报文封装单元基于所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文所包含的客户设备地址信息在缓存表中对应的客户设备的代理状态对所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文进行重新封装。

根据本公开的无线接入设备，其中所增加或删除的DNS信息为所述无线接入设备自身的DNS信息。

根据本公开的无线接入设备，其中所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文在被封装为新的DHCP服务器要约报文或响应报文以及原始DHCP回复报文将被丢弃。

根据本公开的另一个方面，提供了一种无线接入设备的数据处理方法，包括：通过筛选单元筛选来自客户设备和DHCP服务器的DHCP报文；通过解析单元解析所筛选出的DHCP报文，确定报文DHCP报文类型；以及由报文封装单元在解析单元确定DHCP报文为来自DHCP服务器的广播报文或响应报文并且不包含DNS信息时，通过将所述DHCP服务器要约报文和响应报文中的源信息替换为所述无线接入设备自身的地址信息并增加DNS信息，从而将所述DHCP服务器要约报文和响应报文重新封装成新的DHCP服务器要约报文和响应报文，以及通过将来自客户设备针对所述新DHCP服务器要约报文的DHCP请求报文中的目的地地址信息替换为DHCP服务器的地址信息以及删除DNS信息，从而将所述客户设备DHCP请求报文重新封装成新的客户设备DHCP请求报文。

根据本公开的无线接入设备的数据处理方法，还包括：在存储单元存储缓存表，所述缓存表在解析单元确定DHCP报文为客户设备广播报文时至少记录所述广播报文中的源MAC地址、目的MAC地址以及状态标志；以及由更新单元在解析单元确定DHCP报文为针对所述客户设备广播报文的不包含DNS信息的DHCP服务器要约报文时，将所述DHCP服务器要约报文中的目的地信息在缓存表中对应的客户设备的状态标志修改为代理状态。

根据本公开的无线接入设备的数据处理方法，其中所述报文封装单元基于所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文所包含的客户设备地址信息在缓存表中对应的客户设备的代理状态对所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文进行重新封装。

根据本公开的无线接入设备的数据处理方法，其中所增加或删除的DNS信息为所述无线接入设备自身的DNS信息。

根据本公开的无线接入设备的数据处理方法，还包括：所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文在被封装为新的DHCP服务器要约报文或响应报文以及原始DHCP回复报文将被丢弃。

综上所述，根据本公开的无线接入设备及其数据处理方法可以在DHCP服务器没有配置DNS的情况下，由无线接入设备自动补全DNS并回复给客户设备，这降低部署无线局域网面临的风险，提升终端用户上网体验。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

为了使本领域技术人员更好地理解本公开，下面结合附图和具体实施方式对本公开作进一步详细说明。

图1所示的是根据本公开无线接入设备示例性框图；

图2示出了根据本公开无线接入设备处理客户设备与无DNS配置信息的DHCP服务器之间建立连接的时序图；以及

图3示出了根据本公开根据本公开无线接入设备的数据处理方法的流程图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

参照附图描述示例性实施方式。在任何方便的地方，在整个附图中使用相同的附图标记来表示相同或相似的部分。虽然本文描述了所公开原理的示例和特征，但是在不脱离所公开实施方式的精神和范围的情况下，修改、适应性改编和其他实现方式是可以的。

阐述了所示出的部件和步骤以说明所示出的示例性实施方式，并且应该预期，正在进行的技术开发将改变执行特定功能的方式。这些示例呈现在本文中用于说明的目的而非限制的目的。此外，为了便于描述，本文中任意限定了功能构建块的边界。可以限定可替选边界，只要适当地执行指定的功能及其关系即可。基于本文中包含的教导，可替选方案(包括本文中描述的那些的等同物、扩展、变型、偏差等)对相关领域的技术人员而言将是明显的。这些可替选方案落入所公开实施方式的范围和精神内。

图1所示的是根据本公开无线接入设备示例性框图。所有的无线接入设备统一标识为100，为了进行区分在同一个接入控制设备(AC)下的不同无线接入设备，依次采用了100-1、100-2…100-N来表示。但是在不进行区分时，统一采用附图标记100来指代。由于所有无线接入设备100-1具有相同的结构，因此，为了表述方便，在提到其他无线接入设备100-1时，可直接参看无线接入设备100-1的示例性框图。同样，所有的DHCP服务器统一标识为400，为了进行区分在与接入控制设备(AC)相连的不同DHCP服务器，依次采用了400-1、400-2…400-N来表示。但是在不进行区分时，统一采用附图标记400来指代。如图1所示，无线接入设备100-1的收发单元110作为一个客户设备200和各种服务器(包括DHCP服务器和其他服务器)之间的一个报文中转结构，接收来自客户设备200和各种服务器的报文并按照目的地地址进行转发。

如图1所示，无线接入设备100-1的收发单元110在接收到任何一个客户设备200报文或服务器400-1的报文时，筛选单元120对所接收到的报文进行筛选。DHCP封包在传输层(Transport Layer)是采用UDP(用户数据报协议)协议，而当客户设备传送给封包给DHCP服务器时，采用的是UDP 67端口，而从DHCP服务器传送封包给客户设备则是使用UDP 68端口。因此通过报文在传输层所使用的端口就可以筛选出DHCP报文。如果筛选单元120通过筛选得知所获得报文不是DHCP报文，则不进行处理，直接由收发单元110对所接收到的报文进行转发到目的地地址。如果筛选单元120通过筛选得知所获得报文是DHCP报文，解析单元130会对DHCP广播报文进行解析，确定DHCP报文的类型。DHCP报文类型基于客户设备200与DHCP服务器400-1之间建立连接的过程，分为客户设备DHCP广播报文、DHCP服务器要约报文、客户设备DHCP请求报文以及DHCP服务器响应报文。这些报文类型都是广播报文。当解析单元130解析确认所接收到的报文为客户设备DHCP广播报文时，那么客户设备DHCP广播报文中的客户设备MAC作为源MAC地址被提取出来并补充到存储单元150的缓存表151中。缓存表151至少包含客户设备200的源MAC地址以及状态信息。可选择地，缓存表151至少包含源MAC地址、DHCP服务器的MAC地址以及状态信息。通常状态信息指的是客户设备200的状态，包括“正常”和“代理”两种状态。解析单元130对于客户设备DHCP广播报文中包含的客户设备200的源MAC地址的状态信息首先设置为“正常”(例如用标记“0”标识)。此时，收发单元110回基于解析单元130的解析结果，直接将客户设备DHCP广播报文转发到目的地地址。

接着DHCP服务器400-1客户设备DHCP广播报文后会回复DHCP服务器要约报文。当DHCP服务器要约报文到达接入设备100-1时，同样被筛选但愿120筛选出来并由接入设备100-1的解析单元130进行解析并检查报文中的可选字段中的DNS字段信息，例如“Option(6)Domain Name Server”字段。

下表1为常规DHCP报文的结构。

在表1中，op，报文类型，1表示请求报文，2表示回应报文。htype，硬件地址类型，1表示10Mb/s的以太网的硬件地址。hlen，硬件地址长度，以太网中该值为6。hops，跳数。客户设备设置为0，也能被一个代理服务器设置。xid，事务ID，由客户设备选择的一个随机数，被服务器和客户设备用来在它们之间交流请求和响应，客户设备用它对请求和应答进行匹配。该ID由客户设备设置并由服务器返回，为32位整数。secs，由客户设备填充，表示从客户设备开始获得IP地址或IP地址续借后所使用了的秒数。flags，标志字段。这个16比特的字段，目前只有最左边的一个比特有用，该位为0，表示单播，为1表示广播。ciaddr，客户设备的IP地址。只有客户设备是Bound、Renew、Rebinding状态，并且能响应ARP请求时，才能被填充。yiaddr，“你自己的”或客户设备的IP地址。siaddr，表明DHCP协议流程的下一个阶段要使用的服务器的IP地址。giaddr，DHCP中继器的IP地址。//注意：不是地址池中定义的网关chaddr，客户设备硬件地址。客户设备必须设置它的"chaddr"字段。UDP数据包中的以太网帧首部也有该字段，但通常通过查看UDP数据包来确定以太网帧首部中的该字段获取该值比较困难或者说不可能，而在UDP协议承载的DHCP报文中设置该字段，用户进程就可以很容易地获取该值。sname，可选的服务器主机名，该字段是空结尾的字符串，由服务器填写。file，启动文件名，是一个空结尾的字符串，在客户设备DHCP广播报文(DHCP Discover报文)中是“generic”名字或空字符，而在DHCP服务器要约报文(DHCP Offer报文)中则会提供有效的目录路径全名。options，可选参数域，格式为“代码+长度+数据”。常见的option参数字段主要如下表2：

在表2中，“Message type(消息类型)”通常有8种，包括：1-DHCP DISCOVER、2-DHCPOFFER、3-DHCP REQUEST、4-DHCP DECLINE、5-DHCP ACK、6-DHCP NAK、7-DHCP RELEASE以及8-DHCP INFORM。Authentication for DHCP messages是用来完成基于标准DHCP协议，以在客户设备处输入用户名和密码的方式进行的地址鉴权。

如表1和2所示，通过解析单元130解析获得上述DHCP封包中的信息，从而获知DHCP报文具体属于何种类型。如果表1和2所示的DHCP报文中存在Option(6)字段，说明该DHCP服务器400-1已经配置了DNS，接入设备100-1的收发单元110会基于解析单元130的解析判断结果直接将DHCP服务器要约报文转发给客户设备200。如果不存在Option(6)字段，说明该DHCP服务器400-1没有配置了DNS。接入设备100-1的封装单元140将原始DHCP服务器要约报文重新封装为一个新的DHCP服务器要约报文，并将新的DHCP服务器要约报文转发给客户设备200，而原始DHCP服务器要约报文将被丢弃。表3和表4显示了原始DHCP服务器要约报文和新DHCP服务器要约报文结构之间的对比情况：

表3(原始DHCP服务器要约报文结构)

链路层	目的MAC(STA的MAC)	源MAC(DHCP服务器的MAC)	省略
				网络层	源IP(DHCP服务器的IP)	目的IP(DHCP分配给STA的IP)	省略
传输层	源端口(固定67)	目的端口(固定68)	省略
				应用层	省略	省略	省略
应用层	Yiaddr(DHCP分配给STA的IP)	省略	省略
				应用层	Option(53):DHCP Message Type(Offer)	省略	省略

表4(重新封装后的新DHCP服务器要约报文结构)

表3和表4中的“STA”为一种无线客户设备或无线终端。如表3和表4对比可以看出，一方面，新的DHCP服务器要约报文和原始的DHCP服务器要约报文，在传输层以上的应用层基本一致，仅仅新增加了DHCP服务器要约报文新增了Option(6)字段的内容，具体而言，可以直接将接入设备100-1的DNS配置信息添加到新DHCP服务器要约报文的Option(6)字段。另一方面，在传输层及传输层以下的网络层和链路层会有所不同，即，将链路层的源MAC地址修改为接入设备100-1的MAC地址，并将网络层的源IP修改为接入设备100-1的IP。由此，构造成一个新的DHCP服务器要约报文。新的DHCP服务器要约报文将存储在待转发缓存区。该新的DHCP服务器要约报文看起来就像是接入设备100-1发出的一个DHCP要约报文一样，因此，此时接入设备100-1起到一个客户设备200和DHCP服务器400-1之间的一个代理的作用。

在接入设备100-1的封装单元140重新封装DHCP服务器要约报文的同时，更新单元160会基于解析单元130的解析结果修改存储单元150中的缓存表151。具体而言，根据从DHCP服务器要约报文解析出的目的MAC，查找缓存表151，将目的MAC对应的条目中的“状态”项字段置为“代理”(例如标识“1”)。这样，当该客户设备200在该接入设备100-1中的缓存表151中的状态标志为“代理”时，其后续的所有目的地为该客户设备的DHCP回复报文都会被接入设备100-1所代理，即丢弃原始DHCP回复报文，同时生成新的DHCP回复报文后再转发给客户设备200。

随后，客户设备200收到DHCP服务器要约报文后会发出客户设备DHCP请求报文。接入设备100-1收到客户设备DHCP请求报文后，被筛选单元120筛选处理并被解析单元130提取处其源MAC地址，并基于所提取的源MAC地址查找缓存表151，以查看该客户设备所对应的状态标志。如果该客户设备所对应的状态标志为“正常”状态，这意味着该客户设备DHCP请求报文所对应的原始DHCP服务器要约报文是配置了DNS信息的DHCP服务器发出的，因此该客户设备所对应的状态标志为“正常”状态未曾改变为，因此收发单元110会基于该结果而直接转发该客户设备DHCP请求报文到对应的DHCP服务器400-1。相反，如果该客户设备所对应的状态标志为“代理”状态，这意味着该客户设备DHCP请求报文所对应的原始DHCP服务器要约报文是未配置DNS信息的DHCP服务器发出的，则接入设备100-1的封装单元140将原始客户设备DHCP请求报文重新封装为一个新的客户设备DHCP请求报文，并将新的客户设备DHCP请求报文转发给DHCP服务器400-1，而原始客户设备DHCP请求报文将被丢弃。表5和表6显示了原始客户设备DHCP请求报文和新客户设备DHCP请求报文结构之间的对比情况：

表5(原始客户设备DHCP请求报文结构)

链路层	目的MAC(AP的MAC)	源MAC(STA的MAC)	省略
				网络层	源IP(0.0.0.0)	目的IP(255.255.255.255)	省略
传输层	源端口(固定68)	目的端口(固定67)	省略
				应用层	省略	省略	省略
应用层	yiaddr(0.0.0.0)	省略	省略
				应用层	Option(53):DHCP Message Type(Request)	省略	Option(6):Domain Name Server

表6(重新封装后的新客户设备DHCP请求报文结构)

链路层	目的MAC(DHCP服务器的MAC)	源MAC(STA的MAC)	省略
				网络层	源IP(0.0.0.0)	目的IP(255.255.255.255)	省略
传输层	源端口(固定68)	目的端口(固定67)	省略
				应用层	省略	省略	省略
应用层	yiaddr(0.0.0.0)	省略	省略
				应用层	Option(53):DHCP Message Type(Request)	省略	省略

表5和表6中的“STA”为一种无线客户设备或无线终端。如表5和表6对比可以看出，一方面，新的客户设备DHCP请求报文和原始的客户设备DHCP请求报文，在传输层以上的应用层基本一致，仅仅新客户设备DHCP请求报文中的省略了原始客户设备DHCP请求报文中的Option(6)字段的内容。另一方面，在传输层及传输层以下的网络层和链路层会有所不同，即，将链路层的目的MAC地址从接入设备100-1的MAC地址修改为DHCP服务器的MAC地址，该DHCP服务器的MAC地址是该客户设备DHCP请求报文所对应的DHCP服务器要约报文中所包含的DHCP服务器的MAC地址。由此，构造成一个新的客户设备DHCP请求报文。新的客户设备DHCP请求报文将存储在待转发缓存区。该新的客户设备DHCP请求报文看起来就像是接入设备100-1发出的一个客户设备DHCP请求报文一样，因此，此时接入设备100-1起到一个客户设备200和DHCP服务器400-1之间的一个请求代理的作用。

随后，接着DHCP服务器400-1会针对客户设备DHCP请求报文后会回复DHCP服务器响应报文。同样，接入设备100-1收到DHCP服务器响应报文后，DHCP服务器响应报文被筛选单元120筛选处理并被解析单元130提取出其中目的MAC地址，并基于所提取的目的MAC地址查找缓存表151，以查看该客户设备所对应的状态标志。如果该客户设备所对应的状态标志为“正常”状态，这意味着该DHCP服务器响应报文是配置了DNS信息的DHCP服务器发出的，因此该客户设备所对应的状态标志为“正常”状态未曾改变为，因此收发单元110会基于该结果而直接转发该DHCP服务器响应报文到对应的客户设备200。相反，如果该客户设备所对应的状态标志为“代理”状态，这意味着该DHCP服务器响应报文是未配置DNS信息的DHCP服务器发出的，则接入设备100-1的封装单元140将原始DHCP服务器响应报文重新封装为一个新的DHCP服务器响应报文，并将新的DHCP服务器响应报文转发给客户设备200，而原始DHCP服务器响应报文将被丢弃。表7和表8显示了原始DHCP服务器响应报文和新DHCP服务器响应报文结构之间的对比情况：

表7(原始DHCP服务器响应报文结构)

链路层	目的MAC(STA的MAC)	源MAC(DHCP服务器的MAC)	省略
				网络层	源IP(DHCP服务器的IP)	目的IP(DHCP分配给STA的IP)	省略
传输层	源端口(固定67)	目的端口(固定68)	省略
				应用层	省略	省略	省略
应用层	yiaddr(DHCP分配给STA的IP)	省略	省略
				应用层	Option(53):DHCP Message Type(ACK)	省略	省略

表8(重新封装后的新DHCP服务器响应报文结构)

链路层	目的MAC(STA的MAC)	源MAC(AP的MAC)	省略
				网络层	源IP(AP的IP)	目的IP(DHCP分配给STA的IP)	省略
传输层	源端口(固定67)	目的端口(固定68)	省略
				应用层	省略	省略	省略
应用层	yiaddr(DHCP分配给STA的IP)	省略	省略
				应用层	Option(53):DHCP Message Type(ACK)	省略	Option(6):Domain Name Server

表7和表8中的“STA”为一种无线客户设备或无线终端。如表7和表8对比可以看出，一方面，新的DHCP服务器响应报文和原始的DHCP服务器响应报文，在传输层以上的应用层基本一致，仅仅新增加了DHCP服务器要约报文新增了Option(6)字段的内容，具体而言，可以直接将接入设备100-1的DNS配置信息添加到新DHCP服务器响应报文的Option(6)字段。另一方面，在传输层及传输层以下的网络层和链路层会有所不同，即，将链路层的源MAC地址修改为接入设备100-1的MAC地址，并将网络层的源IP修改为接入设备100-1的IP。由此，构造成一个新的DHCP服务器响应报文。新的DHCP服务器响应报文将存储在待转发缓存区。该新的DHCP服务器响应报文看起来就像是接入设备100-1发出的一个DHCP响应报文一样，因此，此时接入设备100-1起到一个客户设备200和DHCP服务器400-1之间的一个代理的作用。

至此，客户设备200与未配置DNS的DHCP服务器400-1之间的DHCP交互过程结束。总的来说，接入设备100-1通过查询缓存表151中客户设备对应MAC的状态来处理DHCP报文交互。如果是“正常”状态则原封不动地转发，如果是“代理”状态会创建包含DNS信息的新报文并丢弃原始报文。

图2示出了根据本公开无线接入设备处理客户设备与无DNS配置信息的DHCP服务器之间建立连接的时序图。如图2所示，接入设备100-1在接收到客户设备200发起的寻找链接到DHCP服务器400-1的客户设备DHCP广播报文(DISCOVER)后，会将客户设备200的MAC地址及其状态信息填充到缓冲表中，并将客户设备DHCP广播报文转发到DHCP服务器400-1。随后，接入设备100-1在接收到DHCP服务器400-1发送到客户设备200的DHCP服务器要约报文(OFFER)后，将DHCP服务器要约报文重新封装为源地址信息为接入设备100-1地址信息的新DHCP服务器要约报文，并转发到客户设备200,同时修改缓存表中客户设备200的MAC地址对应状态信息修改为“代理”状态。接着，接入设备100-1在接收到客户设备100-1发送的客户设备DHCP请求报文(REQUEST)后,将客户设备DHCP请求报文重新封装为目的地地址信息为DHCP服务器400-1的地址信息的新客户设备DHCP请求报文，并转发到DHCP服务器400-1。最后，接入设备100-1在接收到DHCP服务器400-1发送到客户设备200的DHCP服务器响应报文(ACK)后，将DHCP服务器响应报文重新封装为源地址信息为接入设备100-1地址信息的新DHCP服务器响应报文，并转发到客户设备200。通过与客户设备与具有DNS配置DHCP服务器建立连接的四个常规步骤完全相同的方式，客户设备200能够与无DNS配置的DHCP服务器400-1之间建立连接。

图3示出了根据本公开无线接入设备的数据处理方法的流程图。如图3所示，首先在步骤S205处，筛选单元120对所有报文进行筛选，确定其是否为DHCP报文。主要是基于其UDP端口进行判断其是否是来源于客户设备200的DHCP报文或来自于DHCP服务器的DHCP报文。对于为DHCP报文，在步骤S210处，解析单元120对其进行解析，获取其各个字段信息，从而确认其是否为来自客户设备的客户设备DHCP广播报文、来自客户设备的客户设备DHCP请求报文、来自DHCP服务器的DHCP服务器要约报文以及来自DHCP服务器的DHCP服务器响应报文之一。如果确认其为来自客户设备的客户设备DHCP广播报文，则在步骤S215处，将客户设备DHCP广播报文的作为源地址对应的客户设备的MAC地址及其状态信息补充到存储单元150的缓存表151中。其初始状态为“正常”状态，表示其报文不需要接入设备100-1进行代理。随后，在步骤S260处，收发单元直接将客户设备DHCP广播报文基于其目的地信息转发到DHCP服务器400-1。

随后DHCP服务器400-1在收到客户设备DHCP广播报文后，会对应发出DHCP服务器要约报文，当在步骤S210处解析单元120确认所收到的DHCP报文为DHCP服务器要约报文时，在步骤S220处，解析单元120会基于所解析获得DHCP服务器要约报文字段信息中包含的目的地地址信息查询缓存表151对应的客户设备200的MAC地址所对应的状态标志。随后在步骤S225处，更新单元160会将其对应的状态标志从“正常”修改为“代理”，并且封装单元140在步骤S230处，将DHCP服务器要约报文的地址信息修改为接入设备100-1的地址信息以及增加DNS信息。具体而言，将DHCP服务器要约报文链路层的源MAC地址从DHCP服务器的MAC地址修改为接入设备100-1的MAC地址，以及将网络层的源IP地址从DHCP服务器的IP地址修改为接入设备100-1的IP地址，同时将DHCP服务器要约报文中的DNS信息从省略状态修改为接入设备100-1自身的DNS信息，也就是将接入设备100-1自身的DNS信息填充到Option(6)字段。接入设备100-1自身的DNS信息为接入设备100-1为接入设备控制器(AC)上预先配置好后通过CAPWAP协议下发给所有链接在接入设备控制器(未示出)上的接入设备。随后，在步骤S260处，收发单元将重新封装后的新DHCP服务器要约报文转发到客户设备200。

客户设备200在收到接入设备100-1转发来的新DHCP服务器要约报文后，会发出客户设备DHCP请求报文。当在步骤S210处解析单元120确认所收到的DHCP报文为客户设备DHCP请求报文时，在步骤S235处，解析单元120会基于所解析获得客户设备DHCP请求报文的字段信息中包含的源地址信息查询缓存表151对应的客户设备200的MAC地址所对应的状态标志。随后在步骤S240处，解析单元130判断客户设备200的MAC地址所对应的状态标志是否为“代理”状态。如果为“代理”状态，由于此时客户设备DHCP请求报文是对接入设备100-1转发来的新DHCP服务器要约报文的响应，因此，其目的地地址信息为接入设备100-1的地址信息。由于客户设备DHCP请求报文最终的连接目的地为DHCP服务器，因此，封装单元140在步骤S245处，将客户设备DHCP请求报文的目的地地址信息修改为DHCP服务器的地址信息以及删除DNS信息。具体而言，将客户设备DHCP请求报文链路层的目的地MAC地址从接入设备100-1的MAC地址修改为DHCP服务器的MAC地址，以及将客户设备DHCP请求报文中的DNS信息从接入设备100-1自身的DNS信息修改为省略状态。随后，在步骤S260处，收发单元将重新封装后的新客户设备DHCP请求报文转发到DHCP服务器400-1。如果在步骤S240处，解析单元130判断客户设备200的MAC地址所对应的状态标志为“正常”状态，这意味着该原始客户设备DHCP请求报文所针对的DHCP服务器要约报文本身是包含DNS信息的，因此收发单元110会在步骤S260处直接转发原始客户设备DHCP请求报文。

随后，DHCP服务器400-1在接收到新客户设备DHCP请求报文后，也会针对其做出响应，并发出DHCP服务器响应报文。当在步骤S210处解析单元120确认所收到的DHCP报文为DHCP服务器响应报文时，在步骤S250处，解析单元120会基于所解析获得DHCP服务器响应报文的字段信息中包含的目的地地址信息查询缓存表151对应的客户设备200的MAC地址所对应的状态标志。随后在步骤S255，解析单元130判断客户设备200的MAC地址所对应的状态标志是否为“代理”状态。如果为“代理”状态，由于此时DHCP服务器响应报文是对接入设备100-1转发来的重新封装的客户设备DHCP请求报文响应，因此，其源地址信息为DHCP服务器400-1的地址信息。由于客户设备200的MAC地址所对应的状态标志为“代理”状态，因此，作为对原始客户设备DHCP请求报文响应，要获得对应的响应报文，封装单元140在步骤S230处，将DHCP服务器响应报文的源地址信息修改为接入设备100-1的地址信息以及删除DNS信息。具体而言，将DHCP服务器响应报文的链路层的源MAC地址从DHCP服务器的MAC地址修改为接入设备100-1的MAC地址和网络层的源IP地址从DHCP服务器400-1的IP地址修改为接入设备100-1的IP地址，以及将DHCP服务器响应报文中的DNS信息从接入设备100-1自身的DNS信息修改为省略状态。随后，在步骤S260处，收发单元将重新封装后的新DHCP服务器响应报文转发客户设备200。如果在步骤S240处，解析单元130判断客户设备200的MAC地址所对应的状态标志为“正常”状态，这意味着该原始客户设备DHCP请求报文所针对的DHCP服务器要约报文本身是包含DNS信息的，因此收发单元110会在步骤S260处直接转发原始DHCP服务器响应报文。

综上所述，每当接入设备100-1收到客户设备的DHCP广播报文(DISCOVER报文)时，都会设置对应MAC表项状态为“正常”，而在接入设备100-1收到DHCP服务器要约报文时，如果该报文携带了Option(6)字段，则保持“正常”状态；如果没有携带，则对应客户设备200对应的状态标志设置为“代理”状态。

采用本公开接入设备及其数据处理方法，在DHCP服务器没有配置DNS的情况下，可以通过本公开的接入设备检查DHCP服务器要约报文是否缺失DNS，并通过修改DHCP服务器要约报文以及响应报文自动补全DNS，通过创建缓存表，记录STA的代理状态，根据报文中的MAC查询缓存表，由此判断是否需要代理报文，从而避免了客户设备连接无线网络后由于DHCP服务器没有配置DNS信息或服务器而无法正常上网的问题。而且，通过修改原始报文的链路层、网络层、传输层、应用层，在不会破坏现有的DHCP报文交互流程的情况下，实现客户设备和DHCP服务器之间通信，用户不会感知到接入设备的存在。整个过程，DHCP服务器认为自己只和客户设备通信；客户设备认为自己只和DHCP服务器通信。

本公开的目的还可以通过在任何计算装置上运行一个程序或者一组程序来实现。所述计算装置可以是公知的通用装置。因此，本公开的目的也可以仅仅通过提供包含实现所述方法或者装置的程序代码的程序产品来实现。也就是说，这样的程序产品也构成本公开，并且存储有这样的程序产品的存储介质也构成本公开。显然，所述存储介质可以是任何公知的存储介质或者将来所开发出来的任何存储介质。

还需要指出的是，在本公开的装置和方法中，显然，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本公开的等效方案。并且，执行上述系列处理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要一定按照时间顺序执行。某些步骤可以并行或彼此独立地执行。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (10)

1.一种无线接入设备，包括：

筛选单元，筛选来自客户设备和DHCP服务器的DHCP报文；

解析单元，解析所筛选出的DHCP报文，确定报文DHCP报文类型；以及

报文封装单元，在解析单元确定DHCP报文为来自DHCP服务器的要约报文或响应报文并且不包含DNS信息时，通过将所述DHCP服务器要约报文和响应报文中的源信息替换为所述无线接入设备自身的地址信息并增加DNS信息，从而将所述DHCP服务器要约报文和响应报文重新封装成新的DHCP服务器要约报文和响应报文，以及通过将来自客户设备针对所述新DHCP服务器要约报文的DHCP请求报文中的目的地地址信息替换为DHCP服务器的地址信息以及删除DNS信息，从而将所述客户设备DHCP请求报文重新封装成新的客户设备DHCP请求报文。

2.根据权利要求1所述无线接入设备，还包括：

存储单元，用于存储缓存表，所述缓存表在解析单元确定DHCP报文为客户设备广播报文时至少记录所述广播报文中的源MAC地址、目的MAC地址以及状态标志；以及

更新单元，在解析单元确定DHCP报文为针对所述客户设备广播报文的不包含DNS信息的DHCP服务器要约报文时，将所述DHCP服务器要约报文中的目的地信息在缓存表中对应的客户设备的状态标志修改为代理状态。

3.根据权利要求2所述的无线接入设备，其中

所述报文封装单元基于所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文所包含的客户设备地址信息在缓存表中对应的客户设备的代理状态对所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文进行重新封装。

4.根据权利要求1-3任意一项所述的无线接入设备，其中所增加或删除的DNS信息为所述无线接入设备自身的DNS信息。

5.根据权利要求4所述的无线接入设备，其中所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文在被封装为新的DHCP服务器要约报文或响应报文以及原始DHCP回复报文将被丢弃。

6.一种无线接入设备的数据处理方法，包括：

通过筛选单元筛选来自客户设备和DHCP服务器的DHCP报文；

通过解析单元解析所筛选出的DHCP报文，确定报文DHCP报文类型；以及

由报文封装单元在解析单元确定DHCP报文为来自DHCP服务器的广播报文或响应报文并且不包含DNS信息时，通过将所述DHCP服务器要约报文和响应报文中的源信息替换为所述无线接入设备自身的地址信息并增加DNS信息，从而将所述DHCP服务器要约报文和响应报文重新封装成新的DHCP服务器要约报文和响应报文，以及通过将来自客户设备针对所述新DHCP服务器要约报文的DHCP请求报文中的目的地地址信息替换为DHCP服务器的地址信息以及删除DNS信息，从而将所述客户设备DHCP请求报文重新封装成新的客户设备DHCP请求报文。

7.根据权利要求6所述的无线接入设备的数据处理方法，还包括：

在存储单元存储缓存表，所述缓存表在解析单元确定DHCP报文为客户设备广播报文时至少记录所述广播报文中的源MAC地址、目的MAC地址以及状态标志；以及

由更新单元在解析单元确定DHCP报文为针对所述客户设备广播报文的不包含DNS信息的DHCP服务器要约报文时，将所述DHCP服务器要约报文中的目的地信息在缓存表中对应的客户设备的状态标志修改为代理状态。

8.根据权利要求7所述的无线接入设备的数据处理方法，其中

所述报文封装单元基于所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文所包含的客户设备地址信息在缓存表中对应的客户设备的代理状态对所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文进行重新封装。

9.根据权利要求6-8任意一项所述的无线接入设备的数据处理方法，其中所增加或删除的DNS信息为所述无线接入设备自身的DNS信息。

10.根据权利要求9所述的无线接入设备的数据处理方法，还包括：所述DHCP服务器要约报文或响应报文以及所述客户设备DHCP请求报文在被封装为新的DHCP服务器要约报文或响应报文以及原始DHCP回复报文将被丢弃。

Images