Public/Private messages coming through when they shouldn't…
Home › Forums › Conduit: mLinux Model › Public/Private messages coming through when they shouldn't…
Tagged: public private sync word
- This topic has 9 replies, 2 voices, and was last updated 8 years, 8 months ago by
Jason Reiss.
-
AuthorPosts
-
July 25, 2016 at 11:21 am #14293
Damian Christie
ParticipantI’m playing around with the public and private network settings. I have the on-board network server disabled so just running as a packet forwarder. I’m finding that when the sync word on my device is set to 34 and the gateway is set to 12, I’m still getting a few messages through. Likewise, when the device is private and the gateway is public, some messages are showing up on the network server (running on a laptop). If the settings match, everything goes through. Surely private messages should never be forwarded? Is this a function of the SX1301? I can’t find a datasheet for the SX1301.
Anyone else seen this behaviour???
July 25, 2016 at 11:46 am #14294Jason Reiss
KeymasterWe have seen occasional messages get through with mismatched settings.
The sync word is a single byte. If there is interference and the sync word is corrupted to match the other sync word it will be forwarded.
That is the only possibility as the sync word is a filter at the radio front end.
July 26, 2016 at 4:24 am #14301Damian Christie
ParticipantThat’s interesting.
0x12 = 0b00010010
0x34 = 0b00110100Only three bits need to be flipped and the message goes through. I wonder how much filtering is in place to offset the likelihood of that happening.
July 26, 2016 at 7:35 am #14305Jason Reiss
KeymasterCRC is applied to the packet data, so if bits are flipped past the sync word then the packet can be filtered.
What is the concern of a private message being forwarded?
A 3rd party will not have the encryption keys needed to decrypt the packets.
A 3rd party network server will drop the packet as the seqno and MIC will not match, if there is a corresponding record for the packet address.July 26, 2016 at 8:27 am #14306Damian Christie
ParticipantNot much concern. Just trying to understand a little better. What would be a use case of this particular feature?
July 26, 2016 at 8:36 am #14307Jason Reiss
KeymasterThe Public/Private feature?
Using Private mode will filter out the number of packets that need to be processed if there are public network mDot’s in the area.
Also since the network server resides at the gateway a shorter join delay of 1 second is used. And the private mode allows multiple networks in the same area by segmenting the frequencies used with the Frequency Sub Band setting. This mode is applies Multitech devices as it departs slightly from LoRaWAN in the downlink frequencies used.
Using private mode also helps the public network from having to examine and filter out packets if there is a gateway receiving the private packets.
The Public mode is included in the gateway to allow 3rd party LoRaWAN devices to function with the on-board network server.
July 26, 2016 at 10:02 am #14310Damian Christie
ParticipantUsing Private mode will filter out the number of packets that need to be processed if there are public network mDot’s in the area.
This will only filter out most packets though, based on what we’re seeing. The goal is just reduction?
Also since the network server resides at the gateway a shorter join delay of 1 second is used.
In my set up I don’t have the on-board network server running. Public messages are sent by a private gateway to the remote server (the IP address of which is in global_conf.json) about 20-40% of the time. I’ll turn on the local server and see what happens.
The Public mode is included in the gateway to allow 3rd party LoRaWAN devices to function with the on-board network server.
Apologies, I’m a little lost here (can you tell?!). Does this mean that private is for mdots+onboard server, public is for 3rdparty devices+onboard server (which is still technically private because it uses the onboard server) and public and private are also both for 3rd party devices+remote server??
July 26, 2016 at 10:08 am #14311Jason Reiss
KeymasterQ1: The goal is just reduction?
A1: What other goal could be made?
Q2: 3rd party + remote server?
A2: mDot can be used with Public or Private. 3rd party device may not be able to be configured to operate with the Private mode on Conduit.
Private vs Public and remote server is a matter of packet forwarder sync word setting, mDot can also function in this mode.July 26, 2016 at 10:41 am #14313Damian Christie
ParticipantWhat other goal could be made?
For private messages to be invisible to public gateways. I originally thought that was the point of the sync word. Thanks for the help clarifying this.
3rd party device may not be able to be configured to operate with the Private mode on Conduit.
Good to know, thanks.
July 26, 2016 at 10:46 am #14315Jason Reiss
KeymasterIt does it’s best at making it invisible. But as you see there may be a packet error to allow a few through.
Increasing distance from mDot to gateway may reduce this occurance.
-
AuthorPosts
- You must be logged in to reply to this topic.