Kazuyuki Funada
2014-04-11 09:25:58 UTC
Hello. I'm a newbie in this list and I have a question about current implementation of lanplus for retry.
Our firmware developers including me have faced a issue that target controller occasionally returns 0xc1 response to "Get Chassis Status" command.
We found the issue happened when target controller could not respond within 1 second and ipmitool retried sending packet. We checked debugging output of ipmitool and understood the mechanism was below.
- user issued command(netfn=0x00 command=0x01) by ipmitool using lanplus I/F
- ipmitool sent command(netfn=0x06 command=0x01) and added it to list with seq#2
(target controller did not respond within 1 second)
- ipmitool sent command again and added it to list with seq#2
- target controller sent response for 1st command
- ipmitool received it and removed 1st entry(seq#2)
- ipmitool sent command(netfn=0x2c command=0x00) and added it to list with seq#3
- target controller sent response for 2nd command(retry)
- ipmitool received it and removed 2nd entry(seq#2)
- ipmitool sent user command(netfn=0x00 command=0x01) and added it to list with seq#4
- target controller sent response for 3rd command(seq#3) and it had 0xc1 response
- ipmitool received it and removed 3rd entry(seq#3)
- ipmitool returned this 0xc1 response to user even though it was not for user command(seq#4).
I guess ipmitool should remove 1st entry by itself before adding retried command to list.
I also checked source code of version 1.8.13 and found "lanplus.c" does not have a code for the purpose but "lan.c" has it.
My question is whether current implementation of "lanplus.c" is correct or not.
I also know we can avoid this problem by using "-N" option and we will use it for a while.
Best Regards,
Kazuyuki Funada
Our firmware developers including me have faced a issue that target controller occasionally returns 0xc1 response to "Get Chassis Status" command.
We found the issue happened when target controller could not respond within 1 second and ipmitool retried sending packet. We checked debugging output of ipmitool and understood the mechanism was below.
- user issued command(netfn=0x00 command=0x01) by ipmitool using lanplus I/F
- ipmitool sent command(netfn=0x06 command=0x01) and added it to list with seq#2
(target controller did not respond within 1 second)
- ipmitool sent command again and added it to list with seq#2
- target controller sent response for 1st command
- ipmitool received it and removed 1st entry(seq#2)
- ipmitool sent command(netfn=0x2c command=0x00) and added it to list with seq#3
- target controller sent response for 2nd command(retry)
- ipmitool received it and removed 2nd entry(seq#2)
- ipmitool sent user command(netfn=0x00 command=0x01) and added it to list with seq#4
- target controller sent response for 3rd command(seq#3) and it had 0xc1 response
- ipmitool received it and removed 3rd entry(seq#3)
- ipmitool returned this 0xc1 response to user even though it was not for user command(seq#4).
I guess ipmitool should remove 1st entry by itself before adding retried command to list.
I also checked source code of version 1.8.13 and found "lanplus.c" does not have a code for the purpose but "lan.c" has it.
My question is whether current implementation of "lanplus.c" is correct or not.
I also know we can avoid this problem by using "-N" option and we will use it for a while.
Best Regards,
Kazuyuki Funada