November 2018 - Freeradius-Users - lists.freeradius.org

Use 2 modules to auth together.
by luckydog xf 27 Nov '18

27 Nov '18

Hi, here is my access-request from radiusd -fX Only an extra State is added comparing to the 1st auth. # Access-Challenge Ready to process requests (6) Received Access-Request Id 13 from 172.30.240.130:7460 to 172.16.237.52:1812 length 205 (6) NAS-Identifier = "Artisan_FW" (6) State = 0x654e6c7472756d474c576c6a61584b37 (6) User-Name = "someone" (6) MS-CHAP2-Response = 0x0f003132333435363638393035398846f8ca00000000000000000ac4b98d3afb9b42a0e1a1def464b78e5f6b13033d6a6e7c (6) MS-CHAP-Challenge = 0x680d6e49baa9e6f4b4f622042f0917f6 (6) NAS-IP-Address = 172.30.240.130 (6) NAS-Port-Type = Virtual (6) Called-Station-Id = "172.30.240.130" (6) Acct-Session-Id = "033ac507" (6) Connect-Info = "admin-login" (6) Fortinet-Vdom-Name = "root" (6) session-state: No cached attributes (6) # Executing section authorize from file /etc/raddb/sites-enabled/default As you can see there is NO User-Password attribute, which is OTP. It seems that it's caused by mschap authentication, there is no such attribute in mschap. Is there any way to input User-Password( in other words, OTP)? or my own auth method would fail to auth as there is no OTP. Thanks. On Nov 26, 2018, at 8:42 AM, luckydog xf <luckydogxf at gmail.com <http://lists.freeradius.org/mailman/listinfo/freeradius-users>> wrote: Find a challenge-support Device and test it out. Let me answer it. 1. Not every NAS supports Access-Challenge, they may just ignore it and treat it as access-reject. According to my test. 2. my way of raise challeng is correct, it's built-in way of FreeRADIUS. 3. else part seesm correct, too, though I haven't hanle my own auth method, it's just a fake one. Thank Alan again. On Nov 26, 2018, at 12:42 AM, luckydog xf <luckydogxf at gmail.com <http://lists.freeradius.org/mailman/listinfo/freeradius-users>> wrote: Thank, Alan, you enlighten me. Turns out NAS( my VPN) does not support Access-Challenge. Googled and found that Challenge seems to be a speical access-request packet with the Code field set to 11. So can I make the conclusion that it would send an access-quest again? in other words, start a new authentication process like another normal request with an exception that State attribute exists. Let me suppose my VPN supports Access-Challenge, so my configuation is something like: ------------------------------- authorize { # The first auth does not have any State attribute. if (!State) { # MS-CHAP has no User-Password, so it's true. if (!User-Password ) { # If !State and User-Password is null, then goes to MS-CHAP: update { &control:Auth-Type := MS-CHAP } } else { reject } # Make sure it does not contain any other attributes except State. else { update { # IS THIS PART CORRECT ? I think so, as a new request is issued by challage, so it would start over from top to buttom to walk throught the entire process. &control:Auth-Type := MY_OWN_OTP_AUTH } } } authentication { Auth-Type MS-CHAP { mschap if (ok) { update reply { # Create a random State attribute: State := "%{randstr:XXXXXXXXXXXXX}" Reply-Message := "Please type your OTP:" } # Return Access-Challenge, goes to the 2nd auth. # IS IT the correct way to raise a challange? challenge } Please help me to take a look at configuration above, two questions: 1. Is else part correct? which will use my own python auth module 2. Is it correct to raise a challenge using 'challenge' filter of FreeRADIUS? Thanks again. On Mon, Nov 26, 2018 at 8:10 PM Alan DeKok <aland atdeployingradius.com <http://lists.freeradius.org/mailman/listinfo/freeradius-users>> wrote: >** On Nov 26, 2018, at 2:42 AM, luckydog xf <luckydogxf at gmail.com <http://gmail.com> <http://lists.freeradius.org/mailman/listinfo/freeradius-users <http://lists.freeradius.org/mailman/listinfo/freeradius-users>>> wrote: **>* > Our user is in AD and VPN will do an MSCHAP authentication first and *>* > filter property of User-Name from access request, then call an *>* > access-challenge to verify against the other module whose logic is as *>* > simple as starting a http request via http://XXX/check/username= <http://xxx/check/username=> <http://xxx/check/username=> *>* > <http://xxx/check/username= <http://xxx/check/username=>><USER-NAME>&OTP=<xxxxxx>, if return 200, *>* it's *>* > ok. *>>* That's really just more authorization. *>>* > Basically, I want to auth a single login against two modules, only both *>* > of them are successful, the auth could be deemed as OK. *>>* That's possible, subject to certain caveats. *>>* > # ### authentication ##### *>* > authentication { *>* > Auth-Type MS-CHAP { *>* > mschap *>* > if (ok) { *>* > update reply { *>* > # Create a random State attribute: *>* > State := "%{randstr:XXXXXXXXXXXXX}" *>* > Reply-Message := "Please type your OTP:" *>* > } *>* > # Return Access-Challenge, goes to the 2nd auth. *>* > challenge *>>* That's good, but it likely won't work due to the NAS. Doing OTP like *>* that requires support from the NAS. Does the NAS support doing MS-CHAP and *>* then receiving an Access-Challenge? *>>* If it does, then your next step is to write down what you want to *>* happen, like this: *>>* 1) packet 1 contains MS-CHAP *>* 2) it authenticates agains MS-CHAP *>* 3) if MS-CHAP is successful, it returns a State, challenge, and reply *>* message *>* 4) when the next packet comes in with a state attribute, authenticate the *>* OTP *>>* Note that the packet in step 4 *should not* contain any MS-CHAP *>* attributes. It should just contain the response to the OTP. *>>* So your freeradius configuration is: *>>* 1) run MS-CHAP like normal *>* 2) do state / reply-message / challenge in "Auth-Type MS-CHAP" *>>* As a *separate* item: *>>* 3) if packet contains State *>* 4) do OTP verification *>>* The only thing tying the two packets together is the State attribute. *>* They are otherwise completely independent. *>>* Alan DeKok. *>>>>* - *>* List info/subscribe/unsubscribe? See *>* http://www.freeradius.org/list/users.html <http://www.freeradius.org/list/users.html>*

1 0

Use 2 modules to auth together.
by luckydog xf 27 Nov '18

27 Nov '18

Find a challenge-support Device and test it out. Let me answer it. 1. Not every NAS supports Access-Challenge, they may just ignore it and treat it as access-reject. According to my test. 2. my way of raise challeng is correct, it's built-in way of FreeRADIUS. 3. else part seesm correct, too, though I haven't hanle my own auth method, it's just a fake one. Thank Alan again. On Nov 26, 2018, at 12:42 AM, luckydog xf <luckydogxf at gmail.com <http://lists.freeradius.org/mailman/listinfo/freeradius-users>> wrote: Thank, Alan, you enlighten me. Turns out NAS( my VPN) does not support Access-Challenge. Googled and found that Challenge seems to be a speical access-request packet with the Code field set to 11. So can I make the conclusion that it would send an access-quest again? in other words, start a new authentication process like another normal request with an exception that State attribute exists. Let me suppose my VPN supports Access-Challenge, so my configuation is something like: ------------------------------- authorize { # The first auth does not have any State attribute. if (!State) { # MS-CHAP has no User-Password, so it's true. if (!User-Password ) { # If !State and User-Password is null, then goes to MS-CHAP: update { &control:Auth-Type := MS-CHAP } } else { reject } # Make sure it does not contain any other attributes except State. else { update { # IS THIS PART CORRECT ? I think so, as a new request is issued by challage, so it would start over from top to buttom to walk throught the entire process. &control:Auth-Type := MY_OWN_OTP_AUTH } } } authentication { Auth-Type MS-CHAP { mschap if (ok) { update reply { # Create a random State attribute: State := "%{randstr:XXXXXXXXXXXXX}" Reply-Message := "Please type your OTP:" } # Return Access-Challenge, goes to the 2nd auth. # IS IT the correct way to raise a challange? challenge } Please help me to take a look at configuration above, two questions: 1. Is else part correct? which will use my own python auth module 2. Is it correct to raise a challenge using 'challenge' filter of FreeRADIUS? Thanks again. On Mon, Nov 26, 2018 at 8:10 PM Alan DeKok <aland at deployingradius.com <http://lists.freeradius.org/mailman/listinfo/freeradius-users>> wrote: >* On Nov 26, 2018, at 2:42 AM, luckydog xf <luckydogxf at gmail.com <http://lists.freeradius.org/mailman/listinfo/freeradius-users>> wrote: *>* > Our user is in AD and VPN will do an MSCHAP authentication first and *>* > filter property of User-Name from access request, then call an *>* > access-challenge to verify against the other module whose logic is as *>* > simple as starting a http request via http://XXX/check/username= <http://xxx/check/username=> *>* > <http://xxx/check/username= <http://xxx/check/username=>><USER-NAME>&OTP=<xxxxxx>, if return 200, *>* it's *>* > ok. *>>* That's really just more authorization. *>>* > Basically, I want to auth a single login against two modules, only both *>* > of them are successful, the auth could be deemed as OK. *>>* That's possible, subject to certain caveats. *>>* > # ### authentication ##### *>* > authentication { *>* > Auth-Type MS-CHAP { *>* > mschap *>* > if (ok) { *>* > update reply { *>* > # Create a random State attribute: *>* > State := "%{randstr:XXXXXXXXXXXXX}" *>* > Reply-Message := "Please type your OTP:" *>* > } *>* > # Return Access-Challenge, goes to the 2nd auth. *>* > challenge *>>* That's good, but it likely won't work due to the NAS. Doing OTP like *>* that requires support from the NAS. Does the NAS support doing MS-CHAP and *>* then receiving an Access-Challenge? *>>* If it does, then your next step is to write down what you want to *>* happen, like this: *>>* 1) packet 1 contains MS-CHAP *>* 2) it authenticates agains MS-CHAP *>* 3) if MS-CHAP is successful, it returns a State, challenge, and reply *>* message *>* 4) when the next packet comes in with a state attribute, authenticate the *>* OTP *>>* Note that the packet in step 4 *should not* contain any MS-CHAP *>* attributes. It should just contain the response to the OTP. *>>* So your freeradius configuration is: *>>* 1) run MS-CHAP like normal *>* 2) do state / reply-message / challenge in "Auth-Type MS-CHAP" *>>* As a *separate* item: *>>* 3) if packet contains State *>* 4) do OTP verification *>>* The only thing tying the two packets together is the State attribute. *>* They are otherwise completely independent. *>>* Alan DeKok. *>>>>* - *>* List info/subscribe/unsubscribe? See *>* http://www.freeradius.org/list/users.html <http://www.freeradius.org/list/users.html>*

1 0

Freeradius authentication with SSL client certificates
by Tom Yard 27 Nov '18

27 Nov '18

Hi people, I wanto to implement a Freeradius authentication scheme, using server and client SSL certificates: every client that require WiFI access has to have a valid SSL certificate. I think I have to use: Authetication methos: EAP-TLS Authentication protocol with NTLM: MSCHAP or MSCHAPv2 My clients are Windows, Linux and maybe Android. Is my proposal correct ? Thanking in advance. Tommy

5 4

Use 2 modules to auth together.
by luckydog xf 26 Nov '18

26 Nov '18

hi, all, Any way to handle a second access request? Our user is in AD and VPN will do an MSCHAP authentication first and filter property of User-Name from access request, then call an access-challenge to verify against the other module whose logic is as simple as starting a http request via http://XXX/check/username= <http://xxx/check/username=><USER-NAME>&OTP=<xxxxxx>, if return 200, it's ok. Basically, I want to auth a single login against two modules, only both of them are successful, the auth could be deemed as OK. # site-enabled/default authorize { if (!State) { # MS-CHAP has no User-Password, so it's true. if (!User-Password ) { # If !State and User-Password is null, then goes to MS-CHAP: update { &control:Auth-Type := MS-CHAP } } else { reject } } else { # The 2nd auth module. # I DON'T KNOW HOW TO WRITE. } } } # ### authentication ##### authentication { Auth-Type MS-CHAP { mschap if (ok) { update reply { # Create a random State attribute: State := "%{randstr:XXXXXXXXXXXXX}" Reply-Message := "Please type your OTP:" } # Return Access-Challenge, goes to the 2nd auth. challenge } } } Thanks a lot.

2 2

FreeRadius 3.0.17 - outer tunnel username in accounting logs instead of inner tunnel username
by Thorsten Fritsch 23 Nov '18

23 Nov '18

Hi guys, we have recently upgraded our FreeRadius to release 3.0.17 and are now facing the issue that the accounting logs seem to contain the username provided in the anonymous (outer) identity field instead of the username used for the inner tunnel. This makes it hard to identify our eduroam users (user tracking). Has something changed in FreeRadius 3.x regarding thise behavior ? In my understanding the Radius server should provide the inner tunnel username to the NAS (in our case Cisco WLAN Controller) by parameter use_tunneled_reply = yes in the eap file under /mods-enabled which the NAS can then in turn provide to the Accounting server is that correct ? We have set this setting to yes in our config: ttls { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "eduroam-inner-tunnel" } peap { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "eduroam-inner-tunnel" } Thanks for your help. Cheers, Thorsten

3 4

No connections available and at max connection limit
by تعلم البرمجة 22 Nov '18

22 Nov '18

Hello all i have this problem and i want solve it rlm_sql (sql): No connections available and at max connection limit

2 1

Re: TXID mismatch between DHCP Request-Offer (devel version)
by Chinnapaiyan, Nagamani 22 Nov '18

22 Nov '18

It works after changing the code in my local repo... Thanks... We are storing TXID as it is(without ntohl). But while sending we are doing htonl. Corrected that also. # git diff diff --git a/src/modules/proto_dhcpv4/proto_dhcpv4.c b/src/modules/proto_dhcpv4/proto_dhcpv4.c index 465a3ea..3a80a8f 100644 --- a/src/modules/proto_dhcpv4/proto_dhcpv4.c +++ b/src/modules/proto_dhcpv4/proto_dhcpv4.c @@ -416,7 +416,7 @@ static ssize_t mod_encode(void const *instance, REQUEST *request, uint8_t *buffe } data_len = fr_dhcpv4_encode(buffer, buffer_len, - request->reply->code, original->xid, request->reply->vps); + request->reply->code, ntohl(original->xid), request->reply->vps); if (data_len < 0) { RPEDEBUG("Failed encoding DHCPV4 reply"); return -1; diff --git a/src/protocols/dhcpv4/packet.c b/src/protocols/dhcpv4/packet.c index 5460041..38790f9 100644 --- a/src/protocols/dhcpv4/packet.c +++ b/src/protocols/dhcpv4/packet.c @@ -218,6 +218,12 @@ int fr_dhcpv4_packet_decode(RADIUS_PACKET *packet) } p += len; } +//Decode message type from the option. +VALUE_PAIR *message_type = NULL; +message_type = fr_pair_find_by_da(head, attr_dhcp_message_type, TAG_ANY); +if(message_type) { +packet->code = message_type->vp_uint8; +} /* * If option Overload is present in the 'options' field, then fields 'file' and/or 'sname' Regards, Nagamani Chinnapaiyan

2 1

Getting error wile loading module during the uinttest case
by shivu prasad 22 Nov '18

22 Nov '18

Hi All, I am getting below error while loading my module during running testcase. But same module works fine as part of normal server, I can load my module, authenticate and even authorize works fine. But if I try to load the module in src/tests/modules//radiusd.conf I am getting the error. Even I verified the module.conf configuration its same as mods-enabled/mymodule_name only. Not sure what is missing here. Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "reject" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "fail" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "ok" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "handled" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "invalid" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "userlock" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "notfound" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "noop" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "updated" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "pap" from file raddb/mods-enabled/pap Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "my_reject" from file src/tests/modules/always//module.conf Thu Nov 22 19:56:36 2018 : Debug: } # modules Thu Nov 22 19:56:36 2018 : Debug: radiusd: #### Loading Virtual Servers #### Thu Nov 22 19:56:36 2018 : Debug: server { # from file src/tests/modules//radiusd.conf Thu Nov 22 19:56:36 2018 : Debug: } # server Thu Nov 22 19:56:36 2018 : Debug: server default { # from file src/tests/modules//radiusd.conf Thu Nov 22 19:56:36 2018 : Debug: # Loading authenticate {...} Thu Nov 22 19:56:36 2018 : Debug: pap *Thu Nov 22 19:56:36 2018 : Error: src/tests/modules//radiusd.conf[40]: Failed to find "idcs" as a module or policy.Thu Nov 22 19:56:36 2018 : Error: src/tests/modules//radiusd.conf[40]: Please verify that the configuration exists in src/tests/modules//mods-enabled/idcs.Thu Nov 22 19:56:36 2018 : Error: src/tests/modules//radiusd.conf[38]: Errors parsing authenticate section. * # build/tests/modules/always/replace.log Regards, Shivaprasad

1 0

Does freeradius support Eap-sim/AKA module
by manjunath uthappa ponnachana 22 Nov '18

22 Nov '18

Hi All,Does freeradius support Eap-sim/aka module. Is it stable.How to configure it to interact with HLR.Thanks & regardsManjunath

1 0

Re: TXID mismatch between DHCP Request-Offer (devel version)
by Chinnapaiyan, Nagamani 22 Nov '18

22 Nov '18

Thanks for the quick fix. Now TXID is fixed. But the server responds with OFFER even for Request message. Attached the pcap for your reference. Debug output for Redis_ippool: Ready to process requests proto_dhcpv4_udp - Received DHCP-Discover XID 00000000 length 259 proto_dhcpv4_udp server 10.43.18.92 port 67 Network received packet size 259 Resetting worker 30 cleanup timer to +0s (0) running request (0) Received DHCP-Discover XID 00000000 from 127.0.0.1:67 to 10.43.18.92:67 via lo (0) &DHCP-Opcode = Client-Message (0) &DHCP-Hardware-Type = Ethernet (0) &DHCP-Hardware-Address-Length = 6 (0) &DHCP-Hop-Count = 1 (0) &DHCP-Transaction-Id = 0 (0) &DHCP-Number-of-Seconds = 0 (0) &DHCP-Flags = 0 (0) &DHCP-Client-IP-Address = 127.0.0.1 (0) &DHCP-Your-IP-Address = 0.0.0.0 (0) &DHCP-Server-IP-Address = 0.0.0.0 (0) &DHCP-Gateway-IP-Address = 127.0.0.1 (0) &DHCP-Client-Hardware-Address = 00:a1:bc:00:00:01 (0) &DHCP-Message-Type = DHCP-Discover (0) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (0) &DHCP-Client-Identifier = 0x0100a1bc000001 (0) Running 'recv DHCP-Discover' from file /usr/local/etc/raddb/sites-enabled/dhcp (0) recv DHCP-Discover { (0) update reply { (0) DHCP-Message-Type = DHCP-Offer (0) } # update reply (noop) (0) update reply { (0) &DHCP-Domain-Name-Server = 127.0.0.1 (0) &DHCP-Subnet-Mask = 255.255.255.0 (0) &DHCP-Router-Address = 10.43.18.92 (0) &DHCP-IP-Address-Lease-Time = 86400 (0) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (0) } # update reply (noop) (0) update control { (0) &Pool-Name := "local" (0) } # update control (noop) (0) redis_ippool - Allocating lease from pool "local", to "00:a1:bc:00:00:01", expires in 300s (0) redis_ippool - Reserved connection (1) (0) redis_ippool - [1] >>> Sending command(s) to 127.0.0.1:6379 (0) redis_ippool - [1] <<< Returned: success (0) redis_ippool - Released connection (1) (0) redis_ippool - Need 2 more connections to reach min connections (4) (0) redis_ippool - Opening additional connection (2), 1 of 2 pending slots used rlm_redis (redis) [1]: Connecting node to 127.0.0.1:6379 (0) redis_ippool - &reply:DHCP-Your-IP-Address := 192.168.0.122 (0) redis_ippool - &reply:DHCP-IP-Address-Lease-Time := 300 (0) redis_ippool - IP address lease allocated (0) redis_ippool (updated) (0) ok (ok) (0) } # recv DHCP-Discover (updated) (0) Sent DHCP-Offer XID 00000000 from 10.43.18.92:67 to 127.0.0.1:67 via lo (0) &DHCP-Message-Type = DHCP-Offer (0) &DHCP-Domain-Name-Server = 127.0.0.1 (0) &DHCP-Subnet-Mask = 255.255.255.0 (0) &DHCP-Router-Address = 10.43.18.92 (0) &DHCP-IP-Address-Lease-Time := 300 (0) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (0) done request (0) finished request. Ready to process requests Reply will be unicast to CIADDR from original packet. proto_dhcpv4_udp - cleaning up ID 1 Ready to process requests proto_dhcpv4_udp - Received DHCP-Request XID 00000000 length 265 proto_dhcpv4_udp server 10.43.18.92 port 67 Network received packet size 265 Resetting worker 30 cleanup timer to +0s (1) running request (1) Received DHCP-Discover XID 00000000 from 127.0.0.1:67 to 10.43.18.92:67 via lo (1) &DHCP-Opcode = Client-Message (1) &DHCP-Hardware-Type = Ethernet (1) &DHCP-Hardware-Address-Length = 6 (1) &DHCP-Hop-Count = 1 (1) &DHCP-Transaction-Id = 0 (1) &DHCP-Number-of-Seconds = 0 (1) &DHCP-Flags = 0 (1) &DHCP-Client-IP-Address = 127.0.0.1 (1) &DHCP-Your-IP-Address = 0.0.0.0 (1) &DHCP-Server-IP-Address = 0.0.0.0 (1) &DHCP-Gateway-IP-Address = 127.0.0.1 (1) &DHCP-Client-Hardware-Address = 00:a1:bc:00:00:01 (1) &DHCP-Requested-IP-Address = 192.168.0.122 (1) &DHCP-Message-Type = DHCP-Request (1) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (1) &DHCP-Client-Identifier = 0x0100a1bc000001 (1) Running 'recv DHCP-Discover' from file /usr/local/etc/raddb/sites-enabled/dhcp (1) recv DHCP-Discover { (1) update reply { (1) DHCP-Message-Type = DHCP-Offer (1) } # update reply (noop) (1) update reply { (1) &DHCP-Domain-Name-Server = 127.0.0.1 (1) &DHCP-Subnet-Mask = 255.255.255.0 (1) &DHCP-Router-Address = 10.43.18.92 (1) &DHCP-IP-Address-Lease-Time = 86400 (1) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (1) } # update reply (noop) (1) update control { (1) &Pool-Name := "local" (1) } # update control (noop) (1) redis_ippool - Allocating lease from pool "local", to "00:a1:bc:00:00:01", expires in 300s (1) redis_ippool - Reserved connection (2) (1) redis_ippool - [1] >>> Sending command(s) to 127.0.0.1:6379 (1) redis_ippool - [1] <<< Returned: success (1) redis_ippool - Released connection (2) (1) redis_ippool - &reply:DHCP-Your-IP-Address := 192.168.0.122 (1) redis_ippool - &reply:DHCP-IP-Address-Lease-Time := 300 (1) redis_ippool - IP address lease allocated (1) redis_ippool (updated) (1) ok (ok) (1) } # recv DHCP-Discover (updated) (1) Sent DHCP-Offer XID 00000000 from 10.43.18.92:67 to 127.0.0.1:67 via lo (1) &DHCP-Message-Type = DHCP-Offer (1) &DHCP-Domain-Name-Server = 127.0.0.1 (1) &DHCP-Subnet-Mask = 255.255.255.0 (1) &DHCP-Router-Address = 10.43.18.92 (1) &DHCP-IP-Address-Lease-Time := 300 (1) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (1) done request (1) finished request. Ready to process requests Reply will be unicast to CIADDR from original packet. proto_dhcpv4_udp - cleaning up ID 1 Ready to process requests Debug output for mac2ip: proto_dhcpv4_udp - Received DHCP-Discover XID 00000000 length 259 proto_dhcpv4_udp server 10.43.18.92 port 67 Network received packet size 259 Resetting worker 30 cleanup timer to +0s (4) running request (4) Received DHCP-Discover XID 00000000 from 127.0.0.1:67 to 10.43.18.92:67 via lo (4) &DHCP-Opcode = Client-Message (4) &DHCP-Hardware-Type = Ethernet (4) &DHCP-Hardware-Address-Length = 6 (4) &DHCP-Hop-Count = 1 (4) &DHCP-Transaction-Id = 0 (4) &DHCP-Number-of-Seconds = 0 (4) &DHCP-Flags = 0 (4) &DHCP-Client-IP-Address = 127.0.0.1 (4) &DHCP-Your-IP-Address = 0.0.0.0 (4) &DHCP-Server-IP-Address = 0.0.0.0 (4) &DHCP-Gateway-IP-Address = 127.0.0.1 (4) &DHCP-Client-Hardware-Address = 00:a1:bc:00:00:01 (4) &DHCP-Message-Type = DHCP-Discover (4) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (4) &DHCP-Client-Identifier = 0x0100a1bc000001 (4) Running 'recv DHCP-Discover' from file /usr/local/etc/raddb/sites-enabled/dhcp (4) recv DHCP-Discover { (4) update reply { (4) DHCP-Message-Type = DHCP-Offer (4) } # update reply (noop) (4) update reply { (4) &DHCP-Domain-Name-Server = 127.0.0.1 (4) &DHCP-Subnet-Mask = 255.255.255.0 (4) &DHCP-Router-Address = 10.43.18.92 (4) &DHCP-IP-Address-Lease-Time = 86400 (4) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (4) } # update reply (noop) (4) mac2ip - Added DHCP-Your-IP-Address: '10.1.1.3' to reply_items (4) mac2ip (ok) (4) ok (ok) (4) } # recv DHCP-Discover (ok) (4) Sent DHCP-Offer XID 00000000 from 10.43.18.92:67 to 127.0.0.1:67 via lo (4) &DHCP-Message-Type = DHCP-Offer (4) &DHCP-Domain-Name-Server = 127.0.0.1 (4) &DHCP-Subnet-Mask = 255.255.255.0 (4) &DHCP-Router-Address = 10.43.18.92 (4) &DHCP-IP-Address-Lease-Time = 86400 (4) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (4) done request (4) finished request. Ready to process requests Reply will be unicast to CIADDR from original packet. proto_dhcpv4_udp - cleaning up ID 1 Ready to process requests proto_dhcpv4_udp - Received DHCP-Request XID 00000000 length 265 proto_dhcpv4_udp server 10.43.18.92 port 67 Network received packet size 265 Resetting worker 30 cleanup timer to +0s (5) running request (5) Received DHCP-Discover XID 00000000 from 127.0.0.1:67 to 10.43.18.92:67 via lo (5) &DHCP-Opcode = Client-Message (5) &DHCP-Hardware-Type = Ethernet (5) &DHCP-Hardware-Address-Length = 6 (5) &DHCP-Hop-Count = 1 (5) &DHCP-Transaction-Id = 0 (5) &DHCP-Number-of-Seconds = 0 (5) &DHCP-Flags = 0 (5) &DHCP-Client-IP-Address = 127.0.0.1 (5) &DHCP-Your-IP-Address = 0.0.0.0 (5) &DHCP-Server-IP-Address = 0.0.0.0 (5) &DHCP-Gateway-IP-Address = 127.0.0.1 (5) &DHCP-Client-Hardware-Address = 00:a1:bc:00:00:01 (5) &DHCP-Requested-IP-Address = 10.1.1.3 (5) &DHCP-Message-Type = DHCP-Request (5) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (5) &DHCP-Client-Identifier = 0x0100a1bc000001 (5) Running 'recv DHCP-Discover' from file /usr/local/etc/raddb/sites-enabled/dhcp (5) recv DHCP-Discover { (5) update reply { (5) DHCP-Message-Type = DHCP-Offer (5) } # update reply (noop) (5) update reply { (5) &DHCP-Domain-Name-Server = 127.0.0.1 (5) &DHCP-Subnet-Mask = 255.255.255.0 (5) &DHCP-Router-Address = 10.43.18.92 (5) &DHCP-IP-Address-Lease-Time = 86400 (5) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (5) } # update reply (noop) (5) mac2ip - Added DHCP-Your-IP-Address: '10.1.1.3' to reply_items (5) mac2ip (ok) (5) ok (ok) (5) } # recv DHCP-Discover (ok) (5) Sent DHCP-Offer XID 00000000 from 10.43.18.92:67 to 127.0.0.1:67 via lo (5) &DHCP-Message-Type = DHCP-Offer (5) &DHCP-Domain-Name-Server = 127.0.0.1 (5) &DHCP-Subnet-Mask = 255.255.255.0 (5) &DHCP-Router-Address = 10.43.18.92 (5) &DHCP-IP-Address-Lease-Time = 86400 (5) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (5) done request (5) finished request. Ready to process requests Reply will be unicast to CIADDR from original packet. proto_dhcpv4_udp - cleaning up ID 1 Ready to process requests Regards, Nagamani Chinnapaiyan

1 0