Re: No Aoth Type problem again
Andy An wrote:
Hi Ivan:
The password is in the ldap server as one of attributes binded to the
user (userPassword: {CRYPT}something).
...
rlm_ldap: performing search in ou=People,dc=eciad,dc=ca, with filter
(uid=andyan)
...
WARNING: No known good password was found in LDAP. Are you sure that
the user is configured correctly?
The debug output disagrees with you.
There is no known good password available.
Again, it helps to READ the debug output yourself. The warning
messages are clear, and are written in simple English.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server (DHCPFlags feature)
EvilEzh wrote: I use relays (because i want to use option 82 ... not tested yet) ... so replay to relay is unicast. And if i want relay to broadcast replay message, i need to update broadcast flag. So after relay receive message it will broadcast to client (i hope so). Ah, OK. I've added the ability to update the flags via the flags attribute. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Dependencies of Freeradius 2.0.5
Hi, Where can I check wether postgresql support is compiled in or not?? try configuring postgres in your FR config - if, when you run FR with full debug (radiusd -X) you get to see lots of lovely postgres stuff - then its got support built in. if you compiled the thing yourself, then simply check the configure output - lots of WARNINGs for things it couldnt compile in alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: DHCP and dynamic ip allocation from a pool
Evgeniy Kozhuhovskiy wrote: Does anybody already implemented dynamic allocation of ips from pool? I don't think so. In fact, main problem in native rlm_sql_ippool is that freeing of ip is done via accounting section - and there is no analog of Stop packet in dhcp (but it can be simulated, using Lease-Time) Yes. There is some work that needs to be done in order to integrate DHCP into the SQL IP pools. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: No Aoth Type problem again
The password is in the ldap server as one of attributes binded to the
user (userPassword: {CRYPT}something).
I posted the debugging info here and thanks a lot for your help!
1. crypt and mschap don't mix:
http://deployingradius.com/documents/protocols/compatibility.html
2. Even the encrypted one is not there:
rlm_ldap: performing search in ou=People,dc=eciad,dc=ca, with filter
(uid=andyan)
rlm_ldap: looking for check items in directory...
rlm_ldap: looking for reply items in directory...
WARNING: No known good password was found in LDAP. Are you sure that
the user is configured correctly?
Ivan Kalik
Kalik Informatika ISP
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: DHCP and dynamic ip allocation from a pool
Alan DeKok wrote: In fact, main problem in native rlm_sql_ippool is that freeing of ip is done via accounting section - and there is no analog of Stop packet in dhcp (but it can be simulated, using Lease-Time) Yes. There is some work that needs to be done in order to integrate DHCP into the SQL IP pools. Keep us informed :-) -- With best regards, Evgeniy Kozhuhovskiy, Leader of Services team, Minsk State Phony Network, RUE Beltelecom. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: help EAP-TNC
Fernando wrote: ok, I have another question, is TNC_PATH has a default path to libTNCS.so but i can't find libTNCS.so exists? FreeRADIUS doesn't include library binaries for OpenSSL, PostgreSQL, MySQL, LDAP, or TNC. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: DHCP and dynamic ip allocation from a pool
Evgeniy Kozhuhovskiy wrote: Keep us informed :-) As always, patches are welcome. It's easy for me to do 1-2 line fixes. Re-writing the SQL IPPool module to handle DHCP is not a priority, and will not be a priority for a long time. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: DHCP and dynamic ip allocation from a pool
Alan DeKok wrote: Evgeniy Kozhuhovskiy wrote: Keep us informed :-) As always, patches are welcome. In fact, i'm thinking about it. I'll try :) It's easy for me to do 1-2 line fixes. Re-writing the SQL IPPool module to handle DHCP is not a priority, and will not be a priority for a long time. -- With best regards, Evgeniy Kozhuhovskiy, Leader of Services team, Minsk State Phony Network, RUE Beltelecom. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server (DHCPFlags feature)
Ah, OK. I've added the ability to update the flags via the flags attribute. Just checked out from cvs .. and got compile error: creating .libs/radiusdS.c (cd .libs gcc -g -O2 -c -fno-builtin radiusdS.c) rm -f .libs/radiusdS.c .libs/radiusd.nm .libs/radiusd.nmS .libs/radiusd.nmT gcc .libs/radiusdS.o -o .libs/radiusd .libs/acct.o .libs/auth.o .libs/client.o .libs/conffile.o .libs/crypt.o .libs/exec.o .libs/files.o .libs/listen.o .libs/log.o .libs/mainconfig.o .libs/modules.o .libs/modcall.o .libs/radiusd.o .libs/radius_snmp.o .libs/session.o .libs/smux.o .libs/threads.o .libs/util.o .libs/valuepair.o .libs/version.o .libs/xlat.o .libs/event.o .libs/realms.o .libs/evaluate.o .libs/vmps.o .libs/detail.o -Wl,--export-dynamic /root/freeradius/radiusd/src/lib/.libs/libfreeradius-radius.so -lnsl -lresolv -lpthread /usr/lib64/libsnmp.so -lcrypt /usr/lib64/libltdl.so -ldl -lssl -lcrypto .libs/listen.o: In function `rad_status_server': /root/freeradius/radiusd/src/main/listen.c:309: undefined reference to `request_stats_reply' .libs/listen.o: In function `acct_socket_recv': /root/freeradius/radiusd/src/main/listen.c:725: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:728: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:725: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:728: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:778: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:778: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:792: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:801: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:792: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:801: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:735: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:735: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:767: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:767: undefined reference to `radius_acct_stats' .libs/listen.o: In function `auth_socket_recv': /root/freeradius/radiusd/src/main/listen.c:675: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:623: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:626: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:623: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:626: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:690: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:696: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:690: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:696: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:633: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:633: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/listen.c:665: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/listen.c:665: undefined reference to `radius_acct_stats' .libs/radius_snmp.o: In function `radAuthServ': /root/freeradius/radiusd/src/main/radius_snmp.c:437: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/radius_snmp.c:441: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/radius_snmp.c:445: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/radius_snmp.c:449: undefined reference to `radius_auth_stats' /root/freeradius/radiusd/src/main/radius_snmp.c:453: undefined reference to `radius_auth_stats' .libs/radius_snmp.o:/root/freeradius/radiusd/src/main/radius_snmp.c:457: more undefined references to `radius_auth_stats' follow .libs/radius_snmp.o: In function `radAccServ': /root/freeradius/radiusd/src/main/radius_snmp.c:292: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/radius_snmp.c:296: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/radius_snmp.c:300: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/radius_snmp.c:304: undefined reference to `radius_acct_stats' /root/freeradius/radiusd/src/main/radius_snmp.c:308: undefined reference to `radius_acct_stats' .libs/radius_snmp.o:/root/freeradius/radiusd/src/main/radius_snmp.c:312: more undefined references to `radius_acct_stats' follow .libs/event.o: In function `wait_a_bit':
Re: dhcp server (DHCPFlags feature)
Haralds Ulmanis wrote: Just checked out from cvs .. and got compile error: ... /root/freeradius/radiusd/src/main/listen.c:309: undefined reference to `request_stats_reply' Edit src/main/Makefile, and add stats.c to the SERVER_SRCS line. It's in Makefile.in, but you probably didn't re-run configure, and likely don't want to do that, either. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: No Aoth Type problem again
Jelle Langbroek wrote: Hi, I know it's plain English but I still can't figure out where the warning is comming from and what I have to change. It finds the password, but still gives the auth(failure): You're running 2.0.4, and you need to install raddb/sites-enabled/inner-tunnel. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: No Aoth Type problem again
What version is this? It looks like you are missing the inner-tunnel
virtual server config file. You should copy it from the download
dictionary to raddb/sites-enabled/.
Ivan Kalik
Kalik Informatika ISP
Dana 20/6/2008, Jelle Langbroek [EMAIL PROTECTED] piše:
Hi,
I know it's plain English but I still can't figure out where the warning is
comming from and what I have to change. It finds the password, but still
gives the auth(failure):
auth: No authenticate method (Auth-Type) configuration found for the
request: Rejecting the user
auth: Failed to validate the user.
I'm using the default config-files with PEAP auth. Can somebody give me a
hint in the right direction? Where/what config file should I look in and
what to edit? THANKS!
Here are my logs...
Listening on authentication address 172.16.27.103 port 1812
Ready to process requests.
rad_recv: Access-Request packet from host 172.16.27.37 port 3072, id=0,
length=141
User-Name = userX
NAS-IP-Address = 172.16.27.37
Called-Station-Id = 001c1066a106
Calling-Station-Id = 001cdf77bb4d
NAS-Identifier = 001c1066a106
NAS-Port = 1
Framed-MTU = 1400
NAS-Port-Type = Wireless-802.11
EAP-Message = 0x0213016a656c6c656c616e6762726f656b
Message-Authenticator = 0x933439cddca44559a4ee3c2b327aaac5
+- entering group authorize
++[preprocess] returns ok
expand:
/usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -
/usr/local/var/log/radius/radacct/172.16.27.37/auth-detail-20080620
rlm_detail:
/usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d
expands to /usr/local/var/log/radius/radacct/
172.16.27.37/auth-detail-20080620
expand: %t - Fri Jun 20 15:25:59 2008
++[auth_log] returns ok
++[chap] returns noop
++[mschap] returns noop
rlm_realm: No '@' in User-Name = userX, looking up realm NULL
rlm_realm: No such realm NULL
++[suffix] returns noop
rlm_eap: EAP packet type response id 0 length 19
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
expand: %{User-Name} - userX
rlm_sql (sql): sql_set_user escaped user -- 'userX'
rlm_sql (sql): Reserving sql socket id: 4
expand: SELECT ownerid as id, username, 'Cleartext-Password' as
attribute, passwd as value, ':=' as op FROM nodes WHERE
username = '%{SQL-User-Name}' ORDER BY id - SELECT ownerid as id,
username, 'Cleartext-Password' as attribute, passwd as value, ':=' as
op FROM nodes WHERE username = 'userX' ORDER
BY id
rlm_sql (sql): User found in radcheck table
expand: SELECT ownerid as id, username, 'Cleartext-Password' as
attribute, passwd as value, ':=' as op FROM nodes WHERE
username = '%{SQL-User-Name}' ORDER BY id - SELECT ownerid as id,
username, 'Cleartext-Password' as attribute, passwd as value, ':=' as
op FROM nodes WHERE username = 'userX' ORDER
BY id
expand: SELECT 'dynamic' as groupname FROM
customers WHERE name = '%{SQL-User-Name}' ORDER BY id -
SELECT 'dynamic' as groupname FROM customers WHERE name
= 'userX' ORDER BY id
rlm_sql (sql): Released sql socket id: 4
++[sql] returns ok
++[expiration] returns noop
++[logintime] returns noop
rlm_pap: Found existing Auth-Type, not changing it.
++[pap] returns noop
rad_check_password: Found Auth-Type EAP
auth: type EAP
+- entering group authenticate
rlm_eap: EAP Identity
rlm_eap: processing type tls
rlm_eap_tls: Initiate
rlm_eap_tls: Start returned 1
++[eap] returns handled
Sending Access-Challenge of id 0 to 172.16.27.37 port 3072
EAP-Message = 0x010100061920
Message-Authenticator = 0x
State = 0x9baa2d299bab34161e655ea3ece36f0c
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host 172.16.27.37 port 3072, id=0,
length=233
Cleaning up request 0 ID 0 with timestamp +41
User-Name = userX
NAS-IP-Address = 172.16.27.37
Called-Station-Id = 001c1066a106
Calling-Station-Id = 001cdf77bb4d
NAS-Identifier = 001c1066a106
NAS-Port = 1
Framed-MTU = 1400
State = 0x9baa2d299bab34161e655ea3ece36f0c
NAS-Port-Type = Wireless-802.11
EAP-Message =
0x0201005d19001603010052014e0301485baf3e8e15e57593e3e1819134ab3ad55c2a65dbdd6278dadce70ffee5409a2600390038003500160013000a00330032002f0005000400150012000900140011000800060003020100
Message-Authenticator = 0xda28b5bb86c975ef4fd3c5bf45e4bba5
+- entering group authorize
++[preprocess] returns ok
expand:
/usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -
/usr/local/var/log/radius/radacct/172.16.27.37/auth-detail-20080620
rlm_detail:
/usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m
Re: Goodbye SNMP, hello statistics.
hi, this is very cool - i guess it would be handy to let remote authorised machiens query it (trivial to have one central stats store then) but still. I hope to see a lot of useful tools/widgets using this. bit of RRDTool is calling. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Goodbye SNMP, hello statistics.
[EMAIL PROTECTED] wrote: this is very cool - i guess it would be handy to let remote authorised machiens query it Yes. But... it is a potential security issue to expose those statistics to anyone who asks. I could see external sites querying these statistics if: - the connection is encrypted - the client is querying a socket dedicated to Status-Server messages. (trivial to have one central stats store then) but still. I hope to see a lot of useful tools/widgets using this. bit of RRDTool is calling. Yes. There are a LOT of statistics available now. Almost every counter that you could track inside the server is exposed via this method. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Goodbye SNMP, hello statistics.
Alan DeKok wrote: [EMAIL PROTECTED] wrote: this is very cool - i guess it would be handy to let remote authorised machiens query it Seconded. Yes. But... it is a potential security issue to expose those statistics to anyone who asks. I could see external sites querying these statistics if: - the connection is encrypted - the client is querying a socket dedicated to Status-Server messages. But it also kinda limits the usefulness of the feature. Couldn't you place it in the hands of the server admins to decide which hosts can query and which can't? Another configuration item in clients? (trivial to have one central stats store then) but still. I hope to see a lot of useful tools/widgets using this. bit of RRDTool is calling. Yes. There are a LOT of statistics available now. Almost every counter that you could track inside the server is exposed via this method. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Arran -- Arran Cudbard-Bell ([EMAIL PROTECTED]), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Goodbye SNMP, hello statistics.
Arran Cudbard-Bell wrote: But it also kinda limits the usefulness of the feature. Couldn't you place it in the hands of the server admins to decide which hosts can query and which can't? Another configuration item in clients? grumble It's possible. I guess. I think the safest thing to do is to have a socket that's *only* for these statistics. That way it's clear that no authentication can be done using it. and real clients have no business querying it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server (udp packet size)
I still can't get some clients to receive my dhcp packets. After some more testing i figured out packet size differences. In other dhcp server responses it's 342 bytes ... on radius dhcp server i've 618 bytes. Is it possible to make send back messages as short as possbile ? :) Also found some references that dhcp clients can refuse messages if thay are larger that expected. Haralds from rfc: The client SHOULD include the 'maximum DHCP message size' option to let the server know how large the server may make its DHCP messages. The parameters returned to a client may still exceed the space allocated to options in a DHCP message. In this case, two additional options flags (which must appear in the 'options' field of the message) indicate that the 'file' and 'sname' fields are to be used for options. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Goodbye SNMP, hello statistics.
Hi, Yes. But... it is a potential security issue to expose those statistics to anyone who asks. obviously. I could see external sites querying these statistics if: - the connection is encrypted - the client is querying a socket dedicated to Status-Server messages. yep. now...although I'm thinking RADSEC could be involved...just a new port that is properly firewalled would do. i guess a 'statistics virtual server' would be the ideal thing. Yes. There are a LOT of statistics available now. Almost every counter that you could track inside the server is exposed via this method. i noted! grabbed the CVS to just have a look at the dictionary file. nice. however, it didnt compile... but i see a new change in auth.c as i write this...nope. still dead auth.c: In function 'rad_authlog': auth.c:119: error: expected expression before '' token auth.c:828: error: expected declaration or statement at end of input alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Goodbye SNMP, hello statistics.
[EMAIL PROTECTED] wrote: yep. now...although I'm thinking RADSEC could be involved...just a new port that is properly firewalled would do. i guess a 'statistics virtual server' would be the ideal thing. Done. Listen type = status. In CVS. i noted! grabbed the CVS to just have a look at the dictionary file. nice. however, it didnt compile... but i see a new change in auth.c as i write this...nope. still dead auth.c: In function 'rad_authlog': auth.c:119: error: expected expression before '' token You have local modifications, and the CVS update didn't do a merge, because it didn't know how. Grab a fresh copy of CVS, apply your patches, and see raddb/sites-available/status. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Goodbye SNMP, hello statistics.
Hi, Done. Listen type = status. In CVS. :-) You have local modifications, and the CVS update didn't do a merge, because it didn't know how. okay. yup. auth.c - modified a while back now - was the goodpass/badpass logging issue. removed and it now works alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Goodbye SNMP, hello statistics.
Arran Cudbard-Bell wrote: But it also kinda limits the usefulness of the feature. Couldn't you place it in the hands of the server admins to decide which hosts can query and which can't? Another configuration item in clients? grumble It's possible. I guess. I think the safest thing to do is to have a socket that's *only* for these statistics. That way it's clear that no authentication can be done using it. and real clients have no business querying it. Maybe a quicker solution would be to enable libwrap for it? I understand the changes to the code to support libwrap aren't too much, and it can even be made optional via the ./configure . Tuc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Goodbye SNMP, hello statistics.
Tuc at T-B-O-H.NET wrote: Maybe a quicker solution would be to enable libwrap for it? I understand the changes to the code to support libwrap aren't too much, and it can even be made optional via the ./configure . Ugh. The IP configuration / filter in the server already does as much, if not more, than libwrap. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Goodbye SNMP, hello statistics.
Tuc at T-B-O-H.NET wrote: Maybe a quicker solution would be to enable libwrap for it? I understand the changes to the code to support libwrap aren't too much, and it can even be made optional via the ./configure . Ugh. The IP configuration / filter in the server already does as much, if not more, than libwrap. Ok. It was just a suggestion, sorta like the one from 2004 with code : http://lists.cistron.nl/pipermail/freeradius-devel/2004-October/007608.html (Oddly, I think I saw that in the bug database and wondered why it didn't make it, and then when looking for an example to show how little it takes to integrate I happened on that email.) Thought maybe adding more configuration options or hooking into the current system was less to your liking. Tuc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server (udp packet size)
- Original Message - From: EvilEzh [EMAIL PROTECTED] To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Sent: Friday, June 20, 2008 8:12 PM Subject: Re: dhcp server (udp packet size) I still can't get some clients to receive my dhcp packets. After some more testing i figured out packet size differences. In other dhcp server responses it's 342 bytes ... on radius dhcp server i've 618 bytes. Is it possible to make send back messages as short as possbile ? :) Also found some references that dhcp clients can refuse messages if thay are larger that expected. Have schange defaulr packet size to 300 in dhcp.c , looks ok now. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Weird windows issue
Hi, this is a weird one for ya'll. windows clients (xp sp2 and what not) can be configured to pass there credentials along to wireless when they authenticate to the computer(to the AD domain). that seems to work fine. then randomly it seems to stop working and their login seems to be wrong. ideas? Joe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server (udp packet size)
Hi, In other dhcp server responses it's 342 bytes ... on radius dhcp server i've 618 bytes. Is it possible to make send back messages as short as possbile ? :) Also found some references that dhcp clients can refuse messages if thay are larger that expected. Have schange defaulr packet size to 300 in dhcp.c , looks ok now. hmm, i was going to advise doing a packet dump of each system to see how the 2 compare - where there are differences etc alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Weird windows issue
Hi, Hi, this is a weird one for ya'll. windows clients (xp sp2 and what not) can be configured to pass there credentials along to wireless when they authenticate to the computer(to the AD domain). that seems to work fine. then randomly it seems to stop working and their login seems to be wrong. ideas? their credentials in the AD have expired or been updated - that change cannot be propagated through an encrypted link. will work on wired 802.1X because thats not an encrypted link. funny, the exchange is allowed to occur on a completely insecure medium. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server (udp packet size)
I've net with over 1k dhcp clients. Problem with packet size was with linksys routers. They have udhcp client. Now it looks ok. Will do more testing. In other dhcp server responses it's 342 bytes ... on radius dhcp server i've 618 bytes. Is it possible to make send back messages as short as possbile ? :) Also found some references that dhcp clients can refuse messages if thay are larger that expected. Have schange defaulr packet size to 300 in dhcp.c , looks ok now. hmm, i was going to advise doing a packet dump of each system to see how the 2 compare - where there are differences etc alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server (udp packet size)
Hi, I've net with over 1k dhcp clients. so? you just sniff the traffic of one of them...or a limited subnet of those. or, you sniff the traffic on a single client itself. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server (udp packet size)
All of them .. i've redundant(duplicate) dhcp server also :) I tried to comapre response packets from both servers, new one (freeradius dhcp) and old one. And understand what's different. - Original Message - From: [EMAIL PROTECTED] To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Sent: Friday, June 20, 2008 11:54 PM Subject: Re: dhcp server (udp packet size) Hi, I've net with over 1k dhcp clients. so? you just sniff the traffic of one of them...or a limited subnet of those. or, you sniff the traffic on a single client itself. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
dhcp server (socket binding)
Can someone explain more about subj. Let see: incoming broadcast 0.0.0.0 - 255.255.255.255 i can get thease packets incoming broadcast 10.4.0.1-255.255.255.255 i can't get thease packets. In another words, if there is ip address in source, i can't get thease packets to process (mostly thease are request packets to renew lease). I've binding ip = 0.0.0.0 interface = eth1 if i bind to ip address ip=xx.xx.xx.xx i can't get any packet to process. I've set up relay also ... so relay catch thease packets and forward to ip address. ip = 10.2.0.15 interface = eth0 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
dhcp server (unicast replay)
Actualy i see in packet source x.x.x.x (client) - z.z.z.z (server). replay is z.z.z.z - y.y.y.y (relay). There is several retries from client. So i think clien't don't receive packet from relay. So if there is unicast from already configured client .. response should be sent directly back to client ignoring relay. DHCPREQUEST generated during RENEWING state: ... This message will be unicast, so no relay agents will be involved in its transmission. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server (unicast replay)
btw .. it works anyway with dhcp relay set. So nothing to do with it. With relay everything looks ok. :) It works. option 82 is also ok. Actualy i see in packet source x.x.x.x (client) - z.z.z.z (server). replay is z.z.z.z - y.y.y.y (relay). There is several retries from client. So i think clien't don't receive packet from relay. So if there is unicast from already configured client .. response should be sent directly back to client ignoring relay. DHCPREQUEST generated during RENEWING state: ... This message will be unicast, so no relay agents will be involved in its transmission. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Dependencies of Freeradius 2.0.5
Hi Leander and all, In message [EMAIL PROTECTED], Leander S. [EMAIL PROTECTED] writes Yes, thanks I understood this. But the Reason why I'm asking is, because I want to know about the version numbers which are required for example with snmp - because I use FreeBSD 7.0 RELEASE and there might be not the newst snmp software ready to install from the ports. The latest SNMP software is available in FreeBSD ports - well, very nearly. net-mgmt/net-snmp is currently at version 5.4.1 whilst it looks like Net SNMP version 5.4.1.2 has just been released. However, the issue with SNMP is not how new the SNMP software is! As has been said, the SNMP code in FreeRADIUS has rotted; it's not 64 bit safe, it uses the obsolescent smux protocol and it uses the ucd-snmp API. The latter of these issues means FreeRADIUS's SNMP code only works on FreeBSD against the obsolescent net-mgmt/net-snmp4 port, which is UCD SNMP. The correct way ahead with the FreeRADIUS SNMP code is widely acknowledged to be a rewrite using AgentX - however the new statistics code may turn out to be a better option. I wonder if the current SNMP code will be retired now that the statistics code is available. Rather than worrying about the dependencies, you could just install the FreeBSD net/freeradius2 port. I've done all the work for you - I've even provided an option to install every FreeRADIUS feature for which the libraries are available in ports. The net/freeradius2 port isn't in 7.0-RELEASE - it missed the deadline to be included. Even if it hadn't missed the deadline, it would have been version 2.0.0. All you need to do is to bring your ports tree up to date via your favourite method. 'portsnap fetch update' will do the job. At the moment, the port is still 2.0.3 - there's been some configuration management stuff to sort out that needs to go in the upgrade to 2.0.5. Once you have an up to date ports tree in /usr/ports, the following commands should download and install a pre-release version of the 2.0.5 port: cp -R /usr/ports/net/freeradius2 freeradius2 fetch http://www.wood2.org.uk/freebsd/port-freeradius2-2.0.5.patch patch -sd freeradius2 -i ../port-freeradius2-2.0.5.patch \ find freeradius2 -name '*.orig' -delete ( cd freeradius2 ; make install ) should do the job. I suggest copying and pasting those lines to a shell prompt. Note that the last step almost certainly requires root privileges. If you did not already have a FreeRADIUS configuration in /usr/local/etc/raddb, a copy of the sample configuration is made there ready for your customisation and raddb/certs has been bootstrapped so that the server is ready to go. Unless you deliberately disable the USER option, the server is configured to use the freeradius user and freeradius group (the group and user are created if necessary). This is recommended from a security perspective. The port installs an rc.d script for radiusd. Finally, you'll get a message on screen giving you various useful information including pointers to the documentation and the FreeRADIUS Wiki. I hope that this latest version of the port is easier to get going 'out of the box' than any previous version. Whilst it's a pre-release, I've completed my testing on it tonight - the only task remaining is to write up some documentation, then hopefully I can get it committed to the ports tree. ** IMPORTANT ** If you have an existing FreeRADIUS configuration, back up /usr/local/etc/raddb *before* uninstalling the old FreeRADIUS port - otherwise you will finish up with unmodified files being deleted from your existing configuration and these files not being restored after you install the 2.0.5 port. This is the issue that's delaying the upgrade until it's properly documented. The behaviour of the port is being changed to prevent this problem in the future. For more details, see http://www.freebsd.org/cgi/query-pr.cgi?pr=124439 ** IMPORTANT ** It is important to read /usr/ports/UPDATING after updating your ports tree. If you haven't already been through this, there's been an update to gettext that means many ports need rebuilding. Best wishes, David (FreeBSD port maintainer for FreeRADIUS) -- David Wood [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Dependencies of Freeradius 2.0.5
David Wood wrote: The correct way ahead with the FreeRADIUS SNMP code is widely acknowledged to be a rewrite using AgentX - however the new statistics code may turn out to be a better option. I wonder if the current SNMP code will be retired now that the statistics code is available. The current SNMP code will be deleted before the next release. The goal by the end of the year is either to implement AgentX in the server, OR there will be a separate program that does AgentX on one side, and the RADIUS statistics on the other. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
