RaDius

TableOfContents

* NoCatsplashpage * RadiusAndWiana

Login script
{{{

=
==================== prefix="/usr/local" exec_prefix="${prefix}" bindir="/hj"
 * 1) echo "$*" >>/tmp/cw.log

Just remove the # from the first line Then if you want the date just add it in, like so

echo "`date` $*" >>/tmp/cw.log prefix="/usr/local" exec_prefix="${prefix}" bindir="/hj"

And now you have /tmp/cw.log logging just like it is supposed to, with the additional date field

modified the cwradius1 script to log all logins to a file.

prefix="/usr/local" exec_prefix="${prefix}" bindir="/hj" !!!!!!! date=`date` echo $date >>/drv2/logins echo "username:-$1, Password:-$2,  MAC:-$3 " >>/drv2/logins !!!!!!! usage { echo "Usage: radtest user passwd radius-server[:port] nas-port-number secret [ppphint] [nasname]" >&2 exit 100 }
 * 1) echo "$*" >>/tmp/cw.log

the bit that I added in in-between the !!!!!!!!, don't include the !!!!!!!!

This writes all logins to a file called logins into the drv2 folder. From this you can see exactly who has logged in with username,password and MAC address. Once you have found what username is being used change the settings in your realm for that user to username password and Mac Address using the Mac address of the correct user.. That will stop them but if the correct user changes their wifi card then you will have to change the Mac address.

Any one out there know if there is a way of telling what mac address logged on with what username and password. Not talking about wiana. We are talking within the mesh box. I.e you have a unknown mac address that is passing a lot of traffic, but you do not know that mac address! its not one of your registered customers (hacker or some sharing there user name)is there a way of showing the username and password that it logged in with. }}}

no cat
The documentation is on the NoCatSplash site. And I sure wouldn't use Winduhs for this.

I have a client that is starting out with a mesh system but wants to use their own radius server. Currently they are using the radius that comes with windows 2000 server. When we try to do cwradius user pwd we get the following response immediately: rad_decode: Received Access-Reject packet from 192.168.1.4 with invalid signature! According to the 2000 server log, the meshbox is looking for a digital certificate. Is this correct. We are running qcode on this box. I added the address of the radius in usr/local/etc/raddb/client/servers along with the secret and still get the same response above.

Radius and Wiana
Yep, that was it. radius only local was set to no.

> At 07:10 -0500 6/3/06, clark wrote: >>I replaced a gateway AP over the weekend. This is the first time I have >>had a radius server failure. The relay nodes perform user authentication >>correctly, but my new gateway node will only authenticate owner/owner.

>>Users in the realm cannot use their given username/password. The wiana >>settings look correct: Radius local prefix is the same number that is in >>the parenthesis. Lock to realm prefix is correct. When I do a radping it >>returns DOWN. But this is also what is returned when I do a radping from >>the relay nodes which authenticate users correclty. I can do a cwradius >>with usernames and passwords from the relay nodes and it returns OK.

But >>from the gateway node it returns denied for everyone except owner/owner. If owner/owner is working, then the "radius only local" parameter is not set to yes. If it appears to be set to yes in wiana, check the equivalent parameter in /etc/wiana.settings - it is possible that the settings failed the check when they downloaded, and so are out of sync with wiana.

Trouble Shooting Radius
{{{ Radius prefix value from 2200 to 2242 """'cwradius ' will test the Radius authentication

I don't know whether its relevant, but I noticed that all my auth was going wrong since the weekend - I checked my settings, and the RADIUS prefix value had changed from 2200 to 2242, so I updated the nodes, and it works now.

> I was wondering if they are somehow out of sync? > I have a direct T1 connection to the internet. > > Also, I was looking at the cwradius script. I noticed that the script > it calls behaves differently based on whether it's cwradius1, > cwradius2, cwradius3. As a test I flipped the order that cwradius > calls these other scripts. Then cwradius returned OK and exited. When > it's running in the original form it returns DENIED followed by OK > then exits. > I was wondering if splashd/nocat treats the first response as > authoritative and then rejects the login before trying the second. If > this is the case. Is there a setting that affects this behavior?

>> If you get either an OK or DENIED back then that is the response from >> the server. The servers are checked automatically every 3 minutes and >> there have been no reported problems. Check your radius realm >> settings are correct etc and check you've got a pure ip connection to >> the internet.

>>> Could you tell me what's happen when i have got this message from my >>> meshbox? >>> Message from syslogd@meshbox at Mon Jun 14 13:03:17 2004 ... >>> meshbox kernel: STORMWARNING: IN=br0 OUT= >>> MAC=00:60:b3:6b:f1:27:00:0e:a6:2e:1d:71:08:00 SRC=192.168.191.198 >>> DST=192.168.191.1 LEN=60 TOS=0x00 PREC=0x00 TTL=1 ID=84 DF PROTO=ICMP >>> TYPE=8 CODE=0 ID=512 SEQ=2816 >>> >>> And my second question: >>> >>> I tried to put command "radping" - the answer was "DOWN", I tried to >>> verify some client's nicks and passwords with "cwradius" and the >>> answers >>> were "DENIED, DENIED, DENIED". Are Radius servers down?

Spot on! The nodes have been transferred from our setup Wiana account to one of our production meshes and the Radius local prefix was therefore incorrect.

Is the Radius local prefix: 1128 the same as the number in brackets shown for each node in wiana and the REALM name (KIRBYHILLNET ) the same as the one you want to use? If not it will cause the same problem, I know it sounds a daft question but many have been caught out by the wrong local prefix, normally after moving nodes between wiana accounts.

> MAC address is listed but I still see the splash page. I cannot login using > the username/PW entered in the realm. I just get thrown back to the splash > page. If I turn on guest access I can login as Guest. This is happening on > all 15 Meshboxes I just upgraded to dev88. > > Any ideas? > > Gareth -- > Have you checked /etc/autoaccess to see if the MAC addresses you require > are listed? > > Use > >  cat /etc/autoaccess

> I've just started deploying Dev88 as part of a new mesh network and > today upgraded the 5 nodes on our existing network from dev85. > > On all nodes I am seeing a problem with the captive portal. For users > with "Authenticate using MAC ID OR username/password pair" set, I see > the splash logon screen even though their MAC ID is recorded and allowed > them access under dev85. > > My Wiana setings are: > > Captive Portal: capture on > Wired Captive Portal: No > Portal Mode: Auth only > Portal timeout: 12 hours > Portal style: Wiana based > > Radius only local: Yes > Radius local prefix: 1128 > Lock to relam prefix: KIRBYHILLNET > > Please help if you've seen this problem before or think you know what it > might be.

The biggest issue with using a MeshAP at every location will be cost. If you are letting the users pay for the hardware - I suppose it will be a matter of whether or not that market will support it. It is possible to use recycled ATX boxes to run MeshAP (to significantly reduce costs), but as you introduce a variety of platforms into your network, you most likely will introduce a variety of issues that are not seen with the recommended mini-itx setup. Another thing that has been discussed offlist amongst some of us is node density & routing issues. One network operator on the list has a highly populated mesh that is very dense. With Wiana defaults, the mesh became "wobbly" once nodes got to where they could talk to more than 9 or 10 neighbors. The workaround was either to separate the mesh into sectors on separate freq's, or change Wiana to force the nodes to only mesh with 5 or 6 neighbors. I suspect that the problem is that once you start meshing with a high number of neighbor nodes, the routing issues become very complex and require a more powerful CPU & more RAM than what LW recommends. By setting the nodes to mesh with a limited number of neighbors, the routes will be smaller and easier to handle. Keep in mind that not only are the nodes acting as gateways & repeaters, they will be serving up users on the wired interface and wireless interfaces. The amount of RAM & CPU will limit the performance of a node.

Thanks to a couple people on the list, I finally got my radius working. I do have some questions regaurding authentication though. When I used Lucent AP's, radius was used as the authentication scheme. The way it worked was a radio tried to connect to the AP, which in turn passed the MAC of the radio to radius as the username. If the username matched, then access was granted. The password was assigned in the user file, and was the same for all users. The AP had that password stored to pass with the MAC to radius. My question is this:

Is there a way to combine the way the AP did authentication with the captive portal of meshap. The reason for this is to allow an authorized MAC to begin using the system immediately, and the user would not have to enter a username and password. Only the guest would need to do that.

My second question:

Would it make sense to use a meshap at each users location? By using the ethernet port, you could run a cat5 from the unit directly to the users computer/network. Also this would, in my opinion, help populate the network even better. Someone correct me if I am wrong in this assumption.

Here is a checklist of things you should do to ensure you radius is configured correctly:

1) Make sure that in the radcheck table, there is an entry that looks like this for the user:

id | UserName| Attribute | op | Value 1 | tjohnson | password | == | MACAddress

2) Make sure that you have enabled the PAM module that your NAS is using by uncommenting it in the radiusd.conf file.

3) Start radiusd with very verbose output so you can see more info about the login failure. That will tell you the true tale.  I don't remember the command line switch right off hand for that.

>I reset to Capture on, and now I am getting invalid login. Here's the >output from my log file: > >Wed May 26 08:10:32 2004: Info: Ready to process requests. >Wed May 26 08:12:01 2004: Auth: Login incorrect: [QX:2220::tjohnson/xxxxxxx] >(from nas 255.255.255.255/S0) >Wed May 26 08:12:01 2004: Auth: Login incorrect: >[QX:2220::tjohnson/0e044db5a4d5ada2] (from nas 255.255.255.255/S0) >Wed May 26 08:12:02 2004: Auth: Login incorrect: >[QX:2220:bogus:tjohnson/xxxxxxx] (from nas 255.255.255.255/S0) > >I'm not sure I have my users file set correctly. I've only used radius with >Lucent AP's, and all authorization was MAC based.

>>Sure, >>I had thought about it once I'd finished my accounting setup, but I >>suppose I could upload the simple setup first. >> >>There is already one document that is pretty informative here: >>http://www.locustworld.com/tracker/wiki?p=UsingOwnRadius >> >>For the question about the hardcoded "testing" secret, just change it in >>/hj/cwradius2 (I think).

>>Any chance on putting a document together on your free radius setup ? >>i.e free radius + config + wiana changes that could be uploaded to the >>wiki for people to be able to configure their own free radius servers.

>>make sure you are using wiana based splash, and you should be all set. >>I'm running the same build with freeradius. -Original

>>Thanks to Joel Smith for suggesting I move to build25dev85. I now have >>3 meshed nodes. One last thing I need to figure out, how do I send >>authentication through my radius server? Right now it is letting anyone >>in. I have it set for Auth Only, but I don't see anything in my radius >>log file for authentication. >> >>Thanks to all for the help!

Make sure you have choosen realms from wiana and node has downloaded changes. and make sure again that said MAC address downloaded into the mesh node allready. If your customer still cannot logon then check if you have choosen username + password OR MAC authentication. If you have choosen AND option, then your router need extra port settings for radius. (Dont remember which ports but you can find in wiki too)

Customers gets IP leased because splash page faces them first so node has to hand out IP anyhow.

We are using MAC only authentication with no problem on 20 node mesh with allmost 300 users. single problem we had similar to your was that we forgot adding realms to a node which that customer tried to connect.

hope this helps.

> i STILL have login issues on a fairly regular basis and often enough > for some of my customers to tell me they want to pay twice as much for > satilite dsl than to keep my service when my speed is always 3+ times as > fast. > it seems if i dont put the mac in the realm its a no go most of the > time. i dont mind putting the mac address in but sometimes i dont get > the chance like today when a customer who just purchased a brand new > computer called me and said and i quote " Come get your shit off my > property I dont want your so called service anymore"... he couldnt log > in but had been been given a dhcp lease. All my signal levels between > nodes and clients are as good or better than anyones. > i searched the wiki and found this > """'cwradius ' will test the Radius authentication  > """""" > the 3 user names and passwords are fake but the ones actually used were  > real and are in the realm that the node is locked to > they were copy and pasted from my realm manager to prevent a typo > this is what was returned > > 1.208.98.142@meshbox:~# iptables -L | grep MAC > ACCEPT     all  --  anywhere             anywhere           MAC  > 00:60:08:37:9B:A3 > ACCEPT     all  --  anywhere             anywhere           MAC  > 00:0E:7F:B6:4A:75 > ACCEPT     all  --  anywhere             anywhere           MAC  > 00:AA:00:BC:44:28 > ACCEPT     all  --  anywhere             anywhere           MAC  > 00:0B:DB:1D:17:D6 > ACCEPT     all  --  anywhere             anywhere           MAC  > 00:04:5A:7B:64:8A > ACCEPT     all  --  anywhere             anywhere           MAC  > 00:02:A5:2D:35:9D > ACCEPT     all  --  anywhere             anywhere           MAC > 00:60:97:DC:6D:09 > ACCEPT    all  --  anywhere             anywhere           MAC > 00:08:54:13:E6:8E > 1.208.98.142@meshbox:~# cwradius stupid1 stupid1 > DENIED > DENIED > radclient: no response from server > No reply > 1.208.98.142@meshbox:~# ping signon.communitywireless.org > PING signon.communitywireless.org (213.219.19.76): 56 data bytes > 64 bytes from 213.219.19.76: icmp_seq=0 ttl=238 time=142.981 ms > 64 bytes from 213.219.19.76: icmp_seq=1 ttl=238 time=140.414 ms > 64 bytes from 213.219.19.76: icmp_seq=2 ttl=238 time=150.397 ms > 64 bytes from 213.219.19.76: icmp_seq=3 ttl=238 time=140.420 ms > 64 bytes from 213.219.19.76: icmp_seq=4 ttl=238 time=150.417 ms > 64 bytes from 213.219.19.76: icmp_seq=5 ttl=238 time=140.402 ms > 64 bytes from 213.219.19.76: icmp_seq=6 ttl=238 time=140.273 ms > 64 bytes from 213.219.19.76: icmp_seq=7 ttl=238 time=150.430 ms > 64 bytes from 213.219.19.76: icmp_seq=8 ttl=238 time=140.931 ms > 64 bytes from 213.219.19.76: icmp_seq=9 ttl=238 time=140.919 ms > 64 bytes from 213.219.19.76: icmp_seq=10 ttl=238 time=140.911 ms > 64 bytes from 213.219.19.76: icmp_seq=11 ttl=238 time=140.267 ms > 64 bytes from 213.219.19.76: icmp_seq=12 ttl=238 time=150.404 ms > 64 bytes from 213.219.19.76: icmp_seq=13 ttl=238 time=150.268 ms > 64 bytes from 213.219.19.76: icmp_seq=14 ttl=238 time=150.274 ms > 64 bytes from 213.219.19.76: icmp_seq=15 ttl=238 time=150.258 ms > ^C64 bytes from 213.219.19.76: icmp_seq=16 ttl=238 time=140.252 ms > 64 bytes from 213.219.19.76: icmp_seq=17 ttl=238 time=150.253 ms > 64 bytes from 213.219.19.76: icmp_seq=18 ttl=238 time=150.269 ms > 64 bytes from 213.219.19.76: icmp_seq=19 ttl=238 time=140.227 ms > --- signon.communitywireless.org ping statistics --- > 20 packets transmitted, 20 packets received, 0% packet loss > round-trip min/avg/max/stddev = 140.227/145.048/150.430/4.811 ms > 1.208.98.142@meshbox:~# cwradius stupid 1234567 > radclient: no response from server > No reply > 1.208.98.142@meshbox:~# cat /etc/wiana.settings | grep REALM > RADIUSREALMPREFIX2:bogus > RADIUSREALMPREFIX:OHMROGER > 1.208.98.142@meshbox:~# cwradius thad happy > radclient: no response from server > No reply > 1.208.98.142@meshbox:~# cat /etc/wiana.settings | grep REALM > RADIUSREALMPREFIX2:bogus > RADIUSREALMPREFIX:OHMROGER > 1.208.98.142@meshbox:~# cwradius stupid 1234567 > DENIED > DENIED > DENIED > 1.208.98.142@meshbox:~# > > INSTALLING 3 customers and uninstalling one... at least i wont run out > of customer equipment as fast > the login issue has been ongoing since the first week the origional two > meshaps was deployed and has remained a prob as more nodes were > deployed thats been several months.. it seems to come and go for no > apparent reason.

=
}}}

[:Online management system]

[:Trouble shooting]