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
Related
I am looking at implementing USB communication on a MCU which has a USB engine built into it. Basically you have access to the pipes/endpoints.
I am a little bit confused on the USB stack now. It appears that drivers operate on another level above the pipe/endpoint setup, so the pipe/endpoint is like a middle level layer that drivers are built on. Is this correct?
Secondly, I am interested in simulating serial communication over USB. It appears windows has a premade driver so on the computer side I do not need to program the pipe level.
How do I find out what I need to implement on the MCU to make it behave correctly with the generic serial driver?
This is an answer to your second question regarding the serial communication.
The USB standard defines a communication device class (CDC) for serial communication. The required drivers on the host side are implemented by Windows, macOS, Linux and many more operation systems.
The relevant CDC subclass is PSTN. The relevant documents are found in Class definition for Communication Devices 1.2.
The device basically implements four endpoints:
Control endpoint for configuration requests (baud rate, DTR state etc.). Have a look at SetLineCodeing, GetLineCoding and SetControlLineState.
Bulk endpoint for USB to serial transmission
Bulk endpoint for serial to USB transmission
Interrupt endpoint for notifications (DCD state, errors). See SerialState.
And of course you need to get the device descriptor right.
On top of that, you need to implement all the standard USB requests.
Chances are high that this has already been written for your MCU, both the standard requests and the serial communication. So why not use the existing code?
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 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).
I`m working on a project about Man In The Middle Attack by ARP poisoning method.
In this project I need to work like as a router. For example suppose In My Lan there is two other device (a modem & a laptop). I says to laptop that I`m the modem to fraud it. whenever the laptop wants to send a packet to outside of the LAN, sends the packet to me!
All thing I need is I want to send the received packet to the modem & sends the response to victim laptop.
How can I do it programmatically?
Thanks a lot.
Ya Ali.
Well the first thing you need to do is perform the ARP poisoning attack. You can review how to do this in detail here.
One thing of note is that your middle-man PC must how be able to perform like a switch and forward out packets it receives in - It will be passing packets between the modem and the laptop in both directions.
My application communicates with several GSM electric controllers, that means that I have to send anywhere between one to twenty messages every few hours. right now I'm working with HUAWEI Mobile Connect - 3G. it is a USB device that uses a comm port for the pc communication and I'm using GSMComm to send messages and read/delete messages from the device.
Every two seconds I'm checking the device's storage, and if there is any message, I will then read it and store it locally and then clear the device's storage. I'm not sure if I'm working correctly, but it seems to me as if it is a very unreliable device:
Every time I boot my machine, I must remove the device from the USB or my machine will get stuck at the BIOS start up screen (or whatever the name is).
Very frequently the comm port can become unavailable for some reason. I have to close and re open the port, and at times that may not even help.
In the production machine of my client, when he uses one of his software's that utilize the first comm port, he will get a warning message from the software about problems in the port if the device is plugged in (the device port is around 28 or something).
If you've been using a device which you consider reliable, or have been working with the same device as I work with, or you just think that I'm doing it wrong, I'd like to get an advice from you.
Thanks.
This sounds like an issue with your modem. Have you tried any other models? Consumer USB models tend to be unreliable. The preferred method, though slightly more expensive, is using a commercial grade modem in situations where you need the reliability.
Some modems to look at:
Wavecom Fastrack
Sierra Wireless Airlink
These use a serial port or ethernet to communicate with the host which is far more reliable. Serial ports may not be available in your particular situation but even a USB to RS232 adapter will be more reliable.
One further option is to use a smartphone, there are several applications that you can act as a gateway through HTTP.
SMS Gateway for Android:
https://market.android.com/details?id=eu.apksoft.android.smsgateway&hl=en
i have not used this method, but it seems like some people are having luck with it. it may not be any more reliable then your USB modem though.
Hope that answers your question.
I have used WaveCom's modem for sending messages in bulks and found it to be reliable. One difference though, in my implementation was i used Kannel as an SMSC, so my queues were automatically handled by Kannel. But sending multiple requests like 40+ per minute didnt pose any problems for me.
Hope this helps.