On Mon, 2005-12-05 at 02:52, Eitan Zahavi wrote: > > > > > > I agree that currently we do not have an authentication mechanism, > > > thus - we cannot decide that an SM is not trusted. > > > I think that in the current situation the option of always sending > our > > > true SM_Key when receiving SMInfo SubnGet request is a good one. > > > In this case - there is no need to update anything in the SMInfo > SubnGet > > > request. > > > Any objections? > > > > IMO this is a first step (assuming in subnet with only OpenSMs and > hence > > all are trusted). What needs to be done is: > > The SM needs a way to know whether the other SM(s) (and which ones) > are > > trusted or not so the SM_Key can be filled in. To accomplish this, > > OpenSM needs to have a list of trusted SMs (e.g. additional > > configuration). > [EZ] I guess what you mean is that a list of trusted SM's port guids > will provided to the SM? We can do that.
Yes, that's what I mean/meant. -- Hal > > > > Also, given that the current default SM Key is 0. there is no > difference > > here (so perhaps the default SM Key should be changed to a non 0 > value). > > There is some ambiguity in the spec currently around this (and a > comment > > has been filed with the MgtWG on this). > > > > -- Hal > > > > > Yael > > > > > > > > > -----Original Message----- > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, December 01, 2005 7:02 PM > > > To: Eitan Zahavi > > > Cc: Yael Kalka; [email protected] > > > Subject: RE: [Fwd: [openib-general] OpenSM and Wrong SM_Key] > > > > > > > > > Hi Eitan, > > > > > > On Thu, 2005-12-01 at 10:35, Eitan Zahavi wrote: > > > > Hi Yael, > > > > > > > > As I read through the MgtWg mails I get the impression that an out > of > > > > spec mechanism is required to know if the other SM is trusted. > > > > > > Yes, that was what I was proposing (in > > > http://openib.org/pipermail/openib-general/2005-December/014186.html > > > where I wrote "The SM needs a way to know whether the other SM(s) > (and > > > which ones) are trusted or not so the SM_Key can be filled in."): > that > > > OpenSM have a list of trusted SMs and OpenSM would use that > information. > > > > > > > In that case and since OpenSM does not currently provide any such > > > > mechanism, I would prefer never to send out the SM_Key on the > request > > > > and always send zero. Sending our SM_Key to a non - trusted SM is > not > > > a > > > > good idea in my mind. > > > > > > > > OpenSM behavior should be to always trust any other SM. > > > > > > Above you said no other SM was trusted so do you mean not trust > rather > > > than trust other SMs ? > > > > > > > So any discovered SM that deserves to be the master should be > granted > > > > that right. > > > > > > Only if it were trusted and had the correct SM Key. > > > > > > -- Hal > > > > > > > Eitan Zahavi > > > > Design Technology Director > > > > Mellanox Technologies LTD > > > > Tel:+972-4-9097208 > > > > Fax:+972-4-9593245 > > > > P.O. Box 586 Yokneam 20692 ISRAEL > > > > > > > > > > > > > -----Original Message----- > > > > > From: Yael Kalka > > > > > Sent: Thursday, December 01, 2005 2:17 PM > > > > > To: 'Hal Rosenstock'; Eitan Zahavi > > > > > Cc: [email protected] > > > > > Subject: RE: [Fwd: [openib-general] OpenSM and Wrong SM_Key] > > > > > > > > > > Hi Hal, Eitan, > > > > > I think the best option is to add an OpenSM option flag - > > > > exit_on_fatal. > > > > > This flag can decide on the action on fatal cases: > > > > > 1. Exit or not when seeing SM with different SM_Key. > > > > > 2. Exit or not when there is a fatal link error (e.g - multiple > > > > guids). > > > > > etc. > > > > > > > > > > I tried to run 2 SMs just now with different SM_keys, and I see > that > > > > none of them > > > > > exit, since both receive SM_Key=0 on SMInfo GetResp. > > > > > The reason for that is that in the SMInfo Get request (as in all > > > other > > > > requests) > > > > > we do not send anything in the mad data. Meaning - all fields > are > > > > clear. > > > > > In the __osm_sminfo_rcv_process_get_request function we are > checking > > > > the state > > > > > according > > > > > to the payload data. This is always zero! Thus - SM will never > know > > > > that the SMInfo > > > > > request is sent from an SM that is master. > > > > > > > > > > I will work on a fix for that. > > > > > Yael > > > > > > > > > > -----Original Message----- > > > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, November 30, 2005 11:57 PM > > > > > To: Yael Kalka; Eitan Zahavi > > > > > Cc: [email protected] > > > > > Subject: [Fwd: [openib-general] OpenSM and Wrong SM_Key] > > > > > > > > > > > > > > > Hi Yael & Eitan, > > > > > > > > > > Based on the recent MgtWG discussions, are you still holding > your > > > > > position in terms of exiting OpenSM when a non matching SM Key > is > > > > > discovered ? Just wondering if I can issue a patch for this and > > > clear > > > > > this issue so OpenSM can be compliant for this aspect. Thanks. > > > > > > > > > > -- Hal > > > > > > > > > > -----Forwarded Message----- > > > > > > > > > > From: Hal Rosenstock <[EMAIL PROTECTED]> > > > > > To: [email protected] > > > > > Subject: [openib-general] OpenSM and Wrong SM_Key > > > > > Date: 08 Nov 2005 16:08:47 -0500 > > > > > > > > > > Hi, > > > > > > > > > > Currently, when OpenSM receives SMInfo with a different SM_Key, > it > > > > exits > > > > > as follows: > > > > > > > > > > > > > > > void > > > > > __osm_sminfo_rcv_process_get_response( > > > > > IN const osm_sminfo_rcv_t* const p_rcv, > > > > > IN const osm_madw_t* const p_madw ) > > > > > { > > > > > ... > > > > > > > > > > > > > > > > > > > > /* > > > > > Check that the sm_key of the found SM is the same as ours, > > > > > or is zero. If not - OpenSM cannot continue with > > > configuration!. > > > > */ > > > > > if ( p_smi->sm_key != 0 && > > > > > p_smi->sm_key != p_rcv->p_subn->opt.sm_key ) > > > > > { > > > > > osm_log( p_rcv->p_log, OSM_LOG_ERROR, > > > > > "__osm_sminfo_rcv_process_get_response: ERR 2F18: " > > > > > "Got SM with sm_key that doesn't match our " > > > > > "local key. Exiting\n" ); > > > > > osm_log( p_rcv->p_log, OSM_LOG_SYS, > > > > > "Found remote SM with non-matching sm_key. > Exiting\n" > > > ); > > > > > osm_exit_flag = TRUE; > > > > > goto Exit; > > > > > } > > > > > > > > > > C14-61.2.1 states that: > > > > > A master SM which finds a higher priority master SM with the > wrong > > > > > SM_Key should not relinquish the subnet. > > > > > > > > > > Exiting OpenSM relinquishes the subnet. > > > > > > > > > > So it appears to me that perhaps this behavior of exiting OpenSM > > > > should > > > > > be at least contingent on the SM state and relative priority of > the > > > > > SMInfo received. Make sense ? If so, I will work on a patch for > > > this. > > > > > > > > > > -- Hal > > > > > > > > > > > > > > > _______________________________________________ > > > > > openib-general mailing list > > > > > [email protected] > > > > > http://openib.org/mailman/listinfo/openib-general > > > > > > > > > > To unsubscribe, please visit > > > > http://openib.org/mailman/listinfo/openib-general > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
