Bug#564158: [libmlpcap-ocaml-dev] Invalid payload in callback function when reading a trace with pcap_loop

[Johan Mazel <johan.mazel@gmail.com>]

Hi

2010/1/8 Stéphane Glondu <steph@glondu.net>

Johan Mazel a écrit :
> The size of pcap_payload is always -1. This means that we can never access to the data inside the packet.

Actually, pcap_payload embeds a pointer outside the ML heap (ML block
with unaligned_tag). I guess it is the libpcap receive buffer. As such,
it is not marshallable nor usable with regular string functions.
However, unsafe_* variants work fine (see pcap_loop.ml example for
example). If you want to use it as a regular string, you'll have to
unsafe_blit the contents into another OCaml string yourself.

I fond this quite inelegant at first. But it allows to use pcap_payload
as a bitstring without any string copy from libpcap buffer, with turned
out to be interesting, especially in a highly sollicitated application.


Best regards,

--
Stéphane

Thanks for the explanation.

I have another remark to do.
I think that the original code, the one that have been used to build the debian package, is the one from this this website: http://www.drugphish.ch/~jonny/mlpcap.html. I figured it because the file mlpcap_0.9.orig.tar.gz from the page of the package http://packages.debian.org/lenny/libmlpcap-ocaml-dev contains the same file README than the mlpcap archive on the http://www.drugphish.ch/~jonny/mlpcap.html.

The version from http://www.drugphish.ch/~jonny/mlpcap.html doesn't have this bug.

Another problem is that both the pcap_loop.ml located in the directory "tests" (I think it is the file that you talk about when you talk about examples, correct me if I'm wrong) from the original package (http://www.drugphish.ch/~jonny/mlpcap.html) and the one from the page of the libmlpcap-ocaml-dev package, both use String.unsafe_*.
But, as I said before, when you compile, install and use the original source, there is no problem with the value given to the callback function.
Is it possible that Sylvain le Gall (the maintainer of this package) added a kind of protection to the Debian package that wopuld explain these two behaviours ?

I'll try to install the package manually from its own source on a Debian machine to see wether I have a behaviour similar to the one of the original code or the package itself.

Regards.

Johan