On Jan 6, 2008 3:40 PM, Guy Harris <[EMAIL PROTECTED]> 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.
