chuma.org

Category: networking

  • Aaaand the DSL is good!

    Turns out it wasn’t a problem with my BSW (the wire from the brown pedestal to my house). It was with my F2 pair (the wire from the pedestal out to the big brown box on the side of the road).

  • The saga is over

    My new friend the Bell lineman came by yesterday and found the problem. After over a month of insisting that I had a problem with the Bell wires, guess what – the problem was with the Bell wires! He swapped my line over to a spare set – hearing that nice, clear, non-fuzzy tone on the line was music to my ears. Also had a good chat with him about future issues if they come up, and importantly what to say to get service. Hooray!

  • Still with the ongoing DSL saga…

    We’re still – still! – having DSL issues. But I hope that finally we’re going to get some relief. Let’s start at the beginning:

    Back in February we had a new “dry” DSL line (let’s call it line #2) setup alongside our existing dial tone/DSL line (line #1). Then we cancelled all service on line #1, and began relying on Vonage for VoIP service via line 2’s DSL. Sounds real easy, doesn’t it? Especially when you factor in that our subdivision is only 5 years old and is teeming with spare Bell wires all over the place.

    Well, once I got a bulletproof router setup, everything seemed fine. Then, out of the blue, we started having very weird intermittent line issues. One day the DSL would be bulletproof, excellent utilization and signal/noise numbers. The next I’d be unable to keep line sync for more than a few minutes and the line numbers would be terrible. Most times this happened, I’d call my ISP and report it, they’d check the line stats and notice the horribleness, and we’d troubleshoot. But between the NID (grey box where Bell’s wires and my wires meet) and my basement, there’s nothing to troubleshoot: the wires terminate with a single jack, with a 3′ RJ11 cord going to my DSL modem. A few times I even took my modem outside and plugged it directly into the line at the NID. No change.

    I went through every possible troubleshooting step possible, and everything pointed to some problem with the wires in the ground. The DSL on line #1 was always bulletproof, and I was using the same modem and the simplest inside wiring possible. It had to be the line #2. From talking to a friend’s friend who works as a Bell lineman, I learned a lot about how this stuff works, what everything is called and how to bitch loud enough to get it fixed – indispensible information to say the least.

    So finally, finally, after documenting it enough times my ISP (TekSavvy, who I cannot say enough good things about) finally got Bell to notice the issue. They opened a ticket with Bell and put all of these details and more into it. I just found out that they spent a good 30 minutes talking with Bell about my problems, and finally got Bell to realize that YES, it’s the ground wiring – and they’re finally going to send a tech to fix it!

    Apparently the deciding factor was when my ISP mentioned that my DSL utilization numbers (a measure of how much bandwidth the DSL layer is using on the wire) went from a very good 40-60% to a horrific 100% every time. As soon as Bell heard that they said “oh, yeah, there must be a short somewhere along the line.” Um, no shit!

    So I’m hoping to get a call from Bell soon to find out when they’ll come, and I’ll for sure stay home in order to catch and talk to the tech to make sure they do the work right.

  • Guess what? The router is crap.

    So apparently, the Linksys BEFSR81 router that I scored isn’t all it’s cracked up to be. Two major drawbacks are going to force me to get rid of it, possibly with extreme prejudice:

    1. The QoS features of this router are useless. You can do port-based QoS, but that only deals with transfers WITHIN THE LAN. Useless. You can also do ‘application-based’ QoS, but that just marks the outgoing packets with a ToS priority flag, so if your ISP doesn’t respect the flags, it’s useless. Also you have to enter one port at a time, and with Vonage the voice packets could use any UDP port from 10000-20000. ARGH. So no traffic prioritization has actually been happening for the past week, which explains a lot: we’ve been getting occasional echoing and stuttering on Vonage calls. This article at PracticallyNetworked has the skinny on the QoS.

    2. This router seems to have a problem with either UDP streaming or something else, because every so often it just goes batshit crazy and drops ALL LAN TRAFFIC for periods of time – anywhere from 5-15 seconds to minutes. The WAN side stays up, but the LAN just drops 100% of packets. It sometimes comes back, and after resetting the router it’s OK for a while, but this is purely unacceptable. Once when it did this it took 2-3 minutes for Vonage to reconnect and during that time Sandy was trying to get the voicemail. FFS! She was pissed and now I’m pissed. I did a bit of research and found lots of other people having the same issues.
      Particularly this guy’s page was informative.

    So it looks like I’ll have to either get a new router or use my Linux box. I didn’t want to spend any more money but a Linksys WRT54G or WRT54GS should do the trick with a minimum of fuss. I really don’t want to have to rely on my Linux box for routing because it’ll suck a ton of juice out of the UPS if the power goes out. With just the DSL modem, router, and VoIP box on the UPS it’ll last for hours and hours.

    Update my friend Jon writes below that he’s been using the same router, with the same issues. Bleah. I’m going out and getting a WRT54G tonight 🙁

  • Home networking is done.

    Well it seems like Bell finally transfered my number over to Vonage today. I noticed because the Vonage phone was ringing more than it ever has, and there’s suddenly no voltage on the Bell line 😛

    If you’re an incredible geek or just interested, this is what my home network/phone wiring looks like now.

  • Home network re-wire project

    I drew four network diagrams before finally figuring out how I was going to hook things up at home. I really wanted something to provide QoS to the VoIP phone adapter, and ended up borrowing a Linksys wired router (BEFSR81) that does port-based QoS. Doing QoS in Linux is really, really scary, and I wasn’t prepared to spend the time to wrap my head completely around it. On this router I just say “port 1 has high priority over everything else” and that should work just fine.

    So last night I spent an hour installing the new router, reconfiguring my old Microsoft wireless router to be a bridge (but also a wireless access point at the same time), running an Ethernet cable in the ceiling to connect one router to the other, moving the UPS over to the wiring cabinet, and then re-wiring everything and tidying up. But now the networking part of this project is… done!

    The final part will be wiring the security system up to the VoIP connection, testing it, and then when our Bell phone line is gone, hooking up the house phone jacks to VoIP.

  • Collecting more information about my security system

    I’ve amassed a whole lot of information about my security system over the last few days. I’m starting to feel better and better about switching to VoIP and ensuring that my system will be able to communicate.

    First off. my “ADT Focus 32” system is really a close of the DSC Power832, which is very commonly deployed. After scouring some websites for a while I managed to snag the Programming Worksheets and the Installation Manual for this unit, which I’m going to need if I want to program the thing myself.

    Secondly, I finally found good information about what protocols exist for security system communication and what will work for VoIP.

    This report from the Canadian Alarm and Security Association (Google cache) shows that they did a little test of what protocols will work with VoIP. Here’s the Coles Notes edition:

    • The Contact ID protocol sucks, it won’t work with VoIP. DTMF Express didn’t work either. There’s too much echo coming back to the security system for it to receive signals from the monitoring station. In the case of Contact ID, your system won’t be able to receive the “OK” from the monitoring station, so it will keep on retransmitting until a counter is reached, and then your panel will display an error.
    • Pulse formats like 10, 20, or 40 pps should work fine. 4×2 and 1400Hz handshake seems to be the “standard”. However pulse is the slowest of all formats.
    • SIA format will work as well. Apparently this is because the VoIP hardware thinks that it sounds like a fax transmission, and switches the protocol for the VoIP signal to a type specifically for modem/fax type transmission. SIA is basicially bursts of modem transmission, so it works.

    This posts on dslreports is where I got some good info as well.

    So now from here, I’m going to call ADT and see if I can get them to program my panel remotely to use the SIA protocol. Then we should be hunky-dory when the VoIP switch happens.

  • Getting rid of Bell: still a head-spinning exercise

    The debate at home about going VoIP with Vonage for our main phone line heated back up at home yesterday. It’s something we’ve been thinking about for months, and according to our calculations we’d save $40 a month – but it has two main impediments:

    1. We use DSL for our internet connection and are not willing to switch to cable. “Dry” DSL is now an option (DSL service without local phone service on the same line) but it’s so new no one seems to know about it.
    2. Our security system requires that we have phone line monitoring. Nevermind the fact that we get reamed out the ass paying for it. And we’re locked into our contract until the summer of 2007.

    (1) is no longer an issue, now that “dry” DSL is available – DSL without Bell phone service. #2 is still an issue, though it might be possible to get it to work over VoIP.

    I called up my ISP to ask them abou dry DSL and they didn’t have a lot of answers for me unfortunately. They said to switch my line I’d have to fight Bell tooth and nail, and also that Bell still requires that you pay for using their wires even when they’re not providing service on it.

    I poked around online and found another provider – TekSavvy out of Chatham, Ontario. They mention dry DSL right on their website so I figured I’d call them up to talk about it. Well, I spent about 15 minutes on the phone with a fellow named Bill who answered all my questions and generally impressed the hell out of me with his candor and straightforward facts. Here’s what I learned:

    1. Yes, Bell still charges your DSL provider for using their copper when Bell isn’t charging you for phone service. In most places, that’s $16.99 a month. HOWEVER, that fee is currently unregulated (Bell set it themselves) and the CRTC is expected to set this fee in the next few months. It’s likely that the CRTC will force Bell to lower it. Right now, for my dry DSL, it would be $16.99/month on top of the DSL service.
    2. It is really hard to get Bell to convert a currently active phone line with DSL to “dry” DSL. They will fight and bitch and complain. Also you might be without any service for two or three weeks. BUT, if you have another free line running to your house (and you probably do – they always run lots of extra copper for future service), it’s much easier to get them to bring up dry DSL on that unallocated line. The wait time is still 2-3 weeks but since they’re not losing any money out of the workorder, there’s less crap to cut through. Once you get DSL up on the other pair, you can cancel your phone service and the other DSL service. You might have some overlap for a while though, but it sounds like less of a mess.
    3. If I wanted Vonage to keep my existing phone number, I’d have to ask Vonage to take it over when I activate their service. Yet another reason to do point #2 (get a second DSL service temporarially) first, because if I cancelled my phone number without Vonage taking it over, I’d never get it back.

    4. I even picked the guy’s brain about running my security system over VoIP. I’ve read about some people doing it but he said there are two main problems:

      the reason the security companies are so dead-set against internet monitoring is because of insurance and possible outages. If your internet went down say four or five times a year, that’s considered a lot of times. They are very slow to change their tune because they’re afraid of not being able to provide reliable enough service, and of losing their insurance coverage. And insurance policies take forever to catch up to technological advances.

      the reason that you will have problems trying to trick your security system into running over VoIP is because VoIP is asynchronous – only one side transmits at a time. Normal phone service it, by definition, synchronous – both ends of the line can talk and hear each other simultaneously. Security systems talk like this and need a synchronous connection. Your VoIP provider would have to be able to switch very fast between the two ends of the link while your security system is talking in order for the connection to work. I think this is what I have read about where people phone up Vonage and get them to change some setting on their line which improves the security system communication

    What I would kill for is for my security provider to just install and support a dialer capture module like this one. It tricks your existing system into thinking it’s talking to a phone line, while retransmitting the data over the internet using TCP/IP. Boy, would I.

    So that’s a lot to think about, but it’s also more information than I’ve ever gotten on the subject. Many thanks to TekSavvy, I might just be calling them up for my new DSL service if I can solve issue #2.

  • Last night was quite the adventure in networking. I played Mario Kart: Double Dash in LAN mode, with my friend Jon who lives about 200km away in London, Ontario. No, we don’t have a cable that long – we used some very cool software called Warp Pipe.

    Warp Pipe was easy enough to setup, however the performance was lacking. On my end most of the games stuttered quite a bit. I guess this is the price to pay for putting your packets on the bit bad ‘net instead of keeping them safe on the LAN. Still I thought that the performance would be better.

    Well I was browsing the forums over at the Warp Pipe and it seems like the problem might have been Norton Antivirus on my computer… I guess I’ll just have to try again.