Gateway connects to TTN but operates on AS923 instead of EU868 – moved to CUPS to change frequency, now CUPS not connecting

Gateways
1

I am working with a Dragino LoRaWAN gateway (EU868 hardware) and The Things Network / The Things Stack Cloud.

Initial situation

Initially, I registered the gateway on TTN using normal (non-CUPS) configuration.
The gateway successfully connected to TTN, and I could see it online in the console.

However, end devices were not able to communicate properly through the gateway.

Issue Discovered During Debugging

While troubleshooting, I checked the gateway logs (LogRead) and noticed that the gateway was operating on 923 MHz frequencies (AS923) instead of EU868.

Example observed frequencies:

**LogRead**
**FreqINFO:**
Gateway Channels frequency**

chan_multSF_0
Lora MAC, 125kHz, all SF, 923.2 MHz**

chan_multSF_1
Lora MAC, 125kHz, all SF, 923.4 MHz**

chan_multSF_2
Lora MAC, 125kHz, all SF, 922.2 MHz**

chan_multSF_3
Lora MAC, 125kHz, all SF, 922.4 MHz**

chan_multSF_4
Lora MAC, 125kHz, all SF, 922.6 MHz**

chan_multSF_5
Lora MAC, 125kHz, all SF, 922.8 MHz**

chan_multSF_6
Lora MAC, 125kHz, all SF, 923.0 MHz**

chan_multSF_7
Lora MAC, 125kHz, all SF, 922.0 MHz**

## **chan_Lora_std
Lora MAC, 250kHz, SF7, 922.1 MHz**

## **chan_FSK
FSK 50kbps, 921.8 MHz**

IoT Server Connection Ctate:
Logread FWD State:
Logread Error:
Logread RxTxJson:
Logread PULL State:

This suggests the gateway is not receiving EU868 from CUPS.

Because of this frequency mismatch, devices configured for EU868 could not communicate correctly.

Understanding After Research

After further research, I realized that:

  • The cluster I am using automatically registers gateways as AS923
  • This seems to be the default behavior based on cluster/region
  • However, EU868 is allowed in my deployment region (UAE)

So the problem was not connectivity, but wrong frequency configuration.

Decision: Move to EU868 Using CUPS

Since the default registration kept using AS923, I looked for a way to force the gateway to operate on EU868.

Based on TTN documentation, the recommended approach is to use LoRa Basics Station with CUPS, where:

  • Frequency plan is pushed from the server
  • Gateway configuration becomes centrally managed
  • Frequency can be changed by server-side configuration

Reference documentation:
Using CUPS to redirect to a different LNS | The Things Stack for LoRaWAN.

Actions Taken (In Sequence)

  1. Registered the gateway on TTN / TTS Cloud

  2. Set the gateway frequency plan to EU868 in the console

  3. Switched the gateway to:
    LoRa Basics Station – TTN

  4. Started configuring CUPS

  5. Generated API keys from TTN:

  6. LNS authentication key

  • CUPS authorization key
  • Added the keys to the gateway configuration
  • Rebooted and retried multiple times

Current Problem

After enabling CUPS:

  • The gateway no longer completes connection to CUPS

  • Gateway logs show CUPS connection errors

  • Because CUPS is not connecting, the EU868 configuration is never applied

  • Gateway continues to show AS923 frequencies in LogRead

  • Devices still cannot communicate properly

    Gateway Logs

    • Relevant excerpts from LogRead → LoRaWAN:
      **
      BootInfo:** Linux version 4.9.109 (root@DraginoHK) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r7360-e15565a) ) #0 Fri Jun 29 16:58:53 2018 MyLoader: sysp=aaaaaaaa, boardp=aaaaaaaa, parts=aaaaaaaa bootconsole [early0] enabled CPU0 revision is: 00019374 (MIPS 24Kc) SoC: Atheros AR9330 rev 1 Determined physical RAM map: memory: 04000000 @ 00000000 (usable) Initrd not found or empty - disabling initrd Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes Zone ranges: Normal [mem 0x0000000000000000-0x0000000003ffffff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000000000000-0x0000000003ffffff] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff] On node 0 totalpages: 16384 free_area_init_node: node 0, pgdat 8045dc44, node_mem_map 81000020 Normal zone: 128 pages used for memmap Normal zone: 0 pages reserved Normal zone: 16384 pages, LIFO batch:3 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: board=DRAGINO2 console=ttyATH0,115200 mtdparts=spi0.0:256k(u-boot)ro,16000k(firmware),64k(config),64k(art)ro rootfstype=squashfs noinitrd PID hash table entries: 256 (order: -2, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Writing ErrCtl register=00000000 Readback ErrCtl register=00000000 Memory: 59900K/65536K available (3131K kernel code, 168K rwdata, 792K rodata, 316K init, 208K bss, 5636K reserved, 0K cma-reserved) SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS:51 Clocks: CPU:400.000MHz, DDR:400.000MHz, AHB:200.000MHz, Ref:25.000MHz clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns Calibrating delay loop… 265.42 BogoMIPS (lpj=1327104) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns futex hash table entries: 256 (order: -1, 3072 bytes) NET: Registered protocol family 16 MIPS: machine is Dragino Dragino v2 clocksource: Switched to clocksource MIPS NET: Registered protocol family 2 TCP established hash table entries: 1024 (order: 0, 4096 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 1024 bind 1024) UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 PCI: CLS 0 bytes, default 32 Crashlog allocated RAM at address 0x3f00000 workingset: timestamp_bits=30 max_order=14 bucket_order=0 squashfs: version 4.0 (2009/01/31) Phillip Lougher jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler deadline registered (default) ar933x-uart: ttyATH0 at MMIO 0x18020000 (irq = 11, base_baud = 1562500) is a AR933X UART console [ttyATH0] enabled bootconsole [early0] disabled m25p80 spi0.0: found w25q128, expected m25p80 m25p80 spi0.0: w25q128 (16384 Kbytes) 4 cmdlinepart partitions found on MTD device spi0.0 Creating 4 MTD partitions on “spi0.0”: 0x000000000000-0x000000040000 : “u-boot” 0x000000040000-0x000000fe0000 : “firmware” 2 uimage-fw partitions found on MTD device firmware 0x000000040000-0x0000001a0000 : “kernel” 0x0000001a0000-0x000000fe0000 : “rootfs” mtd: device 3 (rootfs) set to be root filesystem 1 squashfs-split partitions found on MTD device rootfs 0x000000a70000-0x000000fe0000 : “rootfs_data” 0x000000fe0000-0x000000ff0000 : “config” 0x000000ff0000-0x000001000000 : “art” libphy: Fixed MDIO Bus: probed libphy: ag71xx_mdio: probed ag71xx-mdio.1: Found an AR7

SystemLogs:
2025-12-10 12:24:39.607 [AIO:DEBU] [-1] HTTP connection shutdown… 2025-12-10 12:24:39.607 [CUP:ERRO] CUPS connect failed - URI: https://as1.cloud.thethings.network:443 2025-12-10 12:24:39.607 [CUP:INFO] Interaction with CUPS failed - retrying in 1m 2025-12-10 12:24:39.608 [TCE:INFO] Starting TC engine 2025-12-10 12:24:39.608 [TCE:ERRO] No TC URI configured 2025-12-10 12:24:39.608 [TCE:INFO] Router rejected or retry limit reached. Invoking CUPS. 2025-12-10 12:24:39.609 [TCE:INFO] Terminating TC engine 2025-12-10 12:24:39.609 [CUP:INFO] Starting a CUPS session in 60 seconds. 2025-12-10 12:24:39.609 [__:INFO] lgw_stop:1202: — IN Note: LoRa concentrator was not started… 2025-12-10 12:25:39.610 [CUP:INFO] Starting a CUPS session now. 2025-12-10 12:25:39.610 [CUP:INFO] Connecting to CUPS … https://as1.cloud.thethings.network:443 (try #2) 2025-12-10 12:25:39.613 [AIO:INFO] /etc/station/cups.trust: cert. version : 3 serial number : 82:10:CF:B0:D2:40:E3:59:44:63:E0:BB:63:82:8B:00 issuer name : C=US, O=Internet Security Research Group, CN=ISRG Root X1 subject name : C=US, O=Internet Security Research Group, CN=ISRG Root X1 issued on : 2015-06-04 11:04:38 expires on : 2035-06-04 11:04:38 signed using : RSA with SHA-256 RSA key size : 4096 bits basic constraints : CA=true key usage : Key Cert �2025-12-10 12:25:39.616 [AIO:ERRO] [-1] HTTP connect failed: NET - Failed to get an IP address for the given hostname 2025-12-10 12:25:39.616 [AIO:DEBU] [-1] HTTP connection shutdown… 2025-12-10 12:25:39.616 [CUP:ERRO] CUPS connect failed - URI: https://as1.cloud.thethings.network:443 2025-12-10 12:25:39.616 [CUP:INFO] Interaction with CUPS failed - retrying in 1m 2025-12-10 12:25:39.616 [TCE:INFO] Starting TC engine 2025-12-10 12:25:39.617 [TCE:ERRO] No TC URI configured 2025-12-10 12:25:39.617 [TCE:INFO] Router rejected or retry limit reached. Invoking CUPS. 2025-12-10 12:25:39.617 [TCE:INFO] Terminating TC engine 2025-12-10 12:25:39.618 [CUP:INFO] Starting a CUPS session in 60 seconds. 2025-12-10 12:25:39.618 [__:INFO] lgw_stop:1202: — IN Note: LoRa concentrator was not started…

Any guidance from users running Dragino gateways with LoRa Basics Station on TTS Cloud would be greatly appreciated, especially regarding correct CUPS endpoints and expected behavior when CUPS connectivity fails.

Thanks in advance.

2

Follow-up Update (Clear Summary + New Findings)

Posting a structured update to make the issue clearer and to request further guidance from the community.

1. Current Problem in One Line

The gateway is configured for EU868 in The Things Stack Cloud,
but the Dragino device continues to run on AS923 frequencies, and CUPS never returns a TCURI.

Because of this, the correct frequency plan is never applied and EU868 devices cannot communicate.

2. What We Are Observing

Despite selecting EU868 in the TTS console, LogRead consistently shows:

  • 923.2 MHz
  • 923.4 MHz
  • 922.2 MHz
  • 922.4 MHz
  • 922.6 MHz
  • … etc.

That means the gateway boots using AS923 defaults instead of the configured EU868 plan.

3. CUPS Behavior

After switching to LoRa Basics Station → TTN, the gateway loops with:

301 Moved Permanently
Failed to retrieve TCURI from CUPS
No TC URI configured

What has been verified:

  • Correct CUPS server URI
  • Correct CUPS authorization key
  • Correct LNS authentication key
  • Gateway EUI matches TTS console
  • Tried both eu1 and as1 clusters
  • Factory reset + reconfiguration

Still no TCURI received, and no frequency plan update is applied.

4. Sequence of Actions Performed

To avoid confusion, here is the step-by-step sequence already completed:

  1. Registered gateway on TTS Cloud
  2. Set frequency plan to EU868
  3. Switched gateway to LoRa Basics Station
  4. Entered:
  • CUPS URI
  • CUPS auth key
  • LNS key
  1. Rebooted gateway
  2. Tried alternate clusters (eu1 and as1)
  3. Deleted + recreated the gateway
  4. Double-checked the EUI and keys

But the gateway still:

  • Boots up on AS923, and
  • CUPS keeps returning 301 Moved Permanently without a TCURI

5. Questions for the Community

Looking for help from anyone familiar with Dragino + Basic Station + TTS Cloud:

  1. Does TTS enforce frequency plans based on region, ignoring the console selection?
    (Meaning: could it be overriding EU868 and forcing AS923?)
  2. Why would CUPS refuse to return a TCURI even with correct keys and URIs?
  3. Is there a specific or alternate CUPS endpoint needed for Basic Station gateways on TTS Cloud (EU868)?
  4. Is it normal for Dragino gateways to fall back to AS923 when CUPS does not deliver update-info?
  5. Has anyone successfully run a Dragino gateway in EU868 on TTS Cloud via CUPS?
    If yes, what exact CUPS/LNS endpoints were used?

6. Request for Assistance

I am still debugging this and would appreciate guidance from anyone who has faced similar issues.
If additional logs/screenshots are needed, I can share them.

3

One question - when running in ‘classic’ vs CUPS mode how did you configure the Dragino GW in local console?

Had you actually configured directly for 868Mhz operation? I note you ‘registered’ as 868 in TTN/TTI console but how was actual device set? Might be worth checking/trying again if you are struggling with CUPS based implementation…..

4

Thanks Jeff-UK for your response.

image
image1426×676 99.4 KB

I have done Factory reset to default which means now the Gateway is on reset condition.
No TTN configured not anything else. (just connected to wifi)

But it is not showing me the options for the reset of the frequencies and this is a very strange behaviour.

Because the Dragino DLSO8N is 868 supported but the web UI is not showing me the option to select this specific band

Dragino cover image
Dragino cover image1600×900 89.6 KB

and also the LogRead are showing me the AS923 Band frequcies of receiver channels

image
image1426×676 105 KB

What do you say what is the core issue here?
Am I missing something important.

Sorry for posting these images but I feel this is the best way to communicate the issue

5

1st try to update the gw firmware version and see if you get EU868 option. If not contact Dragino support. Mispacked or misprogrammed SKU’s are not unheard of so label may not match actual shipped build. In early days of the TTIG I had a mispack where one of a half dozen ordered from a uk disty in single box had external labels saying EU868 but one proved to be a 915 on investigation. Had same problem of devices not being heard…..opening up confirmed a config smt resistor on pcb in 915 vs 868 config position……just got seller to replace.

Update: I notice you have the -EC25 variant with embedded Quectel EC25 cellular modem. Which version did you order? What was shipped (invoice/dispatch/shipper docs, box, inners etc.) There seems to be atleast three variants with just the Freq marking block to discriminate on the GW case label so scope for error:

Regional Variants: The EC25 version is available in multiple regional configurations to match local cellular frequencies:

  • EC25-E: Standard for Europe.

  • EC25-AFX: Optimized for North American carriers.

  • EC25-AUX: Optimized for regions like Latin America and Australia.

Looks like the E vs AFX vs AUX isnt called out directly on the device?