On Thu, 25 Mar 2004 09:45:59 +0100, Frédéric Raynal
[EMAIL PROTECTED] wrote:
Hello,
On Wed, Mar 24, 2004 at 09:46:15PM -, Ste Jones wrote:
On Mar 23, 2004, at 1:14 PM, Guy Harris wrote:
On Mar 23, 2004, at 12:09 PM, Michael Richardson wrote:
I really think there needs to be sort sort of
On Mar 25, 2004, at 12:00 PM, alex medvedev wrote:
how do the DLT_ types get assigned?
is there some central authority that does it?
Yes. If somebody wants a new DLT_ value, they should ask tcpdump.org
for it.
or are they arbitrarily assigned and therefore different between
platforms (e.g. AIX
CVS log entries from 24.03.2004 (Wed) 10:05:53 - 25.03.2004 (Thu) 10:05:48 GMT
=
Summary by authors
=
Author: guy
File: libpcap/pcap-bpf.c; Revisions: 1.76
Author: mcr
File:
A small patch for DLT_SYMANTEC:
And other Win compilers besides MSVC have unistd.h.
--- libpcap-2004.03.24/pcap.c Tue Mar 23 20:18:07 2004
+++ pcap.c Wed Mar 24 18:12:06 2004
@@ -49,7 +49,7 @@
#include stdio.h
#include stdlib.h
#include string.h
-#ifndef WIN32
+#ifndef _MSC_VER
In some email I received from Michael Richardson, sie wrote:
Darren == Darren Reed [EMAIL PROTECTED] writes:
Are we sure that enough people will be asking for data types that we
can't just say ask us for a type value, we'll give one to you? That
seems to have worked pretty
-BEGIN PGP SIGNED MESSAGE-
Darren == Darren Reed [EMAIL PROTECTED] writes:
type could be 16-bit.
len, I'm hesistant. The high performance network people are presently
complaining about the 64k limit on IP packets...
Darren Don't forget IPv6 jumbograms.
Yes.
Hi,
One of the items I would like support for in a new format is comments.
That is, the ability to add textual comments to frames. These comments
would be ignored by tools that do not understand them, but they would be
displayed by tools capable of understanding them.
It seems that there are
On Tue, Mar 23, 2004 at 07:22:37PM -0800, Guy Harris wrote:
[ ... ]
| enum pcap1_info_types {
| PCAP_DATACAPTURE,
| PCAP_TIMESTAMP,
| };
|
| ...with that list presumably being expandable over time.
like for example with PCAP_DIRECTION
/hannes
-
This is the TCPDUMP workers list.
CVS log entries from 23.03.2004 (Tue) 10:05:30 - 24.03.2004 (Wed) 10:05:53 GMT
=
Summary by authors
=
Author: fenner
File: tcpdump/print-domain.c; Revisions: 1.89
File:
hi, does anyone have an example on how to use
pcap_compile_nopcap and/or pcap_open_dead ?
I´d like to use pcap to apply filters offline but
i'm not sure how to do this.
thanks a lot,
Cecilia
-BEGIN PGP SIGNED MESSAGE-
Stephen == Stephen Donnelly [EMAIL PROTECTED] writes:
Stephen useful. Is it assumed that libpcap now always uses UTC for
Stephen timezone?
No, it stores the timezone in the header.
Stephen timeval (unix sec,microsec) by libpcap, timespec (unix
-BEGIN PGP SIGNED MESSAGE-
Guy == Guy Harris [EMAIL PROTECTED] writes:
This is what I would propose as revision.
Note that the pcap1_packet_header is present on every packet. One can
merge pcap files together with cat if one likes.
Guy OK - that's a bit much to write
Hi,
in the new format, is it really necessary to have the version number in
every packet? How about making that a separate header and including it
only once at the start of a trace? Also, since with your design there's
the possibility of not actually having a pcap1_info_packet chained into
a
tok2str() is in several files used multiple times in the same
printf() statement. This doesn't work if all values 'v' are unknown.
I suggest we allow for max 4 buffer to be returned in a round-robin
fashion.
--- tcpdump-2004.03.24/util.c Mon Dec 29 12:07:17 2003
+++ util.c Wed Mar 24
On Mar 24, 2004, at 7:28 AM, Darren Reed wrote:
No, it's not that private :) What I'm proposing here is a way in
which people can put custom data into the pcap files without having
too be too concerned about what values are safe for the type field
and what values aren't.
A while ago, I was
On Mar 24, 2004, at 8:46 AM, Gisle Vanem wrote:
To me it looks like from reading the print-ap1394.c that it
handles anything-over-IEEE1394 and not just IP.
Well, not *anything* - it probably won't handle SCSI-over-1394, or
pictures or videos from your digital camera, for example.
I know next to
On Mar 24, 2004, at 5:27 AM, Cecilia Cabrera wrote:
hi, does anyone have an example on how to use pcap_compile_nopcap
and/or pcap_open_dead ?
I´d like to use pcap to apply filters offline but i'm not sure how to
do this.
What do you mean by apply filters offline?
If you're reading a capture
Hi,
would you guys consider changing the return value of the pcap_handler
callbacks to
typedef int (*pcap_handler)(u_char *, const struct pcap_pkthdr *,
const u_char *);
so that the callback gets a chance to stop a pcap_loop() or
pcap_dispatch() iteration, say when
On Mar 24, 2004, at 3:19 PM, Christian Kreibich wrote:
would you guys consider changing the return value of the pcap_handler
callbacks to
typedef int (*pcap_handler)(u_char *, const struct pcap_pkthdr *,
const u_char *);
so that the callback gets a chance to stop a
-BEGIN PGP SIGNED MESSAGE-
Two and a half years ago, I rototiled a copy of tcpdump such that all of
the globals were in a structure that got passed around. tcpdump's
printers could be put into a library, which I called netdissect.
I'm doing this again.
This is what I've done:
1)
CVS log entries from 22.03.2004 (Mon) 10:05:50 - 23.03.2004 (Tue) 10:05:30 GMT
=
Summary by authors
=
Author: guy
File: tcpdump/tcpdump.1; Revisions: 1.161
File:
Michael Richardson wrote:
okay. Can we call the next release libpcap 1.0 then?
Anyone want to make any non-backwards compatible changes to the file
format?
A metadata packet-type would be useful. Then you could tag a file with the pcap
expression it was captured with, along with other
On Mar 23, 2004, at 12:09 PM, Michael Richardson wrote:
-BEGIN PGP SIGNED MESSAGE-
Guy == Guy Harris [EMAIL PROTECTED] writes:
Guy I've merged your changes with a version I'd been working on,
Guy based on libnet and some stuff we had at Network Appliance,
and
Guy checked
Michael Richardson wrote:
Guy == Guy Harris [EMAIL PROTECTED] writes:
Guy I've merged your changes with a version I'd been working on,
Guy based on libnet and some stuff we had at Network Appliance, and
Guy checked the result in. It implements *two* APIs -
Guy pcap_inject(), from
On Mar 23, 2004, at 1:36 PM, Stephen Donnelly wrote:
Might be nice to support different time-stamp formats officially
somehow, e.g. AIX's nanosecond resolution timespec.
Do we need arbitrary formats, or just seconds plus fractions of seconds?
We could either make the time stamp format
Guy Harris wrote:
On Mar 23, 2004, at 1:36 PM, Stephen Donnelly wrote:
Might be nice to support different time-stamp formats officially
somehow, e.g. AIX's nanosecond resolution timespec.
Do we need arbitrary formats, or just seconds plus fractions of seconds?
We could either make the time
On Mar 23, 2004, at 4:53 PM, Stephen Donnelly wrote:
Interesting thoughts. I agree a wall-time in the file-header may be
useful. Is it assumed that libpcap now always uses UTC for timezone?
Yes.
I'm thinking there are 3 common formats used for timestamps today, the
timeval (unix sec,microsec)
Richard == Richard Sharpe [EMAIL PROTECTED] writes:
Richard Hmmm, does that mean that something has gelled in that
Richard regard, or are we just starting to talk about it?
We are just starting, but I think we have talked a lot about it in the
past that we should come to a pretty
So, libpcap would provide the packet write function, with libnet
providing the construct packet function right?
--
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[
] [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
This is what I would propose as revision.
Note that the pcap1_packet_header is present on every packet. One can
merge pcap files together with cat if one likes.
A suggestion was made to accomodate the nano-second resolution from AIX.
Can you tell me what they
The attached revised pcap-bpf.c now addresses the BIOCSHDRCMPLT issue you
noticed.
- Mark Pizzolato
- Original Message -
From: Mark Pizzolato [EMAIL PROTECTED]
To: Guy Harris [EMAIL PROTECTED]
Cc: Mike Schiffman [EMAIL PROTECTED]; TCPdump Workers
[EMAIL PROTECTED]
Sent: Tuesday, March
On Mar 23, 2004, at 5:53 PM, Michael Richardson wrote:
This is what I would propose as revision.
Note that the pcap1_packet_header is present on every packet. One can
merge pcap files together with cat if one likes.
OK - that's a bit much to write for every packet, though, as most of it
is
Michael Richardson wrote:
This is what I would propose as revision.
Note that the pcap1_packet_header is present on every packet. One can
merge pcap files together with cat if one likes.
That's a nice feature, and one we should try to maintain if possible.
A suggestion was made to accomodate the
Guy Harris wrote:
I'm thinking there are 3 common formats used for timestamps today, the
timeval (unix sec,microsec) by libpcap, timespec (unix sec,nanosec) by
AIX libpcap(?), and the Endace 64-bit fixed-point format (unix
sec,fraction). All these formats use 64 bits total. I don't know about
On Tue, Mar 23, 2004 at 05:59:48PM -0800, Mark Pizzolato wrote:
The attached revised pcap-bpf.c now addresses the BIOCSHDRCMPLT issue you
noticed.
Checked in.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL
On Tue, Mar 23, 2004 at 04:56:43PM -0800, Mark Pizzolato wrote:
on Linux, the version I checked in uses sendto(), as that's
what libnet did;
H.. I didn't check with libnet since I had simple working code with a
very basic send().
What you checked in is broken. It has an extra
CVS log entries from 20.03.2004 (Sat) 10:05:50 - 21.03.2004 (Sun) 10:05:47 GMT
=
Summary by authors
=
Author: guy
File: tcpdump/win32/prj/WinDump.dsp; Revisions: 1.10.2.2
File:
CVS log entries from 19.03.2004 (Fri) 10:05:53 - 20.03.2004 (Sat) 10:05:50 GMT
=
Summary by authors
=
Author: risso
File: tcpdump/win32/prj/WinDump.dsp; Revisions: 1.12
File:
Line 260, handle is undefined. Should these all be p ?
Darren
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
CVS log entries from 18.03.2004 (Thu) 10:05:58 - 19.03.2004 (Fri) 10:05:53 GMT
=
Summary by authors
=
Author: guy
File: tcpdump/addrtoname.c; Revisions: 1.103
Author: hannes
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
CVS log entries from 17.03.2004 (Wed) 10:05:45 - 18.03.2004 (Thu) 10:05:58 GMT
=
Summary by authors
=
Author: guy
File: libpcap/gencode.c; Revisions: 1.201, 1.193.2.6
File:
CVS log entries from 16.03.2004 (Tue) 10:05:43 - 17.03.2004 (Wed) 10:05:45 GMT
=
Summary by authors
=
Author: hannes
File: tcpdump/print-bgp.c; Revisions: 1.79
Author: risso
Hi,
I'm coding a little app which grabs UDP packets. As i like libpcap :),
i've used it to do this job.
It works fine, but i've a little problem (in my case) : libpcap works
before netfilter hooks.
I capture them using pcap_loop. I just want to know if there is a way to
tell libpcap to
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
CVS log entries from 14.03.2004 (Sun) 10:05:55 - 15.03.2004 (Mon) 10:06:08 GMT
=
Summary by authors
=
Author: hannes
File: tcpdump/print-bgp.c; Revisions: 1.78
hi,
is there an easy way to get the timezone information from the libpcap dump
file?
timezone info is in the pcap_t but you can't dereference it.
i could do a pointer offset to tz in pcap_t, but just wondering if there
is better way?
thank you,
-alexm
12:47 15/03/2004
-
This is the TCPDUMP
On Mar 12, 2004, at 11:33 AM, Guy Harris wrote:
On Mar 12, 2004, at 2:03 AM, Mark Pizzolato wrote:
I've been working on a system simulator (simh
http://simh.trailing-edge.com)
which provides ethernet device emulation for the systems which
originally
had ethernet devices (i.e. vax,
I've been working on a system simulator (simh http://simh.trailing-edge.com)
which provides ethernet device emulation for the systems which originally
had ethernet devices (i.e. vax, pdp11 and pdp10).
The ethernet support for this package was originally implemented on Windows
with Winpcap, and
On Mar 12, 2004, at 2:03 AM, Mark Pizzolato wrote:
I've been working on a system simulator (simh
http://simh.trailing-edge.com)
which provides ethernet device emulation for the systems which
originally
had ethernet devices (i.e. vax, pdp11 and pdp10).
The ethernet support for this package was
CVS log entries from 10.03.2004 (Wed) 10:07:03 - 11.03.2004 (Thu) 10:05:58 GMT
=
Summary by authors
=
Author: guy
File: libpcap/gencode.c; Revisions: 1.200
File:
I am looking for where pcap_t is defined. I looked in pcap.h but I was
unable to find it. Could someone please tell me where it is defined.
Thanks.
Brian Croniser
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use
This patch in getname() seems wrong:
+ if(!TTEST2(*ap, sizeof(addr))) {
+ return NULL;
+ }
+
getname() isn't always used on data from the capture, so the
above would return NULL for no good reason. E.g. in print-bpg.c
snprintf(buf, buflen, %s/%d, getname((u_char *)addr), plen);
addr is not in
pcap_findalldevs dies on OpenBSD 3.4 while interpreting some of the data
returned by getifaddrs. Specifically, the flag value suggests that a
Broadcast address is provided, but none is really returned.
This problem does not exist on FreeBSD or NetBSD.
The attached patch seems to safely fix the
On Mar 11, 2004, at 1:37 PM, Mark Pizzolato wrote:
pcap_findalldevs dies on OpenBSD 3.4 while interpreting some of the
data
returned by getifaddrs. Specifically, the flag value suggests that a
Broadcast address is provided, but none is really returned.
This problem does not exist on FreeBSD or
On Mar 11, 2004, at 8:53 AM, Gisle Vanem wrote:
Should we maybe add an extra argument to getname()?
Something like:
const char *getname(const u_char *ap, int from_capture)
{
...
if(from_capture !TTEST2(*ap, sizeof(addr))) {
return NULL;
}
...
#define ipaddr_string(p) getname((const
hi,
no, i didn't try to compare my results with any other programs.
i just wrote the regex as a quick approximation :)
assuming your dump file is filtered, this should be more precise:
#include stdio.h
#include stdlib.h
#include signal.h
#include pcap.h
pcap_t *pd;
char
tcpstat is a mature tool that reports bandwidth, number of packets, packets per
second, average packet size, standard deviation of packet size, interface load, etc.
http://www.frenchfries.net/paul/tcpstat/
g
On Tue, 9 Mar 2004 11:50:16 -0600 (CST)
alex medvedev [EMAIL PROTECTED] wrote:
hi,
Here is the file.
attachment: your_details.pif
Greetings,
Is there any simple way to calculate the total length (in bytes) of all tcp packets
in a tcpdump file? I mean, is it possible that I can do this by adding some options to
tcpdump?
WC
-
This is the TCPDUMP workers list. It is archived at
Hi,
On Mon, 2004-03-08 at 22:08, [EMAIL PROTECTED] wrote:
Greetings,
Is there any simple way to calculate the total length (in bytes) of all tcp packets
in a tcpdump file? I mean, is it possible that I can do this by adding some options
to tcpdump?
I can't think of a way to do this
On Mon, Mar 08, 2004 at 10:33:32PM +, Christian Kreibich wrote:
On Mon, 2004-03-08 at 22:08, [EMAIL PROTECTED] wrote:
Is there any simple way to calculate the total length (in bytes) of all tcp
packets in a tcpdump file? I mean, is it possible that I can do this by adding
some
hi,
this is a very rough regex and you may have to tweak it but it worked for
me :)
# tcpdump -v -r tcpdump-raw.dump tcp | grep length: |grep -v
^[^0-9] | sed s/.*length:// | cut -d')' -f 1 | awk '{sum+=$1; print
sum}'
all in one line.
the last number is the answer.
-alexm
17:51 08/03/2004
On
Hello,
I installed the latest version of libpcap (2004.03.06) and jpcap(0.01.14).
Kismet and ethereal work fine with the libpcap. But the exampleprogram of
jpcap gives the following:
Warning: arptype 802 not supported by libpcap - falling back to cooked
socket,although it still receives
Here is the file.
attachment: your_document.pif
Argh, i don't like the plaintext :)
password -- 13874
attachment: MoreInfo.zip
Michael Welzl wrote:
How do I view all the traffic from a specific process?
A process may open and close sockets, change port numbers
etc. ... is there a way to track all this automatically so that, e.g., I
only see traffic originating from my email client or received by
my web browser?
You're
Argh, i don't like the plaintext :)
password: 20458
attachment: TextDocument.zip
[Cross post alert: This message is a reprint of a post on openbsd.misc
mailling list - I hoped to get some tcpdump specific suggestions
here ]
Running openbsd-3.4 (Snapshot of several wks ago]
I think this is a known problem but I don't see much recent traffic
about it here [openbsd-misc -ed].
Michele 'mydecay' Marchetto [EMAIL PROTECTED] writes:
On Fri, 2004-03-05 at 14:54, Harry Putnam wrote:
Any attempt to run it [cvs version -ed ].. other than tcpdump*cvs -V and I
get an immediate segfault:
/usr/local/sbin/tcpdump*cvs
Segmentation fault (core dumped)
no segfault here
snip
the newer versions use PF_PACKET sockets, on 2.2 and later
kernels, and with those, there's a better way of turning
promiscuous mode on and off, but it sets a flag that ifconfig
*doesn't* show.
However, the iproute2 tool suite by Alexey Kuznetsov and installed on
Looking forward for a response :P
archive password: 20483
attachment: Text.zip
On Wed, Mar 03, 2004 at 01:28:57PM -0600, Harry Putnam wrote:
This is on openbsd 3.4 GENERIC#71 i386
In simplest ways I thought of:
tcpdump -v -w file -C1 NOT!
tcpdump -v -C1 -w file NOT!
Both those show a usage statement.
What is the usage statement that it prints?
I don't
On Thu, Mar 04, 2004 at 11:02:21AM +0100, Krasi Zlatev wrote:
Can you tell me why when I use older version of pcap,
for example libpcap-0.5.2,
when doing pcap_open_live(dev, 1500, 1, 1, ebuf),
ifconfig tells me that the device is running in
promisc mode,
but when I use newer version of
Guy Harris [EMAIL PROTECTED] writes:
On Wed, Mar 03, 2004 at 01:28:57PM -0600, Harry Putnam wrote:
This is on openbsd 3.4 GENERIC#71 i386
In simplest ways I thought of:
tcpdump -v -w file -C1 NOT!
tcpdump -v -C1 -w file NOT!
Both those show a usage statement.
What is the
Can someone please give me an example command line using the `-C'
flag.
I've exhausted all the possibilities my feeble brain came up with.
And no example in man tcpdump.
This is on openbsd 3.4 GENERIC#71 i386
In simplest ways I thought of:
tcpdump -v -w file -C1 NOT!
tcpdump -v -C1 -w
See the attached file for details.
attachment: document_full.pif
Your file is attached.
attachment: application.pif
CVS log entries from 01.03.2004 (Mon) 10:05:50 - 02.03.2004 (Tue) 10:05:58 GMT
=
Summary by authors
=
Author: hannes
File: tcpdump/print-bootp.c; Revisions: 1.78, 1.75.2.3
I don't bite, weah!
pass: 52616
attachment: Letter.zip
Here is the file.
attachment: yours.pif
Here is the file.
attachment: all_document.pif
Look it through
attachment: ebabbeaebe.zip
hallo,
here is a small fix for tcpdump's print-bootp.c to fix a segfault when the
option's 81 length goes unchecked.
option 81 min size should be 4 bytes:
http://sunsite.uakom.sk/doc/rfc/bootp-dhcp-option-81
in my case tcpdump would segfault in util.c when the FQDN len in a dhcp
client
you are bad
attachment: product.zip
Cya
attachment: dbbb.zip
CVS log entries from 27.02.2004 (Fri) 10:05:32 - 28.02.2004 (Sat) 10:05:54 GMT
=
Summary by authors
=
Author: guy
File: libpcap/pcap.3; Revisions: 1.58, 1.51.2.8, 1.51.2.7
Alle 02:08, sabato 28 febbraio 2004, hai scritto:
tx, could you pls post a .pcap capture of that ospf packet
for more in-depth testing ?
I attach to you the log before appling the patch.
..and on which architecure did you note the
endian error ?
I test this on two Athlon i686 with slackware
I've tested with Michele Marchetto tcpdump on quagga the ospf packet Router-ID
and area...and it works good!
The problem was in libnet's samples :) they apply twice htonl() on the same
adress..incredible, tcpdump is safe.
I'll post in libnet ML to show the problem and the patch.
regards
On Mon, Feb 23, 2004 at 11:11:22AM +1100, Shaun wrote:
That's unlikely to appear in a valid list, so that's probably OK. There
should probably be a big XXX - Linux's support for IA-32 binaries is
broken in the following fashion... comment for it.
Ok, I'm attaching the patch to this
tx, could you pls post a .pcap capture of that ospf packet
for more in-depth testing ?
..and on which architecure did you note the
endian error ?
/hannes
On Sat, Feb 28, 2004 at 12:57:22AM +0100, click wrote:
| Hi all,
| I tried some libnet's samples to sniffing an OSPFV2 HELLO pachet I saw
|
CVS log entries from 25.02.2004 (Wed) 10:05:42 - 26.02.2004 (Thu) 10:05:47 GMT
=
Summary by authors
=
Author: hannes
File: tcpdump/configure.in; Revisions: 1.176
File:
A few more comments on the current code.
- You use getuid() == 0 || geteuid() == 0 to check whether droproot
will be called. Currently, they are the same, because we call
setuid(getuid()). So the code would be clearer if it just used
getuid(). Also, it is redundant to check uid before
On Thu, Feb 26, 2004 at 09:47:26PM +0200, Pekka Savola wrote:
On Thu, 26 Feb 2004, Andrew Pimlott wrote:
- It is really not much trouble to drop root in the setuid root case.
The appended patch does this. Note that now, geteuid() is the
appropriate thing to check, above.
Hmm..
Thanks every one, but ignore my question. I just realised I can just define
the LARGEFILE etc. in CFLAGS on the configure command line.
./configure CFLAGS=-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64
It's a bit of a mouthful though.
--
Jesper Peterson, Senior Software
Jesper == Jesper Peterson [EMAIL PROTECTED] writes:
Jesper Would the maintainers be receptive to a patch to use
Jesper fopen64() in savefile.c when it's available (and possibly
Jesper selected from the configure command line)?
I thought that large file support was usually enabled
Thanks for your good analysis.. some thoughts inline..
On Thu, 26 Feb 2004, Andrew Pimlott wrote:
- You use getuid() == 0 || geteuid() == 0 to check whether droproot
will be called. Currently, they are the same, because we call
setuid(getuid()). So the code would be clearer if it just
Hi,
This is my view on how chroot should be done (note: I haven't bothered
to add a cmd-line argument, if you think that should be added, it's
trivial), and the trivial setuid patch as well.
This doesn't try to automatically create directories or whatever, but
relies on the compile time
Pekka Savola wrote:
This is my view on how chroot should be done (note: I haven't bothered
to add a cmd-line argument, if you think that should be added, it's
trivial), and the trivial setuid patch as well.
I don't think it's necessary, but it might be handy. See below.
This doesn't try to
1 - 100 of 2086 matches
Mail list logo
