Question about WAN DHCP configuration…
larathydo last edited by
Note: Sorry if my original post looked a bit funky, I typed it on my iPhone so autocorrect made me sound like I was on crack in some places :)
I have 25Mbit fibre coming into my house via my ISP (Bell Aliant) with their "FibreOP" service. I've been doing a bit of research and it turns out that their setup is particularly picky in terms of the requirements to facilitate a successful DHCP reservation.
According to what I I've been able to find out so far, you need to configure PFSense to spoof the MAC address of the wan port of the supplied Actiontec router before the ONT will actually communicate properly. I have done this and it also appears you also have to insure that there is nothing set for the DHCP hostname, and that your WAN interface is configured for VLAN 35 as well.
I made sure all these requirements were all met, and yet I still cannot make a successful reservation. I did some more more digging, and apparently there is a bug with PFSense still assigning a hostname even though the webconfiguration page shows the hostname field left blank. I think the link itself is working, because I see I/O and the link lights flash madly, but it just seems to be holding up on the reservation request. (The bug report i'm talking about can be found here: http://redmine.pfsense.org/issues/1135).
So my question is… Where is the configuration file located for the properties of WAN DHCP? Apparently if I manually change the value to say nothing, it'll start to work.
For anyone more curious about the setup of FibreOP someone posted some more "in depth" information on how the service works at the following link:
Thanks in advance for any help!
yngndrw last edited by
Regarding the extra info link, I am personally blacklisted from that so can only assume others are too - You might want to summarise it and post it on this forum.
As for the configuration file, I haven't been a pfSense user for very long so take my advice with a pinch of salt, but I believe you can access the configuration file by downloading it as a backup, modifying it then restoring it.
larathydo last edited by
Here's what it says. For the record, I'm using 2.0 RC1
After eliminating the provided FibreOP Actiontec router from my network I thought I would document all I have learned about how the FibreOP infrastructure actually works, so here it is.
Your first question might be why did I eliminate the Actiontec router? Well… I found that when watching multiple HD channels and downloading many high traffic torrents the TV quality would suffer. While the Actiontec router doesn't really have good enough tools to determine the cause I suspect that it just could not handle the sheer number of packets per second. This is because all traffic between Bell Aliant and your local network (Internet / IPTV) has to go through the embedded processor within the router. This is a 680MHz ARM processor which can certainly handle sustained traffic, but not lots of tiny packets at the same time. Lots of tiny packets kills lots of equipment out there. I have replaced the router with a dual core Atom server, and even that machine is usually hovering around 13% with my traffic patterns.
When you order any FibreOP service you are assigned a specific router and an ONT. The MAC address of this router is added to your account. You are given access to a management VLAN (a virtual network segment over the ethernet from the ONT). This VLAN is number 33. Bell Aliant can use this to remotely manage your router. As for the ONT it is configured (usually at installation) with a specific timeslot for the fiber you are connected to. With the architecture Bell Aliant has deployed there are actually multiple people on the fiber you are connected to. You get a copy of all their data incoming but since it is encrypted you can only really see yours. As for outgoing data since you can't send light from multiple sources at the same time you have to be synchronized and only send when it is your turn (thus the timeslot value).
When you order FibreOP internet service DHCP access is added to your account and you are given access to the internet VLAN. This VLAN is number 35. The DHCP access is based on the MAC address of your router. If you hook up a different router on this VLAN with DHCP it will not get an IP address unless it is using the same MAC address as your provided router. You can not have a client identifier set in the DHCP client or you will get no DHCP lease.
Additionally if you hook up another router and it's not on any VLAN (well, it's on the default VLAN of 1) you will not be able to get a DHCP lease either and you will not be able to get to anything.
The router does NAT between this VLAN and your local network.
When you order FibreOP TV service you are given access to the IPTV VLAN. Unlike internet service where the router gets an IP address and then NATs this VLAN is actually 'bridged' to your local network. This means that any packets that your router gets and doesn't handle gets forwarded to this IPTV VLAN at Bell Aliant. One thing I learned is that packets going to this VLAN MUST contain a priority of 4 (for video). If you don't have this priority set then the packets are ignored. I suspect Bell Aliant is doing this for filtering purposes.
Let's examine how this works in the real world. When you turn on an IPTV Receiver it sends out a request to get an IP address. The provided router IGNORES this request and instead the request gets forwarded to the IPTV VLAN of Bell Aliant. A server at Bell Aliant provides the receiver with an IP address and also with additional information (where to get firmware, what firmware to get, some other configuration details). This is why you see your IPTV receiver getting a 10.X.X.X address even though your local network might be different. As the receiver contacts various IPTV servers these packets get sent to the router, which forwards them on to the IPTV VLAN and vice versa. The router is essentially a dumb forwarder.
When you tune into a channel the receiver joins a multicast group which is broadcasting the channel. This gets forwarded up the chain so that if equipment in the chain is not yet receiving the channel it shortly will, and if it already is receiving the channel then nothing needs to be done except send it downward.
This is crucial for IPTV since it scales far, there aren't multiple copies of a channel being sent simultaneously in the core infrastructure like a normal UDP stream would be. Multicast is good.
As for bandwidth usage on channels HD channels seem to utilize about 7.45Mbps and SD channels 2.45Mbps.