Re: [Wireshark-dev] PCAP-over-IP in Wireshark?
Thank you Guy and Chuck! Adding a Pipe interface with the path "TCP@127.0.0.1:57012" worked, and so did running "wireshark -k -i TCP@127.0.0.1:57012"! I've now verified that this feature can be used to read PCAP from a TCP socket in both Windows and Linux. This is exactly what I was hoping for! Replacing 127.0.0.1 with localhost didn't work for some reason though. I just get an error message saying that "TCP@localhost:57012" is not a valid socket specification. I was delighted to see that tshark also reads the pcap stream nicely when I run it like this: tshark -i TCP@127.0.0.1:57012 I've also verified that I can read the PCAP stream from a remote IP instead of just 127.0.0.1. Thank you for your great work! Den tis 1 feb. 2022 kl 04:28 skrev chuck c : > https://wiki.wireshark.org/CaptureSetup/Pipes.md#tcp-socket > > "A TCP stream is treated as like data from other pipes and the same > restrictions apply. > On each new connection the TCP server must send the header blocks as > specified by libpcap or pcapng before any packet captures. > TCP@ pipes may also be added in the GUI's Menu Capture/Options…, Manage > Interfaces…, Pipes Tab, but pipe settings are not saved by Wireshark." > > On Mon, Jan 31, 2022 at 6:19 PM Guy Harris wrote: > >> On Jan 31, 2022, at 4:56 AM, Erik Hjelmvik >> wrote: >> >> > Is there some way to read PCAP-over-IP in Wireshark? I.e. read a PCAP >> stream over a TCP socket. >> > >> > Currently, the best solution to read PCAP-over-IP in Wireshark is by >> using netcat to read the PCAP stream and forward it to Wireshark's STDIN >> like this: >> > nc localhost | wireshark -k -i - >> >> So this means "stream a pcap file to Wireshark and have it read it as a >> live capture". >> >> Wireshark - well, dumpcap, which does the capturing - has supported >> capturing from a pipe for a while. >> >> Support for capturing from a TCP socket was added at some point; the man >> page doesn't document it all that well: >> >>−i|−−interface |rpcap://:/>interface>|TCP@:|− >> >>Set the name of the network interface or pipe to use for live >>packet capture. >> >>Network interface names should match one of the names listed in >>"dumpcap −D" (described above); a number, as reported by >> "dumpcap >>−D", can also be used. If you’re using UNIX, "netstat −i", >> ied, >>"ifconfig −a" or "ip link" might also work to list interface >> names, >>although not all versions of UNIX support the −a option to >>ifconfig. >> >>If no interface is specified, Dumpcap searches the list of >>interfaces, choosing the first non−loopback interface if there >> are >>any non−loopback interfaces, and choosing the first loopback >>interface if there are no non−loopback interfaces. If there >> are no >>interfaces at all, Dumpcap reports an error and doesn’t start >> theg >>capture. >> >>Pipe names should be either the name of a FIFO (named pipe) or >> "−" >>to read data from the standard input. On Windows systems, >> pipe >>names must be of the form "\\pipe\.*pipename*". Data read from >>pipes must be in standard pcapng or pcap format. Pcapng data >> must >>have the same endianness as the capturing host. >> >> It mentions "TCP@:" in the line describing the interface, >> but doesn't say what it means. >> >> So try >> >> wireshark -k -i TCP@localhost:57012 >> >> >> ___ >> 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 >> > ___ > 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 > ___ 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
Re: [Wireshark-dev] PCAP-over-IP in Wireshark?
Thanks for the feedback Roland! sshdump is indeed a neat way to capture packets from a remote machine. But I'm afraid that extcap solution isn't quite what I'm looking for either. I should have explained more in detail what I'm trying to achieve, so that you folks would't have to guess. I primarily use PCAP-over-IP to read decrypted TLS packets from PolarProxy, for example as in these two examples: * Ingesting packets from PolarProxy to Arkime: https://netresec.com/?b=20C3247 * Live extraction of TLS encrypted data in Windows: https://netresec.com/?b=221d46b One option would be to implement an additional packet export feature to PolarProxy, which transmits decrypted packets over ERSPAN or wrapping the packets in UDP, so that they can be parsed with udpdump. However, I'm a bit reluctant to adding new features unless there is a real need for them. What I'd like to achieve in the end is for Wireshark/tshark to be able to parse decrypted traffic from PolarProxy in near-real time. Any suggestions or ideas that you might have on how we can make PolarProxy+Wireshark work better together are welcome! PS: I actually did a live TLS decryption demo at the SEC-T conference in 2019, which was recorded and posted here: https://www.youtube.com/watch?v=lVS0DHjgpKc In this demo I simply pushed the decrypted PCAP stream from PolarProxy to STDOUT and piped that into Wireshark with "-i -". This integration works, but it's not how I prefer to read packets with Wireshark and it's not a viable option if PolarProxy and Wireshark are running on different machines. /erik Den mån 31 jan. 2022 kl 20:39 skrev Roland Knall : > If udpdump is nothing for you, and you are able to run a capture tool like > tshark or tcpdump on the remote machine, you can take a look at sshdump. A > sibling of udpdump, it executes the remote capture program via ssh, and > then transports the data as-is through a ssh-connection. It can be seen as > a simple capture device on the host pc. > > Roland > > Am Mo., 31. Jan. 2022 um 19:53 Uhr schrieb Erik Hjelmvik < > erik.hjelm...@gmail.com>: > >> Hi Dario, >> >> Udpdump looks interesting, but I'm afraid it doesn't quite fulfill my >> requirements. Wrapping captured packets inside of UDP packets or IP packets >> (as in ERSPAN) to allow remote sniffing is an attractive solution, but it >> comes with several drawbacks. Some of these drawbacks include difficulties >> in handling captured packets that exceed the MTU between sniffer and >> collector, how to preserve timestamps from the original capture source etc. >> Transmitting packets over a TCP connection has a few drawbacks as well, but >> it's a method that has served me very well over the years. >> >> As of now, I'd say that the primary drawback of using PCAP-over-IP (which >> really should be called "PCAP-over-TCP") is that Wireshark/tshark can't >> read this data natively without having to use netcat as a shim between the >> TCP socket and Wireshar/tshark. I was hoping that there was an extcap >> solution for this, but I'm guessing I might be out of luck there :( >> >> /erik >> >> Den mån 31 jan. 2022 kl 14:02 skrev Dario Lombardo : >> >>> You can have a look at udpdump, which doesn't use TCP but UDP, but it >>> may fit your purpose. >>> >>> On Mon, Jan 31, 2022 at 1:57 PM Erik Hjelmvik >>> wrote: >>> >>>> Hello folks, >>>> >>>> Is there some way to read PCAP-over-IP in Wireshark? I.e. read a PCAP >>>> stream over a TCP socket. >>>> >>>> Currently, the best solution to read PCAP-over-IP in Wireshark is by >>>> using netcat to read the PCAP stream and forward it to Wireshark's STDIN >>>> like this: >>>> nc localhost 57012 | wireshark -k -i - >>>> >>>> But it would be much nicer if this data could be read directly without >>>> having to use netcat. Maybe as an extcap interface? >>>> >>>> Best regards, >>>> Erik >>>> >>>> ___ >>>> 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 >>>> >>> >>> >>> -- >>> >>> Naima is online. >>> >>> >>> ___ >>> Sent via:
Re: [Wireshark-dev] PCAP-over-IP in Wireshark?
Hi Dario, Udpdump looks interesting, but I'm afraid it doesn't quite fulfill my requirements. Wrapping captured packets inside of UDP packets or IP packets (as in ERSPAN) to allow remote sniffing is an attractive solution, but it comes with several drawbacks. Some of these drawbacks include difficulties in handling captured packets that exceed the MTU between sniffer and collector, how to preserve timestamps from the original capture source etc. Transmitting packets over a TCP connection has a few drawbacks as well, but it's a method that has served me very well over the years. As of now, I'd say that the primary drawback of using PCAP-over-IP (which really should be called "PCAP-over-TCP") is that Wireshark/tshark can't read this data natively without having to use netcat as a shim between the TCP socket and Wireshar/tshark. I was hoping that there was an extcap solution for this, but I'm guessing I might be out of luck there :( /erik Den mån 31 jan. 2022 kl 14:02 skrev Dario Lombardo : > You can have a look at udpdump, which doesn't use TCP but UDP, but it may > fit your purpose. > > On Mon, Jan 31, 2022 at 1:57 PM Erik Hjelmvik > wrote: > >> Hello folks, >> >> Is there some way to read PCAP-over-IP in Wireshark? I.e. read a PCAP >> stream over a TCP socket. >> >> Currently, the best solution to read PCAP-over-IP in Wireshark is by >> using netcat to read the PCAP stream and forward it to Wireshark's STDIN >> like this: >> nc localhost 57012 | wireshark -k -i - >> >> But it would be much nicer if this data could be read directly without >> having to use netcat. Maybe as an extcap interface? >> >> Best regards, >> Erik >> >> ___ >> 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 >> > > > -- > > Naima is online. > > ___ > 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 > ___ 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
[Wireshark-dev] PCAP-over-IP in Wireshark?
Hello folks, Is there some way to read PCAP-over-IP in Wireshark? I.e. read a PCAP stream over a TCP socket. Currently, the best solution to read PCAP-over-IP in Wireshark is by using netcat to read the PCAP stream and forward it to Wireshark's STDIN like this: nc localhost 57012 | wireshark -k -i - But it would be much nicer if this data could be read directly without having to use netcat. Maybe as an extcap interface? Best regards, Erik ___ 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
[Wireshark-dev] Adding GPS data from Kismet as Expert Info?
Hi all, I have discovered that Kismet can generate pcap-ng files that contain GPS coordinates stored in custom option fields. I've started thinking about how this GPS data can be represented in Wireshark or tshark. The GPS options are attached to standard Enhanced Packet Blocks, so they could be considered as meta-data for a frame. Would it make sense to show the lat/long coordinates from the Kismet GPS option as Expert Info (_ws.expert)? Or do you have a better suggestion of how to display this data? For reference, here is the definition of the custom Kismet GPS option: https://kismetwireless.net/docs/devel/pcapng-gps/ Best regards, Erik Hjelmvik ___ 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