MacMesh

back to http://scratchpad.wikia.com/wiki/Sasecurity TableOfContents

Show MAC of every meshbox
* MacNotes1 * MacAndpassword * AddingMacToRealm * Cb3ApAndMac * MacRouterandrealm * AdHoc

MAC changing
He was smart enough to spoof but not before I grabbed his and his mates MAC ID's. The ' attack ' is still in progress and Im up to about 250 seperate SSID's with Free Access which is the SSID I use. Only one AP is ever active and every minute the MAC address changes alpha numerically. Are you sure it isn't someone accidentally going into ad-hoc mode instead of managed? In ad-hoc mode, the MAC address changes frequently...

Cloning the MAC
I found that if we DID NOT clone the MAC - the CB-3 will pass everything through under it's MAC. Your ARP table will show all of the devices behind the CB- pulling IP's, but it all comes from the MAC of the CB-3. Traffic gets shaped by this MAC as well, which is nice. I have to have auto-MAC on clients that have VoIP, because if the portal times out, they have no phone service! Anyhow, that seemed to work the best for me. I found that dev87 handled all of this better for some reason than dev76, but I have my entire mesh back on dev76 because the routing is so stable. I am trying to keep a user logged in by using mac or password pair authentication wiana based captive portal.

the user connects with a CB3 delux. the other cb3 had a clone mac setting that seemed to help. I have entered both the mac of the router (netgear WGR614) as well as the MAC of the CB3 (2 user accounts) and still the user is presented with the splash screen. Any suggestions are greatly appreciated! We have to use the MAC of the CB-3 for MAC auth. /var/state/dhcp/dhcpd.leases will show the MAC of the ethernet adapter, as this is actually the device that the ip is given to. However, if you look in the ARP tables (arp -n), you will see that the ip that it's associating to the MAC address is the MAC of the CB-3. You can clone the MAC of the CB-3 to the MAC of the device behind it, but we've found that just setting Wiana RADIUS to use the MAC of the CB-3 works best.

> I've been using some CB3s as client devices, and the MAC > authentication no longer seems to work, although the DHCP address > allocation shows the correct end user MAC address. > > My guess is that the CB3 is actually the MAC address used for the > authentication - is there any way to change this behaviour? What other > workarounds have people used?

ZYXEL issues
[:Zyxel configuration]

MAC login
Check in the realm that the user is not set to MAC Only for Authentication, you want MAC+Username and Password set. Subject: [MeshAPuser] login restriction not working I have a node here with dev 88 on it and it has been turned off for a couple of weeks. I bought another laptop yesterday and clean installed xp pro on it, then installed my senao card to test it with the wireless node.

I use auth only in wiana with mac filtering and 128 bit wep. When I booted the node all went as planned and it logged in to wiana so I turned on the laptop        and tried to log in. xp let me know that a wireless connection was available        so I tried to connect and xp asked me for my wep key, which I entered.

I then opened Internet Explorer and it went straight to MSN,s webpage and never displayed the splash page or asked me for my username and password. It is not possible that it was stored on this laptop because it had been formatted and installed that day and had not been on the net in anyway until then. The only thing that was previously registered with wiana was the senao cards mac because it had been used previously with my other laptop.

That was nearly 24 hours ago and I just booted it up again and it went straight on to net without splash page again. I have checked wiana again and found that captive portal is on and all the realm setting are set as they were before when the splash page was working. Locked to my realm and radius only local step to yes. Is this a bug in dev 88

CLIENT devices
{{{ It seams to be a problem with some client devices, But this would not be an issue if the mac-auth worked on the mac address that is passed to the DHCP table. We trust Senao to do the job of client connect and small AP backhaul links, also this is a major problem when we feed a shared office block (i.e. via switch then wired clients) we need a CPE that is very close to 95% up pheenet and d-link don't seam to work for us. would be nice to have a fix in the build without having to worry about the mac-auth being restricted to certain wireless clients.

Ok before I start this one!! only creative answer please!! we have been meshing for a long time and know how the system works. This is the situation, we have nodes all over the place, but needed to cover a small area, so a node was not cost effective, we already have a massive stock of Senao 2611CB3+', so we configured one to be a client of the local mesh node and the other to be a local AP.

>The problem we are getting is the senao in client mode does not show the >customers MAC address to the radio side of the mesh node, yet the customers MAC address shows on the DHCP list on the node, so why is it that when we set the customers account to mac-auth, they always need to login via the splash screen, Jon can you shed some light on this, or tweak the build please. We need to give mac-auth for customers that are using voip only viaan ATA.

Hi Adrian, it seems to be a feature (or a bug) of a few of the client wireless bridges to not pass the mac of the client, yet pass it OK on a DHCP request. I think it uses the mac of the Senao bridge on all IP frames apart from DHCP. The same thing happens on a Linksys WET 11. There is a setting on the later firmware for the WET11 to set mac address cloning, this may then pass the clients mac through on all IP frames TCP UDP DHCP etc. I am not sure if the Senao client bridges have the same facility as I don't have one to check.

=
===================== If what you are saying is true, I'm going to take a wild stab and guess that DHCP discovery packets do include the MAC address of the requesting client so that when the reply packet is sent back, the Senao will know where to direct the broadcast reply packet. After that, MAC address isn't necessary for end to end IP communications as far as the Senao is concerned.

Sniff some packets and see what's coming off the Senao. If the MAC is being stripped post-DHCP reply and replaced uniformly with that of the Senao, then the problem cannot be fixed on the mesh side unless I am missing something. You will probably have to replace the Senao with something that preserves MAC per IP session to fix it.

=
===================================== have you considered using a Linksys WRT54G as your client bridge? If you update the firmware to Sveasoft, you can set it in Client-bridged mode which will keep the original MAC address intact provided you are not doing any NAT with the CB3 AP. If I remember correctly, the Satori release does Client-bridged mode whereas the Alchemy release does Client-routed and you will loose the MAC's of your clients. }}}

Updateing of MAC address
This used to happen with billing software which adds the mac addresss, but does set the flag that tells the mesh node that there are new mac addresses to be downloaded. Whether this is still the case, I'm not sure, but it could be your issue. The Mac addresses will be updated on the node if you click update in realm manager.

I'm not exactly following you on this - what auto script are you talking about? I have over 200 users on our network, but everything is   adding just fine. When we add a new mac to the realm, say an outdoor receiver that is being installed, the local database gets updated when the node checks into Wiana. But from the sounds of things - you have a   script that is doing it before?

Sorry for not following you - I guess the heat has my brain frazzled as   well. It's going to be 105 to 106 Fahrenheit in the shade today (that's   about 41 Celsius). I've lived here all my life and you never get used to it. I suppose it's genetics...

> Hi all... >   > Sorry struggling with the sun in the UK. Not used to this! Brain > frazzled!! > We have a prob which seems to be surfacing on the free script... am I   > imagining it. We now have over 250 user macs on our node database at   > wiana. > Can that overload system as macs not being added to node database. > They add > at wiana fine but not to node database. >   > Our auto script adds and removes users fine at wiana... but now will > not do   > an auto refresh of wiana list to send to node data base.... when we   > use for > example iptables -n -L | grep AB:CD:EF:AB:12:34  its not found on node > until we actually go into wiana and do a push on the update button at   > wiana. > Once we do a physical push of update button and a remotemanagement user > connects! >   > This is a pain as its stopped us being able to auto add users.... >   > This was never necessary earlier.... Can anyone illuminate me???

BLOCK BY MAC
1. Use following patch before dev 106 " alwaysblockby mac" 2.In wiana put "MAC" of client device or AP in "always block nodes" This will prevent it from associating

Also added with this release is support for the Zcomax high power > pcmcia card, some potential lockup workarounds and the inclusion of the previously released "always block by mac" patch.

How does the "always block by mac" patch work?

On the fly, you can issue the command BarMac xx:xx:xx:xx:xx:xx 1. SSH into the node 2. Command: "getandverify alwaysblockbymac" 3. In wiana put "MAC" of client device or AP in "always block nodes" This will prevent it from associating

MAC+Username and Password set in Realm manager
Check in the realm that the user is not set to MAC Only for     Authentication, you want MAC+Username and Password set.  Answ:   

I have a node here with dev 88 on it and it has been turned off   for a couple of weeks. I bought another laptop yesterday and clean installed   xp pro on it, then installed my senao card to test it with the wireless   node.I use auth only in wiana with mac filtering and 128 bit wep. When I   booted the node all went as planned and it logged in to wiana so I turned   on the laptop and tried to log in. xp let me know that a wireless connection   was available so I tried to connect and xp asked me for my wep key, which I  entered.

I then opened Internet Explorer and it went straight to MSN,s   webpage and never displayed the splash page or asked me for my username and  password. It is not possible that it was stored on this laptop because it   had been formatted and installed that day and had not been on the net in  anyway until then. The only thing that was previously registered with wiana   was the senao cards mac because it had been used previously with my other   laptop.

That was nearly 24 hours ago and I just booted it up again and it went <BR> straight on to net without splash page again. I have checked wiana again and  <BR> found that captive portal is on and all the realm setting are set as they  <BR> were before when the splash page was working. Locked to my realm and radius  <BR> only local set to yes. Is this a bug in dev 88  <BR>

How many users can MeshAP handle?
I'm not exactly following you on this - what auto script are you talking about? I have over 200 users on our network, but everything is adding just fine. When we add a new mac to the realm, say an outdoor receiver that is being installed, the local database gets updated when the node checks into Wiana. But from the sounds of things - you have a script that is doing it before?

Sorry for not following you - I guess the heat has my brain frazzled as well. It's going to be 105 to 106 Fahrenheit in the shade today (that's about 41 Celsius). I've lived here all my life and you never get used to it. I suppose it's genetics...

There was a bug with this quite some time ago. Even if you used the Realm API to add the user to Wiana, it would not get queued for download to the nodes and you had to do a dummy update via wiana.org. We worked extensively with LW on this and it *was* fixed over a year ago. However, with over a thousand users on one of our networks, we are aware that there is a huge delay in getting all those MACs onto the node, into /etc/autoaccess and then into iptables. 10-15mins is not uncommon.

MAC username and password
Ques: 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.

ANSW: I have 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. If you need anymore help please feel free to email me. Regards Andy Wireless Internet Via Croft Wireless www.croftwireless.co.uk

ANSW2: Maybe I am missing something, but isn't the logging already there?

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

MAC phone authentication
Check that the phone's MAC is being auto-authenticated... else it will not pass anything through. I've run into this before and that was my problem.

I have setup a new outdoor box in a remote location for a VoIP wifi system. The phone sees the box and picks up an ip and therefore registers fine.

I for some reason can not dial in or out which is puzzling as when testing in my office (as a repeater) the phone was working fine.

The only parameters I have changed is the ‘Lock to gateway’ setting from my gateway node to ‘any’. However, when I attempt to change it to ‘any’ wiana does not change and it is reverted  back to a blank field. I am running build25dev88 and was wondering if this is a bug in this build and what needs to be done to rectify the issue.