I am being confused on all terminology referring to it, so here is my request:
Name at least one USB Wireless Adapter whose Wi-Fi chipset is supported by a wireless driver enabling AP mode, Monitor Mode and PSM (Power Saving Mode) in a SoftMAC implementation (PSM functions accessible and modifiable via software).
The goal is to work on a new Power Saving Mode implementation, by modifying existing implementations of either PSM or APSM.
Check out MediaTek USB dongles:
http://www.mediatek.com/en/products/connectivity/wifi/pc/usb/
Most of these can work straight away using Linux mainline rt2x00 driver. rt2x00 is open-source, supports Monitor mode (can sniff packets), AP mode (can work with wpa_supplicant/hostapd), and is a SoftMAC driver (as it works with mac80211 driver). As for PSM, I'm not sure although there seems to be a good chance that rt2x00 supports it as well..
Related
I want to create a network intrusion detection system for iOS application. The main function is to allow the user to select a home network (maybe prompt them to simply enter the IP address only) and to be able to monitor the packets and if there is anything suspicious- we need to alert user via push notification or email. i wanted to use the features and functions of Snort, an open source network intrusion detection system.
Any Suggestions,Sample code ?! Where to start?
VM's do not have native hardware access, which is necessary for monitor mode. Maybe IOMMU PCI passthrough or bridged devices might work. It is probable that it is possible to compile the iOS kernel with a module that works for the wireless nic. I don't think it's a proprietary chip specific to apple, because a chip with multie technology capabilities in RF wouldn't be cost effective qt all. I'm just not sure if the filesystem blocks access in the OS framework or whatever. I have tried to compile linux/iOS ARM packages natively in the shell with the aircrack-ng source, but have not had any luck. Maybe someone would have better luck actually cross-compiling a package and sideloading it somehow.
I don't think this is possible for multiple reasons:
You wouldn't be able to compile snort for iOS.
In order to run snort you have to have the interface (NIC) in promiscuous mode, which I really don't think you can do on an iOS device (iPhone, iPad, etc) but I have never really looked into it, but Apple probably locks this down and restricts this for security purposes so if you could do it you'd likely have to jail-break the device first. It's not even possible to put the wifi card in an Apple laptop into monitor mode, which is similar.
There are a lot of dependencies for snort, most importantly the DAQ. You would probably only be able to monitor the wifi interface (even this might not be possible), not the interface used for the cellular network as this is probably a different daq than standard Ethernet nics.
This very likely is not possible on iOS, if it is it would be VERY difficult to pull off and even if you did the use case isn't really good. Even if you could get a daq for the cellular card, I don't know if promiscuous mode even exists and if it did all of the traffic on the cellular network is encrypted, so inspecting this with snort would be pointless. If you could do it for the wifi traffic it's probably not worth the effort honestly, especially since almost all traffic nowadays is encrypted, you'd have to decrypt it first, which certainly isn't possible to do.
In the view of Johnjg12's comments, I am wondering about your goal. If you want to make a NIDS, you can make it OS independent, anyway. If you want to consider only HIDS that monitors packet destined to it, we don't need it to be in promiscuous mode (a comment to Johgj12's response). so, now it is something to do with Snort on iOS. I am wondering if we can do it on a VM and then turning its promiscuous mode? Having said that I came across a link: https://www.securemac.com/macosxsnort.php
I'm trying to set up a Wi-Fi repeater on Ubuntu PC or embedded Linux with Wi-Fi dongles, using one dongle at a time. Drivers and firmwares for dongles are done and worked on my PC/embedded board for AP mode and station mode. Then what can I do next?
In my thought, I have to simulate 2 interfaces with only 1 dongle. Than run Hostapd on a interface, run wpa_supplicant on another interface. Is that a workable method? If yes, how can I "create" 2 interface with 1 dongle, say, wlan0/wlan1 or wlan0.1/wlan0.2 or something like that?
Is the whole scenario workable just through some operation about interface and system, or the scenario MUST be supported by driver of dongles, if driver doesn't provide this scenario, then it is impossible?
I tried it on Ralink Soc before(it's called ap-client mode by Ralink). On Ralink platform with its own SDK including Linux source and Wi-Fi drivers, it is done by iwpriv commands. There are interfaces call "apcli0" to work in station mode and "ra0" work in AP mode, but there is only 1 physical Wi-Fi interface built-in in Ralink Soc. It works just fine but I'm not using Ralink Soc now. Is that feature also available for other dongles?
After working on driver compiling, I got some idea.
The chip I'm using supports "dual mac" feature, and the driver must support this feature.
If the driver is successfully compiled, inserted and the dongle is plugged in, there will be 2 interfaces coming out, for example, wlan0 and wlan1. Therefore I can configure one interface as AP and another interface as station.
So the key point is the chip and driver must support dual mac feature.
Does exist a standard protocol for network printers? Some network printers require the installation of drivers to be used... Is there some network printer that can be used without installing additional drivers? After all, when we connect the network cable from the laptop to the router, we do not need to install drivers (any operating system already includes the driver).
Are there any open source projects related to protocols for communication with a network printer?
The standard protocols are the LPD or IPP protocols.
If you need to talk to a printer over the network, you can either attach it to a device that translates packets into USB/LPT commands, or attach it to a linux/windows PC and print through an LPD service running on that OS.
IPP Everywhere tries to be what you are asking for.
A PWG standard that allows personal computers and mobile devices to find and print to networked and USB printers without using vendor-specific software.
I have a Wi-Fi driver from a manufacturer. That driver has Plug and Play support. After the adapter has been inserted or removed, Windows CE has recognized it successfully. But at boot time, if the adapter is "inserted state", CE OS does not load it so I must remove then insert it.
I want to load the driver automatically during boot time. Is it possible?
Before, I've written a simple stream interface driver. I have edited project.reg to create a sub-key under HKLM\Devices\BuiltIn so that Device Manager can load automatically during boot time. And it was successfully loaded. But Wi-Fi driver is a non-stream driver. Can Device Manager load Wi-Fi driver automatically with the same way?
Are "all of drivers under HKLM\Drivers\BuiltIn" stream interface drivers? What differences are there between stream interface drivers and NDIS Wi-Fi drivers from the point of loading automatically during boot-time? I will very happy if you can explain it a little.
I want to load the driver automatically during boot time. Is it
possible?
Yes, it is definitely possible. That was the main purpose of plug and play devices. The WinCE device automatically loads a driver appropriate to the Plug 'n' Play device. There would not be any need for doing it manually. If so, then there is no need for a Plug 'n' Play functionality.
As this is not happening in your case, you could try the following
Have you checked with any other Plug-n-Play devices to the WinCE device?
Each time you plug-out and plug-in, is it installing the drivers or is it just loading? You can verify the debug logs to confirm this.
Are "all of drivers under HKLM\Drivers\BuiltIn" stream interface drivers? What differences are there between stream interface drivers and NDIS Wi-Fi drivers from the point of loading automatically during boot-time?
Actually, the block devices can also be loaded automatically, as similar to stream interface drivers. The HKEY_LOCAL_MACHINE\Drivers\BuiltIn registry key recognizes built-in block devices also.
You can refer this msdn link for further information regarding loading the block devices.
I am very enthusiastic in writing device drivers for a microcontroller(like PIC, Atmel etc).
Since I am a newbie in this controller-coding-area I just want to know whether writing device drivers for controller is same as we write for linux( or any other OS) ?
Also can anyone suggest some online device driver building tutorial for the same ..?
Thanks,
If you are thinking about developing the device drivers to interface your device with a host computer (probably using USB), then most of the microcontrollers nowadays implement default classes that rely on native drivers.
A concrete example:
If you use a PIC18F4555, you can use the regular HID (human interface device) windows driver to communicate with your microcontroller (given you implemented it correctly). No need to develop any driver.
Writing a device driver for an MCU is a pretty far cry from writing it for a OS. Most MCUs won't have an OS running on them at all. You'll generally end up writing some low level Interrupt Service Routines (ISRs) and filling up buffers, that your application software will end up emptying. You don't have to fit into any device driver paradigm that an O/S has defined. You basically have to read the datasheet for the device you are wanting to interface with and read and write to its memory over whatever interface it might use (e.g. SPI, I2C, UART, etc.). Ultimately the device driver ought to provide intuitive function calls to the application software.
If you are using AVR MCU like atmega then you can use vusb (https://www.obdev.at/products/vusb/index.html) for those MCU that don't have any HID and handles the interrupts by connecting D+ and D- pins of the USB to digital I/O ports of the MCU.
The atmegaU2 packages have their own USB communication ports and HID.