Re: [tcpdump-workers] Printing PPI packets
Michael, See the attached file for a sample of IPv4 packets captured. There are also libpcap issues here that need to be resolved. At present, using any filter with a PPI device fails to match any packet that doesn't have a DLT of DLT_IEEE802_11. Darren On 3/05/11 03:59 PM, Michael Richardson wrote: "Darren" == Darren Reed writes: Darren> Printing PPI packets with tcpdump does not turn out to be Darren> that hard. Darren> My simple tests have produced the output as below. Super! Do you have some PPI pcap files we can include in the test cases? I've committed your code, will git push when I get online. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Printing PPI packets
On May 5, 2011, at 11:07 AM, Darren Reed wrote: > There are also libpcap issues here that need to be resolved. At present, > using any filter with a PPI device fails to match any packet that doesn't > have a DLT of DLT_IEEE802_11. ...which is one of the things wrong with PPI. pcap-ng makes the link-layer type part of the record header, rather than part of the record data, so you don't have to special-case the filtering routine (so that, for PPI, the filter routine would pull the link-layer type out and run different filter programs based on the link-layer type) or have the BPF compiler generate, for PPI, code that switches off the link-layer type and includes code to do the filtering for all possible link-layer types. pcap-ng, and the first of those strategies for PPI, would require a routine that sets the filter on a pcap_t to a string, so that code can be generated while reading the savefile as each link-layer type is discovered (unless you generate code for every possible link-layer type and stash it away "just in case", but even that requires a different API).- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Printing PPI packets
On 5/05/11 11:16 AM, Guy Harris wrote: On May 5, 2011, at 11:07 AM, Darren Reed wrote: There are also libpcap issues here that need to be resolved. At present, using any filter with a PPI device fails to match any packet that doesn't have a DLT of DLT_IEEE802_11. ...which is one of the things wrong with PPI. pcap-ng makes the link-layer type part of the record header, rather than part of the record data, so you don't have to special-case the filtering routine (so that, for PPI, the filter routine would pull the link-layer type out and run different filter programs based on the link-layer type) or have the BPF compiler generate, for PPI, code that switches off the link-layer type and includes code to do the filtering for all possible link-layer types. pcap-ng, and the first of those strategies for PPI, would require a routine that sets the filter on a pcap_t to a string, so that code can be generated while reading the savefile as each link-layer type is discovered (unless you generate code for every possible link-layer type and stash it away "just in case", but even that requires a different API). I see - you're concerned about how do you make "tcpdump icmp" work when the link type is PPI (or pcap-ng) and the contents of the file could be a mixture of ethernet, Infiniband and others. The problem being that the location of the IP header is different in each, requiring a different program to be generated and applied. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Printing PPI packets
On May 5, 2011, at 11:28 AM, Darren Reed wrote: > I see - you're concerned about how do you make "tcpdump icmp" work when the > link type is PPI (or pcap-ng) Presumably meaning "when the link type is PPI or when the file is a pcap-ng file" (pcap-ng isn't a link type, it's a file format). > and the contents of the file could be a mixture of ethernet, Infiniband and > others. The problem being that the location of the IP header is different in > each, requiring a different program to be generated and applied. The location of the IP header *and* the location and values of the type field in the link-layer header are different.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] pcap_loop - any other option that won't block while sniffing for infinite time
Hi. I am looking to setup a kind of a sniffer manager in C that is cross platform (Windows, Linux). I have everything working in both platforms, with the exception of one thing - the main sniffing loop. So far, the code I have used is nothing that I haven't already seen online in various places. Basically, I want a client to be able to issue commands to a "manager" that manages the interfaces and perform sniffing on them. Eg. Step 1 is I want to list the interfaces, so I created a function to print the info on the screen after calling pcap_lookupdevs() function. Step 2 is to start sniffing on a particular device (eg. the name of one of the devices returned from previous function) using any BPF filter. Again, I get the code, using pcap_open_live() and pcap_comiple() and pcap_setfilter(). My problem is with the sniffing loop part of it. I want to be able to return from Step 2 and say "yes, sniffing was started successfully" or "no there was an error". I also want the sniffing to occur infinitely, or until I say stop (via pcap_breakloop() function). In addition, I want to be able to issue other calls, like getting the received/dropped packets stats for the network device (which I have the code for), and stopping the sniffing and printing the final statistics and closing the handle to the device. But, I can't seem to do that because the code is always blocking on pcap_loop() or pcap_dispatch(), which I know its expected to. I have a global array of handles and device names for which I am sniffing. Is there any good ideas for this kind of functionality? Is creating a thread and calling the pcap_loop function a good idea? Is there any example code of doing that? Please advise. Thanks. Jeff - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_loop - any other option that won't block while sniffing for infinite time
On May 5, 2011, at 8:29 AM, Jeff Garrett wrote: > I want to be able to return from Step 2 and say "yes, sniffing was started > successfully" or "no there was an error". I also want the sniffing to occur > infinitely, or until I say stop (via pcap_breakloop() function). > In addition, I want to be able to issue other calls, like getting the > received/dropped packets stats for the network device (which I have the code > for), and stopping the sniffing and printing the final statistics and > closing the handle to the device. When will you be issuing the other calls? Will that happen as a result of user input, timer expiration, or what? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Printing PPI packets
On 5/05/11 11:35 AM, Guy Harris wrote: On May 5, 2011, at 11:28 AM, Darren Reed wrote: I see - you're concerned about how do you make "tcpdump icmp" work when the link type is PPI (or pcap-ng) Presumably meaning "when the link type is PPI or when the file is a pcap-ng file" (pcap-ng isn't a link type, it's a file format). and the contents of the file could be a mixture of ethernet, Infiniband and others. The problem being that the location of the IP header is different in each, requiring a different program to be generated and applied. The location of the IP header *and* the location and values of the type field in the link-layer header are different. In terms of pcap, I'm becoming more and more of the opinion that DLT_PPI should not be used for anything other than DLT_IEEE802_11. The reason being is that it increases the complexity of generating BPF far in excess of its worth to try and handle the "special case" of "length == 0" along with the current use of DLT_PPI. Whilst this may actually serve the purposes of the file format and printing packets, in terms of a solution for filtering packets of varied data link types, it just doesn't work. In terms of pcap, I'd thus like to suggest that we add a DLT_LINK that has a header like this: version=0 (8 bits) reserved=0 (8 bits) dlt_hdr_len (16 bits) SAP (32 bits) DLT (32 bits) The dlt_hdr_len is the length of the ethernet header or the 802.11 header or the infiniband header or... The value of the SAP has meaning only for a specific value of the DLT. Whilst some DLTs may use the same set of values for the SAP field, this is not guaranteed. There's no length field because the pcap header already contains the length For example, an ethernet packet might have SAP=0x0800 (ETHERTYPE_IP) and DLT=0x1 (DLT_EN10MB) Why am I not very interested in pcap-ng? "The pcapng file format specification is still work in progress, see:" ... moving target. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Printing PPI packets
On May 5, 2011, at 1:38 PM, Darren Reed wrote: > In terms of pcap, I'm becoming more and more of the opinion that DLT_PPI > should not be used for anything other than DLT_IEEE802_11. Sounds good to me. > Why am I not very interested in pcap-ng? > "The pcapng file format specification is still work in progress, see:" > > ... moving target. pcap-ng is extensible, so it's *always* going to be a moving target. However, both Wireshark and libpcap read it, so there are limits on how much it can move; the spec needs to be clarified to indicate what part isn't going to change and what part is.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Printing PPI packets
On 5/05/11 01:42 PM, Guy Harris wrote: On May 5, 2011, at 1:38 PM, Darren Reed wrote: In terms of pcap, I'm becoming more and more of the opinion that DLT_PPI should not be used for anything other than DLT_IEEE802_11. Sounds good to me. Why am I not very interested in pcap-ng? "The pcapng file format specification is still work in progress, see:" ... moving target. pcap-ng is extensible, so it's *always* going to be a moving target. However, both Wireshark and libpcap read it, so there are limits on how much it can move; the spec needs to be clarified to indicate what part isn't going to change and what part is. Looking through it, the first observation I'd make is that there should not have been any 16 bit fields. The one that concerns me most is the IDB which has a 16bit link type. On Solaris, we're using numbers above 0x8000 to represent a "private" number space for DLPI link types that correspond to internal features. I can see that it being desirable to continue to be able to do that, even if only for the purposes of experimentation. At present, those DLPI numbers typically relate to a more "normal" link type, such as DL_IPV4 (0x8001) being LINKTYPE_IPV4 but others may not. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_loop - any other option that won't block
I would just perform the capture in a separate thread. Have a nice day GV -Original Message- From: tcpdump-workers-ow...@lists.tcpdump.org [mailto:tcpdump-workers-ow...@lists.tcpdump.org] On Behalf Of Jeff Garrett Sent: Thursday, May 05, 2011 8:30 AM To: tcpdump-workers@lists.tcpdump.org Subject: [tcpdump-workers] pcap_loop - any other option that won't block while sniffing for infinite time Hi. I am looking to setup a kind of a sniffer manager in C that is cross platform (Windows, Linux). I have everything working in both platforms, with the exception of one thing - the main sniffing loop. So far, the code I have used is nothing that I haven't already seen online in various places. Basically, I want a client to be able to issue commands to a "manager" that manages the interfaces and perform sniffing on them. Eg. Step 1 is I want to list the interfaces, so I created a function to print the info on the screen after calling pcap_lookupdevs() function. Step 2 is to start sniffing on a particular device (eg. the name of one of the devices returned from previous function) using any BPF filter. Again, I get the code, using pcap_open_live() and pcap_comiple() and pcap_setfilter(). My problem is with the sniffing loop part of it. I want to be able to return from Step 2 and say "yes, sniffing was started successfully" or "no there was an error". I also want the sniffing to occur infinitely, or until I say stop (via pcap_breakloop() function). In addition, I want to be able to issue other calls, like getting the received/dropped packets stats for the network device (which I have the code for), and stopping the sniffing and printing the final statistics and closing the handle to the device. But, I can't seem to do that because the code is always blocking on pcap_loop() or pcap_dispatch(), which I know its expected to. I have a global array of handles and device names for which I am sniffing. Is there any good ideas for this kind of functionality? Is creating a thread and calling the pcap_loop function a good idea? Is there any example code of doing that? Please advise. Thanks. Jeff - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Printing PPI packets
On May 5, 2011, at 2:45 PM, Darren Reed wrote: > Looking through it, the first observation I'd make is that there should not > have been any 16 bit fields. The one that concerns me most is the IDB which > has a 16bit link type. We could add an "enhanced IDB" with a 32-bit LinkType field. > On Solaris, we're using numbers above 0x8000 to represent a "private" > number space for DLPI link types that correspond to internal features. I can > see that it being desirable to continue to be able to do that, even if only > for the purposes of experimentation. At present, those DLPI numbers typically > relate to a more "normal" link type, such as DL_IPV4 (0x8001) being > LINKTYPE_IPV4 but others may not. If a link-layer type is desired for internal experimentation within an organization, with the organization having no reason to care whether those captures will be properly interpreted outside the organization, you can use one of the LINKTYPE_USERn types. If you want the files to be usable outside the organization - i.e., if you want a vendor namespace for link-layer types (which means it applies to pcap as well as pcap-ng) - we'd need to structure the link-layer type values to include an organization ID. I've already put some work into that to support some NetBSD-specific link-layer types; it never went any further, but it splits the link-layer type value into: the upper 4 bits, for an FCS length field, plus the next bit whose purpose I'd have to remember, plus the next bit, which indicates whether the FCS length is present or not; the next 10 bits, for a "class" value that would be an organization ID; the next 16 bits, for link-layer type values within that class. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Printing PPI packets
On May 5, 2011, at 4:54 PM, Guy Harris wrote: > On May 5, 2011, at 2:45 PM, Darren Reed wrote: > >> Looking through it, the first observation I'd make is that there should not >> have been any 16 bit fields. The one that concerns me most is the IDB which >> has a 16bit link type. > > We could add an "enhanced IDB" with a 32-bit LinkType field. ...and the only remaining 16-bit fields are: the major and minor version numbers in the Section Header Block - yeah, I know, 640K and all that, but I doubt that'll be an issue, especially for the major version number (if you completely incompatibly change the file format more than 65535 times in the next 1000 years, UR DOING IT WRONG, and even for the minor version number, given the extensibility of the format, I don't see much need for version number changes); the Interface ID and Drops Count in the Packet Block, but that's been deprecated in favor of the Extended Packet Block, with a 32-bit interface ID and a 64-bit drop count as an option; the Record Type and Record Length in the Name Resolution Block - I'm not sure there will be more than 65533 more name types, so the Record Type is probably OK at 16 bits, but I guess you could either have really really long network addresses or, more likely, a huge number of names corresponding to an address, so the 16-bit Record Length might be an issue, so there might have to be an Extended Name Resolution Block.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Printing PPI packets
On 5/05/11 05:09 PM, Guy Harris wrote: On May 5, 2011, at 4:54 PM, Guy Harris wrote: On May 5, 2011, at 2:45 PM, Darren Reed wrote: Looking through it, the first observation I'd make is that there should not have been any 16 bit fields. The one that concerns me most is the IDB which has a 16bit link type. We could add an "enhanced IDB" with a 32-bit LinkType field. ...and the only remaining 16-bit fields are: the major and minor version numbers in the Section Header Block - yeah, I know, 640K and all that, but I doubt that'll be an issue, especially for the major version number (if you completely incompatibly change the file format more than 65535 times in the next 1000 years, UR DOING IT WRONG, and even for the minor version number, given the extensibility of the format, I don't see much need for version number changes); the Interface ID and Drops Count in the Packet Block, but that's been deprecated in favor of the Extended Packet Block, with a 32-bit interface ID and a 64-bit drop count as an option; the Record Type and Record Length in the Name Resolution Block - I'm not sure there will be more than 65533 more name types, so the Record Type is probably OK at 16 bits, but I guess you could either have really really long network addresses or, more likely, a huge number of names corresponding to an address, so the 16-bit Record Length might be an issue, so there might have to be an Extended Name Resolution Block. I looked over the other 16 bit fields and came to the same conclusion as yourself about the above so didn't mention them. In the breakup where you were suggesting 10 bits that could be an organization ID, reserve "0" for the publicly recognised set and all 1's for private/experimental. Is 10 bits enough for an organisation ID? How many organisations have received a number for use with SNMP? I'm not saying that as many organisations will need an identifier here but rather that the number of organisations might be larger than you would suspect at first. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Printing PPI packets
On May 5, 2011, at 5:20 PM, Darren Reed wrote: > In the breakup where you were suggesting 10 bits that could be an > organization ID, reserve "0" for the publicly recognised set That's already done (implicitly, by virtue of those bits being 0 in existing LINKTYPE_ values, and explicitly as well). > and all 1's for private/experimental. Sounds good, although it is somewhat redundant with LINKTYPE_USERn (presumably "private/experimental" means "multiple organizations can use the same value for different purposes, so don't request that the tcpdump/Wireshark/etc. developers put into their official releases anything that assigns a particular interpretation to any of those values"). > Is 10 bits enough for an organisation ID? How many organisations have > received a number for use with SNMP? I'm not saying that as many > organisations will need an identifier here but rather that the number of > organisations might be larger than you would suspect at first. Well, given that the other bits I took aren't necessary for pcap-ng, we could use the reserved field in the existing IDB for an organization code, and, if and when we get above 1023 organizations, say "sorry, usable only in pcap-ng". If by "how many organisations have received a number for use with SNMP?" you mean "how many organizations have SMI Network Management Private Enterprise Codes?", the answer is "probably somewhere around 37,891, modulo holes in the number space" as of today: http://www.iana.org/assignments/enterprise-numbers Using IEEE OUI's would require 24 bits, leaving only 8 bits for existing LINKTYPE_ values, and we're already up to 238, so that's not acceptable. Besides, OUIs cost a minimum of USD 1,750: http://standards.ieee.org/develop/regauth/oui/index.html which is another reason not to use them.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
