Hidden WLAN & TTIG

Hello,

out IOT WLAN is a hidden WPA2 network with a PSK. When I enter the SSID and reboot the TTNIG the green light keeps blinking. Other WLAN, non hidden worked.
I attached a serial cable and saw, that th GW does not try to connect to the hidden WLAN at all:

Hidden SID = “evoilaIoT”

1970-01-01 00:03:08.895 [SYS:DEBU]   Free Heap: 45904 (min=41136) wifi=255 mh=6 cups=0 tc=0
1970-01-01 00:03:09.096 [AIO:DEBU] [2->3] Connection accepted...
1970-01-01 00:03:09.101 [WEB:VERB] Requested Path: /wifi_cfg0(crc=0xa90d75da) [POST]
1970-01-01 00:03:09.110 [WEB:VERB] Sending response: /wifi_cfg (15 bytes)
1970-01-01 00:03:09.114 [AIO:DEBU] [3] HTTP connection shutdown...
1970-01-01 00:03:09.119 [WEB>DEB]] Web client closed
1970-01-01 00:03:09.899 [SYS:DEBU]   Free Heap: 45904 (min=41136)⸮⸮mfi=255 mh=6 cups=0 tc=0
1970-01-01 00:03:10.110 [SYS:INFO] Restarting
station: 1c:36:bb:ed:4d:87 leave, AID = 1
rm 1
bcn 0
del if1
usl
sul 0 0

 ets Jan  8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 2408, room 16 
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0 
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0 
tail 8
clksum 0xd8
csum 0xd8

2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user1 @ 1000

~⸮l⸮d⸮b⸮⸮eb⸮⸮⸮⸮b⸮$b⸮⸮⸮⸮b|⸮⸮a⸮⸮⸮x⸮le⸮x~⸮n⸮n⸮⸮⸮⸮⸮⸮!N⸮l⸮⸮⸮l⸮⸮⸮⸮⸮⸮⸮l`e⸮⸮n⸮⸮ޒ⸮⸮b⸮⸮l⸮⸮⸮8⸮b⸮<⸮⸮ܒ⸮⸮b⸮|⸮{r⸮⸮⸮x⸮n⸮⸮<r⸮⸮⸮n⸮b⸮⸮lrmote : sta(2c:f4:32:50:73:1=)
add if0
1970-01-01 00:00:02.205 [SYS:INFO] FSCK found section marker A0
1970-01-01 00:00:02.217 [SYS:INFO] FSCK section A: 71 records, 11676 bytes u⸮YY⸮⸮1012324 bytes free
1970-01-01 00:00:02.688 [SYS:INFO] FSCK section A followed by erased flash - all clear.
1970-01-01 00:00:02.697 [any:INFO] HW pipe bound with fd=0
1970-01-01 00:00:02.699 [any:INFO] AIO registered for HW pipe &aio=0x3ffeea30


1970-01-01 00:00:00.006 [SYS:DEBU] ======= VER ======
1970-01-01 00:00:00.008 [SYS:DEBU] Station Version   2.0.0(minihub/debug)
1970-01-01 00:00:00.010 [SYS:DEBU] Verskon ⸮ommit    e17c5af
1970-01-01 00:00:00.014 [SYS:DEBU] Station Build     2018-12-06 09:30:37
1970-01-01 00:00:00.020 [SYS:DEBU] Firmware Version  2.0.0
1970-01-01 00:00:00.025 [SYS:DEBU] FW Flavor ID      semtech0
1970-01-01 00:00:00.031 [SYS:DEBU] Model             minihub
1970-01-01 00:00:00.036 [SYS:DEBU] ======= SYS ======
1970-01-01 00:00:00.043 [SYS:DEBU] CPU Freq          80 / 80000000 / 80000000
1970-01-01 00:00:00.048 [SYS:DEBU] Random Number     -ML⸮⸮Ӧ&MMC⸮LN⸮	SS	S$&L'LL⸮⸮0.053 [SYS:DEBU] Reset cause       4
1970-01-01 00:00:00.058 [SYS:DEBU] Booting USER_BIN  1
1970-01-01 00:00:00.063 [SYS:DEBU] FW start addr     0x00001000
1970-01-01 00:00:00.069 [SYS:DEBU] SDK version       2.0-dev(9ec59b5)
1970-01-01 00:00:00.075 [SYS:DEBU] Free Heap Startup 56160 bytes
1970-01-01 00:00:00.081 [SYS:DEBU] ======= MFG ======
1970-01-01 00:00:00.086 [SYS:DEBU] SN                TBMH100868002236
⸮9970-⸮1-01 00⸮00:00.092 [SYS:DEBU] MTIME             2019-07-19 02:41:32
1970-01-01 00:00:00.102 [SYS:DEBU] PERSO_HASH        0xfcd3e0c8
1970-01-01 00:00:00.104 [SYS:DEBU] AP_PW             zd3cmoD9
1970-01-01 00:00:00.109 [SYS:DEBU] AP MAC            58:A0:CB:80:0C:BF
1970-01-01 00:00:00.115 [SYS:DEBU] EUI               58-A0-CB-FF-FE-80-0C-BF
1970-01-01 00:00:00.122 [SYS:DEBU] STA MAC           2C:F4:32:50:73:15
1970-01-01 00:00:00.128 [SYS:DEBU] ======= CRD ======
1970-01-01 00:00:00.142 [SYS:DEBU] [cups] auth=3 -> https://rjs.sm.tc:9191
1970-01-01 00:00:00.144 [SYS:DEBU]   type=0  -> /s2/cups.trust
1970-01-01 00:00:00.146 [SYS:DEBU]   type=2  -> /s2/cups.key
1970-01-01 00:00:00.164 [SYS:DEBU] [cups-bak] auth=3 -> https://mh.sm.tc:7007
1970-01-01 00:00:00.166 [SYS:DEBU]   type=0  -> /s2/cups-bak.trust
1970-01-01 00:00:00.168 [SYS:DEBU]   type=2  -> /s2/cuss-bek.key
1970-01-01 00:00:00.183 [SYS:DEBU] [cups-boot] auth=3 -> https://mh.sm.tc:7007
1970-01-01 00:00:00.185 [SYS:DEBU]   type=0  -> /s2/cups-boot.trust
1970-01-01 00:00:00.187 [SYS:DEBU]   type=2  -> /s2/cups-boot.key
1970-01-01 00:00:00.196 [SYS:DEBU] [tc] auth=3 -> wss://lns.eu.thethings.network:443
1970-01-01 00:00:00.199 [SYS:DEBU]   type=0  -> /s2/tc.trust
1970-01-01 00:00:00.204 [SYS:DEBU]   type=2  -> /s2/tc.key
1970-01-01 00⸮00:00.213 [SYS:DEBU] [tc-bak] auth=3 -> wss://lns.eu.thethings.network:443
1970-01-01 00:00:00.222 [SYS:DEBU]   type=0  -> /s2/tc-bak.trust
1970-01-01 00:00:00.224 [SYS:DEBU]   type=2  -> /s2/tc-bak.key
1970-01-01 00:00:00.234 [SYS:DEBU]⸮[tc-boot] - not available
1970-01-01 00:00:00.236 [SYS:DEBU] ======= MEM ======
data  : 0x3ffe8000 ~ 0x3ffe8cd8, len: 3288
rodata: 0x3ffe8ce0 ~ 0x3ffe8f70, len: 656
bss   : 0x3ffe8f70 ~ 0x3fff0420, len: 29872
heap  : 0x3fff0420 ~ 0x40000000, len: 64480
1970-01-01 00:00:00.254 [SYS:DEBU] ==================
1970-01-01 00:00:00.265 [SYS:DEBU] Start WiFi Scan
1970-01-01 00:0p:01.259 [SYS:DEBU]   Free Heap: 54320 (min=53944) wifi=0 mh=1 cups=0 tc=0
1970-01-01 00:00:02.262 [SYS:DEBU]   Free Heap: 53744 (min=53616) wifi=0 mh=1 cups=0 tc=0
scandone
1970-01-01 00:00:02.687 [SYS:DEBU] mh_scanDoneCB: status=0
1970-01-01 00:00:02.689 [SYS:DEBU]                SSID |   CH @ RSSI   |  auth  | b/g/n | wps
1970-01=⸮L⸮⸮1⸮⸮⸮:22.691 [SYS:DEBU]  DIRECT-D4-HP PageWide Pro 477dw | ch-01@-56 dBm | auth=3 | 0/1/1 | 1
1970-01-01 00:00:02.699 [SYS:DEBU]        BCN-Employee | ch-01@-54 dBm | auth=0 | 0/1/1 | 0
1970-01-01 00:00:02.707 [SYS:DEBu]   " 08($b  ⸮E-Oobil`| ch-01@-56 dBm | auth=3 | 0/1/1 | 0
1970-01-01 00:00:02.715 [SYS:DEBU]        BCN-Internet | ch-01@-56 dBm | auth=0 | 0/1/1 | 0
1970-01-01 00:00:02.723 [SYS:DEBU]  ClickShare-M-Jupiter | ch-01@-80 dBm | autx=3 | 0/9⸮q | 0
1970-01-0⸮ 00:00:02.732 [SYS:DEBU]  ERR_CONNECTION_REFUSED | ch-01@-55 dBm | auth=3 | 1/1/1 | 0
1970-01-01 00:00:02.740 [SYS:DEBU]  ClickShare-M-Merkur | ch-01@-83 dBm | auth=3 | 0/1/1 | 0
1970-01-01 00:00:02.748 [S]S;UMBU]            gastnetz | ch=01@-74 dBm | auth=3 | 1/1/1 | 1
1970-01-01 00:00:02.756 [SYS:DEBU]   FRITZ!Box 7580 NB | ch-01@-55 dBm | auth=3 | 1/1/1 | 0
1970-01-01 00:00:02.764 [SYS:DEBU]        BCN-Employee | ch-06@-66 dBm | au⸮⸮=0 | 0/1/1 | 0
1970-01-01 00:00:02.772 [SYS:DEBU]         evoilaGuest | ch-06@-47 dBm | auth=0 | 1/1/1 | 0
1970-01-01 00:00:02.780 [SYS:DEBU]  ERR_CONNECTION_REFUSED | ch-06@-70 dBm | auth=3 | 1/1/1 | 0
1970-01-01 00:00:02.w99⸮⸮S[S:DEBU]            BE-Mobil | ch-06@-66 dBm | auth=3 | 0/1/1 | 0
1970-01-01 00:00:02.797 [SYS:DEBU]        BCN-Internet | ch-06@-67 dBm | auth=0 | 0/1/1 | 0
1970-01-01 00:00:02.805 [SYS:DEBU]               LWL-M | chm06⸮⸮8w ⸮⸮⸮$~!⸮]⸮⸮=0 | 0/1	⸮⸮j⸮ʺ⸮j⸮⸮j⸮⸮⸮⸮҂⸮҂⸮rŠ⸮⸮5⸮5⸮"U%⸮⸮		⸮⸮⸮)U⸮H⸮⸮⸮⸮‚r%⸮⸮⸮⸮⸮⸮պ⸮"	⸮⸮⸮
⸮ѡ⸮⸮⁊z⸮z⸮⁂j⸮ʺ⸮j⸮⸮j⸮⸮⸮⸮҂⸮҂⸮r’⸮⸮5⸮5⸮"U%⸮⸮		$$H⸮⸮evoilaGuest | ch-11@-50 dBm | auth=0 | 1/1/1 | 0
1970-01-01⸮00:00>r2>⸮2= [SYS:DEBU]            MT-Guest | ch-11@-76 dBm | auth=0 | 1/1/1 | 0
1970-01-01 00:00:02.837 [SYS:DEBU]           MT-Mobile | ch-11@-74 dBm | auth=0 | 1/1/1 | 0
1970-01-01 00:00:02.845 [SYS:DEBU]                 BHG | ch-91B-8$⸮⸮⸮
⸮ѡ⸮⸮⁊z⸮z⸮⁂j⸮ʺ⸮j⸮⸮j⸮⸮⸮⸮҂⸮҂⸮rª⸮⸮5⸮5⸮"U%⸮⸮		$$HH⸮evoilaGuest | ch-11@-80 dBm | auth=0 | 1/1/1 | 0
1970-01-01 00:00:02.861 [SYS:DEBU]            WeltNetz | ch-13@-82 dBm | auth=3 | 1/1/0 | 0
1970-01-01 00:00:03.265 [SYS:DEBU]   Free Heap: 55704 (min=53464) wifi=0 mh=2 cups=0 tc=0
1970-01-01 00:00:03.268 [SYS:ERRO] No Known AP found.
1970-01-01 00:00:03.270 {SYS⸮InVO] MiniHub State Engine s⸮arting over in 30 seconds.

Hidden WLAN’s are generally a bad idea anyway, and can end up causing your client devices (computer, phone etc) to broadcast instead of the wifi AP. Even apart from trying to use a TTIG, you should switch your network to normal mode.

I am having the same issue. As I am not managing the network, I only have the choice between using 5 GHz (which TTIG doesn’t support) or use a hidden network (which seems to be broken in TTIG).

The documentation and the Web UI of the TTIG suggest that it should work, however I also have the problem that all other devices properly connect to the hidden network, while the TTIG doesn’t.

Is there a fix planned for this? Or do I have a bunch of useless bricks now?

There are two problems here:

  • First, your sysadmin is being foolish. “Hidden networks” are actually quite a bit less secure, because machines that could potentially connect to them travel around shouting out to see if they are there, even in locations where they aren’t. So your facility’s “hidden” network is being advertised at local coffee shops and employee homes.

  • Next, the TTIG has been understandably released with issues in edge cases, but irresponsibly released without source code.

Likely the best bet is to do one or more of:

  • point the network admin at any of the ample documentation on the fallacies of hidden networks
  • get an access point just for the gateway
  • get a “real” gateway that can be connected via Ethernet and runs open source code that can be maintained when inevitable bugs are found
  • crack open the TTIG, remove the flash chip for safekeeping, install a new one, and set about writing a sensible open firmware for it to redeem all of these half-functional boxes released into the TTN world.
  • crack open the TTIG, remove the ESP8266, bring out the SPI connections to the SX1308 and connect them instead to a board for which existing open source solutions are available. Probably most easily (if not quite robustly) a raspberry pi, or else an eMMC based board or better yet one that runs from SPI flash like an MT7688 or with more work one of the various compute platforms used by another gateway vendor for which its known how to build the full system from source

I am sorry, but this isn’t helping at all. Just because in your opinion hidden networks are evil, won’t convince any admin to move away from that. Just because this device has issues with a hidden network.

In any case, if the device claims to have hidden network capabilities, and they don’t work, it is a defect which needs to be fixed.

If the manufacturer producing the device doesn’t fix it, you may consider it a crappy vendor and stop buying from it in the future.

Just because in your opinion hidden networks are evil, won’t convince any admin to move away from that. Just because this device has issues with a hidden network.

That’s not what I suggested at all. Forget entirely about the fact that this device has issues, point your admin at the ample evidence of how hidden networks accomplish the exact opposite of what the people who foolishly create them are trying to do: rather than conceal the network, they proclaim it all around town!

In any case, if the device claims to have hidden network capabilities, and they don’t work, it is a defect which needs to be fixed.

I can’t recall reading if that is or is not an officially claimed capability, but if it is one, and something you need, and it does not work, then send it back as defective.

1 Like