On Sep 23, 2010, at 3:11 AM, Jaap Keuter wrote:
> I understand what you're doing in this matter (I do a similar thing in our
> software), still I doubt it's a good idea to strip out the underlying network
> layer information. That information is needed in Wireshark to get a grasp of the
> nodes involved, conversations between endpoints, etc. All kinds of analysis
> functions are based on that. Making it a pure application level dissection
> strips away what makes Wireshark Wireshark, a *network* traffic analyzer, not an
> application log viewer.
Right, what I'm proposing isn't to strip away all network layer information - just not encode it as contrived headers, with fake IP ident fields, UDP/TCP checksums, TCP sequence/ack numbers, etc. Essentially this would encode what's available at a socket level: local+remote IP, ports, and transport type. Think of it as a socket wiretap.
I take it no one's done this yet. :)
> I'm not sure why UDP encapsulation won't work for you in this case. You most
> likely tap your SIP messages between the SIP engine and the protocol stack.
> There you have complete SIP messages, ideal for putting in UDP encapsulated
> payloads.
Unfortunately you don't - you do if you wait until after the parser's done, so it can decide what a bounded/full "message" is; but if you do it before the parser (i.e., right above the socket) then obviously for TCP you'll be seeing a stream and not whole messages. If you wait until after the parser's decided what a full SIP message is, and encode that as a fake UDP packet, you're limited to 64k message size and it creates confusion for someone looking at the capture because they think it's over UDP. (we have this problem right now, because our tool currently encodes SIP/TCP as SIP/UDP in pcap)
-hadriel
