Re: [tcpdump-workers] reconstruct HTTP requests in custom sniffer
-[ Sun, Jan 09, 2011 at 02:19:53PM +0900, Andrej van der Zee ] > Is there anything to say about a rough time-schedule? Support for TCP segmentation as well as new parsers that use this feature should be pushed before end of week. Concerning the capture of POST messages we should probably start working on this in february (this is a small company so no schedule is ever definitive, so no promise). > In some of our projects, we are only interested in the length of HTTP > requests and responses therefor reassembling the whole requests would be > overkill, as the segment lengths can be read from the TCP headers of packets > in a TCP stream, obviously. Yes, in theory we could follow the sizes associated with each request quite precisely even with truncated packets as long as the "Content-length" header lines are present. To be honest, truncated packets were introduced very recently and were not tested much (since we do not require this feature), thus I'm not certain junkie is very robust in this regard ; but I'm going to check. > In other projects, we definitely have to access > the POST data need full-reassembly. Depending on the project, a different > parsing-behavior is wanted. Will such behavior be configurable without > having to write my own patches against junkie? What we need here is to be able to tell junkie for which hosts we want to keep all queries (including POST data). At first sight, I planned to let junkie reassemble everything on HTTP and copies all HTTP requests in whole, then drop everything I do not need in the callback that's called after the parse. I find this approach simpler and I don't think we require extra speed in the parse phase anyway. It will still be possible to optimize this later anyway. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] reconstruct HTTP requests in custom sniffer
Hi Cedric, > Support for TCP segmentation as well as new parsers that use this > feature should be pushed before end of week. Concerning the capture of > POST messages we should probably start working on this in february (this > is a small company so no schedule is ever definitive, so no promise). > I guess we just have to wait awhile then and see how things develop. We are a small company too, and the projects concerning POST re-assembly need some time to take off. After TCP segmentation is pushed, I will make some time to get a first feel of junkie. > > > In some of our projects, we are only interested in the length of HTTP > > requests and responses therefor reassembling the whole requests would be > > overkill, as the segment lengths can be read from the TCP headers of > packets > > in a TCP stream, obviously. > > Yes, in theory we could follow the sizes associated with each request quite > precisely even with truncated packets as long as the "Content-length" > header lines are present. Another way is too follow the TCP stream and summarize the payload lengths in the TCP headers instead of using HTTP headers, ignoring retransmitted packets. > To be honest, truncated packets were > introduced very recently and were not tested much (since we do not > require this feature), thus I'm not certain junkie is very robust in this > regard ; but I'm going to check. > Nice test-case for us would be to check if one could get the HTTP request/response lengths as described above. Cheers, Andrej - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Request for new DLT value for Wireshark Dissector
Hi, I´ve written a dissector (MUX27010) for wireshark and I want to commit it to the project. Therefore I need a new DLT value for this dissector/protocol because the protocol doesn´t base upon another data link layer protocol. What the dissector does: It analyses a multiplexed communication between a GSM modem and the host, whereby the multiplexing is based upon the specification 3G TS 27.010. Could you please assign a DLT value for this MUX27010 dissector? Kind regards, Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
On Jan 10, 2011, at 6:16 AM, Schemmel, Hans-Christoph wrote: > I´ve written a dissector (MUX27010) for wireshark and I want to commit it to > the project. Therefore I need a new DLT value for this dissector/protocol > because the protocol doesn´t base upon another data link layer protocol. > What the dissector does: It analyses a multiplexed communication between a > GSM modem and the host, whereby the multiplexing is based upon the > specification 3G TS 27.010. So does a packet begin with the address field, as described by TS 27.010 section 5.2.1.2, followed by the section 5.2.1.3 control field, followed by the information field if present? (Or does it, for example, include the flag octets - in which case the packet contents presumably escape that octet value - or do something else? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
