In the RAK7289CV2 running WisGateOS 2.2.8, when a user tries to enable White List Mode in the Packet Filter, the system forces the user to set both the OUI and the Network ID. However, it should be possible to configure only the OUI or only the Network ID, depending on the use case.
Additionally, I noticed that in another forum topic, the Network ID is entered in decimal, but there seems to be a limitation: the maximum allowed value is 127.
The system displays the error: “This value cannot be more than 127”.
Why is this limit enforced, if the Network ID should be allowed up to 0xFFFFFF (decimal: 16,777,215)?
Yes, it’s quite annoying that White listing still doesn’t work using WisgateOS. The workaround is to install Chirpstack Gateway OS and use its whitelisting tools, but then we may as well cancel our Wisdm gateway management subscription, as that needs the Wisgate OS.
The filter is White, which means it will allow the devices. That is why first the NetID is provided, then the OUIs.
Unless specific use cases, where a packet multiplexers are used, a single gateway is connected to a single LNS, and the NetID is known. Then you can add different OUIs.
We understand that this can be confusing or restrictive in some use cases; thus, our dev team is working to separate the functionality and allow only one or another.
As for the limitation of the Net ID, this is not true. The NetID is the first 7 most significant bits (MSB) of a device’s DevAddr. For example, a DevAddr starting with 0x26 (00100110 in binary) has the first 7 bits 0010011, which equals decimal 19. DevAddr provided by the LNS is based on the NetID. More info here - https://docs.rakwireless.com/product-categories/software-apis-and-libraries/wisgateos2/lora-configuration/#enable-packet-filter-1
Hi @j9archer, the White List filter works in both PF and Basics Station modes(latest WisGtateOS2). Can you share more details on what does not work for you?
Hi @JaeHwan.Jin,
You can try it by adding our NetID to the white list filter:
Our devAddr range is fe008800 - fe008fff. Both of these convert to 127 when using your formula for calculating the NetID. In fact 127 = 0x FE000000, which is the common prefix for ALL Type 7 Network IDs. This means that not only can we not filter within our own devAddr range, but we also can’t filter between our range and the devices of any other type 7 organizations that might be nearby.
Here is the table from the LoRa Alliance listing the NetID types. The highlighted binary prefix shows the problem - all Type 7 NetIDs are effectively lumped together, as you’re only using the first 7 bits:
As @j9archer already explained, the issue lies with the mask for the NetID. You could implement a similar approach to what’s used in the chirpstack-gateway-bridge.
# NetIDs filters.
#
# The configured NetIDs will be used to filter uplink data frames.
# When left blank, no filtering will be performed on NetIDs.
#
# Example:
# net_ids=[
# "000000",
# "000001",
# ]
net_ids=[
]
