DLNA Media Controller plugin - Common library for UPnP AV

[lolodomo]

I'm so sorry, but my vera is in production and my girlfriend will just kill me if the house run crazy

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.

[macfly92]

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 !

[macfly92]

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  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

[futzle]

Sure having @futzle network config or someone who have a working wemo plugin will help !

Code: [Select]

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)

10.191.x.x/16 is Vera's subnet.

Here is the outgoing packet from Vera caught at my router:

Code: [Select]

# 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:

Code: [Select]

# 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


[futzle]

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. :/

[futzle]

ip route add 239.255.255.250/32 dev eth0:0 src 192.168.x.x (ip of vera in your network)

Give this a go:

Code: [Select]

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0:0
where eth0:0 is whichever interface has your LAN address in ifconfig.

Undo with:

Code: [Select]

route del -net 224.0.0.0 netmask 240.0.0.0 dev eth0:0

[lolodomo]

I 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.

[macfly92]

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

[lolodomo]

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).

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...

[macfly92]

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:

Code: [Select]

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 :

Code: [Select]

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 ? :

Code: [Select]

iptables -t nat -nvLIt will print your NAT netfilter configuration.

[macfly92]

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.

In this post I see two interesting thing :
1st LAN & WAN config seem not really used, It is a workaround to have the same network architecture with Vera not lite (with two real NIC)
2nd This man change the .81. address without brick his Vera ... So we can set 2 IP address in the same subnet and use 2 IP  for vera.. Not sure if it is annoying thing.
or maybe we can just config LAN Interface with our config, and delete WAN one.
or maybe we could too use THE SAME IP for the two interface, since is just an Alias...

On my side, I am a little desesperate...

Don't Be Man ! My previous post give you a working workaround, and we are pretty close to find a better solution !

EDIT :

Regarding my (our) Vera NAT configuration ... I found why we have this bug (MASQUERADE wildcard for wan interface use eth0 and so replace source with .81.) ... but what I don't understand, is why it is working for @Futzle hope she (? Am I understand right ?) can give us the result of the command in my previous post.

Anyway, my iptables nat command is pretty the same than Vera config, without the bug, but we have to set the correct IP of Vera by hand.

If we keep this workaround, it will be easy to launch it at vera startup.

[lolodomo]

Use this command on Vera:

Code: [Select]

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.)

macfly, you are a genius.
This workaround is working perfectly for me too. My lua UPnP discovery code is now working from the Vera too.

I imagine that the workaround will probably be required for Vera3 users too ?

Can we conclude that futzle's VeraLite internal route table is simply different from ours ? What could be the reason ?


Additionnal good news: even Windwos Media Player is finally discovered. There was just a little difference in the returned message, no space after each entry, like "Location:hhtp://..." rather than "Location: http://...".

[lolodomo]

I am not familiar with advanded network stuff, I will certainly never find this workaround.
Thanks a lot to macfly92 and futzle.


Now I have to try to make the discovery code work even with a router between the Vera and the DMR devices !


We have to think about how we can use this UPnP discovery. The idea could be to have a UI to launch the discovery, display the result and let the user select the right DMR device. If the user entered an IP address, the result could be filtered with only DMR running on this IP. For this, the UPnP discovery will only be launched each time the user requests it.

Running the full discovery for each device at lua startup, and even regurlarly (every 5 minutes for example) to check if the DMR is still alive and to find change of port (BubbleUPnP) is possible too, but I don't know if it is a good idea to have several Vera devices launching a full UPnP discovery more or less at the same time ? Each discovery will "lock" the Vera for about 5 seconds.

[macfly92]

macfly, you are a genius.
This workaround is working perfectly for me too. My lua UPnP discovery code is now working from the Vera too.

I imagine that the workaround will probably be required for Vera3 users too ?

Can we conclude that futzle's VeraLite internal route table is simply different from ours ? What could be the reason ?

Additionnal good news: even Windwos Media Player is finally discovered. There was just a little difference in the returned message, no space after each entry, like "Location:hhtp://..." rather than "Location: http://...".

My knowledge on linux and network are much more than programming, so I'm very happy to help in your very interesting project ! Even if I have head heck to write in english while I assume that you are french like me (But it give me some training so it isn't a bad thing....)

Vera3 have a Wifi router function no ? so It have Two real Interfaces and the Netfilter bug don't apply ... so no need this "patch". I've see Futzle have a vera lite too so it is strange ... (or maybe i'm wrong)
It is not Routing related, much more Firewall related thing ... it appear because we have only one interface with a MIOS trick to apply same config as Vera with routing capability but with a side effect...

Discover with a router between will by tricky I think ...

[lolodomo]

My knowledge on linux and network are much more than programming, so I'm very happy to help in your very interesting project ! Even if I have head heck to write in english while I assume that you are french like me (But it give me some training so it isn't a bad thing....)

  Same here.
Some training without teacher to correct faults