Wifidog流程网关协议v2

线路协议
回复形式

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

• 紧凑表示（当浏览分散式网络时，宽带也不便宜）
• 用户可读
• 能够为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配置

Main contributors: Benoit Grégoire, Philippe April, Alexandre Carmel-Veilleux

This page documents the design effort for designing version two of the wifidog protocol specification. While it will eventually turn into a structured specification, currently,

Wire protocol

Response format

It is desirable to have the following features in the wire protocol:

• Compact representation (bandwidth is NOT cheap when serving a distributed network)
• Human readable
• Fast and small parsers available for C and PHP, and ideally multiple other languages
• Suitable for sharing parser and format with the configuration file
• Suitable for cleanly representing trees (like the list of auth servers)

After discussion, the representation will be JASON. For config comment, a verb will be reserved for comments, which will be systematically ignored.

Request format

It is beyond desirable to have to following with request format:

• More than one operation per http request (for example, update statistics for more than one user)
• Keep the http transport, as it allows us full NAT and transparent proxy resistance

Some of the requirements above do not lend itself well to a RESTFull Resource oriented architecture (ROA). However, keeping the current format (GET parameters) limit us, in practice, to a single list of tag-value pairs. Even if one could, in theory, put an action=whatever in the middle of the list and have the protocol decree that every following parameters (until the next action) is to be a parameter of that action, that would utterly confuse most web servers and frameworks.

acv: One other possibility is to borrow a page from the way PHP does URL-parsing. Setting the key part of the get request to a array representation would allow for fairly logical request bundling., I.e.:

/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: This format would remain human readable while being very simple to parse (free in PHP, trivial in other languages).

So POSTing the parameters may have to be considered, in which case the same format as the response should be used, for obvious reasons.

Functionnal Requirements

• Allow some general configuration changes to be sent by the auth server.
• Allow non web-based MAC auth > Philippe: Explain this?
• Allow non connection based MAC auth
• Allow per-connection firewall policies
• Allow per-connection bandwidth management, not limited to set amounts
• Allow global bandwidth management (might come in configuration)
• Specify walled garden
• Specify list of initially connected users
• Many more....

Philippe: Ideas?

Philippe: Way to allow people on restart, or deny people on inactivity acv: People on restart needs to be pulled from auth server unless either of: (a) We have non-volatile storage that isn't too badly affected by write-wear; or (b) We have not rebooted and can read a file from ramdisk.

Actions

NOOP

Basically there only for gateway heartbeating. A min delay between operations would be specified, and if this delay is reached before an actual operation has to be performed, a NOOP is sent.

Philippe: not required, we'll always send at LEAST the status. If no "command" is sent, it means NOOP :)

AUTH_VERIFY

STATS_UPDATE

A proposed solution

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.

and a sample reply (just ideas...)

{
    "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", ... },
        ... ]
}

Gateway and Auth-Server communication

Gateway : Verbes / Actions	Auth-Server
Init request	Gateway configurations
MAC detect	Auth response (accept/deny this MAC)
User auth request	User connection configation (open/closed port, QOS)
Auth the auth server (key + protocol)	Auth the gateway (key + protocol)

Configurations

• Splash page if auth-server=down (URL)
• Splash page if internet=down (content)
• Walled garden (Think about DNS timeout)
• Static White/Black? list MAC
• Global firewall / QOS configuration
• Gzip optionnel, response only, through standard HTTP