Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
Hi,
On Thu, May 07, 2020 at 01:05:19AM -0700, Guy Harris wrote:
> A mechanism where you could do something such as "-T tcp:1073:{protocol}"
> to force traffic to TCP port 1073 to be dissected as the specified
> protocol might be useful; in this case, we'd do something such as
> "-T mpls:{protocol}" to force *all* MPLS packets to be dissected
> as the specified protocol, and "-T mpls:{label}:{protocol}", to
> force packets with a particular label to be dissected as the specified
> protocol (which might mean you'd have to run tcpdump twice - once
> to see what the label is, and once to decode the label.
I find this to be a fairly complex solution, at least for my use case.
I know what I'm looking at ("tcpdump -s0 'label 12003'"), it's just
tcpdump not knowing what these packets are - so for these simple cases, a
"-T mplsnocweth"
"-T mplscweth"
(or whatever it's called in the end) would be sufficient. The documentation
would need updating to make clear what happens behind the scenes ("this
forces some of the dissectors to decode the packet in a particular way",
and then possibly explain for each -T value to what sort of packets it applies)
OTOH, as a long-term road map, why not :-)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Thu, May 07, 2020 at 03:39:07AM -0400, Francois-Xavier Le Bail via tcpdump-workers wrote: > What if the first nibble is <> de 4, 6, 1, 0, e.g. 'f' like the first f of > ff:ff:ff:ff:ff:ff ? This is, as far as I understand, the primary reason why control word was added. Routers misinterpretation these packets due to MAC addresses starting with "4" or "6". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
Hi,
On Wed, May 06, 2020 at 11:54:55PM -0700, Guy Harris wrote:
> OK, so what *shark's MPLS dissector does is:
[..]
> "Looks like a valid Ethernet address" is defined as "the first three octets
> appear in Wireshark's file giving manufacturer names for OUIs". Tcpdump
> *currently* doesn't have such a file.
So, how do we/you want to handle this in tcpdump then? "-T mplsnocw"
for "mpls, ethernet, no control word" and "0 means control word", as
proposed by Francois-Xavier?
(Of course this would need a man page patch as well :) )
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
Hi,
On Thu, May 07, 2020 at 08:20:40AM +0200, Francois-Xavier Le Bail wrote:
> Proposed patch attached.
>
> With new '-T mplsethnocw' option to force 'Ethernet without Control Word'
> decode.
> (from Francesco Fondelli comment)
There's one bug here:
> + case 0x00: /* RFC 4448 PW Ethernet Control Word */
> + if (ndo->ndo_vflag) {
> + ND_PRINT("\n\tPW Ethernet Control
> Word");
> + p += 2;
> + ND_PRINT(", Sequence Number %u",
> GET_BE_U_2(p));
> + p += 2;
> + } else
> + ND_PRINT(" PWETHCW");
> + p += 4;
> + length -= 4;
Due to missing {}, the "p += 4" will always be executed, skipping the
control word twice if "-v" is set.
I'd totally leave off printing the "PWETHCW", though. If it's decoding the
payload, that is all information I need - if I want more, I can always
do "-v".
So the code would become:
+ case 0x00: /* RFC 4448 PW Ethernet Control Word */
+ if (ndo->ndo_vflag) {
+ ND_PRINT("\n\tPW Ethernet Control
Word");
+ ND_PRINT(", Sequence Number %u",
GET_BE_U_2(p+2));
+ }
+ p += 4;
+ length -= 4;
+ pt = PT_ETHER;
+ break;
There's something else:
+ case PT_ETHER:
+ ether_print(ndo, p, length, ND_BYTES_AVAILABLE_AFTER(bp), NULL,
NULL);
This might actually be a bug in my original patch, ND_BYTES_AVAILABLE_AFTER()
should possibly call "(p)", not "(bp)". Copy-pasted that line from
print-gre.c, and only changed the first "bp" to "p.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Tue, May 05, 2020 at 08:47:04PM +0200, Francois-Xavier Le Bail wrote: > > So, given that the first 16 bits are "4 bit always 0, and 12 bits > > reserved-must-be-set-to-0", using these as heuristics for "if two 0-bytes > > are following the MPLS headers, it's a control word, so we skip 4 bytes > > and the rest is a regular Ethernet packet" should work. > > We should print "PW Ethernet Control Word" and the "Sequence Number", 2 last > 2 octets of the 4. > Like: > PW Ethernet Control Word, Sequence Number xxx I think we should only print this if "-v" is given. Most of the time, both control word and sequence number are of little interest. I really like tcpdump's very compact "only the most relevant info" output format (by default). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
Hi,
On Tue, May 05, 2020 at 07:28:28PM +0200, Francois-Xavier Le Bail wrote:
> On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote:
> > In my case, there is an MPLS control word before the ethernet header
> > (" "), and if I skip that and just clear "ethernet in here", I
> > get nicely printed packets...
>
> It seems it is like:
> https://tools.ietf.org/html/rfc4448#section-4.6
>
> Can you confirm?
This very much looks like it, indeed.
So, given that the first 16 bits are "4 bit always 0, and 12 bits
reserved-must-be-set-to-0", using these as heuristics for "if two 0-bytes
are following the MPLS headers, it's a control word, so we skip 4 bytes
and the rest is a regular Ethernet packet" should work.
Thanks for digging up that reference :)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Tue, May 05, 2020 at 07:24:37PM +0200, Francois-Xavier Le Bail wrote: > Ok, it had DOS line ending format ... Not when I sent it, but who knows which mailer mangled it in surprising and fascinating ways on the path... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Tue, May 05, 2020 at 06:45:27PM +0200, Francois-Xavier Le Bail wrote: > > Attached as well. Not very smart yet, just does "what I need". > > Thanks, > > Patch for which tcpdump version? github checkout, it identifies itself as tcpdump version 4.10.0-PRE-GIT (git clone https://github.com/the-tcpdump-group/tcpdump.git) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Tue, May 05, 2020 at 04:45:04PM +0200, Francois-Xavier Le Bail wrote: > On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote: > > 12:11:46.116238 MPLS (label 105, exp 0, ttl 254) (label 24003, exp 0, [S], > > ttl 254) IP 10.27.99.2 > 10.27.99.34: ICMP echo request, id 49866, seq > > 5160, length 84 > > 12:11:46.117107 MPLS (label 24002, exp 0, [S], ttl 253) IP 10.27.99.34 > > > 10.27.99.2: ICMP echo reply, id 49866, seq 5160, length 84 > > > > > > So, for my debugging purposes, I have what I need now. > > Could you send a pcap file with the ICMP echo request/reply test ? Of course. Attached. This is EVPN/MPLS between two Cisco ASRs (in case it makes a difference). One direction has only a single label because the final router is on the link I'm sniffing, the other direction has two labels. Inside are a few machines pinging around plus one or two ARPs. (The .cap file is very small, just 4 kbyte, so I dare send it to the list as well) > And the patch you apply ? Attached as well. Not very smart yet, just does "what I need". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
Hi,
On Tue, May 05, 2020 at 05:50:40AM -0400, Gert Doering via tcpdump-workers
wrote:
> Now, the two questions:
>
> - is there a switch I'm missing to decode packets-in-MPLS?
> (like, "packets in GRE" get decoded already)
> - if not, is someone already working on it? I might just hack
>it in, if not...
O-kay. That turned out to be easier and harder than I thought, at the
same time.
tcpdump's print-mpls.c already does "if I know what upper-layer protocol
is in here, I call the appropriate printer". But there is no well-defined
type field, so it fails for my packets, and and falls back to "hexdump"
(good enough).
In my case, there is an MPLS control word before the ethernet header
(" "), and if I skip that and just clear "ethernet in here", I
get nicely printed packets...
12:11:46.116238 MPLS (label 105, exp 0, ttl 254) (label 24003, exp 0, [S], ttl
254) IP 10.27.99.2 > 10.27.99.34: ICMP echo request, id 49866, seq 5160, length
84
12:11:46.117107 MPLS (label 24002, exp 0, [S], ttl 253) IP 10.27.99.34 >
10.27.99.2: ICMP echo reply, id 49866, seq 5160, length 84
So, for my debugging purposes, I have what I need now.
For "contribute back to tcpdump", this is unsatisfactory, as I'm just
guessing what is in there - we already have guesswork, but that isn't
covering "0" (and being a control word, it could be anything).
How does wireshark/tshark approach this?
Would it make sense to add a flag option "hey, MPLS dissector, this is
ethernet + control-world, always"?
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
Hi,
I need to trace "MPLS-y" stuff between some routers, and wonder if
I'm missing tcpdump functionality here, namely "decode packets inside
MPLS".
I can match on "mpls" or "mpls ", but then I just get a hex
dump...
11:13:58.765851 MPLS (label 105, exp 0, ttl 254)
(label 24003, exp 0, [S], ttl 254)
0x: 0050 569c 338e 3cfd febd 7835 .PV.3.<...x5
0x0010: 0800 4500 0068 1218 4001 8e3b 0a1b ..E..h@..;..
0x0020: 6302 0a1b 630a 0800 a2ea 6e4b 0738 c...c.nK.8..
0x0030:
0x0040: 6c69 626f 7069 6e67 202d 2d20 4943 ..liboping.--.IC
0x0050: 4d50 2070 696e 6720 6c69 6272 6172 7920 MP.ping.library.
0x0060: 3c68 7474 703a 2f2f 6f63 746f 2e69 742f <http://octo.it/
0x0070: 6c69 626f 7069 6e67 2f3e liboping/>
... while tshark would nicely decode the inner headers...
MultiProtocol Label Switching Header, Label: 24002, Exp: 0, S: 1, TTL: 253
0101 1101 1100 0010 = MPLS Label: 24002
000. = MPLS Experimental Bits: 0
...1 = MPLS Bottom Of Label Stack: 1
1101 = MPLS TTL: 253
Ethernet II, Src: Cisco_65:92:0f (00:c1:64:65:92:0f), Dst: IntelCor_bd:78:35
(3c:fd:fe:bd:78:35)
...
Internet Protocol Version 4, Src: 10.27.99.34, Dst: 10.27.99.2
...
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Now, I do not want to use tshark here, because it is way too chatty -
for a quick live packet view ("1-3 lines per packet", so I can immediately
see "ah, yes, packet went out, reply is / is not coming back") without
scrolling or folding packets I like tcpdump way better...
Now, the two questions:
- is there a switch I'm missing to decode packets-in-MPLS?
(like, "packets in GRE" get decoded already)
- if not, is someone already working on it? I might just hack
it in, if not...
thanks :)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy non-Linux support
Hi,
On Mon, Oct 07, 2019 at 11:29:24AM -0700, Guy Harris wrote:
> While we're discussing dropping support for older OSes:
>
> Do we still need to worry about:
>
> SunOS prior to 4.x NIT?
>
> SunOS 4.x STREAMS NIT?
>
> IRIX?
>
> DEC OSF/1^W^WDigital UNIX^W^WTru64 UNIX?
My take on this on other projects has been "no, because if they really
need it, they can always compile an older version of libFOO, and use that".
(This is also relevant for questions like "can we start using C99
features, even if SunOS 4 does not have C99 compiler")
The risk in cutting off support for legacy things (Linux 1.x, SunOS 4, etc.)
is that you might need to do a "libpcap.old.1" release in case a security
critical bug is found.
But I certainly can't tell you what to do, just bring in a few cents of
thinking, as someone who maintains "portable" unix stuff, and also loves
running old machines :-) (so, don't drop support for SunOS 4 in tcpdump)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0
Hi,
On Mon, Jul 23, 2018 at 09:35:30AM -0400, Michael Richardson wrote:
> Let's switch over to cmake as our official mechanism now... i.e. have
> travis, etc. use it in preference to configure.
From a sysadmin perspective, I find cmake to be a major annoyance
(because it usually does not exist on systems where I want to install
packages, and if your platform is not "mainstream i386/amd64", there's
quite often no binary packages, so "go out and compile cmake" is it,
then... like, FreeBSD/Sparc64).
I do understand that this is not for me to decide and that you're
fully free to ignore me, but I still wanted to say it so nobody can
say afterwards "hey, we announced this on the list and nobody spoke
up".
(If you say "... use it in preference to configure" and configure stays
around as fallback, I shut up and be happy :-) )
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] BUG FOUNDED (CANT STOP PROCESS)
Hi,
On Tue, Nov 29, 2016 at 12:39:17AM +0100, Sergio Garcia Gutierrez wrote:
> When i execute this line "sudo tcpdump -vvv dst host 'your IP' & port 80"
> You CANT STOP TCPDUMP using "Ctrl + C".
That's because you sent it into the background with "&", and then ran
another command "port 80".
The correct syntax is
sudo tcpdump -vvv dst host 'your_IP and port 80'
not "&", and quotes around all of it to be sure the shell will not
interfere with special characters.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] incorrect tcp checksum on Linux tun interfaces?
Hi, I'm a bit irritated by a byproduct of a problem hunt today, incorrect TCP checksums on a *tun* interface... 23:17:39.862001 IP6 (hlim 64, next-header TCP (6) payload length: 40) fd00:abcd:194:7::1.33509 fd00:abcd:194:7::1000.2: S, cksum 0x6502 (incorrect (- 0x3962), 1541095226:1541095226(0) win 14400 mss 1440,sackOK,timestamp 178211075 0,nop,wscale 6 23:17:39.926409 IP6 (hlim 64, next-header TCP (6) payload length: 20) fd00:abcd:194:7::1000.2 fd00:abcd:194:7::1.33509: R, cksum 0x2cff (correct), 0:0(0) ack 1541095227 win 0 23:18:14.295000 IP (tos 0x10, ttl 64, id 4904, offset 0, flags [DF], proto TCP (6), length 60) 10.194.7.1.52647 10.194.7.6.2: S, cksum 0x23b9 (incorrect (- 0xd832), 2395069612:2395069612(0) win 14600 mss 1460,sackOK,timestamp 178245508 0,nop,wscale 6 23:18:14.322183 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 10.194.7.6.2 10.194.7.1.52647: R, cksum 0x532d (correct), 0:0(0) ack 2395069613 win 0 this is tcpdump -v -s0 -i tun6 on a Linux 3.3.8 kernel. I'm quite used to see incorrect TCP checksums on interfaces that have hardware TCP checksum offloading (because pcap sees the packet before it's handed to the hardware for checksumming) - but on a *tun* interface, with no hardware to actually offload it to? Is this something new in the way Linux tun operates? (The tun goes into openvpn, and out of the other side's tun comes a packet with a perfectly valid TCP checksum, so what openvpn sees has the correct checksum, only what tcpdum sees does not) For the fun of it, I asked ethtool, and it tells me no checksum offloading... gert@gentoo $ ethtool -k tun6 Offload parameters for tun6: rx-checksumming: off tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: on large-receive-offload: off rx-vlan-offload: off tx-vlan-offload: off ntuple-filters: off receive-hashing: off ... weird. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] incorrect tcp checksum on Linux tun interfaces?
Hi,
On Tue, Dec 04, 2012 at 11:09:43AM -0500, Michael Richardson wrote:
{sorry if I'm a bit tardy at removing the emergency moderation that I
turned on in order to keep junk off the list}
I understand that, which I wasn't bugging anyone about this :-)
Gert == Gert Doering g...@greenie.muc.de writes:
Gert I'm a bit irritated by a byproduct of a problem hunt today,
incorrect
Gert TCP checksums on a *tun* interface...
Gert 23:17:39.862001 IP6 (hlim 64, next-header TCP (6) payload length:
40) fd00:abcd:194:7::1.33509 fd00:abcd:194:7::1000.2: S, cksum 0x6502
(incorrect (- 0x3962), 1541095226:1541095226(0) win 14400 mss
1440,sackOK,timestamp 178211075 0,nop,wscale 6
What's curious to me is that the chsum is not zero. If it was being
offloaded into a step after the PF_PACKET interface, it would be zero,
right?
I'm not sure. I find this highly irritating, and I'm fairly sure that
*here* are the folks that have seen all the funnies when tcpdumping on
specific interfaces...
Gert 23:18:14.295000 IP (tos 0x10, ttl 64, id 4904, offset 0, flags
[DF], proto TCP (6), length 60) 10.194.7.1.52647 10.194.7.6.2: S, cksum
0x23b9 (incorrect (- 0xd832), 2395069612:2395069612(0) win 14600 mss
1460,sackOK,timestamp 178245508 0,nop,wscale 6
Both for IPv4 and IPv6?
Yes.
Gert (The tun goes into openvpn, and out of the other side's tun
Gert comes a packet
openvpn does IPv6 now?
For point-to-point links, it did for a long time (but you had to set it
up manually on both ends). For multipoint setups with a server that
assigns IPv6 addresses etc., this is new functionality in 2.3, to be
released real soon now.
I suppose the next step would be to hexdump packets from /dev/net/tun.
I can try to do that, but I'm fairly sure that the packet is fine when it
really arrives at the tun interface - after all, it's coming *out* of
the server side tun with a correct checksum:
Client tun (kernel-tun-openvpn):
23:03:32.016262 IP (tos 0x10, ttl 64, id 15966, offset 0, flags [DF], proto TCP
(6), length 60)
10.194.7.6.42707 10.194.7.1.2: Flags [S], cksum 0x23b9 (incorrect -
0x0ff4), seq 3558498516, win 14600, options [mss 1460,sackOK,TS val 2703974026
ecr 0,nop,wscale 6], length 0
23:03:33.264096 IP6 (hlim 64, next-header TCP (6) payload length: 40)
fd00:abcd:194:7::1000.33677 fd00:abcd:194:7::1.2: Flags [S], cksum 0x6502
(incorrect - 0x4150), seq 1568376760, win 14400, options [mss 1440,sackOK,TS
val 2703974338 ecr 0,nop,wscale 6], length 0
Server tun (openvpn-tun-kernel), same two packets:
23:07:08.409938 IP (tos 0x10, ttl 64, id 15966, offset 0, flags [DF], proto TCP
(6), length 60) 10.194.7.6.42707 10.194.7.1.2: S, cksum 0x104f (correct),
3558498516:3558498516(0) win 14600 mss 1369,sackOK,timestamp 2703974026
0,nop,wscale 6
23:07:09.642172 IP6 (hlim 64, next-header TCP (6) payload length: 40)
fd00:abcd:194:7::1000.33677 fd00:abcd:194:7::1.2: S, cksum 0x4150 (correct),
1568376760:1568376760(0) win 14400 mss 1440,sackOK,timestamp 2703974338
0,nop,wscale 6
(for the SYN-ACK, the incorrect bit is on the other end, so this is
symmetric)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Multifile patch
Hi, On Mon, Sep 03, 2012 at 10:13:57PM -0400, Michael Richardson wrote: Wesley, is fopen(/dev/stdin) really the most portal way to get a reference to stdin? It's about the most complicated way, and guaranteed to be non-portable (no /dev/std* devices on AIX, for example). I'd have thought that doing: VFile=stdin; was the best way? This is well-defined. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump dissector for IP protocol 97 (EtherIP)?
Hi, On Wed, Apr 27, 2011 at 03:25:40PM -0400, Michael Richardson wrote: Gert == Gert Doering g...@greenie.muc.de writes: Gert is someone already working on a tcpdump dissector for IP Gert protocol 97 (ethernet tunneled over IP, RFC 3378)? Lack of answer suggests that the answer is no. I guessed so :-) Not promising anything yet, depends on available time and brains. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] tcpdump dissector for IP protocol 97 (EtherIP)?
Hi, is someone already working on a tcpdump dissector for IP protocol 97 (ethernet tunneled over IP, RFC 3378)? I'm using etherip in a project, and a quick grep in the tcpdump git doesn't look like it's supported - so I'd be willing to write a dissector (fairly trivial), but want to avoid duplication of work. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bandwidth by user or process id
hi, On Wed, Oct 06, 2010 at 01:29:58AM -0700, Patrick Kurz wrote: Let's say 10 users transfer large amounts of data through ssh at the same time. I assume in this situation 10 different processes would share the same socket, They won't. This (normally) only happens for server processes where there is a central server that accepts a given connection, and then forks a child to handle this connection (sharing the file descriptor for a moment). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bandwidth by user or process id
Hi, On Tue, Oct 05, 2010 at 02:14:19AM -0700, Patrick Kurz wrote: For typical point-to-point IP traffic, the combination of local address, local port, remote address, remote port, and transport protocol (TCP or UDP) is the closest thing you have to a unique key. Are you saying, that this method cannot distinguish two different users/PIDs downloading huge data from the same remote address to the same local address? This was the key point of my original question, and if your method relies on addresses and ports only, I have to search for a different solution. Two differnet local users will have to use different local ports. That's just the way TCP/UDP works, one of the 5 variables listed above has to be different for each parallel connection. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcp sequence and ack number with libpcap
Hi, On Thu, Aug 19, 2010 at 11:23:39PM +0900, Andrej van der Zee wrote: I am trying to get the TCP sequence and ack number of TCP packets. Somehow I get different values than tcpdump -vv does. The numbers are way too big all the time. Source and destination ports are just fine. Below the relevant code. I studied the tcpdump source code but can't find why. Please help, I am stuck! TCP sequence numbers basically start with a random start (ISN) value. tcpdump will internally take note of the ISNs for a given flow and will then only show the deltas how many bytes sent/acked since the beginning of the flow, instead of the absolute numbers. From a brief glance, your code looks fine to me. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcp sequence and ack number with libpcap
Hi, On Thu, Aug 19, 2010 at 08:47:26PM +0200, Luis MartinGarcia. wrote: I think you are performing your byte ordering conversion wrong. Seq and Ack values are transmitted in network byte order so you need to perform a network to host long conversion, and for that, you need to user ntohl(), not htonl(). On standard platforms with byte order 1234 or 4321, there is no difference. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] deduct local IP address from cap-file
Hi, On Fri, Apr 30, 2010 at 02:38:59PM -0700, Guy Harris wrote: if they're received by that host, and the destination address isn't a broadcast or multicast address, see what the destination address is; ... and to nitpick: if that host is not a router and is just forwarding this packet on behalf of others. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] forces (and sctp) patch
Hi, On Tue, Jan 19, 2010 at 02:35:15PM +0100, sth...@nethelp.no wrote: but that also gives us the multi-line format. My claim is that the 3.9.8 format is much preferable (gives me more relevant info) in the face of no -v option. Seconded. Sequence numbers is highly important for debugging network issues caused by packet loss / reordering. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap on VMWare
Hi, On Wed, Jan 13, 2010 at 06:14:20AM +, Vikram Roopchand wrote: jnetpcap does not perform a copy either. I am not sure where the issue lies , perhaps it's VMWar e drivers , perhaps not. But I doubt we (libpcap + jnetpcap + testcode) are not reading the data fast enough :( ... What sort of VMware network card are you using? As far as I remember, VMware simulates either a dec21143 based card (vmlance), an Intel e1000 card, or something which is more paravirtualized and needs a special driver. This might make a big difference... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] does port 25 work?
Hi, On Fri, Aug 01, 2008 at 05:45:40PM -0700, Guy Harris wrote: and possibly also IPv4-over-PPPoE-on-a-VLAN IPv6-over-PPPoE-on-a-VLAN and what about IPv4-over-GRE-over-IPv4 IPv6-over-GRE-over-IPv4-over-PPPoE IPv6-over-GRE-over-IPv4-over-PPPoE-on-a-VLAN and all the other possible variants of packet tunnels... I'd rather not go that way. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] does port 25 work?
Hi, On Thu, Jul 31, 2008 at 11:53:27PM -0400, U. George wrote: Without a detailed study, on my part, I am unable to jump to that conclusion. There is nothing to study here, or any conclusion to jump to. Guy has described the way tcpdump currently works. It works that way because it was implemented that way. Specifying port does not necessarily also specify ether type ( or anything else ). It does, for tcpdump. Ports are only defined in the context of TCP and UDP (for tcpdump), and TCP and UDP are only defined for IP, and IP (for tcpdump) implies IP over Ethernet. If you don't like that, change the source - but be aware of the implications that Guy already pointed out: more complex BPF filter, which might have performance impacts on high-bandwidth links. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Should we enable IPv6 support by default?
Hi, On Wed, Feb 06, 2008 at 03:37:05AM -0800, Guy Harris wrote: It's 2008. Should we enable IPv6 support by default in libpcap and tcpdump (as long as the OS supports IPv6 to a sufficient extent that we can compile the support in), and let users do --disable-ipv6 if, for whatever reason, they don't want it? I would certainly appreciate that. What is the reason for having optional IPv6 in the first place (besides OSes that don't provide all necessary header files)? Memory savings? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Should we enable IPv6 support by default?
Hi, On Wed, Feb 06, 2008 at 10:09:33AM -0800, Rick Jones wrote: What is the reason for having optional IPv6 in the first place (besides OSes that don't provide all necessary header files)? Memory savings? ISTR there were some funnies on some OSes where IPv6 was pre-enabled but not actually enabled unless something else was added. tcpdump is not actually *doing* any IPv6. All it does is read packets, print their contents. Which is completely independent of the question will the operating system provide IPv6 support?. It's not like tcpdump is trying to actually *use* IPv6. (I can do tcpdump to look at spanning tree packets. Or Cisco CDP. Neither is supported in my operating system...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Should we enable IPv6 support by default?
Hi, On Wed, Feb 06, 2008 at 12:58:49PM -0800, Guy Harris wrote: Gert Doering wrote: tcpdump is not actually *doing* any IPv6. It's doing IPv6 name resolution. OK, good argument. Some IPv6 related stuff without actually sending IPv6 packets (unless the resolver library does it internally) :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [patch] Teach tcpdump to recognize new OpenBSD pflog packets
Hi, On Thu, Sep 27, 2007 at 05:07:11PM +0200, Max Laier wrote: From my experience and feedback from various sources the need to look at old pflog dumps is rather small (if not non-existing). I see one possible operational issue here - upgrading your OS (- new pflog header) but not upgrading applications that use libpcap at the same time, like wireshark from the ports. Would the pflog change then break the applications? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump output format
Hi, On Wed, Mar 08, 2006 at 12:23:46PM +0530, Latha G wrote: Actually I am testing the tcpdump..for that I am cheching the output.. That's why I want to know all the possible output formats.. But here, the output formats are changing from time to time.. This is the way it is. The output format is not fixed, and you cannot rely on a specific output format. The point of getting output format was disturbing me.. I suppose, u understand my problem.. No. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] misprinting of GRE tunneled packets on NetBSD Sparc64
Hi, I'm sure this is going to be difficult to diagnose - so I need some help to figure out where to start. Setup: NetBSD -current (3.99.7) on Sparc64. IPv6-over-GRE-over-IPv4 tunneling tcpdump HEAD from CVS system libpcap $ ./tcpdump -V tcpdump version 3.9-PRE-CVS libpcap version 0.8.3 (this is because using libpcap-3.9-PRE-CVS makes tcpdump core dump, for whatever reason??!) Sniffing on the LAN for host remote address of tunnel gives: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on hme0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:14:04.595494 IP 172.30.1.153 193.149.44.208: GREv0, length 60: IP6 2001:608:8003::1 2001:608:4::3: ICMP6, echo request, seq 0, length 16 16:14:04.700420 IP 193.149.44.208 172.30.1.153: GREv0, length 60: IP6 2001:608:4::3 2001:608:8003::1: ICMP6, echo reply, seq 0, length 16 16:14:05.595419 IP 172.30.1.153 193.149.44.208: GREv0, length 60: IP6 2001:608:8003::1 2001:608:4::3: ICMP6, echo request, seq 1, length 16 16:14:05.746677 IP 193.149.44.208 172.30.1.153: GREv0, length 60: IP6 2001:608:4::3 2001:608:8003::1: ICMP6, echo reply, seq 1, length 16 - perfect, this is exactly how it should be. Sniffing on the tunnel interface (gre0) gives: [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU ./tcpdump -n -s0 -i gre0 tcpdump: WARNING: gre0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gre0, link-type NULL (BSD loopback), capture size 65535 bytes 16:16:28.835438 IP6 2001:608:8003::1 2001:608:4::3: ICMP6, echo request, seq 0, length 16 16:16:28.937041 IP6 , wrong link-layer encapsulationbad-hlen 0 16:16:29.835377 IP6 2001:608:8003::1 2001:608:4::3: ICMP6, echo request, seq 1, length 16 16:16:29.947910 IP6 , wrong link-layer encapsulationbad-hlen 0 - which is weird. Outgoing packets are properly decoded, incoming packets are not properly displayed. With -X, the packets look like this: 16:32:36.925380 IP6 2001:608:8003::1 2001:608:4::3: ICMP6, echo request, seq 1, length 16 0x: 6000 0010 3a40 2001 0608 8003 `.:@ 0x0010: 0001 2001 0608 0004 0x0020: 0003 8000 1c21 ecc8 0001 ...! 0x0030: 42e6 4984 000e 1e34 B.I4 16:32:37.024946 IP6 , wrong link-layer encapsulationbad-hlen 0 0x: 6000 0010 3a3d 2001 0608 0004 `.:= 0x0010: 0003 2001 0608 8003 0x0020: 0001 8100 1b21 ecc8 0001 ...! 0x0030: 42e6 4984 000e 1e34 B.I4 (The pinging itself works fine, so the issue is not corrupted packets but more corrupted signalling kernel-libpcap or such). What could be causing this effect? How can I narrow this down, and get it fixed / fix it? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] misprinting of GRE tunneled packets on NetBSD Sparc64
Hi, On Tue, Jul 26, 2005 at 05:45:15PM +0200, Hannes Gredler wrote: | (this is because using libpcap-3.9-PRE-CVS makes tcpdump core dump, for | whatever reason??!) can i have the core file for inspection, pls ? I've already removed the core file, but it has something to do with actual BPF sniffing. Dump file reading works, sniffing fails: [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ ./tcpdump -V tcpdump version 3.9-PRE-CVS libpcap version 0.9-PRE-CVS [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ ./tcpdump -r /tmp/bla reading from file /tmp/bla, link-type NULL (BSD loopback) 16:40:29.845410 IP6 zeta-v6.medat.de kirk.greenie.muc.de: ICMP6, echo request, seq 0, length 16 16:40:29.947464 IP6 , wrong link-layer encapsulationbad-hlen 0 16:40:30.845353 IP6 zeta-v6.medat.de kirk.greenie.muc.de: ICMP6, echo request, seq 1, length 16 16:40:30.944974 IP6 , wrong link-layer encapsulationbad-hlen 0 The effect is quite weird - with -i, it will not dump, but exit immediately, printing an empty message: [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU ./tcpdump -n -i gre0 tcpdump: WARNING: gre0: no IPv4 address assigned tcpdump: [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU ./tcpdump -n -i hme0 tcpdump: without -i, it will dump: [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU ./tcpdump -n Bus error (core dumped) GDB says: (gdb) run -n Starting program: /home/gert/cdp/tcpdump/tcpdump -n Program received signal SIGBUS, Bus error. 0x001b6c24 in pcap_stats_bpf (p=0x4a2000, ps=0x20bb11) at pcap-bpf.c:135 135 ps-ps_recv = s.bs_recv; (gdb) where #0 0x001b6c24 in pcap_stats_bpf (p=0x4a2000, ps=0x20bb11) at pcap-bpf.c:135 #1 0x001b981c in pcap_close (p=0x4a2000) at pcap.c:784 #2 0x001b9a84 in add_or_find_if (curdev_ret=0xc148, alldevs=0xc2a8, name=0x49ee3d hme0, flags=4294935139, description=0x0, errbuf=0xc4e0 ) at inet.c:157 #3 0x001b9dd4 in add_addr_to_iflist (alldevs=0xc2a8, name=0x49ee3d hme0, flags=4294935139, addr=0x49ea68, addr_size=24, netmask=0x0, netmask_size=24, broadaddr=0x0, broadaddr_size=0, dstaddr=0x0, dstaddr_size=0, errbuf=0xc4e0 ) at inet.c:316 #4 0x001b8518 in pcap_findalldevs (alldevsp=0xc388, errbuf=0xc4e0 ) at fad-getad.c:252 #5 0x001ba330 in pcap_lookupdev (errbuf=0xc4e0 ) at inet.c:493 #6 0x0019d9ec in main (argc=2, argv=0xc7a8) at tcpdump.c:854 #7 0x001024d8 in ___start () (gdb) list pcap-bpf.c:135 130 snprintf(p-errbuf, PCAP_ERRBUF_SIZE, BIOCGSTATS: %s, 131 pcap_strerror(errno)); 132 return (-1); 133 } 134 135 ps-ps_recv = s.bs_recv; 136 ps-ps_drop = s.bs_drop; 137 return (0); 138 } 139 [..] | [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU ./tcpdump -n -s0 -i gre0 | tcpdump: WARNING: gre0: no IPv4 address assigned | tcpdump: verbose output suppressed, use -v or -vv for full protocol decode | listening on gre0, link-type NULL (BSD loopback), capture size 65535 bytes | 16:16:28.835438 IP6 2001:608:8003::1 2001:608:4::3: ICMP6, echo request, seq 0, length 16 | 16:16:28.937041 IP6 , wrong link-layer encapsulationbad-hlen 0 [..] can you send me the .pcap of the gre tunnel and i have a look; I've sent this directly to Hannes (assuming the list will drop attachments). i am anticipating a kernel issue - typically we get this error message when the kernel tells us that the payload is IPv4 [and in reality is IPv6] - that makes the IPv4 printer bark; Might be an explanation, especially given the fact that the capture related part of the NetBSD GRE implementation wasn't changed at all when I added IPv6-over-GRE. Sending and receiving packets on the tunnel take a completely different route, so this might also explain the different behaviour seen. In that case I take all the blaim and go fix it :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] print GRE over IPv6 packets
hi, On Sun, Jul 03, 2005 at 10:30:29PM +0200, Hannes Gredler wrote: | I'm working on adding Cisco-compatible GRE over IPv6 tunneling, and | the following patch to tcpdump makes tcpdump dissect Cisco-encapsulated | GRE-over-IPv6 packets. have added it along with support for RSVP over IPv6; - /hannes Thanks. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] print GRE over IPv6 packets
Hi, On Sat, Jul 02, 2005 at 11:45:56AM +0200, Gert Doering wrote: I'm working on adding Cisco-compatible GRE over IPv6 tunneling, and ... to NetBSD, that is :-) (just in case you were wondering adding *to what*?). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] fddipad on NetBSD
Hi, On Wed, Apr 06, 2005 at 07:38:46PM -0700, Guy Harris wrote: Perhaps a post-1.6 version happened to define PCAP_FDDIPAD elsewhere (or perhaps the code didn't even compile on those versions - did you try it on 2.0, for example?). If you tell me what to look for, I can do some testing on 2.0.2 on Sparc64. I also have -current sources here, to check header file changes or whatever. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] TCPDUMP version 3.8.3
Hi, On Tue, Mar 22, 2005 at 07:00:15PM +0530, Manoj Kumar wrote: libpcap does not have exit() and libc exit() cannot release the memory allocated in heap.Only free() can release memmory from heap. Memory allocated via malloc is accounted in heap section of process memory, and pcap_complie() does malloc. Thus with malloc , free is necessary. If the program ends (which is what exit() does), the operating system will ALWAYS clean up and return all memory. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] can't do CVS checkouts/updates anymore
Hi, On Mon, Feb 07, 2005 at 08:28:43PM +0100, Hannes Gredler wrote: wrt the cdp printer can you send me your print-cdp file and i'll check it in; Annoyingly enough, I just found out that the feature I wanted to add (parsing of the CDP TLV attribute VoIP VLAN request) has already been implemented :-) So you won't see print-cdp.c updates any time soon... But still, it's good to be able (soon) to checkout current sources, for future work - whatever it will be. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] can't do CVS checkouts/updates anymore
Hi, On Tue, Feb 08, 2005 at 11:06:36AM -0800, Guy Harris wrote: But still, it's good to be able (soon) to checkout current sources, for future work - whatever it will be. It's not as nice as having anonymous CVS access, but nightly CVS snapshots are available from the tcpdump.org home page - see Current Tar files. Yes, I'm aware of that. It's a inconvenient, though, if your local tcpdump/libpcap tree already contains local changes - CVS handles that fine, while get a full snapshot, move over local patches is very cumbersome. But thankfully, this issue is being resolved :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] can't do CVS checkouts/updates anymore
Hi, On Mon, Feb 07, 2005 at 08:34:44PM -0500, Michael Richardson wrote: Gert, the problem with the anoncvs was that it got into situations where there was a cvs --pserver running (often four or five) with no network socket attached (I guess it closed down), consuming 100% of the CPU on the box. [..] So, I restricted the cvs pserver in hosts.allow, since I suspected that it might have been people abusing the service. Yes, this explains things (it *did* look like a TCP wrapper :) ), and I know the situation I need to do something about this open source project's web server all too well... If you (or anyone else) wants to send their IP address, I can insert it into hosts.allow. I'll even take /24s if you don't have a static. Please add 193.149.48.160/27 for me (Gert Doering, [EMAIL PROTECTED]). This /27 is statically assigned to me, and I use various machines out of the network to do testing on Linux, NetBSD, etc. thanks, gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] can't do CVS checkouts/updates anymore
Hi, since quite a while, I can't do CVS pserver operations anymore (at least half a year, but since I had no need to actually do anything to the sources, I never bothered enough to send mail). I asked Hannes Gredler privately, he says works for me, but it doesn't work for me. I tried 4 different machines (Linux, NetBSD, SCO, some with IPv4+IPv6, some with only IPv4) but the result is always the same: [EMAIL PROTECTED]:/user/gert$ cvs -d :pserver:[EMAIL PROTECTED]:/tcpdump/master login Logging in to :pserver:[EMAIL PROTECTED]:2401/tcpdump/master CVS password: cvs [login aborted]: end of file from server (consult above messages if any) (this is from miyu.greenie.muc.de, 193.149.48.180, consistent forward and reverse DNS for IPv4 and IPv6, Linux. Last attempt was done at 12:05 GMT, just when composing this e-mail - so you might see it in the server logs) Any idea what is causing this? It looks like an over-eager tcp wrapper is kicking me for some reason. I have some new items for print-cdp.c that I'd like to integrate, test, and then send upstream... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
