[tcpdump-workers] Capturing external packets sent to loopback (FreeBSD) ?
--- Begin Message --- I've got a daemon that listens on a virtual IP address, that is itself attached to a cloned loopback interface on FreeBSD. Packets for that daemon could be arriving from multiple physical interfaces, and that's what's taxing me just now. I would -really- like to be able to process those packets without needing a per-interface thread or process (or other code changes) but it seems FreeBSD (and Linux FWIW) will only capture packets on that loopback IP that also -originated- on the loopback. Does anyone know of any magic trick I can invoke that'll reveal those packets? cheers, Ray --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Capturing external packets sent to loopback (FreeBSD) ?
--- Begin Message --- On 24/02/2020 17:19, Michael Richardson wrote: > > Ray Bellis via tcpdump-workers wrote: > > I've got a daemon that listens on a virtual IP address, that is itself > > attached to a cloned loopback interface on FreeBSD. > > What do you mean by cloned? > ifconfig lo create Yes, indeed. "cloned" is the FreeBSD parlance for that. > Is the address a public address via BGP/OSPF? (because I know where this > comes from I guess) I figured you might guess :) Yes, the address is _announced_ via BGP to upstream routers, but there could be multiple routers with packets arriving on multiple interfaces. > Linux has "any" which captures on "all" interfaces, and with the right stuff > in the libpcap layer can tell you which interface it came from. > It's not clear to me if adequately reveal this through the pcap API. > (I'm just ignorant right now here) I never considered "any" ! But you appear to be suggesting it's not available in FreeBSD ? > My guess is that the packets never actually "arrive" on the loopback > interface. They arrive on all the other interfaces, and since the system is > using a weak-host model, the destination address will match any incoming > interface to get to the "loopback". Hmm... > I know diddly squat about FreeBSD packet capture since SunOS 4.0 BPF > days. Okay, maybe NetBSD 1.0 era. > > So I think you are SOL, and have to do thread-per-interface for now :-) I'll keep digging :) cheers, Ray --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Capturing external packets sent to loopback (FreeBSD) ?
--- Begin Message --- On 24/02/2020 17:42, Guy Harris wrote: > What do you mean by "loopback" here? The term "loopback interface" > generally means "fake interface that sends packets from the machine > to itself" on UN*Xes, e.g. the lo0 interface on most UN*Xes or just > lo on Linux. Is that the type of interface on which you're > capturing? It is, but it's also the type of interface typically used when you want to announce a (potentially multi-homed) service address (e.g. via an IGP) that is not directly on a physical interface. > ...why would packets be delivered on the loopback interface if they > arrived on a physical interface? That depends on what you mean by "delivered". The daemon is only listening on that single IP address, which is itself only present on the loopback address. The kernel even has a routing table entry for that address, with the correct loopback interface specified as the destination. What appears to be missing is any way to tell the kernel to send a packet that's in transit between the outside and that virtual "inside" interface out to the BPF system. You *can* sniff packets that a machine "sends to itself", though. cheers, Ray --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] libpcap pluggable I/O branch, rebased
--- Begin Message --- On 21/08/2020 20:26, Michael Richardson wrote: > > Ray, I rebased raybellis-gzip-v2 upon libpcap head. > Do you have a github that I can add as as reviewer? Do you mean my github a/c name? That's just "raybellis". > Mostly I did this because the FreeBSD tests seemed to fail, and I wanted to > see them work. I know this has taken forever. > > There are some changes to use charset_fopen() that I think that I managed to > port across. Do you have some tests that you could put this through? Not any more, but I could likely devise some. > https://github.com/mcr/libpcap/tree/raybellis-gzip-v2 > > https://github.com/the-tcpdump-group/libpcap/pull/914/files > > Thank you. > I hope to merge it next week, but I want to add: > ./configure --enable-ioplugin > > and the equivalent for CMake, but I really am CMake-challenged, so I don't > really understand how to do the equivalent there. I am also CMake-challenged. I loathe it as a build system :p > I've left a comment in the pull request above where we'd #ifdef out. > > I also wonder if we should have a pcap_enableioplugin() option so that > applications have to opt-in. I'm just really concerned about opening up > holes for some setuid() libpcap system. I share that concern, but don't know how to address it. Ray --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
