I have an iOS app that reads/writes on a BLE device. The device is sending me data over 20 bytes long and I see they get trimmed. Based on the following thread
Bluetooth LE maximum transmission size
it looks like iOS is trimming the data. That thread shows the solution on how to write bigger data sizes, but how do we read info larger than 20 bytes?
For anyone looking at this post years later like I am, we ran into this question as well at one point. I would like to share some helpful hints for data larger than 20 bytes.
Since the data is larger than one packet can handle, you will need to send it in multiple packets. It helps significantly if your data ALWAYS ends with some sort of END byte. For us, our end byte gives the size of the total byte array so we can check that at the end of reading.
Create a loop that checks for a packet constantly and stops when it receives that end byte (would also be good to have a timeout for that loop).
Make sure to clear the "buffer" when you start a new read.
It is nice to have an "isBusy" boolean to keep track of whether another function is currently waiting to read from the device. This prevents read overlaps. For us, if the port is currently busy, we wait a half second and try again.
Hope this helps!
Anyone know why 802.11 Acknowledgement Frames have no source MAC address? I don't see it when I capture the packets from TCPDUMP or Wireshark from Linux with a monitor-mode and promiscuous-mode driver. How does the Access Point distinguish ACK frames from different 802.11 clients if there is no source MAC addresses in the frame?
I can see from all the captures that the ACK comes immediately after the frame is sent (around 10 to 30 microseconds) but that alone can't be enough to distinguish the source can it? Maybe each frame has some kind of unique identifier and the ACK frame has this ID inside it? Maybe there is identifying information in the encrypted payload since the WLAN uses WPA-PSK mode?
No, there is nothing encripted in 802.11 MAC ACK frames.
802.11 is a contention based protocol. ie the medium is shared by different STA's and AP's who all are working in the same channel [frequency] in terms of time. Those who wants to transmit are competing for medium , winner who gets medium starts transmitting.
As per 802.11 spec. , once a frame is on air, the next "SIFS" period medium should be free. ie no one is allowed to transmit.
At the end of SIFS, the reciever of unicast frame should transmit ACK. This is the rule.
SIFS [Short Interframe space] in 802.11 is ~10 microseconds for OFDM based 802.11 implementations [802.11 G,A]. For 802.11b its ~20 microseconds if my memory is correct. Thats why you are seeing 10 or 30 microseconds in between TX and ACK
So, everyone knows who is transmitting the ACK and whom the ACK is to. So no need to include source address, its implecit.
Why Source address not included?
To reduce the frame size and so to same power.
Hope it helps. If you got more questions on this, please feel free
ACK frames, like all 802.11 management frames, have a DA (Destination Address) and SA (Source Address) in their MAC header (both not to be exactly confused with just "MAC address, see below), and that's all what's needed in this context.
TLD;DR: In 802.11 context, "MAC address", SA (Source addr), TA (Transmitter addr), DA (Destination addr), BSSID or whatnot all look alike a 6 byte "MAC address" that we're familiar with from other technologies, yet they should not be confused.
And now for the demolition of "MAC address" concept in 802.11 context.
802.11 Acknowledgement Frames are parts of 802.11 managements frames, and 802.11 is "a set of media access control (MAC) and physical layer (PHY) specifications" (source).
What this mean - and this is a very important concept to grasp when working with Wi-Fi - is that 802.11 in itself, including its management frames, have nothing to do with "traditional" (say 802.3, aka Ethernet) PHY (layer 1) nor MAC (layer 2) layers - they are a kind of their own.
802.3/Ethernet, to continue with this analogy - or rather counter example - have no such thing as ACK frames, beacons, probe request, RTS/CTS, auth/deauth, association etc, which are all types of 802.11 management frames. These are simply not needed with 802.3, for the most part because wired Ethernet is not a shared media (that's IEEE terminology), that may lead to unreliability/collision as is air with 802.11/Wi-Fi.
The important consequence of this is that you should not expect a priori to meet other, more familiar concept nor data from other layer 1/2 technologies. Forget this, once for all.
Sure, Wi-Fi looks like it carry on some MAC and IP and TCP and or UDP or whatnot, and they do most of the time, but regarding management frames such as ACK, that's a different world - its own world. As it is, 802.11 could perfectly be used - and maybe is used in some niche use cases - to carry other higher level protocols than TCP/IP. And its MAC concept, though looking familiar with its 6 bytes, should not be confused in its form nor use to the MAC of 802.3/Ethernet. To take another example, 802.15 aka Bluetooth also have a 6 bytes MAC, yet that is again another thing.
And to take the 802.11 a contrario example, 802.11 layer 1/2 beacon frames for instance carry some info about SSID, supported rates, Frequency-hopping (FH), parameter set etc etc that have no counterparts in other L1/2 technologies.
Now, embrace the complexity of what is/are "MAC addresses" in 802.11...
And this is why, to take an example in day to day use, pcap/tcpdump have such weird filters such as wlan ra, wlan ta, wlan addr1, wlan addr2, wlan addr3, wlan addr4 - and the like for wireshark capture and display filter.
Right George..!!
In MAC format NAV timer is updated like that, while data frames NAV is updated while transmitting , It updates for
DATA frame + SIFS + ACK + SIFS
So there is clear for this time, only one AP <---> station is talking, all are waiting to be clear NAV time period, so doesn't need to add Source address as it is wasting frame bytes.
I came across same question and saw this stackoverflow question on internet.
If you think about it, if stationA is waiting for ack from stationB, that means stationA has pretty much secured/locked medium for that long (see Jaydeep's answer) time i.e. (enough time for 2SIFS + 1ACK assuming no follow-up transmission between these 2 stations).
Hence no other station is sending any frame (i.e. ack here), leading no need to distinguish ack.
Its just StationA is waiting for ack from stationB in that time window.
I am doing a research and trying to find the distance between 2 samsung S2 galaxy phones, using Wi-Fi, by measuring RTT.
For that, in order to get the highest accuracy, I need to access the network Phy, and see the exact time the packet has left one cellphone, and the exact time it arrives back, before it has been processed in the LAN card (again, I need a very high accuracy).
Is it possible? Did someone succeed in accessing the LAN card physical layer on samsung S2 galaxy?
BTW - my cell phones are "rooted".
Thanks in advance,
Tzach
It's not too feasible at SW level. There are several factors that severely limit your ability to perform such measurements:
Data is being propagated at speed of light, any timer that you might have access to, is no match for such resolution.
You need to do at least some processing to understand that the data has arrived; similarly, there is a delay from when you measure transmission start till the packet actually leaves to the air. These delays are much more significant than the actual time of travel in the air.
Also see a related question: WI-FI 802.11 speed depending on distance
Thanks a lot for your quick answer. I worked a lot on this ability at SW level, and as you have written - it is not feasible. My question is about testing this ability at HW level ("talk with the PY"). Do you know if it can be done with Samsung S2 galaxy?
I'm using Wireshark to monitor network traffinc to test a new software installed on a router. The router itself lets other networks (4g, mobile devices through usb etc) connect to it and enhance the speed on that router.
What I'm trying to do is to disconnect the connected devices and discover if there are any packet losses while doing this. I know I can simply use a filter stating "tcp.analysis.lost_segment" to track down lost packets, but how can I eventually isolate the specific device that causes the packet loss? Or even know if the reason was because of a disconnected device when there is a loss?
Also, what is the most stable method to test this with? To download a big file? To stream a video? Etc etc
All input is greatly appreciated
You can't detect lost packets solely with Wireshark or any other packet capture*.
Wireshark basically "records" what was seen on the line.
If a packet is lost, then by definition you will not see it on the line.
The * means I lied. Sort of. You can't detect them as such, but you can extremely strongly indicate them by taking simultaneous captures at/near both devices in the data exchange... then compare the two captures.
COMPUTER1<-->CAPTURE-MACHINE<-->NETWORK<-->CAPTURE-MACHINE<-->COMPUTER2
If you see the data leaving COMPUTER1, but never see it in the capture at COMPUTER2, there's your loss. (You could then move the capture machines one device closer on the network until you find the exact box/line losing your packets... or just analyze the devices in the network for eg configs, errors, etc.)
Alternately if you know exactly when the packet was sent, you could not prove but INDICATE its absence with a capture covering a minute or two before and after the packet was sent which does NOT have that packet. Such an indicator may even stand on its own as sufficient to find the problem.
I am attempting to use my arduino uno's rx and tx pins to receive an ASCII character string from an rs485 device transmitting at 2400 BAUD with 0.100Sec between transmissions, and then parse and output certain pieces of the string to a 16x2 LCD attached to the arduino.. I am getting some data strings, as I checked with my scope, coming in on the rx pin 0-5vdc square wave. Anyone with sample code to receive rs485 ascii strings into a buffer would be helpful.
RS485, RS422, and RS232 are different schemes for the hardware link layer. By that I mean, those specifications only describe what is on the wire. A transceiver chipset converts the wire signals back to the logic level signals that are connected to Arduino, or any other device. At the logic level the Arduino sees, any of the RS___ signals will look the same.
A USART converts the bit stream to a byte (this can be software or hardware). The USART does not know about the signal levels on the wire, it operates solely on the logical level bit stream. The UNO contains one USART that is available on the TxRx pins.
So your code on the microcontroller does not need to be different, RS232 or RS485. All the Serial code samples you see will function fine. You tell the Serial library baud, stop bits, and parity, and you are done. Set the serial connection to 2400, and the Arduino will start seeing characters.
Caveat
RS485 is sometimes used in half-duplex mode. This means you cannot receive and transmit at the same time. If you are wiring for half duplex, then you code must be certain you are not transmitting while some other device is still transmitting.