pcap-dbus.o:undefined reference to `dbus_message_demarshal'

Anton Ivanov anton.ivanov at cambridgegreys.com
Thu Mar 7 02:27:52 PST 2024



On 07/03/2024 10:03, Johannes Berg wrote:
> On Thu, 2024-03-07 at 09:54 +0000, Anton Ivanov wrote:
>>
>> PCAP is not feasible to incorporate into the build system at present.
>> It has grown all kinds of warts over the years and brings a lot of dependencies.
>> IMHO we should remove it from the tree. It has reached a point where it cannot
>> be built on a modern system.
> 
> I suppose it might be possible to call pcap-config? But agree that it
> doesn't seem really worth investing in.
> 
>> The users who need the same functionality can produce a bpf filter using tcpdump
>> and load it as "firmware" into the vector/raw driver.
>>
>> I am working on a pure python bpf compiler which takes the same syntax as PCAP.
>> It is showing signs of life and it can do some of the simpler use cases. Once
>> that is ready, it should be possible to use that instead of pcap/tcpdump.
> 
> How's that required to be formatted and loaded? tcpdump itself can also
> dump the filter in BPF format, with -d/-ddd (-dd is a C representation,
> so probably not useful). Perhaps we could even automatically call
> 'tcpdump' at runtime?

That is one option.

As far as common use cases are concerned, at present you can:

tcpdump -ddd, convert it to raw binary (3 liner in a language of choice) and pass that to vecX as a bpffile=

It may be worth it to make vecX also take the -ddd format directly by adding "format" options to bpffile.

I'd rather do that instead of invoking tcpdump out of a device open. The -ddd notation (+/- a comma here and there) is
standard - it is also used by iptables, etc. It can used by other code generators as well.

> 
> johannes
> 

-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/



More information about the linux-um mailing list