[RFC] USBdump patches

[Hans Petter Selasky]

On Wednesday 24 November 2010 07:35:30 Andrew Thompson wrote:
> On 24 November 2010 18:46, Weongyo Jeong <weongyo.jeong at gmail.com> wrote:
> > On Wed, Nov 24, 2010 at 01:59:47PM +1300, Andrew Thompson wrote:
> >> On 24 November 2010 13:36, Jung-uk Kim <jkim at freebsd.org> wrote:
> >> > On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote:
> >> >>    - BPF was normally for ethernet frames (most operations were
> >> >> based on mbuf including the machine filter and there were a lot of
> >> >> assumptions the input buffer is mbuf type.  For example, handling
> >> >> BPF_LD|BPF_W|BPF_ABS).  However the USB packet isn't like mbuf
> >> >> style that it's just a linear buffer.  So the most important code
> >> >> or assumption wasn't compatible.
> >> > 
> >> > BPF can deal with linear buffer just fine.  For example, ng_bpf(4)
> >> > does it.  Please see sys/netgraph/ng_bpf.c.
> >> > 
> >> >>    - Just making the patch for BPF code, it looked like a trick or
> >> >> a hack to me because I couldn't define what BPF should be.
> >> > 
> >> > If you don't want to touch bpf.c for some reason, netgraph(4) (->
> >> > ng_bpf) may be an alternate solution for you.
> >> > 
> >> >>    - I could not define BPF exactly myself that what BPF should
> >> >> cover. I agreed with that BPF is for ethernet packet filtering but
> >> >> could not make sure myself that BPF could cover USB packets.
> >> > 
> >> > BPF is a generic packet filter machine, i.e., bytecode is generic
> >> > enough for any type of data stream.
> >> 
> >> I agree that this is the best way forward, if it can be achieved.
> > 
> > Attached is what I really wanted to do.  USB pf is greatly simplified
> > and perfectly satisfy me.  It'll fully benefit from changes of BPF code.
> > 
> > I'll commit this version into HEAD if no objections.
> 
> Looks good. Is this compatible with the wireshark pcap format?

Hi,

To avoid that extra copy of all the data into a linear buffer before the PF-
code is run, I think you should look more carefully at my last released patch.

Probably what we need is a special function that can tap "struct 
usb_page_cache *" with a offset and a length. We can probably do this in a 
similar fashion as to this:

#if USB_HAVE_MBUF
struct usb_m_copy_in_arg {
        struct usb_page_cache *cache;
        usb_frlength_t dst_offset;
};

static int
usbd_m_copy_in_cb(void *arg, void *src, uint32_t count)
{
        register struct usb_m_copy_in_arg *ua = arg;

        usbd_copy_in(ua->cache, ua->dst_offset, src, count);
        ua->dst_offset += count;
        return (0);
}

void
usbd_m_copy_in(struct usb_page_cache *cache, usb_frlength_t dst_offset,
    struct mbuf *m, usb_size_t src_offset, usb_frlength_t src_len)
{
        struct usb_m_copy_in_arg arg = {cache, dst_offset};
        int error;

        error = m_apply(m, src_offset, src_len, &usbd_m_copy_in_cb, &arg);
}
#endif

So I would suggest a function like this:

bpf_tap_apply(bus->ifp, src_offset, src_len, usbd_m_copy_in_cb, &arg);

But USB-PF would also require some additional information, which I'm not sure 
where to put.

Please have a look at my patch posted to freebsd-usb yesterday.

Reference:

@@ -1778,7 +187,7 @@ usbpf_xfertap(struct usb_xfer *xfer, int type)
         * read filter to pass a virtually linear buffer.
         */
        buf = ptr = malloc(sizeof(struct usbpf_pkthdr) + (USB_PAGE_SIZE * 5),
-           M_USBPF, M_NOWAIT);
+           M_TEMP, M_NOWAIT);
        if (buf == NULL) {
                printf("usbpf_xfertap: out of memory\n");       /* XXX */
                return;
@@ -1828,49 +237,7 @@ usbpf_xfertap(struct usb_xfer *xfer, int type)
                ptr += xfer->frlengths[i];
        }
 
-       usbpf_tap(bus->uif, buf, ptr - buf);
+       bpf_tap(bus->ifp->if_bpf, buf, ptr - buf);
 done:
-       free(buf, M_USBPF);
+       free(buf, M_TEMP);
 }

--HPS