EZ-WifiBroadcast
EZ-WifiBroadcast copied to clipboard
rodizio1
bind code for telemetry and RC
can you add a bind function now that you have RC and telemetry, just a unique number or word that can be set on TX and RX so that RC or telemetry commands will be rejected if originating from the wrong ground station.
it could be done with mac addresses also i suppose, only accept RC and telemetry from a specific MAC address.
my worry is that if someone changed channel to see my feed and they still had a handset or telemetry hooked up it could send erroneous commands to the machine they are viewing. im not worried about hackers or anything like that so it doesnt have to be secure.
For video, telemetry downstream and telemetry upstream, this can be achieved by the wbc 'port' setting (not configurable in 1.5, but would be no big deal making this configurable).
For the R/C uplink it's different, the reason is, that the frames must be as short as possible to keep packetloss low. Currently, they are 20bytes long including IEEE header and checksum.
I could add another byte for the port to the packets, that would make packetloss slightly worse, which I'm a bit reluctant to do without further testing to quantify it.
Another option would be 'squeezing out' another byte by reducing the resolution of the channels to 10bit=1024 steps (now it's 11bit=2048 steps), but my plan was actually to do that and use the 'freed' byte for additional (low-resolution, for switches) channels.
Now you want to use up that byte for an unique ID feature and all my plans are spoiled ;)
Makes sense though, I'll look into it, maybe I can make it configurable so that people can choose what's more important to them, additional channels, lower packetloss or that unique ID feature.
That's the problem, there is no mac anymore :)
It's just the 2byte frame control field, two bytes duration field, then the payload (sequence number and channel values). Maybe I can further abuse the 2nd byte of the frame control field, to give maybe 4 different IDs, would that be enough?
should be enough, they can be set with profiles if its in the wifibroadcast.txt
how are the 3dr radios doing it? they have a setting called net id in the firmware that lets you set 1-100 surely they dont transmit that ever packet?, just checked they have a hardware header.
@geofrancis I have been working on a code that does exactly what you wish. You can set a comm_id so that RC commands on the same frequency do not get mixed up. However there currently is only support for a i6S RC as I do not have access to others. The code works with Ralink and Atheros cards. The packets have more bytes. I have not tested how much packet loss is caused but the video quality was not affected too much in in my few tests.
You can check out the code here: Code
I am trying to clean up the clutter @careyer , do you know if this is still relevant or can we close it ?
I think we should keep this enhancement since as of now there is no protection for any data that is transfered. Anybody can basically "tune in" to your signal and see your video/telemetry and even can gain control of your aircraft. If packetlength is an issue and must be kept as small as possible - maybe we can simply apply a fast symetric cipher (e.g. AES) to all data that is being transmitted upstream and downstream? This will not increase the amount of data being sent but render it immune to tampering. High speed and low RAM requirements were criteria of the AES selection process. As the chosen algorithm, AES performed well on a wide variety of hardware, from 8-bit smart cards to high-performance computers. This could at least be offered as a config option. Thoughts?
Sorry to refer one more time on DroneBridge, but we can see in "DroneBridgeConfig.ini" :
# choose a random number. Allowed numbers: 0-255
# has to be the same on drone and groundstation ! Acts as a identifier for both and the link.
communication_id=200
Don't know how it works.
@Yes21 : Wolfang writes "... The packets have more bytes."(see his post above) which in my understanding means that the comm_id is added to the payload of each packet as sort of an identifier. Rodizio claimed that this increased packet size would cause considerably more packet loss and hence would not implement this feature. My idea of making use of a fast blockcipher (such as AES) was based on the property that this will not add any bits or bytes (i.e. 16byte plainext get encoded to 16byte ciphertext) and would make the transmission at the same time immune to "ID enumeration" and also against "bruteforcing". There should be various cipher implementations readily available for Raspberry Pi. Only drawback would be slightly increased CPU, but I believe e.g. AES is well optimzed to run even on very poor hardware. 10 years back I implemented it on a Nokia Symbian phone (pre smartphone aera) in JavaME and it was easily capable to transcode the spoken voice in realtime. ... If that does not perform well enough or the blocklength (AES=128bit) does not fit we could use a Electronic Code Book cipher which can look like this: Define a random byte "01011010" and XOR it to every payload byte. Not even a single bit will be added but you need the right Byte-Key to decode the plaintext in a meaningfull way. Not very sophisticated and not immune to enumeration attacks either but not a single bit overhead and FAST ;-)
Your last suggestion should be good enough security wise if it works practically, we will need to test it out later on. It will ad at least some security to rc communication. Let's keep this for near future.
It's not possible to get that kind of functionality without putting additional information into the packet. Doing the XOR or AES like careyer wrote, would be quite dangerous. Think about it: You encrypt the data and then decrypt it without the ability to check if it was decrypted correctly. When you accidently have a different secret on the RX and TX (or when somebody switches on his WBC R/C system nearby with a different secret configured ...) you end up with garbage being decoded and your controls going completely nuts.
I used to think that using different FEC values at different frequency points, mainly unique package length values could avoid RC confusion.
Yes you are right. I guess there is no way to add more security without adding a checksum/CRC or alike. Nick is right. The GroundPi somehow has to prove that he is, the legit talker. Could be done with a HMAC but indeed that adds information.
Von meinem iPhone gesendet
Am 07.11.2018 um 22:08 schrieb zipray [email protected]:
I used to think that using different FEC values at different frequency points, mainly unique package length values could avoid RC confusion.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
What if you pre-configure the same pre-shared-secret on both ground an airpi. Wouldn't one be able to verify the legitimacy of originating packets?
I have always found Vasily's solution pretty elegant. With the generated keys for ground and air. https://github.com/svpcom/wifibroadcast I have it on my list to see which parts of his solution could replace some of the parts we have now. I do feel there are some drawbacks, but overall his solution is pretty clean and stable. We had some talks in the past about two way telemetry, and i feel that can be done, later he also mentioned this himself: https://github.com/svpcom/wifibroadcast/issues/20
Now i'm not proposing ditching all we have, but his solution merits closer inspection i think...
Can we take over maybe one packet in 100 for verification? It's not ideally secure but may solve the basic problem. You could also send a block crc for validation. On vasily's site is a link to a white paper on packet injection and you can actually get better throughput with some atheros cards trying to send on the same channel. I'm trying to figure out how we can use that information to improve our uplink abilities
