Re: [tcpdump-workers] streamlined direction patch for libpcap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A pcap_t structure, as of 0.8, contains a list of function pointers for various libpcap operations; look for Methods in pcap-int.h. You'd add a direction_op member, which would be a function with the same arguments as pcap_direction(). pcap_direction() would just call that function and return its return value. Each pcap-*.c file for a particular platform would contain the appropriate function for that platform, e.g. pcap_setdirection_linux(); that would be a static function. In the code to open a capture, the direction_op member of the pcap_t would be set to point to that function. What needs to be determined is not the operating system, but the capture mechanism. That's already done by the configure script - that's what determines which pcap-*.c file to compile, so doing it the way I describe above handles that for you. That's great, I'll try to code this today. Should the function be called pcap_direction(), pcap_setdirection(), or something else? pcap_setdirection() indicates that it sets something, but direction doesn't indicate which direction it's setting, so pcap_direction() might be sufficient. Well I'm not good at naming things, but pcap_setdirection() sounds like pcap_setfilter() function. This functions are quite related in functionality, because they both set some start parameters. But I leave that strategic decision to main pcap developers :) Greetings, Pawel Pokrywka -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQD1AwUBQndbNwYJ6m8RUpKnAQI7AAb/aKPFjbUr8KU1B7OTX8cMvvOC1XKdFpq1 zQEI3nPrabDDzbQDlYm3KaZngK2f83OOcih0dwC7iSLGGZFErPG1CdPWNO/CrMQS 5+UYlbLNgolyXA/XvZr8rbtRXZlyjVcwZH7mP6Q44V+sTd9ZA0hlsyhVmwoxsSd1 McNaZRAjhsuYYwKy7VBUzLeS0l/7DqYHoLDtNAEof04Yuy5vi6LMqsXFEVJRV5Uy TjYhPgiGyCXBmL4Cegk+CCIZS6J0eEFbvvYEs99Aeu6gq4Qfb4KvGQ2aIfsG8SL3 DQzy+VNhxjU= =idSm -END PGP SIGNATURE- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] streamlined direction patch for libpcap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To specify direction pcap_direction() have to be called after pcap_open_live() with desired direction (D_IN, D_OUT, D_INOUT). Default direction, in case pcap_direction() was not called is D_INOUT. Are all three of those needed? On some platforms, I think it might be possible to implement D_IN and D_INOUT, but not D_OUT - some BSDs have an option in BPF to control whether to see outgoing packets. The *main* complaint I've seen is that people are writing applications that are capturing with libpcap and also sending packets, and they don't want to see the packets they're sending. Sorry for delay, I was fighting with my email account. This is my exactly my case. My app is sending ethernet frames with spoofed mac address and when listening I don't want to see them. If all three are needed, we could have it return an error on some platforms. (On other platforms, it might not be possible to implement either D_IN or D_OUT, at least not without checking source MAC addresses.) For me, only D_IN is required, so I would be happy with this direction only :) I don't know other platforms, but are you sure that there is no way to implement for example D_IN, when there is D_OUT and D_INOUT? Maybe there are other problems, but substracting D_OUT from D_INOUT gives D_IN in my opinion :) Greetings, Pawel Pokrywka -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQD1AwUBQnYM6gYJ6m8RUpKnAQLfZAcAzVp5mH83nk1iTL3XwBvxbOQVz6RJ2qix 94UAn5WNyyrEWuHf7JeYDRGLspWJ5FHFw48XiNk+MovJtjVMrbJm3aOE2WnFUGZP yeccCkbbfDwVZaU739mDl+3U/0T+T/v4uWMtYWEi6MMDT6uz/X2vKQcz/GoOGL/l 2K7mLflCvsx0VPF5eaONKlC7n8uM3hYEI6vFzzkbJH6vrXhqjMqXwYV8mpdcVmjg ztDRpP4VgP/xR23JL+4xhRL0lS4EoJP4K8yKdM86ZCVNH9lHkCJQH6BBZzTej3vs tzJ7g6ITL8g= =R/bO -END PGP SIGNATURE- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] streamlined direction patch for libpcap
Pawel Pokrywka wrote: For me, only D_IN is required, so I would be happy with this direction only :) I don't know other platforms, but are you sure that there is no way to implement for example D_IN, when there is D_OUT and D_INOUT? Maybe there are other problems, but substracting D_OUT from D_INOUT gives D_IN in my opinion :) It does, assuming that subtracting is implementable. :-) The problem is that, for example, on most if not all of the BSDs, the direction of incoming packets isn't supplied (which is a problem that should ultimately be fixed, but that's not something we can fix purely in libpcap; it'd require kernel changes, and it'd also be useful to supply some additional information while we're at it - I'll be looking at changes of that sort at some point). This means that libpcap can't check the direction, so it can't decide to reject incoming rather than outgoing packets. Some, perhaps all, of the BSDs now have an ioctl for BPF devices, BIOCSEESENT, which controls whether outgoing packets will be supplied to BPF devices; that can be used to implement D_IN vs. D_INOUT, but can't be used to implement D_OUT, as it can't control whether *incoming* packets are supplied. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] streamlined direction patch for libpcap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guy Harris wrote: Pawel Pokrywka wrote: For me, only D_IN is required, so I would be happy with this direction only :) I don't know other platforms, but are you sure that there is no way to implement for example D_IN, when there is D_OUT and D_INOUT? Maybe there are other problems, but substracting D_OUT from D_INOUT gives D_IN in my opinion :) It does, assuming that subtracting is implementable. :-) The problem is that, for example, on most if not all of the BSDs, the direction of incoming packets isn't supplied (which is a problem that should ultimately be fixed, but that's not something we can fix purely in libpcap; it'd require kernel changes, and it'd also be useful to supply some additional information while we're at it - I'll be looking at changes of that sort at some point). This means that libpcap can't check the direction, so it can't decide to reject incoming rather than outgoing packets. Some, perhaps all, of the BSDs now have an ioctl for BPF devices, BIOCSEESENT, which controls whether outgoing packets will be supplied to BPF devices; that can be used to implement D_IN vs. D_INOUT, but can't be used to implement D_OUT, as it can't control whether *incoming* packets are supplied. Now I see your point. I've thought that info about packet direction can be read per packet on these BSD platforms. But it is set on capture start only, and it behaves like a filter, so outgoing packets just can't be read by pcap. Thanks for clarification :) Back to pcap_direction() function. I think I better like idea, that pcap_direction() should return error when given direction is not supported on users platform. If there are no better ways, enclosing pcap_direction() body and direction checks in pcap_read_packet() with #ifdefs should do the job. I will do this tomorrow and send updated patch. But first I need to figure out how determine operating system at compile time. Greetings, Pawel Pokrywka -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQD1AwUBQnabkgYJ6m8RUpKnAQKuSwb+KSSfWuvDMQwfaI+2iQwduQfL/rc/DhnE hSKF6W1s4L5FkGltS6h0eip1/GvId2FsW57EnD9hLpf7MFmp11PSLvoIOOgv2shj ImOQymDUy04J83Pz/2ZECKzIYC12BkxC0JM8XLKv1oXDMHOcBKDpA+Bm/kX13LkN StNZIJX34JdILayByWPBBT+WJUTtOMl27dCkvUzx9XDmhwa3BveQOvR5GSBUbN+k ieFW1hpiGFK5e1F/PX4hkpMPITKog0W6h+Z4GD3vdD8PH1QmhAx/Lx+lBM5XHGUd uIXc/YA0A/8= =2BTT -END PGP SIGNATURE- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] streamlined direction patch for libpcap
Pawel Pokrywka wrote: Back to pcap_direction() function. I think I better like idea, that pcap_direction() should return error when given direction is not supported on users platform. If there are no better ways, enclosing pcap_direction() body and direction checks in pcap_read_packet() with #ifdefs should do the job. There is a better way. A pcap_t structure, as of 0.8, contains a list of function pointers for various libpcap operations; look for Methods in pcap-int.h. You'd add a direction_op member, which would be a function with the same arguments as pcap_direction(). pcap_direction() would just call that function and return its return value. Each pcap-*.c file for a particular platform would contain the appropriate function for that platform, e.g. pcap_setdirection_linux(); that would be a static function. In the code to open a capture, the direction_op member of the pcap_t would be set to point to that function. I will do this tomorrow and send updated patch. But first I need to figure out how determine operating system at compile time. What needs to be determined is not the operating system, but the capture mechanism. That's already done by the configure script - that's what determines which pcap-*.c file to compile, so doing it the way I describe above handles that for you. Should the function be called pcap_direction(), pcap_setdirection(), or something else? pcap_setdirection() indicates that it sets something, but direction doesn't indicate which direction it's setting, so pcap_direction() might be sufficient. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] streamlined direction patch for libpcap
Pawel Pokrywka wrote: Hello, I need to specify packet direction for my sniffing application, but current libpcap doesn't offer this functionality. I've found a patch[1], which adds ability to set direction of packet capture. The patch works good, but it modifies pcap_pkthdr struct from pcap.h, which can be considered API change[2]. Therefore I streamlined this patch, so now it doesn't change public structures. It adds just new function: int pcap_direction(pcap_t *p, direction_t d) and new enum typedef - direction_t. To specify direction pcap_direction() have to be called after pcap_open_live() with desired direction (D_IN, D_OUT, D_INOUT). Default direction, in case pcap_direction() was not called is D_INOUT. Are all three of those needed? On some platforms, I think it might be possible to implement D_IN and D_INOUT, but not D_OUT - some BSDs have an option in BPF to control whether to see outgoing packets. The *main* complaint I've seen is that people are writing applications that are capturing with libpcap and also sending packets, and they don't want to see the packets they're sending. If all three are needed, we could have it return an error on some platforms. (On other platforms, it might not be possible to implement either D_IN or D_OUT, at least not without checking source MAC addresses.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] streamlined direction patch for libpcap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I need to specify packet direction for my sniffing application, but current libpcap doesn't offer this functionality. I've found a patch[1], which adds ability to set direction of packet capture. The patch works good, but it modifies pcap_pkthdr struct from pcap.h, which can be considered API change[2]. Therefore I streamlined this patch, so now it doesn't change public structures. It adds just new function: int pcap_direction(pcap_t *p, direction_t d) and new enum typedef - direction_t. To specify direction pcap_direction() have to be called after pcap_open_live() with desired direction (D_IN, D_OUT, D_INOUT). Default direction, in case pcap_direction() was not called is D_INOUT. Information about direction is not saved to dump file. I think of it as promiscuous flag, which also isn't saved. I've tested it on the latest libpcap from cvs (2005.04.28). I've read that pcap-ng will allow to specify additional options, such as direction, without changing the API and with ability to save pcap dumps in portable way. But it seems pcap-ng won't be available too early, so pcap_direction() could be used as temporary, but minimal and clean solution. What do you people think about it? Is there any chance for this to go into mainline libpcap? (if so, I would be very happy :) ) My time and skills are limited, but if there are changes required, I will do my best. Pawel Pokrywka [1] http://www.beonline.com.au/kb/pcap.html [2] http://marc.theaimsgroup.com/?l=tcpdump-workersm=108146017831222w=2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQD1AwUBQnN3iAYJ6m8RUpKnAQK6GwcAreJlvs94g1igI0ILXg9nsBLnFzeG04Zb BlNf/oJDSWUzFb6c7iDqm20bSRb0sXi1371JKX4Sq1r2scn+/5ayYrWcrYuzeL0S D85EJ+NM9OKRmFvok1ELQ0jnHbWJS5P3Uvue1tCvj2NVA+77V8PDshGpB4RGSWiy qfSp3USnMzRw1rbaOI12qbZCMSI92eppO9LgWqD6SaFhxHKoHa9opr5aL70MCs0K pMp5GFk832JBh3qtesKXrW01SeOqWPeB0baJLPv+uLz253Fv8/VLUZVD04M3uHxc DtljhvA7HoM= =wV6j -END PGP SIGNATURE- libpcap-direction-minimal.patch.gz Description: GNU Zip compressed data - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
