Specifications
BMC Messaging Interfaces QSSC-S4R Technical Product Specification
296
x When Block Size < 16, it must be the last Block request in this series. In other words Byte 2 is equal to “Update is
complete” (1) on that request.
x When ever Block Size < 16, the Block data bytes must end with a NULL Character or Byte (=0).
x All Block write requests are updated into a local Memory byte array. When Byte 2 is set to “Update is Complete”,
the Local Memory is committed to the NV Storage. Local Memory is reset to NULL after changes are committed.
- When BYTE 1 (Block Selector = 1), FW will reset all the 64 bytes local memory. This can be used to undo
any changes after the last “Update in Progress”.
- User should always set the hostname starting from block selector 1 after the last “Update is complete”. If
the user skips block selector 1 while setting the hostname, the BMC will record the hostname as “NULL,” because
the first block contains NULL data.
- This scheme effectively does not allow user to make a partial Hostname change. Any Hostname change
needs to start from Block 1.
x Byte 64 ( Block Selector 04h byte 16) is always ignored and set to NULL by BMC which effectively means we can
set only 63 bytes.
x User is responsible for keeping track of the Set series of commands and Local Memory contents.
While IBMC FW is in “Set Hostname in Progress” (Update not complete), the FW continues using the Previous
Hostname for DHCP purposes.
25.9.7 Address Resolution Protocol (ARP)
The
BMC
can
receive
and
respond
t
o
ARP
reques
t
s
on
BMC
N
I
Cs
, Gratuitous ARPs are supported and disabled by
default.
25.9.8
I
n
t
e
r
n
e
t
C
o
n
t
r
o
l
M
e
ssa
g
e
P
r
o
t
o
c
o
l
(
I
C
M
P
)
The
BMC
suppor
t
s
t
he
f
ollowing
I
CMP
message
t
ypes
t
arge
t
ing
t
he
BMC
over in
t
egra
t
ed
N
I
Cs
:
x
Echo
reques
t
(ping)
:
The
BMC
sends
an
Echo
Reply
.
x
Des
t
ina
t
ion
unreachable
:
If
message
is
associa
t
ed
wi
t
h
an
ac
t
ive
socke
t
connec
t
ion
wi
t
hin
t
he
BMC
,
t
he
BMC
closes
t
he
socke
t.
25.9.9
V
i
r
t
u
a
l
L
o
c
a
l
A
r
e
a
N
e
t
w
o
r
k
(
V
L
A
N
)
No
t
suppor
t
ed.
25.9.10
S
e
c
u
r
e
S
h
e
ll
(
SS
H
)
Secure
Shell
(SSH)
connec
t
ions
are
suppor
t
ed
f
or
SMASH-CLP
sessions
t
o
t
he BMC
.
25.9.11
S
e
r
i
a
l
-o
v
e
r
-
L
A
N
(
S
O
L
2
.
0
)
The
BMC
suppor
t
s
I
PM
I
2
.
0
SOL
.I
PM
I
2
.
0
in
t
roduced
a
s
t
andard
serial-over-LAN
f
ea
t
ure
.
This
is
implemen
t
ed
as
a
s
t
andard
payload
t
ype
(01h)
over
RMCP+
.
Three
commands
are
implemen
t
ed
f
or
SOL
2
.
0
con
f
igura
t
ion
.
x “
Ge
t
SOL
2
.
0
Con
f
igura
t
ion
Parame
t
ers
”
and
“
Se
t
SOL
2
.
0
Con
f
igura
t
ion Parame
t
ers
”
:
These
commands
are
used
t
o
ge
t
and
se
t
t
he
values
o
f
t
he
SOL con
f
igura
t
ion
parame
t
ers
.
The
parame
t
ers
are
implemen
t
ed
on
a
per-
channel basis
.
x “Activating SOL”: This command is not accepted by the BMC. It is sent by the BMC when SOL is activated, to
notify a remote client of the switch to SOL.
Ac
t
iva
t
ing
a
SOL
session
requires
an
exis
t
ing
I
PM
I
-over-LAN
session
.
If
encryp
t
ion is
used
,
i
t
should
be
nego
t
ia
t
ed
when
t
he
I
OL
session
is
es
t
ablished
.
SOL
sessions are
only
suppor
t
ed
on
serial
por
t
1
(COM1)
.