Unable to connect Echo Dot Gen. 2 (No new devices found)

[herzfeldd]

I have an Echo Dot Gen. 2, that is unable to discover the Amazon Echo Hub node in Node Red ("No new devices found"). Can someone point me in the right direction?

Set-up:

1. node-red is running in docker on system with IP address 10.10.60.10 (LAN interface). The docker container is running as root with the following modified command from the troubleshooting guide:
   docker run -it --network host --user 0 --name mynodered -v /tmp/data:/data --env 'DEBUG=node-ssdp:*' nodered/node-red-docker
2. The "Amazon Echo Hub" node is configured to use port 80.
3. I (slightly) modified index.js at line 301 to read:

    var ssdpService = require('node-ssdp').Server,
      server = new ssdpService({
        location: {
          port: port,
          path: '/description.xml'
        },
        udn: 'uuid:' + getHueHubId(config),
        //explicitly bind to interface enp3s0
        interfaces: ['enp3s0']
      })

This system has multiple NICs, so this line ensures that the SSDP server advertises the correct IP address.
3. My Echo Dot Gen. 2 is on IP address 10.10.60.34 (WiFi)
4. All firewalls are disabled on my network.

Debugging information:

1. The node-red instance correctly listens on UDP 1900 for SSDP messages from the Echo Dot. A complete debug log is attached, but the relevant sections show:

node-ssdp:server Outgoing server message: { message: 'NOTIFY * HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nNT: uuid:00112233-4455-6677-8899-80f90e2ef3131\r\nNTS: ssdp:alive\r\nUSN: uuid:00112233-4455-6677-8899-80f90e2ef3131\r\nCACHE-CONTROL: max-age=1800\r\nSERVER: node.js/8.16.1 UPnP/1.1 node-ssdp/4.0.0\r\n\r\n', id: '3d768c8cb4304d93' } +1ms
  node-ssdp:server Sending an advertisement event +10s
  node-ssdp:server Setting LOCATION header "http://10.10.60.10:80/description.xml" on message ID 671cb0c3f8f88a78 +0ms
  node-ssdp:server Sending a message to 239.255.255.250:1900 +1ms
  node-ssdp:server Sending an advertisement event +0ms
  node-ssdp:server Setting LOCATION header "http://10.10.60.10:80/description.xml" on message ID d1f90cbf8d885d2d +0ms
  node-ssdp:server Sending a message to 239.255.255.250:1900 +0ms
  node-ssdp:server Sending an advertisement event +0ms
  node-ssdp:server Setting LOCATION header "http://10.10.60.10:80/description.xml" on message ID 289873c21e4e9630 +0ms
  node-ssdp:server Sending a message to 239.255.255.250:1900 +0ms

2. Listening for SSPD commands on my network via sudo tcpdump -vv -A -s 0 'port 1900 and host 239.255.255.250 and udp' Shows the following exchange.

08:47:24.210032 IP (tos 0x0, ttl 4, id 32467, offset 0, flags [DF], proto UDP (17), length 318)
    server-1.herzfeld.edu.ssdp > 239.255.255.250.ssdp: [bad udp cksum 0x374a -> 0x2e71!] UDP, length 290
E..>~.@.....

<
.....l.l.*7JNOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
NT: uuid:00112233-4455-6677-8899-80f90e2ef3131
NTS: ssdp:alive
USN: uuid:00112233-4455-6677-8899-80f90e2ef3131
CACHE-CONTROL: max-age=1800
SERVER: node.js/8.16.1 UPnP/1.1 node-ssdp/4.0.0
LOCATION: http://10.10.60.10:80/description.xml

3. I am able to access both http://10.10.60.10:80/description.xml (attached) and http://10.10.60.10:80/api/description.xml (also attached).
4. Wireshark sitting on 10.10.60.10 shows what I believe is a valid exchange. Including:

No.	Time	Source	Destination	Protocol	Length	Info
10448	32.909429419	10.10.60.34	239.255.255.250	SSDP	143	M-SEARCH * HTTP/1.1 
10449	32.909429544	10.10.60.34	239.255.255.250	SSDP	136	M-SEARCH * HTTP/1.1 
10450	32.909429664	10.10.60.34	239.255.255.250	SSDP	143	M-SEARCH * HTTP/1.1 
10461	32.911021107	10.10.60.10	10.10.60.34	SSDP	319	HTTP/1.1 200 OK 
10470	32.913944732	10.10.60.10	10.10.60.34	SSDP	359	HTTP/1.1 200 OK 
10471	32.913951537	10.10.60.10	10.10.60.34	SSDP	329	HTTP/1.1 200 OK 
10472	32.913956017	10.10.60.10	10.10.60.34	SSDP	319	HTTP/1.1 200 OK 
10473	32.913961181	10.10.60.10	10.10.60.34	SSDP	319	HTTP/1.1 200 OK 
10474	32.913965414	10.10.60.10	10.10.60.34	SSDP	359	HTTP/1.1 200 OK 
10475	32.913969514	10.10.60.10	10.10.60.34	SSDP	329	HTTP/1.1 200 OK 
10476	32.913974013	10.10.60.10	10.10.60.34	SSDP	319	HTTP/1.1 200 OK 
10477	32.913978293	10.10.60.10	10.10.60.34	SSDP	319	HTTP/1.1 200 OK 
10478	32.913982961	10.10.60.10	10.10.60.34	SSDP	359	HTTP/1.1 200 OK 
10479	32.913987101	10.10.60.10	10.10.60.34	SSDP	329	HTTP/1.1 200 OK 
10480	32.913991109	10.10.60.10	10.10.60.34	SSDP	319	HTTP/1.1 200 OK 
10524	32.996296967	10.10.60.34	10.10.60.10	TCP	74	43895 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=4302083 TSecr=0 WS=64
10525	32.996409744	10.10.60.10	10.10.60.34	TCP	74	80 → 43895 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval=399052223 TSecr=4302083 WS=128
10526	32.997585120	10.10.60.34	10.10.60.10	TCP	66	43895 → 80 [ACK] Seq=1 Ack=1 Win=87616 Len=0 TSval=4302085 TSecr=399052223
10527	32.998259617	10.10.60.34	10.10.60.10	HTTP	269	GET /description.xml HTTP/1.1 
10528	32.998327028	10.10.60.10	10.10.60.34	TCP	66	80 → 43895 [ACK] Seq=1 Ack=204 Win=65024 Len=0 TSval=399052225 TSecr=4302085
10529	33.013951201	10.10.60.10	10.10.60.34	TCP	1514	80 → 43895 [ACK] Seq=1 Ack=204 Win=65024 Len=1448 TSval=399052240 TSecr=4302085 [TCP segment of a reassembled PDU]
10530	33.013953448	10.10.60.10	10.10.60.34	HTTP/XML	332	HTTP/1.1 200 OK 
10531	33.015807535	10.10.60.34	10.10.60.10	TCP	66	43895 → 80 [ACK] Seq=204 Ack=1449 Win=90496 Len=0 TSval=4302087 TSecr=399052240
10532	33.015925345	10.10.60.34	10.10.60.10	TCP	66	43895 → 80 [ACK] Seq=204 Ack=1715 Win=93440 Len=0 TSval=4302087 TSecr=399052240
10534	33.036105244	10.10.60.34	10.10.60.10	HTTP	300	POST /api HTTP/1.1  (application/json)
10535	33.036143714	10.10.60.10	10.10.60.34	TCP	66	80 → 43895 [ACK] Seq=1715 Ack=438 Win=64896 Len=0 TSval=399052262 TSecr=4302089
10536	33.052520660	10.10.60.10	10.10.60.34	HTTP	338	HTTP/1.1 200 OK  (application/json)
10540	33.068324591	10.10.60.34	10.10.60.10	HTTP	296	GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1 
10541	33.068372722	10.10.60.10	10.10.60.34	TCP	66	80 → 43895 [ACK] Seq=1987 Ack=668 Win=64768 Len=0 TSval=399052295 TSecr=4302091
10542	33.072706533	10.10.60.10	10.10.60.34	HTTP	278	HTTP/1.1 200 OK  (application/json)
10543	33.114142143	10.10.60.34	10.10.60.10	TCP	66	43895 → 80 [ACK] Seq=668 Ack=2199 Win=99200 Len=0 TSval=4302097 TSecr=399052299
11807	38.071813011	10.10.60.10	10.10.60.34	TCP	66	80 → 43895 [FIN, ACK] Seq=2199 Ack=668 Win=64768 Len=0 TSval=399057298 TSecr=4302097
11809	38.084810908	10.10.60.34	10.10.60.10	TCP	66	43895 → 80 [FIN, ACK] Seq=668 Ack=2200 Win=99200 Len=0 TSval=4302593 TSecr=399057298
11810	38.084848705	10.10.60.10	10.10.60.34	TCP	66	80 → 43895 [ACK] Seq=2200 Ack=669 Win=64768 Len=0 TSval=399057311 TSecr=4302593
11811	38.089676547	10.10.60.34	10.10.60.10	TCP	74	34487 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=4302594 TSecr=0 WS=64
11812	38.089737751	10.10.60.10	10.10.60.34	TCP	74	80 → 34487 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval=399057316 TSecr=4302594 WS=128
11813	38.091590844	10.10.60.34	10.10.60.10	TCP	66	34487 → 80 [ACK] Seq=1 Ack=1 Win=87616 Len=0 TSval=4302594 TSecr=399057316
11814	38.092958348	10.10.60.34	10.10.60.10	HTTP	300	POST /api HTTP/1.1  (application/json)
11815	38.093008127	10.10.60.10	10.10.60.34	TCP	66	80 → 34487 [ACK] Seq=1 Ack=235 Win=65024 Len=0 TSval=399057319 TSecr=4302594
11816	38.094408326	10.10.60.10	10.10.60.34	HTTP	338	HTTP/1.1 200 OK  (application/json)
11820	38.112288844	10.10.60.34	10.10.60.10	TCP	66	34487 → 80 [ACK] Seq=235 Ack=273 Win=88704 Len=0 TSval=4302595 TSecr=399057321
11821	38.112289251	10.10.60.34	10.10.60.10	HTTP	296	GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1 
11822	38.112335764	10.10.60.10	10.10.60.34	TCP	66	80 → 34487 [ACK] Seq=273 Ack=465 Win=64896 Len=0 TSval=399057339 TSecr=4302595
11823	38.113315478	10.10.60.10	10.10.60.34	HTTP	278	HTTP/1.1 200 OK  (application/json)
11828	38.155569758	10.10.60.34	10.10.60.10	TCP	66	34487 → 80 [ACK] Seq=465 Ack=485 Win=89792 Len=0 TSval=4302601 TSecr=399057340
13444	43.114033091	10.10.60.10	10.10.60.34	TCP	66	80 → 34487 [FIN, ACK] Seq=485 Ack=465 Win=64896 Len=0 TSval=399062340 TSecr=4302601
13445	43.124561764	10.10.60.34	10.10.60.10	TCP	66	34487 → 80 [FIN, ACK] Seq=465 Ack=486 Win=89792 Len=0 TSval=4303097 TSecr=399062340
13446	43.124646415	10.10.60.10	10.10.60.34	TCP	66	80 → 34487 [ACK] Seq=486 Ack=466 Win=64896 Len=0 TSval=399062351 TSecr=4303097
13447	43.128505992	10.10.60.34	10.10.60.10	TCP	74	40943 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=4303098 TSecr=0 WS=64
13448	43.128619255	10.10.60.10	10.10.60.34	TCP	74	80 → 40943 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval=399062355 TSecr=4303098 WS=128
13449	43.130455342	10.10.60.34	10.10.60.10	TCP	66	40943 → 80 [ACK] Seq=1 Ack=1 Win=87616 Len=0 TSval=4303098 TSecr=399062355
13450	43.132193933	10.10.60.34	10.10.60.10	HTTP	300	POST /api HTTP/1.1  (application/json)

I am happy to post the full dump, if it would be helpful for debugging.

This exchange looks like everything should work, but no devices are found...

Attachments

docker_log.txt
api_description.xml.txt
description.xml.txt

[herzfeldd]

Sorry, forgot to mention my versions:
Node-RED: v0.20.8
node-red-contrib-amazon-echo: v0.1.10

[Barabba11]

Have you searched solution in other different issues notifications with the same topic? Or troubleshooting guide, you may save lot of time doing that.
Maybe you simply forgot to activate the discovery,
I would suggest you to update to the latest version of node red 1.06 and don't forget to update node.js too

[herzfeldd]

Thanks for the feedback - yes, I have looked through all of the open and closed tickets. I included all the debugging info in the hopes that it will be useful to people that are experiencing the same symptoms.

Discovery is definitely turned on, otherwise I would imagine that it wouldn't be sending any SSDP traffic. I also tried the trick mentioned in #104 (toggling discovery). This has no effect.

It seems to me, based on the logs, that discovery is working appropriately. Based on the Wireshark capture, the Echo Dot successfully starts pulling json files from
http://10.10.60.10:80/description.xml
http://10.10.60.10:80/api/c6260f982b43a226b5542b967f612ce/lights
and does POSTs to
http://10.10.60.10:80/api
It seems like this is all working appropriately (no HTTP errors), except that the Dot, in the end, refuses to identify 10.10.60.10 as a new device.

I ran this using the image nodered/nod-red-docker as that is what is described in the troubleshooting guide here. The latest version of node-red in that image is v0.20.8. Using the newer tags nodered/nod-red (v1.0.6) unfortunately gives the same symptoms.

[Barabba11]

have you tried remove alexa from your alexa profile, reset it, register back to profile and ask re discover devices?

[herzfeldd]

Sorry for the delay. I just de-registered the Eco Dot from my Amazon profile, factory reset the device, re-added the Dot to the Alexa app and tried device discovery again. Unfortunately, exactly the same symptoms.

[Barabba11]

Echo is well connected to internet? What device are you using for NR? has it only one connection or other IP address?
If you are using a Raspberry why don't you install Raspbian and last NR? I have it and never had problem with Echo 2nd

[herzfeldd]

Thanks for your response.

1. Yes, the Echo dot is connected to the internet. It plays music and responds to the Alexa app just fine.
2. Node Red is running in docker on a LAN connected machine (not a Raspberry PI). I am using the latest tag on the docker container (v1.0.6)
3. The system has multiple IP addresses/NICs, as described in my original post. That is the reason that I modified index.js to ensure it is using and reporting the appropriate IP Address during discovery (this is confirmed via the Wireshark dump). Is it possible that the HTTP server is using the incorrect interface?

If I turn on Node Red debugging, I can see that the Echo is requesting information from Node Red:
Request body: {"devicetype":"Echo"}
This is the only message that I see from node-red-contrib-amazon-echo with debugging enabled.

Thanks for your help!

[herzfeldd]

I apologize. I was able to get this to work after being stupid for several hours. You must add a series of downstream "Amazon Echo Devices" before discovering them. I incorrectly assumed that the Echo would be able to discover the Hub first without any downstream devices.

This was an error in my understanding of how/which devices are discovered.

Thanks for all of the help, hopefully the debugging process / wireshark captures are at least useful to people if they are having issues getting their Echo's to connect.

[guardiande]

I had similar problems. It turned out that Sonos plugins which also use uPnP interfered with this plugin. I also have OpenHAB running on the same system which can also use uPnP. Maybe your problems come from a similar setup.