Join-Accept not forwarded to V3 nodes via V2 gateways on AU1

OTAA not working on V3 nodes since Friday 2 July. Looks like the join accept is not getting forwarded correctly. Experiencing this problem on the AU915 FSB2
channel plan, problem appears to be identical to another user on the Australia AS923 channel plan. Equipment worked fine before 2021-07-02.2021-07-04 Unsuccessful V3 Join Request via TTN.pdf (709.3 KB)

1 Like

Searching being your friend, here’s something recent to look at:

I searched for “AU915” and sorted by most recent post.

1 Like

Thanks, yes I found this but felt it was not exactly the same issue, our units operated fine up until last Friday. Ok, could be related on second reading.

Not exactly the same, in my scenario gateway is V2.

Problem solving on here is about accumulating information & ideas - there are too many moving parts in LoRaWAN for any one presentation of an issue to appear the same to someone else.

Do you have or can create v3 device on ABP?
Do you have or can create v2 devices on ABP & OTAA?
As you have the Conduit gateway, can you register that on v3 to test your v3 OTAA device?

Where did the successful TTIG join & uplink on p11 come from - is that a v2 device?

Apologies for the confusion, that was not a successful TTIG join, that was just the traffic getting picked up from the successful join with the Conduit. Included it to illustrate that both are on the same channel plan. The TTIG and Conduit are in close proximity to each other.

OK, and for the other questions …

  1. I can try and create an ABP device on V3, but this will be my first dabble into this territory. Will definitely try this as I can then retain device for troubleshooting in the future.

  2. My understanding is that we can no longer register devices on V2. I have a few hundred V2 devices but they are on the EU868 channel plan operating in South Africa.

  3. I “borrowed” the Conduit from our production department so I am hesitant to configure it to TTI. I have placed an urgent order for another TTIG.

OK then, my bad.

Do you have a device on ABP on v2?
Do you have a device on OTAA on v2?

I type pointers & suggestions on here at speed, I get paid to type detailed & exhaustive test & debugging plans. As I suggested above, read around the topic. don’t look for someone with your exact same situation, if TTS was exhibiting system wide problems I’d be moderating half-a-dozen topics about the same thing.

1 Like

I believe the issue is not system wide but it is only affecting V3 devices that are trying to join via au1.cloud.thethings.network since Friday. Those that have existing sessions are currently not affected.

???

Currently no ABP devices, all V2 devices are OTAA but on EU868 channel plan.

Ah, and this is the first time I’ve entered this transition “Twigglet Zone” where we need a device on v2 but can’t register it due to the read-only situation.

As I understand it, it’s establishing if downlinks of any variety can be sent from TTS on AU1 using AU915 FSB2 via a v2 gateway.

So hopefully you can create an ABP device on TTS to give that a try. You may need to enter the different channel frequencies so TTS doesn’t try to use something that the device doesn’t know about - but they can be edited in after the fact, so you could travel hopeful and just bang in an ABP device - you’ve got an oven ready DevAddr in your PDF.

Maybe the grownups @kersing or @Jeff-UK can weigh in with suggestions?

1 Like

I’m on the ABP V3 AU915 route and will provide feedback asap.

The screenshots below refer. Have registered a new V3 node with ABP and the uplinks are received 100%, It would appear that the downlinks are not forwarded. The downlink scheduled at 14:52:07 on the Live Data preview screen for the node does not appear on the V2 console gateway traffic log. Are all downlinks not getting forwarded?
image
image

No idea, I’m on the other side of the planet with no kit that covers that frequency range.

But I’ve gone in the RF shielded cellar where I keep naughty forum members locked up and tried a v3 OTAA join & downlink using a v2 gateway and it’s working for EU868. Checked the meta-data and only Packet Forwarder entries.

This has highlighted one of those bits of info that I’d not recalled - the v2 console doesn’t show Join Accepts or Downlinks.

So just incase, can you put a serial log on a device to see what it thinks is happening, ie, does show any evidence of a Join Accept? And what is the device, just incase it’s one that needs particular version settings for LW.

1 Like

I’m almost 100% certain downlinks are not getting forwarded as the ADR is not kicking in. At a RSSI of -48 and a SNR of 11.75 the data rate should speed up to SF8BW125 quite quickly. The live data for the ABP node (verbose mode) is enqueuing ADR requests to switch to SF7BW125 and these are not getting actioned by the node.
image

{
  "name": "ns.mac.link_adr.request",
  "time": "2021-07-04T15:04:13.246163961Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "ausabp-37-37-33-31-78-37-7c-03",
        "application_ids": {
          "application_id": "ausv3-au915-c8-monitor"
        }
      }
    },
    {
      "device_ids": {
        "device_id": "ausabp-37-37-33-31-78-37-7c-03",
        "application_ids": {
          "application_id": "ausv3-au915-c8-monitor"
        },
        "dev_eui": "3737333178377C03",
        "dev_addr": "260D88C9"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRReq",
    "data_rate_index": 5,
    "tx_power_index": 2,
    "channel_mask": [
      false,
      false,
      false,
      false,
      false,
      false,
      false,
      false,
      true,
      true,
      true,
      true,
      true,
      true,
      true,
      true
    ],
    "nb_trans": 1
  },
  "correlation_ids": [
    "ns:downlink:01F9S0RSNWYTA4HRDZYCCRJMWT",
    "ns:uplink:01F9S0RS8EMFREC4C6CH77HBVS",
    "pba:conn:up:01F993M51D8FDK8N6X7W380RXY",
    "pba:uplink:01F9S0RS6WN0SHR44NAW0ZTJMR",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01F9S0RS8EFY2AWPGZYVYZFR6W"
  ],
  "origin": "ip-10-102-12-39.ap-southeast-2.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ",
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01F9S0RSNY0A0EKNNWGYHR85VS"
}

@SteveLeigh-AUS we had a configuration issue since Thursday. We have resolved that and we will do some additional operational maintenance tomorrow (July 6). Please try again and post the results here.

2 Likes

Hi @johan unfortunately no change in behavior - downlinks still not received. I will retest after your scheduled maintenance tomorrow (July 6), what is your anticipated end time of the scheduled maintenance? Thanks.

Hi Johan, I am joining v3 devices on v2 gateways via au1 this morning. ie back to how it was before Friday.
@SteveLeigh-AUS Hi Steve, thanks so much for all your work and excellent documentation on this issue. Hope you have some success today mate!

2 Likes