On 12/09/13 11:05, Thomas Mieslinger wrote:
[...]
It would be helpful for that overview page if I could display the
switchport right away.
So for me, I'd just need PortID and PortDescr. But for other uses, I
guess that ChassisID, SysName and SysDescr could be useful.
For naming ipxe variables, I'd propose the trick to compose the name of
a prefix and the original variable name. Example: lldp-PortDescr which
then would be used as ${net0/lldp-PortID:uristring}.
Ok, so the next step would be wait for the approval of the variable
names and then to propose a patch.
From a quick look at the LLDP specs, it seems as though the mapping
${net0.lldp/<length>.<offset>.<type>}
might be reasonably natural, where <type> is the LLDP TLV type, and
<offset> and <length> describe the offset and length of the desired data
within the TLV value. (As a special case, a <length> of zero could
indicate "all remaining data".)
This would allow for some fairly simple encodings of simple values, e.g.
${net0.lldp/4:string} for the Port Description
${net0.lldp/5:string} for the System Name
${net0.lldp/3:uint16} for the Time To Live
while also allowing for access to the more complex LLDP data structures
${net0.lldp/1.0.1:uint8} for the Chassis ID Subtype
${net0.lldp/1.1:hex} for the Chassis ID
There seems to be no way to solicit LLDP information; iPXE would just
have to wait for an LLDP packet to arrive. This wait could be
implemented within an iPXE script, e.g.:
ifopen
:lldp
isset ${net0.lldp/1} && goto lldp_done
sleep 1
goto lldp
:lldp_done
I'm assuming that we need to support only point-to-point LANs, and that
we can get away with receive-only operation (i.e. no need to transmit
our own LLDP information).
Michael
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
