From IPMI Spec, Chapter 22.22 Set Channel Access Command
Table 22, Set Channel Access Command
Byte#2, Bit#5 is "PEF Alerting Enable/Disable"
And the bit value:
0b = enable PEF Alerting
1b = disable PEF Alerting on this channel
In current code, alert "on" set Bit#5 to 1 and alert "off" set Bit#5 to
0, it's straightforward but just opposite of IPMI spec bit definition.
Resolvesipmitool/ipmitool#247
Reported-by: Ryan Fang <Ryan.Fang@quantatw.com>
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Both 'Set/Get LAN Configuration Parameter' commands may return
command-specific codes that weren't properly parsed and were
reported as 'Unknown' before. This is fixed now.
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Unify the comparison idioms use.
Always use `if(!strcmp())` for "if string equals"
and `if(strcmp())` for "if string is not equal".
Never use `== 0` and `!= 0` with `strcmp()`.
Minor reformatting of the code immediately surrounding the
refactored lines.
Resolvesipmitool/ipmitool#104
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Clean up use of strcmp/strncmp/strncasecmp for command line arguments.
Never use anything but `strcmp()` unless absolutely neccessary.
Partialy resolvesipmitool/ipmitool#104
Commit 6e2b688e introduced a bug due to which VLAN id range checking
was negated and resulted in error messages printed for correct VLAN ids.
Resolvesipmitool/ipmitool#55
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Move static objects declared in headers to the source files where
they're used.
Partially resolvesipmitool/ipmitool#13
Signed-off-by: Patrick Venture <venture@google.com>
Before this fix `ipmitool` would complain that VLAN ID
is out of range when trying to disable an already disabled VLAN
on a lan channel. With this fix it will properly report that
VLAN is already disabled.
Resolvesipmitool/ipmitool#55
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Remove all direct comparisons to 'NULL' for pointers.
Replace them with boolean-like 'if (ptr)' and 'if (!ptr)'.
This makes conditions shorter and easier to read.
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Make code better readable by replacing `if (rsp->ccode > 0)`
and 'if (rsp->ccode != 0)' with just `if (rsp->ccode)` as
rsp->ccode is anyway an unsigned byte and can't be negative.
Also replace 'if (rsp->ccode == 0)' with 'if (!rsp->ccode)'.
All these changes make lines shorter and easier to read as
a non-zero ccode is an indication of some failure, and so !ccode
naturally reads as 'no error'.
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
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.
Redundant call for find_lan_channel() for several 'lan' commands
produces misguiding error output. Those commands require expicit
specification of the channel number and calling to find_lan_channel()
for them is useless. For the rest 'lan' commands which allow
ommiting of the channels number, the find_lan_channel() is called
additionally.
Commit is a rewrite of ipmi_set_channel_access(). Function utilizes _ipmi_*()
functions now in order to avoid code repetition. Other than that, functionality
should remain the same.
