You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(30) |
Feb
(4) |
Mar
(52) |
Apr
(27) |
May
(15) |
Jun
(33) |
Jul
(32) |
Aug
(48) |
Sep
(25) |
Oct
(28) |
Nov
(22) |
Dec
(16) |
2005 |
Jan
(22) |
Feb
(72) |
Mar
(29) |
Apr
(35) |
May
(22) |
Jun
(20) |
Jul
(23) |
Aug
(28) |
Sep
(7) |
Oct
(11) |
Nov
(33) |
Dec
(32) |
2006 |
Jan
(55) |
Feb
(34) |
Mar
(50) |
Apr
(29) |
May
(33) |
Jun
(19) |
Jul
(37) |
Aug
(46) |
Sep
(100) |
Oct
(38) |
Nov
(54) |
Dec
(38) |
2007 |
Jan
(34) |
Feb
(63) |
Mar
(37) |
Apr
(40) |
May
(41) |
Jun
(21) |
Jul
(27) |
Aug
(39) |
Sep
(38) |
Oct
(24) |
Nov
(42) |
Dec
(35) |
2008 |
Jan
(8) |
Feb
(26) |
Mar
(18) |
Apr
(24) |
May
(24) |
Jun
(43) |
Jul
(46) |
Aug
(35) |
Sep
(7) |
Oct
(21) |
Nov
(24) |
Dec
(21) |
2009 |
Jan
(51) |
Feb
(21) |
Mar
(31) |
Apr
(27) |
May
(23) |
Jun
(31) |
Jul
(35) |
Aug
(22) |
Sep
(14) |
Oct
(12) |
Nov
(24) |
Dec
(15) |
2010 |
Jan
(8) |
Feb
(53) |
Mar
(61) |
Apr
(11) |
May
(11) |
Jun
(5) |
Jul
(9) |
Aug
(14) |
Sep
(18) |
Oct
(19) |
Nov
(5) |
Dec
(11) |
2011 |
Jan
(38) |
Feb
(22) |
Mar
(22) |
Apr
(14) |
May
(6) |
Jun
(6) |
Jul
(5) |
Aug
(10) |
Sep
(40) |
Oct
(23) |
Nov
(17) |
Dec
(26) |
2012 |
Jan
(34) |
Feb
(54) |
Mar
(13) |
Apr
(74) |
May
(45) |
Jun
(8) |
Jul
(23) |
Aug
(30) |
Sep
(46) |
Oct
(30) |
Nov
(35) |
Dec
(8) |
2013 |
Jan
(43) |
Feb
(38) |
Mar
(118) |
Apr
(131) |
May
(35) |
Jun
(7) |
Jul
(57) |
Aug
(36) |
Sep
(22) |
Oct
(5) |
Nov
(14) |
Dec
(17) |
2014 |
Jan
(38) |
Feb
(20) |
Mar
(31) |
Apr
(16) |
May
(20) |
Jun
(2) |
Jul
(9) |
Aug
(16) |
Sep
(6) |
Oct
(3) |
Nov
(8) |
Dec
(4) |
2015 |
Jan
|
Feb
(23) |
Mar
(6) |
Apr
(7) |
May
|
Jun
|
Jul
(1) |
Aug
(19) |
Sep
(8) |
Oct
|
Nov
|
Dec
(10) |
2016 |
Jan
(2) |
Feb
(2) |
Mar
(16) |
Apr
(10) |
May
|
Jun
(5) |
Jul
(7) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2017 |
Jan
(8) |
Feb
(16) |
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
2018 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(8) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2019 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Zdenek S. <zde...@gm...> - 2017-02-02 18:04:47
|
On Thu, Feb 2, 2017 at 3:57 PM, Josef Ridky <jr...@re...> wrote: > Hi folks, > > I am still newbie in ipmitool so, I would like to ask, if has been already somehow implemented this feature [1] in the latest (or previous) version (1.8.18) or not. > Hello, I don't think that specific patch has been picked up nor the feature was implemented. Is there a demand for such feature? Best regards, Z. -- Zdenek Styblik email: zde...@gm... jabber: zde...@gm... > Thanks a lot > > [1] https://sourceforge.net/p/ipmitool/mailman/ipmitool-devel/thread/20090602140420.8553.84958.stgit%40dhcp-lab-214.englab.brq.redhat.com/#msg22629118 > > Regards > > Josef Ridky > Associate Software Engineer > Core Services Team > Red Hat Czech, s.r.o. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Ipmitool-devel mailing list > Ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel |
From: Josef R. <jr...@re...> - 2017-02-02 14:57:18
|
Hi folks, I am still newbie in ipmitool so, I would like to ask, if has been already somehow implemented this feature [1] in the latest (or previous) version (1.8.18) or not. Thanks a lot [1] https://sourceforge.net/p/ipmitool/mailman/ipmitool-devel/thread/20090602140420.8553.84958.stgit%40dhcp-lab-214.englab.brq.redhat.com/#msg22629118 Regards Josef Ridky Associate Software Engineer Core Services Team Red Hat Czech, s.r.o. |
From: <hol...@ts...> - 2017-01-31 09:04:18
|
Typically a BMC lists only the cipher suites it supports with ipmitool lan print e.g. # ipmitool lan print | grep Cipher RMCP+ Cipher Suites : 0,1,2,3,6,7,8,17 Cipher Suite Priv Max : XaaaaaaaXXXXXXX : X=Cipher Suite Unused : c=CALLBACK : u=USER : o=OPERATOR : a=ADMIN : O=OEM Cipher suite 17 in the example above corresponds with the 8th character. From: VJ [mailto:pur...@gm...] Sent: Tuesday, January 31, 2017 4:10 AM To: ipm...@li... Subject: Re: [Ipmitool-devel] set cipher esp., Iam looking to enable Ciper Suite ID 17 : RAKP-HMAC-SHA256;HMAC-SHA256-128;AES-CBC-128 How can I set 17 when the man page says : privlist must be 15 characters in length I get error: lan set 1 cipher_privs XXXaXXXXXXXXXXXaa Invalid privilege specification length: 17 Thanks. On Mon, Jan 30, 2017 at 6:53 PM, VJ <pur...@gm...> wrote: How do I set cipher using ipmitool ? I see ipmitoool getcipher but I dont see set cipher Thanks. |
From: VJ <pur...@gm...> - 2017-01-31 03:10:49
|
esp., Iam looking to enable *Ciper Suite ID 17* : RAKP-HMAC-SHA256;HMAC-SHA256-128;AES-CBC-128 How can I set 17 when the man page says : privlist must be 15 characters in length I get error: lan set 1 cipher_privs XXXaXXXXXXXXXXXaa Invalid privilege specification length: 17 Thanks. On Mon, Jan 30, 2017 at 6:53 PM, VJ <pur...@gm...> wrote: > How do I set cipher using ipmitool ? > > I see ipmitoool getcipher but I dont see set cipher > > > Thanks. > |
From: VJ <pur...@gm...> - 2017-01-31 02:53:49
|
How do I set cipher using ipmitool ? I see ipmitoool getcipher but I dont see set cipher Thanks. |
From: VJ <pur...@gm...> - 2017-01-25 05:11:22
|
Hi, Iam able to disable channel 1 using : ipmitool raw 0x6 0x40 0x01 0x40 0x44 http://serverfault.com/questions/676145/how-to-disable-ipmi-over-lan-using-ipmitool/828445#828445 but channel 0x0 gives error. How do I disable some of the system interfaces ? Thanks. |
From: Zdenek S. <zde...@gm...> - 2017-01-15 13:40:08
|
On Mon, Jan 2, 2017 at 2:55 PM, Alan Evangelista <al...@li...> wrote: > Hi. > > I see that condrestart action in contrib/ipmievd.init.redhat calls a inexistent restart() function > (looking at cvs repo and git repo - master branch). > > It seems this bug was fixed in this patch:https://sourceforge.net/p/ipmitool/patches/34/ . Although > Jim Mankovich says the fix was merged to the cvs repository, for some reason I do not see it in the > cvs repository nor in the master branch in the git repository. > > Should I resend the patch? > > Regards, > Alan Evangelista > Hello Alan, it seems you're right. Maybe Jim forgot to push his changes. Feel free to open ticket at SF.net, if possible, and submit new patch. Please note, however, I believe that Red Hat, or distributions in general, has better init scripts and distribution-specific tooling in general. For example, Debian tooling has been removed from the IPMI tool upon agreement and left completely up to Debian as they simply know what's best for Debian. IPMI tool doesn't. :) Best regards, Z. -- Zdenek Styblik email: zde...@gm... jabber: zde...@gm... > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Ipmitool-devel mailing list > Ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel |
From: Zdenek S. <zde...@gm...> - 2017-01-15 13:30:27
|
On Mon, Jan 2, 2017 at 2:56 PM, Alan Evangelista <al...@li...> wrote: > Hi. > > Bug in Red Hat bug tracker:https://bugzilla.redhat.com/show_bug.cgi?id=742837 > Proposed patch:https://bugzilla.redhat.com/attachment.cgi?id=525972 > > I see this patch is not applied upstream. Is there a reason to not do it? Hello Alan, the reason for patch not being applied is that I believe issue has been addressed by another patch and in different way. I believe the topic has been brought up before and I've asked for a proof that issue persists. It's possible that upstream patch is a fix-failed under certain conditions, eg. Ubuntu sets completely different umask. Please, can you provide more information on is PID file still exploitable and under which conditions? Thank you. Best regards, Z. ``` commit 5ed7f6ac0a3c8ee433ea0a20be9554cbf98a4f51 Author: Zdenek Styblik <zde...@gm...> Date: Tue Jan 24 13:26:56 2012 +0000 Fixes CVE-2011-4339 - world writeable PID file Adds proper umask() before writing PID file. diff --git a/ipmitool/src/ipmievd.c b/ipmitool/src/ipmievd.c index 6fe1537..f5a2613 100644 --- a/ipmitool/src/ipmievd.c +++ b/ipmitool/src/ipmievd.c @@ -746,6 +746,7 @@ ipmievd_main(struct ipmi_event_intf * eintf, int argc, char ** argv) } } + umask(022); fp = ipmi_open_file_write(pidfile); if (fp != NULL) { fprintf(fp, "%d\n", (int)getpid()); ``` > > > Regards, > Alan Evangelista > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Ipmitool-devel mailing list > Ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel |
From: Alan E. <al...@li...> - 2017-01-02 13:56:34
|
Hi. Bug in Red Hat bug tracker:https://bugzilla.redhat.com/show_bug.cgi?id=742837 Proposed patch:https://bugzilla.redhat.com/attachment.cgi?id=525972 I see this patch is not applied upstream. Is there a reason to not do it? Regards, Alan Evangelista |
From: Alan E. <al...@li...> - 2017-01-02 13:55:43
|
Hi. I see that condrestart action in contrib/ipmievd.init.redhat calls a inexistent restart() function (looking at cvs repo and git repo - master branch). It seems this bug was fixed in this patch:https://sourceforge.net/p/ipmitool/patches/34/ . Although Jim Mankovich says the fix was merged to the cvs repository, for some reason I do not see it in the cvs repository nor in the master branch in the git repository. Should I resend the patch? Regards, Alan Evangelista |
From: Zdenek S. <zde...@gm...> - 2016-12-07 08:21:32
|
Hello, first of all, I did see e-mails and open issues and my apologies for not replying. So, what's up? I have two jobs now, because I have bills to pay. In other words - work, more work and a bit of life. In yet another words, I don't have time to maintain IPMI tool right now. That's how it has been for past two months and that's how it's going to be for next month or months to come. You could probably argue: "How come? Come on, all you have to do is just to merge stuff in. It's like 5 minute job for you". Unfortunately, it's not that easy as it doesn't make sense to merge everything right away and without review and at least one round of compilation. I don't claim that all changes were perfect, stuff breaks and will keep breaking down, but once something is merged in, it stays with the project and original author usually doesn't follow up on the issues or improving the code, because that's how it works. And let me praise those who do. What does it all mean? I think the best option would be for somebody else to step up as a maintainer. Another option are donations. And last, but not least, option is simply wait. Although, I understand one usually fixes problem, posts patch and moves on. In case you've made it here, thank you for your attention and have a nice day. Best regards, Z. -- Zdenek Styblik email: zde...@gm... jabber: zde...@gm... |
From: Zdenek S. <zde...@gm...> - 2016-08-27 08:56:30
|
Hello all, preliminary release date for IPMItool v1.8.18 is mid September 2016. Have a nice weekend. Best regards, Z. -- Zdenek Styblik email: zde...@gm... jabber: zde...@gm... |
From: Tom J. <tom...@gm...> - 2016-08-24 11:35:24
|
Hello All, I am trying to compile ipmitool version on AIX 7.2 and it fails. We are using gcc version 4.8.5. I have created the log as an attachment. If you have any directions to solve the problem. Please reach out. Regards, Tom Joseph |
From: Zdenek S. <zde...@gm...> - 2016-08-17 20:16:08
|
On Tue, Aug 16, 2016 at 11:11 AM, <B_B...@de...> wrote: > Dell - Internal Use - Confidential > > >>From: Albert Chu [mailto:ch...@ll...] >>Sent: Monday, August 8, 2016 10:27 PM >>To: Zdenek Styblik <zde...@gm...> >>Cc: Singh, B B <B_B_Singh@DELL.com>; ipmitool-devel <ipm...@li...> >>Subject: Re: [Ipmitool-devel] Can't Disable VLAN ID!!! > >>As a fellow IPMI project maintainer, I would side with the opinion the bug is on the BMC. The BMC should not care what the VLAN ID is when it is being disabled, only when it's being enabled. > >>That said, it would perhaps be nice to get a workaround into ipmitool to deal with this. Perhaps nothing more than a "--vlan-id" or something like that option to allow the user to override the default. > >>Al > > Hi Albert, > > The issue of validating the VLAN ID during a disable command has been corrected in the BMC firmware, but there is another incongruency related to this defect that may cause headaches for ipmitool users. > > Currently, when a LAN parameter set command is sent through ipmitool, the corresponding parameter data is requested and compared to the command to verify that the data was written correctly: > > > set_lan_param_wait > > > > if (memcmp(data, p->data, len) != 0) { > sleep(IPMI_LANP_TIMEOUT); > if (retry-- == 0) { > lprintf(LOG_WARNING, "LAN Parameter Data does not match! " > "Write may have failed."); > return -1; > } > continue; > } > > > Since we do send the VLAN ID in this return data, regardless of whether VLAN is disabled or not, this mismatch between requested and received parameters causes ipmitool to retry the command 10 times and return an error. > > In the interest of resolving this issue for all users of the tool, have made these below changes in ipmitool. Please review it & let me know the comments. > > --- ipmi_lanp.c 2016-08-09 15:29:56.000000000 +0530 > +++ ipmi_lanp_with_changes.c 2016-08-09 15:29:56.000000000 +0530 > @@ -1319,10 +1319,20 @@ > { > uint8_t data[2]; > int rc; > + struct lan_param * p; //handling for vlan disable, get the vlan id before sending > > if (string == NULL) { > - data[0] = 0; > - data[1] = 0; > + lprintf(LOG_NOTICE, "get vlan id ."); > + p = get_lan_param(intf, chan, IPMI_LANP_VLAN_ID); > + if (p != NULL && p->data != NULL) { > + int id = ((p->data[1] & 0x0f) << 8) + p->data[0]; > + if (id < 1 || id > 4094) { > + lprintf(LOG_NOTICE, "vlan id retrieved is not 1 and 4094."); > + return -1; > + } > + data[0] = p->data[0]; > + data[1] = p->data[1]; > + } > } > else { > int id = 0; > > Regards > Balaji Singh Hello Balaji, I'm glad to hear you've managed to BMC patched. As for the other finding, please, open ticket at sf.net and attach the patch. Thanks, Z. |
From: <B_B_Singh@DELL.com> - 2016-08-16 09:46:46
|
Dell - Internal Use - Confidential >From: Albert Chu [mailto:ch...@ll...] >Sent: Monday, August 8, 2016 10:27 PM >To: Zdenek Styblik <zde...@gm...> >Cc: Singh, B B <B_B_Singh@DELL.com>; ipmitool-devel <ipm...@li...> >Subject: Re: [Ipmitool-devel] Can't Disable VLAN ID!!! >As a fellow IPMI project maintainer, I would side with the opinion the bug is on the BMC. The BMC should not care what the VLAN ID is when it is being disabled, only when it's being enabled. >That said, it would perhaps be nice to get a workaround into ipmitool to deal with this. Perhaps nothing more than a "--vlan-id" or something like that option to allow the user to override the default. >Al Hi Albert, The issue of validating the VLAN ID during a disable command has been corrected in the BMC firmware, but there is another incongruency related to this defect that may cause headaches for ipmitool users. Currently, when a LAN parameter set command is sent through ipmitool, the corresponding parameter data is requested and compared to the command to verify that the data was written correctly: set_lan_param_wait if (memcmp(data, p->data, len) != 0) { sleep(IPMI_LANP_TIMEOUT); if (retry-- == 0) { lprintf(LOG_WARNING, "LAN Parameter Data does not match! " "Write may have failed."); return -1; } continue; } Since we do send the VLAN ID in this return data, regardless of whether VLAN is disabled or not, this mismatch between requested and received parameters causes ipmitool to retry the command 10 times and return an error. In the interest of resolving this issue for all users of the tool, have made these below changes in ipmitool. Please review it & let me know the comments. --- ipmi_lanp.c 2016-08-09 15:29:56.000000000 +0530 +++ ipmi_lanp_with_changes.c 2016-08-09 15:29:56.000000000 +0530 @@ -1319,10 +1319,20 @@ { uint8_t data[2]; int rc; + struct lan_param * p; //handling for vlan disable, get the vlan id before sending if (string == NULL) { - data[0] = 0; - data[1] = 0; + lprintf(LOG_NOTICE, "get vlan id ."); + p = get_lan_param(intf, chan, IPMI_LANP_VLAN_ID); + if (p != NULL && p->data != NULL) { + int id = ((p->data[1] & 0x0f) << 8) + p->data[0]; + if (id < 1 || id > 4094) { + lprintf(LOG_NOTICE, "vlan id retrieved is not 1 and 4094."); + return -1; + } + data[0] = p->data[0]; + data[1] = p->data[1]; + } } else { int id = 0; Regards Balaji Singh |
From: <B_B_Singh@DELL.com> - 2016-08-16 09:16:50
|
My apologies for the previous mail having tag "confidential". please neglect the tag. >>From: Albert Chu [mailto:ch...@ll...] >>Sent: Monday, August 8, 2016 10:27 PM >>To: Zdenek Styblik <zde...@gm...> >>Cc: Singh, B B <B_B_Singh@DELL.com>; ipmitool-devel <ipm...@li...> >>Subject: Re: [Ipmitool-devel] Can't Disable VLAN ID!!! >>As a fellow IPMI project maintainer, I would side with the opinion the bug is on the BMC. The BMC should not care what the VLAN ID is when it is being disabled, only when it's being enabled. >>That said, it would perhaps be nice to get a workaround into ipmitool to deal with this. Perhaps nothing more than a "--vlan-id" or something like that option to allow the user to override the default. >>Al >Hi Albert, >The issue of validating the VLAN ID during a disable command has been corrected in the BMC firmware, but there is another incongruency related to this defect that may cause headaches for ipmitool users. >Currently, when a LAN parameter set command is sent through ipmitool, the corresponding parameter data is requested and compared to the command to verify that the data was written correctly: >set_lan_param_wait > if (memcmp(data, p->data, len) != 0) { > sleep(IPMI_LANP_TIMEOUT); > if (retry-- == 0) { > lprintf(LOG_WARNING, "LAN Parameter Data does not match! " > "Write may have failed."); > return -1; > } > continue; > } >Since we do send the VLAN ID in this return data, regardless of whether VLAN is disabled or not, this mismatch between requested and received parameters causes ipmitool to retry the command 10 times and >return an error. >In the interest of resolving this issue for all users of the tool, have made these below changes in ipmitool. Please review it & let me know the comments. >--- ipmi_lanp.c 2016-08-09 15:29:56.000000000 +0530 >+++ ipmi_lanp_with_changes.c 2016-08-09 15:29:56.000000000 +0530 >@@ -1319,10 +1319,20 @@ >{ > uint8_t data[2]; > int rc; >+ struct lan_param * p; //handling for vlan disable, get the vlan id before sending > > if (string == NULL) { >- data[0] = 0; >- data[1] = 0; >+ lprintf(LOG_NOTICE, "get vlan id ."); >+ p = get_lan_param(intf, chan, IPMI_LANP_VLAN_ID); >+ if (p != NULL && p->data != NULL) { >+ int id = ((p->data[1] & 0x0f) << 8) + p->data[0]; >+ if (id < 1 || id > 4094) { >+ lprintf(LOG_NOTICE, "vlan id retrieved is not 1 and 4094."); >+ return -1; >+ } >+ data[0] = p->data[0]; >+ data[1] = p->data[1]; >+ } > } > else { > int id = 0; >Regards >Balaji Singh |
From: Albert C. <ch...@ll...> - 2016-08-08 16:57:37
|
As a fellow IPMI project maintainer, I would side with the opinion the bug is on the BMC. The BMC should not care what the VLAN ID is when it is being disabled, only when it's being enabled. That said, it would perhaps be nice to get a workaround into ipmitool to deal with this. Perhaps nothing more than a "--vlan-id" or something like that option to allow the user to override the default. Al On Sun, 2016-08-07 at 12:23 +0200, Zdenek Styblik wrote: > On Sun, Aug 7, 2016 at 6:04 AM, <B_B...@de...> wrote: > > Hi, > > > > Then is it a bug in ipmitool? That it sends 0x000 when VLAN ID is disabled. > > “ipmitool lan set 1 vlan id off” > > > > As per the wiki the ipmitool supposed to send values from 0x001 to 0xFFE > > during VLAN ID disable. > > > > Hello Balaji, > > it's disputable where the bug is. Me, personally, I would say bug is > in your BMC, because there is a little to no reason to send any VLAN > ID when VLAN ID Setting is being disabled. Is there any reason why > client should send any VLAN ID? If my understanding is correct, there > can be only one VLAN ID per channel and it can be either on and then > you need VLAN ID, or off and then VLAN ID doesn't matter. > You're correct, though, that IPMI specification doesn't explicitly say > this. On the other hand, it sort of makes sense. > > Best regards, > Z. > > > > Regards > > > > Balaji Singh > > > > > > > > > > > > From: ^..^ [mailto:ze...@gm...] > > Sent: Saturday, August 6, 2016 11:45 PM > > To: Singh, B B <B_B_Singh@DELL.com> > > Cc: ipm...@li... > > Subject: Re: [Ipmitool-devel] Can't Disable VLAN ID!!! > > > > > > > > I’d imagine it varies by vender (both BMC & network gear), but wiki has a > > good summation - > > > > VLAN identifier (VID): a 12-bit field specifying the VLAN to which the frame > > belongs. The hexadecimal values of 0x000 and 0xFFF are reserved. All other > > values may be used as VLAN identifiers, allowing up to 4,094 VLANs. The > > reserved value 0x000 indicates that the frame does not carry a VLAN ID; in > > this case, the 802.1Q tag specifies only a priority and is referred to as a > > priority tag. On bridges, VID 0x001 (the default VLAN ID) is often reserved > > for a management VLAN; this is vendor-specific. The VID value 0xFFF is > > reserved for implementation use; it must not be configured or transmitted. > > 0xFFF can be used to indicate a wildcard match in management operations or > > filtering database entries. > > > > Basically you should avoid 0,1, and 4095 unless you know your vendor/hw > > supports it for a specific reason. > > > > > > > > — d > > > > > > > > On Sat, Aug 6, 2016 at 6:07 AM, <B_B...@de...> wrote: > > > > > > > > Dear IPMI Experts, > > > > > > > > Need your help in understanding what should be value of VLAN ID value during > > VLAN disable. > > > > > > > > The spec doesn’t clearly call out what should be value of VLAN ID when VLAN > > ID enable bit is zero. > > > > > > > > As per spec… > > > > data 1 > > [7:0] - Least significant 8-bits of the VLAN ID. 00h if VLAN ID not used. > > data 2 > > [7] - VLAN ID enable. > > 0b = disabled, 1b = enabled. If enabled, the BMC will only accept packets > > for this > > channel if they have 802.1q fields and their VLAN ID matches the VLAN ID > > value > > given in this parameter. > > [6:4] - reserved > > [3:0] - most significant four bits of the VLAN ID > > > > > > > > > > > > I’m trying to disable the vlan id using the command “ipmitool lan set 1 vlan > > id off” > > > > I get the below error. > > > > LAN Parameter Data does not match! Write may have failed. > > > > > > > > When I checked in code ipmi_lanp.c the ipmitool is sending the vlan id as “0 > > 0” which is NOT accepted by the BMC. > > > > > > > > ipmi_lan_set_vlan_id(struct ipmi_intf *intf, uint8_t chan, char *string) > > { > > uint8_t data[2]; > > int rc; > > > > if (string == NULL) > > > > { data[0] = 0; data[1] = 0; } > > > > > > > > But when I replace the VLAN ID value with 1-4094 along with VLAN ID enable > > bit = 0. I.e, > > > > > > > > Data[0] = xxxx xxxx > > > > Data[1] = 0xxx xxxx > > > > > > > > Then VLAN ID got disable successfully. > > > > > > > > So, my query is what is the expected value of the VLAN ID when VLAN ID > > enable bit is zero as per the spec? should be zero or 1 to 4094 range? > > > > > > > > Regards > > > > Balaji Singh > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Ipmitool-devel mailing list > > Ipm...@li... > > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Ipmitool-devel mailing list > > Ipm...@li... > > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Ipmitool-devel mailing list > Ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel -- Albert Chu ch...@ll... Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory |
From: <B_B_Singh@DELL.com> - 2016-08-08 05:54:58
|
>Hello Balaji, >it's disputable where the bug is. Me, personally, I would say bug is in your BMC, because there is a little to no reason to send any VLAN ID when VLAN ID Setting is being disabled. Is there any reason why client should >send any VLAN ID? If my understanding is correct, there can be only one VLAN ID per channel and it can be either on and then you need VLAN ID, or off and then VLAN ID doesn't matter. >You're correct, though, that IPMI specification doesn't explicitly say this. On the other hand, it sort of makes sense. >Best regards, >Z. Hi Zdenek, Thanks for the quick reply. Can you please confirm the expected behavior of the BMC. 1. BMC should accept "0x000" VLAN ID when VLAN ID enable bit is disabled (0)? 2. BMC should NOT accept "0x000" VLAN ID when VLAN ID enable bit is enabled(1)? Regards Balaji Singh |
From: Zdenek S. <zde...@gm...> - 2016-08-07 10:24:01
|
On Sun, Aug 7, 2016 at 6:04 AM, <B_B...@de...> wrote: > Hi, > > Then is it a bug in ipmitool? That it sends 0x000 when VLAN ID is disabled. > “ipmitool lan set 1 vlan id off” > > As per the wiki the ipmitool supposed to send values from 0x001 to 0xFFE > during VLAN ID disable. > Hello Balaji, it's disputable where the bug is. Me, personally, I would say bug is in your BMC, because there is a little to no reason to send any VLAN ID when VLAN ID Setting is being disabled. Is there any reason why client should send any VLAN ID? If my understanding is correct, there can be only one VLAN ID per channel and it can be either on and then you need VLAN ID, or off and then VLAN ID doesn't matter. You're correct, though, that IPMI specification doesn't explicitly say this. On the other hand, it sort of makes sense. Best regards, Z. > Regards > > Balaji Singh > > > > > > From: ^..^ [mailto:ze...@gm...] > Sent: Saturday, August 6, 2016 11:45 PM > To: Singh, B B <B_B_Singh@DELL.com> > Cc: ipm...@li... > Subject: Re: [Ipmitool-devel] Can't Disable VLAN ID!!! > > > > I’d imagine it varies by vender (both BMC & network gear), but wiki has a > good summation - > > VLAN identifier (VID): a 12-bit field specifying the VLAN to which the frame > belongs. The hexadecimal values of 0x000 and 0xFFF are reserved. All other > values may be used as VLAN identifiers, allowing up to 4,094 VLANs. The > reserved value 0x000 indicates that the frame does not carry a VLAN ID; in > this case, the 802.1Q tag specifies only a priority and is referred to as a > priority tag. On bridges, VID 0x001 (the default VLAN ID) is often reserved > for a management VLAN; this is vendor-specific. The VID value 0xFFF is > reserved for implementation use; it must not be configured or transmitted. > 0xFFF can be used to indicate a wildcard match in management operations or > filtering database entries. > > Basically you should avoid 0,1, and 4095 unless you know your vendor/hw > supports it for a specific reason. > > > > — d > > > > On Sat, Aug 6, 2016 at 6:07 AM, <B_B...@de...> wrote: > > > > Dear IPMI Experts, > > > > Need your help in understanding what should be value of VLAN ID value during > VLAN disable. > > > > The spec doesn’t clearly call out what should be value of VLAN ID when VLAN > ID enable bit is zero. > > > > As per spec… > > data 1 > [7:0] - Least significant 8-bits of the VLAN ID. 00h if VLAN ID not used. > data 2 > [7] - VLAN ID enable. > 0b = disabled, 1b = enabled. If enabled, the BMC will only accept packets > for this > channel if they have 802.1q fields and their VLAN ID matches the VLAN ID > value > given in this parameter. > [6:4] - reserved > [3:0] - most significant four bits of the VLAN ID > > > > > > I’m trying to disable the vlan id using the command “ipmitool lan set 1 vlan > id off” > > I get the below error. > > LAN Parameter Data does not match! Write may have failed. > > > > When I checked in code ipmi_lanp.c the ipmitool is sending the vlan id as “0 > 0” which is NOT accepted by the BMC. > > > > ipmi_lan_set_vlan_id(struct ipmi_intf *intf, uint8_t chan, char *string) > { > uint8_t data[2]; > int rc; > > if (string == NULL) > > { data[0] = 0; data[1] = 0; } > > > > But when I replace the VLAN ID value with 1-4094 along with VLAN ID enable > bit = 0. I.e, > > > > Data[0] = xxxx xxxx > > Data[1] = 0xxx xxxx > > > > Then VLAN ID got disable successfully. > > > > So, my query is what is the expected value of the VLAN ID when VLAN ID > enable bit is zero as per the spec? should be zero or 1 to 4094 range? > > > > Regards > > Balaji Singh > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Ipmitool-devel mailing list > Ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Ipmitool-devel mailing list > Ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > |
From: <B_B_Singh@DELL.com> - 2016-08-07 04:04:17
|
Hi, Then is it a bug in ipmitool? That it sends 0x000 when VLAN ID is disabled. “ipmitool lan set 1 vlan id off” As per the wiki the ipmitool supposed to send values from 0x001 to 0xFFE during VLAN ID disable. Regards Balaji Singh From: ^..^ [mailto:ze...@gm...] Sent: Saturday, August 6, 2016 11:45 PM To: Singh, B B <B_B_Singh@DELL.com> Cc: ipm...@li... Subject: Re: [Ipmitool-devel] Can't Disable VLAN ID!!! I’d imagine it varies by vender (both BMC & network gear), but wiki has a good summation - VLAN identifier (VID): a 12-bit field specifying the VLAN to which the frame belongs. The hexadecimal values of 0x000 and 0xFFF are reserved. All other values may be used as VLAN identifiers, allowing up to 4,094 VLANs. The reserved value 0x000 indicates that the frame does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a priority and is referred to as a priority tag. On bridges, VID 0x001 (the default VLAN ID) is often reserved for a management VLAN; this is vendor-specific. The VID value 0xFFF is reserved for implementation use; it must not be configured or transmitted. 0xFFF can be used to indicate a wildcard match in management operations or filtering database entries. Basically you should avoid 0,1, and 4095 unless you know your vendor/hw supports it for a specific reason. — d On Sat, Aug 6, 2016 at 6:07 AM, <B_B...@de...<mailto:B_B...@de...>> wrote: Dear IPMI Experts, Need your help in understanding what should be value of VLAN ID value during VLAN disable. The spec doesn’t clearly call out what should be value of VLAN ID when VLAN ID enable bit is zero. As per spec… data 1 [7:0] - Least significant 8-bits of the VLAN ID. 00h if VLAN ID not used. data 2 [7] - VLAN ID enable. 0b = disabled, 1b = enabled. If enabled, the BMC will only accept packets for this channel if they have 802.1q fields and their VLAN ID matches the VLAN ID value given in this parameter. [6:4] - reserved [3:0] - most significant four bits of the VLAN ID I’m trying to disable the vlan id using the command “ipmitool lan set 1 vlan id off” I get the below error. LAN Parameter Data does not match! Write may have failed. When I checked in code ipmi_lanp.c the ipmitool is sending the vlan id as “0 0” which is NOT accepted by the BMC. ipmi_lan_set_vlan_id(struct ipmi_intf *intf, uint8_t chan, char *string) { uint8_t data[2]; int rc; if (string == NULL) { data[0] = 0; data[1] = 0; } But when I replace the VLAN ID value with 1-4094 along with VLAN ID enable bit = 0. I.e, Data[0] = xxxx xxxx Data[1] = 0xxx xxxx Then VLAN ID got disable successfully. So, my query is what is the expected value of the VLAN ID when VLAN ID enable bit is zero as per the spec? should be zero or 1 to 4094 range? Regards Balaji Singh ------------------------------------------------------------------------------ _______________________________________________ Ipmitool-devel mailing list Ipm...@li...<mailto:Ipm...@li...> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel |
From: ^..^ <ze...@gm...> - 2016-08-06 18:14:49
|
I’d imagine it varies by vender (both BMC & network gear), but wiki has a good summation - *VLAN identifier (VID): a 12-bit field specifying the VLAN to which the frame belongs. The hexadecimal values of 0x000 and 0xFFF are reserved. All other values may be used as VLAN identifiers, allowing up to 4,094 VLANs. The reserved value 0x000 indicates that the frame does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a priority and is referred to as a priority tag. On bridges, VID 0x001 (the default VLAN ID) is often reserved for a management VLAN; this is vendor-specific. The VID value 0xFFF is reserved for implementation use; it must not be configured or transmitted. 0xFFF can be used to indicate a wildcard match in management operations or filtering database entries.* Basically you should avoid 0,1, and 4095 unless you know your vendor/hw supports it for a specific reason. — d On Sat, Aug 6, 2016 at 6:07 AM, <B_B...@de...> wrote: > > > Dear IPMI Experts, > > > > Need your help in understanding what should be value of VLAN ID value > during VLAN disable. > > > > The spec doesn’t clearly call out what should be value of VLAN ID when > VLAN ID enable bit is zero. > > > > As per spec… > > data 1 > [7:0] - Least significant 8-bits of the VLAN ID. 00h if VLAN ID not used. > data 2 > [7] - VLAN ID enable. > 0b = disabled, 1b = enabled. If enabled, the BMC will only accept packets > for this > channel if they have 802.1q fields and their VLAN ID matches the VLAN ID > value > given in this parameter. > [6:4] - reserved > [3:0] - most significant four bits of the VLAN ID > > > > > > I’m trying to disable the vlan id using the command “ipmitool lan set 1 > vlan id off” > > I get the below error. > > LAN Parameter Data does not match! Write may have failed. > > > > When I checked in code ipmi_lanp.c the ipmitool is sending the vlan id as > “0 0” which is NOT accepted by the BMC. > > > > ipmi_lan_set_vlan_id(struct ipmi_intf *intf, uint8_t chan, char *string) > { > uint8_t data[2]; > int rc; > > if (string == NULL) > > { data[0] = 0; data[1] = 0; } > > > > But when I replace the VLAN ID value with 1-4094 along with VLAN ID > enable bit = 0. I.e, > > > > Data[0] = xxxx xxxx > > Data[1] = 0xxx xxxx > > > > Then VLAN ID got disable successfully. > > > > So, my query is what is the expected value of the VLAN ID when VLAN ID > enable bit is zero as per the spec? should be zero or 1 to 4094 range? > > > > Regards > > Balaji Singh > > > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > Ipmitool-devel mailing list > Ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > > |
From: <B_B_Singh@DELL.com> - 2016-08-06 13:07:31
|
Dear IPMI Experts, Need your help in understanding what should be value of VLAN ID value during VLAN disable. The spec doesn't clearly call out what should be value of VLAN ID when VLAN ID enable bit is zero. As per spec... data 1 [7:0] - Least significant 8-bits of the VLAN ID. 00h if VLAN ID not used. data 2 [7] - VLAN ID enable. 0b = disabled, 1b = enabled. If enabled, the BMC will only accept packets for this channel if they have 802.1q fields and their VLAN ID matches the VLAN ID value given in this parameter. [6:4] - reserved [3:0] - most significant four bits of the VLAN ID I'm trying to disable the vlan id using the command "ipmitool lan set 1 vlan id off" I get the below error. LAN Parameter Data does not match! Write may have failed. When I checked in code ipmi_lanp.c the ipmitool is sending the vlan id as "0 0" which is NOT accepted by the BMC. ipmi_lan_set_vlan_id(struct ipmi_intf *intf, uint8_t chan, char *string) { uint8_t data[2]; int rc; if (string == NULL) { data[0] = 0; data[1] = 0; } But when I replace the VLAN ID value with 1-4094 along with VLAN ID enable bit = 0. I.e, Data[0] = xxxx xxxx Data[1] = 0xxx xxxx Then VLAN ID got disable successfully. So, my query is what is the expected value of the VLAN ID when VLAN ID enable bit is zero as per the spec? should be zero or 1 to 4094 range? Regards Balaji Singh |
From: Zdenek S. <zde...@gm...> - 2016-07-31 05:35:06
|
On Fri, Jul 22, 2016 at 5:25 AM, Mike Chung(鐘志偉) <Mik...@wn...> wrote: > Hi, > > > > Is it possible to make libipmitool as a shared library? --enable-shared > seems not work… > Hello Mike, unfortunately, I'm not sure if IPMI tool is supposed to be used as a shared library. Best regards, Z. > > > Best Regards, > > Mike > > ________________________________ > This email and any attachments are intended for the sole use of the named > recipient(s) and may contain confidential, proprietary, privileged or > copyrighted information. If you are not the intended recipient, please > delete immediately. Do not read, copy, or forward this email or any > attachments. > ________________________________ > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports.http://sdm.link/zohodev2dev > _______________________________________________ > Ipmitool-devel mailing list > Ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > |
From: Dan G. <dg...@ad...> - 2016-07-28 21:51:35
|
Hi All, Sorry, I munged that last patch.... Here is rev 2. This adds support for decoding new Link class fields from PICMG 3.1 R2.0 in 'ipmitool -v fru' output. Here is some example output: Link Grouping ID: 0x00 Link Type Extension: 0x03 - 1000Base-KX Link Type: 0x02 - PICMG 3.1 Ethernet Fabric Interface Base signaling Link Class Link Designator: Port Flag: 0x01 Interface: 0x01 - Fabric Interface Channel Number: 0x02 Link Grouping ID: 0x00 Link Type Extension: 0x00 - 1000Base-BX Link Type: 0x02 - PICMG 3.1 Ethernet Fabric Interface Base signaling Link Class Link Designator: Port Flag: 0x01 Interface: 0x01 - Fabric Interface Channel Number: 0x01 Link Grouping ID: 0x00 Link Type Extension: 0x00 - 1000Base-BX Link Type: 0x02 - PICMG 3.1 Ethernet Fabric Interface Base signaling Link Class Link Designator: Port Flag: 0x01 Interface: 0x01 - Fabric Interface Channel Number: 0x02 Link Grouping ID: 0x00 Link Type Extension: 0x01 - 40GBase-KR4 Link Type: 0x32 - PICMG 3.1 Ethernet Fabric Interface 10.3125Gbd signaling Link Class Link Designator: Port Flag: 0x0f Interface: 0x01 - Fabric Interface Channel Number: 0x01 Link Grouping ID: 0x00 Link Type Extension: 0x01 - 40GBase-KR4 Link Type: 0x32 - PICMG 3.1 Ethernet Fabric Interface 10.3125Gbd signaling Link Class Link Designator: Port Flag: 0x0f Interface: 0x01 - Fabric Interface Channel Number: 0x02 Link Grouping ID: 0x00 Link Type Extension: 0x00 - 10GBase-KR Link Type: 0x32 - PICMG 3.1 Ethernet Fabric Interface 10.3125Gbd signaling Link Class Link Designator: Port Flag: 0x01 Interface: 0x01 - Fabric Interface Channel Number: 0x01 Link Grouping ID: 0x00 Link Type Extension: 0x00 - 10GBase-KR Link Type: 0x32 - PICMG 3.1 Ethernet Fabric Interface 10.3125Gbd signaling Link Class Link Designator: Port Flag: 0x01 Interface: 0x01 - Fabric Interface Channel Number: 0x02 These patches are on top of the latest git commit a3bec1d3658c Please have a look and let me know if there are any questions or problems. thanks dan ====================== PICMG 3.1 R2.0 introduces new a new Link Class field in the FRU Link Descriptors which is the upper 4 bits of the Link Type field. This new Link Class field specifies SERDES lanes with 10.3125Gbd signalling rate. It also introduces the new Base-KX and Base-KX4 types which are the new IEEE replacements for the PICMG 3.0 Base-BX and Base-BX4 types. This patch decodes these new types and fields and will print out proper descriptions for each one based on PICMG 3.1 R2.0 diff --git a/include/ipmitool/ipmi_fru.h b/include/ipmitool/ipmi_fru.h index b371f44..65696ba 100644 --- a/include/ipmitool/ipmi_fru.h +++ b/include/ipmitool/ipmi_fru.h @@ -297,22 +297,24 @@ struct fru_picmgext_link_desc { unsigned int desig_channel:6; unsigned int desig_if:2; unsigned int desig_port:4; -#define FRU_PICMGEXT_LINK_TYPE_BASE 0x01 +#define FRU_PICMGEXT_LINK_TYPE_BASE 0x01 #define FRU_PICMGEXT_LINK_TYPE_FABRIC_ETHERNET 0x02 #define FRU_PICMGEXT_LINK_TYPE_FABRIC_INFINIBAND 0x03 -#define FRU_PICMGEXT_LINK_TYPE_FABRIC_STAR 0x04 -#define FRU_PICMGEXT_LINK_TYPE_PCIE 0x05 +#define FRU_PICMGEXT_LINK_TYPE_FABRIC_STAR 0x04 +#define FRU_PICMGEXT_LINK_TYPE_PCIE 0x05 +#define FRU_PICMGEXT_LINK_TYPE_FABRIC_ETHERNET_10GBD 0x32 unsigned int type:8; unsigned int ext:4; unsigned int grouping:8; #else unsigned int grouping:8; unsigned int ext:4; -#define FRU_PICMGEXT_LINK_TYPE_BASE 0x01 +#define FRU_PICMGEXT_LINK_TYPE_BASE 0x01 #define FRU_PICMGEXT_LINK_TYPE_FABRIC_ETHERNET 0x02 #define FRU_PICMGEXT_LINK_TYPE_FABRIC_INFINIBAND 0x03 -#define FRU_PICMGEXT_LINK_TYPE_FABRIC_STAR 0x04 -#define FRU_PICMGEXT_LINK_TYPE_PCIE 0x05 +#define FRU_PICMGEXT_LINK_TYPE_FABRIC_STAR 0x04 +#define FRU_PICMGEXT_LINK_TYPE_PCIE 0x05 +#define FRU_PICMGEXT_LINK_TYPE_FABRIC_ETHERNET_10GBD 0x32 unsigned int type:8; unsigned int desig_port:4; unsigned int desig_if:2; diff --git a/lib/ipmi_fru.c b/lib/ipmi_fru.c index e5396d8..110c5d8 100644 --- a/lib/ipmi_fru.c +++ b/lib/ipmi_fru.c @@ -2297,68 +2297,91 @@ static void ipmi_fru_picmg_ext_print(uint8_t * fru_data, int off, int length) printf("ShMC Cross-connect (two-pair)\n"); break; default: - printf("Unknwon\n"); + printf("Unknown\n"); break; } } else if (d->type == FRU_PICMGEXT_LINK_TYPE_FABRIC_ETHERNET) { switch (d->ext) { case 0: - printf("Fixed 1000Base-BX\n"); + printf("1000Base-BX\n"); break; case 1: - printf("Fixed 10GBASE-BX4 [XAUI]\n"); + printf("10GBase-BX4 [XAUI]\n"); break; case 2: printf("FC-PI\n"); break; + case 3: + printf("1000Base-KX\n"); + break; + case 4: + printf("10GBase-KX4\n"); + break; + default: + printf("Unknown\n"); + break; + } + } else if (d->type == FRU_PICMGEXT_LINK_TYPE_FABRIC_ETHERNET_10GBD) { + switch (d->ext) + { + case 0: + printf("10GBase-KR\n"); + break; + case 1: + printf("40GBase-KR4\n"); + break; default: - printf("Unknwon\n"); + printf("Unknown\n"); break; } } else if (d->type == FRU_PICMGEXT_LINK_TYPE_FABRIC_INFINIBAND) { - printf("Unknwon\n"); + printf("Unknown\n"); } else if (d->type == FRU_PICMGEXT_LINK_TYPE_FABRIC_STAR) { - printf("Unknwon\n"); + printf("Unknown\n"); } else if (d->type == FRU_PICMGEXT_LINK_TYPE_PCIE) { - printf("Unknwon\n"); + printf("Unknown\n"); } else { - printf("Unknwon\n"); + printf("Unknown\n"); } printf(" Link Type: 0x%02x - ", d->type); - if (d->type == 0 || d->type == 0xff) { - printf("Reserved\n"); - } - else if (d->type >= 0x06 && d->type <= 0xef) { - printf("Reserved\n"); - } - else if (d->type >= 0xf0 && d->type <= 0xfe) { - printf("OEM GUID Definition\n"); - } - else { - switch (d->type) - { - case FRU_PICMGEXT_LINK_TYPE_BASE: - printf("PICMG 3.0 Base Interface 10/100/1000\n"); - break; - case FRU_PICMGEXT_LINK_TYPE_FABRIC_ETHERNET: - printf("PICMG 3.1 Ethernet Fabric Interface\n"); - break; - case FRU_PICMGEXT_LINK_TYPE_FABRIC_INFINIBAND: - printf("PICMG 3.2 Infiniband Fabric Interface\n"); - break; - case FRU_PICMGEXT_LINK_TYPE_FABRIC_STAR: - printf("PICMG 3.3 Star Fabric Interface\n"); - break; - case FRU_PICMGEXT_LINK_TYPE_PCIE: - printf("PICMG 3.4 PCI Express Fabric Interface\n"); - break; - default: + switch (d->type) { + case FRU_PICMGEXT_LINK_TYPE_BASE: + printf("PICMG 3.0 Base Interface 10/100/1000\n"); + break; + case FRU_PICMGEXT_LINK_TYPE_FABRIC_ETHERNET: + printf("PICMG 3.1 Ethernet Fabric Interface\n"); + printf(" Base signaling Link Class\n"); + break; + case FRU_PICMGEXT_LINK_TYPE_FABRIC_INFINIBAND: + printf("PICMG 3.2 Infiniband Fabric Interface\n"); + break; + case FRU_PICMGEXT_LINK_TYPE_FABRIC_STAR: + printf("PICMG 3.3 Star Fabric Interface\n"); + break; + case FRU_PICMGEXT_LINK_TYPE_PCIE: + printf("PICMG 3.4 PCI Express Fabric Interface\n"); + break; + case FRU_PICMGEXT_LINK_TYPE_FABRIC_ETHERNET_10GBD: + printf("PICMG 3.1 Ethernet Fabric Interface\n"); + printf(" 10.3125Gbd signaling Link Class\n"); + break; + default: + if (d->type == 0 || d->type == 0xff) { + printf("Reserved\n"); + } + else if (d->type >= 0x06 && d->type <= 0xef) { + printf("Reserved\n"); + } + else if (d->type >= 0xf0 && d->type <= 0xfe) { + printf("OEM GUID Definition\n"); + } + else { printf("Invalid\n"); - break; - } + } + break; } printf(" Link Designator: \n"); |
From: Dan G. <dg...@ad...> - 2016-07-28 21:20:43
|
Here is the patch as an attachment in case it gets mangled in gmail.. thanks dan |