[Patchs]

Matthieu Patou mat+Informatique.Samba at matws.net
Sat Jan 23 01:55:41 MST 2010


Hi metze,

> Hi Matthieu,
>
> > From e3ba25c6737410df4f71060d63d4ad51613d3ea5 Mon Sep 17 00:00:00 2001
>    
>> From: Matthieu Patou<mat at matws.net>
>> Date: Sat, 23 Jan 2010 01:43:24 +0300
>> Subject: [PATCH] don't return a buffer if we were not able to decrypt
>> it \!
>>
>> ---
>> epan/dissectors/packet-dcerpc-netlogon.c |    1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/epan/dissectors/packet-dcerpc-netlogon.c
>> b/epan/dissectors/packet-dcerpc-netlogon.c
>> index d01ceed..346b189 100644
>> --- a/epan/dissectors/packet-dcerpc-netlogon.c
>> +++ b/epan/dissectors/packet-dcerpc-netlogon.c
>> @@ -7912,7 +7912,6 @@ dissect_packet_data(tvbuff_t *tvb ,tvbuff_t
>> *auth_tvb _U_,
>>    }
>>    else {
>>      debugprintf("Vars not found  %d
>> (packet_data)\n",g_hash_table_size(netlogon_auths));
>> -    return(buf);
>>    }
>>
>>    return(buf);
>>      
> You haven't tested this patch:-)
> This change is a noop. If we do the same return statement 2 lines later.
> Yeah you are right,
>    

In the same time with   changeset 31598 (that is without my latest 
patches) I do not have on your capture any pb (it didn't try to pretend 
that is decrypted when it's not (see screenshot).

>Would return NULL be the correct thing?

In fact the first line is buf=NULL and only if we find the key we allocate a buffer.


At the end yes this patch is useless but I'm pretty sure that my dissector didn't try to parse what it hasn't been able to decode.

Matthieu.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.png
Type: image/png
Size: 263295 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100123/e5bb53a7/attachment-0001.png>


More information about the samba-technical mailing list