Wireshark · Wireshark-dev: Re: [Wireshark-dev] Prevent recursive IP dissector to fill summary columns

[Andrej Mikus <wireshark-dev@xxxxxxxx>]

The change is unfortunately not working with HTTP, the dissector is
setting COL_INFO as not writable and further modification of the info
field fails. Will try to set fence before running sub dissector.

Andrej

On Sat, 27.Jan.07 02:54:45 +0100, Andrej Mikus wrote:
> Hi,
> 
> In the meantime I found Wireshark wishlist and I find my question
> related to first topic in dissection section at
> http://wiki.wireshark.org/WishList#head-415ef1ebe1134681b1db49769aa1d8bf027db057
> 
> Further check in header files reveals much more info compared to README
> files. Found that the functionality I was looking for it (partially)
> achieved by flag in_error_pkt. Also found information about modification
> of info column.
> 
> To conclude, the attached patch would be acceptable?
> 
> Thanks
> Andrej
> 
> On Mon, 22.Jan.07 10:37:20 +0100, Andrej Mikus wrote:
> > Team,
> > 
> > While troubleshooting wccp traffic it is very useful that Wireshark
> > goes deep into gre redirected packet and pulls the IP address from it.
> > It makes it easy to follow tcp stream also when server responses are not
> > GRE encapsulated.
> > 
> > There are however also situations when the IP information from top level
> > is interesting (what router redirected the packet to what wccp client)
> > and I would like to implement a preference setting to get this kind of
> > information.
> > 
> > Some questions:
> > - Where this preference should be most logical to place? (ip, gre, wccp)
> > - How to actually implement it? It requires that packet-ip.c when called
> >   for second time should not update columns (and fields for display
> > filter), but still continues to build tree for detailed display. Is
> > there any way to find out if the packet being dissected is raw IP
> > packet, or comes from GRE payload?
> > 
> > I would like to modify the Info column in all cases to indicate that the
> > packet is redirected, for example by prepending char '>' to the info,
> > regardless of dissector that produced it. Is this feasible? I notice
> > that dissectors call col_clear all the time. Is it possible to modify
> > the column after packet is completely dissected?
> > 
> > In next step I am thinking of using '<' to indicate packet returned back
> > to router, but at this point still need to work out some protocol
> > details.
> > 
> > Attached is an example of packet I am concerned about. I hope it would
> > help to assist. Output I would like to get after my changes is as
> > follows:
> > 
> > With new preference disabled (current operation):
> > No.     Time            Source                Destination           Protocol Info
> >       1 09:50:26.794117 10.254.127.195        10.254.108.228        DCERPC   > Request: call_id: 1 opnum: 16 ctx_id: 0
> > 
> > New preference enabled (show top level info in summary for wccp redirected frames)
> > No.     Time            Source                Destination           Protocol Info
> >       1 09:50:26.794117 10.254.127.194        10.254.214.82         GREWCCP  Redirected frame
> > 
> > Frame 1 (282 bytes on wire, 282 bytes captured)
> > Ethernet II, Src: Cisco_3a:ab:40 (00:0f:35:3a:ab:40), Dst: Ibm_28:99:a8 (00:14:5e:28:99:a8)
> > Internet Protocol, Src: 10.254.127.194 (10.254.127.194), Dst: 10.254.214.82 (10.254.214.82)
> >     Version: 4
> >     Header length: 20 bytes
> >     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> >     Total Length: 268
> >     Identification: 0xac83 (44163)
> >     Flags: 0x00
> >     Fragment offset: 0
> >     Time to live: 253
> >     Protocol: GRE (0x2f)
> >     Header checksum: 0xa42e [correct]
> >     Source: 10.254.127.194 (10.254.127.194)
> >     Destination: 10.254.214.82 (10.254.214.82)
> > Generic Routing Encapsulation (WCCP)
> >     Flags and version: 0000
> >     Protocol Type: WCCP (0x883e)
> >     Redirect header
> >         0... .... = Well-known service
> >         .0.. .... = Alternative bucket not used
> >         Service ID: Unknown (0x59)
> >         Primary bucket index: 72
> > Internet Protocol, Src: 10.254.127.195 (10.254.127.195), Dst: 10.254.108.228 (10.254.108.228)
> >     Version: 4
> >     Header length: 20 bytes
> >     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> >     Total Length: 240
> >     Identification: 0x9114 (37140)
> >     Flags: 0x04 (Don't Fragment)
> >     Fragment offset: 0
> >     Time to live: 64
> >     Protocol: TCP (0x06)
> >     Header checksum: 0xa650 [correct]
> >     Source: 10.254.127.195 (10.254.127.195)
> >     Destination: 10.254.108.228 (10.254.108.228)
> > Transmission Control Protocol, Src Port: 1291 (1291), Dst Port: microsoft-ds (445), Seq: 0, Ack: 0, Len: 188
> > NetBIOS Session Service
> > SMB (Server Message Block Protocol)
> > SMB Pipe Protocol
> > DCE RPC Request, Fragment: Single, FragLen: 100, Call: 1 Ctx: 0
> > 
> > Many thanks for your cooperation
> > 
> > Andrej Mikus
> 
> 
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> 


> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev