Name |
Date |
Size |
#Lines |
LOC |
||
---|---|---|---|---|---|---|
.. | - | - | ||||
Makefile.am | H A D | 05-Feb-2014 | 2 KiB | 46 | 12 | |
README.lanplus | H A D | 05-Feb-2014 | 4.1 KiB | 75 | 60 | |
README.sol | H A D | 05-Feb-2014 | 3.6 KiB | 77 | 60 | |
asf.h | H A D | 05-Feb-2014 | 2.5 KiB | 76 | 35 | |
lanplus.c | H A D | 01-Aug-2015 | 96.4 KiB | 3,670 | 2,229 | |
lanplus.h | H A D | 05-Feb-2014 | 4.9 KiB | 127 | 61 | |
lanplus_crypt.c | H A D | 11-Mar-2015 | 24.7 KiB | 935 | 481 | |
lanplus_crypt.h | H A D | 05-Feb-2014 | 3.1 KiB | 76 | 31 | |
lanplus_crypt_impl.c | H A D | 05-Feb-2014 | 7.6 KiB | 294 | 143 | |
lanplus_crypt_impl.h | H A D | 05-Feb-2014 | 2.3 KiB | 67 | 25 | |
lanplus_dump.c | H A D | 05-Feb-2014 | 6.5 KiB | 193 | 131 | |
lanplus_dump.h | H A D | 05-Feb-2014 | 2 KiB | 46 | 7 | |
lanplus_strings.c | H A D | 05-Feb-2014 | 2.3 KiB | 40 | 32 | |
rmcp.h | H A D | 05-Feb-2014 | 2.6 KiB | 83 | 39 |
README.lanplus
1This interface exists to provide a means of connecting to an IPMIv2 enabled 2BMC. In some places, the IPMIv2 specification is either unclear or 3inconsistent, and interpretations of the intent of the specification had to 4be made at the discretion of the implementor. The purpose of this 5document is to make those decisions clear so that 1) they can be reviewed 6by others and 2) so that the rationale for those decisions can be made 7clear. 8 9* Though it's not stated explicitly with which algorithm the K1 and K2 keys 10should be generated, we chose to use the authentication algorithm. The 11specification states that K1 and K2 are generated with an HMAC algorithm, 12and all of the authentication algorithms (except for "none") are HMAC 13algorithms, whereas the integrity algorithms are not all HMAC. See section 1413.32 for details about K1 and K2, and section 15 16 17* The IPMIv2 specification describes a key, Kg, that is the "BMC key". 18This key functions as a global key that is required to be known in addition 19to the user's key, by authenticating users. If the BMC has a null Kg, the 20users key, Kuid, is used in its place in algorithms where Kg is required, 21per the specification section 13.33. A user can obtain the status of Kg by 22querying the BMC with the Get Channel Authentication Capabilities command. 23Currently, this implementation does not provide a way for a user to specify 24Kg for BMCs that require it. 25 26 27* The specification is unclear as to which key is used for HMAC based 28integrity checking. One the one hand, section 13.28.4 states explicitly 29that HMAC integrity algorithms use the session integrity key as the HMAC 30key. Confusing that matter is a statement in section 13.32 regarding the 31creation of additional keying material. In this section it is stated that 32"all keying material for the RSP integrity and confidentiality algorithms 33will be generated by processing a pre-defined set of constants using HMAC 34per [RFC2104], keyed by sik". And "For the mandatory-to-implement 35integrity and confidentiality algorithms defined in this specification, 36processing the first two (2) constants will generate the require amount of 37keying material." We decided to use K1 as our HMAC key for the generation 38of authentication codes (integrity checking). Furthermore, we are using 39all 20 bytes of K1. 40 41 42* IPMIv2 compliant BMCs are supposed to support 20 byte passwords, as well 43store metadata describing whether the password was stored as a 16 byte or 4420 byte class password. We do not currently support 20 byte passwords. It 45should be noted that there are obvious mistakes in the SET USER PASSWORD 46command specification, as it mentions the ability to query for 16/20 byte 47password status, but the packet format does not support this. 48 49 50* The IPMIv2 specification describes a type of login called a "role only 51login." This feature allows a user to login providing only a requested 52privilege level and a password. We do not currently support this feature. 53Supporting this feature would only require the ability to specify 54username/privilege lookups in the RAKP 1 message sent from ipmitool. We 55currently specify the use of username only lookups for authentication. 56 57 58* In the IPMIv2 packet description in table 13-8 of the IPMv2 59specification, there are two fields that are rather ambiguous in meaning. 60The fields are "Pad Length" and "Next Header". Although neither field is 61listed as belonging to the IPMIv2 packet format, we include/expect them 62both in our IPMIv2 packets. Are rationale is 1) the Next Headers field's 63comment states what the value of that field should be for IPMIv2, and 2) 64for the most part the ASF and IPMIv2 fields seem to parallel each other, 65and we feel that the Pad Length and Next Header fields were left out of the 66IPMIv2 column by mistake. 67 68 69* The GET CHANNEL CIPHER SUITES command documentation seems to have 70mistakes. The "start of record" byte is stated to be either 0x30 or 0x31, 71whereas the detailed description in table 22-18 leads us to believe that 72this byte should really be 0xC0 or 0xC1. Also the description of bits 5:0 73in the start of record byte should probably be 00_0000 rather than 00_000. 74 75
README.sol
1This document was last updated for release 1.8.8. 2 3This document explains how Serial Over Lan is implemented on in the 4ipmitool IPMI client. Obviously, the code itself is authoritative, but 5this document should serve as a good starting point. 6 7Serial Over Lan (SOL) is defined in the IPMI v2 specification published by 8Intel and available at http://www.intel.com/design/servers/ipmi/. SOL 9functionality is built on top of the RMCP+ protocol as an additional 10payload type (type 1). 11 12The high end SOL logic is implemented in src/ipmitool/lib/ipmi_sol.c. SOL 13sessions are begun in ipmitool using the "sol activate" command. This 14command maps directly to the IPMI Activate Payload command. It first 15verifies that an RMCP+ session (lanplus interface) is being used to 16establish the session. Although the spec allows for a SOL connection to be 17established on a port different than the RMCP+ port that the "activate 18payload" command issued, ipmitool does not support this. 19 20Once a session has been established (the activate payload command 21succeeds), ipmitool simply loops over a select() on user input and data 22returned from the BMC. All user input is first filtered so that special 23escape sequences can suspend or deactivate the SOL session and so that data 24can be broken into chunks no greater than N bytes. This maximum is 25specified by the BMC in the response to the Activate Payload command. 26 27User input to the BMC is handled in ipmitool/src/plugins/lanplus/lanplus.c. 28Every SOL packet (with one exception) traveling in either direction causes 29the recipient to return an acknowledgement packet, though acks themself are 30not acknowledged. The transport layer in lanplus.c handles the logic 31regarding acks, partial acks, sequence numbers. SOL acknowledgements 32packets be acks, partial acks (the remote destination processed only some 33of the data), and nacks (requests to stop sending packets). Nacks are not 34honored by ipmitool. 35 36Note that one way that SOL communication differs from standard IPMI 37commands, is that it is not simply a request response protocol. Packets 38may be returned asyncrhonously from the BMC. When establishing a SOL 39session, ipmitool registers a callback for asynchonously received data. 40This call back simply prints text returned from the BMC. 41 42Once a user has chosen to exit the SOL session (with ~.) ipmitool sends the 43IPMI SOL Deactivate command to the BMC. 44 45The standard code path for SOL logic follows: 46 ipmi_sol_main (ipmi_sol.c): 47 48 ipmi_sol_activate (ipmi_sol.c): 49 Argument validation 50 Creation and dispatch of IPMI Activate Payload command 51 52 ipmi_sol_red_pill (ipmi_sol.c): 53 Loop on select() for user input and data returned from the BMC 54 Periodic dispatch of "keep alive" packet to the BMC. 55 Send user input to the BMC and BMC data to the console. 56 57 processSolUserInput (ipmi_sol.c): 58 Process possible escape sequences (~., ~B, etc.) 59 Send (with retries) user data to the BMC 60 Partial creation of packet payload 61 62 ipmi_lanplus_send_sol (lanplus.c): 63 Completion of packet payload 64 Send (with retries) of SOL packet 65 66 ipmi_lanplus_send_payload (lanplus.c): 67 Creation of RMCP+ packet 68 Details general to all V2 packet processing, as 69 well as a some logic to handle ack reception. 70 71 is_sol_partial_ack (lanplus.c): 72 Determine whether a data needs to be resent 73 74 ipmi_lanplus_recv_sol (lanplus.c): 75 Handle data received by the BMC. Ack as appropriate. 76 77