佐须之男 发布的文章

wifidog 移植到MIPS平台

使用的是一款Broadcom的芯片,现在上面运行wifidog实现认证上网的功能。由于不是openwrt平台,所以就没了make menuconfig 勾选就能自动编译到版本中的。所以想使用交叉编译的方法将wifidog移植到该平台上。

下面写下步骤吧,不是很复杂,但是开始也破费周折。下载源码到http://dev.wifidog.org 下载就可以了。

./configure CC=/opt/toolchains/crosstools-mips-gcc-4.6-linux-3.4-uclibc-0.9.32-binutils-2.21/usr/bin/mips-linux-gcc CXX=/opt/toolchains/crosstools-mips-gcc-4.6-linux-3.4-uclibc-0.9.32-binutils-2.21/usr/bin/mips-linux-g++ LD=/opt/toolchains/crosstools-mips-gcc-4.6-linux-3.4-uclibc-0.9.32-binutils-2.21/usr/bin/mips-linux-ld RANLIB=/opt/toolchains/crosstools-mips-gcc-4.6-linux-3.4-uclibc-0.9.32-binutils-2.21/usr/bin/mips-linux-ranlib AR=/opt/toolchains/crosstools-mips-gcc-4.6-linux-3.4-uclibc-0.9.32-binutils-2.21/usr/bin/mips-linux-ar --build=i686-pc-linux-gnu --host=mips-wrs-linux-gnu --target=mips-wrs-linux-gnu --prefix=/home/wifidog_install/

使用configure 配置。这里我的平台只使用 ./configure --host=mips-linux-gcc 的方式可以编译成功,但是放在板子上运行会报错"mips-linux-gcc " not found。很莫名其妙的。所以采用上面的配置方法,配置生成Makefile文件后,make ,make install,将/home/wifidog_install/下的lib 与 bin中的文件放到板子上。这里可能遇到执行wifidog 缺少libnsl.so.0这个库,查找交叉编译工具器中是否存在?如果没有就去下载源码,交叉编译一个了。

还有一个就是将wifidog 源码中的wifidog.conf 和wifidog-msg.html 两个文件拷贝到板子上。wifidog.conf 是wifidog运行需要解析的配置文件,而wifidog-msg.html 也是一个必须的框架。这个路径在wifidog.conf中指定。

本文章由 http://www.wifidog.pro/2014/12/25/wifidog-mips%E5%B9%B3%E5%8F%B0.html 整理编辑,转载请注明出处

Wifidog初分析(二)

上一节介绍了wifidog 客户端,及网关协议。
三、认证服务端简介

服务端官方推荐的有两个,一个是authpuppy,还有一个是wifidog-auth。两个环境都已经搭建成功。

Authpuppy主要是一个authpuppy.core.php ,类似Linux的管理方式,中心是一个内核文件。扩展功能是以plugin插件的方式进行加载、卸载管理的。

优点:可管理性比较好,随用随加载;不用既可以卸载掉。

缺点:代码不易阅读。因要求易于管理,插件模块形式要求严格。对于小型功能来说浪费时间。

Wifidog-auth显得就是“全面”,理解起来稍微简单。

认证主要分为三块,ping保活、login认证、portal认证。代码可能有不同,但是有相同的协议,以及相同的回复内容。下面是wifidog与服务端通信协议的几个例子。

网关心跳(Ping协议)

Wifidog将ping协议作为心跳机制向认证服务器发送当前状态信息。这可以实现为认证服务器每个节点的状态生成中央日志。

Wifidog客户端在conf文件中进行设置,目的是通过http定期启动thread(ping_thread.c)向认证服务器发送状态信息。信息格式如下:

http://auth_sever/ping/?

gw_id=%s

sys_uptime=%lu

sys_memfree=%u

sys_load=%.2f

wifidog_uptime=%lu"

通过系统调用wifidog客户端收集的数据

Headers/

HTTP/1.0\r\n"

"User-Agent: WiFiDog %s\r\n"

"Host: %s\r\n"

一个典型的HTTP需求应该是:

GET /ping/?gw_id=001217DA42D2&sys_uptime=742725&sys_memfree=2604&sys_load=0.03&wifidog_uptime=3861 HTTP/1.0( k# O# X) };

User-Agent: WiFiDog 1.1.3_beta62 T. R"

Host: auth.ilesansfil.org

认证服务器认证协议

这个页面描述了当用户已经被认证并允许访问互联网时,为了认证用户和进程,wifidog网关和认证服务器之间的信息传送。

Wifidog客户端将定期的启动一个thread来报告每个用户的连接状况。目前它被用来报告每个用户输入/输出计数器,以显示用户依然在现,并允许认证服务器将不再连接的用户断开。

以下是发给每个在线用户的信息

auth_server:/auth/index.php?

stage=

ip=

mac=

token=

incoming=

outgoing=

注意:stage=计数器/登录,取决于是否是新客户端

即使输入输出变量会在所有信息中出现,但他们只对处于counter阶段的信息有效。其它情况下输入输出经常设置为0。

在做回复时,认证服务器会以有效身份或新用户信息,或者认证服务器错误提示形式进行回复。

回复格式如下:

Auth:

新用户状态为:

0 - AUTH_DENIED - User firewall users are deleted and the user removed.% u) i D; j: i4 J' X) \/ P

6 - AUTH_VALIDATION_FAILED - User email validation timeout has occured and user/firewall is deleted7 A% n+ s. z3 O9 r

1 - AUTH_ALLOWED - User was valid, add firewall rules if not present! A" _/ B* a8 ~$ g

5 - AUTH_VALIDATION - Permit user access to email to get validation email under default rules

-1 - AUTH_ERROR - An error occurred during the validation process

注意:认识服务器错误一般不会改变防火墙或用户状态

标准的URL为:

GET /auth/?stage=counters&ip=7.0.0.107&mac=00:40:05:5F:44:43&token=4f473ae3ddc5c1c2165f7a0973c57a98&incoming=6031353&outgoing=827770 HTTP/1.0

User-Agent: WiFiDog 1.1.3_beta6

Host: auth.ilesansfil.org

网关重定向浏览器

客户端浏览器在不同情况下会被重定向到其它页面:

初始化请求:

基于捕捉,客户端会被网关重定向到以下URL:

l login/?gw_address=%s&gw_port=%d&gw_id=%s&url=%s

例如:https://auth.ilesansfil.org/login/?gw_id=0016B6DA9AE0&gw_address=7.0.0.1&gw_port=2060

初始化请求之后

当请求被处理并且客户端已经被重定向到网关时

如果服务器回复AUTH_DENIED:注意你通常在标准认证服务器上看不到这样的提示。客户端将不会被重定向回网关。

l gw_message.php?message=denied

如果服务器回复AUTH_VALIDATION:

l gw_message.php?message=activate

如果服务器回复AUTH_ALLOWED:这是门户重定向

l portal/?gw_id=%s

如果服务器回复AUTH_VALIDATION_FAILED:注意你将不会在标准认证服务器看到此回复。客户端将不会重定向回网关。

l gw_message.php?message=failed_validation

认证服务器重定向浏览器

基于成功登录,客户端将被重定向到网关。 http://" . $gw_address . ":" . $gw_port . "/wifidog/auth?token=" . $token

URL示例:http://7.0.0.1:2060/wifidog/auth?token=4f473ae3ddc5c1c2165f7a0973c57a98

本文章由http://www.wifidog.pro/2014/12/25/wifidog-%E5%88%86%E6%9E%90.html整理编辑,转载请注明出处

Wifidog初分析(一)

一、综述

wifidog是搭建无线热点认证系统的解决方案之一,他比nocat、nodog更适合互联网营销思路。常见的使用在openwrt系统上,它实现了路由器和认证服务器的数据交互,在路由器方(客户端)是用C 语言代码,通过wifidog程序和linux iptables防火墙实现接入用户的认证跳转和控制。在认证服务器方(服务端)是通过php(还有java版本的)实现用户的认证流程和管理。

优点:有开源代码,可以很方便的搭建认证系统。方便用户进行需求定制。

缺点:通过iptables方式实现,性能比较差,整体拉低了路由器的数据包处理速度,协议比较繁琐,对认证服务器的造成性能损耗比较大。

二、wifidog 结构分析

Wifidog 客户端代码简析:

├── libhttpd

│ ├── api.c

│ ├── httpd.h

│ ├── httpd_priv.h

│ ├── ip_acl.c

│ ├── Makefile.am

│ ├── protocol.c

│ ├── README

│ └── version.c

├── src

│ ├── auth.c

│ ├── auth.h

│ ├── centralserver.c

│ ├── centralserver.h

│ ├── client_list.c

│ ├── client_list.h

│ ├── commandline.c

│ ├── commandline.h

│ ├── common.h

│ ├── conf.c

│ ├── conf.h

│ ├── debug.c

│ ├── debug.h

│ ├── firewall.c

│ ├── firewall.h

│ ├── fw_iptables.c

│ ├── fw_iptables.h

│ ├── gateway.c

│ ├── gateway.h

│ ├── http.c

│ ├── httpd_thread.c

│ ├── httpd_thread.h

│ ├── http.h

│ ├── Makefile.am

│ ├── ping_thread.c

│ ├── ping_thread.h

│ ├── safe.c

│ ├── safe.h

│ ├── util.c

│ ├── util.h

│ ├── wdctl.c

│ ├── wdctl.h

│ ├── wdctl_thread.c

│ └── wdctl_thread.h

这是wifidog的部分源码。

下面再来看看wifidog的认证流程图:
1.png

认证的大致流程可以从上图中看到。下面结合代码的实现与图1来说下wifidog 的工作过程。

1、在网关上配置好wifidog.conf 后,运行wifidog程序。此时wifidog对wifidog.conf进行解析,并获取其中的配置选项。如:认证服务的地址或url 项Hostname 192.168.2.103 还有认证服务下的文件选项。如果为根目录下就是认证服务的处理程序,那么就设置为 Path /。Wifidog启动时会将这些参数读取,并保持在一个数组中,以供之后使用。然后调用iptables加入防火墙规则,阻止所以连接网关的用户上网。但是到达认证服务器的规则是打开的状态。

 0 ACCEPT     all  --  *      *       0.0.0.0/0            192.168.2.103

 55  2772 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 redir ports 2060

小结:此节主要用到conf.* 解析配置文件,firewall.* fw_iptables.* 进行防火墙规则添加 。

2、程序运行起来后,当有用户进行外网访问时。根据②中的防火墙规则,会将HTTP请求的外部IP地址和端口通过NAT方式重定向至本地wifidog内嵌HTTP服务器的地址和端口上,并由内嵌HTTP服务器进行服务,而内嵌HTTP服务器的路径和回调处理。然后将具体的请求信息发送给认证服务器。代码不详谈,下面看个实例URL:

POST /authpuppy/web/login/?gw_address=192.168.2.1&gw_port=2060&gw_id=default&url=http%3A//quietmadman.blog.51cto.com/3269500/1384761 HTTP/1.1

当我访问时,wifidog 将我访问的url重定向到上述的url上。目的就是去服务端做认证。

可以看到这里有这几个参数信息:

gw_address,路由器的LAN地址

gw_port:为wifidog的监听端口

gw_id:路由器的标识名

mac:客户端设备的MAC地址

url:为客户端访问的原URL(以便于重定向)

3、接步骤2,wifidog发送上述的url给认证服务器。这里我们使用的认证服务器是authpuppy。安装了apAuthSplashOnlyPlugin 插件。该插件无需输入用户名、密码,但需要点击按钮方可上网,也算是无秘钥认证。

接下来说下抓包看到的认证过程:

POST /authpuppy/web/login/?gw_address=192.168.2.1&gw_port=2060&gw_id=default&url=http%3A//quietmadman.blog.51cto.com/3269500/1384761 HTTP/1.1

... ...

Referer: http://192.168.2.103/authpuppy/web/login/?gw_address=192.168.2.1&gw_port=2060&gw_id=default&url=http%3A//quietmadman.blog.51cto.com/3269500/1384761

Cookie: authpuppy=3oft24lljrish4731dibh2ji80

gw_id=default&gw_address=192.168.2.1&gw_port=2060&authenticator=apAuthSplashOnly&submit%5BapAuthSplashOnlyConnect%5D=Connect&apAuthSplashOnly%5Boptional_name%5D=HTTP/1.1 302 Found

... ...

Location: http://192.168.2.1:2060/wifidog/auth?token=8eb3aae0ade3492cad361443ac54b9dcb644dbb2

上述过程是wifidog给认证服务器发送请求认证的URL,服务器收到后回送一个带token值的url到网关上。此段处理在服务端。网关收到后再次发送信息给认证服务器,如下报文:

GET /wifidog/auth?token=8eb3aae0ade3492cad361443ac54b9dcb644dbb2 HTTP/1.1

... ...

HTTP/1.0 307 Redirect to portal

Server: Hughes Technologies Embedded Server

Location: http://192.168.2.103:80/authpuppy/web/portal/?gw_id=default

Date: Mon, 07 Jul 2014 15:16:00 GMT

... ...

GET /authpuppy/web/auth/?stage=login&ip=192.168.2.222&mac=64:27:37:e1:c3:d3&token=8eb3aae0ade3492cad361443ac54b9dcb644dbb2&incoming=0&outgoing=0&gw_id=default HTTP/1.0

... ...

网关GET到token后,陆续的向认证服务器发送相关认证信息。

这里主要是两大步骤:
1)通过调用 auth_server_request(&auth_response, REQUEST_TYPE_LOGIN, r->clientAddr, mac, token, 0, 0); 让 认证服务器 对该客户端的 token 进行校验;

2)根据 认证服务器 返回的 token 校验结果进行不同的处理(主要是对该客户端的防火墙过滤规则进行不同的设置),这里主要以 AUTH_ALLOWED 校验结果进行分析,这里主要是两个动作:

2).1,通过 fw_allow 函数调用对此客户端"放行";

2).2,返回重定向至 认证服务器的 portal 路径访问的响应

GET /authpuppy/web/portal/?gw_id=default HTTP/1.1

Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, /

Referer: http://192.168.2.103/authpuppy/web/login/?gw_address=192.168.2.1&gw_port=2060&gw_id=default&url=http%3A//quietmadman.blog.51cto.com/3269500/1384761

... ...

Host: 192.168.2.103

... ...

Location: http://quietmadman.blog.51cto.com/3269500/1384761

Wifidog返回信息到认证服务器的portal,portal返回给网关的信息如上。最后重定向到用户最初始访问的url上。

Wifidog 的client代码大致是这些。

本文章由 http://www.wifidog.pro/2014/12/25/wifidog%E5%88%86%E6%9E%90.html 整理编辑,转载请注明出处

WiFiDog 摘要

Wifidog被设计用于替换现有的强制网络门户解决方案,我们觉得不适合下一代社会群体的需求. 特别是, 开发商想为每个热点既个性化和社会各界的广泛内容, 没有弹出窗口, 任何客户端软件和集中管理. 主要作为替代目前使用NoCat门户. 很多其他厂商使用WiFiDog (尤其是在客户端) 作为其解决方案的基础.

主要特点

  1. 强制网络门户,它可以让业主热点与用户沟通 (通过内容分发系统).
  2. Wifidog网关是专为与运行在GNU / Linux服务器和嵌入式Linux设备, E.G. Linksys的WRT54G与OpenWRT的.
  3. 多种语言支持 (通过浏览器检测和用户选择) 与使用。
    英语
    法国人
    德语
    西班牙人
    意大利人
    希腊语
    葡萄牙 (还巴西)
    瑞典
    保加利亚语
    日本
    加泰罗尼亚语
  4. 维护客户端 (热点用户) 通过ping命令检查网络连接活动, 而不是一个JavaScript窗口 (像NoCat使用). 这使得PDA和手机等设备不支持JavaScript的连接.
  5. 支持不同类型的热点:
    1)飞溅Only模式: 用户被重定向到门户, 但不必为了使用服务登录
    2)正常模式: 用户是独一无二的,必须有为了有效的电子邮件地址开户.
  6. 用户可以直接从任何热点的创建工作帐户. 新用户注册上的任何热点, 创建自己的帐户,并授予使用 15 分钟,以确认电子邮件. 如果他们不这样做, 它们断开,必须重新注册.
  7. 通过双向的心脏跳动的热点/节点监控, 所以中央服务器总是知道哪些热点/节点都已启动, 无论动态DNS的, 防火墙, 等等.
  8. 报告和统计,包括:
    10 最高带宽的消费者
    10 最频繁的用户
    10 大多数移动用户
    Anoymised SQL数据导出 (学术研究)
    有多少用户实际使用的网络故障
    连接日志
    内容显示,通过单击报告
    在网络上使用图形 (每小时, 周日和月份)
    个人用户报告, 最流行的节点 (通过访问)
    网络状态信息
    节点的状态信息
    注册登录
    用户注册报告
  9. 自动创建节点 (如果在创建该节点的人具有相关权限,并启用该功能).

最期待的功能:

  1. 用户类
  2. 每级带宽限制
  3. 每个路由器的带宽限制
  4. 每班端口阻挡
  5. 根据一天中的时间应用策略

认证服务器 (当前)

  1. 特定于节点的内容特征. Wifidog-auth的有一个非常酷的本地内容架构.
    RSS feed支持 (可选, 用的magpierss), 每个节点有一个饲料 (URL存储在数据库中, 伟大工程, 但没有GUI来编辑它尚未) 和一个网络范围的RSS提要.
  2. 配置和集成
    无需设置任何路径在Web服务器的配置文件
    所有的路径都是从配置文件编辑
    快速设置: 网络名称, 网址, 默认的RSS, 和类似的数据从配置文件中设置, 并根据需要在整个系统中,将显示.
    可以导入所有的用户和密码从NoCat密码文件 [万维网] 更多信息].
  3. 发育
    演示页,让人们能够更容易地就可以破解
    数据库抽象层具有非常不错的调试功能 (只是真正的追加在通话结束,你会看到查询, 结果, 查询计划, 而受影响的行数. 移植到另一个数据库只需要移植一个文件. 目前使用的Postgres。)
  4. 用户管理 (最终用户)
    用户可以创建并激活帐户没有管理员干预. 该用户将被授予 15 签约以便检索和验证自己的电子邮件分钟后宽限期.
    用户可以请求服务器重新发送验证邮件
    用户可以更改自己的密码
    谁忘记了自己的用户名的用户可以把它邮寄给他们.
    谁失去了他们的密码,用户可以要求系统生成一个新的,并邮寄给他们.
    电子邮件必须是有效的,但不是为了保护用户的隐私展示.
    用户可以使用电子邮件或用户名登录
    强制执行 (礼貌) 重复的电子邮件地址不会在数据库中允许
  5. 日志和监控
    MAC地址记录 (在情况下,它是在你的国家的法律规定)
    重定向到中央服务器,以便允许连接的入口页上之前发送的原始URL
    多语言支持
    脚本和SQL执行时间分解. 已实施, 只需要由模板被打包到,也可以使用.
  6. 报表及统计

网关 (当前)

  1. 支持使用备份auth服务器,如果主之一不响应.
  2. 运行时查询界面
  3. 一个规则的跳, 一个跳出不合格, 一个跳出来接受
  4. 自动检测网络接口的IP地址, 而不是它的配置文件中分别指定.

规格

网站:http://dev.wifidog.org/
价格:免费
许可证:开源
操作系统:Linux的

本文章由 http://www.wifidog.pro/2014/12/25/wifidog.html 整理编辑,转载请注明出处