The previously introduced mechanism of generating
a git revision was only using the abbreviated hash.
That approach doesn't give a clue whether version
1.8.18.2c99bf6 is newer or older than 1.8.18.7f8d374.
The project uses tags, so `git describe` can be
employed to produce an incremental revision number
since the last tag. Version 1.8.18.13 is much more
understandable and comparable. Howerver that doesn't
answer the question "what codebase was used". To
address that, the abbreviated hash should also be
preserved. Hence, this commit introduces a new
versioning scheme like `1.8.18.13.gee01aa5`.
For git snapshots when git program is absent the
version will be like `1.8.18.0.gsnapshot`.
For cases when .git directory is missing (Release
compilation?) the suffix part will be omitted
completely yielding a version like `1.8.18`.
The suffix generation has been moved to the added
csv-revision script. The script is absolutely
POSIX-ly correct and doesn't require XSI or any
other POSIX extensions.
The get_fru_area_str() function is used to decode FRU area
fields into text. Areas may be encoded as text, binary,
BCDplus or 6-bit ASCII. Decoding of 6-bit ASCII and BCDplus
was broken. There was an error in the formulas used to
calculate the resulting string length, plus the decoding
formulas for BCDplus was wrong.
For BCDplus the resulting length was considered equal
the encoded data length, while in fact it's twice as big.
Only one character instead of two was being extracted from
a single input byte while two nibbles must have been taken
into account.
For 6-bit ASCII rounding of 3 to 4 bytes conversion was done
improperly adding 2 to the original length instead of the
result of multiplication.
Ekanalyzer was not reading the type/length byte for the 2nd and
subsequent custom fields. Also the message it displayed when
lacked data for custom fields was very relaxing and incorrect.
Got rid of the field decoding code that was only capable of
processing ASCII and binary fields, and switched to using
get_fru_area_str() that can also decode BCDplus and 6-bit ASCII
and maybe will eventually be enabled to decode Unicode text
as well.
This is the first step to completely get rid of the completely
awfully written FRU data decoding functionality of ekanalyzer
that essentially duplicates that of ipmi_fru.c module.
Replace the static 'csv' suffix with a short hash
and a 'dirty' mark (when the tree is modified).
When git is not available, '.git_snapshot' suffix
will be used.
Currently, when a LAN parameter set command is sent through ipmitool, the
corresponding parameter data is requested and compared to the command to verify
that the data was written correctly. Since we do send the VLAN ID in this return
data, regardless of whether VLAN is disabled or not, this mismatch between
requested and received parameters causes ipmitool to retry the command 10 times
and return an error.
ipmitool is sending "0x00 0x00" reading back data from BMC as "0x01 0x00" which
is NOT matching & hence pops up the error /warning "LAN Parameter Data does not
match! Write may have failed."
After 10 retries when we check "ipmitool lan print" VLAN ID is disabled
successfully.
c&p from the ticket:
~~~
When I try to use CVS-ipmitool on Ubuntu 8.04 x86_64 to talk to a SuperMicros
SIMSO-HTC (Rev. 2.5, IPMI 2.0) chip on a X7SBi-Board via SOL I often get doubled
characters when typing fast, making the SOL interface basically unusable for
anyone accustomed to using a keyboard for longer than a month ;)
At first I thought this was an issue with SuperMicros implementation of the
protocol and/or the flow control
setup on the machine, but their own app works fine (but not the Linux CLI, which
is maybe
based on ipmitool?). But after reading the IPMI 2.0 SOL specs and watching the
debug output for a bit, it seems that is really an issue with lanplus-SOL
protocol implentation of ipmitool in general.
Specifically, in lanplus.c:ipmi_lanplus_send_payload, when waiting for a SOL
response the case that a non SOL packet is returned is not being
checked. Also the "if (is_sol_packet(rsp) && rsp->data_len)" branch does
terminate with a break, but instead goes for a send try, that seems
counterintuitive, Both these things cause doubled characters for me.
The attached patch seems to solve these issues in my case, but I don't claim to
fully understand your protocol code and/or the protocol, so maybe it will cause
problems elsewhere, especially under packet loss conditions.
~~~
Commit implements `Enable status` which shows/is in alignment with (22.27) Get
User Access Command and displays User ID Enable/Disable status of given User ID
at given channel.
PICMG 3.1 R2.0 introduces new a new Link Class field in the FRU
Link Descriptors which is the upper 4 bits of the Link Type field.
This new Link Class field specifies SERDES lanes with 10.3125Gbd
signalling rate.
It also introduces the new Base-KX and Base-KX4 types which are the
new IEEE replacements for the PICMG 3.0 Base-BX and Base-BX4 types.
This patch decodes these new types and fields and will print out
proper descriptions for each one based on PICMG 3.1 R2.0
PICMG extension 5(UTCA, MicroTCA) is not detected as valid extension.
The following patch fixes that at one place. In the second place the board type
is detected in a similar way, but it isn't clear if a patch is needed there, too.
In the new version of ipmitool 1.8.15 and above, sol deactivate command was not
closing the session, This patch is to fix close console session When we issue
sol deactivate command.
Commit adds a check as a workaround for segfault reported in ID:335. However,
the proper fix is to rewrite parts of lib/ipmi_hpmfwupg.c not to put whole
firmware image into memory. Also, MD5 checksum part needs to be rewritten,
because it won't work for large firmware images.
Commit adds a check as a workaround for segfault reported in ID:335. However,
the proper fix is to rewrite parts of lib/ipmi_hpmfwupg.c not to put whole
firmware image into memory. Also, MD5 checksum part needs to be rewritten,
because it won't work for large firmware images.
The netfn structures are populated sequentially in the _gather_info
function and they are accessed only by even indices (and to the double
of its real length). This results in a segmentation fault if you run
* ipmitool firewall reset
This patch fixes the behaviour so that the ipmi_firewall_reset function
treats the structure the same way as the rest of the code does.
Signed-off-by: Boris Ranto <branto@redhat.com>
