[Dibbler-devel] Prefix delegation & prefix pool management issue.
MINODIER David RD-RESA-LAN
david.minodier at orange-ftgroup.com
Fri Apr 27 17:03:52 CEST 2007
Hi all,
In short: Two clients obtain their /64 prefix from a dibbler-server
configured with a single /63 pool.
There are therefore 2 /64 prefixes to be delegated, but they both obtain
the same prefix (!).
Here is my server.conf:
dhcpv6-server:/usr/local/src/dibbler# cat /etc/dibbler/server.conf
log-level 8
log-mode short
iface "eth1" {
T1 1800
T2 2700
prefered-lifetime 3600
valid-lifetime 7200
class {
pool 5000::/48
}
option dns-server 2000::1
pd-class {
pd-pool 2001:688:1F9B:2000::/63
pd-length 64
}
}
which states that 2 prefixes can be delegated from the /63 pool.
However, my two clients get both the same /64 prefix, i.e.:
2001:688:1F9B:2000/64
while they should actually receive :
2001:688:1F9B:2000/64 and 2001:688:1F9B:2001/64
Dibber-server (built from the today CVS repository) displays some wierd
output (in bold):
dhcpv6-server:/usr/local/src/dibbler# ./dibbler-server run
| Dibbler - a portable DHCPv6, version 0.6.0 (SERVER, Linux port)
| Authors : Tomasz Mrugalski<thomson(at)klub.com.pl>,Marek
Senderski<msend(at)o2.pl>
| Licence : GNU GPL v2 or later. Developed at Gdansk University of
Technology.
| Homepage: http://klub.com.pl/dhcpv6/
<SNIP>
2007.04.27 18:07:11 Server Notice Parsing /etc/dibbler/server.conf
config file...
07:11 Server Debug PD: Client will receive /64 prefixes
(T1=1800..1800, T2=2700..2700).
07:11 Server Debug PD: Pool 2001:688:1f9b:2000:: -
2001:688:1f9b:20fe:ffff:ffff:ffff:ffff, pool length: 63.
07:11 Server Debug PD: Up to 2 prefixes may be assigned.
07:11 Server Debug 0 per-client configurations (exceptions) added.
<SNIP>
Indeed the "bold" line says that the range for that pool goes from
2001:688:1f9b:2000 to 2001:688:1f9b:20fe
while it should go from 2001:688:1F9B:2000/64 to 2001:688:1F9B:2001/64.
I had a look at the getRangeMax function and we (a friend and I) found
out there could be a little bug in there.
Here's the patch for both SrvCfgMgr/SrvParser.y and
SrvCfgMgr/SrvParser.cpp:
Index: SrvCfgMgr/SrvParser.cpp
===================================================================
RCS file: /var/cvs/dibbler/SrvCfgMgr/SrvParser.cpp,v
retrieving revision 1.40
diff -u -r1.40 SrvParser.cpp
--- SrvCfgMgr/SrvParser.cpp 22 Apr 2007 21:19:30 -0000 1.40
+++ SrvCfgMgr/SrvParser.cpp 27 Apr 2007 14:28:18 -0000
@@ -2768,7 +2768,7 @@
memcpy(packed, addrPacked,16);
if (prefix%8!=0) {
mask = bitMask[prefix%8];
- packed[prefix/8] = packed[prefix/8] | mask;
+ packed[prefix/8] = packed[prefix/8] | ~mask;
prefix = (prefix/8 + 1)*8;
}
for (int i=prefix/8;i<16; i++) {
Index: SrvCfgMgr/SrvParser.y
===================================================================
RCS file: /var/cvs/dibbler/SrvCfgMgr/SrvParser.y,v
retrieving revision 1.40
diff -u -r1.40 SrvParser.y
--- SrvCfgMgr/SrvParser.y 22 Apr 2007 21:19:30 -0000 1.40
+++ SrvCfgMgr/SrvParser.y 27 Apr 2007 14:28:18 -0000
@@ -1198,7 +1198,7 @@
memcpy(packed, addrPacked,16);
if (prefix%8!=0) {
mask = bitMask[prefix%8];
- packed[prefix/8] = packed[prefix/8] | mask;
+ packed[prefix/8] = packed[prefix/8] | ~mask;
prefix = (prefix/8 + 1)*8;
}
for (int i=prefix/8;i<16; i++) {
===================================================================
This seems to correct it. With the patch applied, it now displays:
dhcpv6-server:/usr/local/src/dibbler# ./dibbler-server run
| Dibbler - a portable DHCPv6, version 0.6.0 (SERVER, Linux port)
| Authors : Tomasz Mrugalski<thomson(at)klub.com.pl>,Marek
Senderski<msend(at)o2.pl>
| Licence : GNU GPL v2 or later. Developed at Gdansk University of
Technology.
| Homepage: http://klub.com.pl/dhcpv6/
<SNIP>
35:16 Server Debug PD: Client will receive /64 prefixes
(T1=1800..1800, T2=2700..2700).
35:16 Server Debug PD: Pool 2001:688:1f9b:2000:: -
2001:688:1f9b:2001:ffff:ffff:ffff:ffff, pool length: 63.
35:16 Server Debug PD: Up to 2 prefixes may be assigned.
35:16 Server Debug 0 per-client configurations (exceptions) added.
</SNIP>
which looks better.
However, it still delegates the same prefix to the two different clients
(different DUIDs), as the *full* (long) output shows
(I mention *full* to insist on the fact that I did not stop the server
nor the clients after
client 1 has received its prefix ;-) ).
<REQUEST FROM CLIENT 1>
36:34 Server Debug Received 52 bytes on interface eth1/3 (socket=4,
addr=fe80::20e:cff:fe71:1f05.).
36:34 Server Debug Authentication is disabled.
36:34 Server Notice Received SOLICIT on eth1/3,TransID=0x56c471, 4
opts: 1 25 8 6, 0 relay(s).
36:34 Server Debug 0 answers buffered. Old reply for transID=56c471
not found. Generating new answer.
36:34 Server Notice PD option (with IAPREFIX suboptions missing)
received.
36:34 Server Debug PD: Client requested unspecified (::) prefix.
Hint ignored.
36:34 Server Info PD:(would be) assigned
prefix(es):2001:688:1f9b:2000::/64
36:34 Server Debug Preference set to 0.
36:34 Server Notice Sending ADVERTISE on eth1/3,transID=0x56c471,
opts: 1 25 23 24 2 7, 0 relay(s).
36:34 Server Debug 1 message(s) were removed from cache.
36:34 Server Notice Accepting connections. Next event in 4294967295
second(s).
36:36 Server Debug Received 70 bytes on interface eth1/3 (socket=4,
addr=fe80::20e:cff:fe71:1f05.).
36:36 Server Debug Authentication is disabled.
36:36 Server Notice Received REQUEST on eth1/3,TransID=0x1a1afe, 5
opts: 1 25 8 6 2, 0 relay(s).
36:36 Server Debug 0 answers buffered. Old reply for transID=1a1afe
not found. Generating new answer.
36:36 Server Notice PD option (with IAPREFIX suboptions missing)
received.
36:36 Server Debug PD: Client requested unspecified (::) prefix.
Hint ignored.
36:36 Server Debug Adding client
(DUID=00:01:00:01:45:fe:a2:0e:00:90:27:61:11:e3) to addrDB.
36:36 Server Debug PD: Adding PD (iaid=1) to addrDB.
36:36 Server Debug PD: Adding 2001:688:1f9b:2000:: prefix to PD
(iaid=1) to addrDB.
36:36 Server Info PD: assigned prefix(es):2001:688:1f9b:2000::/64
36:36 Server Notice Sending REPLY on eth1/3,transID=0x1a1afe, opts: 1
25 2 23 24, 0 relay(s).
36:36 Server Notice Accepting connections. Next event in 60
second(s).
<REQUEST FROM CLIENT 2>
37:29 Server Debug Received 52 bytes on interface eth1/3 (socket=4,
addr=fe80::20d:88ff:fe70:e538.).
37:29 Server Debug Authentication is disabled.
37:29 Server Notice Received SOLICIT on eth1/3,TransID=0xc33214, 4
opts: 1 25 8 6, 0 relay(s).
37:29 Server Debug 1 answers buffered. Old reply for transID=c33214
not found. Generating new answer.
37:29 Server Notice PD option (with IAPREFIX suboptions missing)
received.
37:29 Server Debug PD: Client requested unspecified (::) prefix.
Hint ignored.
37:29 Server Info PD:(would be) assigned
prefix(es):2001:688:1f9b:2000::/64
37:29 Server Debug Preference set to 0.
37:29 Server Notice Sending ADVERTISE on eth1/3,transID=0xc33214,
opts: 1 25 23 24 2 7, 0 relay(s).
37:29 Server Debug 1 message(s) were removed from cache.
37:29 Server Notice Accepting connections. Next event in 7 second(s).
37:31 Server Debug Received 70 bytes on interface eth1/3 (socket=4,
addr=fe80::20d:88ff:fe70:e538.).
37:31 Server Debug Authentication is disabled.
37:31 Server Notice Received REQUEST on eth1/3,TransID=0x2c0af2, 5
opts: 1 25 8 6 2, 0 relay(s).
37:31 Server Debug 1 answers buffered. Old reply for transID=2c0af2
not found. Generating new answer.
37:31 Server Notice PD option (with IAPREFIX suboptions missing)
received.
37:31 Server Debug PD: Client requested unspecified (::) prefix.
Hint ignored.
37:31 Server Debug Adding client
(DUID=00:01:00:00:45:09:40:92:00:0c:76:22:75:db) to addrDB.
37:31 Server Debug PD: Adding PD (iaid=1) to addrDB.
37:31 Server Debug PD: Adding 2001:688:1f9b:2000:: prefix to PD
(iaid=1) to addrDB.
37:31 Server Info PD: assigned prefix(es):2001:688:1f9b:2000::/64
37:31 Server Notice Sending REPLY on eth1/3,transID=0x2c0af2, opts: 1
25 2 23 24, 0 relay(s).
37:31 Server Notice Accepting connections. Next event in 5 second(s).
37:36 Server Debug 1 message(s) were removed from cache.
37:36 Server Notice Accepting connections. Next event in 55
second(s).
So I guess there is something wrong... But I can't honestly find it
after 2 days of hard gdb...
Any hints ?
Many thanks !
David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://klub.com.pl/pipermail/dibbler-devel/attachments/20070427/9a9df6c3/attachment-0001.htm
More information about the Dibbler-devel
mailing list