Wireshark-users: Re: [Wireshark-users] Decoding RFC1950 compressed data?
From: Andreas Weller <weller@xxxxxxxxxxxxxxxxx>
Date: Tue, 22 May 2007 00:28:37 +0200
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Stephen Fisher wrote: >> How do I force wireshark treating the port 1536 data as RFC1950 >> compressed - may be it can be decoded this way... > > There is no zlib dissector right now, but Wireshark is usually compiled > with zlib and it is used within the HTTP and VNC dissectors. Would you > mind sending the first response packet (the one that appears to have the > compressed data and without the password you x out) to the list (or me > privately if you prefer)? I would like to take a closer look at it. If > it is just zlib compressed data, a dissector could be written to > uncompress it and display the uncompressed data for you. Hi! I hope this may help. I think the zlib compressed data starts at HEX 00a5: may be decoded as "Linux 2.4.29.3.5.19(57/57 8,2,1)release"... Regards, Andreas Weller No. Time Source Destination Protocol Info 13 0.018497 192.168.88.205 192.168.88.1 TCP [TCP Out-Of-Order] 32804 > 1536 [PSH, ACK] Seq=22 Ack=25 Win=5840 Len=162 TSV=105326 TSER=4546448 Frame 13 (228 bytes on wire, 228 bytes captured) Arrival Time: May 18, 2007 20:35:45.836837000 [Time delta from previous packet: 0.000010000 seconds] [Time since reference or first frame: 0.018497000 seconds] Frame Number: 13 Packet Length: 228 bytes Capture Length: 228 bytes [Frame is marked: False] [Protocols in frame: eth:ip:tcp:tds] [Coloring Rule Name: TCP] [Coloring Rule String: tcp] Ethernet II, Src: Vmware_6b:d8:bb (00:0c:29:6b:d8:bb), Dst: FujitsuS_83:20:4f (00:30:05:83:20:4f) Destination: FujitsuS_83:20:4f (00:30:05:83:20:4f) Address: FujitsuS_83:20:4f (00:30:05:83:20:4f) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Vmware_6b:d8:bb (00:0c:29:6b:d8:bb) Address: Vmware_6b:d8:bb (00:0c:29:6b:d8:bb) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.88.205 (192.168.88.205), Dst: 192.168.88.1 (192.168.88.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 214 Identification: 0xc692 (50834) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (0x06) Header checksum: 0x4170 [correct] [Good: True] [Bad : False] Source: 192.168.88.205 (192.168.88.205) Destination: 192.168.88.1 (192.168.88.1) Transmission Control Protocol, Src Port: 32804 (32804), Dst Port: 1536 (1536), Seq: 22, Ack: 25, Len: 162 Source port: 32804 (32804) Destination port: 1536 (1536) Sequence number: 22 (relative sequence number) [Next sequence number: 184 (relative sequence number)] Acknowledgement number: 25 (relative ack number) Header length: 32 bytes Flags: 0x18 (PSH, ACK) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...1 .... = Acknowledgment: Set .... 1... = Push: Set .... .0.. = Reset: Not set .... ..0. = Syn: Not set .... ...0 = Fin: Not set Window size: 5840 Checksum: 0x0577 [correct] Options: (12 bytes) NOP NOP Timestamps: TSval 105326, TSecr 4546448 [SEQ/ACK analysis] [TCP Analysis Flags] [This frame is a (suspected) out-of-order segment] Tabular Data Stream Type: Unknown (0x00) Status: Unknown (156) Size: 0 (bogus, should be >= 8) 0000 00 30 05 83 20 4f 00 0c 29 6b d8 bb 08 00 45 00 .0.. O..)k....E. 0010 00 d6 c6 92 40 00 40 06 41 70 c0 a8 58 cd c0 a8 ....@.@.Ap..X... 0020 58 01 80 24 06 00 e0 fc 5e 00 e5 a8 df 95 80 18 X..$....^....... 0030 16 d0 05 77 00 00 01 01 08 0a 00 01 9b 6e 00 45 ...w.........n.E 0040 5f 90 00 9c 00 00 00 78 9c 63 60 80 00 8d 06 3d _......x.c`....= 0050 0e 9e 00 57 c7 ff 40 00 15 62 00 f1 1f 01 b1 5a ...W..@..b.....Z 0060 3d 03 83 0b 90 66 40 02 d7 40 f2 0c 98 40 b6 81 =....f@..@...@.. 0070 81 c1 96 15 22 67 0f c4 02 40 6c 03 c4 1c 68 ea ...."g...@l...h. 0080 7c 32 f3 4a 2b 14 8c f4 4c f4 8c 2c 19 8c f5 4c |2.J+...L..,...L 0090 f5 0c 2d 15 34 4c cd f5 4d cd 15 2c 74 8c 74 0c ..-.4L..M..,t.t. 00a0 35 15 8a 52 73 52 13 8b 53 15 8c 23 42 cc 14 92 5..RsR..S..#B... 00b0 4a 33 73 4a 14 f2 f3 14 12 8b 32 ab f2 f3 12 15 J3sJ......2..... 00c0 1c 4b d3 15 8c 8c 15 8c 0c 0c cc b8 18 4c 0d 2d .K...........L.- 00d0 f5 8c f5 8c f4 2c 4c 75 0c cc 0c f3 2a 18 00 44 .....,Lu....*..D 00e0 9b 24 6b 02 .$k. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUh0UZAUSLfjKnkYRA+2gAJwKVHUZMo3Yhra0QVA7ZXyyLCCBhwCfU/+7 j+90kyBdD3evZWX5P4fzpyc= =mSA0 -----END PGP SIGNATURE-----
Attachment:
frame 13.wireshark
Description: Binary data
- References:
- [Wireshark-users] Decoding RFC1950 compressed data?
- From: Andreas Weller
- Re: [Wireshark-users] Decoding RFC1950 compressed data?
- From: Stephen Fisher
- [Wireshark-users] Decoding RFC1950 compressed data?
- Prev by Date: Re: [Wireshark-users] Help with Output "TCP Dup ACK3#2 1320 > 22 ACK
- Next by Date: Re: [Wireshark-users] Help with Output "TCP Dup ACK3#2 1320 > 22 ACK
- Previous by thread: Re: [Wireshark-users] Decoding RFC1950 compressed data?
- Next by thread: [Wireshark-users] Problems INSTALLING 0.99.6
- Index(es):