Several months ago I wrote about the legal problems facing electronic ‘alternative currencies’ and the shuttering of one particularly sketchy operation — e-gold-based ‘meta-currency’ 1MDC.

Now it seems that the owners of E-Gold are facing stiff fines and possible prison time after pleading guilty to conspiracy to engage in money laundering and operating an unlicensed money-transmitting business, an indictment E-Gold’s founder once called “a farce.”

Basically, the Feds really didn’t like the core strength of E-Gold, which was that it provided a way to anonymously transfer funds without any sort of user verification. E-Gold didn’t make you prove who you were, and thus there wasn’t any prohibition on how many accounts you could have, which meant that there wasn’t a way to really bar someone from using the service — close down one account, and they could just open up a new one.

Unsurprisingly, the plea agreement includes a “comprehensive money-laundering-detection program that will require verified customer identification” — in short, an end to anonymous transfers.

Although E-Gold never amounted to much in the world of legitimate commerce, and it probably would be little missed by most people if it disappeared completely as a result of the changes, it’s unfortunate and sad to see yet another early-Internet dream — that of anonymous, untraceable electronic currency, immune to the whims of national law or taxation — go (dare I say it) down the tubes.

One of the things that’s frustrated me for a while in Emacs is working with diacritics (accented characters) and other international text. Although as a basically monolingual English-speaker I do most of my writing well within the low-ASCII range, every once in a while I find it necessary to reproduce an accented word or string of international text.

Although typing accented characters (and other Latin-1 symbols) is very easy on a Mac in a native editor like TextMate, I’d never spent the time to figure out how to do it in Emacs. However, since Emacs is sort of the least-common-denominator editor, I decided it would be worth figuring out; unlike OS-specific dead-key methods, the Emacs way should work anyplace Emacs is installed. (And I use Emacs regularly on Mac OS X, Windows, Linux, and NetBSD — although the latter two are usually only through SSH sessions.)

Anyway, actually entering accented characters and other basic non-ASCII characters is the easy part. The easiest way is to turn on ‘iso-accents-mode’ within Emacs, and then let it convert character sequences (like “-a for ä) to their Latin-1 equivalent.

The trickier part was getting them to display correctly. The first time I tried using iso-accents-mode, the non-ASCII characters were just displayed as question-mark (?) characters. I quickly traced this to a problem in Emacs, rather than in my terminal (by saving the file and then displaying it with cat, which showed the characters properly), and then with a little more research, to an issue with the “terminal-encoding” parameter.

Basically, Emacs’s “terminal encoding” controls what character set Emacs uses when displaying text (sending it to the terminal device that you’re using to interact with it). It’s distinct from the character set that the file is actually being interpreted using, and also possibly separate from the character set that’s used to interpret keyboard input.

Since I have a UTF-8 terminal (set using the “Window Settings” window, under the Terminal menu, in OS X’s Terminal.app), I set Emacs to use UTF-8 as its terminal encoding by adding the following to my .emacs file:

(set-terminal-coding-system 'utf-8)

With this done (both locally and on the remote systems I SSH into), I was able to see all the non-ASCII characters properly. In fact, not only were Latin-1 characters correctly displayed, but Unicode smartquotes and symbols were also correctly displayed for the first time.

The only issue I anticipate with this is that, when I do connect from a non-UTF-8 terminal (like Cygwin’s Win32 version of rxvt), I’m probably going to get garbage instead of Unicode. However, that’s not really the fault of Emacs, and it’s always possible to temporarily change the terminal encoding back to ASCII if necessary. I just want UTF-8 to be the default.

References:

• Information on permanently setting the terminal-coding-system came from this osdir thread.
• General information on Emacs terminal encoding came from the Emacs documentation, section 27.14, accessible here.
• Also handy is section 27.17 on “Undisplayable Characters”

I ran across a nice blog posting by Steven Frank’s while trolling through Reddit earlier today, and I thought he was right on: “Don’t Use FTP” is pretty good advice for just about anyone.

It’s not that FTP wasn’t a good idea when it was designed; it was nice, it worked, and it served us all well for many years. But it just hasn’t aged well. As Frank points out (see “Note 2” down towards the bottom), although there are many other protocols still in use that were created around the same time, most of them have been extensively updated since then. FTP hasn’t; the defining document for the protocol — insofar as one actually exists — is still RFC 959, written in 1985.

It’s a bit unfortunate that it’s been allowed to languish, because it does serve a need (which is why it’s still around, despite its insecurity and firewall-traversal issues and everything else): it’s a lingua franca for bulk file transfers between systems. It’s certainly better, in theory if not in practice, than abusing port 80 and HTTP for the same purpose. However, given that alternatives (SFTP in particular) exist, there’s really no excuse for using it in new installations or for interacting with a modern hosting environment. Any commercial provider that only offers FTP as a bulk-transfer option should be called publicly onto the carpet; that’s simply not acceptable practice in 2008.

I do most of my Usenet reading through an SSH session using the slrn newsreader, which in my opinion is one of the best around (better than gnus even, although I still use Emacs as an editor). One of the better things about it is its very flexible killfile system. In reality slrn doesn’t have a “killfile” per se, instead it has a “scorefile”, which allows you to apply numeric scores to articles based on regular expressions, killing them when they drop below a threshold.

Anyway, since it allows the use of regular expressions, it’s useful for filtering out “sporgery” and spam designed to defeat less-flexible filtering, like the MI5 Persecution nonsense.

Here’s a set of rules I set up for killing the latest batch of crap:

[*]
% Kill "MI-5 Persecution" crap
Score:: =-9999
   Subject: [A-Z][',-`. ]I[',-`. ]5[',-`. ]P
   From: MI5Victim

The first rule (the Subject: one) is designed for the latest batch, which have varied subject lines and randomly-generated From-addresses. The second rule (the From: one) is for catching the older batch of messages, which all used the same From-address and didn’t vary their headers as much. I keep the old rule around because I sometimes like to read groups where there isn’t much activity, and thus end up seeing them almost as often as I do the new ones.

It’s almost a certainty that the rules will have to be tweaked, or a new rule added, the next time a bunch of messages come out, if the spammer continues to ‘enhance’ the headers to defeat filtering. That is, of course, unless MI5 gets him first. But somehow I doubt we’re all that lucky.

The regexp used to catch the newer messages was taken from Wikipedia, and it seems to work fine, although I’ve been thinking of tweaking it a little more. Ideally I’d like to broaden it until there’s no possible permutations of the subject that wouldn’t get caught, regardless of letters placed in-between the message characters, or any similar-character replacements (e.g. replacing the letter “I” with “|”, or other similar L33T-type stuff).

I’ve only begun playing more seriously with slrn and its scoring features, so as I get a decent scorefile worked out, I’ll probably post some occasional updates, just in case somebody wants to use it as a starting point.

I was pleased to read today that Netflix has come to its collective senses and decided to save the “Profiles” feature. For those of you living under a rock, Profiles was a neat feature that Netflix offered, allowing you to essentially split your account into ‘sub-accounts’ each with their own queue and number of simultaneous movies. This was pretty nice if you had multiple people (say, family members, or you and a S.O.) sharing the same account.

Their elimination of the feature was ostensibly to simplify the website by removing a feature that few users actually took advantage of, but many felt it was done more to encourage the purchase of multiple accounts (which cost more than one account, even one with many movies at a time).

This is by any measurement a good thing. Netflix avoided doing something very stupid, and alienating its userbase (probably driving more than a few of them right into the arms of the competition, Blockbuster) by announcing its intentions, listening to the response, and then changing their tune when it became obvious they were about to shoot themselves in the foot. All good. This should be a lesson to others on how to craft policy that affects your users.

Unfortunately, they had already disabled access to the feature for most users, apparently in preparation for killing it outright. (Which is a bit of a drag for folks like me, who were holding out because they’d only heard of it as a result of the hubbub and didn’t want to try something that was on its way out.) But according to the official blog, the option to create new profiles will return in a couple of weeks. Here’s hoping.

Earlier this week I ran into a pesky issue when using slrn on a remote machine, inside Screen, over an SSH session, via rxvt, running under Cygwin on a WinXP box. The problem looked like this, and seems to be some sort of either character-encoding or display problem with non-ASCII characters used in slrn’s text-mode interface.

It’s an obnoxious problem because it rather seriously interferes with slrn’s thread-tree display, and because there are so many different layers involved, any of which could be to blame. Starting from the user and working backwards towards the source, there’s rxvt, SSH, Cygwin, Windows, Screen, slrn, and Linux, any of which could be causing it. (Although some are a lot more likely than others.)

The simplest and least elegant way to solve the problem is just to force slrn into pure-ASCII mode, by putting

set simulate_graphic_chars 1

into .slrnrc. However, that just seems wrong. VT100 box-drawing characters, which is all slrn seems to be using, aren’t exactly high-tech stuff — we’re talking about the very best of 1978, here. This isn’t Unicode or anything sexy; it’s just an alternate 7-bit character set triggered by “shifting in” and “shifting out” using escape sequences.

I think the problem is probably a termcap/terminfo issue, but I haven’t been able to get any results via any combination of terminfo settings that I’ve tried.

I’ve been pretty pleased with results of my experimental entry into the world of VoIP, because it had been working without a hitch. Up until tonight, anyway.

I noticed the problem when I went to call the new home VoIP number from my cellphone, and got a “Not available” message from Callcentric. I know immediately something was not right, because that shouldn’t ever happen (unless the power was out or Internet service was interrupted). When I got home I logged into the router’s configuration page, and discovered that the line was no longer registered with Callcentric’s servers.

I started off by fixing the obvious things, including network connections and a power cycle. I made sure I could ping Callcentric, so no problems there. The configuration on the ATA matched their website (plus, it had been working fine for a week), so hopefully no problems there. To rule out NAT issues, I put the ATA temporarily in the LAN DMZ. Still no dice.

Getting a little more desperate, I turned on the SPA-2102’s syslog feature, turned the debug verbosity up, and started tailing the output on my PC. The result was mildly enlightening:

 Jun 12 00:33:25 192.168.1.150 system request reboot
 Jun 12 00:33:25 192.168.1.150 fu:0:45af, 0038 043c 0445 0001
 Jun 12 00:33:25 192.168.1.150 fu:0:4605, 03e4 05b0 0001
 Jun 12 00:33:30 192.168.1.150 System started: ip@192.168.1.150, reboot reason:C4
 Jun 12 00:33:30 192.168.1.150 System started: ip@192.168.1.150, reboot reason:C4
 Jun 12 00:33:30 192.168.1.150   subnet mask:    255.255.255.0
 Jun 12 00:33:30 192.168.1.150   gateway ip:     192.168.1.1
 Jun 12 00:33:30 192.168.1.150   dns servers(2): 
 Jun 12 00:33:30 192.168.1.150 192.168.1.1 
 Jun 12 00:33:30 192.168.1.150 71.170.11.156 
 Jun 12 00:33:30 192.168.1.150 
 Jun 12 00:33:30 192.168.1.150 fu:0:4648, 03f6 0001
 Jun 12 00:33:30 192.168.1.150 RSE_DEBUG: reference domain:_sip._udp.callcentric.com
 Jun 12 00:33:30 192.168.1.150 [0]Reg Addr Change(0) 0:0->cc0bc017:5080
 Jun 12 00:33:30 192.168.1.150 [0]Reg Addr Change(0) 0:0->cc0bc017:5080
 Jun 12 00:33:38 192.168.1.150 IDBG: st-0
 Jun 12 00:33:38 192.168.1.150 fs:10648:10720:65536
 Jun 12 00:33:38 192.168.1.150 fls:af:1:0:0
 Jun 12 00:33:38 192.168.1.150 fbr:0:3000:3000:04605:0002:0001:3.3.6
 Jun 12 00:33:38 192.168.1.150 fhs:01:0:0001:upg:app:0:3.3.6
 Jun 12 00:33:38 192.168.1.150 fhs:02:0:0002:upg:app:1:3.3.6
 Jun 12 00:33:38 192.168.1.150 fhs:03:0:0003:upg:app:2:3.3.6
 Jun 12 00:33:39 192.168.1.150 fu:0:465a, 0003 0001
 Jun 12 00:34:02 192.168.1.150 RSE_DEBUG: getting alternate from domain:_sip._udp.callcentric.com
 Jun 12 00:34:02 192.168.1.150 [0]Reg Addr Change(0) cc0bc017:5080->cc0bc022:5080
 Jun 12 00:34:02 192.168.1.150 [0]Reg Addr Change(0) cc0bc017:5080->cc0bc022:5080
 Jun 12 00:34:34 192.168.1.150 RSE_DEBUG: getting alternate from domain:_sip._udp.callcentric.com
 Jun 12 00:34:34 192.168.1.150 [0]RegFail. Retry in 30

After that, there are just a lot of “unref domain” errors, repeated over and over every 30 seconds, as the 2102 tries to register and can’t. (Can we hear it for the guy at Linksys who got them to keep the remote logging feature?)

From this we can tell a few things. It looks like the 2102 is booting up, and then it’s looking for Callcentric’s SIP server, by querying the DNS SRV record. This is as it should be. However, for some reason it’s apparently not getting back the right server to use.

Just as a first shot to eliminate DNS issues, I changed out the DNS server values in the 2102 configuration (normally, I use my gateway/router, which lives at 192.168.1.1) with my ISP’s DNS servers. No improvement. Then, I decided to try pulling the SRV records manually, to see if there was an obvious misconfiguration on Callcentric’s part, or if they weren’t returning DNS SRVs.

Without getting into a whole sidetrack on how DNS SRV records work, the way to pull them is via dig. To get the server and port for SIP traffic carried on UDP for the Callcentric.com domain, you would run

 $ dig _sip._udp.callcentric.com SRV

 ; <<>> DiG 9.3.2 <<>> _sip._udp.callcentric.com SRV
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11397
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5

 ;; QUESTION SECTION:
 ;_sip._udp.callcentric.com.     IN      SRV

 ;; ANSWER SECTION:
 _sip._udp.callcentric.com. 1800 IN      SRV     5 5 5080 alpha4.callcentric.com.
 _sip._udp.callcentric.com. 1800 IN      SRV     5 5 5080 alpha2.callcentric.com.

This tells us that UDP SIP traffic should be directed to either alpha2.callcentric.com or alpha4.callcentric.com, both on port 5080. The servers have equal priority so either one can be used. Running a quick host alpha2.callcentric.com gives the A record for that server, which turns out to be 204.11.192.23.

What we’ve accomplished at this point is what the SPA-2102 is supposed to do every time it tries to register with Callcentric. Query the domain-level SRV record to get the particular server for SIP traffic, and then query that server’s record for its IP address, and then connect to it. We just did that, and now have an IP and port.

To see if that server worked, I put it into the SPA’s incoming and outgoing proxy fields, and turned “Use DNS SRV” off. Lo and behold, after I rebooted it, I was back online.

For the moment, anyway, things are working again. However, they’re not working the way they’re supposed to. If Callcentric decides to change its server’s IP address, I’ll no longer be able to connect. Ditto if that particular server gets overloaded. All the benefits of DNS are lost when you go this route. Therefore, it’s not really a satisfactory long-term solution.

I’ve opened a trouble ticket with Callcentric and will see what they say. Googling terms like “RSE_DEBUG” and “unref domain” produce some results — I’m apparently not the only person to have experienced this problem! — but no good solutions. It’s obviously a DNS problem, but who’s exactly to blame isn’t clear. I suspect Callcentric is going to blame either the ATA configuration or my LAN setup, and in their defense, their DNS records seem to be correct. However I can’t see how the problem can be misconfiguration when it worked well for more than a week. I suspect I’ll probably end up on the phone with Linksys eventually.

If I do figure out some sort of solution, or even a satisfactory explanation, I’ll be sure to post it. In the meantime, if anyone happens to come across this page because they’re experiencing the same problem, the only workaround I’ve found is to manually query the SIP server IP and put that into the 3102’s configuration. (And pray your VoIP provider’s IP address assignments are relatively stable.)

Any thoughts or suggestions are, as always, appreciated.

FOLLOWUP: I got a form response back from Callcentric noting that my device was registered again, and blaming the problem on my Internet connection. (Of course, it was back up because I put the IP address in directly.) However, when I went back to using DNS SRV, it seemed to work fine … which really annoys me, because if there’s one thing I hate more than stuff that doesn’t work, it’s a stuff that breaks unpredictably and for no reason.

After doing my due diligence, combing NewEgg and the greater Internet for more than a week, reading every blog review I could find, and even making a little comparison chart, I decided to take the plunge and ordered myself a VoIP ATA.

At the last minute, I passed up the favorite for most of my comparison, the PAP2-NA, ordering the slightly more full-featured SPA-2102 instead. Although it allegedly lists for $110, I picked it up from Telephony Depot for $58, with after shipping was the best deal I could find.

The 2102 arrived yesterday, and I got a chance to play around and set it up last night. Overall, the installation process went smoothly, although I did run into one significant hiccup. The 2102’s installation and setup documentation is sufficient if you’re planning on using it at the edge of your LAN, but if you want to have it inside the LAN, you’re mostly on your own. Furthermore, the paper documentation for the voice-prompt interface is flat-out wrong in several areas, giving incorrect values for options (a problem that I believe stems from a mismatch between the firmware revision on the box and the version the docs were written for).

After having to reset the box several times — it’s possible to get it into a basically un-configurable state by switching it into bridge mode, when combined with the poorly-document voice prompt — I began writing up notes on the ‘right’ order to change the 2102 from gateway to statically-addressed, internal mode.

To do it, you’ll need a laptop or other computer with an Ethernet port that you can disconnect from your home LAN. (You definitely don’t want to plug the 2102 into your LAN un-configured, since out of the box it acts as a DHCP server.)

SPA-2102 LAN Setup Notes - 2.27kB ASCII text

For reasons not really germane here, I ended up typing up a very long email a few days ago, basically comprising a very rough introduction to VoIP. It’s less of a “guide” than it is just a braindump, but I thought I’d toss it up online, let Google do its magic, and perhaps it would be helpful to someone.

It can be found here:
VoIP Infodump - 16kB ASCII text

One thing just leads to another around here. My search for a decent VoIP ATA (basically, an Ethernet to analog telephone interface box) led me to discover that I’m all out of ports on my current Ethernet switch that holds together my home-office network. Oops. Guess this VoIP project just got a little bigger.

It’s been a while since I’ve bought much home networking gear, and I was impressed when I fired up NewEgg to discover how far prices on Gigabit switches have fallen. But looking at the specs on them convinced me that not all are made equal — and some of them seem downright trashy. I’ve done battle in the past with crummy, low-quality “consumer” networking gear in the past, and swore never to buy hardware purely (or even mostly) based on price again.

My absolute requirements are:

• 8 ports
• Gigabit Ethernet (802.3ab) on all ports and uplink
• Jumbo frames (>9000B payload)

The major ‘nice to haves’ in a new switch are:

• 12+ ports
• Support for Spanning Tree Protocol
• VLAN
• Link aggregation
• 802.1p ‘Priority Queuing’
• Power Over Ethernet (PoE) injection

My requirements aren’t that stringent — pretty much any run-of-the-mill 8-port switch satisfies them — so really it’s an exercise in balancing cost against which of the ‘nice to haves’ I can get.

• Rosewill RC-410

  • $50 from NewEgg
  • 8 ports
  • Jumbo frames
  • “802.1p flow control” (means priority tagging?)
  • 802.3ad - Link aggregation
  • Limited QoS (per-port QoS bit flagging?)
  • Rosewill seems to be NewEgg’s house brand. It got mostly positive reviews, with the main complaints being about the heat, and that there’s no 12 or 16-port version available.

• Netgear GS108

  • $55 after rebate from NewEgg
  • 8 ports
  • Jumbo frames (9000B max.)
  • 802.3x - Flow control
  • 802.1p - Priority tags
  • Steel case
  • Looks decent, one of Netgear’s “ProSafe” series. Doesn’t do link aggregation, though, and the price before rebate is $70. However, the higher-end Netgear kit has performed well for me in the past, so that’s something it has going for it.

• HP J9077A

  • $80 from NewEgg
  • 8 ports
  • Jumbo frames (9216B max.)
  • 802.3x - Flow control
  • 802.1p - Priority tags
  • Full specs on HP site
  • Starting to get into “real” networking gear, rather than the consumer/home-oriented stuff, here. Only downsides to this unit are the lack of VLAN and link aggregation. HP has a similar unit, the J9079A, which does both and a lot of other tricks besides, but only has 10/100 on the client ports and a GigE uplink.

• Netgear GS108T

  • $105 from NewEgg
  • 8 ports
  • Jumbo frames
  • 802.3x - Flow control
  • 802.1p - “Class of Service” (aka ‘Priority tags’)
  • Port-based VLAN
  • Port and DSCP-based QoS
  • 802.3ad - Link aggregation
  • LACP - Automatic link aggregation
  • 802.1w - Rapid Spanning Tree protocol
  • Now we’ve moved from unmanaged switches into “smart” switches, and we bought ourselves VLANs, QoS, LACP, RSTP, Syslog/SNMP support, port mirroring, and tons of other fun stuff. For what you get, this seems like a good price — the question is just whether it’s necessary.

• HP J9029A

  • $156
  • This one seems to take the J9077’s feature set and add to it many of the “smart switch” features in the Netgear above, including LACP aggregation, 802.1Q VLANs, and QoS. One major feature it doesn’t seem to support is RSTP/STP.

Decisions, decisions. The J9029A is pretty tempting, but it’s leaning distinctly towards overkill for a home LAN. However, I really like the idea of being able to set up VLANs at some point in the future; say, to take all the VoIP devices and put them on a separate VLAN and subnet, and then put that whole subnet behind a separate NAT router and give it a separate internet-facing IP address. (Obviously this would cost money and require purchasing a second public IP from Comcast.) I’m not sure if this will ever be necessary, but it seems like SIP+NAT is just a bad combination, and the glacial pace of IPv6 means it’s a problem that’s not going to go away any time soon. Being able to just segment off all the telephone stuff from data (and maybe making SAN stuff separate from that) seems like a nice feature.