dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
943
djbono
Premium Member
join:2014-05-16
Brossard, QC

djbono

Premium Member

[Internet] General findings re Bell Fibe & qstion app & double NAT

Hi all - been reading your excellent and very informative posts about Bell Fibe's web & TV service for about a week now (got installed Last Friday.)

First of all - I've worked at developing (parts of) VDT's illico2 platform - not that I'm proud of that (quite the opposite) - but I felt worth mentioning here, and also just fire any question about it if you want, I'll do my best (but I'm sure there are other current/past engineers here as well)

=====
First of all - I wasn't aware that Bell's solution meant overhauling (or messing up with) my whole network to properly work. I'd really prefer using my DD-WRT router but it seems it's not trivial since in my case I have to carry the TV signal as well (it's a service both my wife & daughter seemingly 'need'). I've pretty much abandoned that battle, as I really can't find out how to let the reverse packets from the STB to the mediaroom server. (Seems there are two packets almost every second coming out of the STB, maybe for security reasons, maybe it's mandatory when using multicast udp, maybe both.) And yes - my switch does IGMPv3 snooping - so that would actually be a viable idea if it worked.

To this day, I still have VDT in the house as I'm not sure about my Bell Setup - it doesn't pass all my tests.

Initial setup & shortcomings:
Decided to double NAT & DMZ my 2nd router. Everything worked fine behind the 2nd router BUT my VoIP phones. Really weird behaviour, they all would register only a few lines, not all - but worse - some would register lines from servers where other phones couldn't reach. Also - NTP wouldn't work. I reluctantly put the fault on the Double NAT'ing and went back to VDT for local lan. [I later found out that the issue was more with Bell's DNS than anything else - more on this below.]

Since I can't live/work w/o my phone lines, this is a major issue. I then decided to "f*ck it - will use Bell's router..." .

So remapped the IP, logged on by wifi and one local PC - worked like a charm. I hook it up to my switch (roughly 15-16 devices on it)... then the modem crashed badly. It still provided internet & TV - but the web UI would be inaccessible and it wouldn't provide any other DHCP services. [ I believe it's actually an appallingly Looooong time out rather than a crash tbf, but still, unacceptable]

Followed a series of power cycles (btw ... it's extremely long for the modem to pick up its carrier.../rant) and trial and errors.... decided to add devices one by one, starting with my Polycoms... which I had a hunch would be somehow related to the issue. Well boy was I right. Something about polycom's DHCP requests really mess up the sagemcom. I suspect it's the boot options requesting config files location through DHCP that the modem/back-end confuses for an arris STB dhcp request, but doesn't match the MAC/id and hence falls into a loop, my guess is the Sagemcom doesn't know how to interpret the back-end's response (if any) and just waits there. Once set to static, the modem remained alive and the phones could register (some) lines.
if interested, I have a cross mix of 650s, 335 & VVX - they all exhibited the same issue as when they were double-NAT'd. That is - only register a few lines per device. Now this is the part I really don't understand...

I snooped and found that the devices themselves didn't try to register the lines that failed (but registered in a jif the ones that worked.) Again - a server that wouldn't work on polycom A would work on polycom B and vice versa.

Anyway, I thought to myself - why would a device not even try? Only answer I had was "if it can't resolve the IP" SO I overrode the DNS and forced in Google's 8.8.8.8 and BAM... everything worked like magic from that point on, including NTP.
So this really mesmerizes me.... the DNS can resolve the addresses just fine (on my PC, on other devices,etc) but somehow it fails on the polycom phones ?!

Anyway - so that works now so I'm happy. However....:

THE QUESTION: remote app
-----
Sagemcom's WIFI has been shut down, since I want to control/monitor it with my 2nd router w/ DD-WRT. The remote app works like a charm on my Android... but fails on both my wife's iPad & iPhone - it simply "can't find any STB on my network".
I guess now that the Apple versions of the app rely on something completely differnt than Android's.
Q1) Anyone else witnessed this ?
-> if so... did you try and address it? (HOW?!)
Q2) Anyone knows what's the process behind the STB discovery on the iphones/ipads?
Q3) are there 3rd party apps that work ?

While I couldn't care less about the (non-free?) Bell Tele app - the remote app is a must for the wife.

============
Other questions/items...
+ Anybody knows if all channels are encrypted ? It'd be nice to be able to join the udp groups with a PC (perhaps w/ XBMC, mythTV?)
+ Any of you out there, fttN, using your own router to manage the PPPoE ssession and yet sucesfully stream TV to the STBs? (w/o any functionality loss?)
+ Am I the only one who thinks VDT's picture quality is generally better? (and I only have cisco boxes, the samsung ones are way sharper). I'm comparing side-by-side (well, on the same TV but one after the other, same chan, same frames) and the difference is sometimes appaling. Try "Cat in the Hat' on yoopa... Bell's compression simply can't cope with all the high frequency details in there.
+ Speaking of picture quality... anybody knows what's the codec & bitrate used by Bell? (I hope h264?)

Sorry for the biblicly long post, I hope some of you won't be discouraged by its lenght and will provide input !
Thanks
kyphos
join:2014-03-26
Ottawa, ON

kyphos

Member

@djbono,
My home network environment (and requirements) are similar to yours.
I have my own Tomato router, and a lot of gear on my LAN, including a Cisco VoIP ATA. However, I have FTTH (not FTTN), so my experience may not be fully relevant to your setup.

I configured the Tomato router to do PPPoE using my b1xxx credentials, and put it behind the Sagem. It connected through the Sagem with no problems. Some people here have reported reduced throughput with a PPPoE session passing through the Sagem, but I get full 50 Mbps download even with simultaneous IPTV streams. Upload speed does seem to be impaired a bit, but it doesn't bother me.

I'm not surprised your Polycoms caused pain to the Sagem DHCP server. I've observed myriad issues with the Sagem's DHCP implementation. For one thing, its IP leases never expire. Once a lease has been issued by my Sagem, it's there forever. Mine still displays the lease that was assigned to the Bell tech's laptop when he installed the service last month. I've also found it to be sketchy handling IP reservations.

Our family has a variety of iPhones and iPads. All are equipped with the Fibe iOS app and they work fine, including the remote control functionality. They associate with my own APs (3 of them - I don't use the Sagem WiFi). But there's a trick to getting them to work with the STBs (actually, two tricks). First, I temporarily associated the iDevices with the Sagem AP so they could find the STB. I haven't sniffed the LAN traffic, but I assume they are using SDP broadcast packets (239.255.255.250) to discover the whereabouts of the STBs. Once they paired with the STBs, I then switched the WiFi settings back to use my own WiFi network.

The second trick is to set up a static route between the Tomato LAN (192.168.1.0) and the sagem LAN (192.168.2.0). This is pretty easy with Tomato, but I'm sure DD-WRT can do it too. Even though Tomato is using the WAN port to establish the PPPoE session through the Sagem, it can also route to the Sagem. I bind a 192.168.2.0 address to the Tomato WAN interface, and define a static route to 192.168.2.0/24 through that interface. As a result, the Fibe iOS apps can connect to the STBs at their 192.168.2.x IPs once they have discovered the addresses. The STB addresses don't change, thanks to static reservations in the Sagem.

+ According to the spec sheet for the Fibe PVR (the Motorola/Arris VIP2262), it supports MPEG-4 AVC (Advanced Video Coding), which is essentially the same as the ITU H.264 standard.
+ The IPTV streams are all encrypted for transmission, as well as storage on the PVR hard drive. This architecture was devised to keep the MPAA happy...