Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 May 1999 15:01:37 -0700 (PDT)
From:      Mark Atkinson <marka@metaip.checkpoint.com>
To:        freebsd-ports@freebsd.org
Subject:   isc's dhclient
Message-ID:  <Pine.BSF.4.10.9905071429310.19573-200000@moby.dev.metainfo.com>

next in thread | raw e-mail | index | archive | help
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--0-1724573330-926114497=:19573
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

I'm not subscribed to ports, so please include me in your replys.

I've been tinkering with the isc-dhcp port of dhclient, and using this
client with our dhcp server product and freebsd.  Unfortunately on freebsd
and linux, the client lease time that the dhclient program calculates is
bogus and you end up with a shifted value that is in turn a  huge value in
seconds.

On intel boxes the network byte order is reversed from that of solaris,
hp, etc, so I've designed this small program to demonstrate what memcpy()
will hose when dealing with a char vs. a u_int32_t.  This program closely
simiulates what dhclient does so you don't have to go diving into the code
to figure it out.

Compile this on solaris with -DUSE_LONG and without -DUSE_LONG.
You get this output, both times:

packet_value                    00001c20
u_int32_t copied from packet    7200
u_int32_t after ntohl           7200

Compile this program on FreeBSD and you this output:

-DUSE_LONG
packet_value                    201c0000
u_int32_t copied from packet    538705920
u_int32_t after ntohl           7200

without -DUSE_LONG
packet_value                    201c0000
u_int32_t copied from packet    7200
u_int32_t after ntohl           538705920

dchlient's code path is similar to that of without USE_LONG defined.  Thus
generating huge lease times for the client.  The client, in turn, then
eventually loses it's lease.

The same thing happens on linux with minor code modifications.  The
question posed is this -- is it a or port bug or something more basic?

---
Mark Atkinson
Checkpoint Technologies' Metaip Group
marka@metaip.checkpoint.com
!(wired)?(coffee++):(wired)



--0-1724573330-926114497=:19573
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="badntohl.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.BSF.4.10.9905071501370.19573@moby.dev.metainfo.com>
Content-Description: network byte disorder
Content-Disposition: attachment; filename="badntohl.c"

I2luY2x1ZGUgPHN0ZGlvLmg+ICAgICAvKiBmcHJpbnRmICovDQojaW5jbHVk
ZSA8c3RyaW5nLmg+ICAgIC8qIG1lbWNweSAqLw0KDQojaWZuZGVmIF9fRnJl
ZUJTRF9fDQojaW5jbHVkZSA8YXJwYS9pbmV0Lmg+DQojZWxzZQ0KI2luY2x1
ZGUgPHN5cy9wYXJhbS5oPiAvKiBudG9obCAqLw0KI2VuZGlmDQoNCiNpbmNs
dWRlIDx0aW1lLmg+DQoNCnZvaWQgbWFpbiAodm9pZCkgew0KDQojaWZuZGVm
IF9fRnJlZUJTRF9fDQojZGVmaW5lIHVfaW50MzJfdCB1bG9uZw0KI2VuZGlm
DQoNCiNpZmRlZiBVU0VfTE9ORw0KIyAgIGlmbmRlZiBfX0ZyZWVCU0RfXw0K
ICAgICAgIHVfaW50MzJfdCBwYWNrZXRfdmFsPTB4MDAwMDFjMjA7DQojICAg
ZWxzZQ0KICAgICAgIHVfaW50MzJfdCBwYWNrZXRfdmFsPTB4MjAxYzAwMDA7
DQojICAgZW5kaWYNCiNlbHNlIA0KIyAgIGlmbmRlZiBfX0ZyZWVCU0RfXw0K
ICAgIGNoYXIgcGFja2V0X3ZhbFs0XT17MHgwMCwgMHgwMCwgMHgxYywgMHgy
MH07DQojICAgZWxzZQ0KICAgIGNoYXIgcGFja2V0X3ZhbFs0XT17MHgyMCwg
MHgxYywgMHgwMCwgMHgwMH07DQojICAgZW5kaWYNCiNlbmRpZg0KDQogICAg
dW5zaWduZWQgY2hhciAqZGVtb180X2J5dGVfcGFja2V0Ow0KDQogICAgdGlt
ZV90IGRlbW9fNF9ieXRlX2xvbmcgPSAwOw0KICAgIHRpbWVfdCBkZW1vXzRf
Ynl0ZV9uZXR3b3JrX2J5dGVfb3JkZXIgPSAwOw0KDQogICAgZGVtb180X2J5
dGVfcGFja2V0ID0gKHVuc2lnbmVkIGNoYXIgKikgbWFsbG9jIChzaXplb2Yo
dV9pbnQzMl90KSsxKTsNCiAgICBtZW1zZXQoZGVtb180X2J5dGVfcGFja2V0
LDAsc2l6ZW9mKHVfaW50MzJfdCkpOw0KDQojaWZkZWYgVVNFX0xPTkcNCiAg
ICBtZW1jcHkoZGVtb180X2J5dGVfcGFja2V0LCZwYWNrZXRfdmFsLHNpemVv
Zih1X2ludDMyX3QpKTsNCiAgICBmcHJpbnRmKHN0ZG91dCwgInBhY2tldF92
YWx1ZSAgICAgICAgICAgICAgICAgICAgJTA4bHhcbiIscGFja2V0X3ZhbCk7
DQojZWxzZQ0KICAgIG1lbWNweShkZW1vXzRfYnl0ZV9wYWNrZXQscGFja2V0
X3ZhbCxzaXplb2YodV9pbnQzMl90KSk7DQogICAgZnByaW50ZihzdGRvdXQs
ICJwYWNrZXRfdmFsdWUgICAgICAgICAgICAgICAgICAgICUwMnglMDJ4JTAy
eCUwMnhcbiIsDQoJCXBhY2tldF92YWxbMF0scGFja2V0X3ZhbFsxXSxwYWNr
ZXRfdmFsWzJdLHBhY2tldF92YWxbM10pOw0KI2VuZGlmDQoNCg0KICAgIG1l
bWNweSgmZGVtb180X2J5dGVfbG9uZywgZGVtb180X2J5dGVfcGFja2V0LCBz
aXplb2YodV9pbnQzMl90KSk7DQoNCiAgICBmcHJpbnRmKHN0ZG91dCwgInVf
aW50MzJfdCBjb3BpZWQgZnJvbSBwYWNrZXQgICAgJWx1XG4iLCBkZW1vXzRf
Ynl0ZV9sb25nKTsNCg0KICAgIGRlbW9fNF9ieXRlX25ldHdvcmtfYnl0ZV9v
cmRlciA9IG50b2hsKGRlbW9fNF9ieXRlX2xvbmcpOw0KDQogICAgZnByaW50
ZihzdGRvdXQsICJ1X2ludDMyX3QgYWZ0ZXIgbnRvaGwgICAgICAgICAgICVs
dVxuIiwNCiAgICAgICAgICAgIGRlbW9fNF9ieXRlX25ldHdvcmtfYnl0ZV9v
cmRlcik7DQoNCn0NCg==
--0-1724573330-926114497=:19573--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9905071429310.19573-200000>