Hi,
I dont know why you say you dont get Called-Station-ID *before* the user is
authenticated/authorized. It comes as part of the Access-Request from the
NAS.
Here is how we use Called-Station-Id in the authorize section of our
sites-enabled/default file
Huntgroup-Name := %{sql:SELECT `groupname`
Hi,
Thanks for the reply.
My hosts are all dynamic so am using dynamic-clients - don't think that
affects things though does it?
If I put the following in my authorize section (to keep things simply), my
query has a null value:
Huntgroup-Name := %{sql:SELECT `groupname` FROM `radhuntgroup`
On 10/23/2011 09:23 PM, Andrej wrote:
Hi,
Not sure whether this is the right list to be writing to (the website
suggests it is), and I'm not following the suggested method (patch
documentation, and post it here if I don't want to use git), but I
wouldn't really know which document to patch with
Ok, Thanks.
We have started a new test today.
In file attached, i give the results of radiusd -X | tee log, on the both
authentication servers.
We see some errors but don't understand as well.
Date: Fri, 14 Oct 2011 16:36:19 -0700
From: ml-node+s1045715n4904200...@n5.nabble.com
To:
On Mon, Oct 24, 2011 at 4:40 PM, siguillaume gsi...@live.fr wrote:
Ok, Thanks.
We have started a new test today.
In file attached, i give the results of radiusd -X | tee log, on the both
authentication servers.
I explicitly wrote in my last reply
Then you posted log of radiusd -X starting
Hi,
How do I stop logging in radpostauth table? Is commenting out the query that
inserts to radpostauth a correct way of doing that?
thanks!
det
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 24 Oct 2011, at 12:03, Det Det wrote:
Hi,
How do I stop logging in radpostauth table? Is commenting out the query that
inserts to radpostauth a correct way of doing that?
No... comment out the SQL call in the post-auth section.
-Arran
Arran Cudbard-Bell
a.cudba...@freeradius.org
I've upgraded FreeRadius to 2.1.10 and Samba to 3.5.6.
I've got right through (again) to the final Configuring FreeRADIUS to use
ntlm_auth for MS-CHAP stage but the command 'eapol_test -c
peap-mschapv2-cert-ntlm_auth.conf -s testing123' fails.
The 'radiusd -X' output finishes with :
WARNING:
Ciao.
We're also facing the same issue, but on a Windows box. We did a quick test
using a rather old FR version (1.1.7), on the same PC and using the same
certificates, and we get a successful result using eapol_test. We've also
followed the steps available in
Can someone show me how to load FR on boot in Ubuntu?
David
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Mon, Oct 24, 2011 at 9:13 AM, David Peterson
dav...@wirelessconnections.net wrote:
Can someone show me how to load FR on boot in Ubuntu?
David
Not 100% sure off the top of my head, as I don't have an Ubuntu box in
front of me, but I expect you'd have to provide an Upstart script [1].
Hello i have a similar Problem, my radiusd-X output looks like
# Executing section authorize from file
/etc/freeradius/sites-enabled/inner-tunnel
+- entering group authorize {...}
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = cgm\tbo, looking up realm NULL
[suffix]
Thomas Brighton wrote:
Hello i have a similar Problem, my radiusd-X output looks like
# Executing section authorize from file
...
+- entering group authenticate {...}
[eap] Got NOTIFICATION, Ignoring the packet
Well, that's stupid. I don't recall seeing that before. EAP
notifications
Sergio NNX wrote:
Ciao.
We're also facing the same issue, but on a Windows box. We did a quick
test using a rather old FR version (1.1.7), on the same PC and using the
same certificates, and we get a successful result using eapol_test.
Please send the debug output for 1.1.7 the version
Thanks for the help, that did the trick. I found the rc.radiusd file and
added to rc.local /etc/sbin/rc.radiusd start
If that's not the correct method someone please let me know but it seems to
work.
David
-Original Message-
From:
Martin Ubank wrote:
The following lines from the output of the 'eapol_test' command seem to
indicate a problem with the root certificate.:
OpenSSL: tls_connection_ca_cert - Failed to load root certificates
error::lib(0):func(0):reason(0)
Fix that and it should work.
OpenSSL:
On 24 Oct 2011, at 16:19, Alan DeKok wrote:
Thomas Brighton wrote:
Hello i have a similar Problem, my radiusd-X output looks like
# Executing section authorize from file
...
+- entering group authenticate {...}
[eap] Got NOTIFICATION, Ignoring the packet
Well, that's stupid. I don't
On Mon, Oct 24, 2011 at 10:22 AM, David Peterson
dav...@wirelessconnections.net wrote:
Thanks for the help, that did the trick. I found the rc.radiusd file and
added to rc.local /etc/sbin/rc.radiusd start
If that's not the correct method someone please let me know but it seems to
work.
As
Thanks for your reply.
The following lines from the output of the 'eapol_test' command seem
to indicate a problem with the root certificate.:
OpenSSL: tls_connection_ca_cert - Failed to load root certificates
error::lib(0):func(0):reason(0)
Fix that and it should work.
On Mon, Oct 24, 2011 at 9:22 PM, David Peterson
dav...@wirelessconnections.net wrote:
Thanks for the help, that did the trick. I found the rc.radiusd file and
added to rc.local /etc/sbin/rc.radiusd start
Where the heck does /etc/sbin/rc.radiusd comes from? Which Ubuntu and
FR version are you
Martin Ubank wrote:
Understood. By enclosing my .cnf files, I was hoping someone on the list
might point out what I'd done wrong.
Honestly... I don't read that stuff. It's OpenSSL magic that I try to
avoid.
Can you supply the content of the .cnf files you used (obviously with site
On 24 Oct 2011, at 16:19, Alan DeKok wrote:
Thomas Brighton wrote:
Hello i have a similar Problem, my radiusd-X output looks like
# Executing section authorize from file
...
+- entering group authenticate {...}
[eap] Got NOTIFICATION, Ignoring the packet
Well, that's stupid. I don't
On 24 October 2011 21:50, Phil Mayers p.may...@imperial.ac.uk wrote:
Hi Phil,
Thanks for taking the time to respond.
Which location?
/usr/lib64/postgresql
/usr/include/postgresql
What OS are you on?
Slackware64 13.1 - postgres 9.1.1 built and installed from source.
Plain ./configure
On 24/10/11 17:17, Andrej wrote:
On 24 October 2011 21:50, Phil Mayersp.may...@imperial.ac.uk wrote:
Hi Phil,
Thanks for taking the time to respond.
Which location?
/usr/lib64/postgresql
/usr/include/postgresql
Hmm.
What does:
pg_config --includedir --libdir
...say for you?
On 25 October 2011 06:24, Phil Mayers p.may...@imperial.ac.uk wrote:
/usr/lib64/postgresql
/usr/include/postgresql
Hmm.
What does:
pg_config --includedir --libdir
pg_config --includedir --l
/usr/include
/usr/lib64
Slackware64 13.1 - postgres 9.1.1 built and installed from source.
If I put in default authorize section, the called-station-id is present.
What I just don't understand is why it doesn't work in dynamic hosts and also
why default is loaded at all?
The called-station-id is certainly present in the request:
rad_recv: Access-Request packet from host 94.x.x.x
Andrej wrote:
Plain ./configure works fine for me on RHEL5 and Fedora.
That's good for you but kind of besides the point.. :} I *did* get it
installed; what I'm saying is that the build process/build requirements
w/ an RDBMS back-end aren't really documented.
$ ./configure
$ make
$ make
On 10/24/2011 06:51 PM, Andrej wrote:
pg_config --includedir --l
/usr/include
/usr/lib64
This pg_config is the one from the source you built, yes? There isn't
another copy of pg_config / the headers lying around?
Because with those paths, the build really ought to have just worked.
Weird.
On 10/24/2011 07:02 PM, JennyBlunt wrote:
If I put in default authorize section, the called-station-id is present.
What I just don't understand is why it doesn't work in dynamic hosts and
As per the comments in the sample dynamic-clients:
# The request that is processed through this section
OH! I've looked too many lines of code over the last week.
I have no idea how to patch but will investigate. Was thinking we might have to
use nas-id instead.
The ultimate intention was to use the mac address of the nas and a nas specific
shared secret.
In your opinion, are there better ways
On Tue, Oct 25, 2011 at 12:51 AM, Andrej andrej.gro...@gmail.com wrote:
On 25 October 2011 06:24, Phil Mayers p.may...@imperial.ac.uk wrote:
/usr/lib64/postgresql
/usr/include/postgresql
Hmm.
What does:
pg_config --includedir --libdir
pg_config --includedir --l
/usr/include
/usr/lib64
On Tue, Oct 25, 2011 at 2:06 AM, Jennyanydots Napoleon Shoehorn
jennyshoeh...@me.com wrote:
In your opinion, are there better ways to deal with dynamic clients?
Use Packet-Src-IP-Address
--
Fajar
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 10/24/2011 08:06 PM, Jennyanydots Napoleon Shoehorn wrote:
The ultimate intention was to use the mac address of the nas and a nas
specific shared secret.
Do you really need a per-NAS secret?
In your opinion, are there better ways to deal with dynamic clients?
It depends. Can you
We started this conversation because we can't use the packet-src-ip address.
Hence the requirement for dynamic hosts?
On 24 Oct 2011, at 20:28, Fajar A. Nugraha wrote:
On Tue, Oct 25, 2011 at 2:06 AM, Jennyanydots Napoleon Shoehorn
jennyshoeh...@me.com wrote:
In your opinion, are there
Hello Phil
I guess we don't need a per NAS secret but thought it might help block any
customers we don't need.
We have a load of wifi hotspots on dynamic ips. We know all their nas ids, but
not their ip addresses. That's the main reason for it. I guess the other way
would be to use hunt
Jennyanydots Napoleon Shoehorn wrote:
We started this conversation because we can't use the packet-src-ip
address. Hence the requirement for dynamic hosts?
RADIUS works by using the source IP of the packet.
If you want something else, set up SSH or SSL tunnels, and forward the
RADIUS
On 10/24/2011 08:45 PM, JennyBlunt wrote:
Hello Phil
I guess we don't need a per NAS secret but thought it might help block
any customers we don't need.
We have a load of wifi hotspots on dynamic ips. We know all their nas
Ok, that's about the hardest case I'm afraid.
If you have the option
This is very interesting, really appreciate the replies.
Other than using a VPN, how do other wifi providers actually operate securely?
J
On 24 Oct 2011, at 21:04, Phil Mayers wrote:
On 10/24/2011 08:45 PM, JennyBlunt wrote:
Hello Phil
I guess we don't need a per NAS secret but thought it
On 24 Oct 2011, at 23:09, Jennyanydots Napoleon Shoehorn wrote:
This is very interesting, really appreciate the replies.
Other than using a VPN, how do other wifi providers actually operate securely?
They don't :)
It's either VPN or same shared secret. If your equipment is running
Fantastic news ;) !!
We use some ddwrt, openwrt routers, coovap (ubuntu) and higher end Meraki /
Ruckus stuff. Might be a pain to configure each.
What about the idea of a common shared secret and then assigning a 'network' or
huntgroup to each user. We could then block end users authenticating
Hi,
added to rc.local /etc/sbin/rc.radiusd start
Where the heck does /etc/sbin/rc.radiusd comes from? Which Ubuntu and
FR version are you using?
Current FR packages for Ubuntu uses /etc/init.d/freeradius, although
rc.radiusd is still available in /usr/share/doc/freeradius/examples.
41 matches
Mail list logo