线路协议
回复形式

在线路协议中有以下说明：

• 紧凑表示（当浏览分散式网络时，宽带也不便宜）
• 用户可读
• 能够为C语言和PHP提供快速的解析器，并且比较理想的是能够多语言化
• 适用于与配置文件分享解析器和格式
• 适用于清晰的显示树结构（例如认证服务器列表）

请求格式

必须遵循请求格式：

• 每个http请求都有多个操作（例如为多个用户更新统计数据）
• 保持http传送，因为这能允许完整的NAT和透明代理阻力

以上的一些需求没有适用于RESTFull ROA。然而，保持现有格式事实上把我们限制在了tag-value对列表。理论上即使可以将action=whatever放在列表中间并在协议中申明以下每个参数都是那个action的参数，这将使大多数网络服务器与框架完全混淆。

　　Acv：另一个可能性是从PHP进行URL-parsing的方式借用一个页面。将get请求设置到一个数组表示，这将允许公平的逻辑请求捆绑。也就是：

 /page?req[0][action]=Action1&req[0][Param1]=param&req[0][Param...]=param...&req[0][Paramn]=paramn&\


req[...][action]=Action...&req[...][Param1]=param&req[...][Param...]=param...&req[...][Paramn]=paramn&\


req[n][action]=Actionn&req[n][Param1]=param&req[n][Param...]=param...&req[n][Paramn]=paramn

　　Acv:当比较容易进行解析的时候，这个格式会保持用户可读

功能性需求

• 允许认证服务器发送一些主要的配置变更
• 允许基于MAC认证的非连接关系
• 允许per-connection防火墙政策
• 允许per-connection宽带管理，不只限于设置数量
• 允许全球宽带管理
• 指定围墙花园
• 指定最初连接用户列表

指令
NOOP
基本上只为网关心跳。可能会指定操作间很短的延迟，并且如果在实际操作之间延迟的话，就会发送NOOP。
AUTH_VERIFY
STATS_UPDATE

提议方案
　　Philippe：

 I think we could have a Hash kind of structure like this:

 * protocol_version: 1 (start with this to identify protocol)

 * wifidog_version: ...

 * status:

   * uptime, etc.

 * connected_clients:

   * stats, etc.

　　简单回复：

 {

    "protocol_version": 1,

    "config": {

        "login_url": "https://auth.server/login.php",

        "portal_url": "http://portal.server/",

        ... },

    "clients": [

        { "mac": "00aabbccdd22", "ip": "10.0.0.1", ... },

        { "mac": "00aabbccdd22", "ip": "10.0.0.1", ... },

        ... ]

}

网关和认证服务器通信

配置

• 醒目页面，如果auth-server=down(URL)
• 醒目页面，如果internet=down(内容)
• 围墙花园（考虑一下DNS超时）
• 静态MAC黑/白名单
• 全球防火墙/QOS配置

本文章由 http://www.wifidog.pro/2015/03/31/wifidog%E6%B5%81%E7%A8%8Bwifidog%E5%8D%8F%E8%AE%AE.html 整理编辑，转载请注明出处

下面是我所使用的测试方法，有其他更好测试方法的网友也可以共享出来。

测试方法：
通过软件发送多个连接请求来达到测试wifidog处理请求的能力，也就是其稳定性。
通过http_load软件发送网站连接请求，查看后台监控wifidog异常，逐渐增加 发送连接请求次数直到wifidog死掉或者重启。

测试环境：
将刷好的带wifidog认证的路由接入Internet和测试机（电脑或者手机）。使用电脑连接到路由后台，以调试模式运行wifidog，以便随时监控wifidog。

测试条件：
wifidog启动中并且测试机没有进行过认证。

预期结果：
wifidog死掉或者重启。

测试步骤：
测试工具链接：http://pan.baidu.com/s/1i36B8ED
将路由器接入外网，确认wifidog启动之后，在不认证的条件下，将http_load.zip压缩包解压到C盘根目录下。打开http_load文件夹，双击运行“wifidog稳定性测试.bat”批处理程序。等待程序运行完毕，打开文件夹下的result.txt即可查看到结果。

（右侧为修改后wifidog版本测试结果）
结果分析：

   30 fetches, 15 max parallel, 50527 bytes, in 0.140625 seconds
   1684.23 mean bytes/connection
   213.333 fetches/sec, 359303 bytes/sec
   msecs/connect: 1.04167 mean, 31.25 max, 0 min
   msecs/first-response: 46.3542 mean, 78.125 max, 15.625 min
   HTTP response codes:
   code 302 – 30


   1．30 fetches, 15 max parallel, 50527 bytes, in 0.140625 seconds
        说明在上面的测试中运行了30个请求，最大的并发进程数是15，总计传输的数据是50527bytes，运行的时间是0.140625秒
   2．1684.23 mean bytes/connection
        说明每一连接平均传输的数据量50527/30=1684.23
   3．213.333 fetches/sec, 359303 bytes/sec
        说明每秒的响应请求为213.333，每秒传递的数据为359303 bytes/sec
   4．msecs/connect: 1.04167 mean
        说明每连接的平均响应时间是1.04167 msecs，31.25 max, 0 min，最大的响应时间31.25msecs，最小的响应时间0 msecs;
   5．msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
   6、HTTP response codes: code 200 — 49 
        说明打开响应页面的类型，如果403的类型过多，那可能要注意是否系统遇到了瓶颈。

   特殊说明：
          测试结果中主要的指标是 fetches/sec、msecs/connect 这个选项，即服务器每秒能够响应的查询次数，用这个指标来衡量性能。

命令参数如下：
-parallel 简写-p ：含义是并发的用户进程数。
-fetches 简写-f ：含义是总计的访问次数。
-rate 简写-p ：含义是每秒的访问频率。
-seconds简写-s ：含义是总计的访问时间。

本文章由 http://www.wifidog.pro/2015/03/31/wifidog%E7%A8%B3%E5%AE%9A%E6%80%A7%E6%B5%8B%E8%AF%95.html 整理编辑，转载请注明出处

一 认证流程描述
　　i. Wifidog 运行之后建立一系列的防火墙规则，主要规则起到如下作用：

　　　　1.阻断所有内网到外网的访问。

　　　　2.开通内网到外网的 dns 访问。

　　　　3.开通内网到认证服务器以及域名白名单的访问。

　　　　4.对内网到外网 80 端口的访问转向到 wifidog 自己的 http 服务（2060 端口）。

　　ii. 手机、pc 连接上来后，app 或者系统（安卓、ios 会自己连接到各自的服务器上来验证网络的连通性）会发起对外网的访问请求，dns 请求会被放过，然后对应的 80 端口的访问会被指向 2060 的 http 服务，其他的请求都会被拦截。
　　iii. Wifidog 的 http 接到 web 请求后，基本上都会被指向 404 页面，404 页面会给客户端一个重定向返回（302），要求客户端重定向访问认证服务器的 login 页面，附加参数 gw_id、gw_address、gw_port、url。
　　iv. 手机、pc 客户端加载、显示认证服务器的 login 页面，用户根据页面内容做相关的认证操作（qq 登录、微博登录、用户名密码登录、手机短信登录等多种登录方式） ，原则只有一个认证不成功就仍然让用户停留在认证服务器继续认证操作，认证成功给客户端一个 302 重定向返回，根据 login 接口提交上来的参数 gw_address、gw_port 跳转套 wifidog web 服务的/wifidog/auth 页面上，附带 token 和 url 参数。
　　v. Wifidog 的 web 服务收到手机、pc 客户端的/wifidog/auth 请求后，会主动对认证服务器的 auth 接口发起一个验证请求， 附带参数 ip、 mac、 token、 stage=loginvi. 认证服务器的 auth 接口收到 wifidog 的请求， 要根据内部逻辑返回是否允许通过的应答 ：

　　　　Auth: 0 拒绝

　　　　Auth: 1 允许

　　vii. Wifidog 接收到验证结果后，如果拒绝访问，就会返回 302 给客户端，重定向到认证服务器的 gw_message 接口，附带 message=denied 参数，客户端的上网访问仍然会回到第二步骤；如果允许访问，则改动防火墙规则，开通改客户端的上网（至此客户端已经能够正常上网） ，然后返回 302 重点向给客户端，重定向到认证服务器的 portal 接口，附带参数 gw_id。

　　viii. 认证服务器的的 portal 接口根据业务流成显示广告业或者做其他的跳转ix. 整个认证流程完成。

二 ping 心跳流程描述
　　i. ping 接口 wifidog 检测认证服务器访问是否正常、并向认证服务器提交 wifidog的运行状态。
　　ii. 定时 ping 认证服务器。
　　iii. 提交的参数 gw_id、sys_uptime、sys_memfree、wifidog_uptime。

三 auth 心跳流程描述
　　i. 和 ping 一样的频率定期请求认证服务器，并且有多少已认证客户端就发多少请求。
　　ii. 用来向认证服务器提交客户端的状态以及执行认证服务的验证结果。
　　iii. 提交的参数有：ip、mac、token、incoming、outgoing 、stage=counters。
　　iv. 如果服务器返回拒绝，则 wifidog 改动防火墙规则，关闭该客户端的上网。

本文章由 http://www.wifidog.pro/2015/03/18/wifidog%E6%A0%87%E5%87%86%E6%B5%81%E7%A8%8B%E6%8F%8F%E8%BF%B0.html 整理编辑，转载请注明出处

概述

wifidog是搭建无线热点认证系统的解决方案之一，他比nocat更适合互联网营销思路。目前支持openwrt系统，他实现了路由器和认证服务器的数据交互，在路由器方是用C语言代码，通过wifidog程序和linux iptables防火墙实现接入用户的认证跳转和控制，在认证服务器方是通过php实现用户的认证流程和管理。
优点：有开源代码，可以很方便的搭建认证系统。
缺点：通过iptables方式实现，性能比较差，整体拉低了路由器的数据包处理速度，协议比较繁琐，对认证服务器的造成性能损耗比较大，在安全方面都是明文传输，有一定的安全隐患。

认证流程图:

网关心跳协议

Wifidog将ping协议作为心跳机制向认证服务器发送当前状态信息。实现认证服务器和每个节点的状态双向健康监测的机制。

请求信息：
http://auth_sever/ping/? gw_id=%s sys_load=%lu sys_memfree=%u sys_load=%.2f wifidog_uptime=%lu

回复格式：
Pong

例子：
GET/ping/? gw_id=001217DA42D2&sys_uptime=742725&sys_memfree=2604&sys_load=0.03&wifidog_uptime

用户状态心跳协议

请求格式：
http://auth_server/auth/? stage= ip= mac= token= incoming= outgoing=

注意：
ip,mac,token为用户的基本信息，incoming/outgoing为用户的连接计数信息。 stage=counter|login|logout，分别表示：已认证，新认证用户，超时需要删除的用户。

回复格式：
Auth:状态码(注意中间冒号和状态码之间有个空格)

状态码：
0-AUTH_DENIED-Userfirewallusersaredeletedandtheuserremoved. 1-AUTH_ALLOWED-Userwasvalid,addfirewallrulesifnotpresent

例子：
GET/auth/?stage=counters&ip=7.0.0.107&mac=00:40:05:5F:44:43&token=4f473ae3ddc5c1c2165f7a0973c57a98&incoming=6031353&outgoing=827770HTTP/1.0 User-Agent:cnrouterwifidog Host:auth.cnrouter.com

跳转协议

对于新连接用户，路由器将其产生的任意url请求通过302重定向到认证平台。
请求格式：
http://auth_server/login/? gw_id= gw_address= gw_port= mac= url=

例子：
GET/login/? gw_id=808100949391&gw_address=192.168.81.1&gw_port=80&mac=aa:bb:cc:dd:cc:ee&url=http://www.sina.com.cn/HTTP/1.0 User-Agent:cnrouterwifidog Host:auth.cnrouter.com

注册协议

请求格式：
http://gw_ip/wifidog/auth? token=

例子：
GET wifidog/auth?token=12312412124 User-Agent:iphone Host:路由器ip 注册请求成功，以307的方式跳转平台的portal/?gw_id=

本文章由 http://www.wifidog.pro/2015/03/17/wifidog%E8%AE%A4%E8%AF%81%E8%B7%AF%E7%94%B1%E6%8E%A5%E5%8F%A3%E6%96%87%E6%A1%A3.html整理编辑，转载请注明出处