dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
11964
iscy
join:2015-06-16
Blainville, QC

1 edit

3 recommendations

iscy

Member

Tossing the Home Hub 2000 while keeping TV

I recently switched from Videotron to Bell because of a better offer, and the availability of FTTH where I'm located. Unfortunately, they had to bring a Sagemcom Home Hub 2000 in the house to take over the network... I tried it for a day, but latency through that device is very inconsistent, wireless is very bad for an AC device and the lack of features is absurd. After doing some research, I noticed that most where trying to use it as a bridge (can't really do that with that HH 2000, not mentioning TV) or setup another router as the DMZ (still bad for latency considering that Sagemcom garbage... oops, meant device...) or use a switch on the ONT to separate the VLAN 35 from the 36 in order to keep two routers... seriously...

At that point, I was either going back to Videotron, or going to use the HH 2000 as a door holder, nothing more, nothing less (well, it seems to be doing fine at being a paper weight at the moment...). So, I've found an infamous post about getting pfSense to replace that Sagemcom device, which gave a lot of information at first sight, but I wasn't really planning on using pfSense. While I like to keep my network sane, I don't need the extra features included in there. My previous router was a Linksys E4200 v1 running DD-WRT. It has been a very good companion until now... or let say, until I discovered that the VLAN configuration wasn't working perfectly. I'll save you the details (ask if you want to know more), but DD-WRT on that device doesn't always behave properly when configuring multiple VLANs. Some Googling suggested that Tomato would be better in that department. In fact, there were right. After flashing, configuring, sniffing, debugging, configuring, sniffing, debugging and a few glass of wines, I got that Linksys E4200 to work in the way I wanted to get things done. And just to mention, I'm posting that today because I couldn't simply use what I've found online, I had to find the cause of that dreaded issue that would make the TV stops after 5 to 10 seconds.

Here is the configuration goal:

ONT -> Linksys WAN
Linksys Port #1 -> Computer
Linksys Port #2 -> Switch to add more computers...
Linksys Port #3 -> STB (The PVR)
Linksys Port #4 -> WAN Bridge
Linksys WAN -- ONT


Port #1 and #2 are usual switching/networking ports for computers/switches. The reason to have a separate port for the STB (or STBs if you install a switch) is to be able to put those on a different VLAN/Network. By doing that, you have to run an extra cable from the router to the STB, but watching (or recording) multiple streams on the PVR will never slow down your network. Each STB is restricted to a 100mbps port, so having a 1gbps port serving it/them is more than enough. As for port #4, it's usable in case you want to quickly connect the Sagemcom thing without having to modify the setup. I've read that firmware wise, the STB won't be able to upgrade if the Sagemcom modem isn't the one plugged in. I still have to look into that, but since the tech already did the update of the STB (when installing the service), I couldn't check/test that just yet.

Here are my configured VLANs:

VLAN1: id=1, ports=1,2
VLAN2: id=2, ports=3
VLAN5: id=35, ports=4(t), WAN(t)
VLAN6: id=36, ports=4(t), WAN(t)
VLAN7: id=37, ports=4(t), WAN(t)
* (t) == tagged traffic (or trunk port)


Most will know that the ONT on Bell FTTH carries the Internet on VLAN #35 and the IPTV on VLAN #36, but I couldn't get any information about VLAN #37. When sniffing the connection between the ONT and their modem, I could see IPv6 traffic on #37, but nothing more than that. My guess would be to say that they already allocated it and pre-configured it to be ready to receive IPv6 for the Internet. I wouldn't see any reason to use it for IPTV since it seems that they reserved themselves the right to use the entire 10.0.0.0/8 network for that, which features more than enough IPs.

Configured interfaces:

BR0 (NET LAN): VLAN1 [DHCP Server 10.0.0.0/24]
BR1 (IPTV LAN): VLAN2 [DHCP Server 192.168.2.1/24]
PPP0 (NET WAN): VLAN5 [PPPoE Client cloning the Sagemcom modem]
VLAN36 (IPTV WAN): VLAN6 [DHCP Client cloning the Sagemcom modem]


Static Routes:

10.0.0.0/8 via IPTV_WAN_GATEWAY on VLAN36


IGMP Proxy:

Upstream: vlan36
Downstream: br1


The last and quite important setting is to make sure that all multicast traffic received on vlan36 would be bridged on br1. This could be different if you aren't using an embedded Broadcom router. Using Tomato on this Linksys E4200, the simpliest way was:
nvram set multicast_pass="1"

In other words, you want to make sure that the destination address does _not_ get mangled/NAT'd when doing through the router. The STB has to see the packets coming from 10.x.x.x to 239.2.x.x

If this is a setup that you also want to do, you should be able to configure Tomato or OpenWRT up until this point, then you'd have to finish with some scripts to complete the setup. Here are the scripts, if you are using Tomato, that you can add under Administration -> Scripts:

Init:
cat > /tmp/script_dhcp_iptv.sh <<EOF
#!/bin/sh
 
ifconfig \$interface \$ip netmask \${subnet:-255.255.255.0} broadcast \${broadcast:-+}
ip route add 10.0.0.0/8  via \$router  dev \$interface  proto kernel  src \$ip
 
EOF
 
chmod +x /tmp/script_dhcp_iptv.sh
 
cat > /etc/igmpproxy.conf <<EOF
quickleave
phyint vlan36 upstream
        altnet 224.0.0.0/4
        altnet 192.168.1.0/24
        altnet 10.0.0.0/8
phyint br1 downstream ratelimit 0
EOF
 

Firewall:
 
iptables -A INPUT -p 2 -d 224.0.0.0/4 -j ACCEPT
iptables -A INPUT -p udp -d 224.0.0.0/4 -j ACCEPT
iptables -I FORWARD 11 -i vlan36 -j wanin
iptables -I FORWARD 13 -o vlan36 -j wanout
iptables -A wanin -p 2 -d 224.0.0.0/4 -j ACCEPT
iptables -A wanin -p udp -d 224.0.0.0/4 -j ACCEPT
 
iptables -t nat -A PREROUTING -i vlan36 -p tcp --dport 8080 -j DNAT --to 192.168.2.64:8080
iptables -t nat -I POSTROUTING 2 -o vlan36 -j MASQUERADE
 

WAN Up (Replace with your proper MAC):
ifconfig vlan36 down
ifconfig vlan37 down
ifconfig vlan36 hw ether 44:E9:DD:XX:XX:XX
ifconfig vlan37 hw ether 44:E9:DD:XX:XX:XX
ifconfig vlan36 up
ifconfig vlan37 up
 
sleep 1
 
udhcpc -i vlan36 -b -s /tmp/script_dhcp_iptv.sh -S -m
 
sleep 2
igmpproxy /etc/igmpproxy.conf
 

That's pretty much it. Once you've done this, you need to reboot the router (to get everything applied) and you should be able to plug your STB directly in the port #3 of the Linksys router. Your network latency will be much better (saving ~0.7ms) and won't be polluted with multicast traffic.

If you are trying this and have any issues getting it up and running, feel free to ask anything. I've kept the sniffing session of the STB to the Segemcom and the Sagemcom to the ONT for debugging and reference purposes.
kyphos
join:2014-03-26
Ottawa, ON

kyphos

Member

@iscy,
Very helpful recipe. Thanks for posting.
Which/whose Tomato build are you using on the Linksys?
iscy
join:2015-06-16
Blainville, QC

iscy

Member

I took Tomato RAF "1.28.9014MIPSR2-RAF-v1.3g", built by victek is-a-geek. I believe that all the recent builds containing igmp proxy should work though.
iscy

iscy

Member

I noticed that after a bit of watching, the STB would stop receiving the packets. Going back to the sniffer to understand what was going on, I discovered that the ONT sends IGMP queries on the VLAN36 once in a while. It's most likely doing that in order to be able to timeout/terminate a multicast feed in the case that you simply unplug the STB.

I've edited the orignal post to add "altnet 192.168.1.0/24" to the upstream configuration of the IGMP Proxy.
iscy

1 recommendation

iscy

Member

After using the setup for a few days, I also noticed that the 'Apps' and 'On demand' features were not working. It is due to a DNS issue. Internet on VLAN35/PPPoE don't share the same DNS server than the VLAN36/IPTV. To resolve this, we just need to hijack all the requests that go to 'bell.ca' and 'bell.com' and use the IPTV DNS server to resolve those.

Here are the lines that you'll need to add to your dnsmasq configuration:

rebind-domain-ok=bell.ca
rebind-domain-ok=bell.com
server=/bell.ca/10.2.127.228
server=/bell.com/10.2.127.228


Once done, you can easily test this by doing on a computer:
dig mdsfe001.iptv.bell.ca

It should resolve to 10.2.121.4 if the IPTV DNS server is properly use. Otherwise, you won't get any IP.
urbang33k
join:2010-02-13
Canada

urbang33k to iscy

Member

to iscy
Great thread. Very cool.
cinergi
join:2012-11-18
Canada

1 recommendation

cinergi to iscy

Member

to iscy
Hello iscy,

I'm currently trying to set this up (also on Bell FTTH), and I have a few questions about your setup if you don't mind.

1) In the IGMP proxy configuration, do you really need the "altnet 224.0.0.0/4" statement? My understanding is that altnet is used to specify multicast source addresses, not destinations; 224.0.0.0/4 is a destination.

2) Since you've added an altnet entry for 192.168.1.0/24, don't you also need a static route for this subnet (just like you did for 10.0.0.0/8) to allow the STB to send packets back to 192.168.1.0/24? What exactly is this subnet anyway?

3) What is the iptables -t nat -A PREROUTING -i vlan36 -p tcp --dport 8080 -j DNAT --to 192.168.2.64:8080 entry used for? What's on port 8080 that you need to DNAT?

Thanks!
cinergi
iscy
join:2015-06-16
Blainville, QC

1 recommendation

iscy

Member

said by cinergi:

1) In the IGMP proxy configuration, do you really need the "altnet 224.0.0.0/4" statement? My understanding is that altnet is used to specify multicast source addresses, not destinations; 224.0.0.0/4 is a destination.

2) Since you've added an altnet entry for 192.168.1.0/24, don't you also need a static route for this subnet (just like you did for 10.0.0.0/8) to allow the STB to send packets back to 192.168.1.0/24? What exactly is this subnet anyway?

3) What is the iptables -t nat -A PREROUTING -i vlan36 -p tcp --dport 8080 -j DNAT --to 192.168.2.64:8080 entry used for? What's on port 8080 that you need to DNAT?

1) It's been a long time since I played with that, but I think so. Once the STB has joined an multicast address, this is going to tell the IGMP Proxy to forward these packets.

2) That's right. Looks like I forgot to update the WAN UP script. Before starting up igmpproxy, you need to add:
route add -net 192.168.1.0/24 vlan36
route add -net 224.0.0.0/4 vlan36

3) That's the STB. I remember seeing packets coming in from either Bell or the ONT to reach the STB directly. To allow these to reach it, I've setup port-forwarding from the router to the STB. This might not even be needed though. But the way I've done the setup was by sniffing the entire communication from the "stock" setup and setting up my network to replicate it. Since I only had one STB, I'm not sure how this port-forwarding would work if more than one STB was present.
said by cinergi:

1) In the IGMP proxy configuration, do you really need the "altnet 224.0.0.0/4" statement? My understanding is that altnet is used to specify multicast source addresses, not destinations; 224.0.0.0/4 is a destination.

2) Since you've added an altnet entry for 192.168.1.0/24, don't you also need a static route for this subnet (just like you did for 10.0.0.0/8) to allow the STB to send packets back to 192.168.1.0/24? What exactly is this subnet anyway?

3) What is the iptables -t nat -A PREROUTING -i vlan36 -p tcp --dport 8080 -j DNAT --to 192.168.2.64:8080 entry used for? What's on port 8080 that you need to DNAT?

1) It's been a long time since I played with that, but I think so. Once the STB has joined an multicast address, this is going to tell the IGMP Proxy to forward these packets.

2) That's right. Looks like I forgot to update the WAN UP script. Before starting up igmpproxy, you need to add:
route add -net 192.168.1.0/24 vlan36
route add -net 224.0.0.0/4 vlan36

3) That's the STB. I remember seeing packets coming in from either Bell or the ONT to reach the STB directly. To allow these to reach it, I've setup port-forwarding from the router to the STB. This might not even be needed though. But the way I've done the setup was by sniffing the entire communication from the "stock" setup and setting up my network to replicate it. Since I only had one STB, I'm not sure how this port-forwarding would work if more than one STB was present.
said by cinergi:

1) In the IGMP proxy configuration, do you really need the "altnet 224.0.0.0/4" statement? My understanding is that altnet is used to specify multicast source addresses, not destinations; 224.0.0.0/4 is a destination.

2) Since you've added an altnet entry for 192.168.1.0/24, don't you also need a static route for this subnet (just like you did for 10.0.0.0/8) to allow the STB to send packets back to 192.168.1.0/24? What exactly is this subnet anyway?

3) What is the iptables -t nat -A PREROUTING -i vlan36 -p tcp --dport 8080 -j DNAT --to 192.168.2.64:8080 entry used for? What's on port 8080 that you need to DNAT?

1) It's been a long time since I played with that, but I think so. Once the STB has joined an multicast address, this is going to tell the IGMP Proxy to forward these packets.

2) That's right. Looks like I forgot to update the WAN UP script. Before starting up igmpproxy, you need to add:
route add -net 192.168.1.0/24 vlan36
route add -net 224.0.0.0/4 vlan36

3) That's the STB. I remember seeing packets coming in from either Bell or the ONT to reach the STB directly. To allow these to reach it, I've setup port-forwarding from the router to the STB. This might not even be needed though. But the way I've done the setup was by sniffing the entire communication from the "stock" setup and setting up my network to replicate it. Since I only had one STB, I'm not sure how this port-forwarding would work if more than one STB was present.
cinergi
join:2012-11-18
Canada

1 recommendation

cinergi

Member

Thanks for your reply! I actually managed to get this working 100% a few weeks ago. I made a few changes to your config:

1) I used "altnet 0.0.0.0/0" in the upstream configuration of the IGMP proxy. This has the effect of proxying any upstream subnet. I have a firewall rule on that interface (VLAN 36) to protect it from non-Bell traffic, but there hasn't been any according to my firewall logs because it's a private Bell network.

2) Since I added "altnet 0.0.0.0/0", I didn't need to specify 192.168.1.0/24. In fact, I didn't even need to set up a static route for 192.168.1.0/24 - it works without it.

3) I didn't need to add this DNAT entry.

Everything is working 100% for me including video on demand and the Bell apps.

Best Regards,
cinergi
iscy
join:2015-06-16
Blainville, QC

iscy

Member

said by cinergi:

Thanks for your reply! I actually managed to get this working 100% a few weeks ago. I made a few changes to your config:

1) I used "altnet 0.0.0.0/0" in the upstream configuration of the IGMP proxy. This has the effect of proxying any upstream subnet. I have a firewall rule on that interface (VLAN 36) to protect it from non-Bell traffic, but there hasn't been any according to my firewall logs because it's a private Bell network.

2) Since I added "altnet 0.0.0.0/0", I didn't need to specify 192.168.1.0/24. In fact, I didn't even need to set up a static route for 192.168.1.0/24 - it works without it.

3) I didn't need to add this DNAT entry.

Everything is working 100% for me including video on demand and the Bell apps.

Best Regards,
cinergi

I'm glad you've been able to get this to work. Since the original setup, I didn't get any issues with Bell of the PVR. All the features seem to work properly, even programming the PVR from their website.
iscy

iscy

Member

Just to keep that up to date, I recently switched my old Linksys E4200 v1 for a Netgear R7000. The builds for TomatoRAF seemed a bit out of date (last update was in 2014), so I tried the builds from 'advanced tomato'. I flashed "Version 3.0-132" and simply copy/paste my previous setup. After the reboot, the router worked flawlessly. So if you reading this tutorial and wondering if you need one of the builds from TomatoRAF, the answer is that you don't. Feel free to pick the most up to date build (an AIO) and IGMP support will be included.

Oh, and in case you really do move to the R7000, don't forget to put the wireless tx power to 0 for both channels. It will be 42 by default, which is really low. 0 switches 'hardware default' on and will get you much better speed and coverage.

pducharme
Premium Member
join:2010-06-29
Sherbrooke, QC

pducharme

Premium Member

I think I will try to apply those instructions to a setup using a Ubiquiti EdgeMax Router....

Sure it will take me lots of time to duplicate the config under a different router OS (EdgeOS --a modified Vyatta OS). Will try this week-end I think

adisor19
join:2004-10-11

adisor19 to iscy

Member

to iscy
Hi iscy,

Is it really necessary to use the entire 10.0.0.0/8 or can we use something smaller like a /16 ? What is Bell really using from the packet capture that you did ?

I ask because this will interfere with me connecting with my work VPN..

Thanks,

Adi
iscy
join:2015-06-16
Blainville, QC

iscy

Member

I don't have all the addresses I saw the PVR communicating with, but there were more than 2 or 3 subnets. Also keep in mind that the 10.x.x.x addresses are a class 8, so they can use class 24 subnets only if their own equipment support it, which they may (or most likely) not support.

However, the trick to resolve your issue is to use VLANs and add specific routes. If you follow the entire tutorial, you'll notice that I'm keeping ports 1,2,3 to LAN0 (br0), which is for Internet and port 4 to LAN1 (br1), which is for the PVR. This means you can have different routing policies depending where the packet enters the router.

computer -> router (br0) -> 10.0.0.0/8 -> vpn
pvr -> router (br1) -> 10.0.0.0/8 -> bell

This is a feature of iproute2, which is what these routers use. I don't have a step by step instruction to set this up, but here's how it works:

1. Packet enters an interface and is destinated for an address outside that interface's subnet, so a lookup through the routing table need to be done
2. iproute2 checks if there is a specific routing table for this 'input' interface, most of the times, it doesn't
3. The routing table for that 'input' interface is used, if there is one. If a selection is done, the work end here and the packet is sent through that route. If nothing can be used (watch out for 'default' gateway rule because it can match), then it will go back to the main routing table and check for a matching entry
4. Packet uses the selected route, if one was selected

This means that you'll need to "create" tables per interface. A table is an id made of a number. This will do:

mkdir -p /etc/iproute2
echo "10 br0" >> /etc/iproute2/rt_tables
echo "20 br1" >> /etc/iproute2/rt_tables

From now on, you can show the content of these tables by doing:

ip route show table br0
ip route show table br1

As you'll notice, they will be empty.

So, table "br0" and "br1" are simply their name. Let's add some rules to specify to use these if the packets are coming from br0 and br1 interfaces:

ip rule add from 10.0.0.1 table br0 # That is, if your interface br0 has that ip.
ip rule add from 192.168.2.1 table br1

Now, you simply need to add routing rules to the right table. I don't know which routing rules you want to add for your VPN, and at the same time, you may as well keep those in the main routing tables. The br1 table will handle all the traffic from the PVR now.

Change this line:
ip route add 10.0.0.0/8 via \$router dev \$interface proto kernel src \$ip

For this one:
ip route add 10.0.0.0/8 table br1 via \$router dev \$interface proto kernel src \$ip

As you can see, I'm simply adding "table xxx" to the 'ip route add' command to specify on which table the route need to be added. When unspecified, the default is "table main".

adisor19
join:2004-10-11

adisor19

Member

Thanks iscy !

I shall start by configuring my Asus AC-66 and see how that goes.

Here's my future plan :

ONT trunk -> HP (3COM managed switch)
HP switch trunk -> Asus AC-66U (Shibby latest Tomato)
HP switch trunk -> Cisco ASA-5510 (last released ASA and ASDM)
HP switch trunk -> Juniper SRX240 (latest firmware)
HP switch trunk -> FortiGate 310B (last supported firmware)

I basically wanna reproduce a 100% working setup with all of these devices and then I'll post the recipe as well as the config file for all of them for everyone to see and share. So far I didn't have much time to advance in this, but the ASUS AC-66U config will be the first one i'll attempt following your recipe

Thanks again for sharing and I'll do the same once I get them all running.
AwaKeN
join:2006-08-15
Saint-Philippe, QC

AwaKeN

Member

You will have 4 devices with PPPOe enabled ? Good luck not be flaged !
wrick9
join:2007-12-22
Le Gardeur, QC

wrick9 to pducharme

Member

to pducharme
More than interested in looking at this scenario too. They have awesome software/hardware. Care to share your results here ?
lowping
join:2013-08-04

lowping to AwaKeN

Member

to AwaKeN
said by AwaKeN:

You will have 4 devices with PPPOe enabled ? Good luck not be flaged !

Shouldn't be an issue.
AwaKeN
join:2006-08-15
Saint-Philippe, QC

AwaKeN

Member

I have read that you can be flaged when you have more than one device with the same PPPOe account

adisor19
join:2004-10-11

adisor19

Member

Been using 2 PPPoE sessions for a few months now with no issues.
AwaKeN
join:2006-08-15
Saint-Philippe, QC

AwaKeN

Member

ok, but 4 ?? I don't mind you are doing it, just curious

adisor19
join:2004-10-11

adisor19

Member

I don't see what the problem is. Whether it's 1, 2 or 4, the total bandwidth used is still the same.
AwaKeN
join:2006-08-15
Saint-Philippe, QC

AwaKeN

Member

Yes but you are gona have 4 external IP.
AwaKeN

AwaKeN

Member

My source: »blog.ngpixel.com/post/10 ··· n-router

"You may not be able to keep this setup quite long as Bell doesn't allow to have more than 1 pppoe connection at the same time. The bot will end up killing your extra pppoe session if it gets flagged. Unless they changed their policies recently, you'll know why if your internet suddenly stops working "

Also:

»Re: [Internet] Guide to bypass Hub completely and use your own router

Gone
Premium Member
join:2011-01-24
Fort Erie, ON

Gone

Premium Member

I thought they only booted multiple sessions from the same mac?

JohnHandcock
@rogers.com

JohnHandcock

Anon

said by Gone:

I thought they only booted multiple sessions from the same mac?

They dont just do macs they also include PC's too
Expand your moderator at work

pducharme
Premium Member
join:2010-06-29
Sherbrooke, QC

pducharme to adisor19

Premium Member

to adisor19

Re: Tossing the Home Hub 2000 while keeping TV

would be nice you do it also with a nice little EdgeMax router from Ubiquiti it's like a 100$ box very powerful.
AwaKeN
join:2006-08-15
Saint-Philippe, QC

AwaKeN to iscy

Member

to iscy
I tried to get internet on my router with a managed switch, without my switch, reset my router, reset my b1 password etc and it did not worked I don't know what I did bad or did not do ...
iscy
join:2015-06-16
Blainville, QC

iscy to adisor19

Member

to adisor19
I have more experience with enterprise hardware than I do with "home hardware". From what I know, you won't have any issues with the Asus (at least, any of them running *any* Tomato release). Any Cisco ASA might cause you a little bit of trouble, that is, if it's indeed possible to actually do it without another piece of hardware. I don't think that they will let you *properly* do the IGMP part in order to get the PVR up and running. As for the Juniper SRX line, it should, really, be a piece of cake. I don't even think you'll need to do something outside of their usual scope, because they do allow pretty much anything on BSD to happen from there... however, I could be proven wrong. My experience on Juniper has been great, but I don't have any SRX at home to test this setup. Now, the FortiGate... I really want to know how this goes on it. I would be quite impressed if you could get the setup up and running without any more hardware. The PPPoE connection won't be an issue, but the PVR IGMP Proxy'ing will be. Please, keep us posted with your results.

I do hope that you aren't going to be using all 4 to actually establish a PPPoE connection over to Bell. When I got the actual fiber optic cable installed here, I tried to simply used my own network while deferring to the Home Hub 2000 for the PVR and that setup didn't last a few hours. One of the two connections would constantly be dropped after a while. It could be coming from Bell's endpoint or from the the ONT but I haven't investigate that. I simply wanted to get rid of that HH2000 as soon as possible...