Time to finally implement the home server I’ve been meaning to set up for a long time, I guess. At least that way I can run a radius server and do fun things with wireless authentication. And I guess I could do it under dd-wrt or openwrt now that I have extra hardware to play with…

1. Copy the nddtune script to somewhere appropriate for your environment and make sure it is executable.  By default, the SMF config expects to find it in /lib/svc/method.
2. Copy network-nddtune.xml to /var/svc/manifest/site.  Edit the XML config file if you put nddtune somewhere other than /lib/svc/method.
3. Import the manifest:

       # svccfg import /var/svc/manifest/site/network-nddtune.xml

4. Create property groups for the devices you wish to tune.  The property group is translated to the device passed to ndd by prepending a slash and converting underscores to slashes, so in this example dev_tcp will result in ‘ndd -set /dev/tcp …’:

       # svccfg -s nddtune addpg dev_tcp application

5. Set some parameters:

       # svccfg -s nddtune setprop dev_tcp/tcp_xmit_hiwat = integer: 4000000
       # svccfg -s nddtune setprop dev_tcp/tcp_recv_hiwat = integer: 4000000
       # svccfg -s nddtune setprop dev_tcp/tcp_max_buf = integer: 4000000
       # svccfg -s nddtune setprop dev_tcp/tcp_cwnd_max = integer: 4000000

6. Create an SMF snapshot that includes your new values:

       # svcadm refresh nddtune

7. Check your current values before enabling:

       % ndd -get /dev/tcp tcp_xmit_hiwat
       49152
       % ndd -get /dev/tcp tcp_recv_hiwat
       49152
       % ndd -get /dev/tcp tcp_max_buf
       1048576
       % ndd -get /dev/tcp tcp_cwnd_max
       1048576

8. Enable the service:

       # svcadm enable nddtune

9. Check the new values to make sure it worked:

       % ndd -get /dev/tcp tcp_xmit_hiwat
       4000000
       % ndd -get /dev/tcp tcp_recv_hiwat
       4000000
       % ndd -get /dev/tcp tcp_max_buf
       4000000
       % ndd -get /dev/tcp tcp_cwnd_max
       4000000

10. You can disable the service to reset the tunables to their previous values, since the previous values are stored whenever the service is enabled. These previous values are stored in an SMF property group named like the one(s) you created, but with ‘_defaults’ appended:

        % /usr/bin/svcprop -p dev_tcp_defaults nddtune
        dev_tcp_defaults/tcp_xmit_hiwat integer 49152
        dev_tcp_defaults/tcp_recv_hiwat integer 49152
        dev_tcp_defaults/tcp_max_buf integer 1048576
        dev_tcp_defaults/tcp_cwnd_max integer 1048576

You can get nddtune from its repository on bitbucket.

=(

Well, I should not have been so confident.

The first discovery upon booting up was that there were no wireless drivers present in the preinstalled Ubuntu 9.10 image. There were a few wireless card options when I configured the order, and I happened to select the Dell Wireless 1501 card, which is, in reality, a Broadcom 4313.  Interestingly, this choice is now gone and the only option available for orders today is the Wireless 1520 card.  Apparently, I chose the old option.  It was kind of impossible to tell which was better.

Thankfully, Linux drivers for this card exist, and they should’ve been available directly from Ubuntu via the bcmwl-kernel-source package, but for reasons I did not investigate very thoroughly, the wl kernel module would not detect the hardware (maybe an old version that doesn’t know the Dell hardware address?). Instead, I had to download the STA/wl driver directly from Broadcom and compile it by hand.

Next, I decided I wanted to try a pared down distro, rather than the flashy and featureful but potentially battery-sapping Ubuntu. So I installed the alpha version of Crunchbang Linux (now based directly on Debian (that’s good!)). Unfortunately, I discovered that the kernel version in Crunchbang was too old to support the ethernet port driver (that’s bad!). So, I quickly dumped Crunchbang and decided to install Debian Squeeze instead. After updating to the latest kernel from Sid, ethernet worked. Hooray!

With that sorted, I turned my attention to the mobile broadband card. It’s branded as a Dell Wireless 5620, but in reality it’s a Qualcomm GOBI 2000 (this much was apparent at purchase – it’s listed by the Qualcomm model rather than the Dell model in the configurator on the Dell Store).

After the wireless fiasco, I feared that there may be no drivers available for the Gobi card, and these fears were soon confirmed, as I could find none from either Dell or Qualcomm. In fact, upon entering my Dell Service Tag into support.dell.com, I discovered that my only OS choices for driver downloads were Windows 7 and Windows XP. Despite mine being the ‘n-series’ model that ships exclusively with Linux. Hmm…

The Gobi 2000 is unique among mobile broadband cards, and it’s one of the reasons I went with the Dell. It supports both GSM and CDMA, and I didn’t want to be locked to one or two providers. As I learned, it does this by loading carrier-specific firmware at boot-time. And I was encouraged to find that loading such firmware had been done under Linux before using gobi_loader. I applied the gobi_loader patches to the Sid kernel’s source and recompiled, but then thought better of running it. I had never tested the device under Ubuntu and started to wonder if it had already worked when the hardware shipped.

So at this point, I decided to reinstall Ubuntu, and found the reinstaller on Dell’s recovery partition. Unfortunately, this resulted in such a broken grub install that I couldn’t even load grub modules. After screwing with that for too long, I had had enough and installed Ubuntu Nebook Edition 10.04 (Lucid) from a USB drive.

Encouraged by findings on ThinkWiki where someone posted his experience extracting the firmware from Lenovo’s Windows driver for the Gobi, I downloaded Dell’s Windows drivers and unzipped the self-extracting .exe. Contained within were:

Utility/
Utility/Setup.exe
Utility/Models.zip
Drivers/
Drivers/XP/
Drivers/XP/x86/
Drivers/XP/x86/qcfilterdl2k.cat
Drivers/XP/x86/qcfilterdl2k.inf
Drivers/XP/x86/qcfilterdl2k.sys
Drivers/XP/x86/qcmdmdl2k.inf
Drivers/XP/x86/qcnetdl2k.inf
Drivers/XP/x86/qcserdl2k.inf
Drivers/XP/x86/qcusbnetdl2k.cat
Drivers/XP/x86/qcusbnetdl2k.sys
Drivers/XP/x86/qcusbserdl2k.cat
Drivers/XP/x86/qcusbserdl2k.sys
Drivers/XP/x64/
… (same as x86)
Drivers/Win7/
… (same as XP)

None of the driver files were the firmware. As seen on ThinkWiki, the Lenovo driver exracts the firmware with the correct name right on the filesystem, but apparently Dell’s were all contained in the installer, which was not a self-extracting .exe. I considered running the Lenovo firmware, but was worried that the firmware might differ by vendor, which could damage or brick the hardware. Probably not since it’s all Qualcomm, but generic providers like LSI do release rebrand-specific firmware for stuff like array disks.

So, I headed on over to an XP VM and extracted the driver, and tried to run the installer. No dice, you immediately get punted from the app, with the helpful message “Incompatible platform.” I suspected the Models.zip in the same folder contained the criteria of what it could be installed on, but annoyingly, it was password protected. Andy suggeseted that I run the installer from the command line with the /? flag, which was a great idea since it gave me a few options, one of which was /vEXTRACTDRIVERS. Well, I got excited for nothing, because all this option did was copy the already-extracted files from the Drivers/ directory to the current directory. Useless.

But eventually, after a lot more screwing around, I thought to run cabextract on the installer, and got a whole bunch of files with annoying generated names:

_062ABFE6150045B98BFE34CE46B105A9.AA6CA6091BA24C2D8E86939D9B2B7961
_0D8AF8E08A2A41BF9DF0E6369820073B.AA6CA6091BA24C2D8E86939D9B2B7961
_1399D3D2AB15428390AB9541D41069F9
_18D8D1860AC74D6C96798DB49BCBEE1B

After comparing the file sizes on these against the Lenovo drivers, I discovered that they must be the wayward firmware files! Tracking down which was which required using the Lenovo drivers. Since I was getting service with Verizon, I checked against the files in Lenovo’s “1” directory. amss.mbn and apps.mbn were easy:

% ls -l GOBI/Images/Lenovo/1
-rw-r--r-- 1 nate nate 6582324 Jun  3 09:19 amss.mbn
-rw-r--r-- 1 nate nate 3022892 Jun  3 09:19 apps.mbn
-rw-r--r-- 1 nate nate   17136 Jun  3 09:19 UQCN.mbn
% ls -l Utility | grep 6582324
-rw-r--r-- 1 nate nate  6582324 Apr 13  2009 _787710DE0BD94E448E3842AA0DFE048E
% ls -l Utility | grep 3022892
-rw-r--r-- 1 nate nate  3022892 Apr 13  2009 _BEC5B34A5031495589E922B092DAEB4F

UQCN.mbn was a problem:

%ls -l Utility | grep 17136
-rw-r--r-- 1 nate nate    17136 Nov  6  2009 _3211A3D6ECFF46B9935C71744C6F9129
-rw-r--r-- 1 nate nate    17136 Nov  6  2009 _7682FE3BC2AC49BE84D7167C0E55F4AC
-rw-r--r-- 1 nate nate    17136 Nov  6  2009 _9F7902055BCC477B942A596DB3283512

But thankfully, strings(1) provided the answer:

% strings GOBI/Images/Lenovo/1/UQCN.mbn > uqcn.strings
% strings Utility/_3211A3D6ECFF46B9935C71744C6F9129 > 3211.strings
% strings Utility/_7682FE3BC2AC49BE84D7167C0E55F4AC > 7682.strings
% strings Utility/_9F7902055BCC477B942A596DB3283512 > 9f79.strings
% diff uqcn.strings 3211.strings
… junk snipped
99c97
< 	02-c2k_vzw-00256-017
---
> 	02-c2k_vzw_nogps-00257-017
% diff uqcn.strings 7682.strings
… junk snipped
%diff uqcn.strings 9f79.strings
… junk snipped
99c95
< 	02-c2k_vzw-00256-017
---
> 	02-c2k_vzw_noxtra-00256-145

“nogps” would seem to be self-explanatory. I don’t know what “noxtra” is, but both the Lenovo UQCN.mbn and Dell _7682FE3BC2AC49BE84D7167C0E55F4AC had matching “ 02-c2k_vzw-00256-017” on that line of the `strings`, so I took that file to be UQCN.mbn. I can’t explain the other differences in strings output (the “junk”), but suppose it could be differing vendor IDs or a newer firmware version (although it’d be surprising that the file sizes matched, then).

Regardless, I put the following files in /lib/firmware/gobi:

_787710DE0BD94E448E3842AA0DFE048E → amss.mbn

_BEC5B34A5031495589E922B092DAEB4F → apps.mbn

_7682FE3BC2AC49BE84D7167C0E55F4AC → UQCN.mbn

Then, using the steps from response #33 in this bug in Launchpad, I rebuilt the qcserial and option kernel modules, and built the new usb_wwan one. Upon module installation, gobi_loader installation, and a reboot, the device finally existed, and was even recognized by NetworkManager!

Alas, my woes were far from over.

One annoying feature of CDMA networks is that since there is no SIM to register, the device itself must be registered, and this cannot be done by the provider, it must be initiated on the device itself. This is easy with a phone. You dial *228, hit option 1 and a few minutes later you’re provisioned. There’s also a quick way, by dialing *22899, and then you’ll be provisioned without prompting.

But how do I dial *228? It turns out, mobile broadband modems are just modems – initiate a serial connection and you send it AT commands just like the old 300 baud. But unfortunately, nothing I tried worked. As I eventually figured out, I think this is supposed to be the way, but my modem just returned ‘ERROR’ to the service programming command (AT+WSPC), despite getting the correct code from Verizon:

AT+WSPC=1,Your Verizon ESID (000000 if you’re lucky)
AT+WMDN=Your Verizon MDM number (usually your phone number)
AT+WCMT=1

AT+WSPC=1,ESID
AT+WIMI=31000Your Verizon MIN number (usually your phone number)
AT+WCMT=1
ATD*22899;

As far as I know, no one has ever activated a device on Verizon under Linux, except perhaps back when there was a Verizon Access Manager (VZAM), their official dialer, for Linux. If they have, they’ve never written how they did it. If you have done it, please comment and tell us how. Regardless, right now, my modem works. How did I do this, if I couldn’t get it to provision?

First, I tried running VZAM under a Windows VM via VirtualBox. The Dell driver would not install because “Incompatible platform.”

Next, I tried running the Dell driver installer under BartPE. “Incompatible platform.”

Finally, I just gave up and installed XP natively. Success. After doing this, I was able to reinstall Ubuntu and use the modem. Yes, I had to install Windows to run one crappy Windows app to do the activation, and then I was free to get rid of it. I’d really like to know what that Verizon app did. But whatever, it works now.

One final note: throughout all of this, I communicated with Dell and Verizon a bunch of times. My first call to Dell looking for drivers got me routed over to the (overseas…) Dell Ubuntu support group, who told me to post on ubuntuforums.org and “someone will post the drivers,” despite my insistence that such drivers did not exist freely. Qualcomm does not directly release them – all vendors selling Gobi cards release their own drivers, and the above proves that Dell has the firmware.

This was not a very acceptable answer for someone I’m paying money to for support. It’s not like I expect everything should work as easily under Linux as it does under Windows, but I want a better answer than “gee, that’s too bad.” If you’re a hardware vendor selling a Linux model of a system, it should at least work, even if I have to do some work to make it work.

Surprisingly, the people at Verizon seemed to understand my issue, but couldn’t help. They punted me back to Dell’s Ubuntu group, and I hung up before it connected.

Finally, I got my case escalated and the Dell escalation engineer knew exactly what the problem was. He was very sympathetic and told me that the Gobi card being orderable with Linux is a mistake, and should be removed from the store configurator. He couldn’t help, although by that point, I didn’t need it. He did say if I needed it, he might’ve been able to round up the firmware for me, which was encouraging to hear. It’s a shame they don’t just stick it up on the drivers site in a plain archive with a README explaining which firmware maps to which provider, but perhaps this is due to some sort of legal situation with Qualcomm. I don’t know.

In order to notify our Buildbot of changes in our source repository at Bitbucket, we’ve been manually pulling from Bitbucket to a repo on a development system here.  The local repo had a changegroup hook that utilized the standard buildbot.changes.hgbuildbot hook.  This worked fine, but it was tedious, so I decided to work on making Bitbucket trigger Buildbot itself.  Bitbucket offers various services that can run on commit, but no direct Buildbot notification.  But, they have a generic POST service that’ll send a specially formatted payload to an HTTP address of your choosing.  I did a quick Google to see if anyone had already written a connector.  Finding nothing and figuring it’d be an easy task, I set about writing my own.

The result is bb2bb, which (in its original form) was a FastCGI daemon serving a WSGI application (since nginx and flup make that setup easy) that reused a bunch of code from hgbuildbot.  I also employed some modules I’d used before (like WebOb), and it came together after most of a day of work and testing.   Unfortunately, after I put it in production I found a problem: after 2 successful commits and subsequent buildbot change notifications, the application would stop sending notifications.

Until this point, I had been blissfully ignoring the inner workings of Twisted since it’s a bit complex and I didn’t want to take the time to learn it when it only seemed vaguely necessary for what I was trying to do.  Unfortunately, I discovered that I couldn’t start and stop a Twisted reactor from within my WSGI application like I was trying to do.

Somewhere after a few hours of trying to wrap my head around Twisted so I could fix this, I happened to take a look at the list of files in Debian’s buildbot package and discovered the following:

% dpkg --listfiles buildbot                                                                                                                                                                                                                                          /usr/lib/python2.5/site-packages/buildbot
/.
/usr
/usr/share
/usr/share/buildbot
/usr/share/buildbot/contrib
/usr/share/buildbot/contrib/svnpoller.py
/usr/share/buildbot/contrib/bb_applet.py
/usr/share/buildbot/contrib/README.txt
/usr/share/buildbot/contrib/svn_watcher.py
/usr/share/buildbot/contrib/generate_changelog.py
/usr/share/buildbot/contrib/git_buildbot.py
/usr/share/buildbot/contrib/run_maxq.py
/usr/share/buildbot/contrib/fakechange.py
/usr/share/buildbot/contrib/hg_buildbot.py
/usr/share/buildbot/contrib/darcs_buildbot.py
/usr/share/buildbot/contrib/svn_buildbot.py
/usr/share/buildbot/contrib/bzr_buildbot.py
/usr/share/buildbot/contrib/arch_buildbot.py
/usr/share/buildbot/contrib/github_buildbot.py
/usr/share/buildbot/contrib/viewcvspoll.py

Hmm… a github to buildbot connector?  I checked it out and (no surprise) it does for github exactly what I was trying to do with Bitbucket.  So I spent another hour integrating my existing code (in the process, removing all those things that I didn’t need (like flup and WebOb) because I learned that Twisted already has the functionality) and an hour testing it.  Once it was all working, I went to modify setup.py to reflect all these changes and I decided to change the name to bitbucket_buildbot.py to match the stuff already in contrib.  At this point it struck me to Google that name.

ARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGH.

Someone had already done exactly what I just spent all this time doing, and it was committed in Buildbot’s contrib/ directory.  It wasn’t in my buildbot package since my version was older.  It, like mine, is even based on github_buildbot.py.

So I just spent almost 2 days doing something that’d already been done because I didn’t look in the right place with the right name.  Oh well, it’ll sit there on Bitbucket as a monument to wasted effort. =P

The White Loop extension received a proposed $23,000 allocation

This is the “drunk bus,” the extended hours for the White Loop during prime partying hours.  This was passed with the “we can’t stop students from going out and partying so we need to make sure they can do so safely!” argument.

The committee requested $6,000 to fund exploration into the use of the “MyMap” program, a potential replacement for eLion.

The UPUA shouldn’t be spending the students’ own money on this.  We already pay AIS (more than you can imagine) to research/develop/deploy/maintain this service.  If it’s not meeting the students’ needs (which it hasn’t for a very long time), it should be replaced.  By AIS.

So a friend of mine recently offered to sell me a coveted “euroswitch” for my ’03 Passat.  The stock light switch for the American market has three positions: off, on, and on + fog lights.  The euro switch, however, has: off, parking, parking + fog, on, and on+ fog.  Plus it has additional positions for turning on the rear fog light (which I would need to wire, but at least now I’ll have the switch for it).  My experience with cars made since at least the mid-90s is that you cannot operate the fog lights independent of the low beams.  If the fog lights are on, the low beams must also be on.  This switch removes that limitation, leading me to believe that the reason for said limitation is due to legislation.  Which brings us to the topic of this post: my friend and I sought to discover whether it was truly a legal issue by trying to consult the laws.

Of course, he took a reasonable course of action, starting at the Pennsylvania DMV website, locating the PA Vehicle Code (Title 75), and then proceeding to search through there.  I also looked, but just googled for the information, and landed at Transportation (Title 67) instead.  Both titles seemed to address lighting codes but contained different information.  And beyond that, the PA Code didn’t contain a Title 75, and in other places I found, Title 67 wasn’t Transportation at all!  After quite a bit of confusion, here’s what I learned (disclaimer: I AM NOT A LAWYER (IANAL), and this may still all be wrong):

The two sources of rules/regulations/laws are: The Pennsylvania Code (officially published by Fry Communications, available unofficially via their site, pacode.com) and Pennsylvania Consolidated Statutes (officially published by the PA Legislative Reference Bureau as the “Laws of Pennsylvania”, unofficially published by Westlaw as the “Purdon’s Pennsylvania Statutes Annotated“, available unofficially via their site, government.westlaw.com).  The Consolidated Statutes are the laws as passed by the legislature, signed by the Governor, and enacted.  The Pennsylvania Code is the rules and regulations as enacted by various agencies of the executive branch, as delegated to them by the language of the laws (thus the Code references its Authority from the PA C.S.).

So, if like me you’re asking “which of these apply when there seems to be a conflict,” the answer seems to be that they both do.  Although it probably seems like you could make a case that the Consolidated Statutes should trump the Code where they overlap, the reality is probably a complex legal situation in which lawyers would need to argue about the definition of the word “is.”

I put ‘em all into a Google Map.

Downtown

Ordered West to East:

Brewsky’s Bottle Shop (Beaver/Burrowes) – (814) 272-1074‎

222 W. Beaver Ave
State College, PA 16801

Zeno’s To Go/Take Six – (814) 237-4350 – zenospub.com

100 W College Ave
State College, PA 16801

The only place to buy Zeno’s Rye!  Also, if you actually go downstairs to Zeno’s, they sell obscure and interesting singles (to go) at the bar.

The Phyrst – (814) 238-1406 – the-phyrst.com

111 E Beaver Ave
State College, PA 16801

Upstairs, next door.

Brewsky’s Bottle Shop (Days Inn) – (814) 238-8454 – lioncountrylodging.com/daysinn‎

240 S Pugh St
State College, PA 16801

Thrifty Bottle Shop (Sharkies) – (814) 238-3566

110 Sowers St
State College, PA 16801

Sharkies has probably the best selection this side of Wegmans.

Kildare’s Irish Pub – (814) 272-0038

538 E College Ave
State College, PA 16801

Uptown (lol)

By “State College Cardinals” (where North is not North…)  And then ordered closest-to-downtown to furthest-away for each.

North

Champs Sports Bar & Grill – (814) 234-7700 – champssportsgrill.net

1611 N Atherton St
State College, PA 16803

All the way in the front of the restaurant, in case you get lost.

Hi-Way Pizza (North) – (814) 237-0375 – dantesinc.com

1688 N Atherton St
State College, PA 16803

If you can call it a bottle shop…  Two stand up coolers and nothing outside of the macros and maybe Sam Adams.

Jack’s Six Pack and Bottle Shop – (814) 238-8066

1669 N Atherton St
State College, PA 16803

Okay selection, but you might as well go to Wegmans, which has more and is cheaper.

Wegmans (Market Cafe) -  (814) 278-9040

345 Colonnade Way
State College, PA 16803

If there’s a better bottle shop in State College, I have not found it.  Best selection and best prices.

Otto’s Pub and Brewery – (814) 867-6886 – ottospubandbrewery.com

2235 N Atherton St
State College, PA 16803

Otto’s only sells their beer and Keewaydin cider, which is available at other bottle shops around town, too.

East

Olde New York – (814) 237-1582 – oldenewyork.net

2298 E College Ave
State College, PA 16801

Olde New York’s liquor license is still issued to Schnitzel’s, Inc.  Moment of silence, please.

South

CLOSED: Hi-Way Pizza (Westerly) – (814) 237-1074 – dantesinc.com

428 Westerly Parkway
State College, PA 16801

Brewsky’s Bottle Shop (PA Pizza on Branch Rd) – (814) 237-8005‎

1663 S Atherton St
State College, PA 16801

I think the phone number is actually for the Super 8.  It’s all the same property.

Home Delivery Pizza – (814) 237-7777 – homedeliverypizza.net

1820 S Atherton St
State College, PA 16801

Kelly’s Bottle Shop – (814) 466-3090

306 Boal Ave
Boalsburg, PA 16827

West

Brewsky’s Bottle Shop (Prospectors/Cato Park) – (814) 238-0015

2070 Cato Ave
State College, PA 16801

Questionable

These are places I suspect may have a bottle shop, but I don’t know for sure.

The Lion’s Den – (814) 237-5081

114 S Garner St
State College, PA 16801

The Arena – (814) 237-8833 – thearenabarandgrill.com

1521 Martin St
State College, PA 16803

Distributors

If you’re new to buying beer in PA, if you want to buy anything more than 192oz. at a time, you can’t buy from any of the above bottle shops.  You have to buy from the distributor, where the price per unit is lower, and they have the most selection, but you have to buy in cases (i.e. ~288oz. or more).

Happy Valley Refreshment – (814) 466-6360 – hvrbeer.com

420 Boal Ave
Boalsburg, PA 16827

They are generally more expensive than the other distributors and I don’t think their selection is quite as good, but they have much better hours.

Pletcher’s – (814) 235-0957

330 W Aaron Dr
State College, PA 16801

Best selection out of the distributors, and you can browse the entire selection yourself (at the others, most beers are just listed on a board).

Nittany Beverage – (814) 237-2542 – nittanybeverage.com

139 N Patterson St
State College, PA 16801

W. R. Hickey – (814) 238-3057 – wrhickey.com (warning: site may cause eye cancer)

1321 E College Ave
State College, PA 16801

Beer Belly’s Beverage – (814) 237-BREW – beerbellysbeverage.com

258 W Hamilton Ave
State College, PA 16801

New distributor in Hamilton Square.  Great craft selection.  Prices on college favorites and some crafts seem to be a bit better than others.

I’m not a fan of either company, but it’s been interesting to watch how this has played out, especially when you take note of the chain of events:

1. Verizon airs “There’s a map for that” ad (a parody of iPhone ads) with the message that Verizon offers 5 times more 3G network coverage than AT&T.
2. AT&T sues Verizon, laughably claiming that their ad is misleading – non-technical users will believe the ad states that Verizon has 5 times more network coverage (of any sort, not just 3G) than AT&T^[1].  AT&T loses.
3. AT&T fights back with ads starring that frat pack guy:
   1. Explaining that AT&T has service (not 3G) covering greater than X percentage (where X is some suitably large number) of the US population^[2].
   2. Explaining that on Verizon’s network, you can’t talk and use your phone’s data features at the same time.
   3. Explaining that Verizon doesn’t have AT&T’s “rollover” minutes.
   4. Explaining that AT&T’s 3G network is faster than Verizon’s 3G network.

What’s interesting about all of this is that none of the statements in any of these ads were false:

• Verizon really does have around 5 times the 3G coverage vs. AT&T,
• AT&T does have the fairly large (mostly non-3G) coverage they state,
• Verizon can’t support concurrent voice and data,
• Verizon doesn’t have rollover, and
• AT&T’s current^[3] 3G technology is indeed faster than Verizon’s.

So what’s happened is that AT&T has engaged in a misdirection campaign^[4] of their own.  “Hey, forget what Verizon said.  We’re not saying they’re wrong, but just forget what they said.  Here’s all the great stuff about AT&T!  Oh, and we really have great coverage!  What’s that?  It’s not 3G?  Shut up and just look how blue our map is!”

It’s clear that AT&T got really pissed off about that original Verizon ad.  But was this overblown response really necessary?  I’ll do some speculation, since I have no data to work with.

I’d guess that most people don’t care.  People know what kind of coverage they get on their phone, the places that they go.  They probably know what kind of coverage their friends on other networks get in the same places.  Was that ad really going to get people running out to their local Verizon store (especially considering contract termination fees), begging to switch, because they were terrified that AT&T didn’t have coverage where they needed it?  What’s more likely is that most of the people who would even care about what the ad was saying (who has more high speed data coverage) probably understood the point. Do you go lots of places?  Do you want more 3G coverage?  Verizon is better^[5].

It’s too late now, but what I’d really like to see would be the results of a survey commissioned after the Verizon ad, before any retaliation by AT&T.  Did people understand the original ad?  If so, did it cause anyone to switch?

Instead of answering the questions, AT&T went to court, and paid some frat pack guy a bunch of money.  I wonder which would have cost more.

I already had a pretty low opinion of realtors.  This is just another nail.