On Tue, Apr 02, 2002 at 01:41:56PM -0800, Brian Wellington wrote: > When getting a response that spans multiple segments (dig for > huge.foo.xbill.org, if anyone wants to try it) and decoding it, I see > [Short Frame: DNS] > in the first segment, and > [Unreassembled Packet: DNS] > in the second (and last). The 'Desegment all DNS packets' option is > enabled. Is the TCP configuration option "Allow subdissector to desegment TCP streams" option enabled? If not, enabled it (and save your configuration, so it stays on). Ther are per-protocol options to control TCP reassembly, which default to "on" (if they don't, that's a bug). There's also a *global* option to control it, which is the TCP "Allow subdissector to desegment TCP streams" option; both options must be on for a particular protocol's data to be reassembled. "Allow subdissector to desegment TCP streams" defaults to "off". If I turn that option off, with a "dig huge.foo.xbill.org" trace, I get the behavior you describe. If I don't, the reply gets reassembled. > I don't see an obvious way to specify explicitly that these > segments are part of the same packet and should be decoded as such. There isn't one. If reassembly isn't enabled in both places, they *shouldn't* be decoded as part of the same packet. If reassembly *is* enabled in both places, they should automatically be decoded as part of the same packet; if they're not, that's a bug, and the bug should be fixed.
Powered by MHonArc 2.6.10