f you have enough sense to configure
all your systems in UTC. Let users set TZ in their .profiles if they want to see
a local zone.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
And so on... mull it over for a minute before you start shredding.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
an
<[EMAIL PROTECTED]>, which is the advertised address of
the list?
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
other esoterica that are sounding a bit archaic in today's computing
environment. I think we should take a hard look at whether it's really
appropriate to define yet another hard binary file format when XML can provide
the same functionality with modest storage overhead, and has many added be
Fulvio Risso wrote:
[mailto:[EMAIL PROTECTED] Behalf Of Stephen
Donnelly
Jefferson Ogata wrote:
Yes, fully fledged decoded captures would use a lot of extra
disk, but a
raw no-frills capture could be recorded with maybe only 50% or
so overhead.
50% extra space and 50% extra disk bandwidth cost
ition: i.e.
your statement is a tautology.
If you store in XML, then many applications could read pcap files, because they
wouldn't /have/ to use libpcap.
I think XML is the 21st centurys response to C++.
I have no idea what you mean by that...
--
Jefferson Ogata <[EMAIL PROTECTED]&g
re like 5 to 20.
NO xml in the kernel where pcap lives.
Huh? BPF lives in the kernel, on some platforms. pcap, and its file format, live
in userland.
Also, some people actually work with pretty large files containint 10's of
milions of packets.
Indeed. I am one of them. So what?
--
Jeffer
st
to the old address...
- Why does the list set Reply-To: to <[EMAIL PROTECTED]>
instead of <[EMAIL PROTECTED]>?
- What's with the weird regex restrictions on postings?
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
ems a bit awkward.
A webserver directory index would be fine, especially if accompanied by an
inline README.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
ut libpcap is primarily about packet
capture.
I disagree, at least in the sense in which you appear to mean this.
libpcap includes BPF and the pcap expression compiler, which are about
packet filtering. And remember that this is the tcpdump-workers list.
--
Jefferson Ogata <[EMAIL PROTECTED]&g
than having userland do it. Can you
describe such a scenario?
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
re-sort the
input addresses before passing the filter to the compiler. Put the addresses
into a balanced, sorted binary tree and then use a recursive >= operation. The
optimizer does not handle this.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CI
into a short and long and doing the byte-order switch at
the same time.
BTW, packet dissectors are especially easy to write in Perl, using the unpack
function, and are then invulnerable to pesky buffer overflows. Just install
Net::Pcap.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Co
s far more than simply having it run as a
regular user. While it's true that some OSes are sorely behind the times and
don't support capabilities, it's still useful to have the infrastructure in
place for the modern ones that do.
--
Jefferson Ogata <[EMAIL PROTECTED]>
N
cific?) capabilities. I'm not sure if it's
Pekka> necessary when we already drop the root privileges.
Yes, they are Linux specific.
We should have a file:
droppriv-FOO.c
IRIX, for one, also supports capabilities.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA C
s.
It would seem to me that the best approach would be to have a format
configuration file when an entry for each dissected protocol. Local
installations could tweak it however they like.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECT
hard as it might seem at first.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
d
packet header, especially for captured ethernet data. The link headers are
unmistakable.
Once you've found a sync point, you just need to strip out the data from the
start of the problem area to your sync point.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Tea
/bpf*
devices and not on super user mode. Normally /dev/bpf* is only readable
by root, but you can change this.
More specifically, you can use libpcap as any user. On most systems, you have to
be root, however, to monitor traffic on a network interface.
--
Jefferson Ogata <[EMAIL PROTECTED]>
you have to be more careful about
intercepting all subnodes with another template; otherwise you get all the text
nodes in the subtree instead of just the topmost one. When everything is marked
up as attributes, you just do and you're done.
--
Jefferson Ogata <[EMAIL PROTECTED]>
);
strcat(d_ip_packet->src_ip_address,"\0");
5. And here?
d_ip_packet->sequence_number = ntohl(tcp->th_seq); // BUG HERE!
sequence number is not correct
6. Not correct, but how? Unrelated? Byte-swapped? Shifted?
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Compu
Claudio Lavecchia wrote:
Jefferson Ogata wrote:
Claudio Lavecchia wrote:
I am using a libpcap based packet dissector to sniff WLAN traffic:
I read tcp packets using the structure:
struct sniff_tcp {
u_short th_sport; /* source port */
u_short th_dport
GET, but can N be an expression itself, e.g. the data offset
in the
TCP header??
Yes.
tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Robert Lowe wrote:
Jefferson Ogata wrote:
tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420
Beautiful! But wouldn't the bit-shift be for 4 bits? Thanks
It would, but then you'd have to multiply by 4 since the offset is in
multiples of 4. So >> 2 does the shift and
ptcpdump.pl src`
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
#!/usr/bin/perl -wT
my $low = shift;
my $high = shift;
die "usage: $0 low-addr high-addr" unless (defined ($high));
$low = &a2n ($low);
$high = &a2n ($hi
Jefferson Ogata wrote:
MMatos wrote:
I want to write a little program that analyses packets within a given
ip range.
My current problem is to set a filter that work with ip ranges.
For example I want to dump all traffic that arrives to my box from ips
192.168.2.15 to 192.168.2.40
I could write
MMatos wrote:
Jefferson Ogata wrote:
Jefferson Ogata wrote:
MMatos wrote:
For example I want to dump all traffic that arrives to my box from
ips 192.168.2.15 to 192.168.2.40
I could write all the ips in the range but that's not a good
solution, so how can implement that filter correctly
MMatos wrote:
Note: I'm resending this message because i've sent it 20 hours ago and
it wasn't arrived to the list (at least i wasn't received it yet).
I saw it yesterday.
Alexander Dupuy wrote:
Jefferson Ogata wrote:
Or you can do something more utilitarian, such as:
tcpdum
te a BPF-to-MTP assembler/compiler,
crunch the result of pcap_compile(), and stuff that into the interface.
This would be a lot easier than hacking on the code generator.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the
DHCP.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
$format = sprintf ("\t%%-%ds", $maxLen);
}
printf ($format, $_);
s/\s//g;
s/([0-9a-f]{2})/chr (hex ($1))/eg;
s/[^\040-\176]/./g;
print "\t$_\n";
}
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Jefferson Ogata wrote:
> This is so obvious a feature that is truly incredible no one has added
> it to tcpdump in all these years. It's no wonder someone would be
> curious that the man page doesn't mention it.
>
> I recommend using ethereal or tethereal, since they
t; Is this behaviour expected?
When you perform live analysis, you may also be capturing DNS and other
related traffic initiated by tcpdump itself. When writing to a file, no
protocol analysis is done, so this traffic is absent.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Re
ters to my xterm/shell. Any ideas?
Escape all non-printing characters, especially anything outside [\040-\176].
If you are passing arbitrary binary data to your terminal, an attacker
may be able to instruct your terminal to insert characters into your
terminal stream to execute arbitrary commands
client system has to send a SYN packet to even find out whether
something's listening.
Either there's something wrong with you capture program, you have a
firewall in the way, or you're capturing on the wrong interface.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Comput
traffic is routed over the loopback interface. Perhaps you
were not sniffing loopback.
Top-posting is evil.
> Quoting Jefferson Ogata <[EMAIL PROTECTED]>:
>>[EMAIL PROTECTED] wrote:
>>>Heya everyone, I'm trying to build a port knocker for fun using pcap and
>>basi
I doing something wrong or is this a bug that I've found?
If you want to see traffic that involves both networks, use "net 10.4.4
and 10.4.1".
Or, if you want to see traffic leaving 10.4.4 bound for any other
destination, use "not dst net 10.4.4".
> _
gt; libnet and get a reply using pcap, but the connection-initiating TCP seems
> to be generating a RST on my behalf before I can transmit the third packet
> of the handshake.
Is there some reason you don't simply synthesize packets using an IP
address that doesn't belong to a box on th
Ethereal's editcap and mergecap might accomplish pretty much
the same thing.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On 03/20/2006 02:01 AM, Don Morrison wrote:
[top posting fixed again]
> On 3/19/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:
>>
>>The trivial way to fix a truncated pcap file:
>>
>>tcpdump -r broken.pcap -w clean.pcap
>
> I tried this method, but it
ain messages, so it's not as if you
will then be able to use other existing tools to analyze the traffic,
since your messages aren't IP packets.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to r
time_t tv_sec;/* seconds */
suseconds_ttv_usec; /* microseconds */
};
> i like calculating jitter in RTP streams.
I like jittering calculators in REM dreams.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL
posted
2006/03/20 09:56 UTC?
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On 03/20/2006 04:18 AM, Don Morrison wrote:
[top posting fixed YET again]
> On 3/20/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:
>>On 03/20/2006 02:01 AM, Don Morrison wrote:
>>[top posting fixed again]
>>>I tried this method, but it hangs tcpdump.
>>
>>
gt; Unfortunately, I cannot send you the pcap file because it would be a
> violation of my contract with the telecom I work for.
Understood.
> Thanks very much for your help.
No problem.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
output?
>> Like wise , are there any other assumptions ? or it is impossible to
>> get the
>> same output on different systems?
>>
>> Thanks in advance.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
process is already ptracing the
target process.
> or 2. how to use libpcap without require the program to run with root
> privlidges?
AFAIK on Linux this is not possible.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
&q
On 05/26/2006 11:24 AM, Scott Krall wrote:
> I'm looking for an rpm for tcpdump that will run on a Red Hat Linux 7.2
> system
Well, you can download and build the SRPM for tcpdump for RHEL 2.1AS
from Red Hat.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Resp
ement a callback opcode in the BPF engine, and do the packet
inspection in userland. If I did it again, I might do it differently,
but it works.
My main point in all this, however, is that when you start digging, the
question of "which subrule" is somewhat more subtle than it might seem
at first.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
OTECTED] test]# ls -l
> total 984
> -rw-r--r--1 root root 1000531 Sep 13 11:36 test.cap
> [EMAIL PROTECTED] test]#
>
> Any ideas ?
The directory needs to be writable by the local tcpdump user, which may
be "pcap".
--
Jefferson Ogata <[EMAIL PROTECTED]>
in parallel.
>
> The keyword inbound cannot be used with link level.
> Which tcpdump expression solves the problem?
Have you tried
left window: not ether src mac:addr:of:eth0
right window: not ether src mac:addr:of:eth1
?
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Inci
On 2006-10-23 15:13, [EMAIL PROTECTED] wrote:
> Jefferson Ogata wrote:
>> Have you tried
>>
>> left window: not ether src mac:addr:of:eth0
>> right window: not ether src mac:addr:of:eth1
>
> Hello Jefferson,
>
> thanks for the quick response.
> Is there
ctions. There's still an upper bound, but
the default value is much lower.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
-
This is the
sts/workers/2004/05/msg7.html
Well, this gives me the urge to quote Steven Wright: "I'm having deja vu
and amnesia at the same time." :^)
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try
in the header information in question.
>>
>> Libpcap, however, won't do it for you; you will have to do it yourself.
>> -
> libtrace from our research group might be able to help:
> http://research.wand.net.nz/software/libtrace.php
Um, gee, is no one going to su
captured, or it might have been written by something other than libpcap.
Is it possible they were the result of combining multiple pcaps via
something like mergecap?
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never tr
On 2006-12-04 15:03, Harley Stenzel wrote:
> On 12/1/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:
>> Is it possible they were the result of combining multiple pcaps via
>> something like mergecap?
>
> It would seem that for something like this to be generally u
uncated
packets in the past, but turning off that behavior now is possibly
dangerous.
So, having said all that, I'll stay on the fence on this one.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrie
, I could go either way. But I think there is a potential problem.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
ofile of your network traffic you could then estimate the
average number of BPF instructions spent on each packet.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
tion: "wireshark -r
pcap-file-containing-captured-traffic". Or just start wireshark with no
arguments and go to the file menu to open your capture file.
You don't need a virtual NIC. RTFM.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMA
> 2].
You can do similar machinations for UDP or what have you.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
se a box with
a couple of dual-port PCIe Gb NICs (Endace or nPulse) and dual quad-core
processors could come to 4Gb/s aggregate capture speed, while writing
some packets to disk. Has anyone out there put together such a box and
come up with some performance statistics?
--
Jefferson Ogata <[EM
Stephen Donnelly wrote:
> On Wed, 2007-06-27 at 22:00 +0000, Jefferson Ogata wrote:
>> some packets to disk. Has anyone out there put together such a box and
>> come up with some performance statistics?
[snip]
> Endace also offers disk capture appliances which provide this leve
our octets, use:
tcp[((tcp[12:1] & 0xf0) >> 2):4 + 4] = 0xdeadbeef
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
-
This is the tcpdump-wo
On 2008-01-17 18:37, Jefferson Ogata wrote:
To get the next four octets, use:
tcp[((tcp[12:1] & 0xf0) >> 2):4 + 4] = 0xdeadbeef
Sorry, that latter case should have been:
tcp[(((tcp[12:1] & 0xf0) >> 2) + 4):4] = 0xdeadbeef
--
Jefferson Ogata <[EMAIL PROTECTED]&
code to generate.
There's really no need. The BPF engine can certainly be protected
against this. E.g. count each BPF instruction you execute and bail after
a threshold is reached. On bailing, you could also detach the filter, if
you want to set a very high threshold.
--
Jefferson Ogata &l
ually exist for
filter specifications. It is not sufficient to describe a capture file
as simply "pcap".
But what I think is missing is a version number. Given the talk in
recent years about implementing the next version, I think the type
should be application/pcap-capture-v1.
rately surprised if ng ever comes
to fruition, frankly.
--
Jefferson Ogata
NOAA Computer Incident Response Team (N-CIRT)
"Never try to retrieve anything from a bear."--National Park Service
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On 2008-12-13 01:17, Guy Harris wrote:
On Dec 12, 2008, at 5:02 PM, Jefferson Ogata wrote:
I still think current and "ng" pcap formats should be distinguished in
MIME type name.
So do I, which is why I said it'd be something such as
application/pcap-ng-capture.
I was resp
a/tcpdump-4.0.0# tcpdump -i ra0 port bootps -vvv
> tcpdump: listening on ra0, link-type EN10MB (Ethernet), capture size 96
> bytes
Try bumping up your snapshot size with the -s option.
--
Jefferson Ogata
NOAA Computer Incident Response Team (N-CIRT)
"Never try to retrieve anything fr
mostly irrelevant zone data as metadata is
so that it can be recorded when pcap timestamps are UTC, as they always
should have been. I'd like to find the person who decided to store
localtime instead of gmtime in the pcap timestamp field and smack him or
her with a large sock filled wit
On 2009-05-15 03:10, Guy Harris wrote:
> On May 14, 2009, at 7:20 PM, Jefferson Ogata wrote:
>> But the point of storing the mostly irrelevant zone data as metadata
>> is so that it can be recorded when pcap timestamps are UTC, as they
>> always should have been. I'd l
On 2009-05-15 18:20, Guy Harris wrote:
On May 15, 2009, at 12:43 AM, Jefferson Ogata wrote:
This has come up before, back when we were talking about the NG format.
I guess I got confused by the current context; if pcap files are
natively UTC (which I had thought they were until this thread
gt;
> Any feedback is very appreciated!
See urlsnarf:
http://monkey.org/~dugsong/dsniff/
I don't think it does POST data but it may be a good starting point.
--
Jefferson Ogata
National Oceanographic Data Center
You can't step into the same river twice. -- Herakleitos
-
This is th
75 matches
Mail list logo
