I tried to run the code alone in “Test luup code” rather than in a plugin to be sure that it could not be relative to something else in the plugin. No change.
I tried to set timeout to 30 seconds. No change.
I ran that from a shell on my Veralite and I got responses from twelve devices on my LAN (one of which was Vera itself) before it timed out. The WeMo was among them along with a NAS and my cat-spying security webcams.
I agree, your code is good. Time to see what your upstream connection is doing. Perhaps the router isn’t forwarding multicast packets symmetrically. Something that occurs to me is that you haven’t said if your PC is connected over Ethernet or Wi-Fi.[/quote]
My PC is connected over Ethernet (through CPL). My Vera is now connected directly to my switch router.
If the problem was due to the router, I think the code would not work on the PC. No ?
I see no parameter on my router relative to multixast packets forwarding.
I disabled UPnP IGD on the router. Could it be a problem ? I will check immediately. Edit: it changes nothing.
@futzle: you are running firmware 1.5.622 ?
I don’t know what CPL is. Try to put the two devices as close to each other as possible. If you have a Layer 2 Ethernet switch (not a router), connect that to the PC, Vera and router in a star topology. You are trying to make sure that all packets are present on the network segment and that the router can’t drop packets because it is too far upstream.
If the problem was due to the router, I think the code would not work on the PC. No ?
No, not necessarily. They are running different operating systems and there’s no guarantee that the packets generated have all the same flags or properties on them (such as the time to live). You’d need Wireshark or something equally low level to debug that.
I asked about Wi-Fi because some Wi-Fi access points have a habit of forwarding multicast from the Wi-Fi segment to the Ethernet segment, but not vice versa. Sometimes there is a configuration option to change this behaviour, usually not.
1.5.621, which is apparently the identical beta.
Using Wireshark, I can see the message is sent to 239.255.255.250 from IP 192.168.81.xx and not 192.168.1.xx. But then I see no response coming from my Sonos devices to 192.168.81.xx (neither 192.168.1.xx).
Of course, when the code is run from my PC, I see these response messages.
In the two cases, the UDP packets have the same size (109); the frame has the same size (143 bytes - 1144 bits).
I see that the same M-SEARCH message is immediately repeated by my router. That’s done in the two cases.
The problem might be that 192.168.81.xx is used rather than 192.168.1.xx. I don’t know exactly what is subnet 192.168.81.xx (eth0 on my VeraLite) but my Sonos devices are on subnet 192.168.1.xx and it looks obvious that they cannot communicate with 192.168.81.xx.
What is this interface/subnet in the Vera Lite ?
Ok, same issue here :
When I test your code in the luup test code, I see only my vera rootdevice.
And I have the same strange network configuration :
eth0 192.168.81.1 (don’t know for what it is)
and eth0:0 with 192.168.0.x, who is my correct network subnet.
So it seem right that Vera use the wrong interface to send discovery, but I don’t know what is the purpose of eth0…
That’s my feeling.
I hope we have a chance to force the right interface through lua code…
That would be interesting if @futzle could confirm having the same network setup and confirm that the wrong interface is used too.
but I don't know what is the purpose of eth0...
Good question…
I tried to use udp:setsockname(“*”, 0) that should bind to all interfaces … but no change.
Looking result of these command on Vera :
$ grep -r 192.168.81.1 /etc/*
It seem 192.168.81.1 is the default network configuration for the vera.
Present in default light_http config (webserver) or in the init script freshinstall.sh
Otherwise when you look the config file for the network configuration used at Vera startup (/etc/config/network) eth0 is named LAN with this fixed IP adresse and eth0:0 is named WAN (witch is dhcp in my case).
But I don’t know if we can remove safely eth0 and change the eth0:0 naming to eth0 without having internal bug.
I’m so sorry, but my vera is in production 
and my girlfriend will just kill me if the house run crazy 
Looking in file /etc/config/network, it seems that eth0 is the lan interface with a static IP and eth0:0 is the wan interface with DHCP…
As VeraLite is not a router, does it make sense to find LAN and WAN interfaces ?
I am now really curious to know what is different on @futzle VeraLite setup.
Yes, there is a big risk to brick the VeraLite. We really need a network expert to understand what’s wrong and what we can change without risk.
I’m pretty comfortable with Network and Linux (wich is my work) much more than programming , and I can tell you we must be able to do a ssh after reboot even if the Vera Z-wave not working anymore to revert back the network config.
But … course there is a but … I can’t guarantee there is no startup script or process that will hang up the vera startup process if the “Lan” interface disappear … so maybe the ssh daemon will not be launched … and if it the case, I don’t know if we can do a factory reset or something else …
Sure having @futzle network config or someone who have a working wemo plugin will help !
Lolodomo, I tried to force multicast to go out through eth0:0 with the help of this command :
ip route add 239.255.255.250/32 dev eth0:0 src 192.168.x.x (ip of vera in your network)
But no change to the result of your script…only discover Vera upnp root, but maybe you can give it a try ?
You can do it without risk and revert back with this command :
ip route del 239.255.255.250/32 dev eth0:0 src 192.168.x.x (ip of vera in your network)
It seem possible to perform a Factory Rest if we are stuck but it scared me :o not sure if we can do a real backup to restore parameters and zwave association after that …
http://wiki.micasaverde.com/index.php/Factory_Reset
[code]eth0 Link encap:Ethernet HWaddr 00:0E:8F:7B:72:A3
inet addr:192.168.81.1 Bcast:192.168.81.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3419384 errors:0 dropped:8 overruns:0 frame:0
TX packets:3430990 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:213992713 (204.0 MiB) TX bytes:860438133 (820.5 MiB)
Interrupt:5
eth0:0 Link encap:Ethernet HWaddr 00:0E:8F:7B:72:A3
inet addr:10.191.21.248 Bcast:10.191.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:5
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:148428 errors:0 dropped:0 overruns:0 frame:0
TX packets:148428 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:28094022 (26.7 MiB) TX bytes:28094022 (26.7 MiB)
[/code]
10.191.x.x/16 is Vera’s subnet.
Here is the outgoing packet from Vera caught at my router:
# tcpdump -c 1 -x -i br-vera udp port 1900
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-vera, link-type EN10MB (Ethernet), capture size 65535 bytes
09:16:52.914423 IP veralite.icemoonprison.com.50195 > 239.255.255.250.1900: UDP, length 101
0x0000: 4500 0081 0000 4000 0111 68bb 0abf 15f8
0x0010: efff fffa c413 076c 006d 25dd 4d2d 5345
0x0020: 4152 4348 202a 2048 5454 502f 312e 310d
0x0030: 0a48 4f53 543a 2032 3339 2e32 3535 2e32
0x0040: 3535 2e32 3530 3a31 3930 300d 0a4d 414e
0x0050: 3a20 2273 7364 703a 6469 7363 6f76 6572
0x0060: 220d 0a4d 583a 2035 0d0a 5354 3a20 7570
0x0070: 6e70 3a72 6f6f 7464 6576 6963 650d 0a0d
0x0080: 0a
Bytes 0x000c-0x000f show that the source address is 10.191.21.248, and byte 0x0008 shows the TTL is 1.
This might also be useful:
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.81.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.191.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 10.191.1.1 0.0.0.0 UG 0 0 0 eth0
There’s a special socket option to specify which interface you should be using to send multicast packets. I’m not at all convinced that you can set this from within Lua though. 
Give this a go:
route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0:0where eth0:0 is whichever interface has your LAN address in ifconfig.
Undo with:
route del -net 224.0.0.0 netmask 240.0.0.0 dev eth0:0I am lost. futzle, it seems that you have a similar VeraLite setup as ours (macfly and me). Why is it working for you and not for us ? 
What a mistery.
Even if we succeed to find a solution for the basic local network case, then I will have to make it work with the Vera in a sunet and the DLNA DMR in another subnet…
TTL is something that we have to consider. futzle, in one of your message, you say that Vera uses TTL 1 for SSDP message ? That would mean that there is no chance to go through a router ?
Doing Web searches yesterday, it seems that Windows 7 uses TTL 1 too but it exists a registry key to adjust that.
Thinking about Wireshark, I have a big doubt. Maybe it is normal that I cannot see the network traffic beween a Sonos and the Vera ? I presume that Wireshark only see the network traffic going through the PC ?
Regarding Windows Media Player discovery, I think I know why it is not working. I read that WMP is using IP v6 so we have certainly to send a discovery message to special multicast IP v6 too, 239.255.255.250 isl only for devices using IP v4.
As I say before Lolodomo, even if you can up the ttl of you packet, Mulicast don’t pass trough Vlan unless your router implement a special protocol to do this (like IGMP or PIM).
And your right for Wireshark, you will see only PC packet or broadcast because you have a Network Switch and not a network HUB.
I was pretty sure That @Futzle don’t have the same primary network interface than our… but it is the case … so why it work for him and not for us …
I will try a tshark on my plex media server to see if I received something from vera when launching the script.
EDIT : Ok, source adresse is really our problem :
205.839014 192.168.81.1 → 239.255.255.250 SSDP 136 M-SEARCH * HTTP/1.1
Do you know if it is possible with DD-WRT ? (i have not yet checked)
And your right for Wireshark, you will see only PC packet or broadcast because you have a Network Switch and not a network HUB.
Ok, thank you for confirming that point.
I should at least see response messages from my PC (XBMC) and the Vera. I am not sure XBMC was running when I did my Wireshark tests. I will do it again.
I was pretty sure That @Futzle don't have the same primary network interface than our... but it is the case ... so why it work for him and not for us ...
her
Did you try route command proposed by futzle ?
Searching on the forum, I discovered an interesting discussion: http://forum.micasaverde.com/index.php/topic,13890.msg104717.html#msg104717
It seems possible to set the LAN IP in the same subnet as the WAN IP.
I will try a tshark on my plex media server to see if I received something from vera when launching the script.
Ok.
On my side, I am a little desesperate…
Woot, I think I found a workaround …
Now I’m Able to discover my plex media server with your script :
From Plex (192.168.0.100) :
0.000000 192.168.0.101 → 239.255.255.250 SSDP 169 M-SEARCH * HTTP/1.1 // This Is My really Vera IP Address in source
From Vera Log :
50 10/20/13 11:44:08.068 luup_log:0: Call to socket.udp ok <0x2d3e1680>
50 10/20/13 11:44:08.069 luup_log:0: Call to udp:sendto ok <0x2d3e1680>
50 10/20/13 11:44:10.073 luup_log:0: LOCATION http://192.168.0.100:32469/DeviceDescription.xml <0x2d3e1680> // This is my plex media server
50 10/20/13 11:44:10.074 luup_log:0: ST urn:schemas-upnp-org:device:MediaServer:1 <0x2d3e1680>
50 10/20/13 11:44:10.074 luup_log:0: SERVER UPnP/1.0 DLNADOC/1.50 Platinum/1.0.4.9 <0x2d3e1680>
How To :
1st, ip route command or route add doesn’t seem to take the Alias attribute of a NIC. So eth0 or eth0:0 is the same for those.
I learnt from my plex media server that I received the M-SEARCH notification but with the wrong IP Address source… (this crappy 192.168.81.1)
So what can we do … Of course ! let do some IP source natting with Netfilter ! (hope iptables is installed on Vera … woot yes !, next !)
Use this command on Vera:
iptables -t nat -I POSTROUTING -d 224.0.0.0/4 -j SNAT --to-source 192.168.0.101 Last Parameter is your Vera LAN Ip Address (not the crappy .81.)
What it does :
iptables -t nat -I POSTROUTING (Put this rule In TOP of POSTROUTING table - Netfilter stuff)
-d 224.0.0.0/4 (Match all packet with Multicast destination)
-j SNAT --to-source 192.168.0.101 (Action → Replace source IP address by this one)
You can undo this command with :
iptables -t nat -D POSTROUTING -d 224.0.0.0/4 -j SNAT --to-source 192.168.0.101 or reboot Vera.
This rule is volatile, so you must add it after each boot.
It is not a solution, it is a Workaround without having to delete this primay network configuration… It will not having a negative effect on vera routine unless Internal code use Multicast too but with the .81. address … (I doubt but can’t be really sure).
@lolodomo It must be working for you too ! unless we find a better solution !
@futzle please can you post the result of this command ? :
iptables -t nat -nvLIt will print your NAT netfilter configuration.