Hi,
I take it that the firewall issue is now solved, or do you still have that issue as well?
There are a few checks that has to be in place for the kick-off function to work correct.
1.) Ensure the NAS device's type and port is correct defined in YFi hotspot Manager
I assume you are running the Coova Chilli on the same box as YFi.
If so: Go to Realms & Providers -> Nas Devices -> Choose 127.0.0.1 and select edit
This will open the edit tab for the nas device.
Select the 'Optional Info' tab.
Ensure the type is 'CoovaChilli' and port 3799
The Kick-off action looks up the NAS device where a user is connected, and depending on the nas device's type will make decisions accordingly.
If this is not configured correct, the Permanent User's Hard Cap will also not work correct.
Also ensure you start Chilli with the:
--coaport 3799 (IE add this to your startup script
switch. This will allow coova chilli to accept disconnect (POD) requests from the radius server defined in Coova. (IE 127.0.0.1)
If the above is not in place the disconnect process will not work correct.
The go login script will not work with yfi since it uses an ajax call to get the latest update usage.
I would encourage you though to try Coova or YFi's JSON login page.
Cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for the quick feedback. with respect to the firewall yes i found that the coovachill come with some default iptable rules that needs a little tweak before it can work ("https://help.ubuntu.com/community/WifiDocs/CoovaChilli"). I added the the string below to the end of the /etc/chilli/up.sh script. (for default source compile install "/usr/local/etc/chilli/up.sh")
may not have been populated the first time; run again
[ -e "/var/run/chilli.iptables" ] && sh /var/run/chilli.iptables 2>/dev/null
force-add the final rule necessary to fix routing tables
it seems the coovachilli script that comes with the source compile install is not suitable for debian like distros. i will encourage folks to use the coova-chilli_1.0.13-1_i386.deb for installation on debian and ubuntu.
with respect to the mal-function of the kick off - yes i am running coovachill on the same box as the LAMP freeradius server. (eg: HS_WANIF = eth0 and HS_LANIF =eth1). coovachill is attached to tun 10.1.0.1. so i created another nas device with ip 10.1.0.1.
Question: should i delete the new nas device i created with IP = 10.1.0.1. i noticed when i run freeradius in the foreground users are authenticated though 127.0.0.1. (e.g. was having problem authenticating users until i change the radiussecret for the default 127.0.0.1 nas device from testing123 to greatsecret.
but on the contrary when i look at the activity viewer users are connected to the the nas device with IP=10.1.0.1
my /etc/chill/config has these variables sets as follows;
I also had to add the following teak "sed -i 's/192.168.182.1/10.1.0.1/g' /etc/chilli/www/ChilliLibrary.js" and change the $port variable in "/var/www/coova_json/login.php from 3660 to 3990.
Is possible tweak the coova_json login page to be a pop-up as new window after authentication. secondly can the short cuts applied through dns "/logout" "/login" "user" etc be applied to yfi hotspot manager. if possible disable the single login page and use json all together since the simple login does not keep any window open after athenticating to track usage and logout.
i hope i am not bothering you too much. i really do appreciate your hardwork.
regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It may be that somehow that the add of that part the /etc/chilli/fucntions did
not made its way to the start-up.
The pop-up does not make use of the coa packet, but rather asks Coova directly
to disconnect the user.
The kick-off is executiong code from the YFi (FreeRADIUS) server targeting the
host where Coova is running on.
If you're into how things work, you're welcome to see the code inside:
/var/www/c2/yfi_cake/controllers/components/kicker.php
Hope this may help in tracking the problem.
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When i try to run radclient in the console, it says
echo User-Name=00-14-51-22-XX-XX | radclient -x 127.0.0.1:3799 40 secret
Sending Disconnect-Request of id 24 to 127.0.0.1 port 3799
User-Name = "00-14-51-22-XX-XX"
rad_recv: Disconnect-NAK packet from host 127.0.0.1 port 3799, id=24, length=20
so it seems to me, its chilli related.
I put the option "coanoipcheck" into the chilli config as well es into the
OPTS part into the init-sript
Same result.
Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you using MAC authentication? I see the username is a MAC addy.
It may be that Coova Requires the MAC to be separated with : instead of -
which means its a bug in the code.
The tests I've done was on Mikrotik, so it may be that.
Can you try the manual disconnect with a : separator and tell us if this does
the disconnection.
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, i dont use MAC authentication.
Coova handles the MAC seperated by "-".
I missunderstood the code in kicker.php - i thought it uses the macaddress,
not the user.
If i replace the MAC address with the user, it works.
curiously it works now from the yfi console as well...
im not quite shure what was the thing it made it.
Im going to set it up aggain and when i got the answer, ill let you know.
Thanx a lot
Anton
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, make sure that NASIP is defined in chilli configurations, HS_NASIP since the code is based on NASIP. If not defined it is not going to work. Also, small bug when MAC authentication is enabled, and we need to kick out the user using client's mac, in the code is in lower case however, radclient command does not work using lower case.
if using RADIUSDESK then
vi /usr/share/nginx/www/cake2/rd_cake/Controller/Component/KickerComponent.php
add following inline 30
$device_mac = strtoupper($device_mac);
add following lines inlines 73
//__ Direct Connected Clients __
$q_r = ClassRegistry::init('Na')->findByNasname($nas_ip);
if(empty ($q_r)) {
// IF NAS does not specified correct NASIP, then we can use NAS-Identifier
$q_r = ClassRegistry::init('Na')->findByNasname($nas_identifier);
$nas_ip = $nas_identifier;
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dirk
i managed to weave my way through coovachilli to make yfi hotspot work
unfortunately when i kick of user appilication returns kicked off but the user is still able to surf the internet.
however if the user logot by himself then he must authenticate again.
any clues will be very much appreciated.
PS: the go php login script that comes with hotcakes is a nice interface. can it be used with this new yfi hotspot manager?
kindly send me an email with your mobile number so i can call you for other discussion.
regards
Hi,
I take it that the firewall issue is now solved, or do you still have that issue as well?
There are a few checks that has to be in place for the kick-off function to work correct.
1.) Ensure the NAS device's type and port is correct defined in YFi hotspot Manager
I assume you are running the Coova Chilli on the same box as YFi.
If so: Go to Realms & Providers -> Nas Devices -> Choose 127.0.0.1 and select edit
This will open the edit tab for the nas device.
Select the 'Optional Info' tab.
Ensure the type is 'CoovaChilli' and port 3799
The Kick-off action looks up the NAS device where a user is connected, and depending on the nas device's type will make decisions accordingly.
If this is not configured correct, the Permanent User's Hard Cap will also not work correct.
Also ensure you start Chilli with the:
--coaport 3799 (IE add this to your startup script
switch. This will allow coova chilli to accept disconnect (POD) requests from the radius server defined in Coova. (IE 127.0.0.1)
If the above is not in place the disconnect process will not work correct.
The go login script will not work with yfi since it uses an ajax call to get the latest update usage.
I would encourage you though to try Coova or YFi's JSON login page.
Cheers
Dirk
thanks for the quick feedback. with respect to the firewall yes i found that the coovachill come with some default iptable rules that needs a little tweak before it can work ("https://help.ubuntu.com/community/WifiDocs/CoovaChilli"). I added the the string below to the end of the /etc/chilli/up.sh script. (for default source compile install "/usr/local/etc/chilli/up.sh")
may not have been populated the first time; run again
[ -e "/var/run/chilli.iptables" ] && sh /var/run/chilli.iptables 2>/dev/null
force-add the final rule necessary to fix routing tables
iptables -I POSTROUTING -t nat -o $HS_WANIF -j MASQUERADE
it seems the coovachilli script that comes with the source compile install is not suitable for debian like distros. i will encourage folks to use the coova-chilli_1.0.13-1_i386.deb for installation on debian and ubuntu.
with respect to the mal-function of the kick off - yes i am running coovachill on the same box as the LAMP freeradius server. (eg: HS_WANIF = eth0 and HS_LANIF =eth1). coovachill is attached to tun 10.1.0.1. so i created another nas device with ip 10.1.0.1.
Question: should i delete the new nas device i created with IP = 10.1.0.1. i noticed when i run freeradius in the foreground users are authenticated though 127.0.0.1. (e.g. was having problem authenticating users until i change the radiussecret for the default 127.0.0.1 nas device from testing123 to greatsecret.
but on the contrary when i look at the activity viewer users are connected to the the nas device with IP=10.1.0.1
my /etc/chill/config has these variables sets as follows;
HS_WANIF=eth0
HS_LANIF=eth1
HS_NETWORK=10.1.0.0
HS_NETMASK=255.255.255.0
HS_UAMLISTEN=10.1.0.1
HS_UAMPORT=3990
HS_UAMSERVER=10.1.0.1
HS_UAMHOMEPAGE=http://10.1.0.1/coova_json/splash.php
HS_UAMSERVER= http:/10.1.0.1/coova_json/hs_land.php
HS_UAMSERVICE=https://10.1.0.1/cgi-bin/uam.pl
HS_WWWDIR=/usr/local/etc/chilli/www
HS_WWWBIN=/usr/local/etc/chilli/wwwsh
==========================================
I also had to add the following teak "sed -i 's/192.168.182.1/10.1.0.1/g' /etc/chilli/www/ChilliLibrary.js" and change the $port variable in "/var/www/coova_json/login.php from 3660 to 3990.
Is possible tweak the coova_json login page to be a pop-up as new window after authentication. secondly can the short cuts applied through dns "/logout" "/login" "user" etc be applied to yfi hotspot manager. if possible disable the single login page and use json all together since the simple login does not keep any window open after athenticating to track usage and logout.
i hope i am not bothering you too much. i really do appreciate your hardwork.
regards
Hi there,
i have the same problem, the kickoff is not working.
The user dissapears from the yfi-viewer but nothing reaches the radius.
I allready checked the NAS-Setup in YFI
IP 10.1.0.1:3799, Type: CoovaChilli
I added a Rule to the Input Chain
ACCEPT tcp -- anywhere 10.1.0.1 tcp dpt:3799
I flushed it and tried without a rule.
I added coaport='3799' to /etc/chilli/functions
It works perfectly with the disconnect button in the pop-up - which obviously
shows that the coova-side is set-up correctly?!.
What am i doing wrong?
Thanx in advance
Anton
Have you got the following part in the startup script of CoovaChilli:
It may be that somehow that the add of that part the /etc/chilli/fucntions did
not made its way to the start-up.
The pop-up does not make use of the coa packet, but rather asks Coova directly
to disconnect the user.
The kick-off is executiong code from the YFi (FreeRADIUS) server targeting the
host where Coova is running on.
If you're into how things work, you're welcome to see the code inside:
/var/www/c2/yfi_cake/controllers/components/kicker.php
Hope this may help in tracking the problem.
Regards
Yes, thats in there.
The port is up
When i try to run radclient in the console, it says
so it seems to me, its chilli related.
I put the option "coanoipcheck" into the chilli config as well es into the
OPTS part into the init-sript
Same result.
Any ideas?
Yes, thats in there.
The port is up
When i try to run radclient in the console, it says
so it seems to me, its chilli related.
I put the option "coanoipcheck" into the chilli config as well es into the
OPTS part into the init-sript
Same result.
Any ideas?
Are you using MAC authentication? I see the username is a MAC addy.
It may be that Coova Requires the MAC to be separated with : instead of -
which means its a bug in the code.
The tests I've done was on Mikrotik, so it may be that.
Can you try the manual disconnect with a : separator and tell us if this does
the disconnection.
Regards
No, i dont use MAC authentication.
Coova handles the MAC seperated by "-".
I missunderstood the code in kicker.php - i thought it uses the macaddress,
not the user.
If i replace the MAC address with the user, it works.
curiously it works now from the yfi console as well...
im not quite shure what was the thing it made it.
Im going to set it up aggain and when i got the answer, ill let you know.
Thanx a lot
Anton
Cool!
Glad you're making progress.
Also, make sure that NASIP is defined in chilli configurations, HS_NASIP since the code is based on NASIP. If not defined it is not going to work. Also, small bug when MAC authentication is enabled, and we need to kick out the user using client's mac, in the code is in lower case however, radclient command does not work using lower case.
if using RADIUSDESK then
vi /usr/share/nginx/www/cake2/rd_cake/Controller/Component/KickerComponent.php
add following inline 30
$device_mac = strtoupper($device_mac);
add following lines inlines 73
//__ Direct Connected Clients __
$q_r = ClassRegistry::init('Na')->findByNasname($nas_ip);
if(empty ($q_r)) {
// IF NAS does not specified correct NASIP, then we can use NAS-Identifier
$q_r = ClassRegistry::init('Na')->findByNasname($nas_identifier);
$nas_ip = $nas_identifier;
}