After a more accurate reading of RFC 3720, it becomes clear how NOPs
are supposed to work. The current implementation (which just ignores
NOP-Ins) is sufficient to cope with NOP-Ins sent to update CmdSN, but
will need to be extended before it can cope with NOP-Ins sent as iSCSI
keepalives.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some iSCSI targets (observed with a Synology DS207+ NAS) send
unsolicited NOP-Ins to the initiator. RFC 3720 is remarkably unclear
and possibly self-contradictory on how NOPs are supposed to work, but
it seems as though we can legitimately just ignore any unsolicited
NOP-In PDU.
Reported-by: Marc Lecuyer <marc@maxiscreen.com>
Originally-implemented-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow functions other than realloc() to be used to reallocate DHCP
option block data, and specify the reallocation function at the time
of calling dhcpopt_init().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The max_len field is never used, and the len field is used only by
dhcp_tx(). Remove these two fields, and perform the necessary trivial
calculation in dhcp_tx() instead.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
For IPoIB, we currently use the hardware address (i.e. the eight-byte
GUID) as the DHCP chaddr. This works, but some PXE servers (notably
Altiris RDP) refuse to respond if the chaddr field is anything other
than six bytes in length.
We already have the notion of an Ethernet-compatible link-layer
address, which is used in the iBFT (the design of which similarly
fails to account for non-Ethernet link layers). Use this as the first
preferred alternative to the actual link-layer address when
constructing the DHCP chaddr field.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some network cards automatically strip the VLAN header, providing the
VLAN tag via a side channel such as a completion queue entry. These
cards need to be able to report receive completions directly against
the relevant VLAN device.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
VLAN device names have the form "netX.Y", e.g. "net0.5" for VLAN 5 on
net0. This use of "." conflicts with the use of "." as the
hierarchical separator in settings block names, with the result that
VLAN device settings cannot be accessed by name.
It would be trivial to treat the VLAN device settings as being a child
of the trunk device settings, but this would cause the VLAN device
settings to be applied to the trunk device: for example, setting
"net0.5/ip" would then apply the IP address to both net0.5 and net0.
Fix by changing the VLAN device name to use "-" instead of ".": the
VLAN device "net0.5" is now "net0-5".
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>
Almost all FIP packets contain at most one instance of each
descriptor. A VLAN notification may contain multiple VLAN
descriptors. The FCoE specification does not provide any guidance
regarding prioritisation of VLANs, so we may choose to arbitrarily
choose the first listed VLAN.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The increase in length in Fibre Channel device names causes the
"selected FCF" message to wrap beyond 80 characters. Fix by using
abbreviations where possible.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Create the Fibre Channel port only when the FCoE port has selected a
Fibre Channel Forwarder to use. This avoids the confusion of having
an FC port created for the network device on which only VLAN discovery
is performed.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Several use cases (e.g. the UNDI API and the EFI SNP API) require
access to the raw network device receive queue, and so currently use
manual calls to netdev_poll() on a specific network device in order to
prevent received packets from being processed by the network stack.
As an alternative, provide a flag that allows receive queue processing
to be frozen on a per-device basis. When receive queue processing is
frozen, packets will be enqueued as normal, but will not be
automatically dequeued and passed up the network stack.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Fix typographical error from commit ea631f6 ("[list] Add
list_first_entry()"). The symptom was PXELINUX 3.86 causing a stack
overflow under VMware.
Tested-by: Shao Miller <shao.miller@yrdsb.edu.on.ca>
Signed-off-by: Shao Miller <shao.miller@yrdsb.edu.on.ca>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow fc_ulp_decrement() to guarantee to fc_peer_decrement() that the
peer reference remains valid for the duration of the call, by ensuring
that ulp->peer remains valid while ulp is valid.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow link examination methods to safely assume that their
self-reference remains valid for the duration of the method call.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Calling a timer's expiry method may cause arbitrary consequences,
including arbitrary modifications of the list of retry timers.
list_for_each_entry_safe() guards against only deletion of the current
list entry; it provides no protection against other list
modifications. In particular, if a timer's expiry method causes the
subsequent timer in the list to be deleted, then the next loop
iteration will access a timer that may no longer exist.
This is a particularly nasty bug, since absolutely none of the
list-manipulation or reference-counting assertion checks will be
triggered. (The first assertion failure happens on the next iteration
through list_for_each_entry(), showing that the list has become
corrupted but providing no clue as to when this happened.)
Fix by stopping traversal of the list of retry timers as soon as we
hit an expired timer.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
There are several points in the iPXE codebase where
list_for_each_entry() is (ab)used to extract only the first entry from
a list. Add a macro list_first_entry() to make this code easier to
read.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Functions that instantiate objects generally own one reference to the
object being created. The error paths must therefore usually call
ref_put() to release this reference.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The FCP command reference number is intended to be used for
controlling precise delivery of FCP commands, rather than being an
essentially arbitrary tag field (as with iSCSI and SRP).
Use the Fibre Channel local exchange ID as the tag for FCP commands,
instead of the FCP command reference. The local exchange ID does not
appear within the FCP IU itself, but does appear within the FC frame
header; debug traces can therefore still be correlated with packet
captures.
Reported-by: Hadar Hen Zion <hadarh@mellanox.co.il>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 5f4ab0d ("[iscsi] Randomise a portion of the ISID to force new
session instantiation") introduced a regression by randomising the
ISID on each call to iscsi_start_login(), which may be called more
than once per connection, rather than on each call to
iscsi_open_connection(), which is guaranteed to be called only once
per connection. This is incorrect behaviour that causes our
connection to be rejected by some iSCSI targets (observed with a
COMSTAR target under OpenSolaris).
Fix by generating the ISID in iscsi_open_connection(), and storing the
randomised ISID as part of the session state.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When a connection to an iSCSI target is broken without gracefully
closing the TCP socket, a subsequent connection attempt may fail
because the target believes that we are attempting session
reinstatement (see RFC3720 section 5.3.1). This has been observed
using the Microsoft iSCSI target.
Section 9.1.1 of RFC3720 states that initiators should use a stable
ISID, however section 5.3.1 shows that the only way to explicitly
request that a new session be created is to use a new ISID.
Fix by randomising the "qualifier" portion of the ISID.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We currently set both the FP and SP bits in our FIP FLOGI, to allow
the FCF the choice of selecting either a fabric-provided or a server-
provided MAC address. This complies with the FCoE specification, but
has been observed to result in an FLOGI rejection from some FCFs.
Fix by recording whether or not the FCF supports SPMA, and requesting
only one of FPMA or SPMA in our FIP FLOGI. We choose to prefer SPMA
where available, because many iPXE drivers will not be able to receive
unicast packets sent to a non-default MAC address.
Reported-by: Hadar Hen Zion <hadarh@mellanox.co.il>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
(Ab)use the "secs" field in transmitted DHCP packets to convey
metadata about the DHCP session state. In particular:
bit 0 represents the receipt of a ProxyDHCPOFFER
bit 1 represents the receipt of a DHCPOFFER
bits 2+ represent the transmitted packet sequence number
This allows some relevant information about the internal state of the
DHCP session to be read out from a packet trace from a non-debug build
of iPXE. It also potentially allows replies to be correlated to their
requests (for servers that copy the "secs" field from request to
reply).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some ProxyDHCP implementations seem to violate the PXE specification
by expecting the client to retain options from the ProxyDHCPOFFER
rather than issuing a separate ProxyDHCPREQUEST.
Work around such broken clients by retaining the ProxyDHCPOFFER
packet, and proceeding to a ProxyDHCPREQUEST only if the
ProxyDHCPOFFER does not already contain PXE options.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown