A blog about flex, php and rails.

Snow Leopard upgraded php to 5.3, this means that passwords have to be changed – usually via SET password FOR ‘user’@'host’ = PASSWORD( ‘password’ ). This is fine, and can be verified by SELECT LENGTH( password ), user FROM mysql.user. The result should be 41.

I had inadvertently enabled old_password=1 in /etc/my.cnf, this caused both PASSWORD and OLD_PASSWORD to return the same value. To fix this, simply comment out the old_password=1 line in my.cnf and restart mysqld.

Hopefully this saves someone a few dozen google searches.

The issue is

In Red5 different scope handlers triggered by universal events (such as a client disconnecting) will be invoked depending on whether or not the universal event applies to the application scope (the root scope) or a child scope. For instance, if a client disconnects from the application, this will call the appStop, appLeave and appDisconnect handlers. By disconnecting from the application scope the client is also disconnecting from all child scopes (ie: rooms), however these handlers are not called.

A little bit confusing

Of itself, that behaviour’s not too difficult to grasp and I certainly haven’t had anywhere close to enough exposure to the design premise behind red5 to comment on it. Having said that, there are a couple of things which I find a little bit confusing:

1. The difference between the disconnect and leave handlers is not immediately obvious. It appears that both these handlers are called from the disconnect method on the Scope class (org.red5.server.Scope). My best guess at the moment is that the duplicitous methods have been left in for backwards compatibility or cohesion with FMS.
2. It seems like the only time the room handlers will be called is if a client is directly connected to a child scope and then wishes to regress to a higher scope. ie: the client connects directly to a room and then drops back to the application scope. In my case the reverse is usually true; the client connects to a lobby and then proceeds to connect to a room (child scope). Connecting to a child scope however is treated by a red5 as a completely new connection, triggering the appConnect handler and resulting in a new client id being assigned to the connection.

I’ve only been using Red5 for a couple of weeks now, so it’s likely a lot of the confusion is my own fault. The code I’m using to connect to a child scope on the server-side was provided by flashmonkey at http://www.flashmonkey.org/?p=341:

public void changeScope() {
IConnection connection = Red5.getConnectionLocal();
IScope currentScope = connection.getScope();
boolean success = currentScope.createChildScope("ChildScope");
if (success)
{
IScope newScope = currentScope.getScope("ChildScope");
newScope.connect(connection);

}


}

Recording bandwidth used by wifi clients sounds like a relatively simple task. $90 and far too many hours later I can assure you that for a person without much network experience it can be deceptively challenging.

This article is a quick guide describing how to configure DD-WRT, Chillispot and Freeradius for the specific use case of mac-address freeradius authentication and accounting. It also briefly touches on web-based admin solutions. A radius server handles authorisation and accounting (ie: counting of bandwidth used by wifi users). The Chillispot instance within DD-WRT funnels all wifi clients through this authorisation and periodically, (if so configured), dispatches accounting packets to the radius server.

The Purpose

The purpose of my configuration is to restrict access to my wireless network and monitor the bandwidth consumed by authorised users. Consequently, the setup which this article describes is not orientated towards a hotspot, as all authentication is performed based on mac addresses.

The main focus of this post is on configuring a Chillispot instance within a router running DD-WRT. For information about setting up free radius check out the following sites:

• http://wiki.freeradius.org/
• http://www.howtoforge.com/authentication-authorization-and-accounting-with-freeradius-and-mysql-backend-and-webbased-management-with-daloradius

The Pieces

1. A router running DD-WRT
2. A configured free radius server

DD-WRT and Chillispot

Full versions of DD-WRT come bundled with Chillispot, however getting Chillispot and free radius using mac-address authorisation to play nicely can be a little bit tricky. The main thing to remember is that DHCP servers within DD-WRT should be disabled as Chillispot contains its own DHCP server. It may be possible to get the various instances to exist harmoniously but the simplest solution for me was just disable them. To configure DD-WRT:

1. Disable the DHCP server under setup, untick all checkboxes relating to DNSMasq.
2. Disable DNSMasq under the Services tab.
3. If you haven’t already, you should probably set some form of security for your wireless network.
4. Enable Chillispot under Services->Hotspot.

Configuring Chillispot

The following image details my Chillispot setup:

Chillispot configuration in DDWRT

Most of the parameters are relatively self explanatory. More information can be found here: http://www.dd-wrt.com/wiki/index.php/Chillispot. The parameters of note are:

• The UAM secret is irrelevant for mac-address based authentication. (It is passed by Chillispot to a login script. Mac-based authentication does not require a login script).
• The shared key should correspond with the secret set in your freeradius client configuration (located at /etc/raddb/clients.conf for me).
• UAM allowed is a comma-delimited list of sites unauthenticated users can access.
• Setting MACAuth to true causes Chillispot to make an authentication request against free radius when a user joins the wireless network, where User =%MAC_ADDRESS%, Pass = Password. %MAC_ADDRESS% is replaced with the user’s mac address, Pass, by default, is literally the string “Password”.
• The additional Chillispot option of macpasswd changes the default password used for mac-address authentication, in my case to “sushi”.

Configuring a Radius user account

Rad-check attributes:

• username = %MAC_ADDRESS%
• User-Password := “Password” (or the value set by macpasswd)

Rad-reply (accounting) attributes:

• Acct-Interim-Interval := 300
• Idle-Timeout := 600

The above attributes cause Chillispot to send updates about bandwidth usage to the radius server every 5 minutes. If a user has been idle for 10 minutes their session is terminated.

That’s all you need! You should have a (mostly) functioning setup at this point in time, the rest of the article is focused on web-based admin tools.

Web-based Administration

Free Radius:

• Dalo Radius allows you to create user accounts from a web-based interface for your radius server. It requires that your radius server is configured via MySQL. http://daloradius.com