(Apologies: I uninstalled and reinstalled WinPcap and now I can see the extra interface! Suggestion found in Wireshark FAQ. I leave the original question below.)
I use WireShark to examine ethernet packet contents at the byte level (in/out of custom FPGA-based hardware). I have a USB-Ethernet adapter to add a second Ethernet port to my laptop. It was a cheap Chinese device bought on Ebay but now that I've found an appropriate driver, it works OK. However, I see that, on Windows, WinPcap/WireShark doesn't support Ethernet capture over USB.
While it would be nice if WireShark could be made to work on USB capture, I'm really looking for an alternative way to grab the raw ethernet bytes. I have some perl scripts set up that operate on the raw frames output from tshark, (Wireshark command line) and I could easily feed it from any stream of frames/bytes.
Is anyone doing something similar or is there a tidy way to output the raw bytes?
Sniffed raw USB bytes would be OK, but it would be nicer if someone has already programmed/scripted extracting the Ethernet frames. I'm using perl but any compiled app or python or C# or C++ or .. would be fine.
You mentioned python, scapy can do a LOT of raw packet things, might want to look at that. From their git:
Scapy is a powerful Python-based interactive packet manipulation
program and library.
It is able to forge or decode packets of a wide number of protocols,
send them on the wire, capture them, store or read them using pcap
files, match requests and replies, and much more. It is designed to
allow fast packet prototyping by using default values that work.
It can easily handle most classical tasks like scanning, tracerouting,
probing, unit tests, attacks or network discovery (it can replace
hping, 85% of nmap, arpspoof, arp-sk, arping, tcpdump, wireshark, p0f,
etc.). It also performs very well at a lot of other specific tasks
that most other tools can't handle, like sending invalid frames,
injecting your own 802.11 frames, combining techniques (VLAN
hopping+ARP cache poisoning, VoIP decoding on WEP protected channel,
...), etc.
Scapy supports Python 2.7 and Python 3 (3.3 to 3.6). It's intended to
be cross platform, and runs on many different platforms (Linux, OSX,
*BSD, and Windows).
Check them out at https://github.com/secdev/scapy
I don't have a Windows PC readily at hand to test, but as far as I can tell, there is no problem capturing Ethernet frames in Wireshark on Windows, from a USB-Ethernet adapter.
What you can't do, is capturing USB bus traffic, but that is not what you wanted, right?
To clarify, just select the USB-Ethernet device as you would any other, and you are set.
Related
Is it possible to dump contents of tcp recv/send to a pcap file and then have wireshark analyse this. I want to do this because I want to log an applications conversations in order to debug issues but I don't want to have to write my own parsers (wireshark already supports it) and don't necessarily trust the application to parse frames correctly.
What follows is based on work that I've done exclusively on Windows.
I can't speak to how well any of this might apply to other systems.
FWIW, I would suggest editing your question (or at least tagging it)
to be more clear about what OS you're targeting.
If you are talking about writing what's received directly from a TCP client to a pcap file, the answer is no. The pcap file format requires at least some networking headers, e.g., the IP and TCP headers, in order for the file to be valid.
There are four approaches I see.
You could fake these headers for each read from the socket. This wouldn't necessarily require a lot of work, but it would require some knowledge of the relationships between the network header, the transport header, and the payload (i.e., your data) in order for everything to work right. If you're only interested in analysis of the payload in Wireshark, this might be a valid approach. However, if the analysis you're wanting to do in Wireshark is network analysis (i.e., analysis that includes the network headers), then you'll want to avoid this option and figure out how to capture the network headers directly.
You could use a raw socket to capture network traffic at the network layer. This will give you the IP packet - IP header, TCP header, and payload. You could dump this to a pcap file using LINKTYPE_RAW as the link-layer header type, and Wireshark will read the file fine. I've used this approach before.
The third approach would be to use WinPcap to collect your data. This is the same software that Wireshark uses behind the scenes to collect the data, and it's the approach I'm using now. If you have Wireshark installed, the WinPcap is already installed, too. WinPcap has a simple API with numerous examples for opening an interface, collecting the data, and dumping it to a pcap or pcap-ng file.
The fourth option is the simplest...just use Wireshark to collect the data simultaneously with your application.
HTH.
Is it possible to read the bits directly off the physical ethernet connection interface from a standard computer ethernet interface?
e.g., suppose I want to use the ethernet jack of a laptop as a differential logic probe(using a standard ethernet cable). Could I just potentially write a driver to get at the bits or is there a limit to how low a driver can go?
Essentially does the physical layer just send the bit stream to the device driver or does it do any decoding which will effect the interpretation of the bits or cause the device to malfunction(such using a different encoding scheme).
I guess what it boils down to, is, can we use the ethernet port as any standard digital differential communications link by writing a suitable driver or are we limited to the the ieee spec(8b/10b, etc...).
To answer shortly, probably not.
Here are some of the reason why:
On a hardware link layer, there is actually no electrical connection between the computer and the ethernet cable, it is electrically isolated by small transformer and is current and not voltage driven signal, so this will be the first problem to overcome, as you would have to send a fairly precise current over two lines rather than a voltage on a single line.
Ethernet transformers
PHY Hardware Interface: Then the next step, is that this is simply not controlled by the CPU where your code is being executed but by an ethernet PHY Chip interface, and there you have no (easy) way of flashing and controlling it. Some different PHY chip allows you different level of access, but I doubt you would find any that would allow you direct control over the transmission interface and even if it did, it would have to be implemented into the driver which is as well unlikely.
Ethernet PHY Controller
Perhaps some other solutions
as the comments above, if you want to have direct IO control on a computer, the best solution is over a serial or parallel port, perhaps you can find ethernet to serial or usb to serial port and then play with that but this would be digital signals.
Another thing you may want to use is the microphone input, as this accepts analog signals and you can have direct control over it, though be careful not burning your computer. (I've seen some bank card magnetic band using that on cellphones).
You can use libpcap/WinPcap to do this. Nevertheless you are not completely free in the choise of what you write/read on the wire. e.g. preamble and SFD must stil be there. This is so fundamental (because of noise resistance), that typical hardware just does not support anything different.
If you want to control completely everything, go to embedded hardware, find a board that uses a PHY that can give you that information and a processor that is capable of handling the data rates.
I'd like to be able to intercept/ modify data in tcp flow, on the side of tcp client. Examples for pcap show how to parse tcp packet header/ payload.
But suppose, i want to modify packet payload before tcp client reads it, or drop the packet entirely. How can i do that with pcap capure?
As above, you can't do interception/modification with pcap. For this you need one of the following OS-dependent techniques:
Linux: libnetfilter_queue + iptables
MacOS, FreeBSD: divert sockets + ipfw
Windows: WinPkFilter (commercial), WinDivert (LGPL), or write your own NDIS IM or WFP call-out driver.
(usual disclosure: WinDivert is my project).
Scapy used in conjunction with python is a very good tool cum library.
You can do all sorts of packet monitoring and editing via command line
Also you can build applications on top of scapy to do a specific task.
Scapy
You can't do that with libpcap or WinPcap; libpcap is built atop OS mechanisms that do not support that (those mechanisms exist to support passive packet capture and low-level packet capture and injection, not to support packet modification in the packet input and output path), and WinPcap's driver is built atop an OS mechanism of that sort.
You would have to find some mechanism, in whatever OS you're using, that supports tapping into the networking stack in a way that allows the tapping program to modify packets as they pass through the networking stack. Such a mechanism might not exist on some OSes; on OSes where it does exist, if there are any, it's probably very OS-dependent. (The mechanisms libpcap uses are also OS-dependent; libpcap exists, in part, to hide those differences from applications, to the maximum extend possible.)
Does anyone know why should I use Winpcap and not just .Net sockets to sniff packets on my local pc?
TY
Sockets (.NET, Winsock, etc.) normally collect at layer 7, the Application layer. That is, whatever is sent by the sender is what is received by the receiver. All of the various headers that are added automatically on the sending side are stripped off by the time the receiver reads the data from the socket.
It is possible to configure a socket to be a raw socket, in which case, you can see all of the headers down to layer 3, the Network layer. Further still, you can put the raw socket in promiscuous mode, which allows you to see all of the traffic on the network, not just the packets destined for your machine. But even this is limited. For example, when you configure the raw socket, you specify the protocol type to use, e.g., IP, ICMP, etc. This limits the socket to "seeing" packets that adhere to that protocol. I have been unable to figure out how to make the socket see all packets at layer 3 regardless of protocol.
Winpcap operates as a device driver at layer 2, the Data Link layer. In this case, you see literally all of the packets on the network with full headers down to layer 2. Winpcap also offers filtering capability so you can narrow down the packets that are reported to you based on whatever criteria you provide.
As far as choosing between them, it really boils down to the requirements of your specific task. If you are trying to implement any kind of realistic network analysis capability, you'll be hardpressed to do that with just sockets. Winpcap makes more sense in that case. However, if you are only interested in IP packets, for example, then sockets will work fine for that.
As far as I understanf .Net sockets are an IPC to communicate between 2 processes. While winpcap is a library that help you to access the data link layer an sniff pacquets going through your network hardware (or virtual) devices on your machine. Data link layer allow to get the data on any socket (.Net or not) created on your system.
I wanted to access the original value from the ethernet, actully by some hardware programming i am sending a value to system via ethernet ,but it's not possible to access what exactly i'm going to send
You could use a packet sniffer like Wireshark, running on either source or destination system. This will let you examine packets as they leave or enter, respectively.
It sounds like what you need is a protocol analyzer. On Windows, look at Microsoft's Network Monitor.