) {/* is this an escape code ? */
+ppp_hdlc(p-1, length);
+return;
+}
+
switch (proto) {
case PPP_LCP:
case PPP_IPCP:
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace
because it makes your box
vulnerable to SYN flood attacks.
Regards
Karoly Kiss
-
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New
. For
Ethernet this is generally the SFD byte. I'm happy to discuss specifics
off-list if people are interested.
Stephen.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone
/ to unsubscribe.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
? It seems to
me that requiring the user to do their own explicit copies when required
is not unreasonable.
Regards,
Stephen.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd
packets to get the sizes on wire?
You can also add an unknown number of bytes of preamble (typ. 8), and 12
bytes of Inter-frame Gap if you like. Depends what you mean by 'On the
wire'.
Stephen.
--
---
Stephen Donnelly BCMS PhD
.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
the libpcap source)?
Thanks,
Don
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd
with this since programs that
are dependent on it (tcpdump, ethereal) hang when attempting to open
any such file. Is this assumption incorrect?
Thanks,
Don
On 3/19/06, Stephen Donnelly [EMAIL PROTECTED] wrote:
It may be worth noting (AFAIK) the libpcap file format is intended to be
opaque
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
as a special
case I have no problem, and Endace can support both linktypes.
Stephen.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton
new linktypes, just for such purpose ?
(I understood that the linktypes are coded on 4 bytes )
Regards
Florent
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd
.
Regards,
Stephen.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
of any recent independent test publications.
Regards,
Stephen.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand
On Thu, 2007-06-28 at 03:09 +, Jefferson Ogata wrote:
Stephen Donnelly wrote:
On Wed, 2007-06-27 at 22:00 +, 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
there are already 19 ERF types defined and
I feel this would unnecessarily consume/pollute the libpcap DLT
namespace.
Comments, questions, objections welcome.
Regards,
Stephen.
--
---
Stephen Donnelly BCMS PhD email
On Tue, 2007-08-07 at 16:55 -0700, Guy Harris wrote:
On Jul 25, 2007, at 1:57 PM, Stephen Donnelly wrote:
Florent Drouin from Alcatel-Lucent has been working on improving the
ERF
support in Wireshark. As part of this work we would like to request a
new DLT (DLT_ERF) which would
the statistics via the DAG
configuration and status API from your own software.
Regards,
Stephen.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
will also need to be
regenerated using the preferred autoconf version.
Stephen.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New
release!)
A release candidate sounds like a good idea. Could easily give it a week
or two to settle before finalising it.
Stephen
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd
.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
---
-
This is the tcpdump
On Thu, 2008-01-10 at 14:53 +1300, Stephen Donnelly wrote:
On Wed, 2008-01-09 at 17:25 -0800, Guy Harris wrote:
On Jan 9, 2008, at 3:37 PM, lei wei wrote:
I'm actually trying to get Argus working with DAG but argus still
can't read
anything from it.
From a quick look
.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
On Wed, 2008-07-30 at 20:07 -0700, Guy Harris wrote:
On Jul 30, 2008, at 2:12 PM, Stephen Donnelly wrote:
I recently came across some packets which tcpdump appears to display
incorrectly.
Is tcpdump incorrectly invoking some heuristic dissector, or is there
another reason?
I guess
.
# tcpdump --version
tcpdump version 3.9.8
libpcap version 0.9.8
Stephen
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New
.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
.
Visit https://cod.sandelman.ca/ to unsubscribe.
--
---
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64
.
--
---
Stephen Donnelly BCMS PhD email: s...@endace.com
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
---
-
This is the tcpdump-workers list
' of
network traffic. The inter-packet timing is preserved and regenerated
with high accuracy, typically orders of magnitude better than
software-only approaches.
Regards,
Stephen
--
---
Stephen Donnelly BCMS PhD email: s
git://github.com/sfd/libpcap.git
Updating Endace DAG ERF support.
--
---
Stephen Donnelly BCMS PhD email: s...@endace.com
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand
would be useful.
Stephen.
--
---
Stephen Donnelly BCMS PhD email: s...@endace.com
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
() and dag_detach_stream() to handle
mapping/unmapping.
Stephen.
--
---
Stephen Donnelly BCMS PhD email: s...@endace.com
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell
.
Regards,
Stephen
--
---
Stephen Donnelly BCMS PhD email: s...@endace.com
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
I have submitted a pull request to mcr's github tree.
https://github.com/mcr/libpcap/pull/1
There are 2 changes. The dag_platform_finddevs() function is updated to
improve the search space and efficiency.
Secondly the build process moves to 'pcap-config' for external library
dependencies
On 29/04/11 19:12, Guy Harris wrote:
On Apr 28, 2011, at 3:31 PM, Michael Richardson wrote:
Unless someone says that there is something else out there, I'm going to
write an (IPv4) pcap file anonymizer. I won't make the first version
efficient.
The Internet Traffic Archive has some
On 06/06/12 22:03, Guy Harris wrote:
On Jun 5, 2012, at 8:04 PM, Stephen Donnelly wrote:
I've posted an 'experimental' patch/hack to dumpcap in Bug #7300.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7300
The dumpcap implementation assumes that there is a one-to-one mapping between
Hi Guy,
In 2007 in libpcap afbb1ce7 you committed some code (possibly from Florent
Drouin) adding the LT_FCS_DATALINK_EXT mechanism to record whether the capture
includes information about captured FCS length, and if so what length it is.
I believe that currently only the DAG capture code
It appears that when Have non-interface modules take responsibility for
identifying their devices 2426611
https://github.com/the-tcpdump-group/libpcap/commit/2426611584e9099af5f98d18ef37337df9bef025
was committed, the heuristic for DAG device names was insufficient.
Hi, I have had a pull request in the queue on github since August:
https://github.com/the-tcpdump-group/libpcap/pull/378
This does include some ideally separate things, a bug fix, and some
improvements. Is there anything blocking this pull request? Is more information
required, or should I
Hi,
I see 1.9.0 is up to rc2 as of 25th June, how is it going? Is there anything we
can do to assist?
This fixes a serious bug in 1.8.1 for us, so keen to see a new release!
Regards,
Stephen
___
tcpdump-workers mailing list
40 matches
Mail list logo
