> > > > 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. > > 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
