Commit 5fbd020 ("[settings] Display canonical setting name in output
of "show" command") introduced a regression causing all setting
expansions (e.g. "${net0/mac}") to expand to an empty string.
Fix by returning the formatted value length from
fetchf_named_setting(), as expected by the caller.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Enable the "show" command to display the full, canonicalised name of
the fetched setting. For example:
iPXE> show mac
net0/mac:hex = 52:54:00:12:34:56
iPXE> dhcp && show ip
DHCP (net0 52:54:00:12:34:56)... ok
net0.dhcp/ip:ipv4 = 10.0.0.168
iPXE> show net0/6
net0.dhcp/dns:ipv4 = 10.0.0.6
Inspired-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expose settings_name(), shrink the unnecessarily large static buffer,
properly name root settings block, and simplify.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expose a function setting_applies() to allow a caller to determine
whether or not a particular setting is applicable to a particular
settings block.
Restrict DHCP-backed settings blocks to accepting only DHCP-based
settings.
Restrict network device settings blocks to accepting only DHCP-based
settings and network device-specific settings such as "mac".
Inspired-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Most callers of functions in the fetch_setting() family treat any
errors as meaning "non-existent setting". In the case of
fetch_string_setting_copy(), an existent setting can still result in
an error due to memory allocation failure.
Allow the caller to distinguish between a non-existent setting and an
error in allocating memory for the copy, by returning success (and a
NULL buffer pointer) for a non-existent setting.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
For consistency with other functions in the fetch_setting() family,
ensure that fetch_string_setting_copy() always initialises the pointer
to the fetched setting even if fetching fails.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Pass the settings block name as a parameter to register_settings(),
rather than defining it with settings_init() (and then possibly
changing it by directly manipulating settings->name).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Provide a "hexhyp" setting type, which functions identically to the
"hex" setting type except that it uses a hyphen instead of a colon as
the byte delimiter.
For example, if ${mac} expands to "52:54:00:12:34:56", then
${mac:hexhyp} will expand to "52-54-00-12-34-56".
Originally-implemented-by: Jarrod Johnson <jarrod.b.johnson@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The DHCP settings registered as a child of the netdevice settings are
not unregistered anywhere. This prevents the netdevice from being
freed on shutdown.
Fix by automatically unregistering any child settings when the parent
settings are unregistered.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Access to the gpxe.org and etherboot.org domains and associated
resources has been revoked by the registrant of the domain. Work
around this problem by renaming project from gPXE to iPXE, and
updating URLs to match.
Also update README, LOG and COPYRIGHTS to remove obsolete information.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The NFS protocol code came from legacy Etherboot and was never updated
to work as a gPXE protocol. There has been no demand for this protocol,
so this patch removes it.
I have an unfinished NFSv3 over TCP implementation for gPXE that can be
used as the base for new work, should we want to resurrect this
protocol.
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>
Currently, handling of URI escapes is ad-hoc; escaped strings are
stored as-is in the URI structure, and it is up to the individual
protocol to unescape as necessary. This is error-prone and expensive
in terms of code size. Modify this behavior by unescaping in
parse_uri() and escaping in unparse_uri() those fields that typically
handle URI escapes (hostname, user, password, path, query, fragment),
and allowing unparse_uri() to accept a subset of fields to print so
it can be easily used to generate e.g. the escaped HTTP path?query
request.
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Marty Connor <mdc@etherboot.org>
A script loaded via autoboot may want to get some of the settings (MAC
address, IP address, et cetera) for the interface via which it was
loaded, in order to pass them to the operating system. Previously such
a script had no way to determine what to put in the X of ${netX/foo}.
Solve this problem by transparently forwarding accesses to the real
settings associated with the most recently opened network device,
so scripts in this situation can say literally ${netX/foo} and get
the foo setting they want.
Signed-off-by: Marty Connor <mdc@etherboot.org>
setting_cmp() compares by option tag and then by name. Empty names
will always match, which gives us a false positive.
Fix by explicitly checking for empty names.
Modified-by: Michael Brown <mcb30@etherboot.org>
Signed-off-by: Michael Brown <mcb30@etherboot.org>
Intel's C compiler (icc) chokes on the zero-length arrays that we
currently use as part of the mechanism for accessing linker table
entries. Abstract away the zero-length arrays, to make a port to icc
easier.
Introduce macros such as for_each_table_entry() to simplify the common
case of iterating over all entries in a linker table.
Represent table names as #defined string constants rather than
unquoted literals; this avoids visual confusion between table names
and C variable or type names, and also allows us to force a
compilation error in the event of incorrect table names.
Allow for settings blocks to be created on demand. This allows for
constructions such as
set defaults/filename http://bootserver/bootfile
set defaults/priority 0xff
dhcp net0
chain ${filename}
which will boot from the DHCP-provided filename, or from
"http://bootserver/bootfile" if the DHCP server does not provide a
filename.
(Note that "priority" gets interpreted as a signed integer, so setting
"defaults/priority" to 0xff will cause the "defaults" settings block
to have an effective priority of -1.)
fetchf_uristring() was failing to handle error values from
fetch_setting(), resulting in its attempting to allocate extremely
large temporary buffers on the stack (and so overrunning the stack and
locking up the machine).
Problem reported by Shao Miller <Shao.Miller@yrdsb.edu.on.ca>.
Automatically unregister any settings with the same name (and position
within the settings tree) as a newly registered settings block.
This functionality is generalised out from dhcp.c.
This fixes a regression introduced in commit 612f4e7:
[settings] Avoid returning uninitialised data on error in fetch_xxx_setting()
in which the memset() was moved from fetch_string_setting() to
fetch_setting(), in order that it would be useful for non-string
setting types. However, this neglects to take into account the fact
that fetch_string_setting() shrinks its buffer by one byte (to allow
for the NUL) before calling fetch_setting().
Restore the memset() in fetch_string_setting(), so that the
terminating NUL is guaranteed to actually be a NUL.
Settings can be constructed using a dotted-decimal notation, to allow
for access to unnamed settings. The default interpretation is as a
DHCP option number (with encapsulated options represented as
"<encapsulating option>.<encapsulated option>".
In several contexts (e.g. SMBIOS, Phantom CLP), it is useful to
interpret the dotted-decimal notation as referring to non-DHCP
options. In this case, it becomes necessary for these contexts to
ignore standard DHCP options, otherwise we end up trying to, for
example, retrieve the boot filename from SMBIOS.
Allow settings blocks to specify a "tag magic". When dotted-decimal
notation is used to construct a setting, the tag magic value of the
originating settings block will be ORed in to the tag number.
Store/fetch methods can then check for the magic number before
interpreting arbitrarily-numbered settings.
Callers (e.g. usr/autoboot.c) may not check the return values from
fetch_xxx_setting(), assuming that in error cases the returned setting
value will be "empty" (for some sensible value of "empty").
In particular, if the DHCP server did not specify a next-server
address, this would result in gPXE using uninitialised data for the
TFTP server IP address.
This allows settings to be expanded in a way that is safe to include
within a URI string, such as
kernel http://10.0.0.1/boot.php?mf=${manufacturer:uristring}
where the ${manufacturer} setting may contain characters that are not
permitted (or have reserved purposes) within a URI.
Since whitespace characters will be URI-encoded (e.g. "%20" for a
space character), this also works around the problem that spaces
within an expanded setting would cause the shell to split command-line
arguments incorrectly.
fetch_string_setting() was subtracting one from the length of the
to-be-NUL-terminated buffer in order to obtain the length of the
unterminated buffer to be passed to fetch_setting(). This works
extremely well unless the length of the to-be-NUL-terminated buffer is
zero, at which point we end up giving fetch_setting() a buffer of
length -1UL, thereby inviting it to overwrite as much memory as it
wants...
Allow for settings to be described by something other than a DHCP option
tag if desirable. Currently used only for the MAC address setting.
Separate out fake DHCP packet creation code from dhcp.c to fakedhcp.c.
Remove notion of settings from dhcppkt.c.
Rationalise dhcp.c to use settings API only for final registration of the
DHCP options, rather than using {store,fetch}_setting throughout.
Add the notion of the settings hierarchy, complete with
register/unregister routines.
Rename set->store and get->fetch to avoid naming conflicts with get/put
as used in reference counting.
Add the concept of an abstract configuration setting, comprising a (DHCP)
tag value and an associated byte sequence.
Add the concept of a settings namespace.
Add functions for extracting string, IPv4 address, and signed and
unsigned integer values from configuration settings (analogous to
dhcp_snprintf(), dhcp_ipv4_option(), etc.).
Update functions for parsing and formatting named/typed options to work
with new settings API.
Update NVO commands and config UI to use new settings API.
Allow encapsulated options to be specified as e.g. "175.3". As a
side-effect, change the separator character for the type field from "." to
":"; for example, the IP address pseudo-option is now "175.3:ipv4".
Michael Brown