IPMI LAN command story design - try 3rd send
Li Nan
william.bjlinan at hotmail.com
Fri Nov 4 03:22:08 AEDT 2016
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 at lists.ozlabs.org> on behalf of Li Nan <william.bjlinan at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161103/da6d6908/attachment-0001.html>
More information about the openbmc
mailing list