A deliberate side effect of this commit is that the "read" command
will now preserve the type of the setting, if the setting name
contains no type information. For example:
iPXE> set foo:ipv4 192.168.0.1
iPXE> read foo
192.168.0.100
iPXE> show foo
foo:ipv4 = 192.168.0.100
rather than the arguably unexpected behaviour of resetting the type to
"string".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use parse_setting_name() and fetchf_setting_copy() in
expand_settings(), to eliminate the call to fetchf_named_setting().
This change also eliminates the potentially large stack-allocated
buffer in expand_settings().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
fetch_settings_copy() currently returns success and a NULL data
pointer to indicate a non-existent setting. This is intended to allow
the caller to differentiate between a non-existent setting and an
error in allocating memory for the copy of the setting.
The underlying settings blocks' fetch() methods provide no way to
perform an existence check separate from an attempt to fetch the
setting. A "non-existent setting" therefore means simply a setting
for which an error was encountered when attempting to fetch from every
settings block within the subtree.
Since any underlying error within a settings block (e.g. a GuestRPC
failure when attempting to retrieve a VMware GuestInfo setting) will
produce the effect of a "non-existent setting", it seems somewhat
meaningless to give special treatment to memory allocation errors
within fetch_setting_copy().
Remove the special treatment and simplify the semantics of
fetch_setting_copy() by directly passing through any underlying error
(including non-existence) encountered while fetching the setting.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
There are currently two conflicting usages of the term "named setting"
within iPXE: one refers to predefined settings (such as show up in the
"config" UI), the other refers to settings identified by a name (such
as "net0.dhcp/ip").
Split these usages into the term "predefined setting" and "named
setting" to avoid ambiguity.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Our use of --gc-sections causes the linker to discard the symbols
defined by FILE_LICENCE(), meaning that the resulting licence
determination is incomplete.
We must use the KEEP() directive in the linker script to force the
linker to not discard the licence symbols. Using KEEP(*(COMMON))
would be undesirable, since there are some symbols in COMMON which we
may wish to discard.
Fix by placing symbols defined by PROVIDE_SYMBOL() (which is used by
FILE_LICENCE()) into a special ".provided" section, which we then mark
with KEEP(). All such symbols are zero-length, so there is no cost in
terms of the final binary size.
Since the symbols are no longer in COMMON, the linker will reject
symbols with the same name coming from multiple objects. We therefore
append the object name to the licence symbol, to ensure that it is
unique.
Reported-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The getopt API defines optind as a global variable. When used by the
"autoboot" command, the payload function passed to ifcommon_exec() may
result in a new iPXE script being executed; the commands therein would
then overwrite the value of optind. On returning, ifcommon_exec()
would continue processing the list of interfaces from an undefined
point.
Fix by using a local variable to hold the index within the list of
interfaces.
Reported-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some hardware (observed with an onboard RTL8168) will erroneously
report a buffer overflow error if the received packet exactly fills
the receive buffer.
Fix by adding an extra four bytes of padding to each receive buffer.
Debugged-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add support for page up, page down, home and end keys, matching the
navigation logic used in the menu user interface.
Originally-implemented-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Adrian Jamróz <adrian.jamroz@gmail.com>
Modified-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow long script lines to be broken up using backslash continuation.
For example:
choose --default linux --timeout 3000 os \
&& goto boot_${os} || goto cancelled
Requested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
base16_encode() will fail to generate a terminating NUL if the length
of the raw data is zero, since the loop calling sprintf() will never
execute.
Fix by explicitly terminating the result with a NUL.
Reported-by: Marin Hannache <git@mareo.fr>
Debugged-by: Marin Hannache <git@mareo.fr>
Tested-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Replace the old via-rhine driver with a new version using the iPXE
API.
Includes fixes by Thomas Miletich for:
- MMIO access
- Link detection
- RX completion in RX overflow case
- Reset and EEPROM reloading
- CRC stripping
- Missing cpu_to_le32() calls
- Missing memory barriers
Signed-off-by: Adrian Jamróz <adrian.jamroz@gmail.com>
Modified-by: Thomas Miletich <thomas.miletich@gmail.com>
Tested-by: Thomas Miletich <thomas.miletich@gmail.com>
Tested-by: Robin Smidsrød <robin@smidsrod.no>
Modified-by: Michael Brown <mcb30@ipxe.org>
Tested-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Include a sequence number as the first four bytes of the loopback test
packet payload. When a content mismatch occurs, this gives some
information about the source of the mismatched packet.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow any iPXE command expecting a network device name to accept
"netX" as a synonym for "most recently opened network device".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a facility for settings blocks to act as symbolic links to other
settings blocks, and reimplement the "netX" virtual settings block
using this facility.
The primary advantage of this approach is that unscoped settings such
as ${mac} and ${filename} will now reflect the settings obtained from
the most recently opened network device: in most cases, this will mean
the settings obtained from the most recent DHCP attempt. This should
improve conformance to the principle of least astonishment.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow values to be read from PCI configuration space using the syntax
${pci/<busdevfn>.<offset>.<length>}
where <busdevfn> is the bus:dev.fn address of the PCI device
(expressed as a single integer, as returned by ${net0/busloc}),
<offset> is the offset within PCI configuration space, and <length> is
the length within PCI configuration space.
Values are returned in reverse byte order, since PCI configuration
space is little-endian by definition.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move VMWARE_SETTINGS build configuration option from config/sideband.h
to a new config/settings.h.
Existing instances of config/local/sideband.h will not be affected,
since config.c still #includes config/sideband.h.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow network device's "busloc" setting to be formatted as a PCI
bus:dev.fn address using e.g. ${net0/busloc:busdevfn}.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use hex_decode() to parse "hex" and "hexhyp" settings. Note that this
parser is stricter than the old parser; it now requires exactly two
hex digits for each byte. (The old parser was based upon strtoul()
and so would allow leading whitespace and a leading plus or minus
sign.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Provide a generic hex_decode() routine which can be shared between the
Base16 code and the "hex" and "hexhyp" settings parsers.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
On large networks with substantial numbers of monitoring agents,
unwanted TCP connection attempts may end up flooding iPXE's ARP cache.
Fix by silently dropping packets received for unrecognised TCP
connections. This should not cause problems, since many firewalls
will also silently drop any such packets.
Reported-by: Jarrod Johnson <jarrod.b.johnson@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown