You are here: Home » Topic » Router setup for server on different subnet than Roku?

Router setup for server on different subnet than Roku?

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Setup Issues Router setup for server on different subnet than Roku?

This topic contains 8 replies, has 6 voices, and was last updated by  greenleaf 10 years, 8 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #1085

    Digital Larry
    Participant

    My wired side LAN and (Kurobox, where Firefly is residing) are on 192.168.11.xxx. Since Roku only supports WEP I would like to isolate this from the main part of the LAN, easy enough, I can set my WEP router to use a different subnet. However then I’m thinking I’d need to set up a static route from subnet 11 to the other one, and make sure that the Kurobox and Roku are both using static IP so they don’t move around in the case of a disconnect.

    Anyone done this? Any special tricks or is it just easy as pie? I’ve never actually done any static routes so that forms part of my apprehension.

    Thx!~

    #9067

    stretch
    Participant

    Roku’s 2.7 beta firmware supports WPA BUT only on the M1001 & R1000

    #9068

    rpedde
    Participant

    @Digital Larry wrote:

    My wired side LAN and (Kurobox, where Firefly is residing) are on 192.168.11.xxx. Since Roku only supports WEP I would like to isolate this from the main part of the LAN, easy enough, I can set my WEP router to use a different subnet. However then I’m thinking I’d need to set up a static route from subnet 11 to the other one, and make sure that the Kurobox and Roku are both using static IP so they don’t move around in the case of a disconnect.

    Anyone done this? Any special tricks or is it just easy as pie? I’ve never actually done any static routes so that forms part of my apprehension.

    Thx!~

    The routing part is pretty straightforward, but the part that will get you is the fact that probably the multicast won’t go across subnets. So you won’t “see” the server on the other subnet (probably).

    The only way I know to get around that (aside from running a real IGMP routing daemon like mrouted) is to run a rendezvous proxy on the side of he network that doesn’t can’t see the server. Problem is, with that subnet only having the soundbridge, there isn’t really anything to run the rendezvous proxy on.

    #9069

    mas
    Participant

    Yep, again someone bumping over that issue with a Roku.

    Read this post here:
    http://www.rokulabs.com/forums/viewtopic.php?t=11452 and rise the issue with Roku. If enough people ask this of Roku then they may just prioritize my feature request.

    #9070

    Digital Larry
    Participant

    I’m pretty sure I have an M1001, so if it supports WPA, that would also be a viable answer to the issue. Thanks!

    #9071

    rpedde
    Participant

    @mas wrote:

    Yep, again someone bumping over that issue with a Roku.

    Read this post here:
    http://www.rokulabs.com/forums/viewtopic.php?t=11452 and rise the issue with Roku. If enough people ask this of Roku then they may just prioritize my feature request.

    I’ve asked this through my (feeble) channels as well. Hopefully something will come of it. I may just implement a broadcast based discovery protocol, and then just give them the specs. Maybe they’ll be able to find time to add support for it if it’s already done on my side.

    — Ron

    #9072

    CCRDude
    Participant

    I remember from some own multicasting implementation I did with Bonjour as an inspiration that multicasting should have no problems with subnets actually. Routers may just decrease the TTL (Time To Live) value, so multi-casting packets may die before reaching other subnets if the packets are send with a low TTL value and the routers dec a not-so-small value (and it probably makes sense for APs to reduce it more than standard routers). So maybe a custom option to set the TTL values could be an easy thing to try?

    edit: I checked Firefly, iTunes and the Roku – they all use a TTL of 255, so the above is not the reason.

    #9073

    rpedde
    Participant

    @ccrdude wrote:

    I remember from some own multicasting implementation I did with Bonjour as an inspiration that multicasting should have no problems with subnets actually. Routers may just decrease the TTL (Time To Live) value, so multi-casting packets may die before reaching other subnets if the packets are send with a low TTL value and the routers dec a not-so-small value (and it probably makes sense for APs to reduce it more than standard routers). So maybe a custom option to set the TTL values could be an easy thing to try?

    edit: I checked Firefly, iTunes and the Roku – they all use a TTL of 255, so the above is not the reason.

    Right. Been down that road also. Seems that most wireless routers are software routers, not hardware routers. And since they try to use the cheapest hardware they can, the usually don’t run a full mrouted, instead, they “fake it” with special case stuff — like rendezvous proxies that are hard-coded to proxy _daap._tcp, etc.

    Multicast works great in an enterprise environment — but then you are running cisco switches with a robust multicast implementation. I’ve got multicast code at work running on 4507s that works great. Just won’t run on consumer grade networks.

    #9074

    greenleaf
    Participant

    I guess this answers the question I was having about sharing music between subnets.

    I’ve got 3 subnets routed together with Linksys routers configured as routers rather than gateways. All nodes on the network can see each other, but I guess Firefly just won’t pass between them.

    It’s not a huge deal since one network is for my family (firefly’s on that one), one’s for testing, breaking and working on other people’s computers, and the third is an outer peripheral subnet so I can have the two routers behind it routing instead of using NAT.

Viewing 9 posts - 1 through 9 (of 9 total)

The forum ‘Setup Issues’ is closed to new topics and replies.