I have few devices connected to wifi router, but pcap_dispatch() always returns 0 for wifi interface while live capturing on Mac OS X. The same code captures response in case of wired interface. Please clarify if I have missed any flag here.
If you are capturing in monitor mode, you will be getting native 802.11 packets, which do not look like Ethernet packets, so filtering similarly to Ethernet will not work.
Furthermore, if you're capturing in monitor mode on a protected network, i.e. a network using WEP or WPA/WPA2, everything past the 802.11 header will be encrypted, and you will not be able to filter on it.
So:
if you're on an unprotected network, try a filter such as
wlan dst 70:73:cb:c1:7c:61 and (arp or (vlan and arp))
if you're on a protected network, try a filter such as wlan dst 70:73:cb:c1:7c:61, and make sure the program that reads the packets either just blindly writes them out to a capture file or is capable of decrypting WEP or WPA/WPA2 packets (the only program I know of that can decrypt them is Wireshark, although some others might be able to do it as well).
Related
I have an application that is very simple. It sends out UDP packets to a client somewhere else on the network.
The host computer is 192.168.11.66 (Windows 10), the client device is 192.168.11.65 (proprietary device).
The host pc cannot see the client device, however I know that it is on and listening to traffic. When I send UDP packets from the host, I use Wireshark and I do not see the packets being sent out. Instead I see messages from ARP trying to locate the client. I assume because ARP is unsuccessful, the host cancels the sending of the packets.
If I change the destination address of the packets to a broadcast address, all of the packets get sent and I see everything on Wireshark. I need to be able to specify the IP address of the client and have Windows send the packets regardless of whether or not it thinks the client device is on the network or not. The client device looks for UDP traffic specifically addressed to itself and the client device has no way of making itself visible on the network.
Does anyone know how to work around this?
Thank you #Remy: instead to create your own ARP record manually. – Remy Lebeau
I did not realize that I could create manual entries in the ARP. I need to read more about ARP. Adding a manual entry solved my issue. I found that you could do it using ASP -s, or add neighbor using NETSH .
Thanks!
First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)
I'm using a macbook air with osx 10.8.4 and i want to sniff the packets in with same Wi-Fi network.
I installed the tcpdump and i can get my own machine's packages. But i can not get the packages of my iphone which is in the same wifi network.
I have done some research and find that i should use a param -I to start monitor mode. So i write a command
sudo tcpdump -In -i en0 host 192.168.1.102
192.168.1.102 is the ip of my iphone in the network. And after running the cmd, the wifi icon on my computer in the top bar add 'an eye' on it.
But unfortunately, when i surf the internet with my iphone, the tcpdump still shows nothing. Why?
If you capture in monitor mode on a protected (WEP or WPA/WPA2) network:
filters used when capturing that apply above the link layer, such as host 192.168.1.102, will not work, because the filter will be used with encrypted packets;
unless the program reading the capture can decrypt the packets, they will just show up as 802.11 Data packets, not as, for example, HTTP-over-TCP-over-IP packets.
tcpdump doesn't support decryption of encrypted 802.11 packets. Wireshark does, but, as the Wireshark "how to decrypt 802.11" page indicates, you need to supply the password for the network, you must either be using WEP or be using WPA/WPA2 Personal/Pre-Shared Key mode (WPA/WPA2 Enterprise/802.1X mode isn't supported) and, for WPA/WPA2, you must have, for any machine whose traffic is to be decrypted, the initial EAPOL handshake for the machine.
I am trying to modify a ethernet driver using WDK tools provided in Visual Studio 2012.
The samples provided in the WDK are 'miniport adapter' and 'NDIS Light Weight Filter' among others. I am still at the very beginning of driver writing and hence finding it tough to navigate through the code.
I was able to install the miniport adapter after building it in Visual Studio 2012 [Shows up as 'Microsoft Virtual Miniport Adapter' in my network adapters list.] I am able to assign it a IP address and Subnet mask also.[I found out that this does not connect to any physical device on my PC].
I also setup the 'Debug View' software to check the driver messages from my adapter.[ I used 'DbgPrint' statements in the code and then built it.] But, The debug messages are printed repeatedly.
1- Why are the messages printed again and again? The messages are from the 'datapath.c' file of the program and is from the function 'MPSendNetBufferLists'. ['Net Buffer' specifies data sent or received on the network.]
2- I setup Wireshark to capture the data on the adapter and it shows that there are requests from ARP,HTTP,SSDP,MDNS etc coming out of it. I am not able to understand what is actually talking to the adapter? and how can I stop it from talking?
I can use 'ping' to see if there is a connection on the IP address I have assigned to the adapter and it responds with a success telling all packets were sent and there was no packet loss.
My goal is to send and receive 'data' packets via a IP address to this ethernet adapter. ie- I want an application to connect to the IP address assigned to the adapter and talk to it.
3- Can I actually do it with the samples provided in WDK?
Any other suggestions or advice are welcome.
PS- I wasn't able to use the windows debugger built into Visual Studio 2012. I used 2 PCs and was able to connect and install the driver onto the 'target' PC but couldn't do anything with breakpoints etc. The code and Program just did nothing after installing the driver on the 'target' PC. Any suggestions on this?. I thought I could do step-by-step debugging of drivers also.[I know I am wrong].
Thanks
Aditya
NDIS miniport drivers, like many low-level drivers, are meant to talk to hardware. The miniport's responsibility is to take send packets from the OS, translate them into whatever format is required by the hardware, and instruct the hardware to send the packet on the wire.
The WDK could (and in fact, used to) include a real-world sample driver that sends packets on real-world hardware. But this leads to some confusion, since real-world drivers have to deal with lots of hardware-specific details that distract from the main point of the sample. If you starting from a real-world driver, the first thing you'd have to do would be to identify all the hardware-specific bits and rip those out, so you could replace them with your own hardware-specific bits.
Instead, the "netvmini" sample in the WDK is a fake driver. That means it pretends to have actual hardware, but secretly it's all a lie. When the OS sends packets to netvmini, the netvmini driver will simply broadcast those packets to any other netvmini miniport adapters installed on that machine. (In effect, installing 2 netvmini adapters on the same machine simulates what would happen if you had two real adapters plugged into the same Ethernet hub.) So in ASCII-art, this is what happens if you install two netvmini adapters on the same system:
TCPIP TCPIP TCPIP
| | |
Real physical miniport Your netvmini #1 Your netvmini #2
| \ /
[The Internet] [The netvmini virtual hub]
As hopefully the ASCII-art illustrates, your netvmini adapters don't have any path to the Internet. So your driver won't get a "real" IP address that can route to the Internet until you add in details of your hardware. Until then, Windows will just keep trying to send ARPs and HTTP requests that will never go anywhere.
To answer your specific questions:
The messages from MPSendNetBufferLists are printed every time the OS attempts to send a packet. Because the OS thinks that you have a real network connection, the OS will make several attempts to use it. Eventually that should quiet down a bit, when everything comes to the conclusion that this isn't a useful link.
The requests are coming from TCPIP. If you don't want TCPIP to send data, then unbind it from the adapter.
You can definitely send data to the adapter. In fact, you've observed that you're already sending random HTTP packets and etc. But the data won't actually reach the Internet, until you teach the driver how to talk to your real hardware.
If you're sitting there thinking "but I don't have hardware!", then you might want to create a virtual miniport of some sort. Virtual miniports are like netvmini in that they don't have real hardware, but they still do have some way to get the packets off the machine. For example, VPN miniports that operate at layer-2 (like L2TP) will typically install a second driver — an NDIS protocol driver — that sends and receives data from the "real" physical miniport. Then the virtual miniport talks to its protocol whenever it needs to get packets off the machine. The result is:
TCPIP
|
Your virtual miniport
|
Your NDIS protocol
|
The real physical miniport
|
The Internet
There are alternative architectures; for example, a VPN that operates at layer-4 (like SSTP) might decide to open a WSK socket instead of implementing an NDIS protocol driver:
TCPIP
|
Your virtual miniport
|
WSK socket
|
TCPIP
|
The real physical miniport
|
The Internet
I am writing my own program, which will be running on a 802.11 AP, to capture all the outgoing beacons on the AP. But I just noticed I cannot do it with the current libpcap: the program couldn't capture any outbound beacons. I've also tried Wireshark which gave the same result.
My questions are:
Can anyone shed some lights on the causes of what I saw?
Is there any user space method that I can capture the outbound beacons of a 802.11 AP on that specific AP (rather than capturing on other PCs)? It is better for me if I can do this without hacking into the wireless driver.
I am using Ubuntu 10.04 as the OS, Madwifi as the wireless driver.
Thanks, folks.
I would guess that the WiFi chip is generating the beacons autonomously
so they never pass the driver-chip interface where libpcap intercepts
packets. You'll probably need a second radio to be able to capture the
beacons from the air (when the primary radio is busy sending a beacon
the receiver is turned off so it can't hear what it is transmitting).
You can Capture those packets(Beacon ,Acknowledgement,etc) in wireshark
all you need to do is following :
go to capture menu
after selecting your interface go to option
select the per packet information option in link layer type of your interface
press start