Re: [tcpdump-workers] using tcpdump
>I would suspect that you have a duplicate IP address on your internet side In case of ip conflict, is there any special message/packet which can be extracted from tcpdump? Regards, Mahmood From: Michael Richardson To: Mahmood Naderan Cc: "tcpdump-workers@lists.tcpdump.org" Sent: Thursday, May 16, 2013 6:26 PM Subject: Re: [tcpdump-workers] using tcpdump > "Mahmood" == Mahmood Naderan writes: Mahmood> I am using scientific linux 6.3 which kernel Mahmood> 2.6.32-279.5.1.el6.x86_64. The chassis, say 'A', has 3 Mahmood> network interfaces. Eth1 has valid IP and is connected to Mahmood> internet and eth2 has invalid IP and is connected to Mahmood> another local switch. Mahmood> Problem is that the internet is randomly disconnected on Mahmood> eth1 so the computer is unreachable through ping Mahmood> command. At the same time, there is another chassis, say Mahmood> 'B', which has also the same configuration. I mean one Mahmood> interface of 'B' is connected to the internet (same Mahmood> internet witch as 'A') and one interface to local switch Mahmood> (same local switch as 'A'). However 'B' uses Ubuntu 12.04. .. Mahmood> The situation is very very random, so I tried to use Mahmood> "tcpdump -vvv -i eth1" to see if I can find any useful Mahmood> information about connect/disconnect messages. Mahmood> Can tcpdump help me with this problem? Any feedback is appreciated. I think not if you are not very experienced using it. I would suspect that you have a duplicate IP address on your internet side. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Request for new DLT
Hi all, Anders Broman, Wireshark core developer, is currently designing an export functionality for PDUs and would need a DLT allocated for this new functionality. You will find below the email he tried to send to this mailing list a few days ago and that got bounced. I hope mine will go through :) Best regards, Pascal. -Original Message- From: Anders Broman Sent: den 16 maj 2013 16:04 To: 'tcpdump-workers@lists.tcpdump.org' Subject: RE: Request for new DLT Hi, I would need a DLT for a wrapper around higher level PDU's or per-packet DLT:s the format is multipurpose and consists of a number of TLV:s proceeding the actual PDU. There are TLV:s which describes which protocol the PDU is and meta data such as IP address and port (if the transport protocol(s) are striped off). The format can be used by logging functions in various nodes, say after deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc. Tag values and an outline of the format can be found here http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup LINKTYPE_ANY_PDU or something like that? Best regards Anders Broman ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] pcap FCS length and LT_FCS_DATALINK_EXT()
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 supports this, and as implemented the LT_FCS_LENGTH is in units of 16-bits, e.g. 16-bit FCS returns 1, and 32-bit FCS returns 2? I don't think Wireshark's pcap wiretap code currently uses this mechanism to check for FCS length, does it make sense to add it? If it is supported in Wireshark, it might be more widely implemented. It seems to solve a genuine problem, and avoids the proliferation of DLTs for WITH and WITHOUT FCS. Regards, Stephen. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] capturing only timestamp excluding other information
Sir, I have been using Tcpdump. Extracting timestamp from a pcap file is quite easy. Is there any way to capture only the timestamp excluding other info using Tcpdump while capturing packet. -- Achyut Baruah M.Tech(IT) Dept. of Computer Sc. & Engg. Tezpur University, India. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Request for new pcap/pcapng DLT Format
Hi, I would like to request a custom DLT type for the Schweitzer
Engineering Laboratories "RTAC" product. Information on the
product/purpose of the DLT is included below:
The RTAC product family (SEL-3530, SEL-2241, SEL-3505) is a Linux-based
Automation Controller product that is capable of interfacing with SEL and
3rd-party equipment using a variety of standard industrial protocols such
as SEL FM, DNP3, Modbus, C37.118, Telegyr 8979 and others. Each protocol
instance (master/client or slave/server) is configured to utilize either
Ethernet or EIA-232/485 serial connectivity with protocol variations for
each medium taken into account. More information is available at
www.selinc.com/sel-3530
The configuration software for the RTAC platform is named AcSELerator RTAC
(SEL-5033) and is used to set up all communications and user logic for the
controller as well as provide downloading and online debugging facilities.
One particularly useful aspect of the online debugging capabilities is a
robust Communication Monitor tool that can show raw data streams from
either serial or Ethernet interfaces. Many similar products have this
same capability but the RTAC software goes a step beyond by providing a
"save-as" function to save all captured data into pcap format for further
analysis in Wireshark.
All Ethernet-based capture files will have a packets with a "Linux Cooked
Capture" Ethernet-header including the "source" MAC address of the device
responsible for the generation of the message and the TCP/IP header(s)
maintained from the original conversation. The application data from the
message will follow as per a standard Wireshark packet.
Serial-based pcap capture files are stored using "User 0" DLT type 147 to
specify a user-defined dissector for pcap data and contain a standard
12-byte serial data header followed by the application payload data from
actual rx/tx activity on the line. Some useful information can be
retrieved from the 12-byte header information, such as conversation
time-stamps, UART function and EIA-232 serial control line states at the
time of the message.
The dissector is intended to be called from the DLT_USER preferences
configuration with User 0 (DLT=147) set with a 'Header Size' of '12' and a
'Header Protocol' of 'rtacser'. The 'Payload Protocol' can be configured
to use whatever standardized industrial protocol is present on the line
for attempted dissection (selfm, mbrtu, dnp3.udp, synphasor)
The general format of this 12-byte header is as follows:
+---+
| Relative TimeStamp (Left) |
| (4 Bytes)|
+---+
| Relative TimeStamp (Right)|
| (4 Bytes)|
+---+
| Serial Event Type |
| (1 Byte) |
+---+
| UART Control Line State |
| (1 Byte) |
+---+
| Footer |
| (2 Bytes) |
+---+
| Payload |
. .
. .
. .
1) The relative timestamp is 8 bytes, the "left" and "right" components
are 32-bit integers representing the left and right-hand side of the
decimal point, respectively
2) The Serial Event type represents the type of packet entry in the pcap
file:
{ 0x00, "STATUS_CHANGE" },
{ 0x01, "DATA_TX_START" },
{ 0x02, "DATA_RX_START" },
{ 0x03, "DATA_TX_END" },
{ 0x04, "DATA_RX_END" },
{ 0x05, "CAPTURE_DATA_LOST" },
{ 0x06, "CAPTURE_COMPLETE" },
{ 0x07, "FRAMING_ERROR" },
{ 0x08, "PARITY_ERROR" },
{ 0x09, "SERIAL_BREAK_EVENT"},
{ 0x0A, "SERIAL_OVERFLOW_EVENT" },
3) The UART Control Line State is a masked-bit representation of the
serial UART lines (asserted, de-asserted) at the time of the packet
generation:
CTS 0x01
DCD 0x02
DSR 0x04
RTS 0x08
DTR 0x10
RING 0x20
MBOK 0x40
4) The 2-byte footer is undefined and for future use.
The Wireshark code submission currently exists at:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8644. The current
plan is to have a User Preference for the payload protocol decoding,
selecting DNP3, Modbus, Synchrophasor or SELFM.
Let me know if any more details are needed.
Thanks,
Chris Bontje
Schweitzer Engineering Labs
Automation Application Specialist, SW Region
(509)334-5664
chris_bon...@selinc.com
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Request for DLT
Hi, I would need a DLT for a wrapper around higher level PDU's or per-packet DLT:s the format is multipurpose and consists of a number of TLV:s proceeding the actual PDU. There are TLV:s which describes which protocol the PDU is and meta data such as IP address and port (if the transport protocol(s) are striped off). The format can be used by logging functions in various nodes, say after deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc. Tag values and an outline of the format can be found here http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup Best regards Anders Broman ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Request for new DLT
Hi, I would need a DLT for a wrapper around higher level PDU's or per-packet DLT:s the format is multipurpose and consists of a number of TLV:s proceeding the actual PDU. There are TLV:s which describes which protocol the PDU is and meta data such as IP address and port (if the transport protocol(s) are striped off). The format can be used by logging functions in various nodes, say after deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc. Tag values and an outline of the format can be found here http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup LINKTYPE_ANY_PDU or something like that? Best regards Anders Broman ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for new DLT
Hi, I would need a DLT for a wrapper around higher level PDU's or per-packet DLT:s the format is multipurpose and consists of a number of TLV:s proceeding the actual PDU. There are TLV:s which describes which protocol the PDU is and meta data such as IP address and port (if the transport protocol(s) are striped off). The format can be used by logging functions in various nodes, say after deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc. Tag values and an outline of the format can be found here http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup LINKTYPE_ANY_PDU or something like that? Best regards Anders Broman ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for new DLT
> "Pascal" == Pascal Quantin writes: Pascal> Anders Broman, Wireshark core developer, is currently designing an export Pascal> functionality for PDUs and would need a DLT allocated for this new Pascal> functionality. Pascal> You will find below the email he tried to send to this mailing list a few Pascal> days ago and that got bounced. I hope mine will go through Pascal> :) sorry. Anders> I would need a DLT for a wrapper around higher level PDU's or per-packet Anders> DLT:s the format is multipurpose and consists of a number of TLV:s Anders> proceeding the actual PDU. Anders> There are TLV:s which describes which protocol the PDU is and meta data Anders> such as IP address and port (if the transport protocol(s) are striped off). Anders> The format can be used by logging functions in various nodes, say after Anders> deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc. Anders> Tag values and an outline of the format can be found here Anders> http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup Looks like a rather sane TLV structure. Is it intended to be used beyond SS7 stuff? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] capturing only timestamp excluding other information
On May 8, 2013, at 10:51 PM, achyut baruah wrote: > Sir, I have been using Tcpdump. Extracting timestamp from a pcap file is > quite easy. Is there any way to capture only the timestamp excluding other > info using Tcpdump while capturing packet. No, there isn't. However, if you capture with as low a snapshot length as possible (try 1 as a value; the OS or libpcap might raise it to a larger minimum value), that will minimize the amount of extra data you're capturing. If you only want the timestamp from the pcap file, you can just extract that and ignore the packet data. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] using tcpdump
Problem is, syslog (and kernel in general) doesn't record such things *at all* Regards, Mahmood From: Mark W. Jeanmougin To: Mahmood Naderan Cc: "tcpdump-workers@lists.tcpdump.org" Sent: Sunday, May 19, 2013 1:09 AM Subject: Re: [tcpdump-workers] using tcpdump For an issue like this, I would look at syslog before I'd check tcpdump. Is anything there when the box looses the network connection? MJ On May 16, 2013 9:16 AM, "Mahmood Naderan" wrote: Hello all users >I am using scientific linux 6.3 which kernel 2.6.32-279.5.1.el6.x86_64. The >chassis, say 'A', has 3 network interfaces. Eth1 has valid IP and is connected >to internet and eth2 has invalid IP and is connected to another local switch. > >Problem is that the internet is randomly disconnected on eth1 so the computer >is unreachable through ping command. At the same time, there is another >chassis, say 'B', which has also the same configuration. I mean one interface >of 'B' is connected to the internet (same internet witch as 'A') and one >interface to local switch (same local switch as 'A'). However 'B' uses Ubuntu >12.04. > >The internet connection is steady and that means while 'A' is unreachable, 'B' >can be pinged. > >The situation is very very random, so I tried to use "tcpdump -vvv -i eth1" to >see if I can find any useful information about connect/disconnect messages. > >Can tcpdump help me with this problem? Any feedback is appreciated. > > >Regards, >Mahmood >___ >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
