The average speed for T-Mobile as reported by speedtest.net is around 2Mbps, so I’m surprised that mine is so high. I ran a few more tests and I got results between 2.5Mbps and 3.5Mbps. What bothers me the most is that T-Mobile’s mobile network provides a better upload speed than the measly 896Kbps that Qwest gives me.

vivin@serenity ~/Projects/code
$ scp -r vivin@www.vivin.net:~/code/agnostic .
Password:
ps: Process environment requires procfs(5)
Initializing new SSH agent...

vivin@serenity ~/Projects/code
$

I fixed the procfs problem by adding the following to my /etc/fstab:

proc                    /proc           procfs  rw              0       0
linproc                 /compat/linux/proc      linprocfs       rw      0       0

and then running:

vivin@enterprise ~
$ sudo mount /compat/linux/proc

vivin@enterprise ~
$ sudo mount /proc

So I try to scp again and I get:

vivin@serenity ~/Projects/code
$ scp -r vivin@www.vivin.net:~/code/agnostic .
Password:
Initializing new SSH agent...

vivin@serenity ~/Projects/code
$

WTF? Then I remembered making some changes to my .bashrc to be able to commit to github:

function start_agent {
  echo "Initializing new SSH agent..."
  /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
  echo succeeded
  chmod 600 "${SSH_ENV}"
  . "${SSH_ENV}" > /dev/null
  /usr/bin/ssh-add;
}

# Source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
  . "${SSH_ENV}" > /dev/null
  #ps ${SSH_AGENT_PID} doesn't work under cywgin
  ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
    start_agent;
  }
else
  start_agent;
fi

I pulled all that out of my .bashrc and made a separate shell script for it. After I did that, scp started working again. I had no idea that calling scp would actually run .bashrc

openssl s_client -connect localhost:995

Everything seemed fine. Furthermore, this problem seemed to be limited to both my FreeBSD servers. My Linux box seemed to be running fine. I tried a bunch of things. I restarted both machines, restarted the network interfaces, made sure firewalls weren’t running, reset my router… nothing seemed to work. Every time I tested the connection to the machines (using this awesome tool here), the connections would time out. What was even stranger was that a netstat showed connections to be in a SYN_RCVD state, which meant that the box had accepted the connection. It’s just that the response wasn’t getting out. Eventually I was so desperate that I decided to reinstall FreeBSD on one of the machines. I also posted to a BSD forum asking for help. I figured that next evening I could probably fix it after work.

Well, next morning I still felt terrible, but it wasn’t so bad. My throat wasn’t hurting as much and I didn’t have that much of a headache so I was able to work from home. Oh, and the installation had completed. I set everything up quickly and gave it a whirl. Nope. Same problem. Yeah, I was getting pretty frustrated and annoyed at this point. I went so far as to contemplate wiping my beloved FreeBSD off both machines and putting Linux on there. I updated my post at the forum and I checked on it periodically throughout the day as I kept working. Finally, a kind soul popped in to help me out. He helped me troubleshoot using tcpdump and I was able to confirm that the machine was responding to the incoming connection, but it wasn’t going out. Finally, he asked me to check the routing information. I’m not that well-versed with that so I didn’t see the problem until he pointed it out. The routing information was all wrong!

See, I have two network interfaces on the box. One for my internal network, and one pointing to the outside world. The one pointing to the outside world is statically configured, whereas the one for my internal network picks up its configuration from my AirPort Extreme router. What was happening was that dhclient was overwriting the route information. So when the machine tried to respond back, it saw its default route as the internal router, and not my modem! I had to update my dhclient.conf and force the router address to the correct one:

backoff-cutoff 2;
initial-interval 1;
retry 10;
select-timeout 0;
timeout 30;

interface "vr0" {
   supersede routers 209.x.y.54;
   supersede host-name "enterprise";
   supersede domain-name "xxxx.xxx";
   request subnet-mask,
           domain-name-servers;

   require subnet-mask,
           domain-name-servers;
}

The important line here is the one that says supersede routers 209.x.y.54; (I’ve hidden the actual numbers from teh hax0rs). This tells the dhclient to override the router information that it gets from the DHCP server. Once I did this, everything started working again. My thanks to jggimi at DaemonForums!

Source: Qwest.net: How much do static IP addresses cost and how many addresses do I get?

I had a hard time understanding this. I mean, I’ll admit that I’m not a networking expert. But how hard can setting up static IP’s be? Does it really take $50 worth of work? I’m assuming it involves some configuration – probably a few keystrokes or something of that nature. $50 for that? Maybe it’s completely different from what I think. Maybe IP addresses are huge blocks of stone that need to be moved from place to place, therefore there are obvious labor costs. Whatever. $50 sounds ridiculous to me. I figured I’d talk to Qwest and see if they could explain this cost to me. I didn’t get anywhere with the reps online, but the prompt and helpful folks at @TalkToQwest finally emailed me with an answer:

Hello Vivin,

After doing a little research on the matter I have found out a little more about the business decision to charge for setting up Static IP’s. Initially, there is a lot more in the way of system software that has to be implemented on our order side to facilitate these orders as apposed to the standard issue.

Additionally, the potential costs of features/functions that are afforded the customer with these services potentially require more resources and as such, cost to maintain and implement.

The setup cost is a way to spread that cost across the specific platform at what is considered a reasonable amount. How exactly they come up with this figure is of course something that I would not be privy to and would be considered proprietary marketing/business internally confidential information that I could not disclose any how, but that is the basic reason why we charge for the setup. There are cost unique to Static IP’s and they need to be covered.

Hope that helps explain it a bit anyway.

Not exactly the answer I was looking for, but I appreciate the time that the rep took to write me an email, and I guess I did understand the rep’s point that there are some costs involved. But come on, now… The point about “cost to maintain and implement” – I assume that this could easily be covered by the $14.99 I pay them every month. Other than that, I don’t see any reason to have a setup fee. If you ask me, there’s really only one reason. I apologize if I’m being cynical, but honestly I think it’s just a way for Qwest to make a quick buck. I can’t think of any other reason. I also don’t really buy into the whole “proprietary marketing/internal business/confidential” aspect of this, because come on… it’s just networking. I’m assuming that not too many people care about the fee, or ask about it and so Qwest is able to get away with it. Come to think of it, whoever invented the concept of a the “setup fee” is a genius. It’s a technical and important-sounding phrase that is also completely meaningless.

Anyway, I decided to take the hit and order them because I need the block. But overall I think it should be mandatory for companies to itemize and describe all the elements that make up a “setup fee” instead of just charging their customers some random amount. As customers we have a right to know what we’re paying for.

• Intel Core 2 Duo Processor T7700 (2.4GHz/800Mhz FSB, 4MB Cache)
• 3GB Shared Dual Channel DDR2 SDRAM at 667MHz (2 Dimms)
• 256MB NVIDIA GeForce 8600M GT
• 250GB 5400rpm SATA Hard Drive
• High Resolution glossy widescreen 15.4 inch LCD(1680×1050) 2MP Camera
• Slot Load DVD+/-RW (DVD/CD read/write)
• Integrated Sound Blaster Audigy HD Software Edition
• Intel Next-Gen Wireless-N Mini-card (4965AGN)

It’s got some punch. I’m mainly going to use it as a development machine so the RAM and speed definitely help as far as compile-times go. They estimated about two weeks to build the laptop, but actually I got a pleasant surprise when the laptop arrived a little over a week after I ordered it. I wasn’t disappointed in the least when I opened up the package. The first thing I did was blast Vista off the hard-drive and install PC-BSD. This is where I learnt a hard lesson. Stability in the BSD world comes at a price. You don’t have very good hardware support (for no fault of FreeBSD; I’ll rant about this later) for the latest hardware. Drivers are not included until they are reliable and stable. As a result, my Marvell Yukon 88E8040 Gigabit Ethernet card, and my Intel 4965AGN Wireless-N card were unrecognized. Marvell (surprisingly) had a FreeBSD 6 driver on their website that is supposed to work with the 88E80XX series, but I was unable to get it to work on my system. I tried using ndiswrapper to get the Intel card working, but I only succeeded in crashing my system very nicely. I was pretty bummed. I really didn’t want to go back to using The Evil (Vista), and so I decided to play around with kubuntu for a while. It was nice, and I may get back to it. But for the hell of it, I wiped it off and tried to install OS X on it. I was able to get a “patched” Leopard ISO and I actually got it to install on the XPS. However, I wasn’t able to get it to recognize any of my network devices. So after playing around with that for a while, I went back to The Evil. I am hoping that by the time PC-BSD 2.0 or FreeBSD 7.0 rolls around, there will be more support for the network cards. If that’s the case, I’ll definitely be wiping out Vista and installing PC-BSD (or install FreeBSD 7.0 and build KDE). I’ve been using Vista for a little while, and I guess it’s not so bad. It’ll stay out of your way if you ask it to. But it really doesn’t compare to either PC-BSD, Kubuntu, or Leopard. As far as the XPS, I like it a whole lot. I think Dell has done a pretty good job with it.

When I installed PC-BSD, I noticed that it wasn’t able to recognize my Wireless Adapter. This wasn’t a surprise, and for no fault of PC-BSD’s. It’s just that very few manufacturers make drivers for OSes other than Windows. Also, they are reluctant to release details for the adapters because they regard them as trade secrets. Hence, developers are left with the option to painstakingly reverse-engineer the adapters and write drivers for them. Anyway, before I could get my card to work, I needed to know what chipset it uses. To do this, you can use lspci, which lists devices on the PCI bus.

So first, open up a terminal window from Start->System->Konsole. Then do:

[vivin@tardis ~] su
Password:
[root@tardis /home/vivin]# pkg_add -r pciutils
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.1-release/Latest/pciutils.tbz... Done
[root@tardis /home/vivin]# lspci
00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev 02)
00:03.0 PCI bridge: Intel Corporation 82875P/E7210 Processor to PCI to CSA Bridge (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV31 [GeForce FX 5600] (rev a1)
02:01.0 Ethernet controller: Intel Corporation 82547EI Gigabit Ethernet Controller (LOM)
03:01.0 Ethernet controller: Marvell Technology Group Ltd. Unknown device 2a02 (rev 03)
03:02.0 Serial controller: 3Com Corp, Modem Division 56K FaxModem Model 5610 (rev 01)
03:03.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
03:03.1 Input device controller: Creative Labs SB Audigy MIDI/Game port (rev 03)
03:03.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port
03:04.0 Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus DVD Decoder (rev 02)

As you can see, the wireless controller has a Marvell chipset. Unfortunately, FreeBSD doesn’t have a driver for Marvell chipsets. This is where the amazing piece of software known as ndiswrapper comes in. FreeBSD doesn’t have ndiswrapper per se, instead it has something similar called ndisulator (also known as Project Evil). This nifty piece of software creates a kernel module by making a wrapper around the Windows driver (using the SYS and INF files). You can then load this kernel module and FreeBSD will be able to recognize your wireless card.

Before you can run ndisulator, you need access to your hardware’s driver files and the kernel source files. For PC-BSD, you can get the source files here. You will need to copy this from /Programs to /usr and extract it. For FreeBSD, run /stand/sysinstall and then download the src distribution. I think it’s somewhere under “Configure”.

As far as the driver files, you can usually get this from your installation CD. However, in some cases (such as this one), the driver files are packed into an executable and there’s no way you can get it unless you actually install the program. If this is the case, you can probably search the web to be able to find the driver files. What I did was install Wine and then run the latest driver from Netgear’s site. If you don’t have X running, then this is a problem. Anyway, I have made it easier for you and I have the bzipped and gzipped tarballs available for download. Now once you have extracted the files to a directory, you will need to run ndisgen on these files. If you notice, there are two SYS files. I built modules for both, and I use both on my system. It seems to work if you load either one. Using ndisgen is simple. However, there are a few caveats. When you first run ndisgen you may get a “Conversion failed” error with a syntax error on line 998 (or something to that effect). The reason is that the INF file parser on FreeBSD is not as forgiving as the one on Windows. It’ll trip up on DOS-style EOL characters (\r\n) and on some other weird characters as well. Often, the file itself has some other weird syntax errors as well. Anyway, to fix the the EOL character problem, you have to change the DOS-style EOL characters to Unix. Some systems have a dos2unix and unix2dos command. If you don’t have it (I didn’t) you can use the sed command:

[root@tardis /home/vivin/wn311t]# sed -i -e 's,^M,,g' NetMW14x.inf

The ^M is not just the caret sign and the capital letter M. To get it, you have to press CTRL+V and then CTRL+M. This command will convert all DOS-style EOL’s to UNIX-style EOL’s. Now we need to try converting the files to kernel modules. Unfortunately, when I did this first, I got the following error:

[root@tardis /home/vivin/wn311t]# ndisgen NetMW14x.inf netmw145.sys
        ==================================================================
        ------------------ Windows(r) driver converter -------------------
        ==================================================================

                        Kernel module generation

        The script will now try to generate the kernel driver module.
        This is the last step. Once this module is generated, you should
        be able to load it just like any other FreeBSD driver module.

        Press enter to compile the stub module and generate the driver
        module now: 

        Generating Makefile... done.
        Building kernel module... In file included from /usr/share/misc/windrv_stub.c:57:
./windrv.h:150:4: unknown escape sequence '\p'
./windrv.h:150:4: unknown escape sequence '\H'
./windrv.h:318:4: unknown escape sequence '\p'
./windrv.h:318:4: unknown escape sequence '\H'
build failed. Exiting.

This is problem is due to un-escaped backslashes in windrv.h. I went ahead and fixed the file, but then realized that when I ran ndisgen again, my changes would be overwritten. So I copied my changes to another file called windrv2.h. I ran ndisgen again, and at the prompt where it tells you that it is going to build the kernel module, I opened up another terminal window and copied windrv2.h over windrv.h. This time the conversion process went through without a hitch. After you convert both SYS files, you will be looking at two .ko files; netmw143_sys.ko and netmw145_sys.ko. You need to kldload these modules:

[root@tardis /home/vivin/wn311t]# kldload netmw145_sys.ko
[root@tardis /home/vivin/wn311t]# kldload netmw143_sys.ko
[root@tardis /home/vivin/wn311t]# kldstat
Id Refs Address    Size     Name
 1   23 0xc0400000 753dc8   kernel
 3    2 0xc0b5f000 1af50    linux.ko
 4    1 0xc0b7a000 75650    netmw143_sys.ko
 5    4 0xc0bf0000 1753c    ndis.ko
 6    3 0xc0c08000 c9e0     if_ndis.ko
 7    1 0xc0c15000 757d0    netmw145_sys.ko
 8    1 0xc0c8b000 58554    acpi.ko
 9    1 0xc57ff000 6000     snd_emu10k1.ko
10    1 0xc5805000 1c000    sound.ko
11    1 0xc5872000 6000     linprocfs.ko
12    1 0xc588f000 4000     logo_saver.ko

Note that I took this output from my machine where I automatically load the modules at startup (more on that later), which is why they are in lower memory locations. Anyway, the highlighted modules are the ones you need to worry about. If all goes well, these modules should be visible. If you do an ifconfig you should now be able to see the ndis0 interface:

[root@tardis /home/vivin/wn311t]# ifconfig ndis0
ndis0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::218:4dff:fe1f:f432%ndis0 prefixlen 64 scopeid 0x7
        inet 0.0.0.0 netmask 0xffffff00 broadcast 255.255.255.255
        ether 00:18:4d:1f:f4:32
        media: IEEE 802.11 Wireless Ethernet autoselect
        status: no carrier
        ssid "" channel 1
        authmode OPEN privacy OFF txpowmax 100 protmode CTS

This is good, because FreeBSD now recognizes your card. The next hurdle is getting your card associated to a wireless network. This is where I had the most difficulty. Scanning for networks didn’t seem to work for me. KDE’s wireless tools were unable to find anything and I was also unable to find anything from the terminal. I figured I could still try and connect to the network by providing my SSID. Since I use WPA, I was going to use wpa_supplicant to connect to my wireless network. This proved to be easier said than done. I set up my wpa_supplicant.conf file in /etc like this:

eapol_version=1
ap_scan=1
fast_reauth=1

network={
           ssid="<put your ssid here>"
           # 'RSN' == 'WPA2'
           proto=RSN WPA
           key_mgmt=WPA-PSK
           pairwise=CCMP TKIP
           group=CCMP TKIP
           psk=<put your psk here>
        }

After that:

[root@tardis /home/vivin/wn311t]# wpa_supplicant -i ndis0 -c /etc/wpa_supplicant.conf
ioctl[SIOCG80211, op 24, len 24576]: No space left on device
ioctl[SIOCG80211, op 24, len 24576]: No space left on device
ioctl[SIOCG80211, op 24, len 24576]: No space left on device
ioctl[SIOCG80211, op 24, len 24576]: No space left on device
ioctl[SIOCG80211, op 24, len 24576]: No space left on device

As you can see, things didn’t go too well. I spent hours scouring the web and message boards. I found someone with exactly the same error message, but they had received no responses to their queries. Finally after about another hour of searching, I had enough information to put it all together. Instead of using the wpa_supplicant binary, you need to use FreeBSD’s wpa_supplicant script together with dhclient:

[root@tardis /home/vivin/wn311t]# /etc/rc.d/wpa_supplicant forcestart ndis0
[root@tardis /home/vivin/wn311t]# dhclient ndis0

If all goes well, your wireless card should be able to authenticate with your wireless router and receive an IP address:

[root@tardis /home/vivin/wn311t]# ifconfig ndis0
ndis0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::218:4dff:fe1f:f432%ndis0 prefixlen 64 scopeid 0x7
        inet 10.0.1.197 netmask 0xffffff00 broadcast 10.0.1.255
        ether 00:18:4d:1f:f4:32
        media: IEEE 802.11 Wireless Ethernet autoselect
        status: associated
        ssid "" channel 1
        authmode OPEN privacy OFF txpowmax 100 protmode CTS

This is fine and dandy. But now you need to make sure that all these steps are done automatically when you startup your machine. First, you need to ensure that your new kernel modules are loaded up when you start your machine. To do that, copy your kernel object files to /boot/kernel. Then, add the following lines to /boot/loader.conf

[root@tardis /home/vivin/wn311t]# grep net /boot/loader.conf
netmw143_sys_load="yes"
netmw145_sys_load="yes"

These changes will ensure that your wireless adapter drivers are loaded up on startup. Finally, you need to add two lines to /etc/rc.conf to let FreeBSD know that your wireless adapter needs to be configured through wpa_supplicant:

# Enable wpa_supplicant
if_ndis0="WPA DHCP"
wpa_supplicant_enable="YES"

I have read that the second line is superfluous because apparently the “WPA” option tells FreeBSD to use wpa_supplicant, but it didn’t seem to hurt anything so I left it in there. Once you have done all this, go ahead and restart your machine. Your WN311T Wireless Adapter should now be able to connect to the wireless network. You can verify that wpa_supplicant is running by doing the following:

[root@tardis /home/vivin/wn311t]# ps x | grep wpa
 1368  ??  Ss     0:56.72 /usr/sbin/wpa_supplicant -B -q -i ndis0 -c /etc/wpa_supplicant.conf -D ndis -P /var/run/wpa_supplicant/ndis0.pid

In some cases, wpa_supplicant still won’t start. I have had this problem before. In that case, you will have to run wpa_supplicant and dhclient manually (like I showed before) to get your card to work. I am not sure why this happens.

These instructions deal with using WPA for your Wireless Security. I believe wpa_supplicant can be configured to use WEP as well.

So there you have it. I hope this writeup is helpful and saves you hours of frustration!