Re: [tcpdump-workers] pcap: forcing pcap_loop() failures
Why not use the 'any' device on Linux? I'm not sure if it will be
supported in 2.6.20, but
in recent kernels it is :-)
Best regards
Michael
On Aug 16, 2006, at 8:15 PM, Richard H. wrote:
Level: pcaplib novice
OS: Linux 2.6.20
I've been running a pcaplib app that reads continually from a
network switch port and processes a well-defined application
protocol. Let's say the network interface it reads from is 'eth0'.
I need to augment this app to handle the failover to a different
network switch port connected to a different network interface on
the host ('eth1'). There is no traffic on the failover switch
unless the primary switch fails. "Fails" means zero packet flow,
not merely the loss of packets containing the application
protocol. Once the primary switch has been repaired, I need to
detect the loss of packet flow on the network interface attached to
the failover switch and start reading again from network interface
attached to the primary switch port.
This all needs to happen automagically.
The most straightforward way I can think of to do this is to create
two handles:
pcap_t * primary_dev ;// "eth0"
pcap_t * failover_dev ;// "eth1"
...and initialize them during program startup, before calling
pcap_loop():
primary_dev = pcap_open_live( "eth0", BUFSIZ, 1, -1, errbuf ) ;
failover_dev = pcap_open_live( "eth1", BUFSIZ, 1, -1, errbuf ) ;
...and then do some abomination like this, so that if the first
pcap_loop() fails the second is invoked:
FOREVER()
{
// condition normal. Read from priimary capture interface
pcap_loop( primary_dev, -1, myCallback, NULL ) ;
// If we're here, the call above has failed. Time to read from
the failover interface
pcap_loop( failover_dev, -1, myCallback, NULL ) ;
// If we're here, the failover interface has failed. Hopefully
this means the primary
// is back up, because we're going back to the top of the loop
}
But this clearly isn't going to work as is. For one, the mere loss
of traffic itself probably won't make pcap_loop() fail. Two, even
if myCallback() keeps a count of the number of times it is
consecutively called without packet data, and uses this to infer a
switch failure, I still can't see any way from within myCallback()
to make pcap_loop() fail.
Has anyone used pcaplib this way? If so, which pcablib calls
should I look at to suss out the solution?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Request for DLT
Hi Guy, could you register a DLT for SCTP? It would be similar to LINKTYPE_IPV4 / DLT_IPV4 or LINKTYPE_IPV6 / DLT_IPV6, just covering the SCTP packet without any lower layer. Suggested name: LINKTYPE_SCTP / DLT_SCTP. Please let me know if you have any further questions. Thanks a lot for your help! Best regards Michael ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for DLT
On Nov 24, 2012, at 7:34 PM, Guy Harris wrote: > > On Nov 24, 2012, at 6:09 AM, Michael Tuexen > wrote: > >> could you register a DLT for SCTP? It would be similar to >> LINKTYPE_IPV4 / DLT_IPV4 or LINKTYPE_IPV6 / DLT_IPV6, >> just covering the SCTP packet without any lower layer. > > No IPv4 or IPv6 headers, so no identification of the IP-layer endpoints? Correct. This is what we want to dump to a file when running SCTP over DTLS over UDP, after DTLS has decrypted the packet. This stack will be using for RTCWeb between Web Browsers. For debugging purposes of SCTP related issues, we don't need lower layer information. We can identify the SCTP association (SCTP specific term for connection) by analyzing the port numbers and verification tags. Best regards Michael > > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for DLT
On Nov 28, 2012, at 12:56 AM, Guy Harris wrote: > > On Nov 24, 2012, at 12:49 PM, Michael Tuexen > wrote: > >> This is what we want to dump to a file when running SCTP over DTLS over UDP, >> after DTLS has decrypted the packet. This stack will be using for RTCWeb >> between Web Browsers. For debugging purposes of SCTP related issues, we >> don't need lower layer information. >> We can identify the SCTP association (SCTP specific term for connection) >> by analyzing the port numbers and verification tags. > > OK, LINKTYPE_SCTP/DLT_SCTP allocated; the value is 248. Great, thanks a lot! Best regards Michael ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] is tcpdump supposed to behave like this?
On Jul 1, 2013, at 3:32 PM, Téssio Fechine wrote: > Hello, > I was trying to analyze the traffic generated by this command: > > root@atena:~# dig rt-dq.quimica.ufpb.br @150.165.145.1 > > But I noticed that when the option '-w file' was not used, the tcpdump > capture changed: > > ** WITH -w (2 packets captured): > root@atena:~# tcpdump -pi eth0 port 53 -w dns.dump > tcpdump: WARNING: eth0: no IPv4 address assigned > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 > bytes > ^C2 packets captured > 4 packets received by filter > 0 packets dropped by kernel > root@atena:~# tcpdump -r dns.dump > reading from file dns.dump, link-type EN10MB (Ethernet) > 09:27:36.961325 IP atena.nti.ufpb.br.53124 > rt-dq.quimica.ufpb.br.domain: > 47498+ A? rt-dq.quimica.ufpb.br. (39) > 09:27:36.964252 IP rt-dq.quimica.ufpb.br.domain > atena.nti.ufpb.br.53124: > 47498*- 1/3/0 A 150.165.145.1 (107) > > ** WITHOUT -w (8 packets captured): > root@atena:~# tcpdump -pi eth0 port 53 > tcpdump: WARNING: eth0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 09:28:46.192113 IP atena.nti.ufpb.br.44510 > rt-dq.quimica.ufpb.br.domain: > 43490+ A? rt-dq.quimica.ufpb.br. (39) > 09:28:46.193493 IP atena.nti.ufpb.br.48548 > > dns-cache-2.bbn.ufpb.br.domain: 13528+ PTR? 1.145.165.150.in-addr.arpa. (44) > 09:28:46.193851 IP rt-dq.quimica.ufpb.br.domain > atena.nti.ufpb.br.44510: > 43490*- 1/3/0 A 150.165.145.1 (107) > 09:28:46.194279 IP dns-cache-2.bbn.ufpb.br.domain > > atena.nti.ufpb.br.48548: 13528 1/2/3 PTR rt-dq.quimica.ufpb.br. (198) > 09:28:46.194540 IP atena.nti.ufpb.br.41682 > > dns-cache-2.bbn.ufpb.br.domain: 33671+ PTR? 13.250.165.150.in-addr.arpa. > (45) > 09:28:46.195187 IP dns-cache-2.bbn.ufpb.br.domain > > atena.nti.ufpb.br.41682: 33671 1/2/3 PTR atena.nti.ufpb.br. (195) > 09:28:46.195462 IP atena.nti.ufpb.br.51372 > > dns-cache-2.bbn.ufpb.br.domain: 36444+ PTR? 3.255.165.150.in-addr.arpa. (44) > 09:28:46.196094 IP dns-cache-2.bbn.ufpb.br.domain > > atena.nti.ufpb.br.51372: 36444 1/2/3 PTR dns-cache-2.bbn.ufpb.br. (200) > ^C > 8 packets captured > 10 packets received by filter > 0 packets dropped by kernel > > I also tried with tshark, and got the same 2 packets as when using tcpdum > with -w: > > root@atena:~# tshark -pf "port 53" -i eth0 > tshark: Lua: Error during loading: > [string "/usr/share/wireshark/init.lua"]:45: dofile has been disabled > Running as user "root" and group "root". This could be dangerous. > Capturing on eth0 > 0.00 150.165.250.13 -> 150.165.145.1 DNS 85 Standard query A > rt-dq.quimica.ufpb.br > 0.002514 150.165.145.1 -> 150.165.250.13 DNS 153 Standard query response > A 150.165.145.1 > ^C2 packets captured > > > I tried this MANY times, and always got the same results. Is tcpdump > supposed to work like this? If you run tcpdump -n -pi eth0 port 53 then tcpdump will not do DNS lookups for its output... Best regards Michael > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] RFC: DLT for "application TCP stream capture"
> On 14 Jan 2015, at 18:19, Denis Ovsienko wrote: > >> Eventually, we'll be using this format to debug multi-path TCP, in which >> case >> the IP addresses (and maybe even the IP4/IP6-ness of it) might change. > > Also there exists SCTP, which implements the concept of variable (0..65535) > number of "streams" for each direction of an "association" between a pair of > sockets (in TCP these two things are the same), so a stream_id field in the > encoding (0 for TCP and UDP) could be handy for SCTP payload representation. and don't forget the PPID, the ordered/unordered flag, and the TSN/SSN. All this is exposed to the application... Best regards Michael > > -- >Denis Ovsienko > > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Re: Accurate ECN support in tcpdump/libpcap
> On 5. Sep 2023, at 09:34, Francois-Xavier Le Bail > wrote: > > On 29/08/2023 16:34, Scheffenegger, Richard via tcpdump-workers wrote: >> And some initial discussions which aren't yet reflected on the mailing list: >> >> -Original Message- >> From: Scheffenegger, Richard >> Sent: Freitag, 18. August 2023 14:01 >> To: Francois-Xavier Le Bail ; >> tcpdump-workers@lists.tcpdump.org >> Cc: Denis Ovsienko ; Guy Harris ; >> [...] ; Michael Richardson ; [...] >> Subject: RE: Accurate ECN support in tcpdump/libpcap >> >> (Adding everyone who has participated in the discussion so far, since it >> seems that tcpdump-workers mailman is not working, as well as a number of >> additional recent committers and participants) > > [...] > >> I do not think there is ambiguity here. > > Hi Richard, > > I think there's an ambiguity here. > Using "A" as the new TCP flag for tcpdump is a mistake because it sounds like > "ACK" (even if tcpdump prints "." for "ACK"). > Thus my proposal to use "N", last letter of "Accurate ECN", as already > suggested in some PR comments and a previous message. > Mnemonic: "Accurate EC[N]" or "[N]ew TCP scheme/mechanism". > Alternatives: > - "M" from "[M]ore Accurate Explicit Congestion Notification", from your > draft title. > - "G" from "TCP Pra[G]ue", perhaps less mnemonic. > >> Tcpdump - any every tool afterwards - has been using "." for ACKs. > > This is incorrect. Wireshark, for example, does not use "." for ACKs. > >> "N" had been in (very rare) use for the NS bit (RFC3540), which is now >> obsolete >> (https://datatracker.ietf.org/doc/status-change-ecn-signaling-with-nonces-to-historic/). >> While this is the same bit (and arguably, the authors of RFC3540 could have >> made more effort to get that bit adopted in tooling back in 2001-2003), the >> semantics are dramatically different than the current use. >> >> "A" has never been in use before, as a single character abbreviation, > > This is incorrect. Wireshark uses "A" for "ACK". > (e.g. TCP Flags: C··A··S·) > ^ It uses A for ACK and AE: https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-tcp.c#L854 But this notation is used in a position dependent way. Best regards Michael > >> and is in use for the last 2+ years in other tooling around packet mangling, >> tracing, decoding and forging such as wireshark and packetdrill... >> (and yes, I did let the ball drop with tcpdump for a couple months, when all >> the other tools were updated reflecting the "A" char change there, which was >> completely uncontentious in those communities). > > s/for a couple months/for 2 years and half/ > Your Proposal to packetdrill: Jan 18, 2020. Your PR to tcpdump: Jul 27, 2022. > Denis questions: Oct 23, 2022. No answer until Jul 23, 2023. > >> I suspect it would create more confusion, if tcpdump was using a different >> mapping, than other tools > > There are already some different mapping between, for example, Wireshark and > tcpdump: > ACK: "." for tcpdump, "A" for Wireshark. > CWR: "W" for tcpdump, "C" for Wireshark. Wireshark uses the first character... Best regards Michael > > If you think this is a problem for the new flag, have you considered > modifying the two tools you mention with two small patches? > > Wireshark, for example, prints "AE" without -V, e.g. "[SYN, ECE, CWR, AE]". > No "A" alone here. > And the only place where the new "A" appears is with -V: > TCP Flags: ···ACES· > --^ > It appears with: > "...1 = Accurate ECN: Set" > > If it's a problem, it could easily be changed to e.g. "N", with a little > patch. > > Same for packetdrill. > >> (just like with the "." for Ack, which is in common use throughout those >> very same tools). > > And again « the "." for Ack » is not used by Wireshark, one of « those very > same tools ». > >> Another interesting aspect which I would be keen on learning, if per-session >> stateful decoding is something that the tcpdump community would entertain. >> Once the AccECN handshake (in a SYN) was seen, subsequently the AE, ECE and >> CWR bits together form the ACE counter. In packetdrill and also wireshark >> this gets then decoded numerically (0..7) instead of having one character >> per bit... > > This per-session stateful session decoding could be examined later... > >> Best regards, >> Richard > > Best regards, > François > >> >> -Original Message- >> From: Francois-Xavier Le Bail >> Sent: Freitag, 18. August 2023 13:20 >> To: Scheffenegger, Richard ; >> tcpdump-workers@lists.tcpdump.org >> Subject: Re: Accurate ECN support in tcpdump/libpcap >> >> NetApp Security WARNING: This is an external email. Do not click links or >> open attachments unless you recognize the sender and know the content is >> safe. >> >> On 18/08/2023 09:55, Scheffenegger, Richard wrote: >>> Hi, >>> >>> I’ve been asked to reach out to this mailing list, to gather some feedbac
Re: [tcpdump-workers] [Wireshark-dev] New RFCs for 1) pcap file format and 2) rpcapd protocol?
--- Begin Message --- > On 21. Mar 2020, at 23:10, Michael Richardson wrote: > > > Guy Harris via tcpdump-workers wrote: >> Currently, on GitHub, there's a "pcapng" team: >> https://github.com/pcapng > >> with one repository containing the pcapng specification, and a >> "the-tcpdump-group" team: > >> https://github.com/the-tcpdump-group >> with repositories for libpcap, tcpdump, and the tcpdump.org Web site. > >> It makes sense to me to keep those specifications on a site such as >> GitHub; GitHub comes to mind first because that's where pcapng >> currently is. > >> 1) add them as repositories to the pcapng team; > >> 1) has the slight disadvantage that the name for the team suggests it's >> for pcapng only; it appears that teams can be renamed: > > ... > >> Were we to rename it, I don't know what would be a good new name. > > I'm good with pcapng, because I also have no other suggestion. > I would like to restart the opsawg work on an IETF specification for this. I would support this. However, last time I tried this, I was not successful. There were not very interested in defining a file format... Maybe things have changed, but I don't know. Best regards Michael > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [OPSAWG] I-D Action: draft-ietf-opsawg-pcapng-00.txt
--- Begin Message --- > On 25. Jan 2023, at 21:33, Carsten Bormann wrote: > > On 25. Jan 2023, at 17:42, Michael Richardson wrote: >> >> I am not sure that pcap*NG* is so incredibly established that we can't change >> it. I just hate "Next Generation" for anything, particularly when time >> moves on. >> What about if we kept N and G, but changed what they meant? > > (SenML started as an XML vocabulary, but now is mostly JSON and CBOR — so we > turned the “ML” into “Measurement Lists”. > Which is somewhat bizarre, but keeps the acronym. > For retronyming PCAPNG, what is central to PCAPNG that would explain the P, > N, and G?) pcap, now generalized? Best regards Michael > > Grüße, Carsten > > ___ > OPSAWG mailing list > ops...@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
