From owner-freebsd-net@FreeBSD.ORG Tue Mar 15 21:03:19 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF76B16A4CE for ; Tue, 15 Mar 2005 21:03:19 +0000 (GMT) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14ACF43D41 for ; Tue, 15 Mar 2005 21:03:19 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.12.11) with ESMTP id j2FL32hc052551; Tue, 15 Mar 2005 16:03:07 -0500 (EST) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: Jeff Date: Tue, 15 Mar 2005 16:02:59 -0500 User-Agent: KMail/1.6.2 References: <4235E6CC.7040909@santaba.com> <200503151232.44158.jkim@niksun.com> <42371E86.7090503@santaba.com> In-Reply-To: <42371E86.7090503@santaba.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503151602.59419.jkim@niksun.com> X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 18:35:33 2005 on anuket.mj.niksun.com X-Virus-Status: Clean cc: freebsd-net@freebsd.org cc: Julian Elischer Subject: Re: IPMI doesn't work... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2005 21:03:19 -0000 On Tuesday 15 March 2005 12:42 pm, Jeff wrote: > Jung-uk Kim wrote: > >On Tuesday 15 March 2005 01:14 am, Jeff Behl wrote: > >>Julian Elischer wrote: > >>>Jeff wrote: > >>>>I'm not sure what you mean by in band. The IP address of the > >>>>BMC is assigned via the bios and is different from what the OS > >>>>later assigns. With imiptool we can turn on/powercycle/monitor > >>>>via the BMC assigned address up until the point where the > >>>> kernel loads. Once it does, the BMC no longer responds. This > >>>> doesn't happen with the two linux distros we've tried it on. > >>>> Wtih both, including SuSE, we can still query/control via the > >>>> BMC using ipmitool. It seems to be some sort of driver issue > >>>> to me. I find it confusing that the NIC is shared between the > >>>> BMC and the OS, but I guess that's just how it's done. > >>>> Perhaps the bsd broadcomm driver is simply blocking this > >>>> somehow... > >>> > >>>you have to assign it the same address! > >> > >>that's not the way it's supposed to work, afaik. it'd be silly > >> to tie the BMC address and the OS assigned address together. > >> you give the BMC an ip address via a little program that comes > >> from IBM and this address is independent of the ip address that > >> whatever os you use on the system assigns to the nic. the > >> redbook that Jung-uk sent a link for shows this process if > >> you're interested. > > > >I believe you are correct. If you have the same IP address, the > >packet reaches host OS and (I think) it must be discarded by OS. > >IPMI spec. is very verbose but I found very simple explanation > > here: > > > >http://www.ethereal.com/lists/ethereal-dev/200304/msg00233.html > > > >'IPMI messages are encapsulated in Remote Management Control > > Protocol packets. RMCP is a UDP-based protocol that uses port > > 623 for remote system control when the system is in a pre-os or > > os-absent state. RMCP can also use port 664 for secure traffic.' > > > >FYI, IPMI v2.0 defines extended RMCP, so called RMCP+. > > > >>like i said earlier, having different ip addresses (the BMC's > >> being in private address space) works fine with the linux > >> kernel... > > > >Just out of my curiosity, are you using bcm or tg3 driver on > > Linux? > > > >Thanks, > > > >Jung-uk Kim > > the tg3, according to lsmod. it looks like the bcm and the tg3 > share common code (tigon3.c is included in the bcm source)... I just glanced at bcm5700 and tg3 drivers. ;-) If my guess is correct, ASF related registers (grep -i asf *) are controlling this function. Unfortunately it doesn't seem trivial to implement something similar for bge(4). :-( Jung-uk Kim