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 ===
=== 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 <BR>
Authentication, you want MAC+Username and Password set. <BR>
Answ: <BR>
I have a node here with dev 88 on it and it has been turned off <BR>
for a couple of weeks. I bought another laptop yesterday and clean installed <BR>
xp pro on it, then installed my senao card to test it with the wireless <BR>
node.I use auth only in wiana with mac filtering and 128 bit wep. When I <BR>
booted the node all went as planned and it logged in to wiana so I turned <BR>
on the laptop and tried to log in. xp let me know that a wireless connection <BR>
was available so I tried to connect and xp asked me for my wep key, which I <BR>
entered. 
I then opened Internet Explorer and it went straight to MSN,s <BR>
webpage and never displayed the splash page or asked me for my username and <BR>
password. It is not possible that it was stored on this laptop because it <BR>
had been formatted and installed that day and had not been on the net in <BR>
anyway until then. The only thing that was previously registered with wiana <BR>
was the senao cards mac because it had been used previously with my other <BR>
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...
 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....
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.
#echo "$*" >>/tmp/cw.log 
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 
} 
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?
#echo "$*" >>/tmp/cw.log 
prefix="/usr/local" 
exec_prefix="${prefix}" 
bindir="/hj" 
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.
Category:Sasecurity
Category:Mesh