summaryrefslogtreecommitdiff
path: root/open_issues/bpf.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/bpf.mdwn')
-rw-r--r--open_issues/bpf.mdwn122
1 files changed, 122 insertions, 0 deletions
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.
<braunr> hm, there is a "snoop" source type, using raw sockets
<braunr> too far from the packet source, but i'll try it anyway
<braunr> hm wrong, snoop was the solaris packet filter fyi
+
+
+## IRC, freenode, #hurd, 2012-01-28
+
+ <braunr> nice, i have tcpdump working :)
+ <braunr> let's see if it's as simple with wireshark
+ <pinotree> \o/
+ <braunr> pinotree: it was actually very simple
+ <pinotree> heh, POV ;)
+ <braunr> yep, wireshark works too
+ <braunr> promiscuous mode is harder to test :/
+ <braunr> but that's a start
+
+
+## IRC, freenode, #hurd, 2012-01-30
+
+ <braunr> ok so next step: get tcpreplay working
+ <antrik> braunr: BTW, when you checked the status of the kernel BPF code,
+ did you take zhengda's enhancements/fixes into account?...
+ <braunr> no
+ <braunr> when did i check it ?
+ <antrik> braunr: well, you said the kernel BPF code has serious
+ shortcomings. did you take zhengda's changes into account?
+ <braunr> antrik: ah, when i mention the issues, i considered the userspace
+ translator only
+ <braunr> antrik: and stuff like non blocking io, exporting a selectable
+ file descriptor
+ <braunr> antrik: deb http://ftp.sceen.net/debian-hurd experimental/
+ <braunr> antrik: this is my easy to use repository with a patched
+ libpcap0.8
+ <braunr> and a small and unoptimized pcap-hurd.c module
+ <braunr> it doesn't use devopen yet
+ <braunr> i thought it would be better to have packet filtering working
+ first as a debian patch, then get the new translator+final patch upstream
+ <jkoenig> 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
+
+ <braunr> antrik: i tend to think we need a bpf translator, or anything
+ between the kernel and libpcap to provide selectable file descriptors
+ <braunr> jkoenig: do you happen to know how mach_msg (as called in a
+ hello.c file without special macros or options) deals with signals ?
+ <braunr> i mean, is it wrapped by the libc in a version that sets errno ?
+ <jkoenig> braunr: no idea.
+ <pinotree> braunr: what's up with it? (not that i have an idea about your
+ actual question, just curious)
+ <braunr> pinotree: i'm improving signal handling in my pcap-hurd module
+ <braunr> i guess checking for MACH_RCV_INTERRUPTED will dio
+ <braunr> -INFO is correctly handled :)
+ <braunr> ok new patch seems fine
+ <antrik> braunr: selectable file descriptors?
+ <braunr> antrik: see pcap_fileno() for example
+ <braunr> it returns a file descriptor matching the underlying object
+ (usually a socket) that can be multiplexed in a select/poll call
+ <braunr> obviously a mach port alone can't do the job
+ <braunr> i've upgraded the libpcap0.8 package with improved signal handling
+ for tests
+ <antrik> braunr: no idea what you are talking about :-(
+
+
+## IRC, freenode, #hurd, 2012-02-01
+
+ <braunr> antrik: you do know about select/poll
+ <braunr> antrik: you know they work with multiple selectable/pollable file
+ descriptors
+ <braunr> on most unix systems, packet capture sources are socket
+ descriptors
+ <braunr> they're selectable/pollable
+ <antrik> braunr: what are packet capture sources?
+ <braunr> antrik: objects that provide applications with packets :)
+ <braunr> antrik: a PF_PACKET socket on Linux for example, or a Mach device,
+ or a BPF file descriptor on BSD
+ <antrik> for a single network device? or all of them?
+ <antrik> 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?
+ <braunr> antrik: that's it, but it's not the point
+ <braunr> antrik: the point is that, if programs need to include packet
+ sources in select/poll calls, they need file descriptors
+ <braunr> without a translator, i can't provide that
+ <braunr> so we either decide to stick with the libpcap patch only, and keep
+ this limitation, or we write a translator that enables this feature
+ <pinotree> braunr: are the two options exclusive?
+ <braunr> pinotree: unless we implement a complete bpf translator like i did
+ years ago, we'll need a patch in libpcap
+ <braunr> pinotree: the problem with my early translator implementation is
+ that it's buggy :(
+ <braunr> pinotree: and it's also slower, as packets are small enough to be
+ passed through raw copies
+ <antrik> braunr: I'm not sure what you mean when talking about "programs
+ including packet sources". programs only interact with packet sources
+ through libpcap, right?
+ <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> antrik: that's the idea, yes
+ <antrik> braunr: what is the idea?
+ <braunr> 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?
+ <antrik> braunr: you didn't answer my question though :-)
+ <antrik> braunr: how do programs obtain these FDs?
+ <braunr> antrik: using pcap_fileno() for example
+
+
+## IRC, freenode, #hurd, 2012-02-02
+
+ <antrik> braunr: oh right, you already mentioned that one...
+ <antrik> 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
+ <antrik> 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
+ <braunr> antrik: i agree
+ <braunr> antrik: eth-multiplexer would be the right place