Bug 196429 - DHCPv6 server in rawhide returns malformed replies
Summary: DHCPv6 server in rawhide returns malformed replies
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcpv6
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: David Cantrell
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
 
Reported: 2006-06-23 08:43 UTC by Tomas Mraz
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-11-22 17:40:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tomas Mraz 2006-06-23 08:43:03 UTC
Server from dhcpv6-0.10-26 returns malformed replies to dhcpv6 client. The
client version is dhcpv6_client-0.10-16.1. When the server is downgraded to the
same version as client, it works fine.

The syslog on client machine contains:

Jun 23 09:56:48 ipv6srot dhcp6c[6736]:   malformed IA option: type 16384, len 33
28
Jun 23 09:56:48 ipv6srot dhcp6c[6736]: failed to parse options
Jun 23 09:56:48 ipv6srot dhcp6c[6736]: unexpected reply

Comment 1 Jason Vas Dias 2006-07-19 06:58:00 UTC
This is now fixed with dhcpv6-0.10-30 in rawhide / FC-6 .

The problem was that previous to dhcpv6-0.10-24? the only way to set the
client address prefix was by router advertisement; after adding the new
address, dhcpv6 expected the route dst_len to be set automatically by
router advertisement in the kernel ; this did not happen, (unless a radvd
was running on the network) so effectively, no client address prefixes could 
be set without radvd.

Then, with -24, I made the server explicitly send the prefix length configured
in the server configuration file to the client; but this broke the packet
parse for earlier clients.

Now, clients must send a new 'DH6OPT_REQUEST_PREFIX' nil-valued option (28),
which will cause the server to send the extra prefix length byte,  if
the 'address{ .. prefix ...}' option or 'range ::x ::x/NN' statements 
specify a non-zero prefix.

This can be disabled in dhcp6c.conf and dhcp6s.conf by use of the 
new 'use_ra_prefix' option, which specifies the default upstream
behaviour of relying on radvd for the address prefixes.


Note You need to log in before you can comment on or make changes to this bug.