freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-devel] FreeIPMI 0.7.4 Released


From: david maxera - Sun Microsystems - Prague Czech Republic
Subject: Re: [Freeipmi-devel] FreeIPMI 0.7.4 Released
Date: Mon, 05 Jan 2009 19:56:21 +0100
User-agent: Thunderbird 2.0.0.16 (X11/20080807)

Hi Al,


> Usually it should be obvious.  For example, running ipmi-sensors should
> get you sensor readings and such.  Looking at the freeipmi(7) manpage,
> it might be worthwhile to put a short section on "what is IPMI" and some
> sanity check introduction in there.  I'll put that on my TODO.

# ipmi-sensors --debug
getpwuid_r: Error 0


It looks like HAVE_FUNC_GETPWUID_R_5 is not defined, apparently getpwuid_r() has only 4 parameters at Solaris. And _get_home_directory(...) in tool-sdr-cache-common.c requires it. Ok, the problem is clear here, I'll figure something.

Nothing else seems to be working, or at least I haven't guessed the correct combination of parameters. Say,
 >  ipmipower -h latte2-sp -u <my_sp_user> -p <my_sp_password> --debug -s
latte2-sp: =====================================================
latte2-sp: IPMI 1.5 Get Channel Authentication Capabilities Request
latte2-sp: =====================================================
latte2-sp: RMCP Header:
latte2-sp: ------------
latte2-sp: [               6h] = version[ 8b]
latte2-sp: [               0h] = reserved[ 8b]
latte2-sp: [              FFh] = sequence_number[ 8b]
latte2-sp: [               7h] = message_class.class[ 5b]
latte2-sp: [               0h] = message_class.reserved[ 2b]
latte2-sp: [               0h] = message_class.ack[ 1b]
latte2-sp: IPMI Session Header:
latte2-sp: --------------------
latte2-sp: [               0h] = authentication_type[ 8b]
latte2-sp: [               0h] = session_sequence_number[32b]
latte2-sp: [               0h] = session_id[32b]
latte2-sp: [               9h] = ipmi_msg_len[ 8b]
latte2-sp: IPMI Message Header:
latte2-sp: --------------------
latte2-sp: [              20h] = rs_addr[ 8b]
latte2-sp: [               0h] = rs_lun[ 2b]
latte2-sp: [               6h] = net_fn[ 6b]
latte2-sp: [              C8h] = checksum1[ 8b]
latte2-sp: [              81h] = rq_addr[ 8b]
latte2-sp: [               0h] = rq_lun[ 2b]
latte2-sp: [              12h] = rq_seq[ 6b]
latte2-sp: IPMI Command Data:
latte2-sp: ------------------
latte2-sp: [              38h] = cmd[ 8b]
latte2-sp: [               Eh] = channel_number[ 4b]
latte2-sp: [               0h] = reserved1[ 4b]
latte2-sp: [               3h] = maximum_privilege_level[ 4b]
latte2-sp: [               0h] = reserved2[ 4b]
latte2-sp: IPMI Trailer:
latte2-sp: --------------
latte2-sp: [              EEh] = checksum2[ 8b]


Truss reveals that sendto(...) syscall fails with Err#124 EAFNOSUPPORT - as if some network protocol wasn't supported or what. But in ipmiping, sendto() passes OK. What could it be?

This on the other hand is unexpected.  I'm not really sure why you would
get a EAFNOSUPPORT error.  I suppose its possible there's some subtlety
with opensolaris in the code that I'm not handling properly?  If you
could send me the --debug output and the truss output that'd be great.
Could you also try other tools (bmc-info, ipmi-sensors) out of band and
let me know if the results are the same?

Out of band bmc-info returns  "bmc-info: invalid hostname".

Well, I now see that the problem isn't in my wrong understanding of FreeIPMI, but rather in the Solaris naming functions. This is basically the information I needed ;-)

Thanks.

David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]