Dana Harding, P.Eng.

Computers, IT Work

Primarily self educated in the general field of "computers", I have built a strong skillset through this hobby that has proven to be highly useful and will continue to be so. Introduced originally to my dad's Commodore 64, I spent the next multitude of years working hands-on with operating systems and their problems, kludged together solutions to run my BBS in high school, fought with device drivers, and have recently (past 3-5 years) dove into what is available for open source software and operating systems. I am proficient managing and troubleshooting small to medium business LANs and WAN connections, and the various services typically found within. I also have a solid grasp on VoIP technology and applications.

I am available to consult on specific IT problems.

• Introduced to the Commodore 64, primarily used it to play games but also learned some BASIC programming.
• Thoroughly explored MS-DOS 4 once I had access to a PC and worked through the various versions of MS-DOS as they came out and eventually into Windows.
• Entered the BBS scene in the mid 1990s - including a brief credit in BATPOWER's MUF for one of my newbie questions
• Became involved and assisted with the network administration of my school's new computer lab - Windows 3.1 workstations running on a Novell network
• Sysop of The Finitely Infinite BBS, a Fidonet Node ~1996-1999 - becoming a master of kludging things together to make the system work and doing things in .bat files that any sane man would use a programming language and compiler for.
• Completed the requirements of my high school computers course (using Microsoft Word and Excel) in short order, and proceeded with the instructor's blessing to go well above and beyond the course outline into MS Access databases and some programming.
• Assisted colleagues in the University computer labs when they were having issues with the computer lab machines

• Scripted and automated model building for analysis purposes
• Replaced a 'print then scan' procedure to create digital reports with a purely digital method - saving time, and increasing reporting quality significantly
• Increased an internal analysis application's speed by orders of magnitude by rewriting portions of the code (Visual Basic)
• Took the initiative to learn enough about unix to install and troubleshoot a FreeBSD replacement for a Windows file server *1
• Initially put my own time and money up front to purchase equipment for a test installation of Asterisk for my proposal to be installed as the firm's PBX.*2
• Monitored the company LAN - troubleshooting user issues and debottlenecking the network where possible. Identified several instances of installed malware and users running bittorrent clients (which was congesting the pipe enough to interfere with VPN traffic) by monitoring the internet gateway traffic.
• Implemented VPN access to enable contractors to work remotely
• Used a hex editor to determine the binary storage format for a proprietary program, and wrote my own application to extract our collected data and present it in a more usable format

• networking and network solutions including cluster applications for storage, processing power, and information distribution
• home and industrial automation
• computer and network security
• VoIP applications
• robotics including embedded computing, and autonomous UAVs

Interesting and Relevant links

FreeBSD	OpenBSD	NetBSD	Debian
w3schools - HTML & CSS	Domain Tools	BlackHat	Offensive Security
Openstreetmap.org	FLOSS manuals	commandlinefu.com	Techarp.com
The Starman's Realm (assembly programming, boot sectors, MBR, etc.)

voip-info.org
asterisk.org
freeswitch.org
snom.com	Easy to provision, easy to configure - good speakerphone (my experience is with the 320 and 360 models) Can modify settings and behaviour with HTTP requests (wget). The documentation mentions the ability to do some RTP encryption - which (if it works well) would be useful when a lone phone will be connecting over the public internet. A solution such as OpenVPN is better suited to connecting PBXes (as opposed to single endpoints) across the internet.
sangoma.com	After trying to fix echo problems with calls through the FXO ports of some sipura SPA-3000 units (before Linksys bought Sipura), we tried a Sangoma A200 with the hardware echo canceller. Echo problems were gone immediately. I wouldn't recommend doing any business installation with a PSTN connection without hardware echo cancellation. That said - I have a machine at home without hardware echo cancellation - but running oslec, which has shown a comparable improvement in call quality. YMMV.
polycom.com	My experience is with the IP-501. A well refined product, excellent speakerphone, quality buttons. It takes a long time for the web-based configuration to come up after a reboot making it a pain to configure one-offs (mass provisioning is better). At the time of testing, it was very difficult to obtain firmware from Polycom - they required end users to obtain firmware from the merchant who sold them the phone. Polycom has since changed policy and decided to allow downloads of firmware directly from them. I personally didn't find the user interface as intuitive as the Snom's.

Having had the experiences (more than one) of a hardware failure in the single Windows Server domain controller - and the resulting all-nighter to get everything working again, we separated the primary file share and the domain controller into separate machines so that a failure of one would not affect the services offered by the other. Without another license for Windows Server, we did what I imagine the vast majority of small companies do - make a regular workstation hardware and OS into a network accessible file server.

After receiving the first "Maximum number of connections exceeded" error from windows, and doing some research into the error, and "BSD vs. Linux vs Windows" - I decided to launch a pilot trial. The general consensus was that the BSDs, although not always as up to date or current as various Linux distributions, were regarded as solid and reliable.   Not needing any newer hardware drivers, and being an OSS newbie, the integrated approach of FreeBSD was perfect. I had never installed and administered a unix machine before - so got acquainted in my spare time over a week or so, and promptly solved the issue.

It was also trivial to establish a redundant sister machine: install OS, copy configs from primary, setup a cronjob to rsync the files, done. Try THAT with a Windows machine.    Failover to the secondary was a simple manual process, and was done several times for hardware upgrades.    The users didn't notice the difference which, to me, means a job well done.

Semi-related -   There was a high rate of hardware failures - mostly hard disks and power supplies - and the lead culprits were: dirty power, and vacuum cleaners. On my recommendation, low-end UPS units were installed on all workstations and existing units for the servers were upgraded. They would provide at least enough uptime to turn the circuit breaker back on WHEN the cleaners (repeatedly) ignored instructions and labeled outlets and plugged their vacuum cleaner into the wrong outlet. They would also act as a rough filter on the power feed to the machines.

The hardware failure rate dropped and not very much broke after that (a handful of power supplies - the ones that were bundled with the ANTEC Sonata II case - all failed after almost exactly one year of being put into service).   My dream of saving the day, getting the fileserver back up in no time with the new redundant setup - contrasting to the previous extended outages - was never realized.

When the business needs grew beyond two analog phone lines, I decided to see what OSS could offer for a solution and found Asterisk.

Some of the unique features of this specific installation included:

• Onsite wiring connected the DEMARCs from three service addresses to the PBX. We needed a rotary service (also called trunk group, hunt group, multi-line hunting, or <other> depending on who you talk to).
  No problem you say (well - I said), and it isn't - technically. BUT the Telco's billing system isn't configured to do this across different service addresses. Or, if it is, the telco agents were not aware of it. After hours on the phone and several confused agents I figured out my own solution and presented it in words that they understood. Fortunately the billing system DOES allow for several features that make lines behave the same way as a hunt group:
  • Add a call-forward when busy feature to all the lines
  • Remove any telco voicemail and call waiting features
  • Setup the call-forward when busy number for each line to forward in a loop: Line1 -> Line2 -> Line3 -> Line1
  • Set the outgoing callerID to display the phone number for Line 1.


• All workstations already had a single Cat5e feed, it was possible to use the dual LAN ports on the IP Phones, but it was also desired to keep the VoIP network physically separate from the computer LAN. Since the switches were only 100Mbit (using only 2 of 4 twisted pairs in the cabling), it was possible to use Network Splitters to run two independent 100Mbit ethernet lines inside the same cable. This approach was a good solution to the specific scenario, some considerations:
  • In this case was ultimately less expensive than running new cable
  • Caused some congestion near the switches - each single cable end became two short patch cables and a network splitter
  • Precludes future use of the wiring for Gigabit LAN (new cables were ran several years later for this purpose)
  • If PoE is desired in the future - equipment must be selected very carefully, Not all IEEE 802.3af implementations will necessarily support powering the data wires
  
  
• Using the vpn version of DD-WRT installed on a WRT54GL - I configured the unit to automatically establish a VPN tunnel to the phone server when it had internet access. This as a base, it could be sent with a properly configured IP phone to a non tech-savvy user in order to establish a remote extension route their phone extension to them and allow them to make calls local to the PBX. (no long distance charges).
  • Call quality is at the mercy of the internet path
  • The specific configuration I tried used the WRT54GL as a node on the remote LAN instead of replacing the existing router, I don't recall specifics except that previous experiments with DD-WRT found the QoS lacking (I suspect some tweaks outside of the GUI might work well - never looked into it). YMMV.
  • Assuming no implementation flaws in the VPN tunnels and secure networks on both ends - calls by this means can actually be more secure than over the PSTN, it cannot be snooped by ANYBODY without access to the endpoints. PSTN can be snooped at multiple points. (ranging from neighbourhood kids with alligator clips to things like Project Echelon)


• More a special feature of any IP PBX solution than specific to this installation: The ability to do ENUM lookups and to connect to multiple ITSPs and decide which to use based on the calling destination. (Which is actually not currently used in this installation)
• Outstanding potential for low cost or, with a direct IP connection, free long distance calls*You still need an internet connection and equipment/power/etc.
• Depending on the ITSP, the cost to run multiple channels (more simultaneous conversations) can be as low as per-minute for actual usage. Compare to the PSTN which will be a monthly per-port charge.
• In contrast to private VPN links, most connections to ITSPs are not encrypted and are easily snoopable by anybody in the communication path. (or not in the path, but with the ability to mount BGP or DNS based attacks to reroute traffic to them).    Also, not all ITSPs will identify where their connections to the PSTN actually are located - meaning that your conversations might actually end up going through different legal jurisdictions.
• In short - don't say anything in a conversation via an ITSP that you wouldn't send out in an email