OUI restrictions and OUI 'advertising'


#1

I do not think this is part of any standard at the moment, so this might be about creating somethign new…

would it be possible / sensible at the Network server to be able to send OUI restriction lists to all the gateways, so they could filter which OUI’s are accepted/rejected. Sort of like a routing protocol of sorts…

This could be further extended for a network server to ‘advertise’ OUI’s, to other NS’s… You could in effect ‘peer’ between Network Servers…


#2

It’s a possible approach, sure. There is at least one unnamed proprietary LoRa implementation that does this by running a network server on each gateway. Personally, I care a lot less about using extra bandwidth to send unnecessary payloads than I do about the maintenance burden of filtering at the gateway level.


#3

It turns out that “peering” between networks is done using records in DNS already. Its mentioned in this doc. I was reading this yesterday for a differnet reason, and came across that!

TTN is talking about this in ‘low bandwidth mode’ in the v3 gateway agent.


#4

This is probably what the Basic Station is doing by filtering on NetID and JoinEUIs :slight_smile: V3 (a test version has been released) of the LoRa Gateway Bride does support sending this information to the Basic Station when the gateway connects, see the config example below:

    # Filters.
    [backend.basic_station.filters]

    # NetIDs to filter on when receiving uplinks.
    net_ids=[
      "000000",
    ]

    # JoinEUIs to filter on when receiving join-requests.
    join_euis=[
      ["0000000000000000", "ffffffffffffffff"],
    ]

#5

are you refering to the TTN v3 stack?

Is this a Lorawan standard, or is it an ‘extra’ that TTN has added to their stack? If theres a standard i would rather do that, than reinvent something.

I’ve got data that needs to transverse LTE networks, and sometimes in places where there is quite a bit of other Lorawan traffic, I have one location, where 95% of the data is not interesting to me.


#6

putting a Network server on each gateway is an ‘option’ but not one i want to pursue.


#7

I’m referring to the LoRa Server LoRa Gateway Bridge component. This is a feature of the Semtech Basic Station forwarder: https://doc.sm.tc/station/tcproto.html#router-config-message

LoRa Gateway Bridge v3 (a test version is already available) implements the Basic Station interface.


#8

oh ok, that makes sense.

Do you think this is going to become the ‘defacto’ way to set up this filtering?


#9

That I don’t know, but potentially this feature could also be made generic on the LoRa Gateway Bridge so that it will be applied for all backends (Basic Station, Semtech UDP, …).


#10

Filtering on JoinEUI at the generic gateway bridge level would be a nice feature.


#11

Would you mind creating an “issue” for this at https://github.com/brocaar/lora-gateway-bridge? That way this feature-request does not get lost :slight_smile:


#12

Done, much appreciated.


#13

If its part of the LoRa Gateway Bridge, and your gateways are using MQTT over TLS, woudl this be an issue.?


#14

Why would this be an issue?


#15

I didn’t have a specific reason. The way I read this was that the ‘restriction’ for Net Id’s / Join Id’s was being done on a LoRa Gateway Bridge. However I didn’t think this quite through and had assumed it was a ‘centralized’ bridge where UDP packet forwarders were pointed to. I can see that this could be implemented on the gateway device as well. Thanks for the explanation. ( and this just needed some more time to think it through )…

Which component of the architecture would send the list of Net_ids / join_euis to the gateway bridge?


#16

Ok, so some more reading. Looks like the gateways just need to periodically poll a ‘CUPS’ server via some http and get the relevent info. This doe’snt need to be integrated with the NS or anything. More details here
https://lora-developers.semtech.com/resources/tools/basic-station/the-cups-protocol/


#17

I had a play with the example code and have a much better understand of how it works now. Is there any point in trying to integrate this with the NS? The NS, needs to know about its NetID; you doint’ really want to have to configure the same information twice?


#18

Not sure to be honest. In some cases this might make sense, but ideally the LoRa Gateway Bridge should be able to work without a NS to provide an API to the gateway. Maybe for now it makes sense to keep this information in the lora-gateway-bridge.toml file.

Potentially CUPS, or other tools allowing you to do remote gateway management could help you to keep the gateway configuration in sync.


#19

Thats a good idea, we can just pull the relevent NetID’s / JoinIDs’ from the config files. Easy, simple.
and just one place to configure it.