New Products Wanted, part 3: Consumer-grade DTV channel demodulator and remodulator

It’s another in my (very) irregular series of “why hasn’t anyone made this yet?” posts…

The idea on this one is simple. Since all the television stations in the United States are now broadcasting in digital format, and since you can buy DTV converter boxes for as little as about $50, I’m assuming that decoding a DTV channel’s data stream isn’t a real big deal.  So why not take that one step further and allow that signal to be remodulated onto a different channel?  The difference between a converter box and what I have in mind is simply this:  A converter box takes a digital signal and converts it to another channel, but the output is analog.  I’m saying do the same thing, except make the output a digital signal, on a different channel than the original.

And WHY would you want to do this?  Well, for any of several reasons:

  • Your antenna is at a distance from your house (or from another building that you’re feeding a signal to), and a station you want to get is way up on UHF, and coaxial cable is typically quite lossy at UHF frequencies.  So, at the bottom of your tower, you convert that channel to VHF (say channel 2, which is now unused in most areas) and now you can send it even a few hundred feet down RG-6 (or RG-11) and still have a usable signal.
  • You have two adjacent channels that you want to receive that are almost equally strong, but in different directions (say for example, channel 8 from the south and channel 9 from the north).  You want to put up a separate antenna to pick up the one station that’s in a different direction from the others, but you can’t just combine the signals using a reverse splitter because on some channels the two antennas might cancel each other out.  Nor can you use a JoinTenna because they are not recommended for use on adjacent channels. So you run the one antenna in a digital demodulator-remodulator and change only the one channel you want to a low VHF channel that’s unused in your area.
  • Cable channel substitution – say your cable company gives you a channel your wouldn’t be caught dead watching (the gimme-your-money religious and shopping channels come to mind) but they don’t give you a channel you want to watch that you can receive with a rooftop antenna. A deluxe model of this unit could actually do drop-in channel substitution – say you receive the over the air channel on 9 but you want to replace a station on 24, you could do that.

Give me enough time and I could probably think up a few more uses – point is, this is a DTV problem solver.

In my opinion, an excellent unit of this type Would have two coax inputs and two coax outputs:

  • An input that carries the channel you want to convert (often from a “secondary” antenna)
  • An input that carries the signal that you want to insert the converted channel into (the cable line or “primary” antenna feed)
  • An output that carries the combination of both the second input and the converted channel from the first input
  • A “passthru” output for the first input, that passes it through unchanged

The reason for the last output would be so you can “stack” boxes, in case you have multiple signals coming off that “secondary” antenna.  You’d bring that antenna into the first box, have that one convert the weakest signal, and then pass the line to box 2, and have it convert another channel.  Your primary feed (cable or main antenna) would pass through both boxes, and each box would insert a channel.

Options: Each box should have a way to do basic setup. Options that would need to be set are as follows:

  • Channel you want to convert (specified by channel number or frequency)
  • New output channel (also specified by channel number or frequency)
  • Option – primary and channel to be converted are on same input

The last option would be used in the case where you have only one line coming in but you still want to convert a channel, say from UHF to VHF.  In this case, the converted channel would still appear at its original postion, but would also be downconverted to the lower channel and inserted back into the feed.

An inexpensive unit might only allow a limited choice of output channels, say VHF only (or even low VHF only, but please not just 3 and 4!).  A deluxe unit might allow the type of channel replacement I mentioned above (actually removing a digital channel from the primary feed and replacing it with another channel).  A VERY deluxe unit might have a network connection that would present a web interface browsable on the TV or the local network, allowing selection of video files off the local network or perhaps from online sources, and could modulate those files onto a particular local digital channel, in addition to (or instead of) remodulating an off-the-air signal.  In addition, the deluxe unit might have the ability to convert more than one channel from the second antenna or source.

But the main point is, in no way should this be an analog conversion, and absolutely no RF should be allowed to cross paths – each input and output should be totally isolated from the other inputs and outputs, except of course for the “passthru” output, which should carry ONLY the unchanged signal from the secondary antenna. When a channel is changed in frequency, it should be done by extracting the data stream from the original signal, then regenerating that digital stream and remodulating it on the conversion channel.

Finally, I’ll even throw one other idea out there, if someone wants a real challenge – have a “replacement signal” mode.  How would that work?  Well, extending the previous example, let’s say your digital channel 8-1 and your digital channel 9-1 are both CBS affiliates.  And let’s say that neither is 100% reliable.  So what you might do is, in some way indicate to the box that both digital channel 9 from the secondary antenna and digital channel 8 from the primary antenna are to be converted to digital channel 3, but you want the channel 8 signal to take precedence.  The receiver would constantly demodulate both signals, but if for any reason the channel 8 data stream is interrupted, it would smoothly switch over to the channel 9 stream until the channel 8 signal comes back to an acceptable level.  This feature, of course, would probably only work well during times when both stations are showing the same network programing, and even then might be a little disconcerting, but not nearly as annoying as having a program disappear completely for thirty seconds or a minute. And, it would seldom or never work right for the secondary channels (e.g. 8-2 and 9-2 in this case).

(I might also add that it could look at the SAME channel on the two different inputs, in case you’re trying to use “diversity reception” techniques – in essence it would then pick whichever data steam was the most usable at any given moment, and try to “fill in the blanks” from the other, converting the best data stream to the remodulated channel frequency).

Now, I know that you can buy equipment designed for use at a cable company head end that can do this sort of thing, but what home viewer has two grand to drop on something like this?  That’s why I say, make a consumer grade unit and keep the price reasonable – the lowest end units should not cost more than about $75, certainly not more than $100 (and if you charge that much, please include a fantastic tuner!).

Whoever is the first to make something like this will be hailed by consumers and TV antenna installers alike!

Of course there’s also that OTHER device that a lot of people want, but that we may never see — a device that will take the HDMI video output and digital audio output from some source, and modulate it onto a channel for local distribution. No, even that would NOT replace what I’ve described above, though, because it would likely only be able to modulate one video source per channel, whereas the over the air data streams may actually contain three or four program streams (which makes my “replacement signal” idea a lot more difficult to do properly).  But my thought is that if you’re going through the trouble and expense of remodulating a channel, you at least want ALL the programming on that channel (the entire data stream, in other words).

Originally posted on Friday, July 3, 2009 at 4:00 AM EDT.

Leave a Comment

Lost channels in the DTV transition? Look up — there’s free TV out there!

For those in the television backwaters — the places that have lost one or more network TV signals due to the switch to digital television — there are alternatives, in a little known form of satellite television.

It’s kind of like one of those “good news, bad news” jokes.

The good news is that there are dozens, even hundreds of television signals available absolutely free, and the reception is almost always crystal clear. As long as you have a clear view of the southern sky, and aren’t prohibited from setting up a satellite dish (if someone — landlord, homeowner’s association, zoning authority, anyone — tries to tell you that you are prohibited from having a dish, that prohibition may be illegal under federal law), all that television is yours for the viewing.

The bad news: There are many “catches”.

First of all, don’t expect to get the equivalent of cable or commercial satellite TV.  While there are a handful of cable channels that will occasionally become available for short periods of time, most of the stations are the sort you’d find on low-power local television stations, or on the secondary channels of local HDTV stations (those channel-02 and channel-03 channels, for example). Many are in Spanish, or some other foreign language.  If you are really lucky, you might pick up a major network feed, but if you do, you probably don’t want to tell anybody, because if too many people find out, that channel will almost certainly disappear.

And that’s the biggest rub with this service — unless you’re really good at scrounging used equipment and figuring out what needs to be done to make it usable with the free signals, you’ll spend at a minimum two to three hundred dollars to get a working system going, and even more if you want to receive signals from multiple satellites or if you want to receive true HDTV signals (note that almost all satellite television is digital these days, but not all of it is in high definition). And once you have spent all that money, the stations you enjoy today could be gone tomorrow.

There is an apocryphal story that went around in the satellite forums — a cable television company in Alaska fed several of the Anchorage TV stations to one of the satellites in the clear, presumably for the purpose of feeding this signals to remote cable systems in cities and villages around Alaska. Those “in the know” enjoyed these stations, particularly viewers in the Eastern half of the U.S., because they provided the west coast feeds of all the major networks. That much I know to be fact, everything else is just rumor that was floating around the satellite forums a while back.

One day, as the story goes, some bigmouth in a bar was bragging about how he could watch the Saturday baseball feeds from both coasts.  What he did not know was that the president of the cable company was there, and was unaware (to that point) that his technicians were uplinking the signals in a totally unencrypted format that anyone with the right kind of receiver and satellite dish could view, no subscription required.  He overheard the bigmouth, and ordered his technicians to scramble the signal, but that wasn’t the end of it.

As the story goes, FOX got wind of the incident and realized that by feeding games to the East and West coasts separately, some folks could watch TWO MLB games on Saturday, just by changing feeds.  I’m not sure if this violated some contractual agreement with Major League Baseball or what, but all anyone knows for sure is that in subsequent seasons, they started doing all Saturday baseball feeds starting at 4:00 PM Eastern nationwide – no more 1:00 PM games for the Eastern and Central time zones.

So the lesson is, you could spend considerable $$$ on receiving equipment, but that doesn’t guarantee there will be anything you want to watch. Here today, maybe gone tomorrow, and loose lips sink channels.

What about the legality?  Well, I am not a lawyer, and I’m definitely not going to give you legal advice.  But to the best of my knowledge, no one in the United States has ever been prosecuted for watching unscrambled signals.  The thinking in the U.S. seems to be that anyone with a signal they want to protect has some duty to mitigate losses, by employing some form of encryption. I’m sure that certain content owners would disagree about the legality of watching just any unscrambled signal you happen to find, but I don’t think any court would be too sympathetic — and besides, are you really going to run around telling everyone just what you’re watching?  Assuming you’re not drunk and shooting your mouth off in a bar somewhere, that is.

However, in the past there have been unscrupulous people who have sold “hacked” receivers that pick up signals they are not supposed to be able to receive without paying.  If you buy one of those, you are an idiot.  Why?  Because those receivers will not continue to pick up those signals indefinitely, because companies change their encryption methods from time to time. So, after a while you’ll have to go back to the guy you bought it from and see if he can unlock it again, assuming you can even find him.  But chances are, the FBI or some other government agency will find him first, and will obtain his customer list, and next thing you know they’ll be at your door and you’ll be charged with theft of service, a federal felony. There is a HUGE difference between watching the unencrypted signals that are freely available, and using “hacked” equipment to try and receive signals that are encrypted. Try the latter and you may be doing most of your TV viewing on a communal TV in an inmate recreation area.

Most people who watch the free, unencrypted satellite TV realize that the hackers are a menace to the hobby. The last thing they need to to be labeled “pirates” and lumped in with those who just want to steal signals. So on many of the online satellite forums, any request for information on hacking a receiver will likely get you banned for life. That’s no small thing, considering that there are very few good sources of online information on the subject.

One of the best sources of information is the Free To Air (FTA) Discussion forum at SatelliteGuys.US.  And make no mistake, if you really want to explore this, there’s a learning curve.  For one thing, satellite dishes have to be aimed fairly precisely – getting just “sort of close” DOES NOT count.  For another thing, satellite signals don’t pass through solid objects of any kind, particularly trees with leaves or needles on them.  Even a small branch with four or five leaves can cast a shadow across a dish that will reduce the received signal to a point where it’s unusable.  And, for the most part, you can’t just take an old Dish Network or DirecTV dish and reuse it (although if you have an old PrimeStar dish, that will work, and the larger sizes of those dishes are much valued by those who view these free signals). You will need to learn about setting up a dish (best to use a pole in the ground set in concrete — with a satellite dish, additionl height does not get you more signal, but makes it a lot harder to clear accumulated snow off the dish in the winter, something else that can interfere with the signal), grounding the dish, aiming it at the desired satellite, and getting the signal to the receiver.

Still, for those who are into technical things, there’s nothing quite like the thrill of getting your first free TV signal from the sky! And unlike the shortwave radio signals that excited our fathers and grandfathers, these signals rarely fade out, so once you’ve “peaked” the signal you can watch the stations on that satellite until you get sick of them or they go away, whichever comes first. And with many people losing free “over the air” television due to the DTV transition, now might be the time to explore the world of Free To Air television, if you are so inclined (and are not adverse to the risk of spending money on equipment that may not be usable after some period of time).

Just one thing, DON’T call your local TV antenna installer and ask him to come out an install one of these systems – unless he’s also into this, he’s probably not going to know what the heck you are talking about. This is definitely a Do-It-Yourself project for most folks. Commercial installers know about commercial systems, like Dish Network and DirecTV, and they would be happy to install one of those systems for you.  My only advice with regard to those services is, seriously, make them put the dish on a pole in your yard, unless you like leaks in your roof, unsightly cable runs, and no TV after a wet, heavy snow (unless you climb up on a wet, slippery roof to clean the snow off the dish). Installers hate pole mounts because they have to make two trips (one to mix and pour the cement, then a day or two later to finish the install) so you may have to put your foot down and say “no yard pole, go away and I’ll get someone else, because you’re not putting a dish on my roof!!” But just remember, even if your roof doesn’t leak immediately after an install, that just means it’s going to take a while for the leaks to form — but once they do, what do you think your chances will be of getting that installer to come back and fix the damage?

Anyway, I’m not trying to talk you into this.  Most people who read this article won’t pursue Free To Air satellite any further, and that’s fine – too many users might hasten the departure of the remaining free (unscrambled) feeds. But on the other hand, too few users and it’s not worth it to the equipment manufacturers to build and market the receivers. So if you are truly interested, check out the forum mentioned above, and the sponsors on that site (and also the Global Communications site, run by an enthusiast and equipment dealer in Wisconsin).

Leave a Comment

Comment on Michael Jackson’s death

As if you haven’t read enough already, right?

Normally I’m not a person impressed by celebrities. I remember one time, when I was much younger, helping a friend out with a show that was essentially an opening act for a private birthday party for someone who was very big in the motion picture business (people today might not recognize the name, but let’s just say he was a huge name in the 30’s and 40’s, and this was like his 80th birthday party, if I recall correctly).  It was held in the Palmer House in Chicago, another institution that had once been huge, but was already past its prime. There were some big name celebrities there (one big TV star in particular) and everyone was going ga-ga over the fact that all these big shots were around.  And I remember being totally unimpressed – I was so tired from the setup work we’d done that I wouldn’t even go out to see the show. Everyone looked at me kind of funny, but I just explained that those people didn’t impress me, and I meant it.

But I would have gone to see Michael Jackson.  I liked his music.  Unlike most folks, I think I liked him better when he was with the Jackson Five (I didn’t care for “Thriller” much, although the song “Billie Jean” definitely got stuck in my head for a while).

The reason I bring this up is that I remember when I first saw the Jacksons on TV, probably when I was in my late teens, and upon learning that Michael was only eight years old, I remember thinking “this kid has already done more with his life than I will probably ever do with mine.”  And I think it was the first, and maybe one of the only times that I was ever genuinely envious of any celebrity.  Of course, I had no way of knowing that he’d been raised in an allegedly abusive home (I can’t believe that his father is being allowed to take care of his kids, even temporarily!), nor how much he envied “normal” kids. And I certainly had no idea of the paths his life would take, nor how it would end. I suspect that when the dust clears, there’s going to be plenty of blame to go around for who caused his death (see this article from the U.K. Daily Mail for some additional insight), but probably not enough to pin on any specific individual.

I’ve always said that groups of individuals will do evil that no one of them would do if solely responsible (hence my dislike of large corporations, which are almost always evil to some degree). That was probably the case here. No one person killed Michael, but many people – primarily greedy people – took their toll. It may have been a case of “death by a thousand cuts”, some much deeper than others.

In any case, looking back, it’s obvious how foolish I was to in any way be envious of Michael Jackson. And nowadays, I always wonder why celebrities seems to have so much “clout” with the public. Why can they get elected to public office, even if barely qualified for the job? Why can they address legislative bodies on social matters, delivering their opinions as if they were some type of authority on any subject? Why do people look up to them at all?

If there’s any lesson to be learned from Michael Jackson’s life and death, I think it is this: Although we can appreciate the talent a particular person may have, we should not wish to be them, nor to emulate them. Sometimes it seems as though the bigger they are, the more troubles they have, and the more likely they are to fall into a destructive lifestyle and (sometimes) early death. Not only that, but if they have kids, those kids will always be in their shadow. No matter what Michael Jackson’s kids do, they will always be known as his children, for whatever that is worth. Would you really want that sort of life? I wouldn’t, and most people wouldn’t. Michael was sort of forced into it by the choices his parents made, and by the time he was old enough to make his own decisions, much of the direction of his life had already been set. Would you want that sort of life for one of your kids?

I’m not big on organized religion (to put it mildly), but one thing most major religions teach is that envy is a destructive force. And it really is, but the kicker is that most of the people we envy (celebrities in particular) we probably would not envy at all if we really knew what they were going through. Is envy driving your life, or your aspirations for your children’s lives? Just something to think about.

Thank you, Michael, for all the great music.

Comments (1)

Mac OS X: Lean on Lingon to launch scripts and applications

This is a post that was recovered from another, very short-lived blog.  Since the original seems to have vanished into thin air, I thought I’d repost it here, since it’s still relevant, and links to another article in this blog. Also, it seems that readers like this type of article — whenever I look at my blog stats, articles like this always tend to be among the top posts.

——————————

Lingon is one of those tools that at first blush may seem to be something only a true geek would love, but it’s actually fairly practical. What it does is to allow you to launch scripts or programs according to certain criteria. If you have previous experience with Linux or Unix, you can think of it as a way to set up something similar to a cron job, except that you have more flexibility.

One thing you can do is set up scripts or applications to launch at startup. Now, you may already know how you can launch applications at startup — you go into System Preferences, click on Accounts, and then (while your account is selected) click on Login Items. Once there, you can add or remove applications you want to launch at startup by using the + and/or – buttons. And, that’s the preferred way to launch an application at startup for the logged-in user.

But what if you want to launch an application based on some other criteria, or you want to launch a script of some kind? What if you need an application to start no matter which user is logging in? Or, what if you want to tweak an existing startup item that’s run by the system (as an agent or a daemon) and not by a particular user? That’s where Lingon comes in. Lingon lets you edit and create configuration files for launchd (and maybe you are asking, what is launchd? Well, according to Wikipedia, “launchd is a unified, open source service management framework for starting, stopping and managing daemons, programs and scripts.” Aren’t you sorry you asked?).

To give you an example of how Lingon can be used, we set it up to start the CallerIDpop perl script from the Michigan Telephone, VoIP and Broadband blog. This is a script used with Linksys/Sipura VoIP adapters (and some phones) that, when there is an incoming call, provides a Growl popup showing caller details and the time the call was received (it can also write this information to a log file). Previously we had been using their suggested method of running an AppleScript (saved as an application) at startup, the AppleScript containing the line that actually starts the Perl script. Although this works, it’s a fairly convoluted way to do it and it seems to eat up a lot of system resources. So, we set out to find another way to invoke the script at startup. Here’s how we did it using Lingon (which, by the way, seems to get the script running a lot quicker, and the script itself seems to be running in a more stable environment):

When you first fire up Lingon, you get this screen:

Lingon opening screen

Lingon opening screen

Click the small button labeled “New” (with the + on the button) in the upper left-hand corner, and you get a dropdown as shown here:

Lingon dropdown

Lingon dropdown

We selected “My Agents” because we only have one user account on that system, and didn’t really want the script to have root privileges. You should think long and hard about running anything as a daemon, because if anything goes wrong (whether due to programming error or malicious intent) the script will be running as root and can do just about anything to your system. Having selected that, we got this window:

Lingon main options window

Lingon main options window

As you can see, everything is fairly straightforward. In section 1 you give the agent a name, in section 2 you insert the command just as you would enter it if you ran it directly from a terminal window (or you choose the application to run, if you are running an application), and in section 3 you pick the options you want to use to trigger running the script or application. If you’re not sure about any of the options, click on Help (in the top menu bar) and then “Lingon Help” and it will bring up a PDF file in Preview that explains how to use Lingon. The Help menu also gives you access to the man pages for launchd.plist, launchctl, and launchd, in case you are making changes in any of those files.

Note the “Expert Mode” button in the lower right-hand corner – this shows you the actual XML code, and allows you to write keys and values directly if you are comfortable doing that.

Don’t forget to click the “Save” button at the top when you are finished – we forgot to do that and had to start all over! We sort of wish that the “Save” button were underneath the other three sections, maybe in a section 4!

Unfortunately, to make everything work properly you’ll have to log out and login again, or reboot your Mac, as Lingon will remind you:

Lingon restart warning

Lingon restart warning

Not only can Lingon be used to make your own script or application launchers, but it can also be used to edit existing system agents and daemons. While you normally shouldn’t do this, if you know what you are doing it can sometimes improve system performance. On the other hand, if you don’t know what you are doing, you could render your system totally inoperable! As an example of why you might want to do this, we recommend you see the article, “The Case of the Slow Mac (and how to fix it)” at Maciverse. If you think that your Mac is running a bit sluggish, or if you’re seeing the “spinning beachball of death” a bit too often, this article explains one possible reason, and a suggested fix that’s much easier to make if you use Lingon.

Leave a Comment

Setting up an OpenVPN tunnel using a CentOS-based system as the server and a router flashed with Tomato firmware as the client – Part 4

Continued from Part 3

If you have set up an OpenVPN server on your system and are using it regularly, eventually you are going to want to trim the log file. Webmin actually makes that easy. Simply click on System, then Log File Rotation. You should see a bunch of existing log file rotation rules. Up near the top of the page there’s a line that reads:

Select all. | Invert selection. | Add a new log file to rotate.

Click on Add a new log file to rotate. You should get a page that looks like this:

Webmin Log File Rotation - Add New File page

Webmin Log File Rotation - Add New File page

The main thing here is to get the correct log file path into the topmost text area. The path will be something like:

/etc/openvpn/servers/servername/logs/openvpn.log

I generally keep all the default settings except for these two:

Rotate even if log file is empty? (I set to No)
Ignore log file if missing? (I set to Yes)

But you can do as you wish. The important thing is to make sure that the log isn’t simply allowed to grow forever Set it up as you like, click Create, and you’re through.

And now a note for FreePBX and Asterisk users.  When setting up an extension, if you use the permit and deny fields to enhance security, the correct way to fill these out may not be intuitive. For example, if you do sip show peers from the CLI, an extension at the client end of the tunnel may show up with an address in the range of addresses assigned by the client router (such as 192.168.5.x) and yet when you fill out the permit field, using that address may not work.  Asterisk’s log file will generally tell you the address it wants to see, and in our case that was 10.8.0.10! No, I don’t know why, but just wanted to give you a “heads up” on that one.

Deny and Permit fields from FreePBX extension page

Deny and Permit fields from FreePBX extension page

If you have followed this series thus far, I should point out that these articles are not static – if I find a mistake, or a better way to do things, they may get changed. On the other hand, since this particular router probably won’t be in my possession much longer, it may be something that I don’t do much more work on.

One thing I had said I would do in this last article is to give you a list of links that I found useful, or at least interesting, while working on this project. I didn’t actually utilize the information in all of these, and some are even a bit off-topic for the subject at hand, but this is just a small fraction of the pages I went through while trying to get this to work:

OpenVPN HOWTO

OpenVPN FAQ

OpenVPN 2.1 man page

The ‘Point and Click’ Home VPN HowTo Guide (this was one of my primary sources)

OpenVPN: Building and Integrating Virtual Private Networks (book)

Tomato’s Frequently Asked Questions & Tips

An Easy Guide to Installing Tomato on the Asus 520gu

Teddy_bear’s Tomato 1.25 ND USB + FTP/Samba Mod (In my opinion the best firmware mod for Asus WL-520GU – be sure to get the VPN version)

Keith Moyer/SgtPepperKSU’s VPN build with Web GUI (also a great version, particularly if your router isn’t supported by the above version)
His blog

Summary of OpenVPN settings in Tomato Firmware

Tomato Firmware forum

Setting Up A Low Cost NAS Using Tomato

Using Tomato QOS

Did I configure QoS VoIP correctly? (message thread)

QOS for SOHO VOIP Solved, Tomato Firmware

Optware installation instructions (supposed to also work with Tomato firmware, potentially allows use of numerous software packages originally written or converted for Linksys NSLU2):

Linux 2.4 NAT HOWTO

OpenVPN IPv6 Tunnel Broker Guide

OpenVPN client configuration for Windows, Linux, Mac OS X and Windows Mobile for Pocket PC

Installing a Virtual Private Network with OpenVPN

USB disc partitioning utilities available.

“A set of disk utilities that will execute on a Tomato router. With these utilities you can now create ext2 partitions on a USB drive on the router itself, so you don’t have to use a Linux desktop machine to do it anymore.”

“A brief help file is included.”

Download link (filename is “tomato_dskutils.tgz”)
Direct link

And there’s probably plenty of other great links that I’ve missed.

Finally, one more word about the TAP/TUN issue. I would sort have liked to have gotten this working in TAP mode. However when I tried to set it up, OpenVPN (on the server) complained about a missing brctl file. Well, it turned out that the way to get that file was to do yum install bridge-utils – sounds easy, right? I assure you, absolutely nothing about this project was easy, at least not for me.

The problem was that after I had installed the software and switched both sides from TUN to TAP, and then restarted the OpenVPN server, it brought down the entire local network! I mean to tell you, I couldn’t connect to any web pages or do anything else until I physically killed the power to the server box! When I brought it back up and disabled OpenVPN, everything connected to the LAN worked fine again. When I uninstalled bridge-utils and went back to using TUN, the tunnel started working again. I had been up all night, it was coming up on 7:00 AM, and I was just so doggone frustrated by that point that I never even tried to get TAP working again. Besides, I just don’t like doing things that can bring down the entire network. I suspect it was doing some kind of packet flood thing, sort of a denial-of-service attack on my local network – pardon me if I’m not thrilled about the prospect of trying that again!

After some additional online research, I suspect that part of the problem is that after installing bridge-utils, you need to create and/or modify certain files, such as /etc/sysconfig/network-scripts/ifcfg-br0, /etc/sysconfig/network-scripts/ifcfg-eth0, and possibly /etc/sysconfig/network-scripts/ifcfg-eth1 (though I’m not at all sure about that last one). For example, one site I went to (which, for some reason, I could only read by using Google’s cached copy, which is why I’m not giving a link) said, “Configure this server’s network configuration to use a bridge as its primary interface. You do this by bridging the physical ethX and virtual tapX interfaces into one logical br0 interface. The br0 interface will be assigned an IP address, and not the physical or virtual interfaces.” That site also suggests that those files should read as follows (note that I do not recommend following this advice verbatim, see my comments below):

/etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
TYPE=Bridge
IPADDR=192.168.0.50 <— local IP of the server
NETMASK=255.255.255.0
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=ETHER
BRIDGE=br0
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=tap0
TYPE=ETHER
BRIDGE=br0
ONBOOT=yes

Please note the above is totally untested at this point, and I’m afraid that the advice to modify the existing files (particularly /etc/sysconfig/network-scripts/ifcfg-eth0) may (or may not) be ill-advised. What concerns me is that the /etc/sysconfig/network-scripts/ifcfg-eth0 file seems to contain a lot of essential information that is in effect being thrown out – for example, on our system, it reads as follows:

DEVICE=eth0
BOOTPROTO=static
DHCPCLASS=
HWADDR=00:xx:xx:xx:xx:xx
ONBOOT=yes
TYPE=Ethernet <— NOTE!! 'Ethernet', not 'ETHER'
IPADDR=192.168.0.50
NETMASK=255.255.255.0
BROADCAST=192.168.0.255
NETWORK=192.168.0.0
NOZEROCONF=yes

I’m just not sure what is the proper thing to do here — maybe just add the BRIDGE=br0 line to the existing file? But, if you do decide to try a full replacement of any file, be sure to copy the existing file to a safe location so that if things go badly you can recover your original file!

Some of the comments I have read suggest that TAP mode is not as efficient in transferring data, and/or not as secure (unless you add even more configuration options), so I’m thinking maybe we should leave well enough alone. But, if you have a truly burning desire to get it going, I suggest using the following Google search string for additional information – it may be strange, but it actually produced the most relevant results of all the searches I’ve tried over the last few days:

“/etc/sysconfig/network-scripts/ifcfg-br0″ OpenVPN

Hopefully this page won’t show up as the first result! :)

If you have any ideas about what went wrong, or in particular, if you manage to get this working in TAP mode, I’d be most interested to hear about it (and how you did it, if you got it working) – the comments are open.

Here’s another bit of information that may be useful for those of you that don’t know much about Linux — here is a very small list of Linux commands that may be useful in diagnosing any problems with your VPN tunnel:

  • ifconfig – shows the current list of  network interfaces.  On both ends of your tunnel you should see a tunx interface when the tunnel is operational. On Windows-based systems a similar command is ipconfig.
  • ip route show – shows current routing information for the system (see also route). ip route list gives a slightly different view.
  • iptables -L – lists the current iptables rules. Add the -v option to get a more verbose display.
  • netstat -r – similar to route but with a slightly different view.
  • ping address - tries to get a response from another connected machine or device.  Note that not all systems or devices will respond to pings.
  • route - shows the current routing tables on the system (see also ip route show).
  • tcpdump -n – this shows a running display of all activity on the network interfaces.  Be careful because this can produce a LOT of output very quickly.  Use Control-C to interrupt, then be prepared to wait until the buffer empties (may take a few seconds.
  • traceroute address – If you run a traceroute to a network address (either on the LAN or on the Internet) it will attempt to show each system the packets pass through on the way to their destination. This can be useful for determining if traffic to a particular destination is actually going through your tunnel. On Windows-based systems use tracert (a holdover from MS-DOS days when filenames were limited to eight characters!).
  • which program-name – not a network command per se, but if you get an error message about a missing program, you can use which program-name to try to determine if the program exists on your system, and the correct path to that program.

Note that there are additional options for most or all of the above commands – read the man page for that command (e.g. man tcpdump) if you are interested, or use a search engine to find more information (yeah, I think most man pages are painful, too). man is short for manual, by the way, not a reference to gender.

Anyway, I’m still trying to catch up on lost sleep, but if I think of anything else pertinent I’ll probably add it to this article, rather than making this series any longer. I hope if you attempt this, it’s not nearly as painful for you as it was for me!

Leave a Comment

Setting up an OpenVPN tunnel using a CentOS-based system as the server and a router flashed with Tomato firmware as the client – Part 3

Continued from Part 2

Okay, time for the hard part… well, at least it was for me.  Please understand, the instructions at The ‘Point and Click’ Home VPN HowTo Guide, combined with the knowledge I acquired from the book OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner, enabled me to get a tunnel going using a software client with no sweat. But getting it to work with the Tomato VPN client, and in particular, to get it to work the way we needed it to, was a whole other thing. It turned out, as so often happens that some simple configuration changes were all that was needed – but finding the correct configuration changes to make were pure grief.

I want to digress just a moment to speak about those elitists that seem to frequent certain forums and IRC channels, and just love to tell newbies (often in not so polite terms) that all the answers can be found by using Google. I’ve pretty much figured out that most of the time, the person saying that doesn’t know the answer either, but they are like the schoolyard bully that gets their kicks by picking on others. In this case, Google may have had the answers somewhere, but they sure weren’t showing up in the first few pages of results. Instead, what was showing up was many others who were having the same problems and asking the same questions, but not getting answers! And usually after the first four or five pages of results, the results became even less relevant, if that were possible. Finally, after taking a more or less scattershot approach to seeking help, I came up with a “recipe” that works in this situation. Of course I cannot guarantee it will work for you… heck, I can’t guarantee it will work for me next week… but at least it’s working as I write this. But the next time someone suggests that you should just Google it (or something like that), I suggest you ask them what search terms they would suggest using that will bring you the answer to your question. When whatever they suggest doesn’t work, let them know and ask for more suggestions, and just keep repeating until you find the answer or they get sick of talking to you. If we all did that, I suspect some of the online bullies would discover that maybe they should keep quiet if they don’t know the answer.

Okay, so to begin, let’s make sure we are all on the same page. I assume you’ve installed the Webmin OpenVPN + CA module (again, following the instructions at The ‘Point and Click’ Home VPN HowTo Guide) but if you had difficulty locating the module, try here — as I write this, it appears that the newest version of the module is the OpenVPNadmin WebMin pre-release 2.5 version. And when you try to download it, if you get “Unauthorized access to downloads!”, try a different browser, or make sure JavaScript and cookies are enabled.  You will probably need to download it to your computer first, then upload it to Webmin, if your experience is anything like mine was.

When you go into the module, you’ll initially see a page like this:

OpenVPN administration page

OpenVPN administration page

This is “home base” for this module, so when I say “return to the admin page”, this is the page I mean. It’s also the page you use to create a new Certification Authority (normally you only need to do that once, but if you really want to you can make more). In the upper left corner there is a link labeled “Module Config” – click on it and make sure all the paths are correct:

OpenVPN + CA configuration page

OpenVPN + CA configuration page

A couple notes on this page:  First, although it indicates that “Server Hint for Clients” is a required field, there is no indication of what actually goes there, nor any default value.  Second, the information under “If you use bridge device” is only applicable if you use TAP mode (remember, we’re using TUN), but I do know the defaults are not correct.  Just in case you ever want to try to get TAP mode working, here is what these paths should be (at least on our installation):

Command to start Bridge:
/usr/libexec/webmin/openvpn/br_scripts/bridge_start

Command to stop Bridge:
/usr/libexec/webmin/openvpn/br_scripts/bridge_end

Path to DOWN-ROOT-PLUGIN:
/usr/share/openvpn/plugin/lib/openvpn-down-root.so

Do check the paths on this page, because the defaults aren’t totally correct.  Now let’s return to the admin page.  I probably should have mentioned that you don’t really need to change any of the defaults for making a certificate for just your own use – those values are probably only important if you are creating a certificate that will be used by the public.  Once you have made a certificate, you can click on the Certification Authority List, where you’ll see this page:

OpenVPN Certification Authority page

OpenVPN Certification Authority page

I really don’t know why you can create a new Certification Authority on both this page and the main admin page, but oh well… once you have created one it will show up in the list at the top of the page.  You can click on it to view what you created, but there’s nothing you can change there. The main thing of importance is the “Keys List” link, where you can actually create new keys and view existing ones:

OpenVPN key list and key creation page

OpenVPN key list and key creation page

Okay, now here’s the important thing to remember about key creation: You need one key for your server, and one key for each client.  You will note we have a server key, and client key for the software client (used for testing) and one more for the OpenVPN client on the Asus router.

As you may have surmised, except for the key name field, you can leave everything else at the defaults. However, there is one thing on this page that will lead you astray.  It says, “Server key doesn’t need password!“, which might lead you to think that a client key does need one, but that’s not true.  And if you use a password with your Tomato-based client key, you will never make a successful connection.  The keys are far stronger protection than passwords anyway, so the only reason you might even consider using one is for a software client where you want to keep anyone other than an authorized user from connecting to the VPN tunnel.  Anyway, don’t use a password for your server key or your Tomato OpenVPN client key!!!

Okay, now it’s time to navigate back to the admin page, then click on “VPN list”. Once you have created a server key, you can create your actual server. So click on the New VPN Server button and a page will come up that permits you to create a server configuration.  This is where things get really tricky.  Here is how ours is filled out:

OpenVPN Server page

OpenVPN Server page

Now the above is actually the edit page you get once the server is created and you have returned to edit it.  Note that some values cannot be changed after the initial entry, so be sure you get them right the first time.  In particular, make sure to select tun and not tap. If you do make a mistake, you can always delete the entire server configuration and start over, but that’s a bit of a pain. There are some differences in our configuration and the one at The ‘Point and Click’ Home VPN HowTo Guide, and generally speaking there are good reasons for the differences. But that said, nobody is claiming our configuration is perfect, just that it works! If you see something here you think should be changed, feel free to leave a comment.

Note in particular the text fields at the bottom of the page. Getting those right is the key to making this thing work! So, here’s what’s in each of those:

Additional Configurations:

push “route 192.168.0.0 255.255.255.0″
push redirect-gateway
push “dhcp-option WINS 192.168.0.50″
script-security 2 system

up (script execute after VPN up):

route add -net 192.168.5.0 netmask 255.255.255.0 gw 10.8.0.2 tun0
echo 1 > /proc/sys/net/ipv4/conf/tun0/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

down-pre (script execute before VPN down):

route delete -net 192.168.5.0 netmask 255.255.255.0 gw 10.8.0.2 tun0

Of course, in the Additional Configurations section you want the line push “dhcp-option WINS 192.168.0.50″ to point to a WINS server on your network, if you have one (if you don’t, just leave that line out).

In the up and down-pre scripts, if you want to be able to reach the local network behind the WAN port of the router on the client side, you should add additional route add and route delete lines in a format similar to those above, but substituting that network’s address range.

Now, once again, I’m NOT saying this is a perfect configuration, just that it works for us. However, if you notice something that just doesn’t look right, feel free to leave a comment. Much of the added configuration was put in so that traffic from the primary LAN to addresses in the 192.168.5.x address space would actually go through the tunnel – that was the hardest part. It was (relatively) easy to create a tunnel in the first place, but getting packets to and from their intended destinations was another matter entirely.

When you have configured you server and clicked “Save”, it should show up in your server list:

OpenVPN Server List page

OpenVPN Server List page

Now click on “Clients List” – there will be a button labeled “New VPN Client” (no screenshot, it’s just a button to click at this point).  Click that button and you will be presented with a client configuration page.  Here’s the one we created for our Tomato OpenVPN client running on the Asus router (again, this is actually the edit page, since the client is already created on our system):

OpenVPN Client Configuration page

OpenVPN Client Configuration page

Most of the settings here will be the defaults but there are two things to pay particular attention to:  First, the “Remote IP” must be the external address of your server – remember that this is the configuration that goes to the client. And second, notice the ccd file content box at the bottom – it is crucial that this be filled in correctly. In our case, we used this line:

iroute 192.168.5.0 255.255.255.0

If you miss this – and I speak from experience on this one – the packets from the Internet or your local LAN just aren’t going to get back to the client end of the tunnel! And remember to add an additional, similar line if you also want to be able to reach the network connected to the WAN port at the client router, substituting the base address of that network for the 192.168.5.0.

Once you have saved this, it should appear in the VPN client list:

OpenVPN Client List page

OpenVPN Client List page

Once you have configured a client, the next step is to export its configuration, particularly the certificate and key files, to your computer using the “Export” link – all the necessary files will be packed up in a ZIP file.  The instructions at The ‘Point and Click’ Home VPN HowTo Guide tell you how to use this file with a software client, but with your Tomato firmware you will have to unzip the file and then open each of the three files (ca.crt, plus the client certificate and key files), in a text editor or viewer. Only those three files are used with the Tomato OpenVPN client; the others in the ZIP archive are not. Then you will need to cut and paste the contents of those files into the three fields that appear under VPN Tunneling | Client | Keys tab in the Tomato firmware (see the screenshot of that page in Part 1 if you’re not sure what file’s contents goes where). With regard to the Client Certificate, there is some extra information at the top of the file that does not need to be pasted into the text field – you only need the two lines —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– plus all the lines in between those two tags. On an Asus WL-520GU router it doesn’t matter much, but there have been cases with some other makes of router where leaving that excess information in was just enough excess data to “brick” the router! So if in doubt, leave the data above the —–BEGIN CERTIFICATE—– line out.

Once you have everything ready, you can go to the OpenVPN admin page in Webmin and start the server, then in your Tomato firmware start the client.  HOPEFULLY the client and server will connect and start communicating.  You can check from the server’s  admin page by clicking on “Active Connection” – hopefully you will see something like this:

OpenVPN Active Connections page

OpenVPN Active Connections page

If you do, congratulations! If not, you have some troubleshooting to do. On the server, take a look at the log file: /etc/openvpn/servers/servername/logs/openvpn.log. On the client, click on Logs (under Status in the left-hand menu) and look at the last several lines. OpenVPN usually doesn’t suffer in silence — when something isn’t working, chances are one or both logs will be filled with messages that may or may not be helpful. You can always try going to Google and using OpenVPN plus the actual error message text (enclosed in quotation marks); once in a while that will actually bring up something useful.

Still stuck? My plan is to add a Part 4 to this series, that will provide links to some of the most useful resources I’ve collected along this journey.  But you can certainly help — if I’ve made any errors in these instructions (not at all unlikely given the sleep I’ve missed during this project), and you find them and can figure out what was incorrect, PLEASE leave a comment. I will warn you that writing to me with your error message will probably get you nowhere – I can definitely play the part of the blind leading the blind, so to speak, but first I have to heal from all the bruises encountered on this journey! :)

I sincerely hope these posts have been useful to you! In Part 4 I’ll wrap this up with brief instructions for rotating the log file so it doesn’t grow forever, provide the aforementioned list of links, and give you a bit more insight into why I set this up using TUN mode even though I’d probably have preferred to use TAP.

Leave a Comment

Setting up an OpenVPN tunnel using a CentOS-based system as the server and a router flashed with Tomato firmware as the client – Part 2

Continued from Part 1

Before you can begin to set up the OpenVPN server, there is some preparation work that needs to be done. But first, let’s talk about the prerequisites and assumptions we are making here. In the case of the tunnel I was helping to set up, the OpenVPN server was located on a box that runs the Elastix PBX distribution, which includes the CentOS operating system, plus FreePBX and Asterisk and a few other things. It doesn’t really matter whether the box has other servers on it (of course, if it’s a really old/slow box there may be performance issues), but for the purposes of our instructions here, the most important thing is that you have Webmin installed.  Let me repeat that loud and clear:

You MUST have Webmin installed to use these instructions!

You don’t have Webmin installed and you don’t want to install it? Fine, shoo, away with you then. There are hundreds of other installation guides on the Internet, go find one you like.  You have to keep in mind that with me, whenever there’s a choice between using the Linux command line or manually editing a configuration file, and using a nice GUI, I’ll pick the GUI every time.  Some people (usually long time Linux users) seem to have some philosophical objection to using Webmin – if that’s you then you’re obviously much too smart to need these instructions, so what are you doing here?

I’m going to assume you already have Webmin installed, but if you don’t, try doing yum install webmin — it might already be in a CentOS repository.  If that doesn’t work, you should be able to do this:

wget download.webmin.com/devel/rpm/webmin-current.rpm
rpm -ivh webmin-current.rpm

Once you get Webmin installed (or if you are using a Debian-based distribution such as Ubuntu) go to The ‘Point and Click’ Home VPN HowTo Guide — we’re going to refer to that document several times, so you may want to keep it open in another browser tab. But for now, just follow the instructions related to installing Webmin, starting (for CentOS users) with the subheading “Access Webmin”.  For now, just follow the instructions in the two paragraphs in that section.  On a Debian-based system, I’d try following the entire document, but I can tell you there are parts missing for a CentOS-based system, so stick with us for a bit.

Another assumption we are making is that your primary network (the one the server in on) has addresses in the 192.168.0.1 through 192.168.0.255 range.  It’s okay if the “0″ in the third octet is some other number (hopefully it’s not 5, because that what we used at the client end) but the main point is that we’re assuming it’s a small network.  If you’re using more than 255 addresses on the primary network it’s not an insurmountable problem, as long as the client end has its own unique address space.

Open the file /etc/hosts.allow at the server – you should see something like this:

ALL : 192.168.0.0/255.255.255.0

If you do, change it to the following two lines (note the change in the netmask in the first line):

ALL : 192.168.0.0/255.255.0.0
ALL : 10.8.0.0/255.255.255.0

Or, if you prefer to be a bit more secure, specify the network(s) at the distant ends of the tunnel individually (using a more restrictive netmask), e.g.:

ALL : 192.168.0.0/255.255.255.0
ALL : 192.168.5.0/255.255.255.0
ALL : 10.8.0.0/255.255.255.0

(If you do the latter, you may also want to add a line for the network on the WAN side of the client router, e.g. ALL : 192.168.1.0/255.255.255.0 to be able to reach devices in that subnet from the server side of the tunnel — assuming that won’t conflict with any addresses on your own local network).

You also need to go into your router (the one between the OpenVPN server and the Internet, that controls the LAN at the server end) and expand the scope of your local network.  I can’t give you specific instructions for your router, but generally the principle is the same as in the hosts.allow file – in most cases you need to expand the scope of the local netmask to 255.255.0.0 (don’t worry about the 10.8.0.x addresses, your router won’t see those).  The reason for this is that when something on your primary LAN tries to connect to an address in the 192.168.5.x range (on the other side of the tunnel), you want your router to send out an ARP probe to find out which device on the network has that address (getting the OpenVPN server to respond is another issue that we’ll cover later).

While you are in the router, you need to open UDP port 1194 for incoming traffic and point it at your OpenVPN server – otherwise outside connection attempts will never be received by the server. Don’t open the corresponding TCP port – it’s really not a good idea to use TCP for OpenVPN unless you are forced to do so (by an overly restrictive ISP, for example).

You also need to open up the file /etc/sysctl.conf and make use that the following line is NOT commented out (add it if it doesn’t already exist):

net.ipv4.ip_forward=1

Also, at a terminal prompt, execute the following:

echo 1 > /proc/sys/net/ipv4/ip_forward

While in the terminal, you SHOULD upgrade OpenVPN to the most current version (or install it if it’s not already installed).  Here is how I did that (of course, the release version may change by the time you read this):

sudo rpm -ihv http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-2.noarch.rpm
yum install openvpn

Note that you must use compatible versions of OpenVPN at both the client and server ends, so once you have an OpenVPN tunnel working, it might not be a good idea to just go upgrading the software at one end or the other unless you know the newer version is still compatible with what you’re using on the other end (minor version upgrades are probably okay, but I am not guaranteeing that!).

Now return to The ‘Point and Click’ Home VPN HowTo Guide — you want to find the section headed “Setting Firewall rule(s) to allow VPN web traffic to redirect out eth0″ — now I will just say that you need to follow those instructions, but when setting up the actual rules, I found that only two were really important.  So if I were rewriting their instructions, here is how I’d say it:

First we’ll assume that the firewall is not set up yet so click Reset Firewall. Now we need to add some rules. From the Showing IPTable: dropdown select Packet filtering  (filter) where we’ll create the following rule:

Forwarded Packets (FORWARD)

Accept If input interface is tun0
Incoming interface Equals tun0

Then, from the Showing IPTable: dropdown select Network address translation (nat) where we’ll create the following rule — this is the rule that goes along with the VPN “push redirect-gateway”. This allows the VPN web traffic to be routed out through your connection:

Packets after routing (POSTROUTING)

Masquerade If source is 10.8.0.0/24 and output interface is eth0
Source address or network Equals 10.8.0.0/24
Outgoing interface Equals eth0

Why not add the rest of the rules? Well, if you Reset Firewall as instructed, you don’t need them, because they are specifying default conditions. But if you didn’t want to reset the firewall because you already have some preexisting rules, or if you ever actually decide to go in and configure some more restrictive firewall rules, then you may need some of the other rules listed. There’s certainly no harm in adding the other rules, but I’d rather emphasize the two that are absolutely necessary to get this working, assuming you started with a clean slate.

When you are finished, the two rules pages should look like this:

Firewall rule: Accept If input interface is tun0
Firewall rule: Accept If input interface is tun0
Firewall rule: Masquerade If source is 10.8.0.0/24 and output interface is eth0
Firewall rule: Masquerade If source is 10.8.0.0/24 and output interface is eth0

(I know that at this point, some Elastix and FreePBX users may be wondering if the above would interfere with the operation of fail2ban, in the event they have installed it. As far as I can tell, the answer is no… fail2ban communicates with the firewall in a different way, and unless you add rules that explicitly contradict what fail2ban does, I don’t think there will be any issues. However, I do recommend that you temporarily disable fail2ban, possibly from Webmin’s System | Bootup and Shutdown page, prior to connecting a new VoIP adapter or similar device on the client end of a tunnel for the first time. The reason is that if the device fails to register for any reason, such as a mis-typed password, fail2ban might refuse connections even after you fix the issue, and it might even clamp down on other connections from the client end of your tunnel. So get your devices registered and working, then restart fail2ban. Alternately, if turning off fail2ban makes you nervous, you could open /etc/fail2ban/jail.conf in a text editor, then edit the ignoreip option under the [DEFAULT] section to include the IP addresses or network on the client side of your tunnel — for example, you could add 10.8.0.0/24 and 192.168.5.0/24 as address ranges you don’t ever want to ban.)

Once again, return to The ‘Point and Click’ Home VPN HowTo Guide — now you want to start at the section, “Install OpenVPN-admin module” and continue through to the part entitled “Testing the VPN Server using the OpenVPN client GUI from Windows.” What I suggest you do here is setup TWO clients, one for a soft client you can use for testing purposes, and one that you will use with the OpenVPN client in the Tomato firmware. While you might be able to get a Windows-based client to work using the instructions shown, I can assure you that the Tomato client isn’t going to work until you add a few additional tweaks, which we’ll cover in Part 3. But you can certainly set up and test the Windows-based client if you like, just to assure yourself that the server is actually working.

Just so you don’t spend a couple hours beating yourself up wondering why the server won’t start, I will point out that there’s a glitch in the Webmin OpenVPN module. When you click on the VPN server list and then click on Start to start a server, the server name is supposed to turn from red to black, and the word Start is supposed to turn to Stop. For whatever reason, that doesn’t happen on our server… you can click Start until the cows come home and it still won’t turn black. It probably has something to do with the module configuration itself – for example there’s a setting for PID file path of running OpenVPN processes (*) which by default is set to /var/run, which may not be correct — however, when I changed it to /var/run/openvpn, which does seem to be correct, it made no difference. I just start and stop the server using the buttons at the bottom of the main “OpenVPN Administration” page, which seem to work fine.

Next up, in Part 3: Configuring the OpenVPN server using Webmin (or more specifically, the changes and additions you need to make to actually get it working as expected). More screenshots!!!

Leave a Comment

Setting up an OpenVPN tunnel using a CentOS-based system as the server and a router flashed with Tomato firmware as the client – Part 1

Some readers of this blog may recall that several months ago I had wished for a Simple VPN device – back then I had written:

There is another type of software that ought to be moved into its own box, and that is Virtual Private Network (VPN) client and server software. Yes, I’m aware of OpenVPN, and I tried to find setup instructions that someone like me could understand, but to no avail – it looks like you need a degree in computer networking to understand how to set up this type of software. And yet, built into hardware devices, it could be immensely useful in certain circumstances. Let’s consider the following diagram:

Diagram showing position of "client side" and "server side" VPN devices

In this particular case we have a SIP-based VoIP adapter at a remote location. Anyone who has worked with Asterisk behind the wrong kind of firewall knows the issues involved with using SIP and not having things set up just so (one-way audio, anyone)? But also, we may for whatever reason want that “remote” VoiP adapter to appear as if it were on the local network (maybe we have an ISP playing games with SIP packets?). So we plug the VoIP adapter into our “VPN Client-Side Device” and on the other end, we have a companion “VPN Server-Side Device” which in this case makes two connections to the router – one to receive the “tunneled” data and the second to send the unencrypted data back onto the local network. The green arrows represent the “tunnel”, the orange arrows show where the data from the VoIP adapter enters and exits the tunnel. Please note this is entirely a wired connection, we aren’t using wireless anywhere here. Also note that as far as the VoIP adapter is concerned, the only network it can “see” is the one at the other end of the tunnel – under no circumstances can it access the Internet other than by going through the tunnel.

I show this using a VoIP adapter, but I’m sure that people could think of a lot of other ways this could be used, and a lot of other devices that could be connected to the client end.

Now some will probably argue that it is inefficient to have a device that does nothing but provide the tunnel. But that’s the point – almost anyone could set this up. If you send the client-side device to your grandmother, she can set it up (well, maybe that’s pushing it a bit, but you get my point). People who would never touch a Linux box or a server could use this.

I want to tell you, when I wrote that I had no idea just how difficult it would be to actually get VPN tunneling working using OpenVPN.  The problem isn’t that it doesn’t work — actually, it works quite well — the problem is that it’s a real bear to set up, unless you have someone who knows what they are doing walk you through it.  Unfortunately, you may not haves someone who knows what they are doing to help you, so you’re stuck with me (unless you can find a better page on the subject – if such exists, please let us know in a comment).

The real issue is that you have to learn so many new things at once to make this work.  So, my attempt here is going to be to try and give you a “cookbook”, with plenty of screenshots so you can see how things actually look when everything is configured.  I’m actually also going to approach this in a slightly backward manner, showing you how to configure the client first, then the server.  My theory is that you will think that configuring the client is so simple that configuring the server can’t be much harder, and you’ll get sucked into the project before you realize what you’ve gotten yourself into! :)

By the way, what we are doing here doesn’t look exactly like the diagram above – instead it looks more like this (note that the “Primary Router” on the client side can be omitted if you don’t need any UN-tunneled connections, or if the DSL or Cable modem has a built-in router):

Diagram showing position of OpenVPN client and OpenVPN server in data flow

Diagram showing position of OpenVPN client and OpenVPN server in data flow

For our client, we need something that you can plug your desired device into. You may have a laptop, and you want to communicate securely with a home office. You may have a VoIP adapter, and you want to make secure calls to a remote Asterisk server.  While you can run a software client on the Laptop, when you have a hardware device like a VoIP adapter your choices become more limited.  The solution is to purchase a router that is capable of being re-flashed with custom firmware.  In this case we are going to use the Tomato firmware, and in particular, a version of the firmware designed to support OpenVPN as either a client or a server. Here we’re going to use it as a client. The idea will be that ANY device plugged into the router will automatically use the VPN tunnel, and if for some reason the tunnel isn’t available then the connected device will not be able to communicate, therefore there’s little chance that an insecure communication can take place.

Some readers will already have a router capable of running Tomato firmware, and some will not.  The main Tomato Firmware page shows which routers are supported.  If you do not already have one of these and plan to buy one, I recommend that you consider the Asus WL-520GU. I know that the main Tomato firmware page says there’s no USB support for that model, but that’s not necessary for what we’re going to do, and it’s not even true if you use the recommended firmware build. The reason I suggest using the WL-520GU is because I’m told that although it’s not totally impossible to “brick” the router by doing a bad flash, if you do make a mistake, your chances of being able to recover (so that the router isn’t consigned to being an expensive paperweight) are far better than with some other models.

I should mention here that I inherited this project from someone else who couldn’t get it to work.  I had made the mistake of casually suggesting they get the Asus router if they wanted to attempt this, only to find them on my doorstep with router in hand.  So again, I’m not saying this will be easy, and the one thing I will not tell you how to do is how to get the Tomato firmware onto your router.  The reason is that if I give you instructions and leave out a step and you brick your router, you will be mad at me.  Better you find someone else’s instructions, and if they’ve left out a step, you can be mad at them. I will mention that, at least in the case of the Asus router I had here, it was a two-step process – I used the Asus Firmware Restoration Utility to first install DD-WRT (using these instructions) and then used DD-WRT’s web interface (Administration -> Firmware Upgrade) to install Tomato (I’m skipping a whole tale of woe and grief that transpired between those two events). Basically I followed the instructions at An Easy Guide to Installing Tomato on the Asus 520gu, but I’m not telling you to do that — it’s up to you which instructions you wish to follow.

Why Tomato instead of DD-WRT?  Because Tomato works, that’s why. But if you want to try getting it working on DD-WRT, go ahead, knock yourself silly (only one tip for you, from a tweet by @pista01 on Twitter —  if you keep getting TLS errors, make sure your NTP client is set up). If you succeed, great for you. If you don’t, you’re welcome to come back here and continue on.

But don’t just grab the first build of the Tomato firmware that you see. You need one that includes VPN support.  There are two versions I would highly recommend — if you have taken my advice and acquired an Asus WL-520GU (or similar model with built-in USB port), then I recommend teddy bear’s build because it enables the “missing” USB support, and also includes the VPN support from SgtPepperKSU’s build — which is the one you should get if you DON’T have the Asus WL-520GU, but instead have some other compatible router.  Make sure you read up on the chosen build and be sure you get the correct firmware version.  For the Asus I used the binary from inside the tomato-1.25-ND-USB-8632-vpn3.3.rar archive, but there will probably be newer versions by the time you read this, or you may prefer a different version.

tomatoIn this series you will see several screenshots.  I’m using the custom “Tomato USB” theme, so the colors and “look” may be a bit different than what you see, but other than that everything’s in the same place as with the default theme. Later (after taking the screenshots) I replaced the tomato.png file from the theme with the one you see at the right, which I happen to like a little bit better.

Two other caveats: Although this router has wireless capability, for this application we aren’t going to use it — it’s going to be used on a wired network only.  That said, once you get it set up and working, feel free to experiment with the wireless capabilities if you like — just be aware that if something on the wireless side of things doesn’t work, I really can’t assist you. And also, we’re assuming that everything plugged into this router will be using the VPN tunnel full time, which implies that this router might (perhaps in a majority of cases) be plugged into another router, so that some other devices can access the local Internet connection, while the devices plugged into this router are limited to going through the tunnel. Note that if this router is plugged into another router, it would be preferable (but not absolutely essential) if it were in that router’s DMZ, so that you don’t have double NAT (Network Address Translation) taking place.

And now, a word about OpenVPN.  OpenVPN supports two different modes of operation — TAP and TUN.  In this case, we are using TUN.  We MIGHT explore TAP at a later time, but TUN is easier to set up, and ANYTHING that can be done to simplify this process is worthwhile.  The main difference, from the users point of view, is that using TUN the two ends of the tunnel occupy two different portions of the local address range.  In this case, on our “home” LAN, the addresses are in the 192.168.0.x range and are assigned by the main router.  At the client end of the tunnel, the router running the Tomato firmware will hand out addresses in the 192.168.5.x range.  Neither router steps on the other’s toes, so to speak, when handing out addresses.  And there is one other difference — although shared directories can be accessed across the network, Windows/Samba shares cannot be “seen” on opposite ends of the tunnel. If you know they are there and know the IP address and share name of the hosting device, you can still access them, but the mechanism that advertises shares doesn’t cross the tunnel.

With TAP, on the other hand, the router at the primary location hands out IP addresses in the same local address range to devices on both sides of the tunnel, and also (in theory, anyway) shares will be “advertised” across the tunnel.  Sound like what you’d want, right?  Except that when we tried to set it up on the server side, somehow we managed to bring down the entire network – it basically acted like a denial-of-service attack on the entire LAN, and the problem stopped the moment we went back to using TUN. After you’ve messed with this stuff long enough, something like that can leave a rather bitter taste in your mouth, so we decided to stick with what worked.  In our particular application, seeing shares across the LAN would not be essential.  Even if you eventually want to try using TAP, I suggest setting it up using TUN first, then when you have achieved that you can cross your fingers and try switching the mode to TUN at both ends.  I doubt it will work easily for you, but experimentation is certainly welcome.

If you want to know more about TUN/TAP and other OpenVPN options, you might want to get the book OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner = see my recent review of this book.

So with the preliminaries out of the way, let’s get to the client screenshots…

Tomato Firmware - Basic | Network page

Tomato Firmware - Basic | Network page

This first shot shows the header, sidebar, and Save/Cancel buttons. Since the settings are probably a bit hard to read, we’ll zoom in on the pertinent part:

Settings portion of Basic | Network page

Settings portion of Basic | Network page

The main thing to keep in mind here is that the subnet you select must not conflict with address assignments on the primary network at the server. Next, on the Router Identification page, enter a Hostname to identify the router:

Basic | Identification page

Basic | Identification page

One thing I have read in several places is that it’s important for the time to be set accurately at the client.  For your choice of time servers there are several presets, but if you use Custom you can specify one or more of your own as the first choice(s), if you have a machine on your network that acts as an NTP server:

Basic | Time page

Basic | Time page

At this point you should probably go to the Administration | Admin Access page and set things up there to your liking. Remember that anything you make accessible on the router’s local LAN will also be accessible on the other side of your tunnel using the same security methods, so be careful.

Now to what we came for… setting up the VPN client. Click on VPN Tunneling and then on Client. I’ll say that one more time – you MUST click on Client. It’s far too easy to skip that step and accidentally be trying to configure a server! Then you should be at the Client 1, Basic tab:

VPN | Client page, Basic tab

VPN | Client page, Basic tab

Of course, the button at the bottom of the page will sat “Start Now” instead of “Stop Now” – I took these screenshots through the tunnel, so I couldn’t very well stop it to get that little detail right! After setting that up you want to click on the Advanced tab:

VPN | Client page, Advanced tab

VPN | Client page, Advanced tab

Note that the connection retry value is -1 (which means infinite retries) and there’s an added line in the custom configuration setion:

keepalive 10 120

Very observant folks may note that the above screenshot was made using a different browser than the others on this page, which is why the dropdowns look slightly different than in the other screenshots — I changed the screenshot to include these settings. In case the connection to the server or the Internet goes down for a time, those settings should cause the client to keep attempting to re-establish the connection to the server. Note that if your client is at a location where the ISP changes the IP address frequently, you may want to add the word float (on a line by itself) in the Custom Configuration — that is supposed to allow the VPN connection to survive an IP address change.

And then the Keys tab – just take a look now, when we move on to the server I’ll explain how these are filled in:

VPN | Client page, Keys tab

VPN | Client page, Keys tab

There is one more thing that needs to be done (besides adding the keys) for our tunnel on the client side. Go to Administration | Scripts and click on the WAN Up tab. Enter the following two lines into the text box:

route del -net 0.0.0.0
route add -host `nvram get vpn_client1_addr` gw `nvram get wan_gateway`

The second line may wrap on your display due to length. You may want to copy and paste those lines so you get them right, but if you must type them, note that the ` characters are actually backticks – the small apostrophe-like character on the key to the left of the “1″ key (the number 1) near the top left corner of most keyboards (well, in my part of the world, anyway). Then click on the Save button way down at the bottom of the page. If you fail to do this and your tunnel ever goes down (server dies or is inaccessible, etc.) there is a possibility that traffic that should go through the tunnel will use the local Internet connection instead.  These two lines will keep that from happening.

Once your tunnel is operational, you should go to the Advanced | Routing page and look at the Current Routing Table.  Your addresses will differ (this was a test setup; you probably will see a wider range of addresses) but the main thing you want to make sure is that there is never an entry of default (or 0.0.0.0) in the destination column that goes to any interface other than a tunnel (tun11 in this illustration) — you should never see that whether the tunnel is enabled or disabled.  If you do, then something’s likely wrong with the two lines you entered above:

Advanced | Routing page

Advanced | Routing page

So, that’s the basic client setup. Wasn’t too difficult, right? Ah, but just wait until we get going on the server — hopefully I can make it easy enough that you won’t have about three weeks worth of sleepless nights, when you occasionally mutter under your breath things like “Why? Why?? Why??? WHY won’t this damn thing work!”, and other things I’d rather not put on the Internet! But before I can write the next part, I REALLY need to catch some ZZZ’s, so the server will have to wait for part 2.

Leave a Comment

Review of OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner (Packt Publishing)

Cover of OpenVPN: Building and Integrating Virtual Private Networks

Cover of OpenVPN: Building and Integrating Virtual Private Networks

Before I start, let me give you a brief description of what’s in each chapter (this is taken directly from the Packt Publishing web site):

  • Chapter 1 looks at what VPNs are, how they evolved during the last decade, why it is necessary to modern enterprises, how typical VPNs work. The chapter also covers some essential networking concepts.
  • Chapter 2 explains VPN security issues, including symmetric and asymmetric encryption, the SSL/TLS library, and SSL certificates.
  • Chapter 3 introduces OpenVPN. In this chapter, we learn about the history of OpenVPN, how OpenVPN works, and how OpenVPN compares to IPSec VPN applications.
  • Chapter 4 covers installing OpenVPN on both Windows, the Mac, Linux, and FreeBSD. It covers the installation on Linux from the source code and RPM packages. Installation on Suse and Debian is covered in detail.
  • In Chapter 5, an encryption key for OpenVPN is created and it is then used to setup up our first OpenVPN Tunnel between two windows systems in the same network. The key is then copied on a Linux system and this system is connected through a tunnel to the first windows machine.
  • Chapter 6 shows how to create x509 server and client certificates for use with OpenVPN. easy-rsa which comes with OpenVPN and is available for both Windows and Linux is used.
  • Chapter 7 reviews the syntax of the command line tool openvpn, which enables building tunnels quickly. The configuration options of openvpn are covered in detail with examples.
  • Chapter 8 shows how to make the example tunnels created earlier safer and persistent by choosing a reliable combination of configuration file parameters. It then covers how to configure firewalls on Linux and Windows to work with OpenVPN.
  • Chapter 9 focuses on using xca, the advanced Windows tool with which x509 certificates can be easily managed. Its Linux equivalent, Tinyca2, which can even manage multiple certificate authorities, is also covered.
  • Chapter 10 covers advanced OpenVPN configurations, including Tunneling through a proxy server, pushing routing commands to clients, pushing and setting the default route through a tunnel, Distributed compilation through VPN tunnels with distcc, and OpenVPN scripting.
  • Chapter 11 shows how to debug and monitor VPN tunnels. It covers standard networking tools that can be used for scanning and testing the connectivity of a VPN server.

Although this may seem like a strange subject for this blog, I have recently become interested in the concept of Virtual Private Networks (VPN) because of the increasing number of attacks on Asterisk-based system based on spoof SIP credentials. SIP, the most popular protocol for VoIP, is an inherently insecure protocol – it relies on password protection only, and on most Asterisk boxes and in many VoIP devices and software products, the password is stored in plain text. On many systems, the user name is the same as the extension number, so all a potential intruder has to do is start a brute-force attack guessing passwords. The use of strong passwords along with the use of software like Fail2Ban (with iptables) can help minimize the exposure, but in the end it’s still only password protection.

Therefore, my feeling is that it would be much better to restrict extensions to access from within the local network (wherever possible), using the permit/deny fields in FreePBX or some similar mechanism, and then “tunnel” remote extensions through a secure VPN, so they appear to be on the local network.  The VPN could do the heavy lifting for security (even making the actual calls secure, although that wasn’t a priority in my situation).  My problem was that I knew next to nothing about VPN’s, and most of the pages on the Web seemed to assume at least some prior knowledge.  I needed something that would take me from zero knowledge to VPN guru.  Unfortunately, at my age it’s a case of “the spirit is willing but the brain is a bit weak”, so I realized that the “guru” part might not come very quickly (just as a comparison, I’ve been playing with FreePBX since back in the Asterisk@Home days, and there’s still a lot I don’t understand, but for the first year or so I felt totally lost).

Since the folks at Packt Publishing were willing to send me a review copy of OpenVPN: Building and Integrating Virtual Private Networks, I decided to see if I could actually learn anything from the book.  The first thing you need to know is that there are many types of VPN’s out there, and each will only communicate with its own kind, as it were.  The problem with most other tunnels is that they are either not all that secure, or contain proprietary code, or are incredibly complicated to set up and use (or some combination of the above).  OpenVPN has several advantages, perhaps the biggest being that it’s open source (so you can, if you are so inclined, examine the code and make sure there are no “backdoors” built in), that it can be as secure as you want it to be (and it’s not that difficult to make it very secure), and that it doesn’t rely on a third-party service over which you have no control (like one VPN application that touts itself as “zero-configuration”). So of all the VPN methods out there, OpenVPN seemed like a logical choice.

Now, having said that, the book covers its subject in a very logical manner.  Advanced readers (those already familiar with the principles behind VPNs) might find the introductory material in the first chapters a bit tedious, but believe me, it was just what I needed to help me get a grasp on the subject. As you go further through the book, there are many actual examples, first showing how to set up a working VPN tunnel, then how to add additional security, and finally how to troubleshoot connections.  If you are brand new at this, like me, you will probably find that you learn a great deal from the first chapters but find the latter chapters (especially Chapter 10) a bit beyond your comprehension at first.  However, the person who has some networking or VPN experience under their belt may think the first chapters a bit elementary, but will find the real meat they are looking for in the latter parts of the book. Either way, I guarantee you will come away with a greater comprehension of the subject.

The book shows how to install OpenVPN on several platforms (Windows, Mac OS X using Tunnelblick, FreeBSD, and SuSE, Debian, and Redhat/Fedora based versions of Linux), but it seems like some platforms are better covered than others.  A disproportionate number of examples and screenshots seem to be based on a Windows installation, whereas the Mac gets very little coverage. Because there are so many variations of Linux, the coverage there is mixed, although it seems like SuSE and Debian are better covered than Fedora-based versions, which was just a little bit disappointing because most Asterisk and FreePBX systems are based on CentOS, which is a Fedora-based OS. But most of the information in this book is not OS specific, so I didn’t have any real problem following along.

The biggest disappointment for me was in Chapter 8, where the book covers the use of Webmin, but primarily as an aid to administration of the Shorewall firewall.  Many Asterisk/FreePBX systems don’t use Shorewall, but instead use iptables (if they have a firewall on the Asterisk server at all).  But what was really disappointing was that there was no mention of, nor instructions for the use of the OpenVPN + CA module for Webmin (page is in Italian, but here is a description in English). I can only guess that because the book was first released in May,  2006 and version 1.0 of the Webmin module had only just been released in January of that same year, the author perhaps hadn’t had an opportunity to work with the module before the final draft of the book was submitted to the publisher. I hope that if this book is ever updated and republished, there will be consideration given to adding a chapter on the use of the Webmin module to set up and administer OpenVPN. In the meantime, you can find instructions for using the OpenVPN + CA module in The ‘Point and Click’ Home VPN HowTo Guide.

That said, I felt I learned a great deal from this book.  I was able to set up an OpenVPN server (using the Webmin module, but the book definitely helped me understand the purpose of the various options, and when I checked the configuration file that the module generated I was able to spot a couple of things that weren’t the way they should be for my setup and was able to change them) and the Windows client.  It all worked beautifully.

My project now, when I have absolutely nothing else to do, is trying to get the OpenVPN client running on an Asus WL-520gu router that has the DD-WRT firmware installed (I inherited this project from someone else who couldn’t do it).  So far this has proven to be a tough nut to crack – although it should be easy because (if you get the right version of DD-WRT) there is a built-in OpenVPN client with a handy configuration page, it just doesn’t seem to work “out of the box” – and from what I’m reading on the ‘net, for every one person who says they’ve got it working, there are about twenty others who have become incredibly frustrated by the process (example here – note that the original poster says he got it working, but that’s followed by about 16 pages of comments, mostly by people who just can’t seem to get it to go).  It’s a bit strange because the Windows client will work perfectly (indicating it’s not an issue with the server) but the firmware client in DD-WRT just doesn’t seem to work.  If I ever get it figured out, I’ll try to post what I did in this blog, but so far I’ve had no luck.  That, however, is not the fault of the book – in my opinion it’s the fault of the writers of the DD-WRT firmware, who apparently included a half-baked OpenVPN client interface in the firmware (I know, it’s free software so I can’t really complain, but one does wish that they’d taken a bit more care to make sure it worked).

After having read the book, I do feel fairly confident that if I should throw in the towel and decide to dump DD-WRT and install a different firmware on the router (I’m thinking about trying the Tomato firmware with USB support) I would be able to install an OpenVPN client from scratch and make it work.  Probably the main reason I haven’t wanted to do that is because I very much prefer using a GUI to do things, and would like to try to make the OpenVPN GUI in DD-WRT work (even if it requires a little help), but so far that doesn’t seem to be panning out.

But I digress a bit – anyway, if you are wanting to learn about OpenVPN, whether or not you are a rank beginner you will benefit from this book. The numerous examples and screenshots make it almost impossible to fail to get an OpenVPN tunnel up and running (providing you’re not using a questionable firmware client). And, as I said above, the book is laid out in a very logical progression, so I really didn’t feel totally lost at any point (as so often happens when I try to read technical books). Especially in the case where your boss suddenly decides he needs VPN tunneling capability, and wants you to have one up and running in a very short timeframe, this would be the book to get!

OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner (Packt Publishing link)

Disclosure (since apparently our Federal Trade Commission is getting a bit uptight about this sort of thing):  I have not been and will not be paid anything for writing this article, and I do not receive any commission or other compensation from sales of this book, and the links in this article are not affiliate links.  I did, however, receive a complementary review copy of the book from the publisher, for which I am most grateful.

Comments (1)

Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 7 – Addendum

Although I have technically finished up the series on the Atcom AG-188N (sold in North America by CIGear), I wanted to open a post to answer any questions or comments that may arise.

One thing that came up in another thread was that I didn’t say much about how the AG-188N unit can be remotely provisioned by a service provider. That’s because I was primarily writing the review from the end user’s point of view. I’m not a provider, and I guess I assumed that any provider that would be purchasing these units in quantity would be talking to the manufacturer or the distributor with questions about provisioning. I can tell you that there is a page explicitly for setting up provisioning, which looks like this:

Atcom AG-188N Auto Provisioning Configuration screen

Atcom AG-188N Auto Provisioning Configuration screen

Here’s what the fields contain:

  • Current Version —  the current version number is displayed
  • Server Address — FTP/TFTP server address
  • Username — FTP server user name
  • Password — FTP server password
  • Config File Name — The name of configuration file
  • Config Encrypt Key — The encrypt key of configuration file
  • Protocol Type — The protocol type used for upgrading — choices are FTP, TFTP, or HTTP
  • Update Interval Time — The AG-188N  will check for a new configuration file at the specified interval
  • Update Mode — auto provision mode — choices are:
    • Disable — Will not auto-update
    • Update after reboot — Will auto update after a reboot
    • Update at time interval — Will auto update at the specified interval

The normal way you’d use this is that you’d first create a “master” settings file by making a backup of the settings from one AG-188N that has been configured the way you want it (that is, with whatever “default” settings you want all users to have).  You’d use “Backup Config” to save this as a plain text file.  You can then open this file in any plain text editor (but use one that preserves the existing line endings, or you may have issues when you attempt to re-upload it). Note the first line of the default file contains this line:

<<VOIP CONFIG FILE>>Version:2.0001

When you change the  configuration file, you should bump the version number — presumably that’s how the unit would know there’s a new version. Then, for each unit, you’d customize the file (changing the values that are unique to each extension), and then save the file to your server with a unique filename and the .cfg extension.  For example, if you had an extension 200, you might name the edited file 200.cfg, and make sure that filename also is placed in the “Config File Name” field in the configuration file itself. You could upload the customized configuration file to the device the first time by using the Web Update page on the AG-188, or if the unit had already been sent to a customer site, you could send them an e-mail with the settings to enter on the above page.

The question was asked, is there a nice configuration tool such as is supplied for some other adapters?  Not to my knowledge, but if you look at the actual format of a configuration file, you’ll realize how easy it would be for any competent programmer to create such a tool. As an example, here’s a sample IAX2 configuration section from the file:

<IAX2 CONFIG MODULE>
Server   Address   :myserver.dyndns.com
Server   Port      :4569
User     Name      :200
User     Password  :securepassword
User     Number    :200
Voice    Number    :
Voice    Text      :
EchoTest Number    :
EchoTest Text      :
Local    Port      :4569
Enable   Register  :1
Refresh  Time      :60
Enable   G.729     :0

All you would need to do is do a search-and-replace on each line in the file — find the values that need to be unique for each extension and then change them.  You could do this using a Bash or Perl or PHP script, or probably any of a number of other scripting languages (you could even do it in BASIC, if that’s the language you’re most comfortable using).  Or you could get fancy and build a database of settings for each extension, allowing you to change values globally (for example, if changing a server name) or for one extension or a group of extensions. If you do that, and you don’t mind sharing it, please post a link in the comments, because I’m sure there would probably be others who would appreciate such a tool.

I know someone will ask, “How do I use the Config Encrypt Key?” And my answer to that is, doggone if I know, but if encrypting the file is that important to you, you’re probably going to be buying in sufficient quantity that you will be talking directly with the distributor and/or the manufacturer, so ask them.  As I said, I wrote this series primarily for end users, and while some end users may want to be able to auto-provision their devices (and there is even some talk of a provisioning tool or module possibly coming in a future version of FreePBX), there are few that would actually need the configuration file to be encrypted, provided that all users are internal and that your FTP or TFTP server (the one used to serve configuration files) is not accessible from the Internet.

Of course, if you have remote users, then you may be concerned about having them FTP or TFTP a plain text configuration file that shows their SIP and/or IAX user name(s) and password(s) with no encryption whatsoever — and if you are not concerned, you probably should be!  For those users, I think I’d at least compress the file with a password (using ZIP or some other format that allows password protection of files), then e-mail the compressed file to the customer, and then use some other medium (such as phone or fax) to get the file password to them.  They can then uncompress the file, and use the Web Update page on the AG-188N to get the .cfg file into their AG-188N.  I realize that’s not very convenient, so if I ever find out how the Config Encrypt Key is implemented, I’ll definitely edit this post to show the information.

As I said, this post is intended to be open-ended, in case any other questions or comments about the AG-188N require a response. So if you are interested in this device, you might want to check back from time to time, to see if anything else has been posted.

Previous Installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

Comments (1)

Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 6 – Final Thoughts and Summary Review

In yesterday’s installment of this series we discussed the internal router and other networing capabilities of the Atcom AG-188N (sold in North America by CIGear). The one thing that had me a bit puzzled was the implementation of VPN Tunneling. I’ve since been informed that the UDP method of VPN tunneling was implemented for a specific customer, and only works with that customer’s servers. However, the LT2P method does use standard L2TP, but without IPSec, which means it’s not a secure tunnel (there is no encryption used by default with L2TP). The most likely reason for using an L2TP tunnel would be to overcome NAT firewall issues, if for some reason you can’t use the IAX protocol and must use SIP instead. I’ve since added some information to yesterday’s article that includes a link to a blog post that shows how to setup an L2TP server on a Linux box. I’d still be interested in hearing from anyone that actually gets this working, since I haven’t really had the time to experiment with it yet.

Anyway, here are my final thoughts on this unit:

Let me state at the outset: I’m highly impressed with the AG-188N. Please keep that in mind as you read the paragraphs below, because reviews often tend to focus on areas where a product does not meet the reviewer’s expectations. In the case of the AG-188N, my expectations were met and for the most part, far exceeded. The one area where that was not the case was the documentation, and I’ll talk about that in a moment. But in my testing, this unit performed at least as well as any other VoIP adapter I’ve used, and I actually perceived the audio quality to be better than what I hear when using the venerable Linksys/Sipura adapters.

Atcom AG-188N

Atcom AG-188N

The Atcom AG-188N is a solid, well-built unit in an attractive charcoal-grey case.  It’s very similar in size to the popular Linksys PAP2, and could be a drop-in replacement in any situation where only a single line (phone port) is required. What most impressed me during my testing was that everything I tested worked at it was supposed to, although not always exactly in the same manner as it would on a Linksys adapter (the need to press the star key to complete a 3-way call being one example). The device supports up to two SIP accounts, but in addition it supports one IAX account (something rarely found in a VoIP adapter in this price range), and you can also connect a PSTN line to the PSTN port on the back to use for calls to emergency services, local calls, etc. If a call comes in using any of the supported methods the phone will ring and you can talk, but call waiting does not appear to work “across technologies” (that is, if you’re on an IAX call and a call comes in on one of your SIP accounts, the device will report BUSY rather than giving you the call waiting beeps).

Call quality is excellent, although out of the box the incoming receiver volume was a bit low, but that was easily adjusted in the device’s configuration.  I had no problems using this device with an Asterisk/FreePBX server, it worked as expected and was easy to configure (I daresay easier than the Linksys/Sipura adapters I’ve set up in the past).  It does not have as many configuration options as the Sipura, but the settings that are missing are for the most part ones you’d probably never change from the defaults anyway.  Actually, about the only settings I really wished for that I did not find were the ability to manually tweak certain tones (in particular, the tone that is sent when you leave the accidentally leave phone off the hook — this unit just provides a fast busy signal at roughly normal volume, which isn’t going to alert anyone that the phone is off the hook) but I’m probably the one person in 1,000 that would even care about that.

Honestly, I’m surprised that this unit hasn’t gained greater acceptance among VoIP users and service providers. Probably the greatest drawback of the unit is that many buyers will compare this with the Linksys PAP2 and notice that the PAP2 has two phone ports, while the AG-188N only has one.  But on the other hand, the PAP2 does not support the IAX protocol, and does not include a router with DHCP support and a NAT firewall, not to mention QoS and VPN tunneling, if you can figure out how to configure the latter two. The Atcom AG-188N supports all of this, at a very reasonable price.

The documentation that is provided with this unit, to put it charitably, could be much better.  No printed documentation is provided at all, but the included mini-CD contains documentation on several Atcom products including the AG-188N.  Unfortunately, it’s in .doc format, which may not be readable if you don’t have Microsoft Word (although there are free online services that can convert .doc files to other formats — Zamzar comes to mind, but there are many others). You can go to the manufacturer’s web site to find PDF versions of the documentation, but at least in the case of the AT-188N, that documentation appears to be older than the .doc files on the disk.  You may find that reading the previous articles in this series fills in some of the holes in the documentation.

Two specific issues with the documentation are that 1) it was apparently poorly translated from Chinese, with numerous spelling, punctuation, and syntax errors, not to mention being borderline incomprehensible in a few places (although it’s far from the worst translation I’ve ever seen), and 2) It is silent in some places where it should be more explanatory.  For example, there’s an entire section of the manual on QoS (Quality-of-Service) configuration, but it’s titled “VLAN implement” (so many users would have difficulty finding it) and worse, it really doesn’t explain which of several possible configurations should be used in any given situation.  For example, if you are using VoIP but you also have a computer (or a switch with multiple connected computers or devices) connected to the LAN port, how do you make sure that the VoIP packets get priority?  That’s the sort of thing that needs to be explained in clear, easy-to-understand language.

And, there are some settings on which the manual is inexplicably silent. Worse yet, the entire section on VPN gives such sparse information that I sincerely doubt that anyone could figure out how to set up a VPN tunnel without getting additional clarification. It doesn’t help that they picked two of the most obscure VPN methods to support – one that’s used only by a single customer (though they don’t mention that in the manual) and the other an implementation that you rarely see anymore (L2TP with IPSec is somewhat common, though still not nearly as popular as some other methods, L2TP without IPSec much less so, although in a perverse way that may be a blessing in disguise – everything I’ve read about IPSec indicates it’s kind of a bear to install).  I’m told that Atcom actually has a working OpenVPN implementation, but that it won’t fit in the flash memory and RAM of the device.

But really, none of this will matter to the typical user – there is a Quick Start Guide on the mini-CD that will be enough to get the average user going (or, you could refer to the previous articles in this series!) using IAX or SIP.  Most of the router configuration on the AG-188N is fairly self-evident — if you’ve ever set up a router before, you shouldn’t have any difficulty with the one in this device.  The places where things get somewhat complicated tend to be mostly places where typical users would fear to tread anyway.

If I could make a suggestion to Atcom, it would be this — For the next iteration of this device, please consider the following:  1) Enough memory for proper support of additional VPN tunneling methods, including OpenVPN,  2) More than one LAN port on the back of the unit (I know this will make it a bit larger, but you already have the AT-188N for those who need the smaller form factor) – it would be good to have at least four LAN ports,  3) the ability to select whether each individual LAN port is tunneled or not tunneled (when a VPN tunnel is active),  4) AT LEAST two phone ports, preferably four (if for no other reason than to make your device competitive with all the other two-line units),  5) Simpler QoS setup — build some default profiles for various situations, or better yet, let users assign QoS priorities on a per port basis (phone ports would default to high priority, LAN ports to medium priority, but each could be changed by the user with simple “radio button” selection),  6) A “greener” power supply — the “wall wart” you’re supplying with the AT-188N throws off too much waste heat,  7) And PLEASE, get someone who is a native English speaker to write or edit the English version of your manual (using proper grammar, spelling and punctuation!), and make sure you document ALL the settings on EVERY screen.

But even with whatever faults it may have, I think that any buyers of a single-line VoIP adapter (ATA) would be extremely happy with this device.  It truly delivers more value than you’d expect for such a low price. When the worst thing you can say about a unit is that the documentation could be improved (and how many other products suffer from the same problem nowadays?), that’s really not much of a criticism.

One other thing that surprises me is that the sort of people who like to hack routers and/or network storage devices, and install rewritten and improved firmware, haven’t discovered this unit.  When you consider all the energy that’s been put into modifying the firmware and then developing software packages for a device like the Linksys NSLU2, I’d have to think this device would be at least as attractive for that purpose.  Sure, it doesn’t have any USB ports, but it’s a network connected device, which means that potentially it could store anything too large to fit in RAM on a network-attached storage device.  Maybe the Atcom folks would not appreciate me mentioning the possibility that the firmware could be improved upon, but since the unit does have telnet access I have to think there’s a good chance it’s running some form of Linux “under the hood” — although I could be wrong about that — and I’m just a little bit shocked that those who enjoy digging into the internals of this type of device haven’t (yet) found the AG-188N attractive.

This is a device that really needs additional exposure among the VoIP community, which is one reason I wanted to review it.  Sometimes it’s hard to get “word of mouth” going on a new device, but in my opinion this one deserves it. It’s a great, well-built device in any case, but with the ability to use IAX protocol and to tunnel its SIP connections via L2TP, you have two ways to handle those tough situations where most other adapters will connect to your server, and you can make their phone ring, but you only get one-way audio (or even no-way audio in some cases).

I’m going to close this article, and this series, with the list of features and specifications for this unit, from CIGear’s web site, but with the caveat that they probably got this from the manufacturer and I don’t believe it’s 100% accurate (just one example: Both this list and the AG-188N manual say that “Reverse polarity” is supported. But there’s no setting to turn it on or off, and I can tell you that it doesn’t appear to be on by default). So if a particular feature is really important to you, look back through the the screenshots in the previous articles of this series and if you don’t see that feature mentioned, there’s a chance it might not be implemented. This is just another example of a disconnect between the documentation and the actual unit.

Features

Enterprise, small office and residential applications

Key features:
Support two sip servers running at the same time.
Redundancy sip server support.
Support T.38 fax function
Support IAX2 protocol
NAT, Firewall.
DHCP client and server.
Support PPPoE, (used for ADSL, cable modem connecting).
Support major G7.xxx CODEC.
VAD,CNG.
G.165 compliant 32ms echo cancellation
E.164 dial plan and customized dial rules
Support Lifeline.
Hotline.
Call Forward, Call Transfer, 3-way conference calls
Call ID display
DND(Do Not Disturb),Black List,Limit List
Reverse polarity
Voice prompt
Increase Vlan and automatically upgrade configuration file encryption function
support IAX2 and FAX
Increase the time zone function

Data Features
Static/Dynamic WAN IP Addressing
PPPoE

Management
Web, telnet and keypad management.
Adjustable user password and super password
Upgrade firmware through HTTP, FTP or TFTP.
Telnet remote management.
Upload/download setting file
Auto-provision.
Safe mode provide reliability

Interface
Two RJ45 ports, one for WAN, one LAN.
One RJ11 PSTN port for lifeline
One RJ11 FXS port for analog phone.

Data Networking:

MAC Address
TCP:Transmission Control Protocol
DHCP:Dynamic Host Configuration Protocol
PPPoE:PPP Protocol over Ethernet
SNTP, Simple Network Time Protocol
STUN – Simple Traversal of User Datagram …
MD5 Message-Digest Algorithm
DNS:Domain Name Server
RTP: Real-time Transport Protocol
RTCP:Real-time Control Protocol
Telnet:Internet’s remote login protocol
HTTP:Hyper Text Transfer protocol
FTP:File Transfer protocol
TFTP:Trivial File Transfer Protocol

Call control /voip Features
SIP RFC3261,RFC 2543
Tone generation and Local DTMF re-generation according with ITU-T
G.711(A-law or u-law)
G729
AGC(Auto Gain Control)
G.168/165 compliant 16ms echo cancellation
AEC(Auto Echo Cancellation)
VAD (Voice Activity Detection)
CNG(Comfort Noise Generation

Enviromental

Electric requirements
Voltage: 9V ~ 24V
Power adapter: output DC 12V/450 mA

Operating requirement
Operation temperature: 0 to 40° C ( 32° to 104°F)
Storage temperature: -30° to 65° C (-22° to 149°F)
Humidity: 10 to 90% no dew

Regulatory compliance
CE, FCC part 15

Thank you to the folks at CIGear for their patience in answering my questions as I wrote this series of articles!

Previous Installment | Next Installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

Comments (3)

Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 5 – Networking and Internal Router

In our previous installment we completed setting up the VoIP portion of the Atcom AG-188N (sold in North America by CIGear), touching on some of the other screens in the process. But there’s a whole other side of this great device that I have avoided touching on until today. If I were a TV infomercial pitchman, this might be the point where I’d take a dramatic pause and say, “You’d think there wouldn’t be anything more that we could pack into this small of a package — but wait, there is more —it’s ALSO a ROUTER!!!” And then the studio audience would applaud on cue!

And when I say router, I mean that it includes a DHCP server, NAT (port forwarding), QoS (Quality of Service), and even some limited VPN (Virtual Private Network) Tunneling support. Now, one reason I’ve sort of avoided talking about this is because of all the things I understand with regard to computing and VoIP, the area where my knowledge is weakest is networking.  The whole process of getting packets from point A to point B over the Internet is sort of a “black hole” for me.  And I’m not one of those reviewers that tries to convince you that I’m smarter than everybody else, and know everything about everything – if you’ve ever taken even one networking class, you’re probably way ahead of me.  So what I’m going to do here is show you the screenshots and tell you what I can, but if I make some wildly inaccurate statement, kindly let me know in the comments, okay?

In Part 2 of this series, I showed you the WAN configuration page.  Let’s take one more look at it:

Atcom AG-188N WAN configuration screen

Atcom AG-188N WAN configuration screen

As you see, you can enter static IP information, dynamically obtain an IP address, or use PPPoE.  Depending on which you choose, you may need to fill in additional information in the text boxes.  Most users will simply pick DHCP to obtain an address from an “upstream” router and be done with it — if you’re like me, you may not understand exactly how it works, you’re just glad it does. But, if you need or want to assign a static IP, or need to use a PPPoE server, you have that ability.  Most VoIP adapters will let you use DHCP or a static IP address, but I can’t recall seeing any others that offer PPPoE support.

As I mentioned in the previous article, the manual is silent on the usage of the “Mac Authenticating Code” field, but the most likely use is for “cloning” the Mac address of another router or computer, in the unlikely event that your ISP actually cares what you plug into their cable or DSL modem.

Now let’s look at the LAN configuration settings:

Atcom AG-188N LAN configuration screen

Atcom AG-188N LAN configuration screen

If you are sending this unit to someone in a remote location and you don’t know whether they are going to plug a computer, a switch, a router, or nothing at all into the LAN port of this device, the default settings are probably the safest – as long as whatever’s plugged into the LAN port gets its address using DHCP, it should work. Providers could send a unit to a customer, knowing that if the customer simply unplugs the network cable from the back of the computer and plugs it into this unit, then uses another network cable to go from this device to the computer, it will still work in most cases (provided they don’t swap the WAN and LAN port connections, anyway).

In the specific case where the WAN port of this device is connected to another router, it’s true that having two routers “stacked” may not be an optimum situation, since you are doing two levels of Network Address Translation (NAT) — therefore this configuration could interfere with certain services (perhaps ironically, one of the things that would be most likely to be affected adversely would be any SIP-based softphone client running on a computer behind the two levels of NAT). But for most typical end users, the defaults are probably the safest if you have no idea what they are going to do on their end.

However, for those who know what they are doing, you can tweak the settings for a more optimum configuration. The available settings are

  • Bridge Mode: You’d probably want to enable this if you know that the AG-188N will be connected to an “upstream” router, rather than directly to a cable or DSL modem.  When this is checked, the AG-188N will not assign IP addresses for devices connected to its LAN port — the AG-188N and any devices plugged into the LAN port will all be on the same network. This would avoid the “double NAT” problem mentioned above. Note that this setting will not take effect until you save the config and reboot the device.
  • IP: The base IP address for the local network. This is also the address that you can use to access the AG-188N configuration pages from devices connected to the LAN port. Normally it should always be in one of the “private” IP address ranges and should always end in .1.  In almost all situations it is safe to leave it at the default — the one exception is if the “upstream” network also uses the 192.168.10.x address range, in which case you might want to change the “10″ to some non-conflicting address. You almost certainly must change this if there is already an upstream device (such as an upstream router) using 192.168.10.1.
  • Netmask: If your IP is in the 192.168.x.x range then leave this at the default.  If you change the IP to something outside that range, I assume you know what needs to be used here.
  • DHCP Server: Enables DHCP service in LAN port. Leave this checked unless you are using “Bridge Mode”, or have a specific reason for turning it off (such as, ALL connected devices use a fixed IP address).
  • NAT: Enables Network Address Translation. Also leave this checked unless you are using “Bridge Mode.”

Note that it may not hurt anything to leave the DHCP Server and NAT enabled when using “Bridge Mode”, but I simply prefer to leave no doubt that we want the “upstream” router to handle these functions. I discovered that enabling “Bridge Mode” does not seem to totally disable the internal LAN, as evidenced by the fact that even though my computer received its IP address from the “upstream” router (in the 192.168.0.x range), I could still access the AG-188N’s web pages on either the 192.168.10.1 address, and that was true even if I disabled the DHCP Server and NAT.  So since I don’t know exactly how things are being handled internally, I just felt it best to tun off those services when running in “Bridge Mode.”

Now let’s look at the DHCP Service configuration page:

Atcom AG-188N DHCP Service configuration screen

Atcom AG-188N DHCP Service configuration screen

I didn’t change anything on this page, and I don’t advise that you do so either unless you know what you are doing. Note that by default, the DHCP server will assign addresses in the range 192.168.10.1 through 192.168.10.30 (with 192.168.10.1 normally being the AG-188N itself), so if you want to assign any device a fixed IP address you’re safe in assigning it anything from 192.168.10.31 through 192.168.10.254 (of course, you’d have to connect the LAN port to a switch in order to connect multiple devices). For the most part the settings seem pretty self-explanatory.  The one thing I didn’t fully understand is the setting for “Update Mode”, which has three choices: None, Update firmware, or Update config file.  I turned to the manual for enlightenment and this is what it had to say:

Update Mode: Using DHCP updated model, None expressed are not updated, Update firmware update firmware is used to DHCP. Update file is used to configure DHCP updated configuration files.

Um, okay then.  Seems like the default choice of “None” is probably right for most users. So, since there’s really nothing to see here (for most users, anyway), let’s move along to the NAT configuration page:

Atcom AG-188N NAT configuration page

Atcom AG-188N NAT configuration page

Again, I didn’t change anything on this page, and most users won’t need to either. The exception would be if you need to map a port to a particular device — this is where you’d do it. Just fill in the blanks for your new port mapping rule, click add, and you’re all set. Under “Transfer Type” your choices are TCP or UDP. Oh, and in case you’re wondering about the first three checkboxes, ALG apparently stands for Application-Level Gateway, and if you click on the link it will take you to a Wikipedia article on the subject.

The Net Service page lets you change certain default port settings used by the AG-188N, and shows you a table of all devices that currently have DHCP leases:

Atcom AG-188N Net Service and DHCP Lease Table screen

Atcom AG-188N Net Service and DHCP Lease Table screen

Most users will not want to change any of these, and I certainly would not advise doing so, but you can if you really want to. If you change the HTTP port and then forget what you changed it to, you probably will not be able to access the Web interface, so be careful here!

The next page we’ll look at is the QoS page:

Atcom AG-188N QoS configuration page

Atcom AG-188N QoS configuration page

QoS stands for “Quality of Service”, and is a method for giving certain packets priority over others. Of all the screens on this device, this is the one of the two that I comprehend the least, and I get the distinct impression that either the author of the manual didn’t fully understand it either, or else felt that anyone changing the parameters on this page would know what they were doing.  Here’s what it has to say about this screen (slightly edited to clean up obvious spelling/punctuation/syntax errors):

AG188 implements QoS based on 802.1p. The QoS is used to mark the network communication priority in the data link/MAC sub-layer.  AG188 will sort the packets using the QoS and send them to the destination.

  • VLAN Enable — Disable/Enable VLAN function
  • VLAN ID Check Enable – not defined by the manual
  • Voice/Data VLAN differentiated — what the manual has to say about this is borderline incomprehensible, but basically you have three choices Undifferentiated, Tag differentiated, and Data untagged. Here’s the actual, verbatim phrase from the manual: “undifferentiated for Date and voice VLAN is not distinction VLAN tag, Tag differentiated for Date and Voice VLAN is distinction VLAN tag, Date untagged for Date VLAN is distinction VLAN tag.”
  • DiffServ Enable — Disable/Enable Diffserv service
  • DiffServ Value — Configure the Diffserv parameter. The permissible range of values is: 0×28, 0×30, 0×38, 0×48, 0×50, 0×58, 0×68, 0×70, 0×78, 0×88, 0×90, 0×98, 0xb8.  The default is 0xb8, which stands for best fast transmission; 28-30 is guarantee for the transmission priority for the 1st rank, 48-58 is guarantee for the transmission priority for the 2nd rank, 68-78 is guarantee for the transmission priority for the 3rd rank, and 88-98 is guarantee for the transmission priority for the 4th rank.
  • Voice VLAN ID — configure the Voice/signaling VLAN ID
  • Data VLAN ID — Assign VLAN id for data stream.
  • Voice 802.1p Priority — Configure the priority of the voice packets in 802.1p protocol.
  • Data 802.1P Priority — Configure the priority of the data packets (non-voice/signaling data) in 802.1p protocol.

There’s also a separate section in the manual on VLAN implementation, which shows several screen captures that will hopefully aid you in setting this up.  Honestly, I’d welcome comments from anyone who can further enlighten me on the correct way to set this up. If you don’t use the LAN port, or if you are not pushing much data through the LAN port while on calls, it’s probably okay to leave this not enabled.  But if you do use the LAN port, and you experience voice breakups and other weirdness while you are on the phone, the best advice I can give you is to try the various sample configurations in the “VLAN implement” section of the manual. If anyone is an expert on QoS implementation, please leave a comment and help us understand the correct way to configure this!

There’s one more networking-related page to talk about, and it’s the other one that I have relatively little understanding of, although I’d definitely like to increase my knowledge.  Let’s look at the VPN Tunnel page:

Atcom AG-188N VPN Tunnel configuration screen

Atcom AG-188N VPN Tunnel configuration page

The AG-188N supports VPN (Virtual Private Network) tunneling using either UDP (apparently a custom format for one specific customer) or L2TP (without IPSec).  Unfortunately, it does not support other popular methods, such as IPSec, PPTP, or OpenVPN.  For those who may not understand why you’d want to use a VPN tunnel, I’m going to quote an excerpt from the Wikipedia article on VoIP VPN here, since it explains this far better than I could (just replace the reference to “IPSec” with “UDP or L2TP”):

A VoIP VPN combines Voice over IP and Virtual Private Network technologies to offer a method for delivering secure voice. Because VoIP transmits digitized voice as a stream of data, the VoIP VPN solution accomplishes voice encryption quite simply, applying standard data-encryption mechanisms inherently available in the collection of protocols used to implement a VPN.

The VoIP gateway-router first converts the analog voice signal to digital form, encapsulates the digitized voice within IP packets, then encrypts the digitized voice using IPSec, and finally routes the encrypted voice packets securely through a VPN tunnel. At the remote site, another VoIP router decodes the voice and converts the digital voice to an analog signal for delivery to the phone.

…..

Security is not the only reason to pass Voice over IP through a Virtual Private Network, however. Session Initiation Protocol, a commonly used VOIP protocol is notoriously difficult to pass through a firewall because it uses of random port numbers to establish connections. A VPN is one solution to avoid a firewall issue when configuring remote VoIP clients. The VPN virtually moves users inside the same network local as the VoIP server.

Edit: Unfortunately, it turns out that the AG-188N uses L2TP without IPSec, which means that the comments about voice encryption in the above excerpt aren’t applicable – L2TP alone does not offer any form of encryption. However, the final paragraph of the excerpt, talking about how a VPN tunnel could overcome difficulties with firewalls when SIP is used, would still be applicable.

Here’s the explanation of the settings on this page:

  • VPN IP — After the AG-188N has registered successfully on the VPN, the VPN server will assign an IP address to the device. If there is a IP address other than 0.0.0.0 shown here, it means that you are successfully registered on the VPN.
  • UDP  Tunnel and L2TP settings — These are obvious from the text field labels. Only fill in the settings for the protocol you plan to use (probably L2TP unless you can somehow reverse-engineer the UDP method).
  • UDP  Tunnel and L2TP radio buttons — Click the one corresponding to the type of tunnel you plan to use.
  • Enable VPN — Enable the VPN server — you must choose either UDP or L2TP type in advance.

Some of you may be wondering – if you set up a VPN tunnel, does all traffic get routed through it (including any traffic on the LAN port), or only VoIP traffic?  And, if only VoIP traffic, will it route both SIP and IAX protocols over the tunnel, or just one or the other?  And unfortunately, I simply don’t know the answer to that at this point.  I also don’t know how to set up a VPN using either UDP or L2TP on an Asterisk/FreePBX server, otherwise I might give this a go. If if any of the more popular forms of VPN tunneling were supported (such as IPSec, PPTP, or OpenVPN) I might be able to set those up and administer them using Webmin, but it appears that there are no Webmin modules available to help configure L2TP or UDP tunnels.

Edit: After receiving some clarification that this uses L2TP without IPSec, I Googled a bit and found a blog post entitled “Use Linux to Setup L2TP Server (without IPSec)” that appears to give server installation and configuration  instructions that should work under CentOS (the opening paragraph is in Chinese, but the actual steps are all in English, and if you’re curious about that opening paragraph you can always view the Google translation). However, I think I’d try using yum install l2tpd rather than using rpm in the first instruction; if that doesn’t work you can always try the rpm method. It looks like it should be a pretty simple installation, but I have not actually attempted it yet.

At this point, this may be my only real letdown with the AG-188N – I was enthused when I saw that it supported VPN, but that enthusiasm rather quickly deflated when I saw that it really didn’t support any of the more widely-used VPN protocols (Edit: and in particular, none that offer encryption). And granted, my disappointment may be in part based on my lack of proficiency in setting up a VPN server, or some other lack of understanding — feel free to enlighten me! — and in any case, my disappointment here is tempered by the knowledge that no other ATA’s (to the best of my knowledge) support any form of VPN tunneling. The vast majority of users of this device are probably not going to care whether it supports VPN or not, let alone which “flavors” of VPN, but it’s just something that had particular appeal to me.

This is a subject I’d obviously like to know more about — some readers may recall my post, New Products Wanted, part 1: Simple VPN devices (switches and/or routers) — so I welcome any comments that might help me set up one of the supported forms of tunneling, especially if there is a web-based GUI administration utility available (sorry, Linux gurus, I don’t share your affinity for config files and the command line).

There are a few other configuration pages on the AG-188N that I have not discussed separately, either because their purpose and usage is fairly self-evident (Clear Config, Backup Config, WEB Update — the latter lets you upload new firmware or restore backup configuration files) or are of interest primarily to service providers and other “system administrator” types (FTP/TFTP Update, Auto Provisioning).  If you really want to see screenshots of any of these, leave a comment and I’ll post them in a followup article.

In the next installment, I plan on wrapping up this series (for now, anyway) with some final thoughts and a summary review. I hope you’ve enjoyed this exploration of the AG-188N up to this point as much as I have!

Previous Installment | Next Installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

Leave a Comment

Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 4 – Setting up SIP, and securing the adapter

After yesterday’s installment we had pretty much configured the VoIP side of the Atcom AG-188N (sold in North America by CIGear) using the IAX protocol. Of course, even though IAX is the superior protocol for getting audio through difficult firewalls, there are still many reasons someone might need to use SIP — perhaps the most compelling reason being that many commercial VoIP providers only offer connections using SIP protocol.

Fortunately, setting up the SIP configuration on this unit is pretty straightforward. Just click on SIP Config (not SIP) in the left-hand menu, and this screen appears:

Atcom AG-188N SIP configuration screen

Atcom AG-188N SIP configuration screen

If you’re connecting to an Asterisk or FreePBX server, you probably only need to fill in the following:

  • Register Server Addr — this is the address of your server, such as 192.168.0.100 or myserver.dyndns.com
  • Register Server Port — the SIP port number of the server — note that while the default of 5060 is most common, there may be cases where a different port is used, so it pays to check.
  • Register Username — just use your extension number here, unless you are instructed otherwise.
  • Register Password — the same as the Asterisk “secret” for your extension.
  • Phone Number — your extension number (again).
  • Display Name — The name you want to appear in the other party’s Caller ID display if you ever do a direct SIP-to-SIP call.  FreePBX and most providers will ignore this, instead using the name associated with your account.
  • Enable Register – Always check this box, to enable SIP registration, if you plan to use SIP.
  • SIP(Default Protocol) — This sets the default protocol to SIP for outgoing calls. If you check this box, it automatically unchecks the box that makes IAX the default protocol on the IAX setup screen.

As long as you haven’t changed any of the default settings (as shown on the above screenshot), everything will very likely work.  You should try a test call and see if you can connect. If so, I then recommend that you try changing the Register Expire Time — the manual says the default on this is 600 seconds, but as you can see from the screenshot above, it’s actually set to 60 seconds, which means it re-registers once per minute, which may generate a lot of unnecessary traffic between you and the server. The manual also says that the AG-188N “will auto configure this expire time to the server recommended setting if it is different from the SIP server.”  Huh? In any case, I’d try setting the registration higher – you can try the 600 second default, but many adapters  go even higher (a 3600 second re-registration is not uncommon).  However, if you pick up the phone and find you don’t get dial tone sometimes, or if your callers get a congestion signal sometimes, you may need to go for a lower value.  I can tell you from personal experience that some users served by a DSL line might need a shorter re-registration interval.

Here’s what the other settings are for.  You probably won’t need to change any of these from the default, unless your system administrator or provider specifically tells you to do so:

  • Proxy Server Addr, Proxy Server Port, Proxy Username, Proxy Password — in almost all cases these will be the same as the equivalent Register values, and that’s what the AG-188N assumes if you leave these blank, so very few users would have any need to fill these in.
  • Domain Realm — if you leave this blank, the AG-188N will use the proxy server address as the SIP domain, which in most cases is fine.  However, if you are using a dotted IP address (such as 192.168.0.100) as the server address, and the server is misconfigured, you (very rarely) might need to put the server’s external address (such as myserver.dyndns.com) here.
  • Detect Interval Time — this is only applicable if you check the Auto Detect Server checkbox, in which case the AG-188N will try to detect whether the SIP server is available at the interval specified here. I had originally thought that perhaps, if  the server could not be detected (or the network connection was lost), the AG-188N would stop delivering dial tone.  But nooooo — in my testing it made absolutely no difference. What it actually does is let you use a second, “fallback” SIP account if your first account goes down!  See the note on the “Auto Detect server” checkbox below.
  • Encrypt Key — the manual is silent on this, but if the server supports encryption on SIP connections, then I would guess you’d put the key here.
  • DTMF Mode — with SIP connections you have three different ways of sending touch tones to the server: RFC2833, DTMF_RELAY (inband audio), and SIP info.  In most cases you’ll leave this at RFC2833, but in some cases, particular if you are having issues with distant systems not recognizing your touch tones, you may want to try a different method.  Inband audio should probably be your last choice, but I have seen cases where it’s the only thing that would work.  Note that the way the server is configured can also have an effect on how tones are passed – even if you send the tones inband, your server may be converting them to RFC2833 before sending them “upstream.”
  • Local SIP port — the local SIP registeration port, which defaults to 5060, which is almost always what you want to use.
  • RFC Protocol Edition — according to the manual, you would only need to set this to RFC 2543 if you are trying to communicate to devices (such as a CISCO 5300) using the SIP 1.0 protocol. The default is RFC 3261, and unless specifically instructed otherwise, that’s the setting you should use.
  • Server types in SIP config window

    AG-188N Server types in SIP configuration screen

  • Server Type — leave this on “common” unless you happen to be connecting to one of the “uncommon” servers shown in the dropdown (pictured at right).
  • User agent — much as your web browser sends a User Agent string to identify itself, VoiP adapters also send an identification string.  By default, the AG-188N sends the rather boring “Voip Phone 1.0″ but you can change that here, although about the only person who would ever see it is the system administrator of the system you’re connecting to.  While you could possibly put something more interesting in here (I’ll leave it to your imagination!), I wouldn’t advise it if the system administrator is not known to have any discernible sense of humor. :)

The AG-188N manual is mostly silent with regard to the checkboxes we’ve not already mentioned. In fact, it only mentions these three:

  • Enable Register — Enable or Disable SIP registration. The AG-188N won’t attempt to register with the SIP server if this isn’t checked, so leave it checked as long as you’re using SIP.
  • Auto Detect server — Okay, here’s how the manual describes this one: “co-work with Server Auto Swap and Detect Interval Time. Enable this option, AG-188N will periodically detect whether the public SIP server is available, if the server is unavailable, the AG-188N will switch to the back-up SIP sever, and continue detecting the public sip server. AG-188N will switch back to the primary SIP server if the server is available again.” Yes, folks, this device lets you use TWO sip accounts, and fallback to the second if the first goes down! Interestingly, although the manual makes reference to a “Server Auto Swap” checkbox, I’m sure not seeing it anyhere on this page.
  • Enable Via rport — checked by default, this configures support for RFC 3581.  If you really want to know, see this FAQ.  If you don’t, just leave it checked.

What about the other checkboxes? Here’s my best guesses, supplemented by additional information from Atcom manuals for some of their other products.  I’d leave all of these at the default setting unless you really know what you are doing:

  • Enable PRACK — read this — the phrase “Numerous implementation problems seen in the field” is enough to discourage me from checking this box! Another Atcom manual offers this: “enable the PRACK in SIP which is mainly used in special ring tone, recommend to keep the default setting.” Do you need any other reasons to avoid it?
  • Enable Keep Authentication — feel free to check this if you like, but the unit seems to stay registered without it. A manual for a different Atcom device says  that this enables “registration with authentication request to be sent to sever together”, while yet another Atcom manual says that it enables “registering signal together with the authentication information. If enable it, the server will confirm the registering and send back the confirmation massage directly instead of requesting the terminals to send authentication information if needed.”  Yeah, that clears it right up for me!
  • Signal Encrypt, RTP Encrypt — if your server supports encryption, and you have filled in the Encrypt Key field, you almost certainly need to check these to make it work.
  • Enable Session Timer — a session timer is a way to determine whether a call session is still active.  Apparently this “enables RFC4028 to refresh the SIP sessions”, according to another Atcom manual.
  • Answer With Single Codec — other Atcom manuals say, “only answer the call with a certain Codec.” My best guess here would be that this will only use your “preferred” codec when answering a call. If the server doesn’t support your preference, you probably won’t receive any calls.

Now, above I mentioned that you can actually have two active SIP accounts on this device, in addition to an active IAX account, presumably in addition to having a landline plugged into the PSTN port.  I suppose that means that potentially, one phone could receive calls from, or place calls to as many as four different sources!  I doubt many people will actually use the device with more than one account, but it’s interesting nonetheless that this adapter has this capability!

I will note that things may not always work quite as you’d hope in a multi-account configuration.  I set it up so that there would be one SIP account and one IAX account active on the unit.  When I had an active call in progress on one account, I’d try calling the other and I always got a busy signal, even though call waiting is enabled. I had rather hoped that if you were using one account and a call came in on anther, it would activate call waiting, although since I am among those that would probably never have a reason to use this device with multiple accounts, that’s kind of a non-issue for me. Call waiting DOES work if another call comes in on the same account while you are on a call, and there may be situations where it would work across multiple accounts (I didn’t test with two SIP accounts, for example).

The manual seems to confirm my suspicions that IAX and SIP don’t work together as well as one might hope:

How many SIP servers may AG-188N register simultaneously?
AG-188N support 2 SIP servers and a IAX server. The Default server is SIP. If you want to use the IAX server you must set IAX as default protocol in the IAX config page. IAX and SIP can register simultaneously but not work simultaneously. If you set 2 SIP servers in the SIP setting page, you can choose the route (server) by dialing plan which is edited by you. Please see “How to use the dial rule?” for detail.

Before you get too perturbed by this, ask yourself how many other devices let you use multiple accounts from the same phone.  And if you’re wondering how you would select which account to use for a particular call when multiple accounts are available, that sort of thing is accomplished in the Dial-Peer screen, which we briefly covered yesterday.  You probably will need to read the manual to learn how to set it up.

You might be wondering how you’d set up that second SIP account. That’s accomplished by looking in the “Advance” section of the left-hand menu, and clicking on SIP.  When you do that you get this screen:

Atcom AG-188N Advanced SIP configuration screen

Atcom AG-188N Advanced SIP configuration screen

As you can see, it’s pretty much a duplicate of the other SIP configuration screen, but without as many settings, and with the word “Private” inserted into many of the description texts (not sure why they chose the word “Private” to describe the second account, but oh well).  Really, there are only five new settings here:

  • STUN Server Addr — If you use a STUN server, enter its address here
  • STUN Server Port — If you use a STUN server, enter the port number here. The default STUN server port is 3478.
  • STUN Effect Time — a different Atcom manual is far less confusing on this item: “STUN detect NAT type interval time. If NAT found a link inactive for a certain time, it will close the link so you need to send a packet within a interval time to keep the link alive.”
  • Enable URI Convert — convert # into %23 when sending URI (from a different Atcom manual, since it’s not in the one for the AG-188N).
  • Enable SIP Stun — A different Atcom manual sums this STUN stuff up nicely: SIP STUN is used for NAT transverse. When you config STUN server’s address and port (default 3478) and enable it, then you can use the normal SIP server to make the IP phone transverse NAT.

I will point out that more than likely, if you define a STUN server on this page, the AG-188N will be able to utilize it whether you are using the primary SIP account, or the “Private” account defined on this page. So it’s just slightly confusing that although at first glance this appears to be the settings for the second account, there are a few items here that could affect the ability of both accounts to penetrate NAT firewalls.

By the way, if you want to know more about STUN you can always try Wikipedia, and if you need to find a public STUN server, just Google public stun servers, and your desire should be met! That said, I’ve never had much luck trying to use a STUN server, and in most cases you won’t need to use one, which perhaps is why these settings were placed on this page.

If you’re starting to see that in many ways this device is more full-featured than some other VoIP adapters that are out there (and probably easier to configure), you can understand why I really like this unit – well, for the most part. And that brings me to the subject of security.

When you first access the unit, you have to login, and that’s to be expected. While some competing adapters don’t force you to use a username and password, they basically only have two accounts — user and admin.  The AG-188N has those (well, actually, guest and admin) by default, but you can add more.  If you click on “Account Management” in the left-hand menu, it brings you to the screen shown below, minus the entry fields at the bottom — those only come up when you press Add, to add an account:

Atcom AG-188N Account configuration page

Atcom AG-188N Account configuration page

It’s probably obvious that this is also the page you’d go to if you wanted to change a user’s password, or to delete an account.

There are two user levels possible, Root and General. General users only get to see a limited subset of the pages: WAN Config, LAN Config, Audio Settings, WEB Update, FTP/TFTP Update, Auto Provisioning, and Logout & Reboot. I’m not sure why you’d need to add additional users, but you can. Anyway, it appears you have to set a User name and Password for all users.

And normally that would not be any problem at all, except that while writing this review I’ve had to go back into the interface several times to look at the configuration, and if I haven’t done anything in there for a few minutes it apparently logs me off, and then I’m forced to login all over again! While I suppose this is really a good thing — if you happen to leave your browser open to this device and then leave, some mischief-maker can’t come along half an hour later and start changing settings on you — it’s still kind of a pain when you are doing something like this.  Oh, well, I guess it really is a good thing!

For those that want extra security, you can go to the “MMI Filter” page and set a filter by address range:

Atcom AG-188N MMI Filter screen

Atcom AG-188N MMI Filter screen

When the MMI filter is enabled, only IP addresses between the start IP and the end IP can access the AG-188N. It’s a good dose of extra security, but be careful not to lock yourself out — and remember, if you ever take your adapter with you when you travel, whatever network you happen to land upon may not be using the same IP range as your home network.  So I don’t think I’d advise setting this if you travel a lot, but at least the AG-188N gives you the option, something that some other adapters do not.

What’s next?  Well, we haven’t even really touched on the networking functions in this unit. Stay tuned for the next installment!

Previous Installment | Next Installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

Leave a Comment

Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 3 – Setting the time and configuring outbound dialing

In yesterday’s installment of this review of the Atcom AG-188N (sold in North America by CIGear), I had mentioned that you could download the documentation from the manufacturer’s web site in .PDF format. Since then I have come to realize that the .doc files on the CD are actually a bit more complete – some options are covered there that are not covered in the PDF version. Perhaps someone at Atcom should make the effort to generate new online PDF files from the current documentation.

Also, today I found out that because I didn’t have the latest firmware, there are more CODEC options on the Audio Settings page than what I had pictured – you can now select up to five CODECs, in order of preference. I’ve uploaded an additional screenshot to yesterday’s article, so you can see what’s changed.

Yesterday, we pretty much covered IAX settings that would allow you to receive incoming calls on the AG-188N, but if you’d like the correct time to show on your CallerID display, you probably want to click on the Time Config selection in the left-hand menu, to access this page:

Atcom AG-188N Time configuration page

Atcom AG-188N Time configuration screen

This one is pretty self-explanatory, but note one thing: The time server must support Simple Network Time Protocol a.k.a. SNTP. Some time servers only support NTP. When I tried to use the time server on the Asterisk system, which does NTP only, I got no time information with my incoming calls.  However, when I went to the time server pool at ntp.org (specifically us.pool.ntp.org) it seemed to work fine, so apparently their time servers “speak” SNTP.  us.pool.ntp.org is a good time server choice if you’re in the U.S.A, while in Canada you’d probably want ca.pool.ntp.org, and if you’re someplace else you can start here and select your continent, then drill down until you find the time server for your country.

Then select your time zone, check “Daylight” if your area observes Daylight Savings Time, and check “select sntp” (if you don’t check that box, it expects that you will be entering the time manually using the lower section!), and Apply. The default timeout of 60 seconds is fine; that’s just how long the device will wait for the time server to respond before giving up.  There’s no real reason to use the Manual Timeset section, unless perhaps for some reason you are on a system that has no connection to the Internet (I suppose such “closed” systems must exist somewhere).

You may be wondering if the Daylight time rules are configurable.  Not from the Web interface, sorry.  Newer Linksys devices, in contrast, let you specify a daylight time change rule (which is a string format that’s clear as mud for many users, but at least they make it possible to install a rule for your area from the Web interface). I had originally thought there was no way to change the rule in the AG-188N, but then I discovered that if you click on “Backup Config” in the left-hand menu, you can save your configuration settings in a plain text file, and in that file there is a section in there that looks like this:

DayLight Shift Min :60
DayLight Start Mon :3
DayLight Start Week:5
DayLight Start Wday:0
DayLight Start Hour:2
DayLight Start Min :0
DayLight End Mon   :10
DayLight End Week  :5
DayLight End Wday  :0
DayLight End Hour  :2
DayLight End Min   :0

If you were to edit those values (using a text editor that does not change the line endings, please!) and then use “Web Update” to reload the configuration, you could change the Daylight time rules. While this is a bit of a pain, it’s probably actually easier to understand than the way Linksys does it.  If you need to know when Daylight time starts and ends in your part of the world you can consult Wikipedia, but in most of the United States and Canada, DST starts on the second Sunday of March and ends on the first Sunday of November. Wikipedia says that they don’t observe DST in China, so I have no idea whose DST rule is loaded into the AG-188N, but it sure doesn’t look like the one for the U.S.A. and Canada to me.  I’m guessing that the following values should be changed as follows (assuming that they are using “1″ based numbering on week and month):

DayLight Start Week:2
DayLight End Mon   :11
DayLight End Week  :1

If I’m wrong, I’ll bet I’m still closer than the original rule! Anyway, if you do feel brave enough to edit the configuration backup file, after you carefully make the edits, rename the backup file extension from .txt to .cfg before using “Web Update” to load it back in. I actually did it and it took the changes (confirmed by saving another backup), but I’m not suggesting anyone should do it – if you want to try it, you assume the risk that something may go wrong, not me!

Okay, with that out of the way, let’s move on to making outgoing calls. Right out of the box it’s possible to dial some numbers, but if you have ever configured a VoIP adapter in the past, you know there are tweaks that need to be made to accommodate local dialing patterns. For one thing, it you were to use the AG-188N to try dialing a feature code that starts with a “star” character (*), such as *43 for the echo test on a FreePBX box, you’d note that the moment you hit the * key it goes to a busy signal. One reason for that is that by default, the star code indicates that you want to access the PSTN line connected to the PSTN port on the device, instead of the IAX and/or SIP account(s) configured on the AG-188N. This allows one analog phone to use either IAX/SIP or the PSTN. But if you aren’t using the PSTN port, and you are using an account on an Asterisk server, you probably want to be able to dial “star” feature codes without the AG-188N intercepting them. In order to accomplish that, we must select “Dial-Peer” in the left-hand menu – yes, I know it looks like it’s not a link, but it is — trust me. Click on it, and you will see this:

Atcom AG-188N Dial-Peer configuration screen

Atcom AG-188N Dial-Peer configuration screen

By default, there is only one entry here, for *T — you should delete this rule entirely.  If you still want to be able to access a phone line plugged into the PSTN port on the device, you could create a new rule, such as **T (which would require two depressions of the * key to select the PSTN line) and use the same parameters as the original *T (in case you are wondering, no you can’t simply modify the existing rule, because when you click on “Modify” you can modify every field except the Number). By the way, the T with no digit after it is the same as T0 (T followed by a zero), which means that there is no delay once the pattern is matched.

You can think of the Dial-Peer page as a variation on speed dialing.  According to the AG-188N manual, here’s what can be accomplished on this page:

  • Replace, delete or add a prefix to the dialed number
  • Make a direct IP to IP call
  • Place the call to a different SIP server after dialing a prefix
  • Make PSTN calls using the Lifeline function (the rule I just had you delete or modify above)

If you need to do any of those things, make sure you read the section of the manual dealing with the Dial-Peer configuration page.

Now at this point you might pick up the phone and hit the star key, only to discover that you’re still getting a busy signal.  What’s going on? Well, it turns out that there’s one more place where an adjustment needs to be made. In the left-hand menu, select “Digital Map” – that should bring up this page:

Atcom AG-188N Digital Map configuration screen

Atcom AG-188N Digital Map configuration screen

“Digital Map” is a fancy way of saying “Dial Plan” – it’s the dial rules used to determine when a number that has been dialed is complete, and should be sent to the switch. Yes, they used the word “Prefix” in this section – I attribute it to someone picking the wrong English word when translating from Chinese.  Either “Pattern” or “Rule” would have probably been a more appropriate choice than “Prefix.”

You’ll note that there’s a rule for a single star (in Texas they’d call it a lone star). :D But, we don’t want the AG-188N to think that dialing is complete after we’ve only pressed the star key once, so using the dropdown and “Delete” key on the bottom line of the page, I deleted that rule. At that point, I had no dial rules at all.  I could dial any number, but there would be a five second delay after the last digit dialed before the call went through. Obviously, we don’t want a post-dial delay on calls if that can be avoided, so we should add some rules, or prefixes as they are called here. But first, we’d better know what we can place in the rules:

  • The digits 0-9 and the * character
  • A range of digits in square brackets [ ], for example it could be a range such as [1-4], or use comma to separate individual numbers, such as [1,3,5], or use a list such as [234].
  • x  is a “wildcard” character represents any one digit between 0~9
  • Tn if used, must be the last thing on a line, and represents the amount of time we will wait after a pattern is matched to see if the user will depress any additional digits. n can be any number of seconds in the range 0-9. If the n digit is omitted and T used by itself, it means the same as T0, which means there would be no wait at all after the last digit is dialed. However, it appears that either T0 or a T by itself may be redundant in this screen – when a pattern is fully matched it is assumed to be complete, and there would be no further delay unless Tn is used, when n is some non-zero value.

Now, for those used to constructing Dial Plans on a Linksys or Sipura device, the principle here is pretty much the same.  Just keep in mind that instead of using a bar character | to separate individual dial plan rules, here you add each separately, and it occupies its own line.  Also, instead of using the S (seconds) to indicate a wait delay, here we use T (time in seconds).

The manual gives some usage examples:

  • [1-8]xxx  All number from 1000 to 89999 will be sent immediately
  • 9xxxxxxx 8 digits numbers beginning with 9 will be sent immediately
  • 911   The number 911 will be sent immediately
  • 99xT4  3 digits numbers that begin with 99 will be sent after four seconds

So, let’s take a Dial Plan string that we might find on a Linksys or Sipura device in the USA or Canada, where local extensions are assigned numbers in the range 1000 through 1999 and it is desired to have seven digit dialing of calls with one’s own area code, and eleven digit dialing to all other area codes:

([3-9]11|1[01]xx|[2-9]xxxxxxS0|1[2-9]xx[2-9]xxxxxxS0|*xxS0|[*x].S4)

Here’s how each rule would be translated to a “Prefix” on the AG-188N:

  • [3-9]11 — [3-9]11 or [3-9]11T or [3-9]11T0
  • 1[01]xx — 1[01]xx or 1[01]xxT or 1[01]xxT0
  • [2-9]xxxxxxS0 — [2-9]xxxxxx or [2-9]xxxxxxT or [2-9]xxxxxxT0
  • 1[2-9]xx[2-9]xxxxxxS0 —1[2-9]xx[2-9]xxxxxx or 1[2-9]xx[2-9]xxxxxxT or 1[2-9]xx[2-9]xxxxxxT0
  • *xxS0 — *xx or *xxT or *xxT0
  • [*x].S4 — [*0-9].T4

As you can see, the most common patterns translate very easily.  But some things are questionable.  Note that last example – whereas a Linksys device allows [*x] to represent “any digit or the star key”, the Ag-188N seems to require the slightly more specific [*0-9].  But also, that rule contains a period (.) period character, which on a Linksys/Sipura device means “one or more of the preceeding character.”  Here it means any length pattern starting with * or 0-9, with any number of digits (possibly mixed with star key presses) following.  This type of rule (or something very similar) is commonly used as a “default” rule, to set a four second timeout for anything that doesn’t fit one of our other rules, such as international numbers. The problem here is that the AG-188N documentation makes absolutely no mention of the period character as having any significance in these settings, yet when I use it as I would on a Linksys/Sipura device, it appears to work in exactly the same manner.  Something they forgot to document, perhaps?

Of course, you could do away with that last pattern entirely and simply set a default timeout, as shown in the image above, but keep in mind, that controls your maximum interdigit delay during all normal dialing (though NOT the length of the initial dial tone).  If you pause to look at a number while dialing, you probably don’t want the device to time out on you too soon.  You might prefer to use a long default “Time Out” (something like 25 seconds), but then specify a shorter timeout for international calls, so instead of that final catch-all rule, you might use something a bit more specific, such as 011xxxxx.T4 (which would mean that once you’ve dialed 011 plus five additional digits, your interdigit timeout is reduced to four seconds.

Or, you could simply use a long “Time Out”, but then always hit the pound key # at the end of dialing any number that doesn’t match one of your patterns. That would work as long as the box for ‘End with “#”‘ is checked – when you check that box, it means that the # key signifies the end of the dialed number.

So, here’s an example of what this page might look like after you have converted the Linksys/Sipura Dial Plan string:

Atcom AG-188N Digital Map sample configuration

Atcom AG-188N Digital Map sample configuration

I know that there are a few things that can be done in a Linksys/Sipura Dial Plan that can’t be done on this page, but often those things can be done, just in a different way.  For example, if you need to do number translations (where you dial one number but the adapter sends something else), you can do that on the aforementioned Dial-Peer configuration page.  And if you want to set up “hotline” service, where the adapter connects to a particular number as soon as someone picks up the phone, that’s also possible, but you’d have to do it from the Call Service configuration page, which is worthy of note because of the capabilities it offers:

Atcom AG-188N Call Service configuration screen

Atcom AG-188N Call Service configuration screen

On this page you can set up the following:

  • Hotline: If you enter a number here, the  AG-188N will immediately dial that number after the phone is taken off-hook.
  • Call Forward: You can call forward on busy, no answer, or always.  In the case of “no answer”, be sure to set the timeout in the “No Answer Time(seconds)” field.
  • No Disturb: Usually known as “Do Not Disturb”, when enabled this option will refuse all incoming calls.
  • Ban Outgoing: Enable this to ban outgoing calls (useful if, for some reason, you want a phone to receive incoming calls only).
  • Enable Call Transfer: “If A is the AG-188N user, and B calls and talking with A through VoIP. A can press the Hook-Flash to hold the call with B, and then press * and then enter C’s number. B will be transferred to C and can talk with C.”  Note that Asterisk and FreePBX users might prefer to use Asterisk’s call transfer facilities.
  • Enable Three Way Call: According to the manual, only the SIP protocol supports this function — but don’t necessarily believe what the manual says (see below). “Assume A is the AG-188N user, and B calls and talking with A through VoIP. A can press Hook-Flash to hold the call with B, then enter C’s number to talk with C, and then press Hook-Flash again switch back to user B,  then A can press * to make 3-way conference calls.”
  • Enable Call Waiting: Enable/disable Call Waiting
  • Accept Any Call: If this option is disabled, the AG-188N will refuse the incoming call when the called number is different from AG-188N’s phone number.
  • No Answer Time: no answer call forward time setting.
  • P2P IP Prefix: Configure point to point calling. For example, if you want to call IP 192.168.1.119 Just define 192.168.1. here and you can dial #119 to make the point to point call with the IP phone of 192.168.1.119
  • Use Record Server: Configure the support of server recording, transferring all the recordings to the server.
  • Remote Record No: Configure the recording number – if you upload your recording to this account, you can login to this account to get your voice recording. I assume the idea here is that you have some internal number you can call that will simply begin recording everything it hears – this is certainly possible to set up on an Asterisk server.
  • Black List: incoming calls with these phone numbers will be refused.
  • Limit List: outgoing calls with these phone numbers will be refused. Although the documentation doesn’t say so, I tried using a pattern here (29x to ban calls to all extension 290-299) and it did work. I assume that’s true of the Black List also, which makes both of these settings much more useful.

Note than many of the above features can also be accomplished via FreePBX or Asterisk, using feature codes, but many folks might appreciate the ability to set certain features from a web page rather than having to remember and dial a particular feature code.  The only thing I changed on this page was that I enabled Call Transfer, Call Waiting, and Three Way Call (I left Accept Any Call checked as well).

The one thing that initially seemed to be a bit of a disappointment here was the inability to do three-way calling using IAX, according to the manual.  I had actually tried to use the feature anyway, failed, and had written a couple of paragraphs lamenting this limitation and suggesting a really crude workaround in Asterisk.  But then I took another look at the above description again, and realized that I had done it wrong. The way it works is, you have to call both parties (call the first, flash, and call the second – or – receive incoming call, flash and call second party) and then, when you are in a condition where you can flash back and forth between the two parties, press the * key — that last minor but crucial step is what makes all the difference.  I have no idea why the manual would say that only SIP supports this function, but I’m very happy to report that it’s just plain wrong on that point, at least according to my testing.

Call transfer is another function that doesn’t work exactly as it might on some other adapters — for example,  on a Linksys/Sipura, you simply flash and call the number you want to transfer the call to, then hang up (either while it is ringing, or after the recipient of the transferred call answers and you’ve had a chance to talk to them before handing over the call). With the AG-188N it’s strictly “blind” transfer — once you flash and then dial * plus the extension number (don’t forget the leading *), the call is immediately transferred.  Of course, FreePBX and Asterisk support both “blind” and “attended” transfers internally, so this probably isn’t a big deal if you’re using an Asterisk server (which you would be if you’re using IAX protocol). And I would guess that 95%+ of all transfers are “blind” transfers anyway, judging by calls where I’ve been the one transferred.

Do remember, if you have made any changes after reading this article, to save your configuration, so you don’t lose all your changes when you reboot.

In the next installment, I want to cover setting up a SIP account.  I’m expecting it will be pretty straightforward, but I’ll let you know once I actually do it.  Overall, I’m still very impressed with this unit.

And now a small bonus, for those that might want to know such things.  First of all, here’s a list of things you can do from the telephone handset, just by dialing certain codes:

  • #****# — reboot gateway
  • #*000# — clear settings (don’t do this unless you really need to!)
  • #*100# — set the IP type to static ip
  • #*101# — set IP type to DHCP
  • #*102# — set IP type to PPPoE
  • #*111# — say unit’s ip address (on WAN port)
  • #*222# — say phone number

The settings below need a reboot to take effect:

  • #*103# — change to bridge mode
  • #*104# — change to router mode
  • #*50192.168.1.117# — set WAN port IP address
  • #*51192.168.1.1# — set default gateway IP
  • #*52202.112.10.37# — set dns server
  • #*53255.255.255.0# — set netmask, use 255.255.255.0 if none given

In all of the above, the trailing # is optional, but speeds things up. In the last four examples, I would ASSUME that the star key * substitutes for the dot in the dotted IP addresses.

Also, this unit does have telnet access, or as the manual says, “User may use telnet command to access and manage gateway.” However, as I prefer to work within the GUI, I’ll stick with it. But I mention this because I know there’s a certain class of folks that love to get into the internals of a piece of equipment, and for those folks telnet access might be quite useful.

Previous Installment | Next Installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

Leave a Comment

Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 2 – Initial setup using IAX

In yesterday’s installment I explained why, in some cases, IAX is the superior protocol to use for VoIP calls.  Of course, having a superior protocol doesn’t count for much if the calls don’t sound good.  So, my first goal with the AG-188N (sold in North America by CIGear) was to try and get it up and running to the point that I could test the actual audio quality.

First, a clarification from yesterday’s post – I’ve been told that the unit I received had been previously used on a demo and therefore had been repackaged. Normally the power supply comes in a small white box, not wrapped in bubble wrap. Since I had specifically asked for a unit for review purposes, it doesn’t bother me at all that I received a unit that is new for all intents and purposes, but can’t be sold as new – that’s the perfect unit to send to a reviewer. :)

After unboxing the unit, I hooked it up to my local network, plugged a phone into the phone port, and connected the power supply and plugged it in. I picked up the phone and heard a distinctly foreign sounding dial tone (I later figured out it was a Chinese dial tone, probably since the unit is manufactured in China). I knew there had to be a web interface, but had no idea what IP address had been assigned to the unit. This is the point at which I might normally have referred to the manual, but there was no printed manual supplied. The only manual was on a small “mini CD” that came with the unit. Unfortunately, my primary computer is a Mac Mini, which has a front-loading DVD drive (where you shove the CD or DVD into a slot, and the Mac Mini sort of sucks it in). I had no idea if that drive could handle a “mini” CD, or if attempting to insert it would jam up the Mac Mini’s drive. Since I didn’t want to chance it, I took the expedient solution of firing up my old Windows box just long enough to read the CD and copy it to a shared drive, where I could peruse it on my Mac.

Mac Mini + Mini Disk? Nah, not gonna try it!

Mac Mini + Mini Disk? Nah, not gonna try it!

Unfortunately that hit a snag as well – the files on the CD are in .doc (Microsoft Word) format, not the more widely accepted PDF format. I never use .doc format – if I am writing a letter or something I use .rtf (Rich Text Format) which is far more universal. Nevertheless, to its credit, QuickLook on the Mac could display the .doc files (I might have installed a plugin to allow that at some point in the past), albeit in very tiny text. I later discovered that I could download the documentation in PDF format at the manufacturer’s web site, although it actually appears that the documentation on the disk is more complete in some sections.

The documentation revealed that in order to discover which IP address the device was occupying, I needed to pick up the phone and dial #*111#

After doing that, a very North American-sounding male voice read the IP address to me.  I entered that address into my web browser, and was greeted by a rather plain but functional Logon page:

Atcom AG-188N Logon screen

Atcom AG-188N Logon screen

Back to the .doc file, which revealed that the default logons are “admin/admin for administrator and guest/guest for user.” So I logged in as an administrator, and got this screen:

Atcom-AG-188N first screen after logon

Atcom AG-188N first screen after logon

Note that there is a left-hand sidebar and a main window. In the upcoming screenshots I’ll only be showing the main window, so let’s get a closer look at that sidebar now:

Atcom AG-188N sidebar

Atcom AG-188N sidebar

As you can see, this unit has many pages of options, but fortunately we don’t need to bother with most of them just to get the device working well enough to make a test call.

The first thing you will probably want to check is the WAN config page. By default, it looked like this (I have deliberately blurred portions of a few items that probably shouldn’t be shown):

AG-188N WAN configuration screen

Atcom AG-188N WAN configuration screen

For the majority of users, the main thing to check here is that it is using the DHCP server on your network to get its address – with the “DHCP” button selected and “Obtain DNS server automatically” checked, you can probably ignore the other text boxes. One thing the documentation is strangely silent on is the use of the “Mac Authenticating Code” field – I would ASSUME that’s so you can “clone” a Mac address, if you happen to be so unlucky as to be served by one of those providers that still actually cares what your router’s MAC address is, and you plan to plug the AG-188N directly into your cable or DSL modem rather than a router.

After that I decided to skip ahead a bit and get the IAX setup working. I clicked on “IAX2 Config” and the following screen came up:

Atcom AG-188N IAX2 configuration screen

Atcom AG-188N IAX2 configuration screen

This is super easy to set up. You only need edit the following fields for use with Asterisk or FreePBX:

  • IAX Server Addr – this is the address of your server, such as 192.168.0.100 or myserver.dyndns.com
  • IAX Server port – leave at 4569
  • Account Name – just use your extension number here
  • Account Password – the same as the Asterisk “secret” for your extension
  • Phone Number – your extension number (again)
  • Local Port – leave at 4569
  • Voice mail, Echo Test fields – just blank out all four (you dial codes like *43 or *98 to reach these in FreePBX)
  • Refresh Time – all the documentation says about this is that it is the “IAX refresh time” – I assume it’s how often the device re-registers with the server. I had originally thought 60 might be a bit too short of an interval, but when I tried a higher value I discovered that calls to the unit failed. So, my advice is, leave it at 60!
  • Enable Register – Always check this box, to enable IAX registration, if you plan to use IAX.
  • Enable G.729 – G.729 is a codec that saves bandwidth at the expense of audio fidelity.  Unless you are sure you need it and the server supports it, leave it unchecked.
  • IAX(Default protocol) – I checked this box, because I wanted to test IAX and don’t have SIP configured yet in any case.  By default, the AG-188N assumes you want SIP to be the default protocol; this changes that assumption

After you make the above changes, be sure to click the “Apply” button at the bottom.  That saves your changes, as long as the unit is not rebooted or powered down. So now I must bring up this important point:

IMPORTANT: After you make changes on any page, you must press the Apply button at the bottom of the page.  But then, after you have made all the changes you plan to make, in order to save them pernamently you MUST click on “Save Config” in the left-hand menu, after which you will see:

IMPORTANT! You MUST click this SAVE button to save your changes!

IMPORTANT! You MUST click this SAVE button to save your changes!

CLICK THE SAVE BUTTON!!! If you forget this step, you get to enter all your changes again after the next reboot of the unit!

At this point, I tried making a test call to the unit.  The phone rang (a short ring by North American standards) but it was perfectly usable, although to my ear the receiver volume was low (people on the other end could hear me just fine, but I had a bit of trouble hearing them).  But I quickly found the fix for those things.  Click on “Audio Settings” in the left-hand menu and you will see this screen (if you have the older firmware — the newer firmware has additional CODEC options, as explained below):

Atcom AG-188N Audio configuration screen

Atcom AG-188N Audio configuration screen

As you can see, unless you happen to live in China there are probably a few things you’ll want to change there! So I started by changing these:

  • CODEC – This is the codec you “prefer” to use – in the U.S.A. and Canada you’ll almost certainly want to use g711Ulaw64k (note Ulaw, not Alaw) unless you have a severe limitation on available bandwidth. Your other choices are g711Alaw64k, g729, g726-32k, iLBC, and (if you have the newer firmware — see below) None. Also, in the newer firmware, there are five CODEC settings, allowing you to select up to five CODECs in order of preference.
  • Signal Standard – This controls things like Dial Tone and Ring Length.  Your choices are CHINA, USA, JAPAN, UK, ISRAEL, BRASIL (their spelling), TOPCOM, and AUSTRALIA.  I’m not sure what country TOPCOM is, but if you live there, you’re supported! :)   (Apparently, Topcom is a European communications company that must have their own signal standard.)
  • Input Volume – 0 seemed to work fine for me, but if your callers complain they can’t hear you, try bumping this a number or two.
  • Output Volume – I found 3 or 4 to be a comfortable setting.  Note that your preference here may in part depend on the phone you are using, but if you are having trouble hearing the people you are talking to (or if they come through too loud), this is the setting to tweak.

I didn’t touch any of the other settings on this page.  Remember to click “Apply”, and then don’t forget to save your configuration! EDIT: After originally posting this article, I was informed that there are now additional CODEC settings on the page that are in the newest firmware, so I went and grabbed that firmware from Atcom’s web site, uploaded it, and this is what the page looks like after configuration and with the additional CODEC settings:

Atcom AG-188N DSP configuration screen - updated firmware

Atcom AG-188N Audio configuration screen - updated firmware

Now I could receive incoming calls, and I could place some outgoing calls.  I say “some” because I still needed to make some adjustments for dialing out (those will be covered next).

So, how did it work? Wonderfully! Calls are at least as clear as any other adapter I’ve used.  I have a friend who calls me frequently, and he just happened to call while I was setting this up, so when I got it configured I transferred his call to this adapter and he said that I sounded better than on the original connection (which was another phone that’s connected to a Linksys PAP2).  On my end, once I had turned up the volume a bit as shown above, he sounded great as well – certainly as good as any other VoIP or landline connection I’ve ever used, and perhaps even a bit better. My friend also said that he didn’t notice the little bit of echo “tail” that he occasionally hears from my end when we use the other phone and adapter – granted, that may be a configuration issue on the PAP2, but it’s worth noting that this unit seems to be performing better in that regard right out of the box. I would certainly have no reservations about recommending this unit to someone based on audio quality.

So you may be asking, have I found anything not to like so far?  Well, only one very minor thing, maybe.  The “wall wart” power supply that comes with the unit has the following specifications:

  • Input:  100-240V~50-60 Hz 0.18A
  • Output: 12 volts – 0.5 A
  • Has FCC and UL certifications

It’s a rather small unit, typical of a “wall wart” except for one thing – when connected to the AG-188N and plugged in, it gets a little bit warmer than I’d expect – sometimes.  Yesterday, it seemed to be running a little warm, not “burn your hand” warm or anything like that, but definitely the warmest of the dozen or so “wall warts” in my immediate vicinity.  I then unplugged it overnight, and after reconnecting it this morning (and leaving it plugged into the wall but not connected to the adapter for an hour or so, during which time it ran cool as a cucumber), today it seems to be only about as warm as some of the others, maybe even not quite as warm as a couple of them.  So what changed – my sense of touch, or did the actual amount of heat produced decrease?  Is the AG-188N drawing less current today? Did the fact that I plugged it into a different outlet on my UPS make some difference? Was I just oversensitive to temperature last night? I dunno, and it may remain one of the mysteries of life.  :) Anyway, it’s not something I’m really concerned about.

Next up, we take on outbound dial plans, and maybe more… stay tuned!

Previous Installment | Next Installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

Leave a Comment

Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 1 – The unboxing

One of the problems often encountered with VoIP is the use of the SIP protocol, specifically when used between a VoIP adapter such as the venerable Linksys PAP2 (or something similar) and an Asterisk server. Everything works great until you try to deploy an adapter at a remote location and the user has some kind of funky NAT firewall that just doesn’t play well with SIP. If you have any doubts that this is a real issue, Google the phrase “one-way audio.”

The crux of the problem is that SIP uses a wide number of ports, and unless you get everything set up exactly so at both ends, you may find that although the VoiP adapter will register with the server, when you actually attempt to place a call it will go through but neither party will be able to hear the other, or more commonly, only one party will be able to hear the other.

It’s an especially frustrating problem for VoIP providers, because a certain number of customers — we don’t know how many, because it’s not the sort of statistic providers like to report — cancel their VoIP service because they just can’t get it working in the first place, and the one-way audio probably certainly must account for a not-insignificant percentage of those cancellations.

There is another protocol that Asterisk supports, called IAX (actually it’s now up to IAX2, but we’ll just call it IAX to keep things simple). It works quite well in “difficult” situations because it only uses ONE port for all information. Therefore, if you can see the device register on your Asterisk system, you know that you’re also going to get audio. Assuming you don’t have problems with excessive packet loss or something of that nature, an IAX connection will almost always work, even if the end user is behind some sort of funky router (or even a chain of routers). The main reason that IAX hasn’t been more widely used is that there has been a real lack of decent ATA’s that support IAX (also, I’ve heard some comments that it doesn’t “scale” well in very large installations, but unless you plan on competing with one of the large commercial VoIP providers, I wouldn’t worry about that). For a while, Digium (the company behind Asterisk) made a unit called the IAXy, but like much of the hardware that Digium sells it was priced just a tad on the high side, and everyone was looking for a less expensive solution, so SIP-based ATA’s have become the norm.

But that doesn’t mean that the need for a decent IAX-based adapter has gone away. Just about every Asterisk system administrator has run into one or two “tough cases” where SIP just wasn’t cutting it, and if they did manage to resolve the issue they probably acquired a few grey hairs in the process. If you are the administrator of an Asterisk system, perhaps you’d just like to be able to pre-configure an ATA before sending it to someone that’s doing some off-site work for you, and know that when they receive it they can plug it into whatever crappy old router they happen to have and it’s probably going to work — right out of the box, with no frustrating hours of “… try changing this setting …” as you burn up cell phone minutes.

Recently I became aware of the fact that there’s an adapter available that can communicate using both IAX and SIP, and it even has both a WAN and a LAN port so that if the end-user doesn’t even have a router, they can plug this unit into the cable or DSL modem, and then plug their computer into the LAN port on the adapter and both will work. I made arrangements to obtain a unit for review purposes, and in the coming days I plan to tell you more about this device. It’s called the Atcom AG-188N and it’s sold in North America by CIGear. Just to give you a small preview, here are a few “unboxing” pictures.  The small box below came inside a larger carton with all the requisite packing peanuts, but I’m not a “pro” at making these photos (a couple came out way too blurry to use) so I decided to just show you the interesting part:

Good things come in small packages

Good things come in small packages

Out of the carton

Out of the carton

Contents of the box, without the bubble wrap

Contents of the box, without the bubble wrap

Closeup of the AG-188N, sorry it's a bit blurry

Closeup of the AG-188N, sorry it's a bit blurry

The back side, showing the connections, from CIGear's web site.

The back side, showing the connections, from CIGear's web site.

EDIT: Since I first posted this review I’ve since found out that the particular unit I received had been previously used on a demo and therefore had been repackaged.  Normally the power supply comes in a small white box, not wrapped in bubble wrap. Since I had specifically asked for a unit for review purposes, it doesn’t bother me at all that I received a unit that is new for all intents and purposes, but can’t be sold as new – that’s the perfect unit to send to a reviewer.

Note that the yellow ruler doesn’t come with the unit, it’s just a 7″ ruler I had lying around that I put in the pictures to give you an idea of relative sizes. Actually, if you set this unit next to a Linksys PAP2 you’d be very hard-pressed to tell any difference in the size. One thing notably missing from the contents of the box: A network cable. If you were going to buy these in quantity to send out to users, you’d probably also want to obtain some some network cables in bulk, so you could throw a cable in with each shipment, because for every guy like me who’s somehow obtained a small surplus of them, there will always be the folks that only have ONE network cable to their name.

One thing you may notice in the last image above is that there is a phone port and a PSTN (telephone company line) port. Yes, that does mean that this is a single line unit.  But, don’t get the idea that because there is a PSTN port, that this is the full equivalent of something like a Sipura SPA-3000 or Linksys SPA-3102, because it isn’t — the PSTN port is a “passthru” port, allowing you to send some calls to the PSTN and others to your VoIP provider based on the pattern dialed, and letting you receive calls from both the PSTN and your VoIP provider without the need use two separate telephones. The difference between this and one of the aforementioned Linksys/Sipura boxes is that you can configure the Linksys/Sipura’s PSTN port to be a trunk on the Asterisk server (essentially an FXO port), and that particular functionality is not included with this unit.

EDIT:  The above paragraph was edited slightly after receiving some clarification from CIGear — they also offered this additional information: With one phone hooked to the ‘phone’ jack, you can dial a star code to access the PSTN line instead of the SIP/IAX configured on the ATA. So, one analog phone enables you to use either SIP/IAX or the PSTN. However, people using the ATA with Asterisk have a problem when they want to dial Asterisk * codes like *97 for voicemail (as the * takes you to PSTN). The solution is to delete the “lifeline *T” option from “Dial-Peer” menu (this gets a bit into configuration, which will be discused much more thoroughly in upcoming posts).

Of course, you don’t HAVE to connect a PSTN line to this unit, and you don’t HAVE to connect a computer to the LAN port — I have used it successfully tonight without doing either.  Ah, but I’m getting ahead of myself a bit – more on that in the next installment, after I’ve had some time to spend working with the unit and reading the documentation (yes, I did get it working mostly without referring to the documentation, so for those who hate wading through documentation, fear not — it’s really not difficult to set up)!

Next installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

Comments (1)

Why some open source projects die a slow and painful death

In the past week or so, I have just by chance (or maybe via Twitter) come across two different articles that have touched on the subject of Autism and Asperger syndrome:  One in Newsweek headlined Erasing Autism and one from a blog called “The Daily Beast” with the title, A Radical New Autism Theory.  You probably should read these, or at least the second one, as a background to what I’m about to say.

Asperger’s syndrome is sometimes described as high-level or high-functioning Autism.  People who have this syndrome tend to be intelligent – sometimes even moreso than the general population – but they are often not perceived as “normal” by the average person.  One of the problems that “Aspies” (a term I’ve seen used to describe those with Asperger’s – it’s easier to write, so I will use it here and hope it doesn’t have any “politically incorrect” connotations, but in any case it’s not in any way intended as a slur) have is that their intelligence sometimes allows them to compensate for their condition, but to such a degree that they overcompensate.  For example, if someone is too empathetic with the emotions of others, they may very well build walls that make them seem cold and distant.  It’s not that they’re trying to be aloof, it’s their way of shielding themselves from sensory input that would otherwise overwhelm them.

So what does this have to do with open source?  Well, quite simply, I believe that many of the people at the top of open source projects are Aspies. Most Aspies prefer to work with concepts, ideas, or numbers rather than people.  It’s almost the typical “nerd profile”, and I don’t mean that in a negative way either.  Aspies will throw a lot of energy, and a lot of themselves into a project.  And sad to say, many Aspies don’t have that much of a social life.  So while the others who are perhaps also interested in the project are off doing other things, perhaps going out with friends or spending time with their extended family, the Aspie may sit home working on code, and hanging out on various social networking sites and chat channels.

When one of the original developers of a project starts getting tired of it – perhaps starts to feel that the project is taking all his waking hours – that’s often when the Aspie will step in and assume a leadership position. For the Aspie, the benefit is they get to commit to a doing something they enjoy, and get some recognition for it.  For the original developer, he knows he’s putting the project in the hands of someone who is competent and who has usually already demonstrated that he has the time and inclination to follow through on the project, by his past participation.  Sounds like a win-win for everyone, right?  Well, yes, yes it is… as long as you’re not counting other interested parties, such as other developers, and users of the software.

The problem, put very simply, is that the Aspie at the head of the project finds himself in an expanded role that requires greater interaction with others – users, developers, module authors (if the project utilizes modules), documentation authors, and in some cases he may even be called on to make live appearances at various events related to the software.  And it’s not necessarily that he’ll shirk from doing these things – in fact he may relish some of them – it’s just that in some cases he may not be very good at it, and not even realize it.

The bane of Aspies is summed up by this descriptive phrase: “No social skills.”  It’s not that they don’t try, and it’s not that they can’t be coached to improve their people skills.  In the majority of cases, it’s not that an Aspie wants to offend anyone, it’s that they are totally unaware that they have done so.

Now, in any open source project, what you want is a lively community of several developers contributing to your core code, and many others contributing additional code, modules and add-ons.  And you want to make it as easy as possible for those people to interact with each other, in a friendly atmosphere.  You want them to feel that their contributions are valued and wanted.  And you want everyone to know what direction the project is going in – that is, what the project will look like in a year, or 3-5 years down the road.  In short, you want a sense of openness, communication, and a welcoming atmosphere.

Unfortunately, with an Aspie in charge, you often get just the opposite.  What typically happens is that the Aspie has a direction for the project in his own mind, but he never asks if anyone else agrees with his vision, and indeed, he may have never tried to communicate that vision to anyone else – it’s just not important to him that anyone else knows where he’s taking the project, as long as he knows.  The same problem exists with documentation:  You want to know what various bits of code do?  Don’t expect him to comment his code; he doesn’t see the need – it just never occurs to him that others might want to understand the code, or have any need to understand it. And the others who want to be involved in the project?  They are just a distraction to him.  They don’t understand the direction he’s taking (again, because he’s never communicated it effectively) so he feels most of their code will be useless after the next revision of the core software (of course, he never asks if anyone wants changes in the core software, or what changes they really need).

I want to emphasize that in cases like this, the Aspie is usually not trying to be evil. It’s just not in him to “get” the social aspects of the project.  So he leaves a lot of hurt feelings behind. People who would gladly and willingly contribute time, effort, and code to a project feel that their contributions aren’t appreciated.  I suspect that more than one project has been “forked” because someone really wanted to participate in the development project and was simply shut out by the person in charge.

This is why open source projects often die a slow and painful death.  And please understand that while I have characterized the person in charge in cases like this as probably having Asperger’s, the fact is that there are socially unskilled persons who do not have Asperger’s syndrome. My characterization here is not meant as a diagnoses of any particular individual; in this case I’m using “Aspie” to refer to a person in charge of an open source project who demonstrates the lack of social skills typical of someone with Asperger’s syndrome.

You may ask, “if Aspies are intelligent enough to compensate for their condition, can’t they learn to be more attentive to the needs of others?” And the answer is that of course they can (and many have, quite successfully), but there are several reasons they don’t.  The biggest is probably inertia – change is uncomfortable, and we humans often don’t like to change our way of thinking until we are backed into the proverbial wall.  But a bigger reason is what I call the “inner circle.”

As the saying goes, no man (no matter how socially unskilled) is an island.  The Aspie needs to feel a connection to other humans, perhaps as much as anyone else.  The difference is, average (I hate to use the word “normal”, because who defines “normal”?) human beings will have friends that agree with them most of the time and friends that don’t.  Many of us have friends that will tell us they think we are full of shit, but we still hang out with them and don’t take it personally.  The Aspie, on the other hand, finds dissent and disagreement very uncomfortable, so his circle of friends will tend to include people who agree with everything he says, or at least pretend to. Oh, there may be some disagreement over minor issues, but once the guy in charge makes a decision the discussion is over, and no one in his inner circle will seriously challenge his thinking.  Kingdoms have been lost because their leaders refuse to hear dissenting opinions, so it’s no wonder that some open source project leaders might go down the same path.

Pretty soon an “us against them” mentality develops – the Aspie in charge and his close followers (there may be as few as one or two) against all the others who just don’t understand where the project is going. So now, when someone questions a decision that the person in charge has made, his “followers” will jump to his defense.  It’s then a personal thing – decisions don’t get made based on what’s best for the project or what the users want, but rather on who proposed the idea under consideration. At this point, if we were talking about a country, we’d be describing a dictatorship, where one person makes all the major decisions, and the job of the inner circle is to agree and deflect criticism by whatever means are necessary.

Another issue that sometimes comes up is the lure of financial enrichment.  If you’ve followed along thus far, you may have realized that it’s not always easy for an Aspie to get employment.  If they can find someone who will hire them based on their knowledge and ability rather than their people skills, they may have it made.  But if they are struggling in that area, they may sign onto an open source project with an idea in the back of their mind that they can somehow make a living off of the project.  They may think about releasing a commercial version with added features, and then totally ignore contributions that might make those same features available for free in the original project.  They may hold training seminars, which may or may not be successful depending on how much participation they permit by others (particularly those outside that “inner circle”). They may charge a fee for custom code and additional support, which again might make them reluctant to approve contributed code that expand the capabilities of the original project.

When this situation occurs, users and developers (those outside the “inner circle”) alike start to get frustrated.  This is particularly true when obvious bugs are not fixed in a timely fashion (particularly when someone has actually submitted the patch code), or when requests for new capabilities seem to disappear into a black hole.  Or when flimsy excuses are made, such as “we can’t consider this module because it may not work in our next upcoming major release” (the one that will appear about the same time as Duke Nukem Forever).

The point of this post is not to point fingers at any particular developer and say, “Bad developer! You should step down and let someone else take over the project!” But if some developers were to recognize themselves in this description, it might be the first step toward breaking the cycle.  Open source projects should be open – there should not be one person making all the decisions and holding the keys to all the “inside knowledge” about how the software operates. How do you know if your project might be in trouble? Well, one tipoff is that people are developing modules and add-ons that fix known bugs, or expand the capabilities of the project in small but significant ways and not contributing back to the original project. If this only happens once in a while, it could just be a selfish coder that doesn’t want to share.  But if it happens with increasing frequency, it may mean that those who want to contribute feel that they may as well not bother, because their contributions will just be criticized and ignored.

I welcome comments on this post.  If you think I’ve hit the nail squarely on the head, tell me.  If you think I’m way off base, tell me that too. But one thing you should realize is that I do NOT mean to disparage everyone with Asperger’s syndrome – one reason being that, although I’ve never been formally diagnosed with the condition, I have a very strong suspicion that I might have it to some degree. I think that any honest person with Asperger’s will tell you that social interaction can be quite a challenge at times and unless someone points it out, a person with Asperger’s simply may not realize how they are coming across to others.  But once it’s pointed out, it’s what they do with that information that counts.

Leave a Comment

Why haven’t any commercial VoIP providers implemented Caller ID popup notifications?

Here’s an idea for any commercial VoIP provider that cares to implement it. When a call comes in, send a Caller ID popup to the subscriber, so if they are online, they can see who is calling on their computer screen.

But, how to send the popup?  Here are three possible suggestions:

1) Use your own Jabber server, and allow people to connect using any Jabber client.  Most multi-protocol instant messaging software allows connection to a Jabber server (Gtalk uses Jabber, so if the client can connect to Gtalk it can likely connect to any other Jabber server).

2) Get an account on a well-known IM service (such as AIM or Gtalk) and use that service to send IM’s to people existing accounts:  Advantage – you don’t have to run your own server.  Disadvantage – you’re not running your own server, so it isn’t under your control.

3) Send a networked Growl message.  Growl is a popup notification service originally developed for Mac OS X, but there is also a version of Growl for Windows. It’s already possible to do this under FreePBX, using the instructions under the “Alternate Method” on this page. I know that the method shown there may not exactly scale up for commercial use, but it certainly provides a starting point.  The one thing I do suggest, in any commercial application, is that the user be allowed (on the user portal) to specify a destination address, password, AND alternate Growl TCP and UDP ports – the reason being that if you have several users on the same local network, you may have to remap alternate Growl ports to the original Growl port on the destination machine. By default, Growl uses TCP port 23052 and UDP port 9887 for communication, but at the router the user could remap different TCP and UDP ports to go to different machines on a particular network.  Advantage – more secure than IM and you don’t need to run a Jabber server or depend on someone else’s service.  Disadvantage is it requires installation of Growl (most Mac users do this anyway, I think) and setting up the router to send incoming Growl notifications to the correct machine.

4) Develop another method to send the notifications and provide your own client.  But if you do that, please make sure that it will interface with Growl on the Mac, and not try to do its own popups (interfacing with Growl is very easy – if I can figure it out, I’m sure any competent programmer can).

I will also mention, my preferred format for a popup looks like this:

  • Caller Name (from Caller ID.  Strip any quote marks, please).
  • Caller Number (Please make it pretty, e.g. 1-800-555-1212 or 800-555-1212, not 18005551212 or 8005551212)
  • [for] Number called (e.g. for 234-567-8900 so you know which DID/line the call came in on)
  • 3:34 PM on Tuesday, May 19, 2009 (so you can look at it at a glance, even a few days later if you were out of town for the weekend, and know exactly when the call came in – assuming you set the notifications not to go away after a few seconds, which is possible with Growl. Please, no leading zeroes or abbreviations, make it look nice!).

Others may have different preferences, but that’s mine. The time, day and date is important to me, because it makes a difference if I know when when someone called. Depending on the person calling, do you give the same weight to a call placed at 2:00 AM as opposed to one at 10:00 AM, or 7:00 PM?

Oh, and even if your provider doesn’t do this, but uses a Linksys or Sipura adapter to provide your service, you may still be able to have the popups – see our post, BETA Perl script for Caller ID popups when using Linksys/Sipura devices.

Comments (2)

Michigan-based company does Asterisk installs

I got an e-mail today that read as follows:

Hello,

Is there any chance we could get listed on your blog?  We are a Michigan based VoIP startup specializing in Asterisk installs.  Any coverage you could provide would be greatly appreciated.

For more information please visit our website at: www.bitwaretech.com  and our blog at blog.bitwaretech.com

Great blog site by the way!

Thank You,


DJ Monroe
BitWare Technologies, LLC
(586) 350-7221
mailto:dj@bitwaretech.com
www.bitwaretech.com | www.von-supply.com

While this is not a commercial blog, I’m not above throwing a little business toward a Michigan company, provided that when I Google the company the first thing is see is not a bunch of complaints from disgruntled or “fired” customers.  I didn’t see anything negative about this company, and did see that they just celebrated their the start of their fifth year in business at the end of last month, which is significant for a company in this line of business.

If anyone else has a Michigan-based small business that does Asterisk and/or FreePBX installations that you’d like to plug, leave a comment on this post – I want to be fair to everybody.  But, be aware that if I’m the slightest bit suspicious I will probably Google your company, and if I see a bunch of negative comments from your customers (or other comments that lead me to think you’re not nice folks to deal with), I will likely edit your comment to include links to those comments! And remember, it’s my blog, so my decision about which comments stay and which comments might get edited (or deleted, if someone becomes abusive) is final – just saying that in case someone is under the mistaken impression that the First Amendment applies to a private blog. All I’m saying is, I really don’t want to help promote companies that don’t treat their customers right, but I do want to help those who still believe in good old-fashioned customer service!

Comments (1)

60 Minutes Australia: Mobile Phones Cause Cancer

If you use a cell phone frequently (or have kids that live on one), you really should watch these!

Leave a Comment

Older Posts »