I'm writing an application in C using airpcap and pcap libraries. I want to ask if there is a ready function to check the CRC (FCS) of received packets or whether it must be calculated manually. In airpcap's Control Panel you can setup the FCS filter.
One of the functions of the application will be something similar to site survey. I want to ask how to list discovered networks in order not to duplicate them. Compare the ssid or maybe there is a simpler way; is there some parameter which is unique to a network?
First I would check whether the driver is providing the OS with the invalid frames. If your driver is capable of providing these invalid frames - then the rest is up to you. Checking the code of aircrack-ng (or a different tool) should give you an idea.
Side note for site survey: I would focus on identifying different BSSIDs which should give you idea about the radios in the neighbourhood. Same SSID can be used for many overlapping BSSes (of course at some point you'd be needing it as well). Have a look at the different 802.11 frames (start with something easy - like Beacon Frame).
Wireshark has a CRC-32 function that it uses to check Ethernet and 802.11 FCSes when available; check out its Ethernet and 802.11 dissectors. It's licensed under the GNU Public License, Version 2.
Related
I'm trying to do the same protocol that is defined and described here in that wiki
https://wiki.trezor.io/Developers_guide-Message_Workflows
My toolset is Protobuf for embedded systems: Nanopb.
STM32F7 using Serial port.
I'm trying to communicate right now between PC and STM32F7, and usually the communication will be done between two STM32F7 boards.
My questions:
What kind of protocol that is sufficient for a request and answer like the one in trezor ?
I googled and I found I have to use something like HLDC, is it necessary for that purpose or it's an overhead ?
Coding and design issue: I will fire a serial interrupt that always polling for the data that is communicated between two boards, now there will a very big state machine to decode each message type and do the event based on the message type. Is there an alternative design ?
Firstly, AFAIK, nanopb doesn't support the full range of possibilities in the Protobuf schema language. So you'll need a schema that works for nanopb, and hopefully that'll be good enough for the needs. However it can be very annoying as (so far as I know) the very useful oneof doesn't work.
Secondly, protobuf wireformat is not self delimiting. So you'll be squirting data down the serial cable, but it's not possible to reliably (if at all) tell where one message ends and another starts. So you'll need to transmit some sort of inter-message sync pattern of bytes, chosen to be unlikely to be encountered in a message. You'll have to read in the bytes inbetween sync patterns, place them in a buffer, and parse from that.
Thirdly, if you're sending a variety of different messages and you can't use oneof, then you'll need some other way of identifying what type of message has arrived so that you can parse it to the right type of object. That "way" could simply be a fixed sequence of message types, or a byte whose value identifies the message type, or a field that does the same thing in all the messages. oneof is attractive (though not available to you) because it can be used as a carrier for a variety of different message types; you simply parse the received data using the oneof's parser.
I am looking to implement some kind of transmission protocol in C, to use on a custom hardware. I have the ability to send and receive through RF, but I need to rely in some protocol that validates the package integrity sent/received, so I though it would be a good idea to implement some kind of UDP library.
Of course, if there is any way that I can modify the existing implementations for UDP or TCP so it works over my RF device it would be of great help. The only thing that I think it needs to be changed is the way that a single bit is sent, if I could change that on the UDP library (sys/socket.h) it would save me a lot of time.
UDP does not exist in standard C99 or C11.
It is generally part of some Internet Protocol layer. These are very complex software (as soon as you want some performance).
I would suggest to use some existing operating system kernel (e.g. Linux) and to write a network driver (e.g. for the Linux kernel) for your device. Life is too short to write a competitive UDP like layer (that could take you dozens of years).
addenda
Apparently, the mention of UDP in the question is confusing. Per your comments (which should go inside the question) you just want some serial protocol on a small 8 bits PIC 18F4550 microcontroller (32Kbytes ROM + 2Kbytes RAM). Without knowing additional constraints, I would suggest a tiny "textual" like protocol (e.g. in ASCII lines, no more than 128 bytes per line, \n terminated ....) and I would put some simple hex checksum inside it. In the 1980s Hayes modems had such things.
What you should then do is define and document the protocol first (e.g. as BNF syntax of the message lines), then implement it (probably with buffering and finite state automaton techniques). You might invent some message format like e.g. DOFOO?123,456%BE53 followed by a newline, meaning do the command DOFOO with arguments 123 then 456 and hex checksum BE53
i'm writing a C program to manage certain aspects of a wireless network (Access Point + Client Devices)
One Part of the program runs on the Devices an another runs on the AP. The AP is a simple Linux-Station (a Cubietruck, later on exchanged with a Intel Celeron holding Board; Access Point setup with hostapd and dnsmasq)
Some features are already implemented. I've done a lot with cfg80211/nl80211 and a bit with Wext and some Communication Routines over BSD Sockets are standing.
But now a problem came up. In the C program running on the Access Point i need the Received Signal Strength of the associated Devices.
On the Devices everything works well. With nl80211 i can get nearly every information about the connection. But on the Access Point i don't know how to obtain the RSS. I've tried some nl80211 requests with some attributes but can't get it to work.
Sure, on the Devices it's easy, because they have a single connection. But on the AP i had expected something like a nl80211 answer with a linked list or nested attributes, but nothing. I checked the contained attributes of the answers from certain requests and the messages contain nothing usable.
Does somebody know how to solve this? It shouldn't be a big deal like that to obtain the Received Signal Strength of the associated devices on a WLAN AP.
Would be really nice if it were doable with nl80211 but another solution would also be welcome.
Maybe with some WiFi Package Parsing? I heared that there is something like a RSSI (Received Signal Strength Indicator) but i'm not familiar with it.
Thanks in advance
Here's a wrokaround: the wireless channel attenuation from AP to a station/device and from that station to the same AP are identical at the same time. So, if transmission power of AP and stations are all the same, stations may report their RSS to AP using you current solution, and the work is done. Surely tx powers at different stations may be different, but they are constant. So find them out and make adjustments accordingly. Here's a simple example:
AP tx power 20 dBm;
Station 1 tx power 15 dBm with RSS -37 dBm;
Then the RSS from station 1 to AP link should be -42 dBm
I have two usb devices that are recognized by the ACM driver and I’m developing a program in C to communicate with them. As the command for each one are different, I need to know the name given for each one (usb/acm/X).
How can I get this name given the vendorId and productId? I have tried parsing dmesg text but in some cases I may have the two lines “ttyACMX: USB ACM device” one after the other.
I could parse the order each device shows its name in dmesg and take the same number in the “ttyACMX” but this force me to parse also the disconnections messages and all becomes a bit dirty.
I’ve seen that the information I need is in the structure tty_driver created for each device and I’m sure I can have this information easier than parsing dmesg.
Can someone point me out int the right direction?
libudev (C) might be a solution, also have a look at the source of ModemManager daemon (C, glib based)
Use libudev or some higher-level library like gudev (GLib-based libudev). Don't use ModemManager unless your devices are really mobile broadband (2G/3G/4G) modems.
I found this thread to be helpful: http://forum.pololu.com/viewtopic.php?f=16&t=6741
You can make a udev rule file in /etc/udev/rules.d that has a rule like this:
KERNEL=="ttyACM0", SUBSYSTEM=="tty", SUBSYSTEMS=="usb",
ATTRS{idVendor}=="1ffb", ATTRS{idProduct}=="008c",
ATTRS{serial}=="00053419", MODE="0666", SYMLINK+="TTYS_002"
I think this will make a device named /dev/TTYS_002 when you plug in a CDC ACM device that has the specified vendor ID, product ID, and serial number.
I'm working on an embedded system, and I need to determine if the user has connected an HID device emulating a keyboard (i.e. a barcode scanner) or an actual keyboard.
I can inspect the iManufacturer, iProduct, iSerialNumber, and iInterface string descriptors to gain some clues. For example, "reader" or "scanner" has been observed to appear in the iProduct string when a barcode reader has been connected. Likewise, "emulation" has been seen in the iInterface string. However, I'm a bit reluctant to rely solely on these strings (string case is easy enough to handle, but handling things like abbreviations in key words/phrases quickly becomes onerous.)
I've reviewed the USB 1.10 and 1.11 specs and found that the Report descriptor offers some cues, as well. For example, the Global Usage item should be something like 0x0501 for Generic Desktop, and the Local Usage item should be 0x0906 (Keyboard). Is there anything else in the Report descriptor that might assist in detecting the difference?
I would like to avoid relying on the Vendor ID and Product ID lists since this is an embedded system with limited resources. Suggestions? Is there something I've missed?
There is no absolutely reliable method to do this. There cannot be, because there is no absolute definition of what is or is not a keyboard -- nor of what the difference is between "emulating a keyboard" and "being a keyboard". The boundary gets particularly fuzzy around assistive devices and things like chording keyboards, but even beyond that, you have the fundamental problem that the way to emulate a keyboard is to communicate across the USB cable in exactly the way that a keyboard communicates.
The methods you've suggested are reasonable heuristics for identifying a number of things that are clearly non-keyboards (with a faint risk of false positives in some cases), but heuristics that look for hints are the best solution that's going to be possible.