From 3bf27c93ac4de57623809b71517116d51465f0e1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 17 Mar 2012 12:31:07 +0100 Subject: IRC bits. --- open_issues/bpf.mdwn | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) (limited to 'open_issues/bpf.mdwn') diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn index 98b50430..2a8c897a 100644 --- a/open_issues/bpf.mdwn +++ b/open_issues/bpf.mdwn @@ -440,3 +440,125 @@ This is a collection of resources concerning *Berkeley Packet Filter*s. hm, there is a "snoop" source type, using raw sockets too far from the packet source, but i'll try it anyway hm wrong, snoop was the solaris packet filter fyi + + +## IRC, freenode, #hurd, 2012-01-28 + + nice, i have tcpdump working :) + let's see if it's as simple with wireshark + \o/ + pinotree: it was actually very simple + heh, POV ;) + yep, wireshark works too + promiscuous mode is harder to test :/ + but that's a start + + +## IRC, freenode, #hurd, 2012-01-30 + + ok so next step: get tcpreplay working + braunr: BTW, when you checked the status of the kernel BPF code, + did you take zhengda's enhancements/fixes into account?... + no + when did i check it ? + braunr: well, you said the kernel BPF code has serious + shortcomings. did you take zhengda's changes into account? + antrik: ah, when i mention the issues, i considered the userspace + translator only + antrik: and stuff like non blocking io, exporting a selectable + file descriptor + antrik: deb http://ftp.sceen.net/debian-hurd experimental/ + antrik: this is my easy to use repository with a patched + libpcap0.8 + and a small and unoptimized pcap-hurd.c module + it doesn't use devopen yet + i thought it would be better to have packet filtering working + first as a debian patch, then get the new translator+final patch upstream + braunr, tcpdump works great here (awesome!). I'm probably using + exactly the same setup and "hardware" as you do, though :-P + + +## IRC, freenode, #hurd, 2012-01-31 + + antrik: i tend to think we need a bpf translator, or anything + between the kernel and libpcap to provide selectable file descriptors + jkoenig: do you happen to know how mach_msg (as called in a + hello.c file without special macros or options) deals with signals ? + i mean, is it wrapped by the libc in a version that sets errno ? + braunr: no idea. + braunr: what's up with it? (not that i have an idea about your + actual question, just curious) + pinotree: i'm improving signal handling in my pcap-hurd module + i guess checking for MACH_RCV_INTERRUPTED will dio + -INFO is correctly handled :) + ok new patch seems fine + braunr: selectable file descriptors? + antrik: see pcap_fileno() for example + it returns a file descriptor matching the underlying object + (usually a socket) that can be multiplexed in a select/poll call + obviously a mach port alone can't do the job + i've upgraded the libpcap0.8 package with improved signal handling + for tests + braunr: no idea what you are talking about :-( + + +## IRC, freenode, #hurd, 2012-02-01 + + antrik: you do know about select/poll + antrik: you know they work with multiple selectable/pollable file + descriptors + on most unix systems, packet capture sources are socket + descriptors + they're selectable/pollable + braunr: what are packet capture sources? + antrik: objects that provide applications with packets :) + antrik: a PF_PACKET socket on Linux for example, or a Mach device, + or a BPF file descriptor on BSD + for a single network device? or all of them? + AIUI the userspace BPF implementation in libpcap opens this + device, waits for packets, and if any arrive, decides depending on the + rules whether to pass them to the main program? + antrik: that's it, but it's not the point + antrik: the point is that, if programs need to include packet + sources in select/poll calls, they need file descriptors + without a translator, i can't provide that + so we either decide to stick with the libpcap patch only, and keep + this limitation, or we write a translator that enables this feature + braunr: are the two options exclusive? + pinotree: unless we implement a complete bpf translator like i did + years ago, we'll need a patch in libpcap + pinotree: the problem with my early translator implementation is + that it's buggy :( + pinotree: and it's also slower, as packets are small enough to be + passed through raw copies + braunr: I'm not sure what you mean when talking about "programs + including packet sources". programs only interact with packet sources + through libpcap, right? + braunr: or are you saying that programs somehow include file + descriptors for packet sources (how do they obtain them?) in their main + loop, and explicitly pass control to libpcap once something arrives on + the respecitive descriptors? + antrik: that's the idea, yes + braunr: what is the idea? + 20:38 < antrik> braunr: or are you saying that programs somehow + include file descriptors for packet sources (how do they obtain them?) in + their main loop, and explicitly pass control to libpcap once something + arrives on the respecitive descriptors? + braunr: you didn't answer my question though :-) + braunr: how do programs obtain these FDs? + antrik: using pcap_fileno() for example + + +## IRC, freenode, #hurd, 2012-02-02 + + braunr: oh right, you already mentioned that one... + braunr: so you want some entity that exposes the device as + something more POSIXy, so it can be used in standard FS calls, unlike the + Mach devices used for pfinet + this is probably a good sentiment in general... but I'm not in + favour of a special solution only for BPF. rather I'd take this as an + indication that we probably should expose network interfaces as something + file-like in general after all, and adapt pfinet, eth-multiplexer, and + DDE accordingly + antrik: i agree + antrik: eth-multiplexer would be the right place -- cgit v1.2.3