Ethereal-dev: Re: [Ethereal-dev] DHCPv6 patch

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Joerg Mayer <jmayer@xxxxxxxxx>
Date: Fri, 3 Dec 2004 20:43:48 +0100
On Thu, Dec 02, 2004 at 11:15:42PM +0100, Tomasz Mrugalski wrote:
> Here's quick list of the changes:
> - FQDN option added (draft-ietf-dhc-dhcpv6-opt-fqdn-00.txt)

> +static int hf_fqdn_1 = -1;
> +static int hf_fqdn_2 = -1;
> +static int hf_fqdn_3 = -1;
> +static int hf_fqdn_4 = -1;

Can you please provide an incremental diff (diff -u) that
changes the _1 ... _4 to something a bit more selfexplanatory?

> +/* This FQDN draft is a mess, I've tried to understand, 
> +   but N,O,S bit descriptions are really cryptic */

By default, the Client will update the AAAA but not the PTR.
If the Client wants the server to update the AAAA too, then it
should set the S (Server) Flag. In case, it wants to set the
PTR itself too, it should set the N Flag. If the server insists
that the client doesn't do any updates, it will set the O
(override) flag. In the O case, the client is not allowed to do a
ddns update. Does this make things a bit more clear?

> +static const true_false_string fqdn_n = {
> +/*    "Client doesn't want server to perform DNS update", "" */
> +    "N bit set","N bit cleared"
> +};
> +
> +static const true_false_string fqdn_o = {
> +    "O bit set", "O bit cleared" 
> +};
> +
> +static const true_false_string fqdn_s = {
> +/*    "Forward mapping (FQDN-to-IPv6, AAAA) performed by client", 
> +      "Forward mapping (FQDN-to-IPv6, AAAA) performed by server" */
> +    "S bit set", "S bit cleared"
> +}; 

Please provide a patch updating the fields - perhaps just using the
names from packet-bootp.c would be the most consistent solution.
Please note that the e Flag is ipv4 only.

> +	case OPTION_CLIENT_FQDN:
> +	  if (optlen < 1) {
> +	    proto_tree_add_text(subtree, tvb, off,
> +				optlen, "FQDN: malformed option");
> +	    break;
>  	  }
> +	  // +-----+-+-+-+
> +	  // | MBZ |N|O|S|
> +	  // +-----+-+-+-+
> +	  proto_tree_add_item(subtree, hf_fqdn_1, tvb, off, 1, FALSE);
> +	  proto_tree_add_item(subtree, hf_fqdn_2, tvb, off, 1, FALSE);
> +	  proto_tree_add_item(subtree, hf_fqdn_3, tvb, off, 1, FALSE);
> +	  proto_tree_add_item(subtree, hf_fqdn_4, tvb, off, 1, FALSE);
> +/* 	  proto_tree_add_text(subtree, tvb, off, 1, */
> +/* 			      "flags: %d", */
> +/* 			      (guint32)tvb_get_guint8(tvb, off)); */
> +	  dhcpv6_domain(subtree,tvb, off+1, optlen-1);

I'd like to see a trace, because in my reading of the rfc, this should
not be in ascii encoding but in <length>first string<length>second
string[repleat, until]<length=0> Format. So please provide a patch fixing
that as well (this last point will allow me to just steal the code
for the ipv4 fqdn decoding ;->

  Ciao
                  Joerg


-- 
Joerg Mayer                                           <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.