Closed ckhyatt closed 7 years ago
From your log, the device, 192.168.2.159, is the only one requesting information. What is this device?
It is a NVR.
On Aug 22, 2017, at 2:32 PM, BWS Systems notifications@github.com wrote:
From your log, the device, 192.168.2.159, is the only one requesting information. What is this device?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
I FINALLY figured it out. There is a switch in the middle with IGMP Snooping enabled by default. I disabled it and everything works correctly! Amazingly, the clue to the solution was an brief note in the Wiki entry for UPNP. Please close issue.
Thanks!
On Tue, Aug 22, 2017 at 2:54 PM, Craig Hyatt ckhyatt@gmail.com wrote:
It is a NVR.
On Aug 22, 2017, at 2:32 PM, BWS Systems notifications@github.com wrote:
From your log, the device, 192.168.2.159, is the only one requesting information. What is this device?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bwssytems/ha-bridge/issues/730#issuecomment-324113365, or mute the thread https://github.com/notifications/unsubscribe-auth/APWE_6qiGCqO6r33tFhv3Ja2U2ahOdPmks5sax6ngaJpZM4O-y0v .
From the Wiki:
IGMP snooping and reliability[edit https://en.wikipedia.org/w/index.php?title=Universal_Plug_and_Play&action=edit§ion=17 ]
UPnP is often the only significant multicast application in use in digital home networks; therefore, multicast network misconfiguration or other deficiencies can appear as UPnP issues rather than underlying network issues.
If IGMP snooping is enabled on a switch, or more commonly a wireless router/switch, it will interfere with UPnP/DLNA device discovery (SSDP) if incorrectly or incompletely configured (e.g. without an active querier or IGMP proxy), making UPnP appear unreliable.
On Tue, Aug 22, 2017 at 7:02 PM, Craig Hyatt ckhyatt@gmail.com wrote:
I FINALLY figured it out. There is a switch in the middle with IGMP Snooping enabled by default. I disabled it and everything works correctly! Amazingly, the clue to the solution was an brief note in the Wiki entry for UPNP. Please close issue.
Thanks!
On Tue, Aug 22, 2017 at 2:54 PM, Craig Hyatt ckhyatt@gmail.com wrote:
It is a NVR.
On Aug 22, 2017, at 2:32 PM, BWS Systems notifications@github.com wrote:
From your log, the device, 192.168.2.159, is the only one requesting information. What is this device?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bwssytems/ha-bridge/issues/730#issuecomment-324113365, or mute the thread https://github.com/notifications/unsubscribe-auth/APWE_6qiGCqO6r33tFhv3Ja2U2ahOdPmks5sax6ngaJpZM4O-y0v .
Thanks! That is a treasure of a piece of information. Will put it in the wiki.
Hopefully that will help someone else :)
Thanks!
Craig
On Aug 23, 2017, at 10:01 AM, BWS Systems notifications@github.com wrote:
Closed #730.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
My bridge has been working great for a couple of years. I am on the current version--4.5.6. I have attached the log with UPNP trace enabled. There are no errors in the log. I noticed in the Alexa app that several devices were listed as offline, even though they appeared to be working. Just SOP I forgot the devices and ran discovery again. The Echo will not discover the the bridge now! I have gone through all the web searches I can find. I have enabled UPNP on my router. I am using a UPNP analyzer and I can see both my Echo and Echo dot send an
M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: 15 ST: urn: Belkin: device: **
I can see the bridge announce NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.2.136:8080/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 NTS: ssdp:alive hue-bridgeid: B827EBFFFEA5A70B NT: uuid:2f402f80-da50-11e1-9b23-b827eba5a70b USN: uuid:2f402f80-da50-11e1-9b23-b827eba5a70b.
The attached log does not appear to show the bridge responding to the Echo/Dot's M-SEARCH.
Both the Echo devices and the bridge are on the same subnet and the same subnet as the UPNP analyzer.
The bridge controls the Vera devices and scenes with no issue. It is only discovery that is failing.
I have spent several hours troubleshooting this and reached a dead end. Any help would be greatly appreciated.
Just to be clear, I was able to control the Vera devices through Echo/Dot prior to forgetting them and attempting discovery. I am stumped why discovery is failing.
Thanks! habridge.log.zip