Hi and thanks for all the infos.
I have to add that I am not a "real" dev, in the way that my
understanding is somehow "limited" for now.
It makes me think of FTP active-mode relative tortuous mechanisms
........ compared to the initial "simple" need which is "I want to
transfer files!" :D
There are reasons for this but it's always a little frustrating !!
I finished complaining :D
we haven't choosed NAT for security purpose, but because our customer
were too short in public IPs , etc
And so... a bunch of port forwarding rules everywhere.
For each Dell server, there is a BMC interface configured with static
private IP. (means the server side is somehow "hardcoded", I can't act
on server behavior).
Then I was asked if there was a way to not bounce/log on servers within
the local network to get to any other server console with ipmitool. So I
suggested the "NAT" solution (and pointed to security issues it implies. )
I thank you for the suggestions and documentation pointers btw. I have
to find the most trivial solution :D
About what you suggested:
1) Make sure that Table 26-5, SOL Configuration Parameters, parameter 2,
bits 6 and 7 are not set.
2) Make sure that the Table 24-2 Activate Payload Command page 332 sent
by IPMITool does not have bits in field 3:6, byte 1, bits 6 and 7 set.
How do I do that ?
If there is no simple solution to that
"SOL-thru-DellBMC-farm-behind-the-NAT-router", I will simply explain
that to my customer.
Thanks !!
Le 03/01/2012 04:00, Hank Bruning a écrit :
Hi Martin,
I think part of the confusion is that the code snippet you provided
does not implement the IPMI standard. The line
lprintf(LOG_ERR, "Error: BMC requests SOL session on different port");
is not an IPMI error and the BMC is preforming it's intended function.
IPMI does allow the different port. Infact that line should be
replaced by a huge amount of logic. IPMI allows the allocation of the
SOL session on any existing RMCP session(IPMI 2.0, Section 24.1
Activate Payload Command, page 330. All references in this email are
to the IPMI 2.0 version dated June 12, 2009) or the creation of a new
RMCP session.
Since IPMITool does not track multiple existing RMCP sessions it
appears that it just prints the error.
Al Chu provided a very concise and correct overview of the SOL session
creation.
If you want some more detail here is a web page but there are two
things to note.
1) This is a programming reference page for a Java library. Since you
are looking at IPMItool internals it not much of a stretch. The links
that begin with "IPMI 2.0" are especially useful. All our software has
links back to the IPMI spec to the page number of relevant decisions.
2) Full disclosure. The web page is for a library called Hemi that my
company provides which replaces IPMItool for high end system managers
implemented in Java.
This is the page
http://www.jblade.com:8080/jbpublic/products/hemi/doc/programmers/HemiSol.html
I'm not sure there is a solution to your problem but try these options
to keep the SOL session using port 623
1) Make sure that Table 26-5, SOL Configuration Parameters, parameter
2, bits 6 and 7 are not set.
2) Make sure that the Table 24-2 Activate Payload Command page 332
sent by IPMITool does not have bits in field 3:6, byte 1, bits 6 and
7 set.
Another approach. This may not meet your needs but abandon the NAT as
a method of security and change to use IEEE 802.1q VLAN as documented
in IPMI 2.0 Table 23-4, LAN Configuration Parameters, parameter #25
and send the VLAN to an encryption/decryption device before forwarding
the UDP stream to the unsecured network.
Hank
JBlade
On Sat, Dec 31, 2011 at 11:26 AM, Al Chu <ch...@llnl.gov
<mailto:ch...@llnl.gov>> wrote:
Hi Martin,
Sorry, it can be confusing to new folks.
With 99% of IPMI over LAN, the communication is always through
port 623.
With SOL, it can be slightly different. The series of events is:
1. Client connects to server/BMC over port 623.
2. Client authenticates w/ server/BMC.
3. server/BMC informs client what port to communicate for SOL.
4a. If server/BMC tells client to use port 623, SOL session continues
under the current connection/session
4b. If server/BMC tells client to use port XXX, client should
disconnect and reconnect under port XXX.
To my knowledge, the disconnect/reconnect under non-port-623 is not
supported in ipmitool. If this is happening with your motherboard, it
would explain your problem.
Al
On Fri, 2011-12-30 at 08:06 -0800, Martin Hamant wrote:
> I'm lost.
> Let me formulate what I understand:
>
> ipmitool is a tool to connect to any (most?) baseboard management
> controller, to get/set system settings.
> ipmitool with default settings connects on port 623/UDP
>
> This was the easiest part :D And to this point all is going well
WITH or
> without PNAT (I can use "chassis" commands etc)
>
> now SOL. Something different is happening when ipmitool ask a SOL
> session. (thru lanplus interface)
>
> Do I have to understand that ipmitool "sol" arg simply doesn't
take the
> given command line "-p <port>" arg into account ?
>
>
> I tried to read IPMI specification but I have to say this is a
little
> complex to eat it like this, at least for me :)
>
> If someone can briefly explain me what's happen when asking a SOL
> session thru IPMI (what is "this" trying to connect to "that",
on which
> (random) port)
>
>
> Maybe I could find a workaround then (other than SOLProxy ^^ )
to get to
> my BMC interface / console redirection from the internet
>
> Thanks again !!
>
> -
>
> Le 30/12/2011 16:41, Al Chu a écrit :
> > I think this is what Hank is talking about. SOL connects at
port 623,
> > but it may communicate over a different port later in the session.
> >
> > However, ipmitool doesn't support communication over any port
other than
> > 623. So if SOL works for you w/o port forwarding, then this
isn't your
> > issue.
> >
> > Al
> >
> > On Fri, 2011-12-30 at 04:27 -0800, Martin Hamant wrote:
> >> Hi Hank,
> >>
> >> Thanks for you reply, but I'm still not sure we speak about
the same
> >> thing :/
> >>
> >> I also have discovered in ipmi_sol.c / ipmitool :
> >>
> >> (...)
> >> /* NOTE: the spec does allow for SOL traffic to be sent on
> >> * a different port. we do not yet support that feature. */
> >> if (intf->session->sol_data.port != intf->session->port)
> >> {
> >> /* try byteswapping port in case BMC sent it
incorrectly */
> >> uint16_t portswap =
BSWAP_16(intf->session->sol_data.port);
> >>
> >> if (portswap == intf->session->port) {
> >> intf->session->sol_data.port = portswap;
> >> }
> >> else {
> >> lprintf(LOG_ERR, "Error: BMC requests SOL session on
> >> different port");
> >> return -1;
> >> }
> >> }
> >> (...)
> >>
> >> the comment seems to explains why I get this message...
> >>
> >> Le 30/12/2011 13:12, Hank Bruning a écrit :
> >>> The RMCP server can use any UDP port it wants to for a SOL
session.
> >>> Some implementations use port 623. If you have more than two SOL
> >>> sessions open on a single RMCP server at least one will be
on a port
> >>> other than 623. Each of the SOL sessions may be encrypted
> >>> differently using separate cipher suites(or none at all).
> >>> Hank
> >>> JBlade
> >>>
> >>> On Fri, Dec 30, 2011 at 6:34 AM, Martin
Hamant<mar...@sound4.biz <mailto:mar...@sound4.biz>>
> >>> wrote:
> >>> Hi !!!
> >>>
> >>> I have a BMC configured with a local IP adress
(192.168.X.X)
> >>> listening
> >>> on default port (623).
> >>>
> >>> I want to access it from the outside world. For
that I have
> >>> set a port
> >>> forwarding rules on the router to the port 623 of
this local
> >>> IP.
> >>>
> >>> every ipmitool commands works well BUT not SOL.
> >>>
> >>> # ipmitool -I lanplus -p (external_port) -U (...)
-P (...)
> >>> -H (external
> >>> IP) sol activate
> >>>
> >>> I get the message: "Error: BMC requests SOL session on
> >>> different port"
> >>>
> >>> I'm not sure to understand exactly what it means ?
What I
> >>> need to do to
> >>> make this work ?
> >>>
> >>> Thanks !!
> >>>
> >>>
------------------------------------------------------------------------------
> >>> Ridiculously easy VDI. With Citrix VDI-in-a-Box,
you don't
> >>> need a complex
> >>> infrastructure or vast IT resources to deliver
seamless,
> >>> secure access to
> >>> virtual desktops. With this all-in-one solution, easily
> >>> deploy virtual
> >>> desktops for less than the cost of PCs and save 60%
on VDI
> >>> infrastructure
> >>> costs. Try it free!
http://p.sf.net/sfu/Citrix-VDIinabox
> >>> _______________________________________________
> >>> Ipmitool-devel mailing list
> >>> Ipmitool-devel@lists.sourceforge.net
<mailto:Ipmitool-devel@lists.sourceforge.net>
> >>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
> >>>
--
Albert Chu
ch...@llnl.gov <mailto:ch...@llnl.gov>
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
