> If I can't negotiate a lease, does udhcpc automatically
> support ZCIP?
no.
> If not, I think I'll start udhcpc and zcip both
> at the same time and write scripts to get the lease or the
> zcip address.
we start zcip after a dhcp lease failure. and, following the advice
of someone on this list, we start zcip on an alias interface. this
way when dhcp comes back, any zcip sessions can remain up.
> What do the options do?
> --vendorclass
> --clientid
these control additional DHCP option values that the client can
send. "client id" normally defaults to [something very similar to]
the client's mac address, and is used by the dhcp server to distinguish
this client from all others. "vendor class" is a way for vendor's
to extend dhcp options without having to change the RFC.
see rfc 2132, search for "client identifier" and "vendor class".
http://tools.ietf.org/html/rfc2132
>
> With reference to my previous email about obtaining a lease, I
> can't see how the option -R (--release) is used. I don't see
if the udhcpc is killed (SIGTERM), then it will send a release to
the server, saying "i'm done with this address". if it does this,
then everyone using that address had better stop. i also notice
an odd combination -- if udhcpc has been told to both "quit after
obtaining a lease" and "release on quit", then as soon as it gets
a lease, it will send a release, and quit. i'm not sure what use
that would have, except perhaps for debugging.
> my script being called with "deconfig" except on
> initialisation. Is this expected?
it will also be called with deconfig if, when it tries to renew the
release with the server, the server never responds. in that case,
the client has to start over, and so the script is run with "deconfig".
calling the script with "deconfig" at init time is sort of a safety
net, to be sure we're starting from a clean slate.
>
> Under what circumstances would my script be called with
> $1==nak?
the server may have been reconfigured, or maybe your client has been
moved to a network where the address it is using isn't valid. in that
case, when it tries to renew the address, the server will NAK the request,
and the script will be so informed.
> with $1==renew?
when the client is in (or probably, when it enters) the "renew" state.
it sounds like you'd benefit from reading a DHCP protocol overview.
paul
=---------------------
paul fox, [EMAIL PROTECTED]
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox