Re: libpcap patches for DLT_SITA support

["Fulko Hew" <fulko.hew () gmail com>]

On Jan 6, 2008 3:40 PM, Guy Harris <guy () alum mit edu> wrote:

> Fulko Hew wrote:
>
> > I think the code is better when its more
> > obvious, segregated and less intrusive.
>
> I've checked into the main and 1.0 branches changes to make it even more
> segregated and less intrusive.  If pcap-linux.c was compiled with SITA
> support, very little of the regular Linux capture code was used, so I
> just removed the SITA support code from pcap-linux.c and moved it to
> pcap-sita.c, and make "--with-sita" cause libpcap to be compiled with
> pcap-sita.c rather than pcap-linux.c.


At this point I'd accept that...
On one hand, my version queries and interoperates with remote
devices to allow remote capture.  What it does do (unfortunately
right now) is ignore any 'local' linux monitorable devices.  It would
be nice to be able to monitor/select either remote (SITA) or local
(Linux) devices.

Thats why I took the approach of 'adding' to linux rather than the
wholesale replacement.  Again... unfortunately I haven't coded (yet)
the ability to do that.  Will I ever have the time to do it?, I don't know,
seeing as (work wise) I won't be allowed the time anymore to work
on it.

In addition, pcap-sita.c was using "ulong" in cases where it wanted a
> 32-bit data type (the "l" in "ntohl()" and "htonl()" really means
> "32-bit", not "long"; the use of "l" is historical and refers to the
> fact that, on L32 and LP32 platforms, where "int" is 16 bits, you need
> "long" for 32 bits); I changed it to use the official libpcap 32-bit
> data type, bpf_u_int32, as "long" could well be 64 bits.


Later on this week I will be looking at a bug (see below),
so I'll have a look at this too.


> As a site effect, I was able to at least compile the SITA code on Mac OS
> X, so I updated README.sita to note that, at least in theory, the SITA
> code might no longer require Linux.  There were some compiler warnings
> generated; I fixed those.  (To get libpcap to compile with GCC warnings,
> create a ".devel" file in the top-level source directory and re-run the
> configure script.)  There are still some warnings:
>
> ./pcap-sita.c: In function 'acn_findalldevs':
> ./pcap-sita.c:415: warning: 'port' may be used uninitialized in this
> function
> ./pcap-sita.c:414: warning: 'proto' may be used uninitialized in this
> function
> ./pcap-sita.c: At top level:
> ./pcap-sita.c:77: warning: 'errorString' defined but not used
> ./pcap-sita.c:86: warning: 'dump_interface_list' defined but not used
> ./pcap-sita.c:127: warning: 'dump_interface_list_p' defined but not used
> ./pcap-sita.c:147: warning: 'dump_unit_table' defined but not used
> ./pcap-sita.c:234: warning: 'find_nth_interface_name' defined but not used
> ./pcap-sita.c:375: warning: 'acn_freealldevs' defined but not used
>
> Does the fact that acn_freealldevs() isn't used mean that memory might
> leak?


Yes, this may be related to the bug I'll be investigating
(the remainder are debug/trace routines).

It may be a memory leak on the monitoring system, but it
appears to cause a catastrophic problem on the monitored
systems taking out no only monitoring, but their primary
functionality too (if abused).

For my testing, I'll start with the source I submitted,
and then forward port the changed into the SVN version.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.