Send dhcp-users mailing list submissions to dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/dhcp-users or, via email, send a message with subject or body 'help' to dhcp-users-requ...@lists.isc.org You can reach the person managing the list at dhcp-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcp-users digest..." Today's Topics: 1. Multiple vendor-encapsulated option spaces? (Peter Rathlev) 2. Re: Multiple vendor-encapsulated option spaces? (Doug Barton) 3. Re: Multiple vendor-encapsulated option spaces? (Peter Rathlev) 4. Re: Multiple vendor-encapsulated option spaces? (Shawn Routhier) 5. Re: Multiple vendor-encapsulated option spaces? (Peter Rathlev) 6. Re: Multiple vendor-encapsulated option spaces? (Shawn Routhier) 7. how to get usernames for .1x authenticated clients from dhcp server (Roberto Innocente) ---------------------------------------------------------------------- Message: 1 Date: Wed, 27 May 2015 22:20:53 +0200 From: Peter Rathlev <pe...@rathlev.dk> To: dhcp-users <dhcp-us...@isc.org> Subject: Multiple vendor-encapsulated option spaces? Message-ID: <1432758053.28063.15.ca...@abehat.dyn.net.rm.dk> Content-Type: text/plain; charset="UTF-8" I'm facing a problem trying to define and use two different option spaces. For some reason only the last defined option space actually works. Swapping them makes the other work. We're running isc-dhcpd-4.3.2 (vanilla from source) on CentOS 5+6 in a text-book failover configuration. The option space configuration that I can't get to work is: option space Cisco-WLC; option Cisco-WLC.ControllerIP code 241 = ip-address; option Cisco-WLC-encapsulation code 43 = encapsulate Cisco-WLC; option space ASCOM; option ASCOM.servicediscovery code 10 = text; option ASCOM-encapsulation code 43 = encapsulate ASCOM; class "Ascom-TeleCARE-IP" { match if option vendor-class-identifier = "1.3.6.1.4.1.27614.1.2"; vendor-option-space ASCOM; option ASCOM.servicediscovery "192.0.2.50/RoomControllerDH"; } class "Cisco-WLC" { match if substring(option vendor-class-identifier, 0, 8) = "Cisco AP"; log(info, "inside Cisco-WLC class"); vendor-option-space Cisco-WLC; option Cisco-WLC.ControllerIP 198.51.100.20; } Apart from this there's of course the subnet definitions et cetera. Both of these options spaces / vendor encapsulations work by themselves with no problems. But if both are defined (as shown above) then only the last "option space" defined (the ASCOM one above) works. Traffic captures verifies that the clients (Cisco 2700 AP and Ascom teleCARE IP) are sending what they should. Logging statements inside the "Cisco-WLC" class actually fires, but for some reason dhcpd doesn't send the option to the client, also verified with tcpdump. Shouldn't I be able to have multiple option spaces in this way? Or current work-around is to send the Cisco options as an opaque blob: option vendor-encapsulated-options F1:04:C6:33:64:14; This works but is rather unelegant. And some day we might have a third or fourth system that expects vendor encapsulated options that are much less straightforward than the Cisco-WLC example. Thanks a bunch for your time! :-) -- Peter ------------------------------ Message: 2 Date: Wed, 27 May 2015 13:30:01 -0700 From: Doug Barton <dougb@dougbarton.email> To: dhcp-users@lists.isc.org Subject: Re: Multiple vendor-encapsulated option spaces? Message-ID: <55662949.6030105@dougbarton.email> Content-Type: text/plain; charset="utf-8"; Format="flowed" It's not clear that your definitions are correct here. You seem to be doing some things you should not, and not doing some things you should. Take a look at this page: http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html#anc13 -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150527/2738be34/attachment-0001.bin> ------------------------------ Message: 3 Date: Wed, 27 May 2015 22:39:38 +0200 From: Peter Rathlev <pe...@rathlev.dk> To: Users of ISC DHCP <dhcp-users@lists.isc.org> Subject: Re: Multiple vendor-encapsulated option spaces? Message-ID: <1432759178.14511.5.ca...@abehat.dyn.net.rm.dk> Content-Type: text/plain; charset="UTF-8" On Wed, 2015-05-27 at 13:30 -0700, Doug Barton wrote: > It's not clear that your definitions are correct here. You seem to be > doing some things you should not, and not doing some things you should. > > Take a look at this page: > > http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html#anc13 I'm not sure what part of that configuration you think I am missing or what excess parts I have. As far as I can tell we're doing exactly what the page says, except for (re-)setting the vendor-class-identifier to what it was matched as, which seems superflous to me. Keep in mind that the DHCP configuration for each of my options spaces works fine as long as it is the only one. When I have more than one then only the last defined works. But thanks for taking a look. :-) -- Peter ------------------------------ Message: 4 Date: Wed, 27 May 2015 14:16:25 -0700 From: Shawn Routhier <s...@isc.org> To: Users of ISC DHCP <dhcp-users@lists.isc.org> Subject: Re: Multiple vendor-encapsulated option spaces? Message-ID: <446133b8-d155-4486-8d9a-03f01f552...@isc.org> Content-Type: text/plain; charset=us-ascii > On May 27, 2015, at 1:20 PM, Peter Rathlev <pe...@rathlev.dk> wrote: > > I'm facing a problem trying to define and use two different option > spaces. For some reason only the last defined option space actually > works. Swapping them makes the other work. > > We're running isc-dhcpd-4.3.2 (vanilla from source) on CentOS 5+6 in a > text-book failover configuration. > > The option space configuration that I can't get to work is: > > option space Cisco-WLC; > option Cisco-WLC.ControllerIP code 241 = ip-address; > option Cisco-WLC-encapsulation code 43 = encapsulate > Cisco-WLC;<----------------- > > option space ASCOM; > option ASCOM.servicediscovery code 10 = text; > option ASCOM-encapsulation code 43 = encapsulate ASCOM; <----------------- Try removing the lines stating that option 43 is encapsulating things. ------------------------------ Message: 5 Date: Thu, 28 May 2015 00:23:14 +0200 From: Peter Rathlev <pe...@rathlev.dk> To: Users of ISC DHCP <dhcp-users@lists.isc.org> Subject: Re: Multiple vendor-encapsulated option spaces? Message-ID: <1432765394.14511.12.ca...@abehat.dyn.net.rm.dk> Content-Type: text/plain; charset="UTF-8" On Wed, 2015-05-27 at 14:16 -0700, Shawn Routhier wrote: > > On May 27, 2015, at 1:20 PM, Peter Rathlev <pe...@rathlev.dk> wrote: > > The option space configuration that I can't get to work is: > > > > option space Cisco-WLC; > > option Cisco-WLC.ControllerIP code 241 = ip-address; > > option Cisco-WLC-encapsulation code 43 = encapsulate > > Cisco-WLC;<----------------- > > > > option space ASCOM; > > option ASCOM.servicediscovery code 10 = text; > > option ASCOM-encapsulation code 43 = encapsulate ASCOM; <----------------- > > Try removing the lines stating that option 43 is encapsulating things. Ah, thanks! That was it! Everything works as intended now. I'm not sure exactly why we had these in the configuration, but I'm pretty sure I've looked at several examples on teh Intarnetz that include a similar line. But then there are a lot of terrible examples out there... Reading the man pages I can now see that this "= encapsulate" thing is only meant for options above 224 (or 128 or whatever) that the DHCP server doesn't already know how to encapsulate. And a nod to Doug, who was right if not elaborate. :-) That line isn't mentioned in Ciscos (old-ish) LWAPP documentation. Cheers all around! -- Peter ------------------------------ Message: 6 Date: Wed, 27 May 2015 22:12:01 -0700 From: Shawn Routhier <s...@isc.org> To: Users of ISC DHCP <dhcp-users@lists.isc.org> Subject: Re: Multiple vendor-encapsulated option spaces? Message-ID: <1987f1cf-d996-42de-9c1d-9443ff569...@isc.org> Content-Type: text/plain; charset=utf-8 > On May 27, 2015, at 3:23 PM, Peter Rathlev <pe...@rathlev.dk> wrote: > > On Wed, 2015-05-27 at 14:16 -0700, Shawn Routhier wrote: >>> On May 27, 2015, at 1:20 PM, Peter Rathlev <pe...@rathlev.dk> wrote: >>> The option space configuration that I can't get to work is: >>> >>> option space Cisco-WLC; >>> option Cisco-WLC.ControllerIP code 241 = ip-address; >>> option Cisco-WLC-encapsulation code 43 = encapsulate >>> Cisco-WLC;<----------------- >>> >>> option space ASCOM; >>> option ASCOM.servicediscovery code 10 = text; >>> option ASCOM-encapsulation code 43 = encapsulate ASCOM; <----------------- >> >> Try removing the lines stating that option 43 is encapsulating things. > > Ah, thanks! That was it! Everything works as intended now. > > I'm not sure exactly why we had these in the configuration, but I'm > pretty sure I've looked at several examples on teh Intarnetz that > include a similar line. But then there are a lot of terrible examples > out there? I?ve seen some indications that they were needed in some older versions of DHCP, but I?ve never felt the desire to figure out if they really were needed or somebody was confused. > > Reading the man pages I can now see that this "= encapsulate" thing is > only meant for options above 224 (or 128 or whatever) that the DHCP > server doesn't already know how to encapsulate. > > And a nod to Doug, who was right if not elaborate. :-) That line isn't > mentioned in Ciscos (old-ish) LWAPP documentation. > > Cheers all around! > > -- > Peter ------------------------------ Message: 7 Date: Thu, 28 May 2015 08:15:08 +0200 From: Roberto Innocente <i...@sissa.it> To: dhcp-users@lists.isc.org Subject: how to get usernames for .1x authenticated clients from dhcp server Message-ID: <97f33cfcdf2fcf9eee50a90c92925...@sissa.it> Content-Type: text/plain; charset="us-ascii"; Format="flowed" (i re-submit this because a previous submission sent before subscriptions went in some sink i dont know about) username associated with lease from isc dhcp server (possible for 802.1x authenticated clients) It would be very useful to be able to query dhcp servers for the radius attributes the switches add to client dhcp requests (according to rfc4014) when the clients were authenticated by 802.1x. I made a very small patch that i did'nt test much. This patch allows isc dhcp server to store the radius attributes that it eventually receives in the lease and therefore replies to dhcp leasquery packets or small python scripts using omapi with for instance the radius User-Name obtained from the NAS. I enclose the untested patch here. It is also available at http://people.sissa.it/~inno/pubs/diff-Naur-radattr-std.txt I know now the development is mainly on kea, but .. let me know if someone finds it useful. eg . small python script using pypureomapi queries dhcp server and gets back username(get-ip-l : get-ip-lease trough omapi) $PYPUREOMAPI/get-ip-l 169.254.1.183 ip 169.254.1.182 mac 00:12:22:33:77:89 User-Name = kitten I took the simplest road to store all radius attributes in one hex option as in this example lease, it remains under the responsability of the clients to decode them : lease 169.254.1.183 { starts 4 2015/05/28 06:04:23; ends 4 2015/05/28 06:09:23; cltt 4 2015/05/28 06:04:23; binding state active; next binding state free; rewind binding state free; hardware ethernet 00:12:22:33:77:89; option agent.circuit-id "cir 123"; option agent.radius-attributes 1:8:6b:69:74:74:65:6e; } write to me for the simple python script querying for usernames. -- Roberto Innocente - SISSA i...@sissa.it - +39 40 3787541 -------------- next part -------------- A non-text attachment was scrubbed... Name: diff-Naur-radattr-std.txt Type: text/x-diff Size: 4395 bytes Desc: not available URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150528/e8c90565/attachment.bin> ------------------------------ _______________________________________________ dhcp-users mailing list dhcp-users@lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users End of dhcp-users Digest, Vol 79, Issue 16 ******************************************