Hi, After re-looking at RFC2478 and looking at traces again and talking to Diego (:-) at IBM, it looks like the following is occurring:
1. The negProt response includes a negTokenInit with a list of OIDs for mechanisms that the server handles. 2. The client sends a sesssetup&X with another negTokenInit with the selected mechanism and a token. 3. The server send back a sesssetup&X response with a negTokenTarg with appropriate things in it, however, unlike the previous negTokenInits, this blob is not cloaked in GSSAPI, it is raw SPNEGO! 4. There will be more negTokenTargs if the previous packet had more processing required set. Now, to dissect this properly in Ethereal, what I think needs to happen is: 1. dissect_smb_sess... should call the gss-api dissector to see if that works. If not, it should call SPNEGO dirrectly on the blob. 2. the gssapi dissector needs some way to indicate that it could not dissect the data it was passed. So, my question is: What will break if I change gss-api to return and indication of success or failure, or should I add an intermediate dissector? Regards ----- Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
