[BUG] - Generate Secret method doesn't work with newer gateway fw version (1.11.47)

[vbtiger]

My gateway version is 1.11.47
I tried to use this sample code:

const string password = "ThisIsMySecretPassword";
const string applicationName = "TradfriControllerApp";
const string ipAddress = "192.168.0.230";
var controller = new TradfriController("Tradfri", ipAddress);
TradfriAuth appSecret = controller.GenerateAppSecret(password, applicationName);

It throws an exception: "Timeout Generating App Secret."
I've tried to increase the AckTimeout value but no luck.

Also the app writes this to the console:
"15:11:10 [DTLSClientChannel] Error - Failed to establish a DTLS session"

When checked the raw network data with Wireshark, this was the result:

[dominicusmento]

Can you please try with newest 1.11.51 gateway version and report back to save time if they are the cause... ?
Connection with created secret works fine for me on 1.11.51..

[JoergSn]

Gateway is on 1.12.31 and the code runs always into TimeOut. Nugets are all updated to todays newest versions. Increasing TimeOut also did not help.

[dominicusmento]

@JoergSn
I've cleared my appsettings and tried again now.. I have acquired the secret successfully, without updating any nuget package nor code.. From my experience it's possible that you have some kind of network problem, that's the most common reason for timeout here..

@vbtiger "Bad record mac" is probably due to the SSL being tampered with (which you are doing by using Wireshark) so that error is definitely misleading..
Just to note, if 'appName' already exists in your gateway you should use another value or reset your gateway when trying to obtain a secret for an app.. but that definitely won't lead to timeout..

If you have timeout problems, please check your router and firewall settings..

[JoergSn]

Thanks Tomidix for your feedback. To troubleshoot I also used WireShark and voila, same "Bad Record MAC" on two machines, using WLAN and Ethernet cable. Now with completely fresh settings in app.config, Tradfri-UI works like a charm. RCA might be: To many tries with possibly same appName etc.

[gardebring]

This is an old open bug but since it's marked as open I'll add to it here.
I got a new gateway as a replacement for my old one that stopped working. I updated the nuget packages to the latest version and then trying to generate a new app secret for my new gateway generates the same "Timeout Generating App Secret." as has been reported above. Gateway version is 1.16.26.
Please let me know if I can provide any additional information.

[dominicusmento]

• Ikea Android app works?
• Have you configured appsettings correctly in tradfriui?
• Can you ping your gateway from cmd?

[gardebring]

Hi. Thanks for your reply.

• Android app works
• I can ping the gateway from cmd

I did not use tradfriui, I coded up the connection myself. I will look into that and get back to you once I have.

[gardebring]

Hi again @tomidix . I had time to look into this again. So I ran tradfriui. First I got this error message:
System.IO.FileLoadException: 'Could not load file or assembly 'RestSharp, Version=106.6.9.0, Culture=neutral.
Not sure why, but I updated to the expected version and then I got the same issue again, Timeout Generating App Secret.
I tried increasing the AckTimeout but no change.
I am connected over gigabit ethernet all the way so should not be any connection issues. Any ideas of where I could look next? I know C# development fairly well but not sure what to look for.

[dominicusmento]

Hi,

I have changed my appName setting and tried to generate the secret again. That worked fine and using settings below and I can confirm that the GW version 1.16.26 is working fine.

One thing I noticed while I was playing around is that every time I publish TradfriUI app, it asks for firewall allowance so please check that you application is not blocked by fwall.

RestSharp is needed in csproj due to apiLibs problem.. (I'm waiting for the author to solve this one)

[gardebring]

Hi again. Sorry for a late reply. Been really busy with other things. Sorry to say that for me the problems persist. I pulled down a completely new copy of master from github, fixed the Restsharp issue and started it up, approved the firewall request but alas, the same issue where it crashes with a "Timeout Generating App Secret". The oddest thing though. My TradfriUI shows a version number of 1.2.0.0, but your screenshot shows 2.1.0.5.

[gardebring]

Hi again @dominicusmento . Have you had the possibility to look into this? When I clone the latest version from master I get version 1.2.0.0, not the version 2.1.0.5 that you seem to have. Am I missing something obvious here?

[dominicusmento]

Hi,
I'm still waiting apilibs owner to publish new version to fix restsharp dependency issue. Regarding the TradfriUI, I can confirm that the code in master is almost the same as mine (my 2.1.0.5 is due to publish profile which I use as distribution package -> every time I publish it's incremented automatically).. anyway I aligned it and pushed to master

Regarding your problem I really can't reproduce it.. Maybe some more info about your network would help to solve the issue as I really can't see what's stopping it from creating the secret..

[gardebring]

Thanks for getting back to me @dominicusmento . Indeed a very strange problem this!
My dev box is a Windows 10 Pro machine with a dynamically assigned IP, at the moment of this writing at 192.168.56.1.
Subnet mask is 255.255.255.0 and default gw is 192.168.1.1
I am connected over gigabit ethernet via a couple of switches.
The tradfri gateway is IP locked to 192.168.1.35 via static ip mapping in my Ubiquiti Edgerouter.
Runing a tracert from my dev box gives this:

❯ tracert 192.168.1.35

Tracing route to 192.168.1.35 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.1.35

Running a ping gives me this:

 ❯ ping 192.168.1.35 -n 3
Pinging 192.168.1.35 with 32 bytes of data:
Reply from 192.168.1.35: bytes=32 time<1ms TTL=128
Reply from 192.168.1.35: bytes=32 time<1ms TTL=128
Reply from 192.168.1.35: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.35:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

The code to create a new app secret is as of now running from a console app (.NET Core 3.1) and this is the code (simplified)

using System;
using Tomidix.NetStandard.Tradfri;

namespace Holly.IkeaTradfriConnectorConsole
{
    class Program
    {
        static void Main(string[] args)
        {
            var controller = new TradfriController("my-gw", "192.168.1.35");
            var appSecret = controller.GenerateAppSecret("GatewaySecret", "Holly");
        }
    }
}

As already mentioned, it fails when generating the secret with a "Timeout Generating App Secret".
I'd be happy to troubleshoot and dig into this but I am not sure where I should start looking, COAP is a completely unknown protocol for me, but there should be some command I could send to see if I can even communicate with the tradfri gw via coap from this machine?

[dominicusmento]

Hi,

from what I see in your last response, the issue should be in a network.
First of all it seems that ping which is an icmp, works fine.
Second, as coap sits on top of udp, you should ensure that udp functions between both, w10 device and gateway is not forbidden by any firewall rule and is not manipulated by switches in any way..
Basically, if you can ensure that udp is working between device and gw, the connection should work..
I also don't think that another subnet should be a problem because I have a vpn server in another subnet, and I'm able to connect to gw via vpn without a problem.. Dotnet version shouldn't really matter as well as the method by which the ip's are obtained by clients (static/dhcp).

I think the problem here is not the generate app secret method; my guess is that, in current network configuration, you will get timeout for any other call too. It's just that it is mandatory call for every other to work.

1. Can you try writing any random number of characters to secret setting so it will be used, then try to make connection with it and make get devices call to confirm my theory?
2. Can you confirm that udp protocol works fine between two devices?
3. Can you try to connect gw and pc to the same physical switch (or router), ensure there are no rules defined for ports in switch/router and try to generate a secret?

[gardebring]

So I did a quick nmap scan for now, I'll get back for more results:

> nmap -sU 192.168.1.35
Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-24 13:10 W. Europe Standard Time
Nmap scan report for 192.168.1.35
Host is up (0.00096s latency).
Not shown: 998 closed udp ports (port-unreach)
PORT     STATE         SERVICE
68/udp   open|filtered dhcpc
5353/udp open|filtered zeroconf
MAC Address: 74:7A:90:9A:00:D3 (Murata Manufacturing)

Nmap done: 1 IP address (1 host up) scanned in 1.86 seconds

[gardebring]

Hi again @dominicusmento. So as you can see I successfully ran an nmap scan on udp without issue.
Moving the gateway to the same switch (it's a dumb switch so no settings to configure) as my dev machine did not seem to make any difference.
Just saving any secret and then loading the UI results in this: