* IPMI LAN command story design - try 3rd send
@ 2016-10-03 13:59 Li Nan
[not found] ` <57F37746.6040304@linux.vnet.ibm.com>
0 siblings, 1 reply; 22+ messages in thread
From: Li Nan @ 2016-10-03 13:59 UTC (permalink / raw)
To: openbmc@lists.ozlabs.org
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 12221 bytes --]
Hi team,
I'm working on the story of Confirm LAN Command meet IPMI 2.0
https://github.com/openbmc/openbmc/issues/444
<https://github.com/openbmc/openbmc/issues/444>
I summarize some fields of settings below, and need some help to confirm the direction of my work.
```
1. IPMI LAN command status and work plan
1.1. Current status
IPMI LAN command consists of 4 command ( refer to IPMI 2.0 Spec, Chapter 23 ): Set LAN Configuration Parameters, Get LAN Configuration Parameters, Suspend BMC ARPs and Get IP/UDP/RMCP Statistics.
Existing code includes implementation of Set/Get LAN configuration Parameters. ( Refer to https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp )
1.2. IPMI LAN Command Handling
Example for Set LAN Configuration Parameters.
Parameter
#
Number
IPMI handling
dbus method
Set In Progress(Volatile)
0
phosphor-host-ipmid/transporthandler.cpp, Line 209.
variable lan_set_in_progress act as a statemachine.
No need.
Authentication Type Support(Read Only)
1
phosphor-host-ipmid/transporthandler.cpp, Line 305.
Set to 0x4 (MD5)
No need.
Authentication Type
Enables
2
phosphor-host-ipmid/transporthandler.cpp, Line 311.
Set to 0x4, 0x4, 0x4, 0x4, 0x4.
No need.
IP Address
3
phosphor-host-ipmid/transporthandler.cpp, Line 169.
phosphor-neworkd/netman.py: Line 266: SetAddress4
MAC Address
(can be Read Only)
5
phosphor-host-ipmid/transporthandler.cpp, Line 174.
phosphor-neworkd/netman.py: Line 334: SetHwAddress.
Subnet Mask
6
phosphor-host-ipmid/transporthandler.cpp, Line 199.
phosphor-neworkd/netman.py: Line 266: SetAddress4
Default Gateway Address
12
phosphor-host-ipmid/transporthandler.cpp, Line 204.
phosphor-neworkd/netman.py: Line 266: SetAddress4
Handling of Get LAN Configuration Parameters command is similar to Set LAN Configuration Parameters. Refer to phosphor-host-ipmid/transporthandler.cpp and phosphor-networkd/netman.py.
1.3. Gap between current code and IPMI Spec 2.0
LAN Configuration Parameter List
Parameter
#
Number
Parameter Data( non-volatile unless otherwise noted )
Bit field
Description
Current status/Note
( Yes = current support.
No = not support. )
Set In Progress(Volatile)
0
byte 1
00b -= set complete
0ab = set in progress
10b = commit write
11b = reserved
Yes
Authentication Type Support(Read Only)
1
byte 1
Authentication type(s) enabled for this channel(bi0tfield):
All bits: 1b =supported
0b= authentication type not available for use.
[5] ¨C OEM proprietary
[4] ¨C straight password / key
[3] ¨C reserved
[2] ¨C MD5
[1] ¨C MD2
[0] - none
Yes.
MD5
Authenticaton Type
Enables
2
This field is used to configure which Authentication Types are available for use when a remote console activates an IPMI messaging connection to the BMC for a given requested maximum privilege level.
Yes.
MD5
IP Address
3
data 1:4
MS-byte first
IP Address
Yes
IP Address Source
4
data1
address source
0h ¨C unspecified
1h = static address (manually configured)
2h = address obtained by BMC running DHCP
3h = address loaded by BIOS or system software
4h = address obtained by BMC running other address assignment protocol
No.
MAC Address
(can be Read Only)
5
data 1:6
MAC Address for messages transmitted from BMC.
MS-byte first.
Yes.
Subnet Mask
6
data1:4
Yes
IPv4 Header Parameter
7
data1
No
Primary RMCP Port Number(optional)
8
data1:2
No.
Secondary RMCP Port Number(optional)
9
data1:2
No.
BMC-generated ARP control (optional)
10
data1
No.
Gratuitous ARP interval (optional)
11
No.
Default Gateway Address
12
Yes
Default Gateway MAC Address
13
No.
Backup Gateway Address
14
No.
Backup Gateway MAC Address
15
No.
Community String
16
No.
Number of Destinations( Read Only )
17
No.
Destination Type (volatile / non-volatile ¨C see description )
18
No.
Destination Address
19
No.
Following parameters are introduced with IPMI v2.0/RMCP+
802.1q VLAN ID (12-bit)
20
No.
802.1q VLAN Priority
21
No.
RMCP+ Messaging Cipher Suite Entry Support( Read Only )
22
No.
RMCP+ Messaging Cipher Suite Entries( Read Only )
23
No.
RMCP+ Messaging Cipher Suite Privilege Levels
24
No.
Destination Address VLAN TAGs
25
No.
Bad Password Threshold
26
No.
IPv6/IPv4 Support
50
No.
IPv6/IPv4 Addressing Enables
51
No.
IPv6/IPv4 Header Static Traffic Class
52
No.
IPv6 Header Static Hop Limit
53
No.
IPv6 Header Flow Label
54
No.
IPv6 Status
55
No.
IPv6 Static Addresses
56
No.
IPv6 DHCPv6 Static DUID storage length
57
No.
IPv6 DHCPv6 Static DUIDs
58
No.
IPv6 Dynamic ( SLAAC/DHCPv6) Address
59
No.
IPv6 DHCPv6 Dynamic DUID storage length
60
No.
IPv6 DHCPv6 Dynamic DUIDs
61
No.
IPv6 DHCPv6 Timing Configuration Support
62
No.
IPv6 DHCPv6 Timing & Configuration
63
No.
IPv6 Router Address Configuration Control
64
No.
IPv6 Static Router 1 IP Address
65
No.
IPv6 Static Router 1 MAC Address
66
No.
IPv6 Static Router 1 Prefix Length
67
No.
IPv6 Static Router 1 Prefix Value
68
No.
IPv6 Static Router 2 Address
69
No.
IPv6 Static Router 2 MAC Address
70
No.
IPv6 Static Router 2 Prefix Length
71
No.
IPv6 Static Router 2 Prefix Value
72
No.
Number of Dynamic Router Info Sets
73
No.
IPv6 Dynamic Router Info IP Address
74
No.
IPv6 Dynamic Router Info MAC Address
75
No.
IPv6 Dynamic Router Info Prefix Length
76
No.
IPv6 Dynamic Router Info Prefix Value
77
No.
IPv6 Dynamic Router Received Hop Limit
78
No.
IPv6 Neighbor Discovery / SLAAC Timing Configuration Support
79
No.
IPv6 Neighbor Discovery / SLAAC Timing Configuration
80
No.
OEM Parameters
192:255
No.
1.4. Work Plan
1.4.1. Set LAN Configuration Parameters
1.4.2. Get LAN Configuration Parameters
I figure out what we support in phosphor-netwokd repo ( Refer to:
https://github.com/openbmc/phosphor-networkd/blob/master/netman.py ) :
* Set In Progress,
* Authentication Type Support,
* Authentication Type Enables,
* IP Address,
* MAC Address,
* Subnet Mask,
* Default Gateway Address
So I think we only support existing configuration.
How can I implement the rest of the configurations/parameters? (open issues?)
1.4.3. ARP
Not implemented in Tom¡¯s IPMI network story.
Should I refer to openbmc/import-layers/meta-openembedded/meta-networking/recipes-support/arptables ?
Optional command. Not to implement?
1.4.4. IP/UDP/RMCP statistics
Seems like it was not implemented in obmc stories too.
This is an optional command. Not to implement?
2. IPMI LAN Commands in IPMI Spec 2.0 -- Format
1.1. Set LAN Configuration Parameters command
Set LAN Configuration Parameters command
Byte
Bit field
Description
Support
Request Data
1
[7:4]
reserved
[3:0]
Channel number
2
Parameter selector
3:N
Configuration parameter data
Response Data
1
Completion code
80h = parameter not supported.
81h = attempt to set the ¡®set in progress¡¯ value (in parameter #0) when not in the ¡®set complete¡¯ state. (This completion code provides a way to recognize that another party has already ¡®claimed¡¯ the parameters)
82h = attempt to write read-only parameter
83h = attempt to read write-only parameter
Existing code supports 7 LAN command:
Set In Progress,
Authentication Type Support,
Authentication Type Enables,
IP Address,
MAC Address,
Subnet Mask,
Default Gateway Address.
Refer to:
https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
1.2. Get LAN Configuration Parameters Command
Get LAN Configuration Parameters Command
Byte
Bit field
Description
Support
Request Data
1
[7]
0b = get parameter
1b = get parameter revision only
[6:4]
reserved
[3:0]
Channel number
2
Parameter selector
3
Set Selector. Selects a given set of parameters under a given Parameter selector value.
00h if parameter don¡¯t use a Set Selector.
4
Block Selector (00h if parameter does not require a block number)
Response Data
1
[7:0]
Completion Code.
Generic codes, plus following command-specific completion code(s):
80h = parameter not supported.
Existing code supports 7 LAN command:
Set In Progress,
Authentication Type Support,
Authentication Type Enables,
IP Address,
MAC Address,
Subnet Mask,
Default Gateway Address.
Refer to https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
2
[7:0]
Parameter revision.
Format: MSN = present revision. LSN = oldest revision parameter is backward compatible with. 11h for parameters in this specification.
The following data bytes are not returned when the ¡®get parameter revision only¡¯ bit is 1b.
3:N
Configuration parameter data.
If the rollback feature is implemented, the BMC makes a copy of the existing parameters when the ¡®set in progress¡¯ state becomes asserted (See the Set in Progress parameter #0). While the ¡®set in progress¡¯ state is active, the BMC will return data from this copy of the parameters, plus any uncommitted changes that were made to data. Otherwise, the BMC returns parameter data from non-volatile storage.
1.2.1. DHCPv6 Timing Parameters
Not support.
1.2.2. Neighbor discovery / SLAAC Timing Parameters
Not support.
1.3. Suspend BMC ARPs command
Suspend BMC ARPs Command
Byte
Bit field
Description
Support
Request
1
[7:4]
Reserved
[3:0]
Channel number
2
[7:2]
Reserved
[1]
ARP response suspend.
[0]
Gratuitous ARP suspend
Respond
1
Completion code
Do not support.
( Should refer to
openbmc/import-layers/meta-openembedded/meta-networking/recipes-support/arptables? )
2
present state o f ARP suspension
[7:2]
reserve
[1]
[0]
Address Resolution Protocol.
1.4. Get IP/UDP/RMCP Statistics Command
Get IP/UDP/RMCP Statistics Command
Byte
Bit field
Description
Support
Request Data
1
[7:4]
reserved
[3:0]
Channel number
2
[7:1]
clear statistics
[0]
Respond Data
1
Completion Code
RMCP is implemented in openbmc.
Refer to
https://github.com/openbmc/openbmc/issues/432 and so on.
Discussed with Tom, these statistics is not implemented in phosphor-networkd.
2:3
IP Packets Received.
4:5
Received IP Header Errors
6:7
Received IP Address Errors
8:9
Fragmented IP Packets Received
10:11
IP Packets Transmitted
12:13
UDP Packets Received
14:15
Valid RMCP Received
16:17
UDP Proxy Packets Received
18:19
UDP Proxy Packets dropped
3. End
```
[-- Attachment #2: Type: text/html, Size: 275914 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
[not found] ` <57F37746.6040304@linux.vnet.ibm.com>
@ 2016-10-04 14:51 ` Patrick Williams
2016-10-17 6:55 ` Li Nan
0 siblings, 1 reply; 22+ messages in thread
From: Patrick Williams @ 2016-10-04 14:51 UTC (permalink / raw)
To: tomjose; +Cc: Li Nan, OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 22952 bytes --]
Forwarding to list.
On Tue, Oct 04, 2016 at 03:02:54PM +0530, tomjose wrote:
> Hello Nan,
>
> The current implementation mandates the user to enter <IP
> Address>,<NetMask> and <Gateway>
> for the network settings to be changed. Even though the user wants to
> change only the IP
> address , because of the way we have implemented we are forcing the user
> to enter all the three details.
>
> The LAN settings is a property of the channel(Channel 1 typically
> corresponds to ETH0) and we can leverage
> the "Set Channel Access" command to apply the settings.We can apply the
> network settings whenever the
> Access Mode is turned on.(ipmitool lan set 1 access on)
>
> With the solution i am thinking , the Set LAN configuration command
> would not be used to apply the network
> settings but it would be used to cache the network settings and it would
> be applied when the Set Channel Access
> command is called.
>
> The following link explains the order of commands.
>
> https://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool(LAN
> Configuration section)
>
> Regarding #2 - Authentication Type Support, it seems that this section
> is not updated properly.
> Get Channel Authentication capabilities is the first command issued for
> a session setup.
> This command also has the same Authentication type support field and the
> 7th bit which
> was reserved in #2 is used in this command to specify IPMI2.0 and
> IPMI1.5 authentication
> capabilities.
>
> So since #2 is outdated to represent the necessary authentication
> capabilities, i think we do
> not need to support parameter #2.
>
> Regarding #3 - Authentication Type Enables - this is needed if we
> support different authentication
> types for different requested privilege levels. Since the authentication
> types are outdated and we
> do not support different authentication types per privilege levels, we
> can avoid this parameter.
>
> Thanks,
> Tom
>
>
>
>
> On Monday 03 October 2016 07:29 PM, Li Nan wrote:
> >
> > Hi team,
> >
> > I'm working on the story of Confirm LAN Command meet IPMI 2.0
> > https://github.com/openbmc/openbmc/issues/444
> >
> >
> > <https://github.com/openbmc/openbmc/issues/444>
> >
> > I summarize some fields of settings below, and need some help to
> > confirm the direction of my work.
> >
> > ```
> >
> >
> > 1.IPMI LAN command status and work plan
> >
> >
> > 1.1.Current status
> >
> > IPMI LAN command consists of 4 command ( refer to IPMI 2.0 Spec,
> > Chapter 23 ):Set LAN Configuration Parameters, Get LAN Configuration
> > Parameters, Suspend BMC ARPs and Get IP/UDP/RMCP Statistics.
> >
> > Existing code includes implementation of Set/Get LAN configuration
> > Parameters. ( Refer to
> > https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp
> > )
> >
> >
> > 1.2.IPMI LAN Command Handling
> >
> > Example for Set LAN Configuration Parameters.
> >
> > Parameter
> >
> >
> >
> > #
> >
> > Number
> >
> >
> >
> > IPMI handling
> >
> >
> >
> > dbus method
> >
> > Set In Progress(Volatile)
> >
> >
> >
> > 0
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 209.
> >
> > variable lan_set_in_progress act as a statemachine.
> >
> >
> >
> > No need.
> >
> > Authentication Type Support(Read Only)
> >
> >
> >
> > 1
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 305.
> >
> > Setto 0x4 (MD5)
> >
> >
> >
> > No need.
> >
> > Authentication Type
> >
> > Enables
> >
> >
> >
> > 2
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 311.
> >
> > Set to 0x4, 0x4, 0x4, 0x4, 0x4.
> >
> >
> >
> > No need.
> >
> > IP Address
> >
> >
> >
> > 3
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 169.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 266: SetAddress4
> >
> > MAC Address
> >
> > (can be Read Only)
> >
> >
> >
> > 5
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 174.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 334: SetHwAddress.
> >
> > Subnet Mask
> >
> >
> >
> > 6
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 199.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 266: SetAddress4
> >
> > Default Gateway Address
> >
> >
> >
> > 12
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 204.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 266: SetAddress4
> >
> > Handling of Get LAN Configuration Parameters command is similar to Set
> > LAN Configuration Parameters. Refer to
> > phosphor-host-ipmid/transporthandler.cpp and phosphor-networkd/netman.py.
> >
> >
> > 1.3.Gap between current code and IPMI Spec 2.0
> >
> > LAN Configuration Parameter List
> >
> > Parameter
> >
> >
> >
> > #
> >
> > Number
> >
> >
> >
> > Parameter Data( non-volatile unless otherwise noted )
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Current status/Note
> >
> > ( Yes = current support.
> >
> > No = not support. )
> >
> > Set In Progress(Volatile)
> >
> >
> >
> > 0
> >
> >
> >
> > byte 1
> >
> >
> >
> >
> >
> > 00b -= set complete
> >
> > 0ab = set in progress
> >
> > 10b = commit write
> >
> > 11b = reserved
> >
> >
> >
> > Yes
> >
> > Authentication Type Support(Read Only)
> >
> >
> >
> > 1
> >
> >
> >
> > byte 1
> >
> >
> >
> >
> >
> > Authentication type(s) enabled for this channel(bi0tfield):
> >
> > All bits: 1b =supported
> >
> > 0b= authentication type not available for use.
> >
> > [5] – OEM proprietary
> >
> > [4] – straight password / key
> >
> > [3] – reserved
> >
> > [2] – MD5
> >
> > [1] – MD2
> >
> > [0] - none
> >
> >
> >
> > Yes.
> >
> > MD5
> >
> > Authenticaton Type
> >
> > Enables
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> >
> >
> > This field is used to configure which Authentication Types are
> > available for use when a remote console activates an IPMI messaging
> > connection to the BMC for a given requested maximum privilege level.
> >
> >
> >
> > Yes.
> >
> > MD5
> >
> > IP Address
> >
> >
> >
> > 3
> >
> >
> >
> > data 1:4
> >
> > MS-byte first
> >
> >
> >
> >
> >
> > IP Address
> >
> >
> >
> > Yes
> >
> > IP Address Source
> >
> >
> >
> > 4
> >
> >
> >
> > data1
> >
> >
> >
> >
> >
> > address source
> >
> > 0h – unspecified
> >
> > 1h = static address (manually configured)
> >
> > 2h = address obtained by BMC running DHCP
> >
> > 3h = address loaded by BIOS or system software
> >
> > 4h = address obtained by BMC running other address assignment protocol
> >
> >
> >
> > No.
> >
> > MAC Address
> >
> > (can be Read Only)
> >
> >
> >
> > 5
> >
> >
> >
> > data 1:6
> >
> >
> >
> >
> >
> > MAC Address for messages transmitted from BMC.
> >
> > MS-byte first.
> >
> >
> >
> > Yes.
> >
> > Subnet Mask
> >
> >
> >
> > 6
> >
> >
> >
> > data1:4
> >
> >
> >
> >
> >
> >
> >
> > Yes
> >
> > IPv4 Header Parameter
> >
> >
> >
> > 7
> >
> >
> >
> > data1
> >
> >
> >
> >
> >
> >
> >
> > No
> >
> > Primary RMCP Port Number(optional)
> >
> >
> >
> > 8
> >
> >
> >
> > data1:2
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Secondary RMCP Port Number(optional)
> >
> >
> >
> > 9
> >
> >
> >
> > data1:2
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > BMC-generated ARP control (optional)
> >
> >
> >
> > 10
> >
> >
> >
> > data1
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Gratuitous ARP interval (optional)
> >
> >
> >
> > 11
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Default GatewayAddress
> >
> >
> >
> > 12
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yes
> >
> > Default Gateway MAC Address
> >
> >
> >
> > 13
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Backup Gateway Address
> >
> >
> >
> > 14
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Backup Gateway MAC Address
> >
> >
> >
> > 15
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Community String
> >
> >
> >
> > 16
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Number of Destinations( Read Only )
> >
> >
> >
> > 17
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Destination Type (volatile / non-volatile – see description )
> >
> >
> >
> > 18
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Destination Address
> >
> >
> >
> > 19
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Following parameters are introduced with IPMI v2.0/RMCP+
> >
> > 802.1q VLAN ID (12-bit)
> >
> >
> >
> > 20
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > 802.1q VLAN Priority
> >
> >
> >
> > 21
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > RMCP+ Messaging Cipher Suite Entry Support( Read Only )
> >
> >
> >
> > 22
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > RMCP+ Messaging Cipher Suite Entries( Read Only )
> >
> >
> >
> > 23
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > RMCP+ Messaging Cipher Suite Privilege Levels
> >
> >
> >
> > 24
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Destination Address VLAN TAGs
> >
> >
> >
> > 25
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Bad Password Threshold
> >
> >
> >
> > 26
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6/IPv4 Support
> >
> >
> >
> > 50
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6/IPv4 Addressing Enables
> >
> >
> >
> > 51
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6/IPv4 Header Static Traffic Class
> >
> >
> >
> > 52
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Header Static Hop Limit
> >
> >
> >
> > 53
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Header Flow Label
> >
> >
> >
> > 54
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Status
> >
> >
> >
> > 55
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Addresses
> >
> >
> >
> > 56
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Static DUID storage length
> >
> >
> >
> > 57
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Static DUIDs
> >
> >
> >
> > 58
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic ( SLAAC/DHCPv6) Address
> >
> >
> >
> > 59
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Dynamic DUID storage length
> >
> >
> >
> > 60
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Dynamic DUIDs
> >
> >
> >
> > 61
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Timing Configuration Support
> >
> >
> >
> > 62
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Timing & Configuration
> >
> >
> >
> > 63
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Router Address Configuration Control
> >
> >
> >
> > 64
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 IP Address
> >
> >
> >
> > 65
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 MAC Address
> >
> >
> >
> > 66
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 Prefix Length
> >
> >
> >
> > 67
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 Prefix Value
> >
> >
> >
> > 68
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 Address
> >
> >
> >
> > 69
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 MAC Address
> >
> >
> >
> > 70
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 Prefix Length
> >
> >
> >
> > 71
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 Prefix Value
> >
> >
> >
> > 72
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Number of Dynamic Router Info Sets
> >
> >
> >
> > 73
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info IP Address
> >
> >
> >
> > 74
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info MAC Address
> >
> >
> >
> > 75
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info Prefix Length
> >
> >
> >
> > 76
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info Prefix Value
> >
> >
> >
> > 77
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Received Hop Limit
> >
> >
> >
> > 78
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Neighbor Discovery / SLAAC Timing Configuration Support
> >
> >
> >
> > 79
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Neighbor Discovery / SLAAC Timing Configuration
> >
> >
> >
> > 80
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > OEM Parameters
> >
> >
> >
> > 192:255
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> >
> > 1.4.Work Plan
> >
> >
> > 1.4.1.Set LAN Configuration Parameters
> >
> >
> > 1.4.2.Get LAN Configuration Parameters
> >
> > I figure out what we support in phosphor-netwokd repo ( Refer to:
> >
> > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py ) :
> >
> > * Set In Progress,
> > * Authentication Type Support,
> > * Authentication Type Enables,
> > * IP Address,
> > * MAC Address,
> > * Subnet Mask,
> > * Default Gateway Address
> >
> > So I think we only support existing configuration.
> >
> > How can I implement the rest of the configurations/parameters? (open
> > issues?)
> >
> >
> > 1.4.3.ARP
> >
> > Not implemented in Tom’s IPMI network story.
> >
> > Should I refer to
> > openbmc/import-layers/meta-openembedded/meta-networking/recipes-support/arptables
> > ?
> >
> > Optional command. Not to implement?
> >
> >
> > 1.4.4.IP/UDP/RMCP statistics
> >
> > Seems like it was not implemented in obmc stories too.
> >
> > This is an optional command. Not to implement?
> >
> >
> > 2.IPMI LAN Commands in IPMI Spec 2.0 -- Format
> >
> >
> > 1.1.Set LAN Configuration Parameters command
> >
> > Set LAN Configuration Parameters command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7:4]
> >
> >
> >
> > reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> > Parameter selector
> >
> >
> >
> >
> >
> > 3:N
> >
> >
> >
> >
> >
> > Configuration parameter data
> >
> >
> >
> > Response Data
> >
> >
> >
> > 1
> >
> >
> >
> > Completion code
> >
> >
> >
> > 80h = parameter not supported.
> >
> > 81h = attempt to set the ‘set in progress’ value (in parameter #0)
> > when not in the ‘set complete’ state. (This completion code provides a
> > way to recognize that another party has already ‘claimed’ the parameters)
> >
> > 82h = attempt to write read-only parameter
> >
> > 83h = attempt to read write-only parameter
> >
> >
> >
> > Existing code supports 7 LAN command:
> >
> > Set In Progress,
> >
> > Authentication Type Support,
> >
> > Authentication Type Enables,
> >
> > IP Address,
> >
> > MAC Address,
> >
> > Subnet Mask,
> >
> > Default Gateway Address.
> >
> > Refer to:
> >
> > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 1.2.Get LAN Configuration Parameters Command
> >
> > Get LAN Configuration Parameters Command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7]
> >
> >
> >
> > 0b = get parameter
> >
> > 1b = get parameter revision only
> >
> >
> >
> >
> >
> >
> >
> > [6:4]
> >
> >
> >
> > reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> > Parameter selector
> >
> >
> >
> >
> >
> > 3
> >
> >
> >
> >
> >
> > Set Selector. Selects a given set of parameters under a given
> > Parameter selector value.
> >
> > 00h if parameter don’t use a Set Selector.
> >
> >
> >
> >
> >
> > 4
> >
> >
> >
> >
> >
> > Block Selector (00h if parameter does not require a block number)
> >
> >
> >
> > Response Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7:0]
> >
> >
> >
> > Completion Code.
> >
> > Generic codes, plus following command-specific completion code(s):
> >
> > 80h = parameter not supported.
> >
> >
> >
> > Existing code supports 7 LAN command:
> >
> > Set In Progress,
> >
> > Authentication Type Support,
> >
> > Authentication Type Enables,
> >
> > IP Address,
> >
> > MAC Address,
> >
> > Subnet Mask,
> >
> > Default Gateway Address.
> >
> > Refer to
> > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
> >
> >
> >
> > 2
> >
> >
> >
> > [7:0]
> >
> >
> >
> > Parameter revision.
> >
> > Format: MSN = present revision. LSN = oldest revision parameter is
> > backward compatible with. 11h for parameters in this specification.
> >
> >
> >
> > The following data bytes are not returned when the ‘get parameter
> > revision only’ bit is 1b.
> >
> >
> >
> > 3:N
> >
> >
> >
> >
> >
> > Configuration parameter data.
> >
> > If the rollback feature is implemented, the BMC makes a copy of the
> > existing parameters when the ‘set in progress’ state becomes asserted
> > (See the Set in Progress parameter #0). While the ‘set in progress’
> > state is active, the BMC will return data from this copy of the
> > parameters, plus any uncommitted changes that were made to data.
> > Otherwise, the BMC returns parameter data from non-volatile storage.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 1.2.1.DHCPv6 Timing Parameters
> >
> > Not support.
> >
> >
> > 1.2.2.Neighbor discovery / SLAAC Timing Parameters
> >
> > Not support.
> >
> >
> > 1.3.Suspend BMC ARPs command
> >
> > Suspend BMC ARPs Command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request
> >
> >
> >
> > 1
> >
> >
> >
> > [7:4]
> >
> >
> >
> > Reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> > [7:2]
> >
> >
> >
> > Reserved
> >
> >
> >
> >
> >
> >
> >
> > [1]
> >
> >
> >
> > ARP response suspend.
> >
> >
> >
> >
> >
> >
> >
> > [0]
> >
> >
> >
> > Gratuitous ARP suspend
> >
> >
> >
> > Respond
> >
> >
> >
> > 1
> >
> >
> >
> >
> >
> > Completion code
> >
> >
> >
> > Do not support.
> >
> > ( Should refer to
> >
> > openbmc/import-layers/meta-openembedded/meta-networking/recipes-support/arptables?
> > )
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> > present state o f ARP suspension
> >
> >
> >
> >
> >
> > [7:2]
> >
> >
> >
> > reserve
> >
> >
> >
> >
> >
> > [1]
> >
> >
> >
> >
> >
> >
> >
> > [0]
> >
> >
> >
> > Address Resolution Protocol.
> >
> >
> > 1.4.Get IP/UDP/RMCP Statistics Command
> >
> > Get IP/UDP/RMCP Statistics Command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7:4]
> >
> >
> >
> > reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> > [7:1]
> >
> >
> >
> > clear statistics
> >
> >
> >
> >
> >
> >
> >
> > [0]
> >
> >
> >
> >
> >
> > Respond Data
> >
> >
> >
> > 1
> >
> >
> >
> >
> >
> > Completion Code
> >
> >
> >
> > RMCP is implemented in openbmc.
> >
> > Refer to
> >
> > https://github.com/openbmc/openbmc/issues/432 and so on.
> >
> > Discussed with Tom, these statistics is not implemented in
> > phosphor-networkd.
> >
> >
> >
> > 2:3
> >
> >
> >
> >
> >
> > IP Packets Received.
> >
> >
> >
> > 4:5
> >
> >
> >
> >
> >
> > Received IP Header Errors
> >
> >
> >
> > 6:7
> >
> >
> >
> >
> >
> > Received IP Address Errors
> >
> >
> >
> > 8:9
> >
> >
> >
> >
> >
> > Fragmented IP Packets Received
> >
> >
> >
> > 10:11
> >
> >
> >
> >
> >
> > IP Packets Transmitted
> >
> >
> >
> > 12:13
> >
> >
> >
> >
> >
> > UDP Packets Received
> >
> >
> >
> > 14:15
> >
> >
> >
> >
> >
> > Valid RMCP Received
> >
> >
> >
> > 16:17
> >
> >
> >
> >
> >
> > UDP Proxy Packets Received
> >
> >
> >
> > 18:19
> >
> >
> >
> >
> >
> > UDP Proxy Packets dropped
> >
> >
> > 3.End
> >
> > ```
> >
> >
> >
> >
> > _______________________________________________
> > openbmc mailing list
> > openbmc@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/openbmc
>
--
Patrick Williams
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: IPMI LAN command story design - try 3rd send
2016-10-04 14:51 ` Patrick Williams
@ 2016-10-17 6:55 ` Li Nan
2016-11-03 16:22 ` Li Nan
0 siblings, 1 reply; 22+ messages in thread
From: Li Nan @ 2016-10-17 6:55 UTC (permalink / raw)
To: Patrick Williams, tomjose, Adriana Kobylak; +Cc: OpenBMC Maillist, Yi Li
[-- Attachment #1: Type: text/plain, Size: 26498 bytes --]
Hi all,
I summarize IPMI LAN command flow here after our discussion.
When we want to change single ip address/Subnet mask/Gateway address, ipmitool (the openbmc/ipmitool) will automatically use a set of command to accomplish it, it works like below:
ex. we want to change ip address.
After we send "ipmitool -I dbus lan set 1 ipaddr A.B.C.D", ipmitool will do:
(1)send Get Channel Info command.
(2)echo "Setting LAN IP Address to A.B.C.D" to shell.
(3)send Get LAN command to fetch the value of "set in progress"(which is 0x0) .
(4)send Set LAN command to change "set in progress" parameter to "Set in Progress"(0x1).
(5)send Get LAN command to fetch the value of "set in progress"( which is 0x1) .
(6)send Set LAN command to set "ip address" with value of "A.B.C.D".
(7)send Get LAN command to fetch value of ip address.
(8)send Set LAN command to "commit write" by setting "set in progress" to 0x2.
(9)send Set LAN command to set "set in progress " to "set complete"(0x0).
It seems like ipmitool (some version) will automatically send SET LAN command to change the value of "set in progress" parameter. So "set in progress" can be used to identify a transaction. The value of "set in progress" can tell us the state of the procedure.
I do my work by using "set in progress" to apply the user settings.
(1) If user want to change only single setting of "ip address/subnet mask/gateway address ",
The ipmid will cache the user setting, and wait for "set complete"("set in progress" parameter value is 0x0). When ipmid receives "set complete", it will apply this user setting and the other two reserved settings fetched from dbus(netman.py).
a. If ipmitool don't send "set complete" automatically, user can send raw command to send it.
b. We also can send "set complete" in the implementation of "set channel access" command mentioned by Tom.
So it will looks like that single setting will be applied right away.
(2)If user want to change two or three settings at the same time:
a. If the "set complete" don't be sent automatically by ipmitool( some version ).
The user can send settings one by one, and then use a raw command(set complete) to apply them.
It will works when running from local shell (accessing it from serial port) or remote interface.
b. If the "set complete" is sent automatically by ipmitool.
So the single change will be applied immediately, the user can operate from a local interface.
Please correct me!
Thanks!
________________________________
寄件者: Patrick Williams <patrick@stwcx.xyz>
寄件日期: 2016年10月4日 上午 09:51
收件者: tomjose
副本: Li Nan; OpenBMC Maillist
主旨: Re: IPMI LAN command story design - try 3rd send
Forwarding to list.
On Tue, Oct 04, 2016 at 03:02:54PM +0530, tomjose wrote:
> Hello Nan,
>
> The current implementation mandates the user to enter <IP
> Address>,<NetMask> and <Gateway>
> for the network settings to be changed. Even though the user wants to
> change only the IP
> address , because of the way we have implemented we are forcing the user
> to enter all the three details.
>
> The LAN settings is a property of the channel(Channel 1 typically
> corresponds to ETH0) and we can leverage
> the "Set Channel Access" command to apply the settings.We can apply the
> network settings whenever the
> Access Mode is turned on.(ipmitool lan set 1 access on)
>
> With the solution i am thinking , the Set LAN configuration command
> would not be used to apply the network
> settings but it would be used to cache the network settings and it would
> be applied when the Set Channel Access
> command is called.
>
> The following link explains the order of commands.
>
> https://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool(LAN
> Configuration section)
>
> Regarding #2 - Authentication Type Support, it seems that this section
> is not updated properly.
> Get Channel Authentication capabilities is the first command issued for
> a session setup.
> This command also has the same Authentication type support field and the
> 7th bit which
> was reserved in #2 is used in this command to specify IPMI2.0 and
> IPMI1.5 authentication
> capabilities.
>
> So since #2 is outdated to represent the necessary authentication
> capabilities, i think we do
> not need to support parameter #2.
>
> Regarding #3 - Authentication Type Enables - this is needed if we
> support different authentication
> types for different requested privilege levels. Since the authentication
> types are outdated and we
> do not support different authentication types per privilege levels, we
> can avoid this parameter.
>
> Thanks,
> Tom
>
>
>
>
> On Monday 03 October 2016 07:29 PM, Li Nan wrote:
> >
> > Hi team,
> >
> > I'm working on the story of Confirm LAN Command meet IPMI 2.0
> > https://github.com/openbmc/openbmc/issues/444
> >
> >
> > <https://github.com/openbmc/openbmc/issues/444>
> >
> > I summarize some fields of settings below, and need some help to
> > confirm the direction of my work.
> >
> > ```
> >
> >
> > 1.IPMI LAN command status and work plan
> >
> >
> > 1.1.Current status
> >
> > IPMI LAN command consists of 4 command ( refer to IPMI 2.0 Spec,
> > Chapter 23 ):Set LAN Configuration Parameters, Get LAN Configuration
> > Parameters, Suspend BMC ARPs and Get IP/UDP/RMCP Statistics.
> >
> > Existing code includes implementation of Set/Get LAN configuration
> > Parameters. ( Refer to
> > https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp
[https://avatars1.githubusercontent.com/u/13670043?v=3&s=400]<https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp>
openbmc/phosphor-host-ipmid<https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp>
github.com
phosphor-host-ipmid - dbus-based ipmid for host-endpoint IPMI commands
> > )
> >
> >
> > 1.2.IPMI LAN Command Handling
> >
> > Example for Set LAN Configuration Parameters.
> >
> > Parameter
> >
> >
> >
> > #
> >
> > Number
> >
> >
> >
> > IPMI handling
> >
> >
> >
> > dbus method
> >
> > Set In Progress(Volatile)
> >
> >
> >
> > 0
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 209.
> >
> > variable lan_set_in_progress act as a statemachine.
> >
> >
> >
> > No need.
> >
> > Authentication Type Support(Read Only)
> >
> >
> >
> > 1
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 305.
> >
> > Setto 0x4 (MD5)
> >
> >
> >
> > No need.
> >
> > Authentication Type
> >
> > Enables
> >
> >
> >
> > 2
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 311.
> >
> > Set to 0x4, 0x4, 0x4, 0x4, 0x4.
> >
> >
> >
> > No need.
> >
> > IP Address
> >
> >
> >
> > 3
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 169.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 266: SetAddress4
> >
> > MAC Address
> >
> > (can be Read Only)
> >
> >
> >
> > 5
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 174.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 334: SetHwAddress.
> >
> > Subnet Mask
> >
> >
> >
> > 6
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 199.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 266: SetAddress4
> >
> > Default Gateway Address
> >
> >
> >
> > 12
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 204.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 266: SetAddress4
> >
> > Handling of Get LAN Configuration Parameters command is similar to Set
> > LAN Configuration Parameters. Refer to
> > phosphor-host-ipmid/transporthandler.cpp and phosphor-networkd/netman.py.
> >
> >
> > 1.3.Gap between current code and IPMI Spec 2.0
> >
> > LAN Configuration Parameter List
> >
> > Parameter
> >
> >
> >
> > #
> >
> > Number
> >
> >
> >
> > Parameter Data( non-volatile unless otherwise noted )
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Current status/Note
> >
> > ( Yes = current support.
> >
> > No = not support. )
> >
> > Set In Progress(Volatile)
> >
> >
> >
> > 0
> >
> >
> >
> > byte 1
> >
> >
> >
> >
> >
> > 00b -= set complete
> >
> > 0ab = set in progress
> >
> > 10b = commit write
> >
> > 11b = reserved
> >
> >
> >
> > Yes
> >
> > Authentication Type Support(Read Only)
> >
> >
> >
> > 1
> >
> >
> >
> > byte 1
> >
> >
> >
> >
> >
> > Authentication type(s) enabled for this channel(bi0tfield):
> >
> > All bits: 1b =supported
> >
> > 0b= authentication type not available for use.
> >
> > [5] – OEM proprietary
> >
> > [4] – straight password / key
> >
> > [3] – reserved
> >
> > [2] – MD5
> >
> > [1] – MD2
> >
> > [0] - none
> >
> >
> >
> > Yes.
> >
> > MD5
> >
> > Authenticaton Type
> >
> > Enables
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> >
> >
> > This field is used to configure which Authentication Types are
> > available for use when a remote console activates an IPMI messaging
> > connection to the BMC for a given requested maximum privilege level.
> >
> >
> >
> > Yes.
> >
> > MD5
> >
> > IP Address
> >
> >
> >
> > 3
> >
> >
> >
> > data 1:4
> >
> > MS-byte first
> >
> >
> >
> >
> >
> > IP Address
> >
> >
> >
> > Yes
> >
> > IP Address Source
> >
> >
> >
> > 4
> >
> >
> >
> > data1
> >
> >
> >
> >
> >
> > address source
> >
> > 0h – unspecified
> >
> > 1h = static address (manually configured)
> >
> > 2h = address obtained by BMC running DHCP
> >
> > 3h = address loaded by BIOS or system software
> >
> > 4h = address obtained by BMC running other address assignment protocol
> >
> >
> >
> > No.
> >
> > MAC Address
> >
> > (can be Read Only)
> >
> >
> >
> > 5
> >
> >
> >
> > data 1:6
> >
> >
> >
> >
> >
> > MAC Address for messages transmitted from BMC.
> >
> > MS-byte first.
> >
> >
> >
> > Yes.
> >
> > Subnet Mask
> >
> >
> >
> > 6
> >
> >
> >
> > data1:4
> >
> >
> >
> >
> >
> >
> >
> > Yes
> >
> > IPv4 Header Parameter
> >
> >
> >
> > 7
> >
> >
> >
> > data1
> >
> >
> >
> >
> >
> >
> >
> > No
> >
> > Primary RMCP Port Number(optional)
> >
> >
> >
> > 8
> >
> >
> >
> > data1:2
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Secondary RMCP Port Number(optional)
> >
> >
> >
> > 9
> >
> >
> >
> > data1:2
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > BMC-generated ARP control (optional)
> >
> >
> >
> > 10
> >
> >
> >
> > data1
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Gratuitous ARP interval (optional)
> >
> >
> >
> > 11
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Default GatewayAddress
> >
> >
> >
> > 12
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yes
> >
> > Default Gateway MAC Address
> >
> >
> >
> > 13
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Backup Gateway Address
> >
> >
> >
> > 14
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Backup Gateway MAC Address
> >
> >
> >
> > 15
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Community String
> >
> >
> >
> > 16
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Number of Destinations( Read Only )
> >
> >
> >
> > 17
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Destination Type (volatile / non-volatile – see description )
> >
> >
> >
> > 18
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Destination Address
> >
> >
> >
> > 19
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Following parameters are introduced with IPMI v2.0/RMCP+
> >
> > 802.1q VLAN ID (12-bit)
> >
> >
> >
> > 20
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > 802.1q VLAN Priority
> >
> >
> >
> > 21
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > RMCP+ Messaging Cipher Suite Entry Support( Read Only )
> >
> >
> >
> > 22
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > RMCP+ Messaging Cipher Suite Entries( Read Only )
> >
> >
> >
> > 23
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > RMCP+ Messaging Cipher Suite Privilege Levels
> >
> >
> >
> > 24
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Destination Address VLAN TAGs
> >
> >
> >
> > 25
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Bad Password Threshold
> >
> >
> >
> > 26
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6/IPv4 Support
> >
> >
> >
> > 50
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6/IPv4 Addressing Enables
> >
> >
> >
> > 51
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6/IPv4 Header Static Traffic Class
> >
> >
> >
> > 52
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Header Static Hop Limit
> >
> >
> >
> > 53
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Header Flow Label
> >
> >
> >
> > 54
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Status
> >
> >
> >
> > 55
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Addresses
> >
> >
> >
> > 56
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Static DUID storage length
> >
> >
> >
> > 57
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Static DUIDs
> >
> >
> >
> > 58
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic ( SLAAC/DHCPv6) Address
> >
> >
> >
> > 59
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Dynamic DUID storage length
> >
> >
> >
> > 60
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Dynamic DUIDs
> >
> >
> >
> > 61
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Timing Configuration Support
> >
> >
> >
> > 62
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Timing & Configuration
> >
> >
> >
> > 63
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Router Address Configuration Control
> >
> >
> >
> > 64
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 IP Address
> >
> >
> >
> > 65
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 MAC Address
> >
> >
> >
> > 66
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 Prefix Length
> >
> >
> >
> > 67
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 Prefix Value
> >
> >
> >
> > 68
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 Address
> >
> >
> >
> > 69
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 MAC Address
> >
> >
> >
> > 70
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 Prefix Length
> >
> >
> >
> > 71
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 Prefix Value
> >
> >
> >
> > 72
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Number of Dynamic Router Info Sets
> >
> >
> >
> > 73
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info IP Address
> >
> >
> >
> > 74
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info MAC Address
> >
> >
> >
> > 75
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info Prefix Length
> >
> >
> >
> > 76
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info Prefix Value
> >
> >
> >
> > 77
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Received Hop Limit
> >
> >
> >
> > 78
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Neighbor Discovery / SLAAC Timing Configuration Support
> >
> >
> >
> > 79
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Neighbor Discovery / SLAAC Timing Configuration
> >
> >
> >
> > 80
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > OEM Parameters
> >
> >
> >
> > 192:255
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> >
> > 1.4.Work Plan
> >
> >
> > 1.4.1.Set LAN Configuration Parameters
> >
> >
> > 1.4.2.Get LAN Configuration Parameters
> >
> > I figure out what we support in phosphor-netwokd repo ( Refer to:
> >
> > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py ) :
[https://avatars1.githubusercontent.com/u/13670043?v=3&s=400]<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
openbmc/phosphor-networkd<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
github.com
Contribute to phosphor-networkd development by creating an account on GitHub.
> >
> > * Set In Progress,
> > * Authentication Type Support,
> > * Authentication Type Enables,
> > * IP Address,
> > * MAC Address,
> > * Subnet Mask,
> > * Default Gateway Address
> >
> > So I think we only support existing configuration.
> >
> > How can I implement the rest of the configurations/parameters? (open
> > issues?)
> >
> >
> > 1.4.3.ARP
> >
> > Not implemented in Tom’s IPMI network story.
> >
> > Should I refer to
> > openbmc/import-layers/meta-openembedded/meta-networking/recipes-support/arptables
> > ?
> >
> > Optional command. Not to implement?
> >
> >
> > 1.4.4.IP/UDP/RMCP statistics
> >
> > Seems like it was not implemented in obmc stories too.
> >
> > This is an optional command. Not to implement?
> >
> >
> > 2.IPMI LAN Commands in IPMI Spec 2.0 -- Format
> >
> >
> > 1.1.Set LAN Configuration Parameters command
> >
> > Set LAN Configuration Parameters command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7:4]
> >
> >
> >
> > reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> > Parameter selector
> >
> >
> >
> >
> >
> > 3:N
> >
> >
> >
> >
> >
> > Configuration parameter data
> >
> >
> >
> > Response Data
> >
> >
> >
> > 1
> >
> >
> >
> > Completion code
> >
> >
> >
> > 80h = parameter not supported.
> >
> > 81h = attempt to set the ‘set in progress’ value (in parameter #0)
> > when not in the ‘set complete’ state. (This completion code provides a
> > way to recognize that another party has already ‘claimed’ the parameters)
> >
> > 82h = attempt to write read-only parameter
> >
> > 83h = attempt to read write-only parameter
> >
> >
> >
> > Existing code supports 7 LAN command:
> >
> > Set In Progress,
> >
> > Authentication Type Support,
> >
> > Authentication Type Enables,
> >
> > IP Address,
> >
> > MAC Address,
> >
> > Subnet Mask,
> >
> > Default Gateway Address.
> >
> > Refer to:
> >
> > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
[https://avatars1.githubusercontent.com/u/13670043?v=3&s=400]<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
openbmc/phosphor-networkd<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
github.com
Contribute to phosphor-networkd development by creating an account on GitHub.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 1.2.Get LAN Configuration Parameters Command
> >
> > Get LAN Configuration Parameters Command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7]
> >
> >
> >
> > 0b = get parameter
> >
> > 1b = get parameter revision only
> >
> >
> >
> >
> >
> >
> >
> > [6:4]
> >
> >
> >
> > reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> > Parameter selector
> >
> >
> >
> >
> >
> > 3
> >
> >
> >
> >
> >
> > Set Selector. Selects a given set of parameters under a given
> > Parameter selector value.
> >
> > 00h if parameter don’t use a Set Selector.
> >
> >
> >
> >
> >
> > 4
> >
> >
> >
> >
> >
> > Block Selector (00h if parameter does not require a block number)
> >
> >
> >
> > Response Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7:0]
> >
> >
> >
> > Completion Code.
> >
> > Generic codes, plus following command-specific completion code(s):
> >
> > 80h = parameter not supported.
> >
> >
> >
> > Existing code supports 7 LAN command:
> >
> > Set In Progress,
> >
> > Authentication Type Support,
> >
> > Authentication Type Enables,
> >
> > IP Address,
> >
> > MAC Address,
> >
> > Subnet Mask,
> >
> > Default Gateway Address.
> >
> > Refer to
> > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
[https://avatars1.githubusercontent.com/u/13670043?v=3&s=400]<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
openbmc/phosphor-networkd<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
github.com
Contribute to phosphor-networkd development by creating an account on GitHub.
> >
> >
> >
> > 2
> >
> >
> >
> > [7:0]
> >
> >
> >
> > Parameter revision.
> >
> > Format: MSN = present revision. LSN = oldest revision parameter is
> > backward compatible with. 11h for parameters in this specification.
> >
> >
> >
> > The following data bytes are not returned when the ‘get parameter
> > revision only’ bit is 1b.
> >
> >
> >
> > 3:N
> >
> >
> >
> >
> >
> > Configuration parameter data.
> >
> > If the rollback feature is implemented, the BMC makes a copy of the
> > existing parameters when the ‘set in progress’ state becomes asserted
> > (See the Set in Progress parameter #0). While the ‘set in progress’
> > state is active, the BMC will return data from this copy of the
> > parameters, plus any uncommitted changes that were made to data.
> > Otherwise, the BMC returns parameter data from non-volatile storage.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 1.2.1.DHCPv6 Timing Parameters
> >
> > Not support.
> >
> >
> > 1.2.2.Neighbor discovery / SLAAC Timing Parameters
> >
> > Not support.
> >
> >
> > 1.3.Suspend BMC ARPs command
> >
> > Suspend BMC ARPs Command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request
> >
> >
> >
> > 1
> >
> >
> >
> > [7:4]
> >
> >
> >
> > Reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> > [7:2]
> >
> >
> >
> > Reserved
> >
> >
> >
> >
> >
> >
> >
> > [1]
> >
> >
> >
> > ARP response suspend.
> >
> >
> >
> >
> >
> >
> >
> > [0]
> >
> >
> >
> > Gratuitous ARP suspend
> >
> >
> >
> > Respond
> >
> >
> >
> > 1
> >
> >
> >
> >
> >
> > Completion code
> >
> >
> >
> > Do not support.
> >
> > ( Should refer to
> >
> > openbmc/import-layers/meta-openembedded/meta-networking/recipes-support/arptables?
> > )
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> > present state o f ARP suspension
> >
> >
> >
> >
> >
> > [7:2]
> >
> >
> >
> > reserve
> >
> >
> >
> >
> >
> > [1]
> >
> >
> >
> >
> >
> >
> >
> > [0]
> >
> >
> >
> > Address Resolution Protocol.
> >
> >
> > 1.4.Get IP/UDP/RMCP Statistics Command
> >
> > Get IP/UDP/RMCP Statistics Command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7:4]
> >
> >
> >
> > reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> > [7:1]
> >
> >
> >
> > clear statistics
> >
> >
> >
> >
> >
> >
> >
> > [0]
> >
> >
> >
> >
> >
> > Respond Data
> >
> >
> >
> > 1
> >
> >
> >
> >
> >
> > Completion Code
> >
> >
> >
> > RMCP is implemented in openbmc.
> >
> > Refer to
> >
> > https://github.com/openbmc/openbmc/issues/432 and so on.
[https://avatars3.githubusercontent.com/u/105009?v=3&s=400]<https://github.com/openbmc/openbmc/issues/432>
Attaching RMCP session to SOL. · Issue #432 · openbmc/openbmc<https://github.com/openbmc/openbmc/issues/432>
github.com
openbmc - OpenBMC Distribution
> >
> > Discussed with Tom, these statistics is not implemented in
> > phosphor-networkd.
> >
> >
> >
> > 2:3
> >
> >
> >
> >
> >
> > IP Packets Received.
> >
> >
> >
> > 4:5
> >
> >
> >
> >
> >
> > Received IP Header Errors
> >
> >
> >
> > 6:7
> >
> >
> >
> >
> >
> > Received IP Address Errors
> >
> >
> >
> > 8:9
> >
> >
> >
> >
> >
> > Fragmented IP Packets Received
> >
> >
> >
> > 10:11
> >
> >
> >
> >
> >
> > IP Packets Transmitted
> >
> >
> >
> > 12:13
> >
> >
> >
> >
> >
> > UDP Packets Received
> >
> >
> >
> > 14:15
> >
> >
> >
> >
> >
> > Valid RMCP Received
> >
> >
> >
> > 16:17
> >
> >
> >
> >
> >
> > UDP Proxy Packets Received
> >
> >
> >
> > 18:19
> >
> >
> >
> >
> >
> > UDP Proxy Packets dropped
> >
> >
> > 3.End
> >
> > ```
> >
> >
> >
> >
> > _______________________________________________
> > openbmc mailing list
> > openbmc@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/openbmc
openbmc Info Page - OzLabs<https://lists.ozlabs.org/listinfo/openbmc>
lists.ozlabs.org
To see the collection of prior postings to the list, visit the openbmc Archives. Using openbmc: To post a message to all the list members, send email ...
>
--
Patrick Williams
[-- Attachment #2: Type: text/html, Size: 79434 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2016-10-17 6:55 ` Li Nan
@ 2016-11-03 16:22 ` Li Nan
2016-11-04 13:26 ` tomjose
0 siblings, 1 reply; 22+ messages in thread
From: Li Nan @ 2016-11-03 16:22 UTC (permalink / raw)
To: tomjose, Patrick Williams, Adriana Kobylak; +Cc: OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 28363 bytes --]
Hi, Tom,
I show my #444 ( story: Confirm LAN device command meet IPMI 2.0 requirements ) implementation below. Want to clarify that how it works.
We did some experiments, so we got that ipmitool would issue "set lan parameter" command like below:
For instance, change ip address.
After we sent "ipmitool -I dbus lan set 1 ipaddr 1.2.3.4", ipmitool would do:
(1)sent Get Channel Info command.
(2)echo "Setting LAN IP Address to 1.2.3.4" to the shell.
(3)sent Get LAN command to fetch the value of "set in progress"(which is 0x0) .
(4)sent Set LAN command to change "set in progress" parameter to "Set in Progress"(0x1).
(5)sent Get LAN command to fetch the value of "set in progress"( which is 0x1) .
(6)sent Set LAN command to set "ip address" with value of "A.B.C.D".
(7)sent Get LAN command to fetch value of ip address.
(8)sent Set LAN command to "commit write" by setting "set in progress" to 0x2.
(9)sent Set LAN command to set "set in progress " to "set complete"(0x0).
Because ipmitool would work like that, so we decided to use 2 steps to issue the changing of lan parameter:
Step 1:
Using Set LAN parameter command to cache the user setting. User can input one item at a time to cache. So user can put items into cache one be one in sequence.
Step 2:
Using Set Channel Access to apply those cached items.
So the mechanism of my implementation is following above steps? right?
https://gerrit.openbmc-project.xyz/#/c/822/
B.R.
Nan
<https://gerrit.openbmc-project.xyz/#/c/822/>
________________________________
From: openbmc <openbmc-bounces+william.bjlinan=hotmail.com@lists.ozlabs.org> on behalf of Li Nan <william.bjlinan@hotmail.com>
Sent: Monday, October 17, 2016 2:55 PM
To: Patrick Williams; tomjose; Adriana Kobylak
Cc: OpenBMC Maillist
Subject: RE: IPMI LAN command story design - try 3rd send
Hi all,
I summarize IPMI LAN command flow here after our discussion.
When we want to change single ip address/Subnet mask/Gateway address, ipmitool (the openbmc/ipmitool) will automatically use a set of command to accomplish it, it works like below:
ex. we want to change ip address.
After we send "ipmitool -I dbus lan set 1 ipaddr A.B.C.D", ipmitool will do:
(1)send Get Channel Info command.
(2)echo "Setting LAN IP Address to A.B.C.D" to shell.
(3)send Get LAN command to fetch the value of "set in progress"(which is 0x0) .
(4)send Set LAN command to change "set in progress" parameter to "Set in Progress"(0x1).
(5)send Get LAN command to fetch the value of "set in progress"( which is 0x1) .
(6)send Set LAN command to set "ip address" with value of "A.B.C.D".
(7)send Get LAN command to fetch value of ip address.
(8)send Set LAN command to "commit write" by setting "set in progress" to 0x2.
(9)send Set LAN command to set "set in progress " to "set complete"(0x0).
It seems like ipmitool (some version) will automatically send SET LAN command to change the value of "set in progress" parameter. So "set in progress" can be used to identify a transaction. The value of "set in progress" can tell us the state of the procedure.
I do my work by using "set in progress" to apply the user settings.
(1) If user want to change only single setting of "ip address/subnet mask/gateway address ",
The ipmid will cache the user setting, and wait for "set complete"("set in progress" parameter value is 0x0). When ipmid receives "set complete", it will apply this user setting and the other two reserved settings fetched from dbus(netman.py).
a. If ipmitool don't send "set complete" automatically, user can send raw command to send it.
b. We also can send "set complete" in the implementation of "set channel access" command mentioned by Tom.
So it will looks like that single setting will be applied right away.
(2)If user want to change two or three settings at the same time:
a. If the "set complete" don't be sent automatically by ipmitool( some version ).
The user can send settings one by one, and then use a raw command(set complete) to apply them.
It will works when running from local shell (accessing it from serial port) or remote interface.
b. If the "set complete" is sent automatically by ipmitool.
So the single change will be applied immediately, the user can operate from a local interface.
Please correct me!
Thanks!
________________________________
寄件者: Patrick Williams <patrick@stwcx.xyz>
寄件日期: 2016年10月4日 上午 09:51
收件者: tomjose
副本: Li Nan; OpenBMC Maillist
主旨: Re: IPMI LAN command story design - try 3rd send
Forwarding to list.
On Tue, Oct 04, 2016 at 03:02:54PM +0530, tomjose wrote:
> Hello Nan,
>
> The current implementation mandates the user to enter <IP
> Address>,<NetMask> and <Gateway>
> for the network settings to be changed. Even though the user wants to
> change only the IP
> address , because of the way we have implemented we are forcing the user
> to enter all the three details.
>
> The LAN settings is a property of the channel(Channel 1 typically
> corresponds to ETH0) and we can leverage
> the "Set Channel Access" command to apply the settings.We can apply the
> network settings whenever the
> Access Mode is turned on.(ipmitool lan set 1 access on)
>
> With the solution i am thinking , the Set LAN configuration command
> would not be used to apply the network
> settings but it would be used to cache the network settings and it would
> be applied when the Set Channel Access
> command is called.
>
> The following link explains the order of commands.
>
> https://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool(LAN
> Configuration section)
>
> Regarding #2 - Authentication Type Support, it seems that this section
> is not updated properly.
> Get Channel Authentication capabilities is the first command issued for
> a session setup.
> This command also has the same Authentication type support field and the
> 7th bit which
> was reserved in #2 is used in this command to specify IPMI2.0 and
> IPMI1.5 authentication
> capabilities.
>
> So since #2 is outdated to represent the necessary authentication
> capabilities, i think we do
> not need to support parameter #2.
>
> Regarding #3 - Authentication Type Enables - this is needed if we
> support different authentication
> types for different requested privilege levels. Since the authentication
> types are outdated and we
> do not support different authentication types per privilege levels, we
> can avoid this parameter.
>
> Thanks,
> Tom
>
>
>
>
> On Monday 03 October 2016 07:29 PM, Li Nan wrote:
> >
> > Hi team,
> >
> > I'm working on the story of Confirm LAN Command meet IPMI 2.0
> > https://github.com/openbmc/openbmc/issues/444
> >
> >
> > <https://github.com/openbmc/openbmc/issues/444>
> >
> > I summarize some fields of settings below, and need some help to
> > confirm the direction of my work.
> >
> > ```
> >
> >
> > 1.IPMI LAN command status and work plan
> >
> >
> > 1.1.Current status
> >
> > IPMI LAN command consists of 4 command ( refer to IPMI 2.0 Spec,
> > Chapter 23 ):Set LAN Configuration Parameters, Get LAN Configuration
> > Parameters, Suspend BMC ARPs and Get IP/UDP/RMCP Statistics.
> >
> > Existing code includes implementation of Set/Get LAN configuration
> > Parameters. ( Refer to
> > https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp
[https://avatars1.githubusercontent.com/u/13670043?v=3&s=400]<https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp>
openbmc/phosphor-host-ipmid<https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp>
github.com
phosphor-host-ipmid - dbus-based ipmid for host-endpoint IPMI commands
> > )
> >
> >
> > 1.2.IPMI LAN Command Handling
> >
> > Example for Set LAN Configuration Parameters.
> >
> > Parameter
> >
> >
> >
> > #
> >
> > Number
> >
> >
> >
> > IPMI handling
> >
> >
> >
> > dbus method
> >
> > Set In Progress(Volatile)
> >
> >
> >
> > 0
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 209.
> >
> > variable lan_set_in_progress act as a statemachine.
> >
> >
> >
> > No need.
> >
> > Authentication Type Support(Read Only)
> >
> >
> >
> > 1
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 305.
> >
> > Setto 0x4 (MD5)
> >
> >
> >
> > No need.
> >
> > Authentication Type
> >
> > Enables
> >
> >
> >
> > 2
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 311.
> >
> > Set to 0x4, 0x4, 0x4, 0x4, 0x4.
> >
> >
> >
> > No need.
> >
> > IP Address
> >
> >
> >
> > 3
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 169.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 266: SetAddress4
> >
> > MAC Address
> >
> > (can be Read Only)
> >
> >
> >
> > 5
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 174.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 334: SetHwAddress.
> >
> > Subnet Mask
> >
> >
> >
> > 6
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 199.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 266: SetAddress4
> >
> > Default Gateway Address
> >
> >
> >
> > 12
> >
> >
> >
> > phosphor-host-ipmid/transporthandler.cpp, Line 204.
> >
> >
> >
> > phosphor-neworkd/netman.py: Line 266: SetAddress4
> >
> > Handling of Get LAN Configuration Parameters command is similar to Set
> > LAN Configuration Parameters. Refer to
> > phosphor-host-ipmid/transporthandler.cpp and phosphor-networkd/netman.py.
> >
> >
> > 1.3.Gap between current code and IPMI Spec 2.0
> >
> > LAN Configuration Parameter List
> >
> > Parameter
> >
> >
> >
> > #
> >
> > Number
> >
> >
> >
> > Parameter Data( non-volatile unless otherwise noted )
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Current status/Note
> >
> > ( Yes = current support.
> >
> > No = not support. )
> >
> > Set In Progress(Volatile)
> >
> >
> >
> > 0
> >
> >
> >
> > byte 1
> >
> >
> >
> >
> >
> > 00b -= set complete
> >
> > 0ab = set in progress
> >
> > 10b = commit write
> >
> > 11b = reserved
> >
> >
> >
> > Yes
> >
> > Authentication Type Support(Read Only)
> >
> >
> >
> > 1
> >
> >
> >
> > byte 1
> >
> >
> >
> >
> >
> > Authentication type(s) enabled for this channel(bi0tfield):
> >
> > All bits: 1b =supported
> >
> > 0b= authentication type not available for use.
> >
> > [5] – OEM proprietary
> >
> > [4] – straight password / key
> >
> > [3] – reserved
> >
> > [2] – MD5
> >
> > [1] – MD2
> >
> > [0] - none
> >
> >
> >
> > Yes.
> >
> > MD5
> >
> > Authenticaton Type
> >
> > Enables
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> >
> >
> > This field is used to configure which Authentication Types are
> > available for use when a remote console activates an IPMI messaging
> > connection to the BMC for a given requested maximum privilege level.
> >
> >
> >
> > Yes.
> >
> > MD5
> >
> > IP Address
> >
> >
> >
> > 3
> >
> >
> >
> > data 1:4
> >
> > MS-byte first
> >
> >
> >
> >
> >
> > IP Address
> >
> >
> >
> > Yes
> >
> > IP Address Source
> >
> >
> >
> > 4
> >
> >
> >
> > data1
> >
> >
> >
> >
> >
> > address source
> >
> > 0h – unspecified
> >
> > 1h = static address (manually configured)
> >
> > 2h = address obtained by BMC running DHCP
> >
> > 3h = address loaded by BIOS or system software
> >
> > 4h = address obtained by BMC running other address assignment protocol
> >
> >
> >
> > No.
> >
> > MAC Address
> >
> > (can be Read Only)
> >
> >
> >
> > 5
> >
> >
> >
> > data 1:6
> >
> >
> >
> >
> >
> > MAC Address for messages transmitted from BMC.
> >
> > MS-byte first.
> >
> >
> >
> > Yes.
> >
> > Subnet Mask
> >
> >
> >
> > 6
> >
> >
> >
> > data1:4
> >
> >
> >
> >
> >
> >
> >
> > Yes
> >
> > IPv4 Header Parameter
> >
> >
> >
> > 7
> >
> >
> >
> > data1
> >
> >
> >
> >
> >
> >
> >
> > No
> >
> > Primary RMCP Port Number(optional)
> >
> >
> >
> > 8
> >
> >
> >
> > data1:2
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Secondary RMCP Port Number(optional)
> >
> >
> >
> > 9
> >
> >
> >
> > data1:2
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > BMC-generated ARP control (optional)
> >
> >
> >
> > 10
> >
> >
> >
> > data1
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Gratuitous ARP interval (optional)
> >
> >
> >
> > 11
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Default GatewayAddress
> >
> >
> >
> > 12
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yes
> >
> > Default Gateway MAC Address
> >
> >
> >
> > 13
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Backup Gateway Address
> >
> >
> >
> > 14
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Backup Gateway MAC Address
> >
> >
> >
> > 15
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Community String
> >
> >
> >
> > 16
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Number of Destinations( Read Only )
> >
> >
> >
> > 17
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Destination Type (volatile / non-volatile – see description )
> >
> >
> >
> > 18
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Destination Address
> >
> >
> >
> > 19
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Following parameters are introduced with IPMI v2.0/RMCP+
> >
> > 802.1q VLAN ID (12-bit)
> >
> >
> >
> > 20
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > 802.1q VLAN Priority
> >
> >
> >
> > 21
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > RMCP+ Messaging Cipher Suite Entry Support( Read Only )
> >
> >
> >
> > 22
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > RMCP+ Messaging Cipher Suite Entries( Read Only )
> >
> >
> >
> > 23
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > RMCP+ Messaging Cipher Suite Privilege Levels
> >
> >
> >
> > 24
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Destination Address VLAN TAGs
> >
> >
> >
> > 25
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Bad Password Threshold
> >
> >
> >
> > 26
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6/IPv4 Support
> >
> >
> >
> > 50
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6/IPv4 Addressing Enables
> >
> >
> >
> > 51
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6/IPv4 Header Static Traffic Class
> >
> >
> >
> > 52
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Header Static Hop Limit
> >
> >
> >
> > 53
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Header Flow Label
> >
> >
> >
> > 54
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Status
> >
> >
> >
> > 55
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Addresses
> >
> >
> >
> > 56
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Static DUID storage length
> >
> >
> >
> > 57
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Static DUIDs
> >
> >
> >
> > 58
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic ( SLAAC/DHCPv6) Address
> >
> >
> >
> > 59
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Dynamic DUID storage length
> >
> >
> >
> > 60
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Dynamic DUIDs
> >
> >
> >
> > 61
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Timing Configuration Support
> >
> >
> >
> > 62
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 DHCPv6 Timing & Configuration
> >
> >
> >
> > 63
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Router Address Configuration Control
> >
> >
> >
> > 64
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 IP Address
> >
> >
> >
> > 65
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 MAC Address
> >
> >
> >
> > 66
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 Prefix Length
> >
> >
> >
> > 67
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 1 Prefix Value
> >
> >
> >
> > 68
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 Address
> >
> >
> >
> > 69
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 MAC Address
> >
> >
> >
> > 70
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 Prefix Length
> >
> >
> >
> > 71
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Static Router 2 Prefix Value
> >
> >
> >
> > 72
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > Number of Dynamic Router Info Sets
> >
> >
> >
> > 73
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info IP Address
> >
> >
> >
> > 74
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info MAC Address
> >
> >
> >
> > 75
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info Prefix Length
> >
> >
> >
> > 76
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Info Prefix Value
> >
> >
> >
> > 77
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Dynamic Router Received Hop Limit
> >
> >
> >
> > 78
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Neighbor Discovery / SLAAC Timing Configuration Support
> >
> >
> >
> > 79
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > IPv6 Neighbor Discovery / SLAAC Timing Configuration
> >
> >
> >
> > 80
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> > OEM Parameters
> >
> >
> >
> > 192:255
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > No.
> >
> >
> > 1.4.Work Plan
> >
> >
> > 1.4.1.Set LAN Configuration Parameters
> >
> >
> > 1.4.2.Get LAN Configuration Parameters
> >
> > I figure out what we support in phosphor-netwokd repo ( Refer to:
> >
> > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py ) :
[https://avatars1.githubusercontent.com/u/13670043?v=3&s=400]<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
openbmc/phosphor-networkd<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
github.com
Contribute to phosphor-networkd development by creating an account on GitHub.
> >
> > * Set In Progress,
> > * Authentication Type Support,
> > * Authentication Type Enables,
> > * IP Address,
> > * MAC Address,
> > * Subnet Mask,
> > * Default Gateway Address
> >
> > So I think we only support existing configuration.
> >
> > How can I implement the rest of the configurations/parameters? (open
> > issues?)
> >
> >
> > 1.4.3.ARP
> >
> > Not implemented in Tom’s IPMI network story.
> >
> > Should I refer to
> > openbmc/import-layers/meta-openembedded/meta-networking/recipes-support/arptables
> > ?
> >
> > Optional command. Not to implement?
> >
> >
> > 1.4.4.IP/UDP/RMCP statistics
> >
> > Seems like it was not implemented in obmc stories too.
> >
> > This is an optional command. Not to implement?
> >
> >
> > 2.IPMI LAN Commands in IPMI Spec 2.0 -- Format
> >
> >
> > 1.1.Set LAN Configuration Parameters command
> >
> > Set LAN Configuration Parameters command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7:4]
> >
> >
> >
> > reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> > Parameter selector
> >
> >
> >
> >
> >
> > 3:N
> >
> >
> >
> >
> >
> > Configuration parameter data
> >
> >
> >
> > Response Data
> >
> >
> >
> > 1
> >
> >
> >
> > Completion code
> >
> >
> >
> > 80h = parameter not supported.
> >
> > 81h = attempt to set the ‘set in progress’ value (in parameter #0)
> > when not in the ‘set complete’ state. (This completion code provides a
> > way to recognize that another party has already ‘claimed’ the parameters)
> >
> > 82h = attempt to write read-only parameter
> >
> > 83h = attempt to read write-only parameter
> >
> >
> >
> > Existing code supports 7 LAN command:
> >
> > Set In Progress,
> >
> > Authentication Type Support,
> >
> > Authentication Type Enables,
> >
> > IP Address,
> >
> > MAC Address,
> >
> > Subnet Mask,
> >
> > Default Gateway Address.
> >
> > Refer to:
> >
> > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
[https://avatars1.githubusercontent.com/u/13670043?v=3&s=400]<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
openbmc/phosphor-networkd<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
github.com
Contribute to phosphor-networkd development by creating an account on GitHub.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 1.2.Get LAN Configuration Parameters Command
> >
> > Get LAN Configuration Parameters Command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7]
> >
> >
> >
> > 0b = get parameter
> >
> > 1b = get parameter revision only
> >
> >
> >
> >
> >
> >
> >
> > [6:4]
> >
> >
> >
> > reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> > Parameter selector
> >
> >
> >
> >
> >
> > 3
> >
> >
> >
> >
> >
> > Set Selector. Selects a given set of parameters under a given
> > Parameter selector value.
> >
> > 00h if parameter don’t use a Set Selector.
> >
> >
> >
> >
> >
> > 4
> >
> >
> >
> >
> >
> > Block Selector (00h if parameter does not require a block number)
> >
> >
> >
> > Response Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7:0]
> >
> >
> >
> > Completion Code.
> >
> > Generic codes, plus following command-specific completion code(s):
> >
> > 80h = parameter not supported.
> >
> >
> >
> > Existing code supports 7 LAN command:
> >
> > Set In Progress,
> >
> > Authentication Type Support,
> >
> > Authentication Type Enables,
> >
> > IP Address,
> >
> > MAC Address,
> >
> > Subnet Mask,
> >
> > Default Gateway Address.
> >
> > Refer to
> > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
[https://avatars1.githubusercontent.com/u/13670043?v=3&s=400]<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
openbmc/phosphor-networkd<https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
github.com
Contribute to phosphor-networkd development by creating an account on GitHub.
> >
> >
> >
> > 2
> >
> >
> >
> > [7:0]
> >
> >
> >
> > Parameter revision.
> >
> > Format: MSN = present revision. LSN = oldest revision parameter is
> > backward compatible with. 11h for parameters in this specification.
> >
> >
> >
> > The following data bytes are not returned when the ‘get parameter
> > revision only’ bit is 1b.
> >
> >
> >
> > 3:N
> >
> >
> >
> >
> >
> > Configuration parameter data.
> >
> > If the rollback feature is implemented, the BMC makes a copy of the
> > existing parameters when the ‘set in progress’ state becomes asserted
> > (See the Set in Progress parameter #0). While the ‘set in progress’
> > state is active, the BMC will return data from this copy of the
> > parameters, plus any uncommitted changes that were made to data.
> > Otherwise, the BMC returns parameter data from non-volatile storage.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 1.2.1.DHCPv6 Timing Parameters
> >
> > Not support.
> >
> >
> > 1.2.2.Neighbor discovery / SLAAC Timing Parameters
> >
> > Not support.
> >
> >
> > 1.3.Suspend BMC ARPs command
> >
> > Suspend BMC ARPs Command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request
> >
> >
> >
> > 1
> >
> >
> >
> > [7:4]
> >
> >
> >
> > Reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> > [7:2]
> >
> >
> >
> > Reserved
> >
> >
> >
> >
> >
> >
> >
> > [1]
> >
> >
> >
> > ARP response suspend.
> >
> >
> >
> >
> >
> >
> >
> > [0]
> >
> >
> >
> > Gratuitous ARP suspend
> >
> >
> >
> > Respond
> >
> >
> >
> > 1
> >
> >
> >
> >
> >
> > Completion code
> >
> >
> >
> > Do not support.
> >
> > ( Should refer to
> >
> > openbmc/import-layers/meta-openembedded/meta-networking/recipes-support/arptables?
> > )
> >
> >
> >
> > 2
> >
> >
> >
> >
> >
> > present state o f ARP suspension
> >
> >
> >
> >
> >
> > [7:2]
> >
> >
> >
> > reserve
> >
> >
> >
> >
> >
> > [1]
> >
> >
> >
> >
> >
> >
> >
> > [0]
> >
> >
> >
> > Address Resolution Protocol.
> >
> >
> > 1.4.Get IP/UDP/RMCP Statistics Command
> >
> > Get IP/UDP/RMCP Statistics Command
> >
> >
> >
> > Byte
> >
> >
> >
> > Bit field
> >
> >
> >
> > Description
> >
> >
> >
> > Support
> >
> > Request Data
> >
> >
> >
> > 1
> >
> >
> >
> > [7:4]
> >
> >
> >
> > reserved
> >
> >
> >
> >
> >
> >
> >
> > [3:0]
> >
> >
> >
> > Channel number
> >
> >
> >
> >
> >
> > 2
> >
> >
> >
> > [7:1]
> >
> >
> >
> > clear statistics
> >
> >
> >
> >
> >
> >
> >
> > [0]
> >
> >
> >
> >
> >
> > Respond Data
> >
> >
> >
> > 1
> >
> >
> >
> >
> >
> > Completion Code
> >
> >
> >
> > RMCP is implemented in openbmc.
> >
> > Refer to
> >
> > https://github.com/openbmc/openbmc/issues/432 and so on.
[https://avatars3.githubusercontent.com/u/105009?v=3&s=400]<https://github.com/openbmc/openbmc/issues/432>
Attaching RMCP session to SOL. · Issue #432 · openbmc/openbmc<https://github.com/openbmc/openbmc/issues/432>
github.com
openbmc - OpenBMC Distribution
> >
> > Discussed with Tom, these statistics is not implemented in
> > phosphor-networkd.
> >
> >
> >
> > 2:3
> >
> >
> >
> >
> >
> > IP Packets Received.
> >
> >
> >
> > 4:5
> >
> >
> >
> >
> >
> > Received IP Header Errors
> >
> >
> >
> > 6:7
> >
> >
> >
> >
> >
> > Received IP Address Errors
> >
> >
> >
> > 8:9
> >
> >
> >
> >
> >
> > Fragmented IP Packets Received
> >
> >
> >
> > 10:11
> >
> >
> >
> >
> >
> > IP Packets Transmitted
> >
> >
> >
> > 12:13
> >
> >
> >
> >
> >
> > UDP Packets Received
> >
> >
> >
> > 14:15
> >
> >
> >
> >
> >
> > Valid RMCP Received
> >
> >
> >
> > 16:17
> >
> >
> >
> >
> >
> > UDP Proxy Packets Received
> >
> >
> >
> > 18:19
> >
> >
> >
> >
> >
> > UDP Proxy Packets dropped
> >
> >
> > 3.End
> >
> > ```
> >
> >
> >
> >
> > _______________________________________________
> > openbmc mailing list
> > openbmc@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/openbmc
openbmc Info Page - OzLabs<https://lists.ozlabs.org/listinfo/openbmc>
lists.ozlabs.org
To see the collection of prior postings to the list, visit the openbmc Archives. Using openbmc: To post a message to all the list members, send email ...
>
--
Patrick Williams
[-- Attachment #2: Type: text/html, Size: 81198 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2016-11-03 16:22 ` Li Nan
@ 2016-11-04 13:26 ` tomjose
2016-11-04 14:14 ` Patrick Williams
0 siblings, 1 reply; 22+ messages in thread
From: tomjose @ 2016-11-04 13:26 UTC (permalink / raw)
To: Li Nan, Patrick Williams, Adriana Kobylak; +Cc: OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 31001 bytes --]
Hi Nan,
The Set Channel access command was decided to be used to mark the end of
a setting LAN configuration transaction.
The patchset logically matches with using 'Set Channel Access' to mark
the end of set LAN configuration and
apply the data from the cache.
Regards,
Tom
On Thursday 03 November 2016 09:52 PM, Li Nan wrote:
>
> Hi, Tom,
>
> I show my #444 ( story: Confirm LAN device command meet IPMI 2.0
> requirements ) implementation below. Want to clarify that how it works.
>
>
> We did some experiments, so we got that ipmitool would issue "set lan
> parameter" command like below:
> For instance, change ip address.
> After we sent "ipmitool -I dbus lan set 1 ipaddr 1.2.3.4", ipmitool
> would do:
> (1)sent Get Channel Info command.
> (2)echo "Setting LAN IP Address to 1.2.3.4" to the shell.
> (3)sent Get LAN command to fetch the value of "set in progress"(which
> is 0x0) .
> (4)sent Set LAN command to change "set in progress" parameter to "Set
> in Progress"(0x1).
> (5)sent Get LAN command to fetch the value of "set in progress"( which
> is 0x1) .
> (6)sent Set LAN command to set "ip address" with value of "A.B.C.D".
> (7)sent Get LAN command to fetch value of ip address.
> (8)sent Set LAN command to "commit write" by setting "set in progress"
> to 0x2.
> (9)sent Set LAN command to set "set in progress " to "set complete"(0x0).
>
>
> Because ipmitool would work like that, so we decided to use 2 steps to
> issue the changing of lan parameter:
> Step 1:
> Using Set LAN parameter command to cache the user setting. User can
> input one item at a time to cache. So user can put items into cache
> one be one in sequence.
>
> Step 2:
> Using Set Channel Access to apply those cached items.
>
> So the mechanism of my implementation is following above steps? right?
> https://gerrit.openbmc-project.xyz/#/c/822/
>
>
> B.R.
> Nan
>
>
> ------------------------------------------------------------------------
> *From:* openbmc
> <openbmc-bounces+william.bjlinan=hotmail.com@lists.ozlabs.org> on
> behalf of Li Nan <william.bjlinan@hotmail.com>
> *Sent:* Monday, October 17, 2016 2:55 PM
> *To:* Patrick Williams; tomjose; Adriana Kobylak
> *Cc:* OpenBMC Maillist
> *Subject:* RE: IPMI LAN command story design - try 3rd send
>
> Hi all,
>
> I summarize IPMI LAN command flow here after our discussion.
>
>
> When we want to change single ip address/Subnet mask/Gateway address,
> ipmitool (the openbmc/ipmitool) will automatically use a set of
> command to accomplish it, it works like below:
> ex. we want to change ip address.
> After we send "ipmitool -I dbus lan set 1 ipaddr A.B.C.D", ipmitool
> will do:
> (1)send Get Channel Info command.
> (2)echo "Setting LAN IP Address to A.B.C.D" to shell.
> (3)send Get LAN command to fetch the value of "set in progress"(which
> is 0x0) .
> (4)send Set LAN command to change "set in progress" parameter to "Set
> in Progress"(0x1).
> (5)send Get LAN command to fetch the value of "set in progress"( which
> is 0x1) .
> (6)send Set LAN command to set "ip address" with value of "A.B.C.D".
> (7)send Get LAN command to fetch value of ip address.
> (8)send Set LAN command to "commit write" by setting "set in progress"
> to 0x2.
> (9)send Set LAN command to set "set in progress " to "set complete"(0x0).
>
> It seems like ipmitool (some version) will automatically send SET LAN
> command to change the value of "set in progress" parameter. So "set in
> progress" can be used to identify a transaction. The value of "set in
> progress" can tell us the state of the procedure.
>
> I do my work by using "set in progress" to apply the user settings.
> (1) If user want to change only single setting of "ip address/subnet
> mask/gateway address ",
> The ipmid will cache the user setting, and wait for "set
> complete"("set in progress" parameter value is 0x0). When
> ipmid receives "set complete", it will apply this user setting and the
> other two reserved settings fetched from dbus(netman.py).
> a. If ipmitool don't send "set complete" automatically, user can
> send raw command to send it.
> b. We also can send "set complete" in the implementation of "set
> channel access" command mentioned by Tom.
> So it will looks like that single setting will be applied right away.
>
> (2)If user want to change two or three settings at the same time:
> a. If the "set complete" don't be sent automatically by ipmitool(
> some version ).
> The user can send settings one by one, and then use a raw
> command(set complete) to apply them.
> It will works when running from local shell (accessing it
> from serial port) or remote interface.
> b. If the "set complete" is sent automatically by ipmitool.
> So the single change will be applied immediately, the user
> can operate from a local interface.
>
> Please correct me!
> Thanks!
>
>
> ------------------------------------------------------------------------
> *寄件者:* Patrick Williams <patrick@stwcx.xyz>
> *寄件日期:* 2016年10月4日 上午 09:51
> *收件者:* tomjose
> *副本:* Li Nan; OpenBMC Maillist
> *主旨:* Re: IPMI LAN command story design - try 3rd send
> Forwarding to list.
>
> On Tue, Oct 04, 2016 at 03:02:54PM +0530, tomjose wrote:
> > Hello Nan,
> >
> > The current implementation mandates the user to enter <IP
> > Address>,<NetMask> and <Gateway>
> > for the network settings to be changed. Even though the user wants to
> > change only the IP
> > address , because of the way we have implemented we are forcing the
> user
> > to enter all the three details.
> >
> > The LAN settings is a property of the channel(Channel 1 typically
> > corresponds to ETH0) and we can leverage
> > the "Set Channel Access" command to apply the settings.We can apply the
> > network settings whenever the
> > Access Mode is turned on.(ipmitool lan set 1 access on)
> >
> > With the solution i am thinking , the Set LAN configuration command
> > would not be used to apply the network
> > settings but it would be used to cache the network settings and it
> would
> > be applied when the Set Channel Access
> > command is called.
> >
> > The following link explains the order of commands.
> >
> >
> https://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool(LAN
> <https://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool%28LAN>
>
> > Configuration section)
> >
> > Regarding #2 - Authentication Type Support, it seems that this section
> > is not updated properly.
> > Get Channel Authentication capabilities is the first command issued for
> > a session setup.
> > This command also has the same Authentication type support field and
> the
> > 7th bit which
> > was reserved in #2 is used in this command to specify IPMI2.0 and
> > IPMI1.5 authentication
> > capabilities.
> >
> > So since #2 is outdated to represent the necessary authentication
> > capabilities, i think we do
> > not need to support parameter #2.
> >
> > Regarding #3 - Authentication Type Enables - this is needed if we
> > support different authentication
> > types for different requested privilege levels. Since the
> authentication
> > types are outdated and we
> > do not support different authentication types per privilege levels, we
> > can avoid this parameter.
> >
> > Thanks,
> > Tom
> >
> >
> >
> >
> > On Monday 03 October 2016 07:29 PM, Li Nan wrote:
> > >
> > > Hi team,
> > >
> > > I'm working on the story of Confirm LAN Command meet IPMI 2.0
> > > https://github.com/openbmc/openbmc/issues/444
> <https://github.com/openbmc/openbmc/issues/444>
> > >
> > >
> > > <https://github.com/openbmc/openbmc/issues/444>
> > >
> > > I summarize some fields of settings below, and need some help to
> > > confirm the direction of my work.
> > >
> > > ```
> > >
> > >
> > > 1.IPMI LAN command status and work plan
> > >
> > >
> > > 1.1.Current status
> > >
> > > IPMI LAN command consists of 4 command ( refer to IPMI 2.0 Spec,
> > > Chapter 23 ):Set LAN Configuration Parameters, Get LAN Configuration
> > > Parameters, Suspend BMC ARPs and Get IP/UDP/RMCP Statistics.
> > >
> > > Existing code includes implementation of Set/Get LAN configuration
> > > Parameters. ( Refer to
> > >
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp
>
> <https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp>
>
> openbmc/phosphor-host-ipmid
> <https://github.com/openbmc/phosphor-host-ipmid/blob/master/transporthandler.cpp>
> github.com
> phosphor-host-ipmid - dbus-based ipmid for host-endpoint IPMI commands
>
>
> > > )
> > >
> > >
> > > 1.2.IPMI LAN Command Handling
> > >
> > > Example for Set LAN Configuration Parameters.
> > >
> > > Parameter
> > >
> > >
> > >
> > > #
> > >
> > > Number
> > >
> > >
> > >
> > > IPMI handling
> > >
> > >
> > >
> > > dbus method
> > >
> > > Set In Progress(Volatile)
> > >
> > >
> > >
> > > 0
> > >
> > >
> > >
> > > phosphor-host-ipmid/transporthandler.cpp, Line 209.
> > >
> > > variable lan_set_in_progress act as a statemachine.
> > >
> > >
> > >
> > > No need.
> > >
> > > Authentication Type Support(Read Only)
> > >
> > >
> > >
> > > 1
> > >
> > >
> > >
> > > phosphor-host-ipmid/transporthandler.cpp, Line 305.
> > >
> > > Setto 0x4 (MD5)
> > >
> > >
> > >
> > > No need.
> > >
> > > Authentication Type
> > >
> > > Enables
> > >
> > >
> > >
> > > 2
> > >
> > >
> > >
> > > phosphor-host-ipmid/transporthandler.cpp, Line 311.
> > >
> > > Set to 0x4, 0x4, 0x4, 0x4, 0x4.
> > >
> > >
> > >
> > > No need.
> > >
> > > IP Address
> > >
> > >
> > >
> > > 3
> > >
> > >
> > >
> > > phosphor-host-ipmid/transporthandler.cpp, Line 169.
> > >
> > >
> > >
> > > phosphor-neworkd/netman.py: Line 266: SetAddress4
> > >
> > > MAC Address
> > >
> > > (can be Read Only)
> > >
> > >
> > >
> > > 5
> > >
> > >
> > >
> > > phosphor-host-ipmid/transporthandler.cpp, Line 174.
> > >
> > >
> > >
> > > phosphor-neworkd/netman.py: Line 334: SetHwAddress.
> > >
> > > Subnet Mask
> > >
> > >
> > >
> > > 6
> > >
> > >
> > >
> > > phosphor-host-ipmid/transporthandler.cpp, Line 199.
> > >
> > >
> > >
> > > phosphor-neworkd/netman.py: Line 266: SetAddress4
> > >
> > > Default Gateway Address
> > >
> > >
> > >
> > > 12
> > >
> > >
> > >
> > > phosphor-host-ipmid/transporthandler.cpp, Line 204.
> > >
> > >
> > >
> > > phosphor-neworkd/netman.py: Line 266: SetAddress4
> > >
> > > Handling of Get LAN Configuration Parameters command is similar to
> Set
> > > LAN Configuration Parameters. Refer to
> > > phosphor-host-ipmid/transporthandler.cpp and
> phosphor-networkd/netman.py.
> > >
> > >
> > > 1.3.Gap between current code and IPMI Spec 2.0
> > >
> > > LAN Configuration Parameter List
> > >
> > > Parameter
> > >
> > >
> > >
> > > #
> > >
> > > Number
> > >
> > >
> > >
> > > Parameter Data( non-volatile unless otherwise noted )
> > >
> > >
> > >
> > > Bit field
> > >
> > >
> > >
> > > Description
> > >
> > >
> > >
> > > Current status/Note
> > >
> > > ( Yes = current support.
> > >
> > > No = not support. )
> > >
> > > Set In Progress(Volatile)
> > >
> > >
> > >
> > > 0
> > >
> > >
> > >
> > > byte 1
> > >
> > >
> > >
> > >
> > >
> > > 00b -= set complete
> > >
> > > 0ab = set in progress
> > >
> > > 10b = commit write
> > >
> > > 11b = reserved
> > >
> > >
> > >
> > > Yes
> > >
> > > Authentication Type Support(Read Only)
> > >
> > >
> > >
> > > 1
> > >
> > >
> > >
> > > byte 1
> > >
> > >
> > >
> > >
> > >
> > > Authentication type(s) enabled for this channel(bi0tfield):
> > >
> > > All bits: 1b =supported
> > >
> > > 0b= authentication type not available for use.
> > >
> > > [5] – OEM proprietary
> > >
> > > [4] – straight password / key
> > >
> > > [3] – reserved
> > >
> > > [2] – MD5
> > >
> > > [1] – MD2
> > >
> > > [0] - none
> > >
> > >
> > >
> > > Yes.
> > >
> > > MD5
> > >
> > > Authenticaton Type
> > >
> > > Enables
> > >
> > >
> > >
> > > 2
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > This field is used to configure which Authentication Types are
> > > available for use when a remote console activates an IPMI messaging
> > > connection to the BMC for a given requested maximum privilege level.
> > >
> > >
> > >
> > > Yes.
> > >
> > > MD5
> > >
> > > IP Address
> > >
> > >
> > >
> > > 3
> > >
> > >
> > >
> > > data 1:4
> > >
> > > MS-byte first
> > >
> > >
> > >
> > >
> > >
> > > IP Address
> > >
> > >
> > >
> > > Yes
> > >
> > > IP Address Source
> > >
> > >
> > >
> > > 4
> > >
> > >
> > >
> > > data1
> > >
> > >
> > >
> > >
> > >
> > > address source
> > >
> > > 0h – unspecified
> > >
> > > 1h = static address (manually configured)
> > >
> > > 2h = address obtained by BMC running DHCP
> > >
> > > 3h = address loaded by BIOS or system software
> > >
> > > 4h = address obtained by BMC running other address assignment protocol
> > >
> > >
> > >
> > > No.
> > >
> > > MAC Address
> > >
> > > (can be Read Only)
> > >
> > >
> > >
> > > 5
> > >
> > >
> > >
> > > data 1:6
> > >
> > >
> > >
> > >
> > >
> > > MAC Address for messages transmitted from BMC.
> > >
> > > MS-byte first.
> > >
> > >
> > >
> > > Yes.
> > >
> > > Subnet Mask
> > >
> > >
> > >
> > > 6
> > >
> > >
> > >
> > > data1:4
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yes
> > >
> > > IPv4 Header Parameter
> > >
> > >
> > >
> > > 7
> > >
> > >
> > >
> > > data1
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No
> > >
> > > Primary RMCP Port Number(optional)
> > >
> > >
> > >
> > > 8
> > >
> > >
> > >
> > > data1:2
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Secondary RMCP Port Number(optional)
> > >
> > >
> > >
> > > 9
> > >
> > >
> > >
> > > data1:2
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > BMC-generated ARP control (optional)
> > >
> > >
> > >
> > > 10
> > >
> > >
> > >
> > > data1
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Gratuitous ARP interval (optional)
> > >
> > >
> > >
> > > 11
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Default GatewayAddress
> > >
> > >
> > >
> > > 12
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yes
> > >
> > > Default Gateway MAC Address
> > >
> > >
> > >
> > > 13
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Backup Gateway Address
> > >
> > >
> > >
> > > 14
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Backup Gateway MAC Address
> > >
> > >
> > >
> > > 15
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Community String
> > >
> > >
> > >
> > > 16
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Number of Destinations( Read Only )
> > >
> > >
> > >
> > > 17
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Destination Type (volatile / non-volatile – see description )
> > >
> > >
> > >
> > > 18
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Destination Address
> > >
> > >
> > >
> > > 19
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Following parameters are introduced with IPMI v2.0/RMCP+
> > >
> > > 802.1q VLAN ID (12-bit)
> > >
> > >
> > >
> > > 20
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > 802.1q VLAN Priority
> > >
> > >
> > >
> > > 21
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > RMCP+ Messaging Cipher Suite Entry Support( Read Only )
> > >
> > >
> > >
> > > 22
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > RMCP+ Messaging Cipher Suite Entries( Read Only )
> > >
> > >
> > >
> > > 23
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > RMCP+ Messaging Cipher Suite Privilege Levels
> > >
> > >
> > >
> > > 24
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Destination Address VLAN TAGs
> > >
> > >
> > >
> > > 25
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Bad Password Threshold
> > >
> > >
> > >
> > > 26
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6/IPv4 Support
> > >
> > >
> > >
> > > 50
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6/IPv4 Addressing Enables
> > >
> > >
> > >
> > > 51
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6/IPv4 Header Static Traffic Class
> > >
> > >
> > >
> > > 52
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Header Static Hop Limit
> > >
> > >
> > >
> > > 53
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Header Flow Label
> > >
> > >
> > >
> > > 54
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Status
> > >
> > >
> > >
> > > 55
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Static Addresses
> > >
> > >
> > >
> > > 56
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 DHCPv6 Static DUID storage length
> > >
> > >
> > >
> > > 57
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 DHCPv6 Static DUIDs
> > >
> > >
> > >
> > > 58
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Dynamic ( SLAAC/DHCPv6) Address
> > >
> > >
> > >
> > > 59
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 DHCPv6 Dynamic DUID storage length
> > >
> > >
> > >
> > > 60
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 DHCPv6 Dynamic DUIDs
> > >
> > >
> > >
> > > 61
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 DHCPv6 Timing Configuration Support
> > >
> > >
> > >
> > > 62
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 DHCPv6 Timing & Configuration
> > >
> > >
> > >
> > > 63
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Router Address Configuration Control
> > >
> > >
> > >
> > > 64
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Static Router 1 IP Address
> > >
> > >
> > >
> > > 65
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Static Router 1 MAC Address
> > >
> > >
> > >
> > > 66
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Static Router 1 Prefix Length
> > >
> > >
> > >
> > > 67
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Static Router 1 Prefix Value
> > >
> > >
> > >
> > > 68
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Static Router 2 Address
> > >
> > >
> > >
> > > 69
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Static Router 2 MAC Address
> > >
> > >
> > >
> > > 70
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Static Router 2 Prefix Length
> > >
> > >
> > >
> > > 71
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Static Router 2 Prefix Value
> > >
> > >
> > >
> > > 72
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > Number of Dynamic Router Info Sets
> > >
> > >
> > >
> > > 73
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Dynamic Router Info IP Address
> > >
> > >
> > >
> > > 74
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Dynamic Router Info MAC Address
> > >
> > >
> > >
> > > 75
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Dynamic Router Info Prefix Length
> > >
> > >
> > >
> > > 76
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Dynamic Router Info Prefix Value
> > >
> > >
> > >
> > > 77
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Dynamic Router Received Hop Limit
> > >
> > >
> > >
> > > 78
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Neighbor Discovery / SLAAC Timing Configuration Support
> > >
> > >
> > >
> > > 79
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > IPv6 Neighbor Discovery / SLAAC Timing Configuration
> > >
> > >
> > >
> > > 80
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > > OEM Parameters
> > >
> > >
> > >
> > > 192:255
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > No.
> > >
> > >
> > > 1.4.Work Plan
> > >
> > >
> > > 1.4.1.Set LAN Configuration Parameters
> > >
> > >
> > > 1.4.2.Get LAN Configuration Parameters
> > >
> > > I figure out what we support in phosphor-netwokd repo ( Refer to:
> > >
> > > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
> ) :
> <https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
>
> openbmc/phosphor-networkd
> <https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
> github.com
> Contribute to phosphor-networkd development by creating an account on
> GitHub.
>
>
> > >
> > > * Set In Progress,
> > > * Authentication Type Support,
> > > * Authentication Type Enables,
> > > * IP Address,
> > > * MAC Address,
> > > * Subnet Mask,
> > > * Default Gateway Address
> > >
> > > So I think we only support existing configuration.
> > >
> > > How can I implement the rest of the configurations/parameters? (open
> > > issues?)
> > >
> > >
> > > 1.4.3.ARP
> > >
> > > Not implemented in Tom’s IPMI network story.
> > >
> > > Should I refer to
> > >
> openbmc/import-layers/meta-openembedded/meta-networking/recipes-support/arptables
> > > ?
> > >
> > > Optional command. Not to implement?
> > >
> > >
> > > 1.4.4.IP/UDP/RMCP statistics
> > >
> > > Seems like it was not implemented in obmc stories too.
> > >
> > > This is an optional command. Not to implement?
> > >
> > >
> > > 2.IPMI LAN Commands in IPMI Spec 2.0 -- Format
> > >
> > >
> > > 1.1.Set LAN Configuration Parameters command
> > >
> > > Set LAN Configuration Parameters command
> > >
> > >
> > >
> > > Byte
> > >
> > >
> > >
> > > Bit field
> > >
> > >
> > >
> > > Description
> > >
> > >
> > >
> > > Support
> > >
> > > Request Data
> > >
> > >
> > >
> > > 1
> > >
> > >
> > >
> > > [7:4]
> > >
> > >
> > >
> > > reserved
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [3:0]
> > >
> > >
> > >
> > > Channel number
> > >
> > >
> > >
> > >
> > >
> > > 2
> > >
> > >
> > >
> > >
> > >
> > > Parameter selector
> > >
> > >
> > >
> > >
> > >
> > > 3:N
> > >
> > >
> > >
> > >
> > >
> > > Configuration parameter data
> > >
> > >
> > >
> > > Response Data
> > >
> > >
> > >
> > > 1
> > >
> > >
> > >
> > > Completion code
> > >
> > >
> > >
> > > 80h = parameter not supported.
> > >
> > > 81h = attempt to set the ‘set in progress’ value (in parameter #0)
> > > when not in the ‘set complete’ state. (This completion code
> provides a
> > > way to recognize that another party has already ‘claimed’ the
> parameters)
> > >
> > > 82h = attempt to write read-only parameter
> > >
> > > 83h = attempt to read write-only parameter
> > >
> > >
> > >
> > > Existing code supports 7 LAN command:
> > >
> > > Set In Progress,
> > >
> > > Authentication Type Support,
> > >
> > > Authentication Type Enables,
> > >
> > > IP Address,
> > >
> > > MAC Address,
> > >
> > > Subnet Mask,
> > >
> > > Default Gateway Address.
> > >
> > > Refer to:
> > >
> > > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
> <https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
>
> openbmc/phosphor-networkd
> <https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
> github.com
> Contribute to phosphor-networkd development by creating an account on
> GitHub.
>
>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 1.2.Get LAN Configuration Parameters Command
> > >
> > > Get LAN Configuration Parameters Command
> > >
> > >
> > >
> > > Byte
> > >
> > >
> > >
> > > Bit field
> > >
> > >
> > >
> > > Description
> > >
> > >
> > >
> > > Support
> > >
> > > Request Data
> > >
> > >
> > >
> > > 1
> > >
> > >
> > >
> > > [7]
> > >
> > >
> > >
> > > 0b = get parameter
> > >
> > > 1b = get parameter revision only
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [6:4]
> > >
> > >
> > >
> > > reserved
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [3:0]
> > >
> > >
> > >
> > > Channel number
> > >
> > >
> > >
> > >
> > >
> > > 2
> > >
> > >
> > >
> > >
> > >
> > > Parameter selector
> > >
> > >
> > >
> > >
> > >
> > > 3
> > >
> > >
> > >
> > >
> > >
> > > Set Selector. Selects a given set of parameters under a given
> > > Parameter selector value.
> > >
> > > 00h if parameter don’t use a Set Selector.
> > >
> > >
> > >
> > >
> > >
> > > 4
> > >
> > >
> > >
> > >
> > >
> > > Block Selector (00h if parameter does not require a block number)
> > >
> > >
> > >
> > > Response Data
> > >
> > >
> > >
> > > 1
> > >
> > >
> > >
> > > [7:0]
> > >
> > >
> > >
> > > Completion Code.
> > >
> > > Generic codes, plus following command-specific completion code(s):
> > >
> > > 80h = parameter not supported.
> > >
> > >
> > >
> > > Existing code supports 7 LAN command:
> > >
> > > Set In Progress,
> > >
> > > Authentication Type Support,
> > >
> > > Authentication Type Enables,
> > >
> > > IP Address,
> > >
> > > MAC Address,
> > >
> > > Subnet Mask,
> > >
> > > Default Gateway Address.
> > >
> > > Refer to
> > > https://github.com/openbmc/phosphor-networkd/blob/master/netman.py
> <https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
>
> openbmc/phosphor-networkd
> <https://github.com/openbmc/phosphor-networkd/blob/master/netman.py>
> github.com
> Contribute to phosphor-networkd development by creating an account on
> GitHub.
>
>
> > >
> > >
> > >
> > > 2
> > >
> > >
> > >
> > > [7:0]
> > >
> > >
> > >
> > > Parameter revision.
> > >
> > > Format: MSN = present revision. LSN = oldest revision parameter is
> > > backward compatible with. 11h for parameters in this specification.
> > >
> > >
> > >
> > > The following data bytes are not returned when the ‘get parameter
> > > revision only’ bit is 1b.
> > >
> > >
> > >
> > > 3:N
> > >
> > >
> > >
> > >
> > >
> > > Configuration parameter data.
> > >
> > > If the rollback feature is implemented, the BMC makes a copy of the
> > > existing parameters when the ‘set in progress’ state becomes asserted
> > > (See the Set in Progress parameter #0). While the ‘set in progress’
> > > state is active, the BMC will return data from this copy of the
> > > parameters, plus any uncommitted changes that were made to data.
> > > Otherwise, the BMC returns parameter data from non-volatile storage.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 1.2.1.DHCPv6 Timing Parameters
> > >
> > > Not support.
> > >
> > >
> > > 1.2.2.Neighbor discovery / SLAAC Timing Parameters
> > >
> > > Not support.
> > >
> > >
> > > 1.3.Suspend BMC ARPs command
> > >
> > > Suspend BMC ARPs Command
> > >
> > >
> > >
> > > Byte
> > >
> > >
> > >
> > > Bit field
> > >
> > >
> > >
> > > Description
> > >
> > >
> > >
> > > Support
> > >
> > > Request
> > >
> > >
> > >
> > > 1
> > >
> > >
> > >
> > > [7:4]
> > >
> > >
> > >
> > > Reserved
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [3:0]
> > >
> > >
> > >
> > > Channel number
> > >
> > >
> > >
> > >
> > >
> > > 2
> > >
> > >
> > >
> > > [7:2]
> > >
> > >
> > >
> > > Reserved
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [1]
> > >
> > >
> > >
> > > ARP response suspend.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [0]
> > >
> > >
> > >
> > > Gratuitous ARP suspend
> > >
> > >
> > >
> > > Respond
> > >
> > >
> > >
> > > 1
> > >
> > >
> > >
> > >
> > >
> > > Completion code
> > >
> > >
> > >
> > > Do not support.
> > >
> > > ( Should refer to
> > >
> > >
> openbmc/import-layers/meta-openembedded/meta-networking/recipes-support/arptables?
> > > )
> > >
> > >
> > >
> > > 2
> > >
> > >
> > >
> > >
> > >
> > > present state o f ARP suspension
> > >
> > >
> > >
> > >
> > >
> > > [7:2]
> > >
> > >
> > >
> > > reserve
> > >
> > >
> > >
> > >
> > >
> > > [1]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [0]
> > >
> > >
> > >
> > > Address Resolution Protocol.
> > >
> > >
> > > 1.4.Get IP/UDP/RMCP Statistics Command
> > >
> > > Get IP/UDP/RMCP Statistics Command
> > >
> > >
> > >
> > > Byte
> > >
> > >
> > >
> > > Bit field
> > >
> > >
> > >
> > > Description
> > >
> > >
> > >
> > > Support
> > >
> > > Request Data
> > >
> > >
> > >
> > > 1
> > >
> > >
> > >
> > > [7:4]
> > >
> > >
> > >
> > > reserved
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [3:0]
> > >
> > >
> > >
> > > Channel number
> > >
> > >
> > >
> > >
> > >
> > > 2
> > >
> > >
> > >
> > > [7:1]
> > >
> > >
> > >
> > > clear statistics
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [0]
> > >
> > >
> > >
> > >
> > >
> > > Respond Data
> > >
> > >
> > >
> > > 1
> > >
> > >
> > >
> > >
> > >
> > > Completion Code
> > >
> > >
> > >
> > > RMCP is implemented in openbmc.
> > >
> > > Refer to
> > >
> > > https://github.com/openbmc/openbmc/issues/432
> <https://github.com/openbmc/openbmc/issues/432> and so on.
> <https://github.com/openbmc/openbmc/issues/432>
>
> Attaching RMCP session to SOL. · Issue #432 · openbmc/openbmc
> <https://github.com/openbmc/openbmc/issues/432>
> github.com
> openbmc - OpenBMC Distribution
>
>
> > >
> > > Discussed with Tom, these statistics is not implemented in
> > > phosphor-networkd.
> > >
> > >
> > >
> > > 2:3
> > >
> > >
> > >
> > >
> > >
> > > IP Packets Received.
> > >
> > >
> > >
> > > 4:5
> > >
> > >
> > >
> > >
> > >
> > > Received IP Header Errors
> > >
> > >
> > >
> > > 6:7
> > >
> > >
> > >
> > >
> > >
> > > Received IP Address Errors
> > >
> > >
> > >
> > > 8:9
> > >
> > >
> > >
> > >
> > >
> > > Fragmented IP Packets Received
> > >
> > >
> > >
> > > 10:11
> > >
> > >
> > >
> > >
> > >
> > > IP Packets Transmitted
> > >
> > >
> > >
> > > 12:13
> > >
> > >
> > >
> > >
> > >
> > > UDP Packets Received
> > >
> > >
> > >
> > > 14:15
> > >
> > >
> > >
> > >
> > >
> > > Valid RMCP Received
> > >
> > >
> > >
> > > 16:17
> > >
> > >
> > >
> > >
> > >
> > > UDP Proxy Packets Received
> > >
> > >
> > >
> > > 18:19
> > >
> > >
> > >
> > >
> > >
> > > UDP Proxy Packets dropped
> > >
> > >
> > > 3.End
> > >
> > > ```
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > openbmc mailing list
> > > openbmc@lists.ozlabs.org
> > > https://lists.ozlabs.org/listinfo/openbmc
> <https://lists.ozlabs.org/listinfo/openbmc>
> openbmc Info Page - OzLabs <https://lists.ozlabs.org/listinfo/openbmc>
> lists.ozlabs.org
> To see the collection of prior postings to the list, visit the openbmc
> Archives. Using openbmc: To post a message to all the list members,
> send email ...
>
>
> >
>
> --
> Patrick Williams
>
[-- Attachment #2: Type: text/html, Size: 133343 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2016-11-04 13:26 ` tomjose
@ 2016-11-04 14:14 ` Patrick Williams
2016-11-04 17:50 ` tomjose
0 siblings, 1 reply; 22+ messages in thread
From: Patrick Williams @ 2016-11-04 14:14 UTC (permalink / raw)
To: tomjose; +Cc: Li Nan, Adriana Kobylak, OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]
Tom,
On Fri, Nov 04, 2016 at 06:56:21PM +0530, tomjose wrote:
> The Set Channel access command was decided to be used to mark the end of
> a setting LAN configuration transaction.
The IPMI spec for the SetLanConfig has a parameter 'Set In Progress'
which states: 10b = commit write. Why are we not utilizing that? Maybe
in addition to Set Channel Access?
I don't see anything in the Set Channel Access command description that
would be obvious as a mechanism for updating IP addresses. Was that
just quick behavior we decided to do for Barreleye? Is there any reason
why we would not deprecate that behavior in favor of the Set In
Progress / commit write?
--
Patrick Williams
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2016-11-04 14:14 ` Patrick Williams
@ 2016-11-04 17:50 ` tomjose
2016-11-07 3:50 ` Patrick Williams
0 siblings, 1 reply; 22+ messages in thread
From: tomjose @ 2016-11-04 17:50 UTC (permalink / raw)
To: Patrick Williams; +Cc: Li Nan, Adriana Kobylak, OpenBMC Maillist
Hi Patrick,
In the IPMI command flow that Nan mentioned in the earlier mail. Any of
the following ipmitool command for
setting the IPv4 configuration, one of the step is to 'Commit
Write'(Step 8 in Nan's mail).
ipmitool lan set 1 ipaddr x.x.x.x
ipmitool lan set 1 netmask x.x.x.x
ipmitool lan set 1 defgw ipaddr x.x.x.x
As part of the execution of any of the above commands a commit write is
executed. In that case we cannot use
'Commit Write' as a way to denote the completion of a transaction.
The IPMI specification expects the IP configuration parameters as
non-volatile parameters. The commit write
parameter is a way to implement rollback feature. The BMC would make a
copy of the existing parameters
when the 'Set in Progress' state is asserted.
The Get/Set LAN Configuration commands do not provide an option to apply
the configuration and is identified as
LAN channel settings. The link below used 'Set Channel Access' command
to apply the settings.
(ipmitool lan set 1 access on). Since LAN configuration parameters are
channel settings, we thought of
applying the LAN configuration parameters as part of 'Set Channel
Access'. I am okie if we have
an OEM command to trigger applying the LAN settings.
https://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool
In Barreleye we did not implement the 'Set Channel Access' command.
There was no external
command to trigger apply the settings. In Barreleye the LAN settings are
applied when all the
three entries(IP Address, Netmask and Gateway address) where set. So
only to change the
IP address, the netmask and gateway address need to be re-entered, which
was an imperfect
solution.
Regards,
Tom
On Friday 04 November 2016 07:44 PM, Patrick Williams wrote:
> Tom,
>
> On Fri, Nov 04, 2016 at 06:56:21PM +0530, tomjose wrote:
>> The Set Channel access command was decided to be used to mark the end of
>> a setting LAN configuration transaction.
> The IPMI spec for the SetLanConfig has a parameter 'Set In Progress'
> which states: 10b = commit write. Why are we not utilizing that? Maybe
> in addition to Set Channel Access?
>
> I don't see anything in the Set Channel Access command description that
> would be obvious as a mechanism for updating IP addresses. Was that
> just quick behavior we decided to do for Barreleye? Is there any reason
> why we would not deprecate that behavior in favor of the Set In
> Progress / commit write?
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2016-11-04 17:50 ` tomjose
@ 2016-11-07 3:50 ` Patrick Williams
2016-11-08 10:45 ` tomjose
2017-12-13 3:08 ` Jeremy Kerr
0 siblings, 2 replies; 22+ messages in thread
From: Patrick Williams @ 2016-11-07 3:50 UTC (permalink / raw)
To: tomjose; +Cc: Li Nan, Adriana Kobylak, OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 3541 bytes --]
Tom,
Thanks for the explanation. With this website you pointed to and some
other investigation I've done, I am comfortable with us using the 'Set
Channel Access' as the time to apply the settings. The documentation of
two competition products both seem to require an 'ipmitool mc reset
warm' for IP address changes to take effect, so we are at least better
than that.
Can you internally track down a contact on the xCAT team and verify that
this will be ok with them? xCAT is an open source management tool that
uses IPMI for most of the system management and we should understand
what process they use for applying IP address changes. If they expect
to do a sequence of set-lan command and then a reset, then our
implementation using 'Set Channel Access' won't cover their cases
either.
On Fri, Nov 04, 2016 at 11:20:25PM +0530, tomjose wrote:
> Hi Patrick,
>
> In the IPMI command flow that Nan mentioned in the earlier mail. Any of
> the following ipmitool command for
> setting the IPv4 configuration, one of the step is to 'Commit
> Write'(Step 8 in Nan's mail).
>
> ipmitool lan set 1 ipaddr x.x.x.x
> ipmitool lan set 1 netmask x.x.x.x
> ipmitool lan set 1 defgw ipaddr x.x.x.x
>
> As part of the execution of any of the above commands a commit write is
> executed. In that case we cannot use
> 'Commit Write' as a way to denote the completion of a transaction.
>
> The IPMI specification expects the IP configuration parameters as
> non-volatile parameters. The commit write
> parameter is a way to implement rollback feature. The BMC would make a
> copy of the existing parameters
> when the 'Set in Progress' state is asserted.
>
> The Get/Set LAN Configuration commands do not provide an option to apply
> the configuration and is identified as
> LAN channel settings. The link below used 'Set Channel Access' command
> to apply the settings.
> (ipmitool lan set 1 access on). Since LAN configuration parameters are
> channel settings, we thought of
> applying the LAN configuration parameters as part of 'Set Channel
> Access'. I am okie if we have
> an OEM command to trigger applying the LAN settings.
>
> https://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool
>
> In Barreleye we did not implement the 'Set Channel Access' command.
> There was no external
> command to trigger apply the settings. In Barreleye the LAN settings are
> applied when all the
> three entries(IP Address, Netmask and Gateway address) where set. So
> only to change the
> IP address, the netmask and gateway address need to be re-entered, which
> was an imperfect
> solution.
>
> Regards,
> Tom
>
>
>
> On Friday 04 November 2016 07:44 PM, Patrick Williams wrote:
> > Tom,
> >
> > On Fri, Nov 04, 2016 at 06:56:21PM +0530, tomjose wrote:
> >> The Set Channel access command was decided to be used to mark the end of
> >> a setting LAN configuration transaction.
> > The IPMI spec for the SetLanConfig has a parameter 'Set In Progress'
> > which states: 10b = commit write. Why are we not utilizing that? Maybe
> > in addition to Set Channel Access?
> >
> > I don't see anything in the Set Channel Access command description that
> > would be obvious as a mechanism for updating IP addresses. Was that
> > just quick behavior we decided to do for Barreleye? Is there any reason
> > why we would not deprecate that behavior in favor of the Set In
> > Progress / commit write?
> >
>
--
Patrick Williams
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2016-11-07 3:50 ` Patrick Williams
@ 2016-11-08 10:45 ` tomjose
2016-11-08 11:41 ` Patrick Williams
2017-12-13 3:08 ` Jeremy Kerr
1 sibling, 1 reply; 22+ messages in thread
From: tomjose @ 2016-11-08 10:45 UTC (permalink / raw)
To: Patrick Williams; +Cc: Li Nan, Adriana Kobylak, OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 5148 bytes --]
Hi Patrick,
I had a discussion with xCAT team member regarding set LAN command.
xCAT does the LAN configuration from the host OS only. xCAT data to
manage a cluster is
stored in a relational database. The xCAT tables need to be updated for
the cluster and
nodes are rebooted into the genesis image and the following standard
script is run.
xCAT has no usecase to run out-of-band set lan configuration commands.
https://github.com/xcat2/xcat-core/blob/master/xCAT-genesis-scripts/bin/bmcsetup#L285
In the script the following commands are executed if the IP
configuration is static.
/ipmitool lan set 1 ipaddr x.x.x.x//
//ipmitool lan set 1 netmask x.x.x.x//
//ipmitool lan set 1 defgw ipaddr x.x.x.x/
After the above IP settings are applied, there is a step in the script,
which expects
that the ip settings are applied after 30 sec on OpenPower boxes and
eventually does a
bmc reset.
/# After network commands are issued, pause to allow the BMC to apply
(OpenPower)//
//snooze/
.
.
.
/# Cold reset the BMC//
//cold_reset_bmc/
From this it looks like the implementation done on Barreleye would work
straight with xCAT implementation.
The script has Open Power specific code as well to define specific
behavior. For example cold_reset_bmc
has code specifically for OpenPower AMI boxes, there is code for OEM
commands as well.
Since we need similar set of lan configuration commands for net-ipmid
and host-ipmid. In the case we
support Set Channel Access or an OEM command to trigger applying the ip
changes. It would mean we
modify the xCAT bmcsetup script.
Regards,
Tom
On Monday 07 November 2016 09:20 AM, Patrick Williams wrote:
> Tom,
>
> Thanks for the explanation. With this website you pointed to and some
> other investigation I've done, I am comfortable with us using the 'Set
> Channel Access' as the time to apply the settings. The documentation of
> two competition products both seem to require an 'ipmitool mc reset
> warm' for IP address changes to take effect, so we are at least better
> than that.
>
> Can you internally track down a contact on the xCAT team and verify that
> this will be ok with them? xCAT is an open source management tool that
> uses IPMI for most of the system management and we should understand
> what process they use for applying IP address changes. If they expect
> to do a sequence of set-lan command and then a reset, then our
> implementation using 'Set Channel Access' won't cover their cases
> either.
>
> On Fri, Nov 04, 2016 at 11:20:25PM +0530, tomjose wrote:
>> Hi Patrick,
>>
>> In the IPMI command flow that Nan mentioned in the earlier mail. Any of
>> the following ipmitool command for
>> setting the IPv4 configuration, one of the step is to 'Commit
>> Write'(Step 8 in Nan's mail).
>>
>> ipmitool lan set 1 ipaddr x.x.x.x
>> ipmitool lan set 1 netmask x.x.x.x
>> ipmitool lan set 1 defgw ipaddr x.x.x.x
>>
>> As part of the execution of any of the above commands a commit write is
>> executed. In that case we cannot use
>> 'Commit Write' as a way to denote the completion of a transaction.
>>
>> The IPMI specification expects the IP configuration parameters as
>> non-volatile parameters. The commit write
>> parameter is a way to implement rollback feature. The BMC would make a
>> copy of the existing parameters
>> when the 'Set in Progress' state is asserted.
>>
>> The Get/Set LAN Configuration commands do not provide an option to apply
>> the configuration and is identified as
>> LAN channel settings. The link below used 'Set Channel Access' command
>> to apply the settings.
>> (ipmitool lan set 1 access on). Since LAN configuration parameters are
>> channel settings, we thought of
>> applying the LAN configuration parameters as part of 'Set Channel
>> Access'. I am okie if we have
>> an OEM command to trigger applying the LAN settings.
>>
>> https://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool
>>
>> In Barreleye we did not implement the 'Set Channel Access' command.
>> There was no external
>> command to trigger apply the settings. In Barreleye the LAN settings are
>> applied when all the
>> three entries(IP Address, Netmask and Gateway address) where set. So
>> only to change the
>> IP address, the netmask and gateway address need to be re-entered, which
>> was an imperfect
>> solution.
>>
>> Regards,
>> Tom
>>
>>
>>
>> On Friday 04 November 2016 07:44 PM, Patrick Williams wrote:
>>> Tom,
>>>
>>> On Fri, Nov 04, 2016 at 06:56:21PM +0530, tomjose wrote:
>>>> The Set Channel access command was decided to be used to mark the end of
>>>> a setting LAN configuration transaction.
>>> The IPMI spec for the SetLanConfig has a parameter 'Set In Progress'
>>> which states: 10b = commit write. Why are we not utilizing that? Maybe
>>> in addition to Set Channel Access?
>>>
>>> I don't see anything in the Set Channel Access command description that
>>> would be obvious as a mechanism for updating IP addresses. Was that
>>> just quick behavior we decided to do for Barreleye? Is there any reason
>>> why we would not deprecate that behavior in favor of the Set In
>>> Progress / commit write?
>>>
[-- Attachment #2: Type: text/html, Size: 6316 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2016-11-08 10:45 ` tomjose
@ 2016-11-08 11:41 ` Patrick Williams
2016-11-10 2:32 ` Li Nan
0 siblings, 1 reply; 22+ messages in thread
From: Patrick Williams @ 2016-11-08 11:41 UTC (permalink / raw)
To: tomjose; +Cc: Li Nan, Adriana Kobylak, OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 283 bytes --]
Tom,
Thanks for tracking this down. I created an issue against xcat to
discuss and make sure they are happy with our direction. Hopefully this
can also be used to track any changes they need to make.
https://github.com/xcat2/xcat-core/issues/2108
--
Patrick Williams
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2016-11-08 11:41 ` Patrick Williams
@ 2016-11-10 2:32 ` Li Nan
0 siblings, 0 replies; 22+ messages in thread
From: Li Nan @ 2016-11-10 2:32 UTC (permalink / raw)
To: Patrick Williams, tomjose; +Cc: Adriana Kobylak, OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]
Tom and Patrick,
Thanks for your kindly support!
Will trace this issue too.
https://github.com/xcat2/xcat-core/issues/2108
B.R.
Nan Li
[https://avatars3.githubusercontent.com/u/105009?v=3&s=400]<https://github.com/xcat2/xcat-core/issues/2108>
ip configuration for OpenBMC-based machines (Witherspoon) · Issue #2108 · xcat2/xcat-core<https://github.com/xcat2/xcat-core/issues/2108>
github.com
The OpenBMC team has been working on our IPMI providers to ensure they are as compliant with IPMI 2.0. One of the areas being worked is the ip configuration. When the ip address is configured it i...
________________________________
From: Patrick Williams <patrick@stwcx.xyz>
Sent: Tuesday, November 8, 2016 7:41:11 PM
To: tomjose
Cc: Li Nan; Adriana Kobylak; OpenBMC Maillist
Subject: Re: IPMI LAN command story design - try 3rd send
Tom,
Thanks for tracking this down. I created an issue against xcat to
discuss and make sure they are happy with our direction. Hopefully this
can also be used to track any changes they need to make.
https://github.com/xcat2/xcat-core/issues/2108
--
Patrick Williams
[-- Attachment #2: Type: text/html, Size: 4733 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2016-11-07 3:50 ` Patrick Williams
2016-11-08 10:45 ` tomjose
@ 2017-12-13 3:08 ` Jeremy Kerr
2017-12-13 16:55 ` Chris Austen
2017-12-14 11:23 ` Tom Joseph
1 sibling, 2 replies; 22+ messages in thread
From: Jeremy Kerr @ 2017-12-13 3:08 UTC (permalink / raw)
To: Patrick Williams, tomjose; +Cc: OpenBMC Maillist
Hi all,
Digging up an old thread here, but I think this is important:
> Thanks for the explanation. With this website you pointed to and some
> other investigation I've done, I am comfortable with us using the 'Set
> Channel Access' as the time to apply the settings. The documentation of
> two competition products both seem to require an 'ipmitool mc reset
> warm' for IP address changes to take effect, so we are at least better
> than that.
The two BMC implementations that I'm aware of do not require a mc reset
for lan parameters to be applied. Both will apply settings without
further commands. One will wait 10 seconds before applying settings, to
allow multiple changes to be grouped into a single reconfiguration.
Requiring non-standard command to be issued causes a disconnect between
user expectations and our implementation. We'd have to document this
difference in behaviour for every potential sysadmin interacting with
OpenBMC.
> Can you internally track down a contact on the xCAT team and verify that
> this will be ok with them?
Not just xCAT, but every other provisioning software that will support
OpenBMC. Including ones that are custom-developed. That's not feasible.
For cases like this, we should really reconsider before coming up with
our own special interface requirements.
Regards,
Jeremy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2017-12-13 3:08 ` Jeremy Kerr
@ 2017-12-13 16:55 ` Chris Austen
2017-12-14 11:23 ` Tom Joseph
1 sibling, 0 replies; 22+ messages in thread
From: Chris Austen @ 2017-12-13 16:55 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: OpenBMC Maillist, openbmc, Patrick Williams, tomjose
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
"openbmc" <openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org> wrote on
12/12/2017 09:08:01 PM:
> From: Jeremy Kerr <jk@ozlabs.org>
> To: Patrick Williams <patrick@stwcx.xyz>, tomjose
<tomjose@linux.vnet.ibm.com>
> Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
> Date: 12/12/2017 09:08 PM
> Subject: Re: IPMI LAN command story design - try 3rd send
> Sent by: "openbmc" <openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org>
>
> Hi all,
>
> Digging up an old thread here, but I think this is important:
>
> > Thanks for the explanation. With this website you pointed to and some
> > other investigation I've done, I am comfortable with us using the 'Set
> > Channel Access' as the time to apply the settings. The documentation
of
> > two competition products both seem to require an 'ipmitool mc reset
> > warm' for IP address changes to take effect, so we are at least better
> > than that.
>
> The two BMC implementations that I'm aware of do not require a mc reset
> for lan parameters to be applied. Both will apply settings without
> further commands. One will wait 10 seconds before applying settings, to
> allow multiple changes to be grouped into a single reconfiguration.
>
> Requiring non-standard command to be issued causes a disconnect between
> user expectations and our implementation. We'd have to document this
> difference in behaviour for every potential sysadmin interacting with
> OpenBMC.
>
> > Can you internally track down a contact on the xCAT team and verify
that
> > this will be ok with them?
>
> Not just xCAT, but every other provisioning software that will support
> OpenBMC. Including ones that are custom-developed. That's not feasible.
>
> For cases like this, we should really reconsider before coming up with
> our own special interface requirements.
>
> Regards,
>
>
> Jeremy
>
Would this make sense for this to become a topic for the OpenBMC
leadership? I have to imagine all companies hit this issue.
Maybe even reach out to Mr Cory Minyard ?
[-- Attachment #2: Type: text/html, Size: 2671 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2017-12-13 3:08 ` Jeremy Kerr
2017-12-13 16:55 ` Chris Austen
@ 2017-12-14 11:23 ` Tom Joseph
2017-12-14 12:30 ` Jeremy Kerr
1 sibling, 1 reply; 22+ messages in thread
From: Tom Joseph @ 2017-12-14 11:23 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: Patrick Williams, OpenBMC Maillist, vernon.mauery
On Wednesday 13 December 2017 08:38 AM, Jeremy Kerr wrote:
> Hi all,
>
> Digging up an old thread here, but I think this is important:
>
>> Thanks for the explanation. With this website you pointed to and some
>> other investigation I've done, I am comfortable with us using the 'Set
>> Channel Access' as the time to apply the settings. The documentation of
>> two competition products both seem to require an 'ipmitool mc reset
>> warm' for IP address changes to take effect, so we are at least better
>> than that.
> The two BMC implementations that I'm aware of do not require a mc reset
> for lan parameters to be applied. Both will apply settings without
> further commands. One will wait 10 seconds before applying settings, to
> allow multiple changes to be grouped into a single reconfiguration.
>
> Requiring non-standard command to be issued causes a disconnect between
> user expectations and our implementation. We'd have to document this
> difference in behaviour for every potential sysadmin interacting with
> OpenBMC.
The command to apply BMC network settings on OpenBMC IPMI reference
implementation is set channel access, which is a standard command
mentioned in the IPMI specification.
It is not clear to me from the IPMI specification, on which
command/condition
the BMC network settings are applied. The BMC implementation that
applies the
settings after `10` sec does it after which parameter? It sounds like
an OEM/custom
way of doing and not based on IPMI specification.
If you can provide more details on how it is done on the BMC
implementation, we
can consider it as a way to implement this command.
>
>> Can you internally track down a contact on the xCAT team and verify that
>> this will be ok with them?
> Not just xCAT, but every other provisioning software that will support
> OpenBMC. Including ones that are custom-developed. That's not feasible.
>
> For cases like this, we should really reconsider before coming up with
> our own special interface requirements.
>
> Regards,
>
>
> Jeremy
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2017-12-14 11:23 ` Tom Joseph
@ 2017-12-14 12:30 ` Jeremy Kerr
2017-12-14 13:03 ` Tom Joseph
0 siblings, 1 reply; 22+ messages in thread
From: Jeremy Kerr @ 2017-12-14 12:30 UTC (permalink / raw)
To: Tom Joseph; +Cc: Patrick Williams, OpenBMC Maillist, vernon.mauery
Hi Tom,
>> Requiring non-standard command to be issued causes a disconnect between
>> user expectations and our implementation. We'd have to document this
>> difference in behaviour for every potential sysadmin interacting with
>> OpenBMC.
> The command to apply BMC network settings on OpenBMC IPMI reference
> implementation is set channel access, which is a standard command
> mentioned in the IPMI specification.
It may be a standard command, but using it in this context certainly
isn't standard, nor even a common convention.
The issue is that we're introducing an "unusual" step for this
configuration process, and expecting all users to know about it.
> It is not clear to me from the IPMI specification, on which
> command/condition
> the BMC network settings are applied.
Ideally, the settings should be applied as soon as the 'Set in progress'
flag indicates that the change is complete.
Adding the 10-second delay allows users to "batch" multiple changes,
meaning that network connectivity isn't lost between those changes. This
is purely to allow ipmitool (which doesn't have a facility to make
multiple changes before indicating that the change is complete) to be
used over the network to change the lan configuration (which is a bit
risky regardless...).
For doing this over the in-band interface, there is no harm in applying
the settings immediately.
To implement something complying to a "principle of least surprise", I'd
suggest that we should:
- batch changes, and have them applied after 10 seconds from clearing
the set-in-progress flag
- submit patches to ipmitool to allow multiple changes to be applied
at once (ie, one clearing of the set-in-progress flag).
Regards,
Jeremy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2017-12-14 12:30 ` Jeremy Kerr
@ 2017-12-14 13:03 ` Tom Joseph
2017-12-14 14:45 ` Jeremy Kerr
0 siblings, 1 reply; 22+ messages in thread
From: Tom Joseph @ 2017-12-14 13:03 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: Patrick Williams, OpenBMC Maillist, vernon.mauery
On Thursday 14 December 2017 06:00 PM, Jeremy Kerr wrote:
> Hi Tom,
>
>>> Requiring non-standard command to be issued causes a disconnect between
>>> user expectations and our implementation. We'd have to document this
>>> difference in behaviour for every potential sysadmin interacting with
>>> OpenBMC.
>> The command to apply BMC network settings on OpenBMC IPMI reference
>> implementation is set channel access, which is a standard command
>> mentioned in the IPMI specification.
> It may be a standard command, but using it in this context certainly
> isn't standard, nor even a common convention.
>
> The issue is that we're introducing an "unusual" step for this
> configuration process, and expecting all users to know about it.
>
>> It is not clear to me from the IPMI specification, on which
>> command/condition
>> the BMC network settings are applied.
> Ideally, the settings should be applied as soon as the 'Set in progress'
> flag indicates that the change is complete.
>
> Adding the 10-second delay allows users to "batch" multiple changes,
> meaning that network connectivity isn't lost between those changes. This
> is purely to allow ipmitool (which doesn't have a facility to make
> multiple changes before indicating that the change is complete) to be
> used over the network to change the lan configuration (which is a bit
> risky regardless...).
Yeah all this lack of clarity, arises from a lack of mechanism in IPMI to
apply multiple changes (IP address, netmask gateway) together. In the
ipmitool implementation the set-in-progress is cleared after each network
parameter setting.
>
> For doing this over the in-band interface, there is no harm in applying
> the settings immediately.
>
> To implement something complying to a "principle of least surprise", I'd
> suggest that we should:
>
> - batch changes, and have them applied after 10 seconds from clearing
> the set-in-progress flag
>
> - submit patches to ipmitool to allow multiple changes to be applied
> at once (ie, one clearing of the set-in-progress flag).
I prefer the second option of allowing ipmitool to explicitly clear the
set-in-progress flag.
thus allowing multiple changes to take effect.
The first option is really "unusual way" to get this done, to overcome
a specification shortcoming.
>
> Regards,
>
>
> Jeremy
>
>
>
>
>
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2017-12-14 13:03 ` Tom Joseph
@ 2017-12-14 14:45 ` Jeremy Kerr
2017-12-14 16:26 ` Vernon Mauery
0 siblings, 1 reply; 22+ messages in thread
From: Jeremy Kerr @ 2017-12-14 14:45 UTC (permalink / raw)
To: Tom Joseph; +Cc: Patrick Williams, OpenBMC Maillist, vernon.mauery
Hi Tom,
>> Adding the 10-second delay allows users to "batch" multiple changes,
>> meaning that network connectivity isn't lost between those changes. This
>> is purely to allow ipmitool (which doesn't have a facility to make
>> multiple changes before indicating that the change is complete) to be
>> used over the network to change the lan configuration (which is a bit
>> risky regardless...).
>
> Yeah all this lack of clarity, arises from a lack of mechanism in IPMI to
> apply multiple changes (IP address, netmask gateway) together.
No, the specification provides a way to do exactly that:
1) Change set-complete to 0x01
2) Send Set LAN Configuration command to update the actual LAN
configuration parameters. If more than one parameter is changed, then
multiple commands can be sent.
3) Change set-complete to 0x00
It's just that ipmitool only has code to change one parameter at a time
at (2). It still does the set-complete process.
>> To implement something complying to a "principle of least surprise", I'd
>> suggest that we should:
>>
>> - batch changes, and have them applied after 10 seconds from clearing
>> the set-in-progress flag
>>
>> - submit patches to ipmitool to allow multiple changes to be applied
>> at once (ie, one clearing of the set-in-progress flag).
>
> I prefer the second option of allowing ipmitool to explicitly clear the
> set-in-progress flag.
They're not "or" options. We'd need to do both.
> The first option is really "unusual way" to get this done, to overcome
> a specification shortcoming.
It's not a specification shortcoming; the specification explicitly
supports this, it's just that ipmitool doesn't.
The 10-second delay is a server-side workaround for that, and is present
on other BMC implementations out there. We should implement that
workaround, because asking everyone to update to a new ipmitool version
isn't feasible either.
Regards,
Jeremy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2017-12-14 14:45 ` Jeremy Kerr
@ 2017-12-14 16:26 ` Vernon Mauery
2017-12-14 21:55 ` Jeremy Kerr
0 siblings, 1 reply; 22+ messages in thread
From: Vernon Mauery @ 2017-12-14 16:26 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: Tom Joseph, Patrick Williams, OpenBMC Maillist
On 14-Dec-2017 10:45 PM, Jeremy Kerr wrote:
>Hi Tom,
>
>>> Adding the 10-second delay allows users to "batch" multiple changes,
>>> meaning that network connectivity isn't lost between those changes. This
>>> is purely to allow ipmitool (which doesn't have a facility to make
>>> multiple changes before indicating that the change is complete) to be
>>> used over the network to change the lan configuration (which is a bit
>>> risky regardless...).
>>
>> Yeah all this lack of clarity, arises from a lack of mechanism in IPMI to
>> apply multiple changes (IP address, netmask gateway) together.
>
>No, the specification provides a way to do exactly that:
>
> 1) Change set-complete to 0x01
>
> 2) Send Set LAN Configuration command to update the actual LAN
> configuration parameters. If more than one parameter is changed, then
> multiple commands can be sent.
>
> 3) Change set-complete to 0x00
>
>It's just that ipmitool only has code to change one parameter at a time
>at (2). It still does the set-complete process.
I would agree. ipmitool is broken. It should have a
network-start-configure mechanism that would set the set-complete bit.
The you could send any number of its network configuration parameters.
Then it should have a network-finish-configure command that would clear
the set-complete bit.
In the case where people forget to send the final command, the BMC
should implement a timeout so it can automatically apply the settings
and clear the flag after a certain amount of time (10 seconds or more).
It appears that ipmitool had a short period of activity there at the
beginning of 2017, but not a peep since. I pushed a fix for a bug
several weeks back and have not heard anything.
--Vernon
>>> To implement something complying to a "principle of least surprise", I'd
>>> suggest that we should:
>>>
>>> - batch changes, and have them applied after 10 seconds from clearing
>>> the set-in-progress flag
>>>
>>> - submit patches to ipmitool to allow multiple changes to be applied
>>> at once (ie, one clearing of the set-in-progress flag).
>>
>> I prefer the second option of allowing ipmitool to explicitly clear the
>> set-in-progress flag.
>
>They're not "or" options. We'd need to do both.
>
>> The first option is really "unusual way" to get this done, to overcome
>> a specification shortcoming.
>
>It's not a specification shortcoming; the specification explicitly
>supports this, it's just that ipmitool doesn't.
>
>The 10-second delay is a server-side workaround for that, and is present
>on other BMC implementations out there. We should implement that
>workaround, because asking everyone to update to a new ipmitool version
>isn't feasible either.
>
>Regards,
>
>
>Jeremy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2017-12-14 16:26 ` Vernon Mauery
@ 2017-12-14 21:55 ` Jeremy Kerr
2017-12-14 23:35 ` Patrick Venture
2017-12-15 5:08 ` Tom Joseph
0 siblings, 2 replies; 22+ messages in thread
From: Jeremy Kerr @ 2017-12-14 21:55 UTC (permalink / raw)
To: Vernon Mauery; +Cc: Tom Joseph, Patrick Williams, OpenBMC Maillist
Hi Vernon,
> I would agree. ipmitool is broken. It should have a
> network-start-configure mechanism that would set the set-complete bit.
> The you could send any number of its network configuration parameters.
> Then it should have a network-finish-configure command that would clear
> the set-complete bit.
Or, even simpler: allow multiple parameter changes on one invocation:
ipmitool [...] lan set 1 ipsrc static ipaddr 192.168.0.2 netmask 255.255.255.0
[which changes all parameters under one transition of the set-complete
flag]
Then, there's no need to modify existing users' behaviour, and no
concern about forgetting to apply.
Regards,
Jeremy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2017-12-14 21:55 ` Jeremy Kerr
@ 2017-12-14 23:35 ` Patrick Venture
2017-12-15 5:08 ` Tom Joseph
1 sibling, 0 replies; 22+ messages in thread
From: Patrick Venture @ 2017-12-14 23:35 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: Vernon Mauery, OpenBMC Maillist
Along with any change here, and sorry I haven't followed the email
thread is that the network configuration is applied when "access on"
is sent over IPMI and not when the "set complete" flag is set. That's
an easy move of code from one place to another in the IPMI daemon.
On Thu, Dec 14, 2017 at 1:55 PM, Jeremy Kerr <jk@ozlabs.org> wrote:
> Hi Vernon,
>
>> I would agree. ipmitool is broken. It should have a
>> network-start-configure mechanism that would set the set-complete bit.
>> The you could send any number of its network configuration parameters.
>> Then it should have a network-finish-configure command that would clear
>> the set-complete bit.
>
> Or, even simpler: allow multiple parameter changes on one invocation:
>
> ipmitool [...] lan set 1 ipsrc static ipaddr 192.168.0.2 netmask 255.255.255.0
>
> [which changes all parameters under one transition of the set-complete
> flag]
>
> Then, there's no need to modify existing users' behaviour, and no
> concern about forgetting to apply.
>
> Regards,
>
>
> Jeremy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2017-12-14 21:55 ` Jeremy Kerr
2017-12-14 23:35 ` Patrick Venture
@ 2017-12-15 5:08 ` Tom Joseph
2017-12-18 16:19 ` Vernon Mauery
1 sibling, 1 reply; 22+ messages in thread
From: Tom Joseph @ 2017-12-15 5:08 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: Vernon Mauery, Patrick Williams, OpenBMC Maillist
On Friday 15 December 2017 03:25 AM, Jeremy Kerr wrote:
> Hi Vernon,
>
>> I would agree. ipmitool is broken. It should have a
>> network-start-configure mechanism that would set the set-complete bit.
>> The you could send any number of its network configuration parameters.
>> Then it should have a network-finish-configure command that would clear
>> the set-complete bit.
> Or, even simpler: allow multiple parameter changes on one invocation:
>
> ipmitool [...] lan set 1 ipsrc static ipaddr 192.168.0.2 netmask 255.255.255.0
>
> [which changes all parameters under one transition of the set-complete
> flag]
>
> Then, there's no need to modify existing users' behaviour, and no
> concern about forgetting to apply.
Jeremy,
I was carried away by the ipmitool implementation when i was trying to
understand how this works.
But this looks like a neat way to get the network settings applied.
>
> Regards,
>
>
> Jeremy
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: IPMI LAN command story design - try 3rd send
2017-12-15 5:08 ` Tom Joseph
@ 2017-12-18 16:19 ` Vernon Mauery
0 siblings, 0 replies; 22+ messages in thread
From: Vernon Mauery @ 2017-12-18 16:19 UTC (permalink / raw)
To: Tom Joseph; +Cc: Jeremy Kerr, Patrick Williams, OpenBMC Maillist
On 15-Dec-2017 10:38 AM, Tom Joseph wrote:
>
>
>On Friday 15 December 2017 03:25 AM, Jeremy Kerr wrote:
>>Hi Vernon,
>>
>>>I would agree. ipmitool is broken. It should have a
>>>network-start-configure mechanism that would set the set-complete bit.
>>>The you could send any number of its network configuration parameters.
>>>Then it should have a network-finish-configure command that would clear
>>>the set-complete bit.
>>Or, even simpler: allow multiple parameter changes on one invocation:
>>
>> ipmitool [...] lan set 1 ipsrc static ipaddr 192.168.0.2 netmask 255.255.255.0
>>
>>[which changes all parameters under one transition of the set-complete
>>flag]
>>
>>Then, there's no need to modify existing users' behaviour, and no
>>concern about forgetting to apply.
>
>Jeremy,
>
>I was carried away by the ipmitool implementation when i was trying to
>understand how this works.
>
>But this looks like a neat way to get the network settings applied.
I agree. This makes it more like ip or ifconfig where you can set it all
up with one command. So who is drafting the patch? :)
--Vernon
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2017-12-18 16:19 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-03 13:59 IPMI LAN command story design - try 3rd send Li Nan
[not found] ` <57F37746.6040304@linux.vnet.ibm.com>
2016-10-04 14:51 ` Patrick Williams
2016-10-17 6:55 ` Li Nan
2016-11-03 16:22 ` Li Nan
2016-11-04 13:26 ` tomjose
2016-11-04 14:14 ` Patrick Williams
2016-11-04 17:50 ` tomjose
2016-11-07 3:50 ` Patrick Williams
2016-11-08 10:45 ` tomjose
2016-11-08 11:41 ` Patrick Williams
2016-11-10 2:32 ` Li Nan
2017-12-13 3:08 ` Jeremy Kerr
2017-12-13 16:55 ` Chris Austen
2017-12-14 11:23 ` Tom Joseph
2017-12-14 12:30 ` Jeremy Kerr
2017-12-14 13:03 ` Tom Joseph
2017-12-14 14:45 ` Jeremy Kerr
2017-12-14 16:26 ` Vernon Mauery
2017-12-14 21:55 ` Jeremy Kerr
2017-12-14 23:35 ` Patrick Venture
2017-12-15 5:08 ` Tom Joseph
2017-12-18 16:19 ` Vernon Mauery
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.