在国外一些酒店、餐厅、咖啡厅、商业中心或其他的商家，经常可以看到客人使用笔记本或手机使用商家提供的无线Wifi网络上网。这是一个非常好的手段，客人得到了便利，商家赢得了客流。

其实，架设一个普通的家用WiFi热点是非常简单的。用一个普通的无线路由器（Wireless Router）就可以实现。但是在商业场合，这种方式往往就不能满足需求了。因为，普通家用的开放式的WiFi热点没有安全验证机制，任何用户都可以使用热点，甚至是商家以外的用户也可以“蹭网”。这就大大影响了网络热点的安全性和网络的稳定性。即使用WEP或WAP等验证方式也难以完全保证热点的安全性，而且也会大大限制了热点的便利性。而商用WiFi热点的构筑则是完全不一样的概念。

创建专业的商用WiFi热点的做法是，为欲使用热点的用户提供一个Web认证页面，一般是用强制网络门户系统(Captive Portal)/热点管理系统来实现的。以此认证页面为基础提供对用户多元化的认证方式。用户只有通过认证后，才能接入Wifi热点以使用Internet。同时，商家也可利用强制网络门户系统的后台实现与客户的一定互动。例如，可以在用户认证前向用户提示热点使用协议；或者发布商家或赞助商的广告；向客户推送商家最新促销信息等。甚至，还可以要求热点用户在线支付一定费用后才允许接入热点等等。一般，商家还可在强制网络门户系统的后台实现一些高级安全设置。如，客户端黑名单限制，地址限制，流量控制等。

架设这样的强制网络门户/热点管理系统有多种方法。但技术原理都是类似的，一般需要一个防火墙/网关系统，一个用于认证管理和控制的后台系统。
常见的技术解决方案有NoCat、Wifidog、Chillispot等。这类系统的构筑都分别有各种系统需求和构筑方法，由于构成的组件和子系统比较多，所以相对都比较繁琐。

此外，也有一些整套的服务商解决方案，比如FON，Wiwiz，ile sans fil，Sputnik和FreeSpot等。相对配置简单很多，用户一般只需要购买这些服务商提供的无线路由器设备或自行配置网关设备即可，而后台系统可使用这些服务商提供的后台服务。

这里着重介绍一下Wiwiz，因为Wiwiz是一个开放式的系统，不仅有中文版，安装配置的方式也最为灵活。最方便的是Wiwiz可以使用用户现有的无线路由器或AP设备。如果无线路由器已经安装或支持DD-WRT固件，只需要简单的设置即可。如果用户的无线路由器不支持DD-WRT，还可以使用用户的本地计算机或虚拟机。

笔者进行了对Wiwiz系统试验。因为笔者的无线路由器并不支持DD-WRT，所以笔者采用了虚拟机的安装方式。

介绍一下系统环境。计算机采用普通家用PC机，Windows XP SP2系统。Internet连接采用的是联通的ADSL接入。普通无线路由器一台。

首先，将ADSL调制解调器的网线另一端连接着无线路由器的WAN/Internet口。将另一根网线的一端插入无线路由器的一个LAN口，另一端接到PC的以太网插口。然后，设置无线路由器。在PC上打开浏览器，访问192.168.1.1，输入用户名密码后即可打开路由器的设置页面。设置好ADSL连接后，PC就可以正常访问Internet了。

接下来就要安装和配置Wiwiz的客户端了。因为是采用虚拟机的安装方式，所以先要下载并安装一个虚拟机软件。笔者使用的是免费的VMWare Player。下载之后直接打开安装程序并按照提示的步骤完成安装即可。

然后，下载Wiwiz的虚拟机镜像文件。在Wiwiz官网的下载页面有下载链接。镜像文件为Zip格式，大约180MB。下载后解压缩。双击后缀为.vmx的文件后，VMWare Player就会自动启动这个虚拟机镜像了，然后立即会看到一个提示，选择Keep。接着会看到一个Linux系统正在启动。

当启动完成后，点击虚拟机的界面以进入操作环境。此处要求用户登录系统，默认的用户名是root，密码为wiwiz-user。然后输入命令/usr/local/hsbuilder/hsbuilder_setup.sh setup ，并按回车。

之后一路回车，直到出现设置成功的提示。此时就已经大功告成了。

最后，用一台有无限网卡的电脑（或者有Wifi功能的手机）测试一下。在测试用的电脑上连接笔者的无线路由器的热点，连接成功后，打开任何一个网址都会见到默认认证页面。

因为笔者在虚拟机中执行设置的命令时使用的都是默认的配置，所以显示的热点认证页面也是默认的。其实，用户可以使用Wiwiz的服务后台创建并定制自己的热点。包括认证方式、是否付费及费率、认证页面的外观样式、颜色、图片以及服务条款等都可以进行定制。同时，还有一些高级权限控制的功能。专业版的用户（付费用户）还可以进行更高级别的设置并使用一些附加功能。详细的内容可以参考Wiwiz的官方网站(www.wiwiz.com)。这里就不做深入讲解了。

本文章由 http://www.wifidog.pro/2015/01/29/%E5%95%86%E7%94%A8wifi.html 整理编辑，转载请注明出处

问题出在init.d下的wifidog未enable, /etc/init.d/wifidog enable

本文章由 http://www.wifidog.pro/2015/01/29/wifidog-luci-1.html 整理编辑，转载请注明出处

认证流程如下图：

认证流程详解：
1.Login登录（参照 login/index.php）
服务器验证后，Redirect to GW，携带 token
http://$_REQUEST[gw_address]:$_REQUEST[gw_port]/wifidog/auth?token=$token
2.Validation of ID
服务器返回 Status
Auth: 1
Messages: | 认证信息（如错误之类的消息）
common.php中有如下定义：
/* Constant shared with the gateway

• NEVER edit these, as they mush match the C code of the gateway */
  define('ACCOUNT_STATUS_ERROR', -1);
  define('ACCOUNT_STATUS_DENIED', 0);
  define('ACCOUNT_STATUS_ALLOWED', 1);
  define('ACCOUNT_STATUS_VALIDATION', 5);
  define('ACCOUNT_STATUS_VALIDATION_FAILED', 6);
  define('ACCOUNT_STATUS_LOCKED', 254);

auth.h中也有相应定义：

/** 
 * @brief Authentication codes returned by auth server. 
 * 
 * Authentication result codes returned by auth_server_request() corresponding 
 * to result code from the central server itself. 
 */  
typedef enum {  
    AUTH_ERROR = -1, /**< An error occured during the validation process*/  
    AUTH_DENIED = 0, /**< Client was denied by the auth server */  
    AUTH_ALLOWED = 1, /**< Client was granted access by the auth server */  
    AUTH_VALIDATION = 5, /**< A misnomer.  Client is in 15 min probation to validate his new account */  
    AUTH_VALIDATION_FAILED = 6, /**< Client had X minutes to validate account by email and didn't = too late */  
    AUTH_LOCKED = 254 /**< Account has been locked */  
} t_authcode; 

本文章由 http://www.wifidog.pro/2015/01/29/wifidog-authserver.html 整理编辑，转载请注明出处

General Flow Description:

1.The client does his initial request, as if he was already connected, (e.g.: http://www.google.ca)
2.The Gateway's firewall rules mangle the request to redirect it to a local port on the Gateway. When that's the done, the Gateway provides an HTTP Redirect reply that contains the Gateway ID, Gateway FQDN and other informations
3.The Client does his request to the Auth Server as specified by the Gateway, see Login Protocol
4.The Gateway replies with a (potentially custom) splash (login) page
5.The Client provides his identification informations (username and password)
6.Upon succesful authentication, the client gets an HTTP Redirect to the Gateway's own web server with his authentication proof (a one-time token), http://GatewayIP:GatewayPort/wifidog/auth?token=[auth token]
7.The Client then connects to the Gateway and thus gives it his token
8.The Gateway requests validation of the token from the Auth Server, see Client Protocol
9.The Auth Server confirms the token
10.The Gateway then sends a redirect to the Client to obtain the Success Page from the Auth Server, redirects to http://auth_server/portal/
11.The Auth Server notifies the Client that his request was successful

本文章由 http://www.wifidog.pro/2015/01/28/wifidog-flow.html 整理编辑，转载请注明出处