Age | Commit message (Collapse) | Author |
|
RFCs for DHCPv6 are written rather badly...
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
d6_send_raw_packet_from_client_data_ifindex - 427 +427
d6_send_kernel_packet_from_client_data_ifindex - 275 +275
send_d6_renew 182 176 -6
perform_d6_release 246 240 -6
d6_mcast_from_client_data_ifindex 45 39 -6
d6_send_kernel_packet 274 - -274
d6_send_raw_packet 429 - -429
------------------------------------------------------------------------------
(add/remove: 2/2 grow/shrink: 0/3 up/down: 702/-721) Total: -19 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Martin Lewis <martin.lewis.x84@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
d6_read_interface 593 582 -11
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Add support for 'bootfile-url' and 'bootfile-params' as defined by
RFC5970 "DHCPv6 Options for Network Boot".
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Based on patch by DannyAAM <danny@saru.moe>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Basedon patch by Bernd Holzmüller <bernd.holzmueller@tiggerswelt.net>
function old new delta
option_to_env 504 580 +76
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Patch is based on work by tiggerswelt.net. They say:
"
We wanted udhcpc6 to release its IPv6-Addresses on
quit (-R-commandline-option) which turned out to generate once again
kind of garbage on the network-link.
We tracked this down to two issues:
- udhcpc6 uses a variable called "srv6_buf" to send packets to
the dhcp6-server, but this variable is never initialized correctly
and contained kind of a garbage-address
- The address of the dhcp6-server is usually a link-local-address,
that requires an interface-index when using connect() on an AF_INET6-
socket
We added an
additional parameter for ifindex to d6_send_kernel_packet() and made
d6_recv_raw_packet() to capture the address of the dhcp6-server and
forward it to its callee.
"
Three last patches together:
function old new delta
d6_read_interface - 454 +454
d6_recv_raw_packet - 283 +283
option_to_env 249 504 +255
.rodata 165226 165371 +145
send_d6_discover 195 237 +42
send_d6_select 118 159 +41
send_d6_renew 173 186 +13
send_d6_release 162 173 +11
opt_req - 10 +10
d6_send_kernel_packet 304 312 +8
opt_fqdn_req - 6 +6
d6_mcast_from_client_config_ifindex 48 51 +3
d6_find_option 63 61 -2
udhcpc6_main 2416 2411 -5
static.d6_recv_raw_packet 266 - -266
------------------------------------------------------------------------------
(add/remove: 5/1 grow/shrink: 8/2 up/down: 1271/-273) Total: 998 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Patch is based on work by tiggerswelt.net. They say:
"
But when we tried to use dnsmasq on server-side, udhcpc6 was unable to
forward the acquired address to its setup-script although the
IPv6-Address had been assigned by the server as we could see via
tcpdump. We traced this issue down to a problem on how udhcpc6 parses
DHCPv6-Options: When moving to next option, a pointer-address is
increased and a length buffer is decreased by the length of the option.
The problem is that it is done in this order:
option += 4 + option[3];
len_m4 -= 4 + option[3];
But this has to be switched as the length is decreased by the length of
the *next* option, not the current one. This affected both - internal
checks if a required option is present and the function to expose
options to the environment of the setup-script.
There was also a bug parsing D6_OPT_STATUS_CODE Options, that made
dnsmasq not work as udhcpc6 thought it is receiving a non-positive
status-code (because it did not parse the status-code as required in RFC
3315).
In addition we introduced basic support for RFC 3646 (OPTION_DNS_SERVERS
and OPTION_DOMAIN_LIST) and RFC 4704 (OPTION_CLIENT_FQDN).
"
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Patch is based on work by tiggerswelt.net. They say:
"Using this patch it was no problem to acquire an IPv6-Address via DHCPv6
using ISC DHCPD6 on server-side."
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
It builds. It sends Solicit packets. Not sure these packets are well-formed.
I have no server to test it against.
function old new delta
udhcpc6_main - 2426 +2426
d6_send_raw_packet - 428 +428
d6_send_kernel_packet - 274 +274
d6_recv_raw_packet - 248 +248
send_d6_discover - 177 +177
packed_usage 28795 28966 +171
d6_run_script - 156 +156
send_d6_renew - 140 +140
send_d6_release - 126 +126
d6_recv_kernel_packet - 116 +116
send_d6_select - 95 +95
perform_d6_release - 78 +78
d6_find_option - 74 +74
init_d6_packet - 54 +54
d6_copy_option - 48 +48
d6_mcast_from_client_config_ifindex - 42 +42
d6_dump_packet - 24 +24
static.FF02__1_2 - 16 +16
d6_store_blob - 13 +13
applet_names 2432 2440 +8
applet_main 1412 1416 +4
applet_nameofs 706 708 +2
add_d6_client_options - 1 +1
------------------------------------------------------------------------------
(add/remove: 21/0 grow/shrink: 4/0 up/down: 4721/0) Total: 4721 bytes
text data bss dec hex filename
879080 493 7584 887157 d8975 busybox_old
884585 497 7584 892666 d9efa busybox_unstripped
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|