The path MTU is currently hardcoded to 1460 bytes, which fails to
allow space for TCP options. Sending a maximum-sized datagram (which
is viable when using HTTP POST) will therefore fail since the Ethernet
MTU will be exceeded.
Reduce the hardcoded path MTU to produce a maximum datagram of 1280
bytes, which is the size required of data link layers by IPv6. It is
a reasonable assumption that all intermediary data link layers will be
able to convey this packet without fragmentation, even for IPv4.
Note that this reduction has a minimal impact upon download
throughput, since it affects only the transmit data path.
Originally-fixed-by: Suresh Sundriyal <ssundriy@vmware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Replace the existing partially-implemented IPv6 stack with a fresh
implementation.
This implementation is not yet complete. The IPv6 transmit and
receive datapaths are functional (including fragment reassembly and
parsing of arbitrary extension headers). NDP neighbour solicitations
and advertisements are supported. ICMPv6 echo is supported.
At present, only link-local addresses may be used, and there is no way
to specify an IPv6 address as part of a URI (either directly or via
a DNS lookup).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[neighbour] Generalise concept of neighbour discovery
Split the protocol-independent portions of arp.c into a separate file
neighbour.c, to allow for sharing of functionality between IPv4+ARP
and IPv6+NDP.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
IPv6 link-local socket addresses require some way to specify a local
network device. We cannot simply use a pointer to the network device,
since a struct sockaddr_in6 may be long-lived and has no way to hold a
reference to the network device.
Using a network device index allows a socket address to cleanly refer
to a network device without worrying about whether or not that device
continues to exist.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Give tap devices a meaningful name, and avoid segmentation faults when
attempting to retrieve ${net0/bustype} by assigning a new bus type for
tap devices.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for configurable provision of built-in settings by placing them
in a linker table rather than an array.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Prevent the card from flagging packets of 1518 bytes length as
overlength.
This fixes the High-MTU loopback test.
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The 3c90x B and C revisions support rounding up the packet length to a
specific boundary. Disable this feature to avoid overlength packets.
This fixes the loopback test.
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[3c90x] Stall upload engine before setting RX ring address
According to the 3c90x datasheet we have to stall the upload (receive)
engine before setting the receive ring address.
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow HTTP POST requests to be generated when the URI includes a
parameter list. For example:
#!ipxe
params
param mac ${net0/mac}
param uuid ${uuid}
param asset ${asset}
chain http://boot.ipxe.org/demo/boot.php##params
Signed-off-by: Michael Brown <mcb30@ipxe.org>
HTTP POST requires the ability to associate a parameter list with a
URI. There is no standardised syntax for this. Use a non-standard
URI syntax to incorporate the specification of a parameter list within
a URI:
URI = [ absoluteURI | relativeURI ]
[ "#" fragment ] [ "##params" [ "=" paramsName ] ]
e.g.
http://boot.ipxe.org/demo/boot.php##paramshttp://boot.ipxe.org/demo/boot.php##params=mylist
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Expose memory map via settings mechanism
Allow memory map entries to be read using the syntax
${memmap/<region>.<properties>.<scale>}
where <region> is the index of the memory region, <properties> is a
bitmask where bit 0 represents the start address and bit 1 represents
the length (allowing the end address to be encoded by having both bits
0 and 1 set), and <scale> is the number of bits by which to shift the
result.
This allows for several values of interest to be encoded. For
example:
${memmap/<region>.1.0:hexraw} # 64-bit start address of <region>
${memmap/<region>.2.0:hexraw} # 64-bit length of <region>, in bytes
${memmap/<region>.3.0:hexraw} # 64-bit end address of <region>
${memmap/<region>.2.10:int32} # Length of <region>, in kB
${memmap/<region>.2.20:int32} # Length of <region>, in MB
The numeric encoding is slightly more sophisticated than described
here, allowing a single encoding to cover multiple regions. (See the
source code for details.) The primary use case for this feature is to
provide the total system memory size (in MB) via the "memsize"
predefined setting.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Allow numeric_setting_value() to handle long setting values
Allow numeric_setting_value() to handle e.g. the byte sequence
00:00:00:00:12:34:56:78
by returning -ERANGE only if the value actually overflows the return
type.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Expose CPUID instruction via settings mechanism
Allow CPUID values to be read using the syntax
${cpuid/<register>.<function>}
For example, ${cpuid/2.0x80000001} will give the value of %ecx after
calling CPUID with %eax=0x80000001. Values for <register> are encoded
as %eax=0, %ebx=1, %ecx=2, %edx=3.
The numeric encoding is more sophisticated than described above,
allowing for settings such as the CPU model (obtained by calling CPUID
with %eax=0x80000002-0x80000004 inclusive and concatenating the values
returned in %eax:%ebx:%ecx:%edx). See the source code for details.
The "cpuvendor" and "cpumodel" settings provide easy access to these
more complex CPUID settings.
This functionality is intended to complement the "cpuid" command,
which allows for testing individual CPUID feature bits.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[udp] Move high-frequency debug messages to DBGLVL_EXTRA
This makes it possible to leave UDP debugging enabled in order to see
interesting UDP events, without flooding the console with at least one
message per packet.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The "inc" command allows the numeric value of a setting to be
incremented, allowing for the construction of simple loops within an
iPXE script.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow commands to be placed on the same line as a label. This allows
for improved legibility of loop constructions by incorporating the
loop check condition into the same line as the loop label. For
example, to iterate over network devices using the forthcoming "inc"
command:
set idx:int16 0
:loop isset ${net${idx}/mac} || goto loop_done
echo net${idx} is a ${net${idx}/chip} with MAC ${net${idx}/mac}
inc idx && goto loop
:loop_done
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[script] Allow initial whitespace on lines containing labels
Initial whitespace is already accepted on lines containing commands,
since it gets ignored by the system() call. Minimise surprise and
allow for neater indentation of scripts by also allowing whitespace on
lines containing labels.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Eliminate calls to {fetch,store}f_named_setting() in NVO commands
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>
[settings] Eliminate call to fetchf_named_setting() in expand_settings()
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>
[settings] Change "not-found" semantics of fetch_setting_copy()
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>
Michael Brown