Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Strange behaviour with Option 53 - what am I missing? (Dave Cole)
2. Re: Strange behaviour with Option 53 - what am I missing?
(Dave Cole)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Jan 2018 00:45:12 +0000
From: Dave Cole <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Strange behaviour with Option 53 - what am I
missing?
Message-ID:
<syxpr01mb172707cea86c8cc59f446aaff2...@syxpr01mb1727.ausprd01.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
I have decided that before publishing my Python bindings I should add a bunch
of unit tests.? In the process I discovered something strange:
>>> from kea import *
>>> p = Pkt4(DHCPDISCOVER, 0)
>>> o = p.getOptions()[DHO_DHCP_MESSAGE_TYPE]
>>> o.getUint8()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Attempt to read uint8 from option 53 that has size 0
>>> o.getString()
'\x01'
The implementation of getUint8 is:
static PyObject *
Option_getUint8(OptionObj *self, PyObject *args) {
try {
return (PyInt_FromLong(self->option_ptr->getUint8()));
} catch (const exception &e) {
return (raisePythonError(PyExc_TypeError, e.what()));
}
}
Whereas the getString is:
static PyObject *
Option_getString(OptionObj *self, PyObject *args) {
try {
vector<uint8_t> value = self->option_ptr->toBinary();
return (PyString_FromStringAndSize((const char *) &value[0],
value.size()));
} catch (const exception &e) {
return (raisePythonError(PyExc_TypeError, e.what()));
}
}
So when I step through the code with gdb it appears that DHO_DHCP_MESSAGE_TYPE
is an instance of OptionInt which does not use the data_ member of Option,
instead it has another member value_ of the type defined in the template
argument.
Is it a deliberate choice in the code to require application code to just know
that getUint8 does not work for OptionInt (which subclasses Option)?
Someone with more of a clue about c++ than me might be able to tell me an easy
(and efficient) way I can make my code notice an OptionInt and internally use
getValue() rather than getUint8(). Would a
dynamic_pointer_cast<OptionUint8>(self->option_ptr) be the way to go?
------------------------------
Message: 2
Date: Tue, 30 Jan 2018 04:00:12 +0000
From: Dave Cole <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Strange behaviour with Option 53 - what am I
missing?
Message-ID:
<syxpr01mb17277919827e282179ddf0c5f2...@syxpr01mb1727.ausprd01.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
After looking into this more deeply I suspect the only way I can provide a
sensible wrapper for the Option class is to do a bunch of dynamic_pointer_cast
operations in my Python wrapper constructor and save a type code. Then I can
just perform a switch in each method that has the potential to fail when I have
a reference to an Option sub-class rather than the generic Option super-class.
I am not sure it makes sense to ever expose the ability to construct an Option
sub-class from Python.
In any event, I am not going to bother doing this until I have tests for all of
the functionality currently implemented. You can quite happily do anything you
need with just the Option class and methods. For example:
>>> from kea import *
>>> from ipaddress import IPv4Address
>>> name_servers = [IPv4Address(u'192.0.3.1'), IPv4Address(u'192.0.3.2')]
>>> packed_name_servers = ''.join([addr.packed for addr in name_servers])
>>> o = Option(DHO_DOMAIN_NAME_SERVERS).setString(packed_name_servers)
>>> o.getString()
'\xc0\x00\x03\x01\xc0\x00\x03\x02'
Hmm... On further investigation, I am going to have to do the funny dynamic
cast thing - even though we will not use it here :-).
>>> from kea import *
>>> from pcapfile import savefile
>>>
>>> def make_packet(frame):
... ll = frame.packet
... ip = ll.payload
... udp = ip.payload
... p = Pkt4(udp.payload.decode('hex'))
... p.setLocalAddr(ip.src)
... p.setRemoteAddr(ip.dst)
... p.setLocalPort(udp.src_port)
... p.setRemotePort(udp.dst_port)
... p.unpack()
... return p
...
>>> pcap = savefile.load_savefile(open('dhcp-trace.pcap'), layers=3)
>>> p = make_packet(pcap.packets[1])
>>> print p.toText()
local_address=172.20.0.4:67, remote_address=11.0.0.1:67, msg_type=DHCPOFFER
(2), transid=0x566fcf25,
options:
type=001, len=004: 255.255.240.0 (ipv4-address)
type=003, len=004: 11.0.0.1
type=042, len=004: 10.10.3.10
type=043, len=058: 01:38:68:74:74:70:73:***private stuff***
type=051, len=004: 86400 (uint32)
type=053, len=001: 2 (uint8)
type=054, len=004: 172.20.0.4 (ipv4-address)
type=058, len=004: 43200 (uint32)
type=059, len=004: 75600 (uint32)
type=082, len=050:,
options:
type=001, len=033: 53:57:***private stuff***
type=002, len=013: 55:4e:***private stuff***
>>>
>>> o = p.getOption(3).getUint16()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Length (0) of buffer is insufficient to read a uint16_t
Oh well :-)
________________________________
From: kea-dev <[email protected]> on behalf of Dave Cole
<[email protected]>
Sent: Tuesday, 30 January 2018 11:45:12 AM
To: [email protected]
Subject: [kea-dev] Strange behaviour with Option 53 - what am I missing?
I have decided that before publishing my Python bindings I should add a bunch
of unit tests. In the process I discovered something strange:
>>> from kea import *
>>> p = Pkt4(DHCPDISCOVER, 0)
>>> o = p.getOptions()[DHO_DHCP_MESSAGE_TYPE]
>>> o.getUint8()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Attempt to read uint8 from option 53 that has size 0
>>> o.getString()
'\x01'
The implementation of getUint8 is:
static PyObject *
Option_getUint8(OptionObj *self, PyObject *args) {
try {
return (PyInt_FromLong(self->option_ptr->getUint8()));
} catch (const exception &e) {
return (raisePythonError(PyExc_TypeError, e.what()));
}
}
Whereas the getString is:
static PyObject *
Option_getString(OptionObj *self, PyObject *args) {
try {
vector<uint8_t> value = self->option_ptr->toBinary();
return (PyString_FromStringAndSize((const char *) &value[0],
value.size()));
} catch (const exception &e) {
return (raisePythonError(PyExc_TypeError, e.what()));
}
}
So when I step through the code with gdb it appears that DHO_DHCP_MESSAGE_TYPE
is an instance of OptionInt which does not use the data_ member of Option,
instead it has another member value_ of the type defined in the template
argument.
Is it a deliberate choice in the code to require application code to just know
that getUint8 does not work for OptionInt (which subclasses Option)?
Someone with more of a clue about c++ than me might be able to tell me an easy
(and efficient) way I can make my code notice an OptionInt and internally use
getValue() rather than getUint8(). Would a
dynamic_pointer_cast<OptionUint8>(self->option_ptr) be the way to go?
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20180130/8ef5d103/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 46, Issue 5
**************************************
