Bell Canada vDSL demystified + GPON/FTTH

 I've been using Bell Canada's DSL lines in some shape or form for the past few decades at least.  The first internet connection I set up myself and managed myself was a Bell Sympatico DSL line.  I learned a lot back then, about DSL line filters and PPPoE and the nuances of getting that set up on my D-Link router with Sympatico's modem.  This was at a time when modems were just that, modems.  The recent release of Bell's Homehub series (and the 2wire that preceded it) are all modem/routers, this was before the 2wire was widely distributed as the Bell modem of choice.

I've never encouraged or endorsed anyone using a modem/router from any provider, they are all terrible. They are the digital equivalent of the phrase "jack of all trades, master of none"; and that rings true with all providers I've encountered so far.  They're not great routers, but the underlying technology can do the modem tasks pretty damn well, if you strip away everything else it's trying to do on top of it.  Most notably, I've found that the DHCP servers on these devices are slow, and frequently crash, so your lease times out, they also are not great at DNS, the queries are slower than going to the internet directly.  Not only are they pointing to Bell's global DNS servers, which are frequently not as fast for response time as other globally accessible DNS, but they add non-trivial delay in and of themselves.  On top of that, they are not great NAT devices, they frequently forget NAT sessions and their session limit seems to be quite low, so if you throw any number of clients at it (beyond a very minimal amount of 2-3), you'll frequently get oddities with your connection that things just stop working or don't work at all.  This requires that you restart your modem/router constantly, which isn't great.

Very quickly: The world of today is built upon the internet.  This foundation should be infallible, reliable and consistent.  The reality is that, even globally for routing, it's a convoluted mess of policies and protocols that enable us to communicate, but the equipment providing that connection in your home should not be under constant question and scrutiny to ensure it's working as intended.  In my opinion, at least for very simple networks, the connectivity provided by the network should not be the thing you're constantly trying to fix.  It's something that's astonishingly easy to get right, yet so many companies do it wrong.  There's a litany of reasons it can go wrong.  I'll refrain from commenting further because my opinions on how a network should operate - regardless of scope (eg. home/business/enterprise/provider), are a whole post in an of themselves.

There's a good number of reasons to put Bell's equipment into bridged mode (operating as a modem only) or removing it entirely.  Both of these can increase the reliability of your network, whether at home or at work.  The only exception is if they're providing you with something better than the Home Hub series.  There are a few instances that I have seen that Bell has provided Cisco or Juniper (or similar) class of equipment.  I believe this is reserved for very specific business use-cases, from medium business up through enterprise connectivity.  Setting that aside for the moment, since those solutions are good and work consistently, I want to talk about the vDSL and GPON that is provided for home-based and small-business use cases.  This often involves a home hub.

The information that Bell won't tell you is enormous.  Their usual line is to use the provided gear and that's the end of the discussion, it can be quite frustrating as a technology enthusiast or networker looking to get something a bit more robust to run your network.  It seems to me that Bell's intention is that clients in the consumer and SMB space will use their gateway as the default gateway, never ask questions and just deal with how horrible the device is.

Let me make this perfectly clear: Bell has a strong, reliable and robust network.... until you get to the gateway that they provide for you.  I've used a lot of Bell's networks for the purposes of connecting to the internet, both as a consumer, and as support for businesses trying to navigate Bell's messaging.  In every case where something is wrong, the problem is 90% of the time, the provided equipment.  If you're having a hard time with Bell, that is very likely the culprit.  Honorable mention to those in rural areas where the copper lines are horrible; but once you get past the modem/router through the copper lines to the node, it's smooth sailing out to the internet.  Why they condemn their clients to the horrible products they put out, I'll never know.  I feel that knowledgeable clients should be able to buy their own gear for the purpose of using it on Bell's network, and Bell should supply options for those people specifically, that serves their needs.  They do not.

To be VERY CLEAR: Bell, please give us devices that are strictly modems.  There's a non-trivial number of users who would benefit from this, and this message, as far as I'm concerned, has been shouted from the rooftops for years.  When it comes to fiber, give us an ONT that works, and let us figure out the rest.

To be fair to Bell, 80% of the clients they service are home-based users that don't know networking well enough to actually do what's required to get things working, and that's fair. I don't think grandma smith down the street cares that her internet isn't super reliable, as long as she can play her facebook games most of the time; but Bell EXCLUSIVELY caters to those who have zero networking knowledge or expertise; and that's what I think should change.

Moving on to more important topics, vDSL on the Bell network is fairly simple and straight forward, at least for anyone capable of their 50/10 "high speed" packages. These connections are handled by VDSL (ITU G.933.1 or ITU G.933.2), usually topping out around Profile 17a, though evidence suggests they may be moving to Profile 30a in the near future. There's remarkably little information as to the DSL profiles available if you examine the provided routers (home hubs 1, 2, and 3 - the 4 doesn't have a DSL port), however, some information can be gained from looking at wholesale customers like Teksavvy or Start.ca.  There's a ton of other wholesale clients for Bell's services, but I'm going to focus on Teksavvy since it seems to be the most popular in my area.  For vDSL 50mbps service, the unit they offer is the SmartRG 516AC, this is from a line of SmartRG modems, which includes everything from the RG501 through the RG516AC and beyond, they all have similar or the same chipsets for DSL, with varying features (the 501 only has a single ethernet port, as an example, while the 516 has full modem/router + wifi capabilities). Looking at the spec sheets for the 516AC, they support Annex A, L and M up to profile 17a.

So breaking it down, the basic specs are vDSL2+ using Profile 17a, on either Annex A, L or M, should be sufficient.  I've done my own research and found the PTM is the mode being used over VLAN 35.

I recently acquired this information by picking up a Cisco EHWIC-VA-DSL-M (Annex M supporting Profile 17a), it's entirely possible you could get everything working using the Annex A version of the same (EHWIC-VA-DSL-A), however, I have not tested this.  I have every suspicion it will work, but I have no evidence.  I'm subscribed to a wholesale line via Start.ca, who has been very good to me.  I installed the EHWIC into a Cisco ISR G2 1921 for use, which comes with it's own caveats.

Relating to Cisco vs DSL: you do not need the EHWIC-VA-DSL module's ATM port, you can disable it with the shutdown command.  How this works is that the ADSL and vDSL modes are descrete interfaces and controllers in IOS. so the ATM features and functions for ADSL are not required at all.  If you're following in my footsteps at all, you may want to look up the firmware for the card, however, there isn't an easy way to find it.  This module is the same as the built in module for the 800 series routers and the firmware is actually listed on the Cisco website under those routers.  One of the options for that firmware is the firmware that actually says it's compatible with the EHWIC-VA-DSL modules, so select that.  If you don't have a service contract with Cisco for the unit, you may be out of luck for downloading the firmware from Cisco - my only suggestion here is that if you manage to acquire it by other means, verify it with the MD5/SHA512 hash from the official download to verify it is correct and has not been tampered with.

vDSL will automatically try to connect without additional configuration, this is a L1 link and the defaults will work with this.  If you wish you can go into the controller settings (command is: (config)# controller vdsl <unit/slot/port>  where the slot/port/unit for me was 0/1/0, but could easily be 0/0/0 depending on your specific configuration), and set it to use the command ' operating mode vdsl2 ' to prevent it from discovering that.  Since it will always discover the same mode every time, this could save a bit of time when getting connected.  There's some merit to setting the SRA command here too for Seamless Rate Adjustment, though not strictly required.  After that, you may note an Ethernet interface popping up under the same unit/slot/port number, in my case Ethernet 0/1/0.  Get into the configuration mode for this interface and perform a no shutdown.  That's all that's needed here.  Next you want to create an interface for vlan 35, I selected ethernet 0/1/0.35 for the purpose, though the subinterface number could be anything, and set ' encapsulation dot1Q 35 ' to set VLAN ID 35 on the interface. this is where you set your dialer interface to dial from (pppoe enable // ppoe-client dial-pool-number #).  which requires a dialer interface configured with your username and password, as well as several other options that have been covered at length in other posts/blogs/kb articles.

One issue I kept running into was that my 1921 refused to connect and closed out the vDSL connection immediately after it was established.  I tracked this to a debug log entry that said it "failed to add pppoe switching subblock". This appears to be a Cisco bug, and I believe what finally fixed this was the inclusion of they keyword "callin" in the ' ppp authentication ' command (full resulting configuration was: ' ppp authentication pap chap callin ' - which appears to do the trick).  Once all that is set, you should have a functioning connection.  All usual nuances of setting up NAT and routing need to be done as well before you have a useful connection, but it does indeed work.

GPON/FTTH/Fibe:  This was an interesting journey down a rabbit hole for me.  Bell is using GPON very similarly to PTM over DSL, on VLAN 35.  With their recent release of the HH4k, they now have units in the field that are also XGS-PON.  So, starting from the beginning, they use GPON with 2.488 Gbit/s downstream and at least 1.244 Gbit/s of upstream (ITU G.984). This technology uses a form of waveform division multiplexing (or WDM), to mux 1310nm light for upstream traffic and 1490nm wavelength for downstream (optionally video at 1550nm).  These are split using, what is essentially a prism so tx and rx are independent, resulting in full-duplex operation.  The addition of XGS-PON is logical, since it can co-exist with GPON.  XGS-PON (ITU G.9807.1), as far as I know, uses the same frequencies as XG-PON (ITU G.987), but with increased bandwidth on upload (Nearing 10Gbit/s with 9.953 Gbit/s). hense XGS-PON - or X (for 10) G (gigabit) S (Symmetrical), PON (Passive Optical Network).  To my understanding this bandwidth is shared, and Bell will only give you a 'cut' of the bandwidth available.  It is likely they are planning to roll out, or have rolled out XGS-PON in high-demand areas, to avoid having to install more GPON line terminals to handle the user load, and more lines/splitters to divide customers up into more ports on the OLT.  At the head end, they can simply splice off the XG-PON wavelengths and install an XGS-PON line terminal to provide the required bandwidth while continuing to serve slower committed-rate clients with GPON. This is an economical solution and demonstrates Bell's ingenuity when it comes to their client-handling equipment.

There's a catch with GPON, that the transceiver needs to be authorized with the OLT.  So Bell can authorize or de-authorize whatever they want on their network, providing a significant challenge to anyone trying to remove, eliminate or otherwise bypass the homehub equipment.  With the early releases of GPON, this was a fairly trivial matter as Bell included a G-010S-A SFP GPON fiber module with the HH3k, which provided the crossover from GPON to ethernet inside of their homehub, you could remove this module and connect it to whatever you wanted, and get service, this has been eliminated with the use of the Homehub 4000, since it has a built-in GPON and XGS-PON transceiver array, which cannot be removed or changed, and must be used to connect, as alternatives are not authorized to connect to the OLT.  There are three factors for authorization that are possible, first is the module's MAC address, which is very commonly a filter that ISPs will use to classify equipment as authorized or not.  Next is the ONT S/N, which is broken into two parts, the MFR ID, which is the first four letters, and the G984 Serial number, which is an eight character hexadecimal code.  These are printed on the HH4k or the G-010S-A modules and can be readily accessed.  The last possible factor is the SLID or Subscriber Local Identifier, which is not printed on the unit nor accessible by the firmware on the homehub.  Luckily, with a bit of wizardry, I was able to obtain this information from a G-010S-A, and resulted in a string of zeros.  It appears Bell isn't using this factor, but may in the future.  We simply do not know.

So if you are pursuing a bypass to the HH3k or HH4k for GPON (the HH4k will tell you if it's in GPON mode on the WAN mode page), you can simply replace the HH4k with a Nokia G-010S-A module (which can have the MAC, SN, and SLID programmed), model 3FE46541AA (or same from Alcatel/Huawei), and reprogram it with the MAC/SN/SLID and use that instead.  All PPPoE needs to be done over VLAN 35, and everything should just work from there.

There is a git repository on the subject, so you shouldn't have any trouble getting access to the module for reprogramming, or finding the reprogramming commands.

This, of course, is informational, I offer no guarantee any of this will be valid tomorrow, or work for anyone else. If you choose to pursue removing the Bell branded equipment for your own, then do so at your own risk.  I am posting all this information because I have been consistently frustrated by Bell's lack of transparency, and rather than have anyone else go through the process of figuring it out, I wanted to put it out there for anyone seeking to do the same, so you can learn from my mistakes (of which there are many) and reach your goals faster, with less effort.  I am certain that Bell will not appreciate using alternative devices, modules, or connection methods to their network, and I am entirely positive that they will refuse to help anyone who has something set up in an "unsupported configuration".  So beware of issues.  It is handy to have the homehub given to you as part of your subscription in case of any issues.  First thing to do when experiencing a problem is to revert back to Bell's equipment and test to see if things are working with that before calling them to complain that anything isn't working.  IMO, they won't even talk to you about it until you do.

But I will say that I've moved over from using the homehubs and ISP provided equipment and my internet is quicker (lower latency), and more reliable than ever before.  Bandwidth is still limited, of course, but I can get what I need to get done, that much faster because I'm not waiting on their systems to figure out what to do next. I have control over the hardware, and I can troubleshoot very intelligently before needing to revert back to the provider-approved and supplied gear to determine if my equipment is at fault, or if their network is at fault.  Simply put, now that I've replaced the garbage modem/router they provided, I haven't had to deal with customer support for internet issues in many years.  Outages still happen, but I can determine the cause and wait it out before having to call them.

Bear in mind, that I do this on a professional level, so troubleshooting network connections is part of my DNA.  If that's not you, then maybe consider something a bit more conservative and hang onto that homehub.... just put it into bridged mode and call it a day.

HPE 1950 CLI - an undocumented COMWARE mess

 Stuck with a HPE 1950 that won't play nice?  lost connection because of a VLAN change? need to add a default route because you forgot to add one before removing the DHCP option?  look no further.

The HPE 1950 is a wonderful SMB switch for L2 and light L3 duties.  They're robust, relatively cheap, and have PoE options.  Everything you could want in a switch.  Then why is the CLI and GUI such a nightmare?  The web GUI seems to be trying too hard to shoehorn really basic functionality into really fancy and unintuitive menus.  Once you get used to the options being all over the place, you then face the lack of guidance from HPE about how to actually make use of this switch.

I've had two run-ins with the HPE 1950 that I'd like to write about.  First, there was some shenanigans with HPE support when the "DHCP Snooping" option was enabled, and it dropped all DHCP traffic, causing a Sev. 1 down.  The second, I removed a DHCP interface before adding a default route, causing me to lose all access to the web UI, luckily, I had another way.

First, what everyone is here for:

How do we make the HPE 1950's CLI actually useful?

Simple.  Connect to the unit, either through telnet (which appears to be enabled by default) or SSH, if it's enabled, or via a console cable.  Whatever option you have, connect, log in, and you'll be dropped to a relatively useless prompt of <%hostname%>.

You'll notice rather quickly, this prompt isn't really good for anything.  You can factory reset the unit using "initialize", which is almost never the best solution to the problem.  You can change the default interface IP configuration using the "ipsetup" command, but as far as I've seen, this only affects the default interface.  If you have VLAN 1 (default) disabled, or otherwise secured, then this option isn't particularly useful.  The "display" command (aliased as "show"), only allows you to see PoE information, which again, isn't specifically useful.

However, there's one command here that will get us to the 'next level': xtd-cli-mode, or extended CLI mode.  This will allow a lot more options, but again, isn't necessarily useful.  The bonus on this is that it's password protected.  Luckily, HPE's own forums has the password published for all to use.  It is "foes-bent-pile-atom-ship".  why this password? ask HPE.  I really don't know.

Next, we have a "extended" prompt. show is useful, there's a lot more commands ( "?" will bring up what's available), some of them may solve your problem, unless you need to add a route or something.

To add a route, or change an interface or similar, you'll want to issue the "system-view" command.  This puts you into the real administrators seat.  the question mark will be your friend, since this mode is basically undocumented.

Some helpful stuff:

vlan # - add a vlan to the switch config. (brings up a sub-menu to add description and other things)

interface (gig/xge) 1/0/# - enter switchport configuration mode

interface vlan # - enter vlan interface configuration mode

Under interface config mode, you can also shut, and no shut, and also issue vlan commands.  "port" is the keyword (similar to "switchport" on Cisco), where "port link-type (access/hybrid/trunk)" for switchport mode access/trunk, and "port (access/hybrid/trunk) vlan # (untagged/tagged)" will add vlans to an interface.

To Summarize:

Connect by available method
enter "xtd-cli-mode"
enter password "foes-bent-pile-atom-ship"
enter "system-view"

Afterwards, use "?" the same way you would on any other router/switch CLI, and you should be able to figure the rest out.

Story time:

Several years ago, I was implementing HPE 1950's for a client for the first time.  I was checking out all the features.  After deployment, I continued looking into what we could/should implement for security, performance, etc.  They were using the switching entirely in Layer 2 mode, the only L3 interface was for management.  I came across the DHCP snooping option, and enabled it to see what it would do.  I was in for a ride.  I thought "snooping"? how bad could it be?  Well, apparently HPE's idea of snooping is also DHCP enforcement, where you have to authorize DHCP servers.  At the time, HPE had a bug in the 1950 where this option, once enabled, had no GUI button to turn it off.  This has since been fixed, but at the time I was stuck, so I quickly assigned it the LAN DHCP server's IP as an authorized DHCP server, and thought that would 'fix it' at least to the point where DHCP would function.  Wrong again.  I don't know, to this day, whether the feature was just completely broken, or if I had done something horribly wrong. DHCP was down, for everyone on the LAN.  This network just went live.  So I tried everything to try and fix it, even getting to the useless CLI modes I've listed above, with no success.  At the time I didn't have the "extended cli mode" password so I was at an impasse.  I called HPE and started a support ticket, the network is down, so I indicated it was the highest severity, and began working with a technician, while a coworker zipped around the office to static IP all the workstations they could, to try to get some people at least working until we fixed the problem.

After several hours of working with HPE we were nowhere.  No resolution in sight, but being keen-eyed helped me here.  I saw the HPE tech get into extended CLI mode, and while I didn't have the password, I saw him use the "sys" command (aka "system-view"), and when he disconnected to have a higher-level team callback (who calls back on a Sev.1 issue?), I re-entered system-view and issued the "no dhcp snooping enable" command, and fixed my own issue.  Years later I found the extended CLI mode password, and was able to complete the whole thing myself if needed, but to this day, I've never been so curious about the DHCP snooping, and whether it's been fixed, to test it out and actually enable it.

Second story:

I'm prepping a small set of 1950's in Layer 3 static routed mode for a client, this is a growing network, but they haven't yet budgeted for a truly L3/routed setup, much to my dismay.  So I proposed an approximation of one, that should be relatively simple to adapt to full L3 switching and expand exponentially, when the time comes.  I drew up an IP subnetting plan, broke down subnets per building, making each 1950 a gateway/router for the network.  I finally got their switches into my lab for prep.  There were about 6 new switches, only two needed routing enabled (the third building had an L3 capable switch already - which was adjusted after the fact).  Well, while I'm prepping the switches, I setup a management vlan.  VLAN 101 was used for the purpose.  The problem I ran into is that the native/default interface (VLAN1) being DHCP, obtained a default route from the DHCP server, which I had setup before hand.  After setting up VLAN 101, I removed the IP from the VLAN1 interface, and the unit dropped off the face of the earth.  It clicked relatively quickly for me that I forgot to add a default route through VLAN 101's gateway, to route back to my workstation on VLAN1.  No problem, I'll just switch my workstation to VLAN 101, except, VLAN 101 doesn't have DHCP, and I'm not in physical proximity to my lab.  So I go to my lab router, add DHCP to VLAN 101, change my VLAN to 101, and my lab workstation drops off the face of the earth.  facepalm. I didn't add VLAN 101 to the port I'm connected to.  what now?  So I jumped onto the lab router (a Cisco ISR), and started poking around.  I found that I could telnet into the problematic switches, since the lab router had IPs on all relevant VLANs, and local connectivity works without a DG being set.  I got into the switch that didn't have a default route and after getting into "system-view" mode, I was able to issue an "ip route-static 0.0.0.0 0 <gatewayIP>" with some extra parameters for priority and comments.  So now that switch is fixed.  I backed out and connected to the switch my workstation was connected to, I checked for ports that are up/up, and found my system on gigabit port 2, once into the interface config, issued 'port link-type hybrid' and 'port hybrid vlan 101 tagged' and poof, my workstation popped up.

I find it ironic that I was able to fix the IP routing issue before I got my workstation online again.  This happened because I was trying to remember how to get into what Cisco would call "configure terminal" mode, again.

I'm not perfect, but I'm pretty proud of my ingenuity on figuring all this out about a platform where the CLI is basically not documented.  I don't want this information to go to waste, and I hope it helps someone else.  Be well.

VMware VCSA 6.5U1a accept EULA

Strange error today, I wanted to share because I didn't find a solution on google immediately.

I came across the solution by cleverness alone.

Situation: VCSA updated to 6.5U1 and 6.5U1a is available (build 6671409); trying either the repository or the CDROM method of updating is unable to be completed: no 'accept' button available when trying to install.

For reference and searching: accept grey, unable to accept EULA, cannot accept EULA, cannot update, unable to update VCSA....

The problem: Chrome has no check box to accept the EULA, and the button to proceed is grey, so you have two options: read the EULA, or cancel, neither results in an install.

The solution: use Firefox.

I'm a huge fan of Chrome; but sometimes, Firefox just works.  this is one of those times.

Good luck out there in the tubes... until next time.

Network connectivity - the definitive guide.

Ever had network connectivity issues? I certainly have seen a good share.  I'd like to take a minute to go over, my definitive guide on navigating network connection problems.  I'm going to take a 'ground up' approach and assume nothing.  If you have some knowledge of your own environment and know certain things are working, then you can probably skip large sections of this post, and get to the 'good stuff' near the bottom - where I normally start, since it's most likely the be the problem.

From the top, from the perspective of one PC not being able to reach the internet:

First question: Do you have a network card?  This seems like a dumb question at first, don't all PC's have network cards?  Not always; in addition, the network interface can malfunction or be disabled.  While you may have a physical port for a network wire, it might go nowhere, so let's talk devices.

From your desktop as a starting point, if you go to start, and right click 'computer' you should be able to get to the computer's properties.  For those not using Windows 7, go to control panel, and select "system properties", and you should end up in the same place... this also works for 7, but the other way is easier.  Take a look at the left of the computer properties window, at the top you should have a link for "Device Manager" - go there.  When inside of device manager, you want to see if your network interface exists.  It may be listed as "NIC" or some brand-name of device under "network adapters", or if the device is lacking a driver, it may be under "other devices" as an "ethernet controller".  I'll tell you how to handle each of these potentially problematic situations.

If you can find a network interface, and you're convinced it's correct; if that device has no errors or warnings, you can bypass this entire section.  Go down to IP troubleshooting.

Device issues and troubleshooting.

Network interfaces is missing or doesn't contain a physical device.  Several "software" network interfaces can appear here, like virtual adapters if you have VPN software installed.  Ignore these, they are not relevant to this discussion, if the Network adapters section contains no items, doesn't exist, or only contains software adapters, then check device manager for "other devices" and determine if you have an unknown (yellow question mark) device listed as an "Ethernet controller".  If so, you need drivers.  You'll have to consult with your manufacturers website.  Briefly, there's a few places you can look.  If you know the make/model of adapter you have, you can easily look it up on google with the keywords: Driver download, and you should be able to find what you require to make the network interface work.  For external (usb) devices, the make and model should be printed on the device; for internal, things get a bit more tricky.  If the device is built-into the system, then you essentially have to look one of two places: if it is an OEM system (Eg. HP, Compaq, Toshiba, Asus, Acer, Dell, IBM/Lenovo, etc.) then you should visit that manufacturers website, and look up your model of PC and it should have the relevant drivers as part of a driver downloads section for that system (look for the system under 'support').  With Dell/HP this might be easier, since I know they use service codes to uniquely identify all PCs, you should be able to enter the service code in the support section of their site and get to the correct system.  For custom built systems, you'll need to know what the Ethernet controller is a part of, and look under that; most commonly, this will be your mainboard.  The mainboard should have the make/model clearly printed on it.

If the device is neither in "network interfaces" nor is it found under "other devices" is may be disconnected, malfunctioning or disabled on a hardware level.  Most commonly, this will be a USB device that isn't properly attached, or a device that is disabled in the BIOS.  Your mileage may vary, but at that point it is a hardware problem or malfunction that needs to be resolved.  Check your BIOS if you know how to do so, and ensure that all network interfaces are enabled, and in the case of USB, ensure that you're using a known-good port, and using known-good cables (if there are any additional cables connecting the device to the system).

When you have proper drivers, there should be the network device listed in "network interfaces" under device manager; then we have a whole other list of issues that could occur.  If the device is showing up with no warnings or errors, you can move onto the IP Troubleshooting section.

If the device has a small circle with a down arrow on it, it has been disabled.  Right-click and select enable, then reassess.

If there is a yellow triangle on the device, it has an error or warning, open properties and check the warning.  At this point, you may have to google the device name and the warning for a more in-depth understanding of what's happening, and what to do next.

At this point, either the device is working or you're googling for some answers on what error might be causing it to not work. So we move on.

So now, you have a network controller that has drivers and is working (not disabled).  Excellent.  Let's talk cables.  You should have a known-good network wire connecting you to your upstream device - the upstream device, depending on configuration, could be a switch, a router, a modem or some other Ethernet connectivity device, or media changer/extender.  On your PC, usually near the Ethernet controller port, you should have a green light.  Sometimes the light is a different color, most commonly green.  This indicates you have "Link"  it might blink to show activity, or it may have an amber companion light that blinks to show activity.  Not all Ethernet ports have lights, but most do.  If yours does not, plug the cable in anyways, and go look at the light indicating connection on your upstream device.  Some devices have one light to indicate multiple Ethernet connections - I can't help you here, but for almost every switch, router or modem I've encountered, with few exceptions, there are numbered lights.  Ensure that the numbered port you've connected yourself to, is showing that the associated port's light is illuminated to indicate connection.  The light may blink to show activity.

In the case of Wireless, you can "connect a wire" by selecting a wireless network to connect to.  Typically this is done within windows, and you only need to select a small icon made of multiple "signal" bars, in the bottom right corner near the clock.  left-clicking this icon should show a list of nearby available networks to connect to.  Remember, wireless has an OPTIMAL range of about 100m (without the use of specialty equipment), so ensure you're close enough to your router or access point to be able to receive the signal with sufficient strength to connect.  Wireless connectivity and reception issues are beyond the scope of this discussion.  Ensure you have the correct passphrase or network password to connect and that it shows that you are connected to that wireless network.  This is the wireless equivalent of "plugging in a cable".

At this point I assume you have a working device with the correct drivers and a reliable connection to your network, whether wireless or wired.

IP Troubleshooting.

Now we get into the nitty-gritty.  This is where things most commonly go wrong.  If someone calls me to get some assistance with their networking trouble, I start here, since typically, nobody touches their underlying networking configuration.

A great thing to do first, if you haven't already is to power-cycle the primary connectivity devices for your network.  What do I mean by that? easy.  Router, modem, switch if applicable.  Whatever is between you and the internet, reboot it. try again.  This is networking 101.  in consumer environments, generally, the equipment has a fairly high failure rate due to glitches, bad programming, lack of updates, or poor quality hardware or worksmanship.  This is the reality of low-cost equipment (by low-cost I mean less than ~ $500 for a router - which is what business/corporate grade stuff basically starts at).  By restarting it, generally you can "fix" any minor issues in the equipment, and continue on your merry way with little to no further work.  Enjoy.

For the rest of us, let's power on.  Start with a command prompt (windowskey+R, then type "cmd" will bring this up, or find "command prompt" in your start menu): type "ipconfig /all"  - we need the /all so we get gateway and DNS information too.  Don't type the quotes :) .

Breaking down ipconfig:

IP Address: this is NORMALLY, something starting with 192.168.x.x.  Depending on configuration.  For most consumer grade equipment, you're going to be dealing with the Class C private range (which is 192.168.x.x) as defined by RFC 1918.  All that blah blah being said, the IP address you have doesn't really matter, as long as it DOES NOT start with 169.254.x.x - these are what we refer to as "APIPA" addresses; Automatic Private IP Addressing.  the keyword there is "private": meaning, you can't go onto the internet with those addresses.  An IP address starting with 169.254 usually indicates that the DHCP server is not working; this is what gives you your IP address.  The DHCP service is usually provided by your router or modem.  You'll need to start investigating if those devices are working correctly, if you have a 169.254.x.x IP address.  They might be able to power on, but they might not be working, a replacement is easiest, but most costly, if possible try with another system, another cable, and try to narrow down if it might be a malfunction in the network device in your PC, a bad cable, a bad modem or router, or if it's something with your PC.  If you have a good cable, modem, router, and another system that gets DHCP, it may also be a firewall.  Check for any firewalling applications (Norton, McAfee, ZoneAlarm, to name a few), and try uninstalling them (BE CAREFUL, if you're uninstalling an application you PAID FOR, ensure you have the product key from the application before uninstalling it, so you can reinstall and re-activate the software without having to pay for it again).  If there's no firewall, there may be a faulty service on your PC, or the device may not be working correctly; services require a reinstall, faulty device can be bypassed by using (or borrowing?) another network interface (eg, a USB wireless device).

Assuming your IP is o.k.:

Gateway: the gateway is exactly that, your gateway to the internet.  Ensure that you have one.  It should have an IP that's similar, but not the exact same, as your system's IP address.  Eg. if your PC is at 192.168.0.100, then your gateway might be 192.168.0.1.  This is a common configuration but by no means the only configuration.  Ensure that you have one and that most of the numbers are the same.  Usually only the number after the last dot changes, but your mileage may vary, depending on the configuration of your network.  If you have no gateway, but you have an IP.  check if someone has set a static IP on your system.  Go to Network and Sharing center, select manage adapters on the left, right click your network interface and find "IPv4", select it, and press "properties" - all the items on the next page should be set to automatic.  If not, make note of what the settings are, then set them to automatic and retry your internet.  If this is already automatic, and "gateway" is blank on ipconfig, then the problem is likely going to be that you did not receive a gateway IP from your DHCP server. in the ipconfig output, it should show which DHCP server it got a response from, go contact whomever is responsible for that server, and complain to them.  Normally this will either be you (if it is a router) or your ISP (if the DHCP server is outside of your local network) - again, this will depend on configuration.

Next, ensure that you can reach your gateway, and that it is responding to requests by running a "ping" at the command prompt, followed by a space, then the IP of the "gateway" as reported by ipconfig.  If this does not respond, then the gateway may not be working, consult with your ISP if your router/gateway belongs to them, and if not, consider getting a new router or gateway for your network, or resetting the one you have to defaults and setting it up from scratch.

Assuming you have a gateway that you can reach, check if you are on the internet at all.  To do this, simply run a ping (from the command line) against any known-good IP address.  Most ISP's allow you to ping google, but "google.com" is a name, not an IP.  Google has DNS servers at 8.8.8.8 and 8.8.4.4, that are known to respond to pings; so if you don't know of a known-good IP address on the internet try to "ping 8.8.8.8" and see if you get replies.  The replies should say they're from 8.8.8.8, and should give the amount of time we spent waiting for the reply (usually in ms. usually less than 200. more and it could be a problem, contact your ISP for performance troubleshooting).  IF THERE IS NO REPLY or replies come from another source with a message like "destination network is unreachable" then you may not be connected to the internet.  Ensure all the appropriate lights on your modem are on, and try to communicate with your ISP for troubleshooting internet connectivity issues further.  There may be an outage or other issue that is beyond your control if this fails.

Assuming you can connect to the internet by IP address, the issue could also be your DNS servers.  You should have two listed in your "ipconfig /all" output, ping them, see if you get a response.  Additionally, try the command "nslookup" to try to resolve a known network name (any website is fine) - eg: "nslookup www.google.com" - it should reply with an IP address.  If not, and you get 3x (or more) "request timed out", then your DNS server isn't working.  You may be able to change to something known-good, like google's... Google maintains two Anycast DNS servers.  All that technical talk only really boils down to: Primary Google DNS: 8.8.8.8, Secondary Google DNS: 8.8.4.4. This can be changed under IPv4 properties, under "control panel", "network and sharing center", "Change adapter settings" (on the left), then selecting the network interface, and going to properties.  you should find IPv4 and you should be able to get into it's properties from there.  Just change the DNS settings on that page (at the bottom) to reflect google's DNS servers listed above, and re-test with nslookup.  If this still doesn't work, your ISP may be blocking DNS requests to external servers, talk to them if that's the case, they may have DNS servers they want you to use.

If your DNS resolution works but internet pages still don't load in your favorite browser, you may need to adjust your "connection" tab settings in internet options.  "Internet Options" can be found on the Control Panel.  Select the "connections" tab, and check to see if there are any dialing rules - there shouldn't be, unless you are using dial-up, or certain types of DSL... you should know if you are.  If you're using cable internet, or have a DSL modem that handles the PPPoE connection (again, if you use this, you should at least recognize the terms), then check "LAN settings".  under most normal circumstances in consumer environments, the next dialog should have everything unchecked.  "Automatically detect settings" is default, but I only find that it slows down my first connection to the internet, so I generally disable it.  Unless you specifically have a proxy set up, or you've been told by your ISP or network administrator to use a proxy, there shouldn't be one set; if there is, it may be the problem.

I know Firefox has it's own set of this same type of dialog, but I am unfamiliar with it.  I would ask Firefox users to test using another browser to ensure it's not JUST Firefox that's having the problem.  If it's just Firefox, you will have to investigate that independently.

Lastly, I want to touch on Firewalls.  The windows firewall generally only restricts unsolicited inbound traffic - meaning, when someone connects to your PC from across the network.  It can be opened to allow the inbound traffic, but generally doesn't block 'outgoing' traffic, eg. from a browser.  So the windows firewall should not ever stop you from connecting to the internet using your browser.  Other firewalls (as I mentioned above, McAfee has one, Norton has one, and there are others, such as ZoneAlarm), will vary on their implementation, but understand that it is very possible for one of these firewalls to stop outgoing connections, eg, from your browser, and prevent applications from reaching the internet.  If you have one of these installed, and you STILL cannot get connected to the internet, I would encourage you to either: disable it completely, OR, uninstall the application (be careful of any subscriptions you've paid for), OR, consult with the manufacturer on how to block/unblock programs from reaching the internet.  Each program is different and managing your firewall is beyond the scope of this discussion.

At this point, you should be back online.  If not, there may be something more major going on.  If you have a firewall-based gateway, it may be filtering web traffic.  Try another website, as your homepage might be down... There's a few items on this list I won't touch on, but they're very rare situations.  For the vast majority, this should be a (probably far too) complete guide on how to get everything working again.

Enjoy.

VoIP.ms

It's been a while.  Since the last time I posted, I've been experimenting with a Cisco CME deployment.

It's been.... interesting.  While CME is doing things very predictably, and as expected by the documentation, what I had to kind of figure out on my own is how to interact with a VoIP provider.

I chose VoIP.ms.  They're great actually.  Very well put together service, no significant bells or whistles, and the service is geared towards the skilled technician.  This means, not a lot is done FOR YOU; and the appropriate level of technical detail is included with the system - this means, SIP gateways on their end are well documented and redundant, they have the codecs and connection types and information all fairly well laid out, so if you know what you're doing, you can fairly easily acquire the information you need to get up and running.

No running around like a crazy person trying to hijack the communication to the upstream provider to try to determine codec information to try to emulate it with a PBX so you can finally use the system the way you want - which is how I would imagine buying a line from some of the 'all in one' VoIP solutions would be (MagicJack comes to mind).

All of that aside, some of the behavior isn't documented, and it can be EXTREMELY useful to know.  I'm tired of hearing "That number, has not yet been assigned" - which I get CONSTANTLY from voip.ms servers.

I'm still working out my dialing rules, but from experimentation, the outgoing SIP connection needs to have a PRIMARY number (in CME) of the 6-digit login ID for the line; otherwise the connection to the outbound voice SP will fail (resulting in the message "that number, has not yet been assigned" - possibly one of the most infuriatingly unspecific error I've heard).  However, when an inbound call comes, the DID phone number for the inbound call is used (10 digit number), if there's no such number (no match) in the destination PBX, then, the caller gets "that number has not yet been assigned".  joy. this again.

The "best" solution to put all my eggs in one basket, so far, has been to create an extension with the SIP login ID for the primary, and the 10-digit DID number as secondary.  That way, inbound, and outbound calls, all come from/go to the same extension.  Obviously, this doesn't work if you need multiple outbound, but for a simple deployment, it would work.

Now I get to dive into the wonderful world of trunks, and dial-plans to try to sort through this mess to make it work the way I ACTUALLY want.  I just wanted to document the difference between the incoming, destination number, and the outgoing numbers for VoIP.ms  something I hadn't come across.

Enjoy your tubes.

Cisco 881 and the wonderful world of DSL

We have a local DSL provider in my area that's just horrible.

ok, you got me, it's Bell Canada.

Anyways,  I've been busy with a project I picked up to rewire an establishment; I'm doing it primarily for experience.  While I know the theory behind proper home-run wiring, I have not had significant opportunity to actually DO IT.  I wasn't going to pass up on this.

I had no idea what I was getting into.  Word of advice: if you can pay someone to do the wiring for you, do it.

Anyways, as part of the package, I started looking around at other things that were not up to standards.  The establishment doesn't need anything crazy, but I'm all about reliability, so getting older-generation Cisco equipment seems about right.  I had a Cisco 881 in my lab setup that just didn't seem to do any of the things I wanted to do in my lab; so instead of hang onto this low-end router, I decided I would donate it to the cause.

The establishment in question is important to family, and therefore I am expected to give them certain.... special treatment.  This 881 was going to be my ticket.

The config looked good, I set it up at home, but I have no DSL so I cannot test.  I setup the WAN port (Fa4) for no ip address and setup the Dialer for PPPoE and put in the credentials.  I then got onsite.

What I was presented with was a 2Wire modem/router  .... I HATE these things.  I start looking around for a guide on how to convert it to using bridge mode. So I reflash the firmware with one that will allow bridge mode, follow the directions step by step.  I set the VCI and VDI, to 0/35 as instructed ( and as I recall from working with Bell in the past ) and perform the final steps of the configuration.  The last step is to reboot to place the unit in bridge mode.  So I do. and off we go.

Immediately after, I expect that the Cisco would pick up the WAN connection, dial the PPPoE and establish internet connectivity and everything would be amazing.... not so much.

I start troubleshooting, googling, maybe a different firmware, maybe I'm missing something in the config?  I could only find configs for 1800 series and similar (I eventually found one for an 881... that was later) - all of them required the vpdn to include the following line:

vpdn accept-dialin protocol pppoe

I got stuck on getting the router to accept this command; I'm here to tell you that THIS COMMAND IS NOT NEEDED.

I eventually got fed up (after nearly 2 hrs of troubleshooting) and ran:

# debug pppoe

with all the pppoe debugging on, to my amazement, the Dialer was actually trying to initiate the connection.  That means the configuration is complete enough for the Cisco to try.  okay, so if we're trying and not getting a response, then what?

So I grabbed a random ethernet cable for a nearby (powered on) machine, and connected it directly to the modem; sure enough, I got an IP, I checked the management and sure enough the VCI and VDI were 0/100 (the default).  Immediately I changed it back to 0/35 and hit save. seconds later, my console sprung to life with debug messages; I frantically typed to try to turn them all off.

Moments later, I rebooted everything to ensure the configuration would persist through power loss; it did.

2 + hours of troubleshooting because I had to use a custom firmware because Bell won't give us modems with bridge mode as an option....

Samsung's Galaxy Tab 10.1

I swear I'll get back to blogging about low level network communication someday... today is not that day.

I just had to wrestle with my tablet, a Samsung Galaxy Tab 10.1 to connect to a 5Ghz wifi AP. I found the problem, even after googling, people seem to just give up... hopefully people having trouble, will find this. (for those looking for help, scroll down to the marker and start reading, a little backstory follows)

I have a pretty complicated network, as you might imagine; being that my wifi is mainly shared, I actually setup an Access Point that will automatically choose the "least congested" channel, so that my android devices can connect to it.  Mainly my phone, since it will only connect to 2.4Ghz wireless. I do however, have 5Ghz routers, and one is on the network, and it's the only 5Ghz in my neighborhood (that I've ever detected).  This is good because there's typically so many 2.4 Ghz networks that congestion will stop you from having a nice, clear, quality signal; as I've stated in previous posts, this will slow down your network communication to a crawl.

Well, that's exactly what happened for me today, I have one AP at 2.4Ghz auto-select "least congested" JUST FOR ME, and a household, shared AP, also 2.4Ghz, that I tend to avoid; primarily so that the bandwidth there can be used by others in the house, and I don't have to fight with their devices... in terms of contention. so there's that.  But today, while using my tablet, I found that I was on the household AP, and trying to watch youtube clips was insanely slow (5+ mins of buffering for a 2 minute video).  I said enough is enough, and went to check my network status; once I found I was on the household wifi I thought to myself "that must be why" and promptly switched to my "least congested" access point.  To my disappointment, this yielded zero improvement. Without going through the motions of reassigning the wifi channels to all my devices to see if I can find something a little less congested (a very difficult feat in this environment); I decided to jump-ship and onto the 5Ghz. I set my tablet to only connect to 5Ghz networks.... voila. wait what? no networks? how is this right?

I logged into my 5Ghz AP and started tinkering.

---- FIX FOLLOWS (for those skipping my little story time) ----

After a little effort, I changed the settings to be more compatible, and the network popped up almost immediately.  My current 5Ghz settings (that are working with my Tab): I selected a low-numbered channel, the second lowest, 36 I believe, changed the channel width to 20Mhz, and saved.

That's it. pretty much just pick a channel in the first dozen or so.

network popped up quickly, I connected and all my wifi woes went away.

Happy networking folks!