Ask Your Question
0

We are upgrading wireshark from 2.6.7 to 4.2.3.Need some info on keys and values in decoded data

asked 2024-04-25 10:54:20 +0000

Harsha gravatar image

Older Wireshark which we used: 2.6.7 Upgraded to version: 4.2.3 We noticed in the older wireshark there are empty character in few keys before or after the key. Does the new wireshark is also sending the data in same way or is it truncating the empty chars from the keys or not Eg.. Previously we had seen a key as " StelDis Data ". Does the new wireshark sends any key in similar fashion (empty characters before or after the key)

edit retag flag offensive close merge delete

Comments

What do you mean by "Key"?

grahamb gravatar imagegrahamb ( 2024-04-25 10:56:46 +0000 )edit

Sample Keys are added. This below set of keys is not having any extra spaces at begin or at end

"Diameter Protocol"
"Version"
"Length"
"Flags"
"Command Code"
"ApplicationId"
"Hop-by-Hop Identifier"
"End-to-End Identifier"
"AVP"
"AVP Code"
"AVP Flags"

But there are keys with extra space at the start

" Request"
" Proxyable"
" Error"
" T(Potentially re-transmitted message)"

Now In short my question is: Is there any chance that the below mentioned words come as a key along with an empty character at the beginning or at the end

" Data"
" StelDis Data"
" OPC"
" DPC"
Harsha gravatar imageHarsha ( 2024-04-25 14:36:20 +0000 )edit

I still don't understand the context and your terminology.

When you mention "key" do you mean a field name or value?

grahamb gravatar imagegrahamb ( 2024-04-25 15:02:56 +0000 )edit

Yes its field name

Harsha gravatar imageHarsha ( 2024-04-25 15:04:31 +0000 )edit

Are you grabbing the data from output of tshark?

(From capture attached to 2984: Diameter R bit in Command Flags not considered)

Diameter Protocol
    Version: 0x01
    Length: 536
    Flags: 0xc0, Request, Proxyable
        1... .... = Request: Set
        .1.. .... = Proxyable: Set
        ..0. .... = Error: Not set
        ...0 .... = T(Potentially re-transmitted message): Not set
        .... 0... = Reserved: Not set
        .... .0.. = Reserved: Not set
        .... ..0. = Reserved: Not set
        .... ...0 = Reserved: Not set
Chuckc gravatar imageChuckc ( 2024-04-25 17:00:42 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2024-04-25 15:55:42 +0000

grahamb gravatar image

updated 2024-04-26 08:51:07 +0000

I don't think field names have leading or trailing spaces, at least they're not intended to have them.

Info that might help:

Using tshark -G fields outputs a list of all fields and protocols in the application in a tab separated format.

Items may have info about Protocols (initial char is "P") or Fields (initial char is "F").

Protocol items have 3 elements; a type indicator ("P"), a text name and a filter name.

Field items have 9 elements: a type indicator ("F"), a text name, a filter name, the field type, the protocol associated with the field, the base for the field value, the bit mask for active bits in the field value and a comment for the field.

And now how I tested:

Post-processing the output of tshark -G fields with PowerShell showed no Fields or Protocols have a name element that has leading or trailing spaces.

tshark -G fields | `
    ConvertFrom-Csv  -Delimiter "`t" -Header "FieldInd", "Name", "FilterName", "FieldType", "Protocol", "Base", "Bits", "Comment" | `
    Where-Object { $_.Name -match "^ +.* +$" }

and

tshark -G fields | `
    ConvertFrom-Csv  -Delimiter "`t" -Header "FieldInd", "Name", "FilterName" | `
    Where-Object { $_.Name -match "^ +.* +$" }
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2024-04-25 10:54:20 +0000

Seen: 99 times

Last updated: Apr 26