I have several new Ford vehicles with SYNC at a workplace and a driver could be assigned a different vehicle day to day. It is easy enough to pair an iPhone to a single vehicle. However, when pairing to a dozen or so vehicles I noticed a couple problems. The most obvious is there are a fairly low number of devices that the head unit will accept to pair to. I have to delete a pairing to be able to add another. Not terrible and likely a manufacturer limitation. The most annoying and time consuming problem is the Bluetooth name is the same for every vehicle. The name is always “SYNC”. There is no way I see to edit the name or add a note to the Bluetooth connection in IOS to signify a vehicle fleet number. So the user has no idea which “SYNC” to connect to. Much worse, when you can’t connect for some reason and need to blow away the old connection because it doesn’t appear as a new device to connect to, then you have to blow away every SYNC connection because you have no label signifying which connection belongs to which vehicle you’re using at the time. Ford sells fleet vehicles and I’d think they would test such a scenario. Any work around? Any way to edit the SYNC name coming from the head unit to something like “SYNC 234” so that it contains a vehicle number?
Related
I surely must have missed something from my reading of the LoRaWAN specifications, because this seems too bad to be true. Please tell me I'm delirious :)
The following seems to happen in my testbed when I have many OTAA nodes and I can't figure out what would prevent it:
multiple nodes in my network issues JOIN REQUEST at the same time (this can happen by chance or if they are powered on simultaneously)
gateway receives (at least) one of them successfully and responds with a JOIN ACCEPT assigning a DevAddr, thinking one node did a join req
all the nodes that did the JOIN REQUEST will receive the ACCEPT and think the JOIN ACCEPT was directed at them, and gladly sets the same received DevAddr
From here on, we have several nodes that all think they joined successfully and all think they are unique but have the same DevAddr. Needless to say, the system gets severely messed up.
Reading the LoRaWAN specification, the JOIN REQUEST has a node unique DevEUI, a network unique AppEUI, and a random DevNonce (to prevent replay attacks). The MIC is calculated from these and the secret network unique AppKey stored in the node.
The JOIN ACCEPT has, as far as I can see, no data in it which is derived from the JOIN REQUEST, and therefore it can't be directed to a specific node in the case that many nodes are currently listening to an ACCEPT.
It has: AppNonce NetID DevAddr DLSettings RxDelay CFList, and is encrypted with the AppKey which is network unique and not node unique. The MIC only involves these values and so doesn't help either.
I would have expected that the JOIN ACCEPT at the minimum includes the DevEUI requesting the join as a part of the MIC, and also that it would include the DevNonce. It seems it includes neither.
What gives? Is OTAA broken or not? :)
The MIC will be different for each device because it's base on the secret (and supposedly unique) master key (AppKey) shared between the device and the network.
The first thing a device do is checking the MIC, if it's not what's expected it will drop the message.
So what you said below is not exactly right :
The JOIN ACCEPT has, as far as I can see, no data in it which is derived from the JOIN > REQUEST, and therefore it can't be directed to a specific node in the case that many > > nodes are currently listening to an ACCEPT.
It has: AppNonce NetID DevAddr DLSettings RxDelay CFList, and is
encrypted with the AppKey which is network unique and not node unique.
The MIC only involves these values and so doesn't help either
Of course if you set the same AppKey on every of your device, you will
get what you described :)
Apart from the different AppKey as mentioned in Pierre's answer (strongly recommended), the node also includes a DevNonce in its Join Request. This DevNonce is used to derive the NwkSKey and AppSKey session keys from the Join Accept response.
In LoRaWAN 1.0.x, this DevNonce should be random. So even when using the same AppKey for all devices, chances should be low that they would also have generated the same DevNonce. So even if the MIC somehow validated, then the derived keys will not match the keys known to the server, basically rendering the device useless without it knowing it.
In LoRaWAN 1.1 I think that the DevNonce is an increasing number, but in 1.1 OTAA has changed so I don't know how that affects the results.
See https://runkit.com/avbentem/deciphering-a-lorawan-otaa-join-accept.
The question also states:
this can happen by chance or if they are powered on simultaneously
As for switching on simultaneously, the 1.0.x specifications state:
The transmission slot scheduled by the end-device is based on its own communication needs with a small variation based on a random time basis
Still then, such small variation probably won't avoid nodes hearing each others Join Accept messages in this scenario, as the downlink receive window will need to be slightly lenient too.
One qualifier is the timing requirements for Join Request (JR) and Join Accept (JA). The specification is that a device can only use a JA received "precisely" 5 or 6 (2nd window) seconds after it sent the JR.
I'd hope there are better fail-safes then this timing but the intention might be to prevent the wrong tags from taking a JA.
I'm working on a little WebVR game using Hayden Lee's library, Networked AFrame and I'd like to place the users on a specific position as soon as they arrive in the networked room.
I've tried using the 'onConnect' callback, but when it's called the NAF object connectList is empty, so I cannot know if I'm the first one in the room or if other clients are already connected.
What would be the best way to get this kind of information, I can't find information about it in the docs.
Thanks for your help!
Currently in Networked-Aframe you can only control the position of entities that you have created and there is not a mechanism for determining how many people are in the room.
The only way to do what you're suggesting with NAF 0.2.3 is to set an arbitrary wait period after the onConnect callback, say 10 seconds, in which you hope that all the other users connect to the room. If there are anomalies that take longer and you end up with a collision of two people choosing the same position you react to that collision (which is also hard given there isn't events for users connecting yet). NAF 0.3.0 will at least have events for other users joining.
If two nodes with same name claiming same address in j1939 what will happen in this situation? will any one of node will claim address or error will occour ?
My copy of the specification is dated, but I'm sure this rule hasn't changed since 2003 (SAE J1939-81):
"Manufacturers of ECUs and integrators of networks must assure that the NAMEs of all CAs intended to
transmit on a particular network are unique."
Of course, that being said, it is of course possible to put devices with the same NAME on the
same set of wires, either through ignorance or malicious intent.
I personally haven't played with it, but in theory, if your device has the exact same NAME as another,
your address claim will exactly overlap the other, neither would be aware of the other's presence,
the message would go through successfully, and each device will assume it is the one that sent it.
I may be wrong, but I think the only thing odd an CA might see is message coming in from an address
it thought it had claimed, a problem which it may not even be checking for.
From the network standpoint, there is no way to distinguish that the nodes are different since they are identifying themselves as the same entity. What would happen is that the first requests will be addressed, and the second request will be ignored. In other words, this is race condition because only one message is processed at a time in the datalink. By the time the second node tries to claim the same address, the address table is already occupied and the late request node won't be able to get the notification that the address was assigned to it. Remember that each node has its own internal states/configuration.
J1939-81 says
"Repeated Collisions Occur, devices go BUS OFF CAs should retry using
a Pseudo-random delay before attempting to reclaim and then revert to
Figures 2 and 3."
we are working on a game with real-time matches. 2 players. 1 against 1.
I have to define a list of items in common between the 2 players before the game start.
It's not really a problem in the case of 1 player invite another. In this case i can define the player receiving the invite as the "client". The app of the "server" player will generate the list.
But in the case of an "auto-match" not sure how i can define this kind of relationship between my players as the same code is going to run the same way on the two instance of the apps.
Edit:
Will try this idea:
Will use a timeelapsed between beginning of the connection and the accepted connection. Exchange the data between users and determine which one should be consider as master/server.
Will post a detail example if the implementation working.
Meanwhile, still opened to any others suggestion.
In peer-peer networking, each device can function as the server. Make your networking client/server agnostic once the connection is made so that it doesn't matter.
I had that same problem and ended up defining my own network classes on top of AsyncSocket so that I could communicate in a middle layer. It's here if you're interested:
github link here
It suited my needs and it may give you some ideas.
This is a little off the beaten path. I've got a DLink DWL-G520 card I'm using under OpenBSD and it works fine. What I want to do is be able to access the radio part of it. Why? I want to use it in a radio telescope. It's a 2.4 GHz receiver with an external antenna connector. I want to connect some coax, some amplifiers, and an old TV dish and point the dish at the sky. It has an RSSI signal and variable RF gain (which it adjusts, from what I can find) so all I'd need to do is record those over time while pointed at a certain spot in the sky. I don't need to control the frequency really since most natural events are broadband.
I'm poking through the OpenBSD ath driver following nested structs but I don't want any of the normal network stuff, which is most of what the driver does. dmesg identifies it as an AR5212 which according to the Atheros PDF is always paired with an AR2112 radio. Is there any easier way than wading through PCI stuff to see what my options are? I need to turn the transmitter off so it doesn't fry my amps too. Trying to find low level documentation is about impossible from what I've seen. Ultimately I'd like to have this work with other WiFi cards too, but I'll start with this one. I've got a Cistron with an external antenna connector also.
Alan, ab1jx