Wireshark-dev: Re: [Wireshark-dev] [PATCH] Fix 80211be u-sig decode.

From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Fri, 19 Jul 2024 16:10:19 +0200
> On 18 Jul 2024, at 02:10, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
> 
> On 7/17/24 17:07, greearb@xxxxxxxxxxxxxxx wrote:
>> From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
>> It is 32-bit instead of 16-bit.  This fixes invalid parsing of the
>> bandwidth, probably among other things.
>> Signed-off-by: Ben Greear <greearb@xxxxxxxxxxxxxxx>
>> ---
>>  epan/dissectors/packet-ieee80211-radiotap.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/epan/dissectors/packet-ieee80211-radiotap.c b/epan/dissectors/packet-ieee80211-radiotap.c
>> index 34bd377a3f..28af26b745 100644
>> --- a/epan/dissectors/packet-ieee80211-radiotap.c
>> +++ b/epan/dissectors/packet-ieee80211-radiotap.c
>> @@ -2053,7 +2053,7 @@ dissect_radiotap_u_sig(tvbuff_t *tvb, packet_info *pinfo _U_, proto_tree *tree,
>>  	uint32_t mask;
>>  	bool bw_known = false;
>>  	struct ieee_802_11be *info_11be = &phdr->phy_info.info_11be;
>> -	uint32_t usig_common = tvb_get_letohs(tvb, offset);
>> +	uint32_t usig_common = tvb_get_letohl(tvb, offset);
>>    	phdr->phy = PHDR_802_11_PHY_11BE;
>>  
> 
> 
> And for completeness, maybe some other dissectors have same issue,
> but I don't really know:
> 
> [greearb@ben-dt5 wireshark-ct]$ git grep tvb_get_letohs|grep int32
> epan/dissectors/packet-assa_r3.c:    uint32_t    packetCRC     = tvb_get_letohs (tvb, offset);
> epan/dissectors/packet-eobi.c:    uint32_t bodylen= tvb_get_letohs(tvb, 0);
> epan/dissectors/packet-ieee802154.c:            uint32_t phr_data = tvb_get_letohs(tvb, offset+4);
> epan/dissectors/packet-ieee802154.c:            uint32_t phr_data = tvb_get_letohs(tvb, offset+4);
> epan/dissectors/packet-rftap.c:    len = 4 * (gint32) tvb_get_letohs(tvb, 4);  /* convert to length in bytes */
> epan/dissectors/packet-rftap.c:    rftap_len = 4 * (gint32) tvb_get_letohs(tvb, 4);
> 
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb@xxxxxxxxxxxxxxx>
> Candela Technologies Inc  http://www.candelatech.com
> 

Hi,

It could be that this is intentional, making use of implicit cast (in most cases). The lines in packet-rftap.c look like that. The others need to be evaluated against their protocol spec. And is so, have their type cast made explicit, to confirm this conversion.

Thanks,
Jaap