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
******************************************

Reply via email to