I try to get the channel width of networks so I'm using WlanGetNetworkBssList to retrieve a list of BSS entries of the wireless networks on a wireless LAN interface but I don't see any information about the channel width. It's kinda trivial to get the channel center frequency to obtain the number of used channel and many other information but the channel width seems to be an obscure information stored somewhere in IE data blob of BSS entry structure. I managed to get some information about the width of the channel from HT and VHT Operation information elements but doesn't seem to be enough. I found on Github a python wrapper that extract info from Extension information element but it's not clear from which one since IE data blob of BSS entry structure might have more IE Extension elements.
For example I have 5 different IE Extension elements:
FF 1A 230108080E00580C2F4EC96FC927DE018F00FAFFFAFFFAFFFAFF
FF 07 24E43F003CFCFF
FF 03 272500
FF 0E 260600FFFF20FFFF40FFFF60FFFF
FF 02 252A
I found some basic information about HT Operation and VHT Operation information elements but nothing about Extension information element.
Where I can find the specifications for these information elements of AP beacon frames?
Related
I need a Read Tag command for NFC Tag ISO 14443-3A type.
For example - we can get UID using FFCA0000.
I am using FEITIAN reader BR500 and their SDK.
http://www.pcscreader.com/docs/ios.html
https://github.com/FeitianSmartcardReader/FEITIAN_MOBILE_READERS
I can use NFC Tools iOS app to read and write tags. But when using FEITIAN sdk I need to send APDU command to read the tags written.
So is there any command to read tags? Is there any documentation?
An ISO 14443-3A type NFC Tag can only provide the UID (and a few other parameters that are some times used to identify card types) as part of the multiple card anti collision handling process.
NFC cards use various different higher level protocols to transfer their actual data content, therefore there is no ISO 14443-3A command to read a Tag.
ISO 14443-3A is more RFID than NFC (there is a overlap)
The below picture is an overview of the different NFC protocols used
The APDU command to read data is
CLASS INS P1 P2 LC
FF B0 00 XX YY
where XX is block number, YY is the data that will be read from card, the data size is 0-16
For example:
ffb0000410 will read block 04 and 16 bytes.
ffb0000510 will read block 05 and 16 bytes.
I am unable to understand the CANopen Protocol. I am aware of the working of CAN and how a CAN frame looks like. A CAN data or remote frame contains the Start of Frame , Message Identifier Field, DLC, RTR , Data(Payload), CRC , ACk fields, etc. I am aware that the CANopen standard utilizes the CAN bus to send the CAN messages. However , the way in which a CANopen's CAN frame looks is different where it contains a COB ID+Node ID in the Message identifier field and in the payload field , it contains object dictionary related information. I would like to ask the following questions therefore:
How are the object dictionaries defined. I am aware that it is a
table containing an ID , sub ID, Datatype information about the data
it contains , the manufacturer information for the respective data
entry , etc . Are they all hard coded as an m*n multidimensional
array in the software stack?
I am confused with the terms transmit PDO and Receive PDO. Is it similar to CAN data frame and CAN remote frame ?
What is PDO mapping and how can i identify which object ID in the object dictionary is mapped to which object ID in the PDO mapping
table. Both use the same terms Object ID ?
I am actually very new to CANopen and i have asked these questions based on my initial understanding. I was unable to find a detailed explanation in the CiA website.
Thank you in advance
Krishna
It is not so easy to understand it!!
CanOpen is a communication between Master (client) and Slave (server).
An device like a sensor is a Slave.
The slave has an OD (object directory). The manufacturer provides all informations about it. Ex. if i want to read the temperature, its location is at adress 0x2040 at sub index 00. Then the master (our system) needs to make this request. To do this, you need to configure the device by sending some request (with SDO) in order to change the TPDO1 mapping (0x1A00) and TPDO1 communication parameters (0x1800). And be able to receive by the device the temperature. The device will not work alone.
SDO (read/write) allows OD access entries. Ex. change the TPDO1 mappings.
PDO is the output/input to the device once operational.
There is NMT Master commands to put the device in operational mode or to send a SYNC or Heartbeat. Depends what the device needs?
Ex. 080h 00 : SYNC send by master
280h 06 E5 EF 02 00 00 00 : response of device by TPDO2
000h 02 01 1F : put the device with ID = 1F in operational mode
If you want a good example device POSITAL FRABA absolute rotary encoder with can open interface.
Hope this will help you a little bit!!!
I have connected OBD2 and getting the can data (11bit 500kpbs CAN) using atmel can controller.
I get data.
Now, how do I get the mode and PIDs from this data?
For example, my data looks like this:
15164A8A-FF088B52 -- Data: 00,00,00,86,9C,FE,9C,FE,
I could see RPM changing, ignition on/off etc... on the data fields.
I don't want to use ELM chips. I need to handle the raw data directly.
HINT: All of my numbers are in HEX.
OBD2 protocol sends you responses in bytes (8 bits). responses are subdivided into header (or called ID as well) and data.
IDs are the address of the ECU and data is "response data" from ECU and it is always 8 bytes (in CAN Bus protocol?!).
8 Bytes of data will be divided into PCI (which can be one or two bytes) and values. PCI will show you what is your frame type (single, First, consecutive or flow control frame) and how many bytes are incoming.
to make it easier I make an example only for single frame:
you might send an OBD request to main ECU like this:
7DF 02 01 0C 00 00 00 00 00
7DF is ECU address for diagnose tester device.
02 is number of sending data bytes
01 is the mode (which you might be interesting in!) 01 is current data, 02 is freeze frame and etc.
0C is rpm PID.
The response from ECU would be something like (single frame):
7E8 04 41 0C 12 13 00 00 00
7E8 is the ECU that responding.
04 number of incoming data bytes.
41 the data are in response to 01 PID
0C response to this PID
12 13 are two byte in response to 0C. Please keep in mind that you have to decode these two bytes with OBD II ISO protocol. you can also find some of conversion rates on Wikipedia.
Other bytes are useless.
To make it short: you have to parse each response from ECU and try to convert the useful bytes to readable decimal value. It depends on which programming language you are using. in C/C++ the best practice in my opinion would be unsigned char which is guaranteed by compiler to be 8 bits and in JAVA it can be Byte. Moreover, try to use bitwise operators to make your life a bit easier.
By more questions do not hesitate to ask.
My project contains a Sender/Receiver framework that can only talk one-way , there is no a return channel from the receiver to the sender.
The sender compress part of the data it's send to the receiver using zlib.
I want to make my receiver resilient to crashes/reboots/restarts, is it possible to join the zlib stream from a random point somehow?
Both Sender/Receiver using Z_SYNC_FLUSH.
Some ideas I had:
Saving state structures to disk and reload them after restart of the receiver.
Replacing Z_SYNC_FLUSH to Z_FULL_FLUSH.
I tried saving the first chunk of zlib compressed data, restart the receiver and than resend the first chunk again and after that continue the stream from a random chunk and it seems to work - I don't understand why, is it a solid solution or it was just a luck?
Replacing to Z_FULL_FLUSH didn't seem to make any difference.
Is there another way to work around this? Do you think I missed something?
Thanks a lot,
Jason
To assure that you can start decompression at some point with no history, you must either use Z_FULL_FLUSH or simply end the stream and start a new one.
For the former you could do a Z_SYNC_FLUSH followed by a Z_FULL_FLUSH in order to insert two markers resulting in the nine bytes 00 00 ff ff 00 00 00 ff ff, which would be unlikely to be seen randomly in the compressed data. You can do the same for the latter, simply inserting a large-enough marker between the end of the previous zlib stream and the start of the next zlib stream.
I'm trying to parse 802.11 frames myself and I've encountered two problems that I can't solve.
First of all, when does an LLC (Logical Link Control) header follow a IEEE 802.11 data frame ? I thought when there is data in a frame, there would always be an llc overhead preceding the data, but I have a wireshark with Ethernet II instead of LLC. But I have no idea how to actually know if it's gonna be an LLC or a Ethernet II header following my 802.11 data header. There's no field in the 802.11 header specifyin what's following.
Secondly, I have noticed something in wireshark when I open a capture file containing 802.11 QoS data frames. At the end of the header there's the QoS control field, which is normal, it's specified in the IEEE 802.11 documentation (i've read it over and over again to try to find an answer to my question) But then, there's 2 bytes that wireshark considers part of the 802.11 header (when you click on the raw bytes, wireshark points to the 802.11 header, but the signification of the bytes is not displayed in the fields of the header ! Does my question make any sense ?
Here are images to explain what I'm not understanding. On the first screen shot below, you see the 802.11 header selected and you see below the concerned bytes in hexadecimal.
Pay attention to the last bytes of this packet:00 00 10 aa
Now I expand the 802.11 header and click on the very last field of it (QoS control, as specified in the RFC). You can see that the corresponding bytes are 00 00. But those bytes are not the last bytes of the packet ! There still is 10 aa that's part of the wifi packet but I have no idea what those bytes represent !
Any one has an idea ?
First of all, when does an LLC (Logical Link Control) header follow a IEEE 802.11 data frame ?
There should always be one, although things might be odd for aggregate packets. If you capture on an 802.11 interface and you're not capturing in monitor mode, you might see the packet begin with an Ethernet header, but that's different - that's the adapter and/or the driver translating the 802.11 header + LLC header into an Ethernet header.
But then, there's 2 bytes that wireshark considers part of the 802.11 header
That might actually be the "Atheros padding", "helpfully" inserted, in monitor mode, between the 802.11 header and the frame body by some Atheros network adapters. Open up the Radiotap header and see if the "Data Pad" flag is set in the Flags field; if so, the packet has "Atheros padding".