Main

Wifi/Wireless Archives

February 24, 2003

Technology Expands... Some current observations on SprintPCS/Vision and Linus Torvalds

    As the ever persistent (and addicted) tinkerer, I have been thoroughly tinkering with SprintPCS or PCS Vision specifically and am amazed by the results in performance I have experienced. I have two Vision (i.e. 3G data) devices that I have tested - a Samsung N400 and a Handspring Treo 300. The Treo has become my new favorite true mobile device. I have commented elsewhere that I wish it had a better screen - i.e. similar to the Sony Clie 320x320 screens - but it is definitely sufficient when compared to my other options out on the market today. This commentary is not aimed at the technical side of each device, however - it is aimed at the connectivity issues. Both devices are under an account through Sprint that offers unlimited Data services. (Although, like any good ISP, they want reasonableness when it comes to your unlimited data usage - thus, they can shut off your service if you become a data hog.) The Treo thus far has only been usable as a computing device on its own or as a wireless modem for my PowerBook (Titanium G4). As far as connectivity with my Sony SRX99 goes, I am limited to using it with an external IR adapter or a USB to Serial adapter - and I'm not willing to putz with that combination or buy the cables... On it's own, the Treo does a fantastic job. Browsing with the Blazer web browser is completely acceptable a.** Browsing the web on the PowerBook (using NotifyMail's WirelessModem program) is also great. I get above 56k dialup speeds. Some people have complained that such speeds are less than what they expected of 3G and while I agree, I also recognize as a tinkerer, putzer and network design hobbyist, that thinking 3G would be faster than dialup - i.e. in the range of slow DSL - was a pipe dream. Networks the size and scale of these national cell/pcs networks need testing and lots of real-world use before they will ever get that fast. So, compared to DSL/Cable, it is slow - but it is much faster than dialup and for that 60% of the US population with access only to dialup, it is a welcome addition to my plate of options - remember, competition brings choice, lower prices and eventually better services.
    Getting back to my ever fluid thoughtline - I have also done some serious testing with the Samsung and am amazed. While the Treo is great because it combines my phone and PDA, the Samsung is simply fantastic as a relatively inexpensive wireless modem that just happens to be capable of being used as a phone, too! I have been having problems with our dialup at work lately and decided today after tooooo sloooowww of speeds, to hook up the Samsung to the PowerBook and test that out in the office. Suffice it to say that I was very pleased with the performance. I collaberated with a friend in NYC on a web project he is finishing the design work for over AIM, uploaded files to the server, used ssh to work on some files, checked the display of the page, etc... all on a wireless 3G connection that was definitely faster than dialup.
Try PCS Vision, you'll like it... There. That's my endorsement. It doesn't get any better than that (for now).

    As for my comment regarding Linus Torvalds... this will be quick. I will formulate my thought in the form of a rhetorical question:
How would you like to be the guy mostly responsible for creating an entire industry revolving around open source software? The man is amazing - and the fact that he still remains relevant years and years after coming up with the Linux paradigm is even more amazing.

March 25, 2003

Point Well Made - VoIP, 3G and WiFi

     The Register has a great article on the reality of combining WiFi hotspots into 3G networks. While companies have fought over the control of the networks and equipment themselves, it may be time to simply provide the pipeline and let the market decide where hotspots are to be installed. Take US's Sprint PCS for example: with mother Sprint having a whole host of data offerings (from DSL to T1's, T3's, etc.), Sprint could easily provide the backbone and you provide the Hotspot equipment. It is unlikely that there will be longevity in the existence of the location for many providers (like myself) mainly because people move, businesses fold and life goes on. But the liquidity and consistency of demand will produce more hotspots than are needed (in my estimation) and all that Sprint is really forced to provide is the pipeline and IP space (which it already has). People like myself, who are already paying hefty sums for high speed service, would be more than willing to switch to a network that offers them the option of providing services supported by a big network provider - and heck, if I go under or move my business, maybe the next person will pick up where I left off.

No, the real value - and wealth - comes from the services that we use, not from fighting over the plumbing. The last thing the USA needs - it's already handicapped by three incompatible air interfaces (GSM, CDMA, IDEN) - is another infrastructure war.

See: Sprint to meet WiFi halfway

March 29, 2003

Rebuilding Iraq - Technology

     Essentially, the US politicians should be supporting US businesses and people, not the opposite. (And one can argue that NAFTA has helped the Mexican population more than the US because of the movement of jobs to Mexico.) In the case of rebuilding Iraq after the war, the same should apply. A recent article in the Wall Street Journal - Online entitled Cellphone Fight Raises Issue of U.S.'s Postwar Priorities points out the future questions our politicians will be answering regarding things as simple as what type of cell phone the Iraqis will be purchasing. I think that it is our duty to support technology invented and manufactured in the US if our money is to be used. It makes no sense to me that we should be spending taxpayer money on technology not developed or manufactured in the US. If the EU wants to supply the cash for rebuilding Iraq's telecommunications network, then it is their prerogative and responsibility to support European manufacturers and technology. The question of which technology - GSM or CDMA - is better, is a wholly different issue.

March 30, 2003

Can you hear me now?

     I am mobile and so is my whole family - i.e. we use cell phones quite a bit because of the convenience of calling one another in the car - no one seems to have time otherwise. One of my biggest complaints, however, is the horrible background noise that tends to be the most frustrating part of mobile phones. I hope technology like this continues to be worked on:
Mobile calls sounding better - BBC News

November 15, 2003

Bluetooth SDIO compatible w/ Palm OS 5 - Where and When?

    I know this rant seems petty considering all that is going on in the world - and considering many of the new toys (in the area of all-things-wifi) that have come out lately, but please... When is Bluetooth SDIO card that is compatible w/ Palm OS 5 ever going to make it to market??? I have literally been waiting for this for 2 months now (actually over 2 years since BT really made its big debut), but have seen and heard nothing. Can someone comment and tell me whether writing drivers for Bluetooth and Palm OS 5 is that difficult? If not, how much would it cost to pay someone to develop drivers to connect to BT enabled phones and my BT enabled Powerbook? I want to sync my Treo 600 via BT w/ my PowerBook now...

March 17, 2004

The Latest Challenge: Darien Wireless Co-Op

    It started out as an idea that had been haunting me over the past few years, but now it just might become a reality. You see, we live out in the sticks. Out in the country. Out in the middle of nowhere. After working for Hillsdale College and having gotten used to the raw power of a T1 and a host of servers to play with, I had a somewhat difficult time adjusting myself back to country life (a little over three years ago, my wife and I moved back to my home town so that I could start working with our family businesses). After playing with three phone lines and multiple dial-up accounts, then testing the fledgling two-way satellite internet service, I came across (a now defunct company), Dakota DSL. They ended up changing their name, but its been so long and the service was so short lived that I can't even remember anymore. I polished up some old workstations I had accumulated over the years and others gotten off of eBay and put Windows NT Server on two machines and started my own little webhosting operation. It was costing me a fortune, but still better than anything I had seen since moving back to Wisconsin. At the time, Aaron and I did a little webhosting off of the servers for both of our domains. It didn't become anything more than two pokey websites because about three months into it, we got hacked... We were hacked pretty badly, too. So, I researched around and around and around and realized that upgrading to newer versions of Windows NT was going to be too costly, so I decided to learn what I needed to do to get our services running on some form of Linux or Unix. By that time, Aaron had split - found a better and more reliable host - and I was convinced I could do webhosting better and cheaper than anyone else. I took about three more months and learned the basics of FreeBSD and got apache, qmail, php4, mysql and a host of other services running on my first FreeBSD box. I also learned that I couldn't do webhosting better and cheaper than anyone else because 1) I had a real job and 2) the box that was hanging off the net was 15 minutes from work - so any time there were troubles, there were troubles. It suited my needs, but I needed stronger, faster and more of everything in order to make the venture work. Then Dakota went bankrupt and I lost my super fast connection. Then, we also got kicked out of the house we were living in (not really, but the owners wanted to move back in and we had to look for a new place to rent or buy). So, I shut my website and hosting service (of one) down and took a 4 month hiatus.
    Between then and now, I have been on Charter in one form or another and have amassed a server farm that makes my head swim (when I realize the money I have sunk into my addiction). I had, at one time, a neighborhood wireless network running - which is what got me started on this topic in the first place - whereby I supplied some of my neighbor/friends with access to my mega-pipe to the net and they helped defray the cost of my service. My wife and I ended up moving, yet again, to a place where I think we'll stay put for some time to come. We also moved our offices and are closer to where I live and are in a business park - whereas before, we were literally in the middle of a very large corn/soy bean field.
    If you are still reading by now, you are either entranced by my writing, you are on the loo with your wireless laptop and having nothing better to read or you are trying to sleep - BUT, I'm actually getting to a point. I'm starting up another wireless project. This time, however, my project has no grand goals other than covering my @ss on bandwidth expenses. I don't want to be the worst and if you graded what I want to do solely on price, I can't be the best - but I can give you the best experience for your dollar and help us help each other. If you are somewhere near this area (click on the link and you will see an amazing little satellite photo), then there is a good chance I can get you online. Sure, there is competition (GenevaOnline and ElkNet - and a few other dial-up entities), but I think we can beat them in every way - price, service and accessibility. But, we can only do it by pooling our resources. I found some great equipment by Proxim and some people who seem genuinely interested in the project. I hope to use this site to document my progress. I have a few goals in mind and would like to put up a chronology of what happens:
1) Get the center base station up and running this weekend.
2) Get final commitment from other users (hopefully 10 of us will sign up).
3) Based upon final commitment, I will put in my T1 orders.
4) Get a few subscribers up and running next week.
5) Keep those subscribers up and running...
6) Get the rest of the subscribers up and running.
7) Keep the rest of the subscribers up and running...
8) Monitor bandwidth to make sure we are utilizing it to the best of our abilities.
9) Put in redundant nodes in case the main node goes down.
10) ...I'm thinking residential on a different scale than approached by ISP's before. Fully private addressing scheme, SPAM filters on all email addy's and nodes supplied by private DSL lines all over the city and countryside. P2P sharing limited to 256kbps of overall bandwidth... period. A ResNet for Darien, built in much the same fashion that the Co-Op is designed to run - a few volunteers and a lot of users.

We'll see how it goes...

May 8, 2004

Adventures with Load Balancing using OpenBSD, pf and a Sangoma Dual CSU/DSU Adapter - HOWTO

Written by Steven N. Fettig
Rev. 1.1 - 8 May 2004
(See Creative Commons Copyright in right pane for copy restrictions)
Materials:
IBM Small Form Factor Workstation (Overkill)
Integrated Intel 10/100 NIC
Sangoma Dual CSU/DSU T1 PCI Card

Preface: As part of the Darien-WiFi project, I spent the past two weeks trying to install a router for our two T1's from Global Crossing. I had originally intended to use FreeBSD as the base system. What I found was that there was no (documentation showing a) way to do native load balancing across both T1's. The Sangoma Wanpipe drivers for Linux were able to do load balancing using the TEQL module (used in firewall QoS). Although an open supporter of what works - which can often be Linux - there was no way that I was going to use Linux on my router considering that I have had much, much more experience with FreeBSD and am familiar with locking it down for security uses. With quite a bit of Google digging, I found that OpenBSD'spf was not only capable of doing load balancing, but a whole array of items that I had spent much time learning how to do with ipfw on FreeBSD. After working until 10:30 pm on a Wednesday, I decided not to try OpenBSD, but instead opted for the pf port for FreeBSD. At about 1 am the next morning, I found out that not only would pf not load on a pre-5.0 machine (I know, I know - it says so in the docs, but I'm not enough of a kernel hacker to understand that it really wouldn't work), but I also couldn't get the Wanpipe drivers to load on the FreeBSD 5.2.1 system I just installed. By this time, I had been in contact with the Wanpipe BSD developer, Alex Feldman, and found that he hadn't thoroughly tested the driver install packages on 5.1 + and he asked me to wait for him to do his work. (He was extremely helpful - if you continue reading, you will find that I found more than one helpful soul through this whole process.) Instead of waiting, though - I had already spent enough wasted time on this project (which might have been completely avoided by using a Cisco Router with dual CSU/DSU's)* - I decided to dive into OpenBSD for the first time. I thought, with all of the structural similarities, it shouldn't be that difficult to acclimate myself to OpenBSD's peculiarities. So, here are basic instructions as to how I was able to get load balancing to work using the Sangoma card and pf on OpenBSD.

Instructions:
It happens that the University of Wisconsin - Madison runs an OpenBSD mirror. I downloaded the 3.4 boot iso from http://mirror.cs.wisc.edu/pub/mirrors/OpenBSD/3.4/i386/ on my OS X workstation:


wget http://mirror.cs.wisc.edu/pub/mirrors/OpenBSD/3.4/i386/cd34.iso

Using DiskTools, I burned the bootable iso image to CD. There are a slew of tools out there to burn ISO's to CD. I assume that if you are reading how to configure a custom workstation/server to be your router, that you know how to burn a CD. I put the CD in my future router and booted the machine.
I was careful to follow the install instructions at:

Some people have complained that FreeBSD's install procedure was difficult... well, they obviously have not tried to install OpenBSD. This is not to say that I found it all too difficult - I'm neither afraid of a command line, nor am I worried if I hose the system - I can rebuild it, right? I learn best through trial-and-error anyway. This was one time, however, that I was able to get the base system installed without a hitch. Well, that is not entirely true - I tried to do a base install on a system with a Broadcom Gigabit NIC and could never get the NIC to activate during the install. Perhaps had I read the supported hardware information on the main site, I would have found that support for the NIC needs to be added via a custom kernel. I had another machine waiting idly by to get used - with an onboard Intel 10/100 NIC (supported by the generic kernel) - and went through the same procedure again.
Because I had not yet received the CD's I purchased (c'mon - support the open source projects you use!), I installed from the UW-Madison http server.
After choosing the install source, I selected the following filesets (in FreeBSD lingo, I suppose this is base packages):

The following sets are available. Enter a filename, 'all' to select all the sets, or 'done'. You may de-select a set by prepending a '-' to its name.
      [X] bsd
      [   ] bsd.rd
      [X] base34.tgz
      [X] etc34.tgz
      [   ] misc34.tgz
      [X] comp34.tgz
      [X] man34.tgz
      [   ] game34.tgz
      [   ] xbase34.tgz
      [   ] xshare34.tgz
      [   ] xfont34.tgz
      [   ] xserv34.tgz

There are a few more items that need to be configured after the appropriate distributions have been downloaded. Again, follow the install FAQ for assistance. I would take more time to outline how to install your OpenBSD system, but the FAQ provides an amazingly detailed explanation of the installation procedure. It would be wrong of me to provide another explanation when it is laid out so well in the OpenBSD documentation.
Since I had already physically installed the Sangoma card, I rebooted the system and started to install the drivers and configure the T1's (according to the settings that Global Crossing is using). I downloaded the Wanpipe drivers and software:

# wget ftp://ftp.sangoma.com/OpenBSD/current_wanpipe/wanpipe-obsd-1.5.2-b2.tgz

I took care to follow the installation instructions given to us by Sangoma and simply ran:

# pkg_add ./wanpipe-obsd-1.5.2-b2.tgz

I had the install script do all the defaults - install drivers, add support to kernel, install startup scripts, etc. Everything went off without a hitch. When I had originally tried the installation on the pre 5.x FreeBSD system, the compilation of the drivers failed. I have yet to test the Wanpipe installation on OpenBSD 3.5, so I can't say whether it works or not. Due to the stability of OpenBSD, I imagine the packages will install without any problems as they did on my 3.4 system.
Again, following instructions that come with the Sangoma card, I configured the T1's.

# /usr/sbin/wancfg

This part requires that you have pertinent protocol and IP information from your provider.
Sidenote: I must say that Global Crossing is amazing. Their Circuit Turn-up staff was amazingly helpful. Through this whole ordeal, a gentleman named John Brox helped me out and was patient with my insistence on doing a custom install - I say patient because I initially was not able to even bring up the circuits with a box I had intended to use (a Eden 500 VIA mini-itx machine), as the ethernet interface caused the circuits to cycle up and down at weird intervals. I don't know if this was a problem with the motherboard itself or with the VIA ethernet interface. I have yet to do the same install on another VIA mini-itx based system, so I don't know. He was more than willing to help me make sure the circuit was up for good before turning it over to the monitoring group.
I haven't worked on routers in years and considering that, not only does Sangoma make the circuit configuration easy, but Global Crossing made the circuit turn-up a breeze.
On to the actual configuration of the firewall and load balancing. The Wanpipe drivers give you two interfaces to work with (once the T1's have been enabled). The last line in wanrouter.rc (in /etc/wanpipe) should read:

WAN_DEVICES="wanpipe1 wanpipe2"

so that both lines are enabled when the machine is rebooted. If you have not rebooted the machine, you can start the wanpipes by (assuming you configured wanpipe1 and wanpipe2):

# wanrouter start wanpipe1
# wanrouter start wanpipe2

After starting the circuits, running

# ifconfig -A

gives you:

wpachdlc0: flags=51 mtu 1500
     inet 22.109.101.234 --> 22.109.101.233 netmask 0xfffffffc
wpbchdlc0: flags=51 mtu 1500
     inet 22.222.9.162 --> 22.222.9.161 netmask 0xfffffffc

at the end.
You also need to make sure that your machine is set up to act as a gateway. Straight from the FAQ: http://www.openbsd.org/faq/faq6.html

The GENERIC kernel already has the ability to allow IP Forwarding, but needs to be turned on. You should do this using the sysctl(8) utility. To change this permanently you should edit the file /etc/sysctl.conf to allow for IP Forwarding. To do so add this line in that configuration file.

net.inet.ip.forwarding=1

My internal ethernet interface (fxp0) was set as 24.192.154.1 - the beginning of my address block available for use. At first - just to try the load balancing - I modified the rules at http://openbsd.org/faq/pf/pools.html#outgoing for my interface:

lan_net = "24.192.154.1/24"
int_if  = "fxp0"
ext_if1 = "wpachdlc0"
ext_if2 = "wpbchdlc0"
ext_gw1 = "22.109.101.233"
ext_gw2 = "22.222.9.161"

so that the whole pf.conf looked like:

# define the interfaces
lan_net = "24.192.154.1/24"
int_if  = "fxp0"
ext_if1 = "wpachdlc0"
ext_if2 = "wpbchdlc0"
ext_gw1 = "22.109.101.233"
ext_gw2 = "22.222.9.161"

# nat outgoing connections on each internet interface
nat on $ext_if1 from $lan_net to any -> ($ext_if1)
nat on $ext_if2 from $lan_net to any -> ($ext_if2)

# default deny
# I disabled these rules because we are in the testing phase - i.e. I am not yet using this as a real firewall - do not forget to re-enable these rules!
#block in from any to any
#block out from any to any

# pass all outgoing packets on internal interface
pass out on $int_if from any to $lan_net
# pass in quick any packets destined for the gateway itself
pass in quick on $int_if from $lan_net to $int_if
# load balance outgoing tcp traffic from internal network.
pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
proto tcp from $lan_net to any flags S/SA modulate state
# load balance outgoing udp and icmp traffic from internal network
pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
proto { udp, icmp } from $lan_net to any keep state

# general "pass out" rules for external interfaces
pass out on $ext_if1 proto tcp from any to any flags S/SA modulate state
pass out on $ext_if1 proto { udp, icmp } from any to any keep state
pass out on $ext_if2 proto tcp from any to any flags S/SA modulate state
pass out on $ext_if2 proto { udp, icmp } from any to any keep state

# route packets from any IPs on $ext_if1 to $ext_gw1 and the same for
# $ext_if2 and $ext_gw2
pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to any


At this point, I was able to ping out of both interfaces, ping beyond the gateway, ping internally, etc. So, I set up a client behind the firewall and ran speed tests. Lo and behold, I was getting load balancing on the inbound (vis a vis Global Crossing's router configuration - it equally passes packets down both pipes), but it did not look like it was working on the outbound. It was about 12 am by this time and I was simply happy to see the OpenBSD machine working with the T1's and everything being pingable. Plus, John was gone by this time. I decided to call it quits and start again in the morning.
I woke up still puzzled as to why I couldn't get load balancing on the outbound route to work - theoretically, I had everything configured correctly! I called John and asked him if he could take a look at packet counts while I was running the bandwidth tests. After running a few tests, we found that the outbound were indeed being passed across both interfaces, but for some reason the bandwidth tests were not showing that. So, I decided to try to run more than one bandwidth test at once to see if I could fill up the pipes with more data. After getting my timing right (I kept starting one test well before the other), we were able to show that both pipes were indeed being load balanced, but for whatever reason, the speed tests would "sense" a limit at the 1 T1 barrier. Running multiple speed tests showed that just as much bandwidth was available down as it was up - i.e. just under 3 mbit/s. John was able to confirm that data was being sent down both pipes - one being favored by about 2% over the other. We chalked this up to "imperfect" round-robin'ing and called it a day. To this day, I still have not been able to figure out why the speed tests show outbound limited by one T1, but I don't really care as long as my available outbound is really the two T1's. I'm sure a ttcp test would be a better measure of throughput, but I haven't had the time to run such tests and am content that things are working as advertised.
After closing the firewall by enabling the default deny rules, I started working on allowing inbound connections. I struggled quite a bit with ssh. So much so that I finally emailed the OpenBSD misc list. I never did get a response to my question - I never really expected to seeing as I doubted many people were trying to do what I was and I further figured that they would pass my query off as being that of someone who failed to read the manual. They were wrong... I read the manual over and over but was never able to wrap my head around setting up the rules such that I could pass ssh through after default denying everything (I did confirm that ssh worked without the firewall...) So, I set out to test this through trial-and-error. Finally, after 5 hrs of testing, I came up with:

pass log quick on { $int_if, $ext_if1, $ext_if2 } inet proto tcp from any to \
     any port 22 flags S/SA keep state

This was the culmination of so many combinations of pass etc. I feign to write them all down out of sheer embarrassment. How simple and elegant it ended up being...
There are a number of other ports I ended up opening. There are also a few clients behind the T1 who want their IP's completely open. I was able to accomplish all of this with the following ruleset:

# define the interfaces
lan_net = "24.192.154.1/24"
int_if  = "fxp0"
ext_if1 = "wpachdlc0"
ext_if2 = "wpbchdlc0"
ext_gw1 = "22.109.101.233"
ext_gw2 = "22.222.9.161"

# a few macros
icmp_types = "echoreq"

priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"

## define all of the open hosts
open_hosts = "{ 24.192.154.15, 24.192.154.9 }"

## define some servers
dns_servers = "{ 24.192.154.3, 24.192.154.6 }"
email_servers = "{ 24.192.154.21 }"
http_servers = "{ 24.192.154.11 }"
# scrub all
scrub in all

# default deny
block log all

# pass all on internal loop
pass quick on lo0 all

# block spoofing from external interfaces
block drop in log quick on { $ext_if1, $ext_if2 } from $priv_nets to any
block drop out log quick on { $ext_if1, $ext_if2 } from any to $priv_nets

# allow ssh
pass log quick on { $int_if, $ext_if1, $ext_if2 } inet proto tcp from any to \
    any port 22 flags S/SA keep state

# allow dns
pass quick on { $int_if, $ext_if1, $ext_if2 } inet proto udp from any to \
    $dns_servers port 53

# allow mail
pass quick on { $int_if, $ext_if1, $ext_if2 } inet proto tcp from any to \
    $email_servers port 25 flags S/SA keep state

# allow traffic to httpd servers
pass quick on { $int_if, $ext_if1, $ext_if2 } inet proto tcp from any to \
    $http_servers port 80 flags S/SA keep state

# define the non-firewalled hosts
pass quick on { $int_if, $ext_if1, $ext_if2 } inet proto tcp from any to \
    $open_hosts flags S/SA keep state
pass quick on { $int_if, $ext_if1, $ext_if2 } inet proto udp from any to \
    $open_hosts

# allow icmp
pass inet proto icmp all icmp-type $icmp_types keep state

# pass all outgoing packets on internal interface
pass out on $int_if from any to $lan_net

# pass in quick any packets destined for the gateway itself
pass in quick on $int_if from $lan_net to $int_if

# load balance tcp
pass in on $int_if route-to \
    { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
    proto tcp from $lan_net to any flags S/SA modulate state

# load balance udp and icmp
pass in on $int_if route-to \
    { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
    proto { udp, icmp } from $lan_net to any keep state

# general "pass out" rules for external interfaces
pass out on $ext_if1 proto tcp from any to any flags S/SA modulate state
pass out on $ext_if1 proto { udp, icmp } from any to any keep state
pass out on $ext_if2 proto tcp from any to any flags S/SA modulate state
pass out on $ext_if2 proto { udp, icmp } from any to any keep state

# route packets on external interfaces through the appropriate
# gateway
pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 \
     to any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 \
    to any


I realize that these rules can be redundant and must be rewritten in a much more efficient manner. That is what I am in the middle of working on. I hope, though, that these will help guide you to set the firewall and routing rules for your needs.
Remaining Problems:
One other item that needs to be cleaned up is having the rules loaded after the T1 interfaces are activated at boot time. This process usually is finished 45-60 seconds after the machine is fully booted. This means that if there is a power failure or problem with the machine and it reboots, one has to physically re-set the default gateway and load the rules. I don't understand enough of OpenBSD to make this happen, but when I do, I'll tell you how it is done.

HTH,
Steve

* In between all of this, I had given up on using pf for load balancing because of what I had seen as problems with pf - I was mistaken at the time, but I was convinced the problem was with pf and not with what I was seeing. I unwrapped a brand new Cisco 1721 and two T1 interfaces from a box - my just in case box - and spent eight hours trying to get it working. Fortunately, I was never able to bring up the circuits with the Cisco. I say fortunately because I ended up back with the BSD box and got it working - what I wanted in the beginning.

May 12, 2005

FiOS/Fiber to Curb - Why not Me?

Owning a small broadband ISP has produced its own series of experiences I never imagined having - and thoughts I never imagined coming from my own person. (For example, I never thought the day would come when I would say 3 Mbit/s is good enough because the cost of increasing said bandwidth is prohibitively expensive.) Reading Verizon hits the gas on fiber campaign (from CNet) started me thinking again about how technology will affect where people live just as the industrial revolution did. I have my doubts it will be as severe as what we have learned about the effects of industrialization - e.g. people moving to the city to specialize in careers instead of being general handymen with no real talent - but many of the choices and opportunities people in my generation have relates to the technology to which they have relatively cheap access. With Verizon's move to bring fiber (enabling a blinding amount of media and data to be efficiently transported to a home or business) to small areas of large communities, it makes me wonder how I can work to bring that type of advanced technology to the neighborhoods I serve. From a business and practical standpoint, delivering the kind of reliability fiber offers without the fiber is a daunting task. Already with our 900MHz and 5.7GHz services, it is difficult to tell what type of RF interference the day is going to bring. Licensed technologies are almost as daunting as trying to use wired technologies. Both require working with bureaucrats and getting licensing to do something that I am doing for more altruistic reasons than the money. Sure, there is some money in providing these types of technologies to people, but nobody wants to pay the real price and you are required - as an operator - to give your business customers the harder end of the bargain. I have a hard time with this type of marketing. I am often inclined at changing midstream and simply marketing to businesses again. I say to myself, however, that the children of our community deserve better. The opportunities that technology brings is staggering if nurtured and used in the correct manner - i.e. learning about your surrounding world instead of looking up porn or playing the latest mindless video game. (Didn't you hear that IM'ing makes you 10 IQ points dumber? [hint sarcasm])
What it boils down to is this: the cost of true broadband services (i.e. DS3) is still prohibitively expensive. I as a second/third tier ISP would love to have that type of connectivity to relay it to our customers (of which, there are very few who actually use much bandwidth). The aggregate cost of supplying ISP's like myself bandwidth is lower than one could imagine due to the fact that so much remains as available excess. Verizon wouldn't be forced to spend billions on ripping up streets. They could spend tens of thousands to provide access to customers like myself who can in turn bring the broadband dream to others.
Hopefully the continued advances in technology will make this possible. If not, we may see another type of industrialization to population movement just because of the internet.

June 21, 2005

You may never find out, but thanks!

We're (Steffi and I) in Amsterdam (the Netherlands, for those who may be geographically challenged) visiting Kathrin and lo and behold, a free wireless network with a fast connection to the net. Whoever is running "battle of waterloo" around Wilhelminastraat 191, I'd love to give you a hug. You've made my week.

August 10, 2005

Treo 650 w/ OpenBSD 3.7-current - Wireless Modem

I have been working on different ways of getting my X40 (ThinkPad), which runs OpenBSD 3.7-current, connected to SprintPCS's CDMA2K network. On other machines, like my PowerBook, I simply use a bluetooth connection to the Treo (650) or a Moto V710. Bluetooth use under OpenBSD is still beyond me (I haven't had the time to see or try to understand how it works), so I decided to go back to the old days and use the USB cable. I came across using a treo 600 with openbsd, which led be to believe the same thing should work with the 650. Last night I got started by trying to better understand pppd under OpenBSD and how to properly configure the serial/usb device that you need to use to connect to the Treo (or any other type of wireless PC Card, for that matter). The example given at jcs's:


sprintpcs:
   set device /dev/ttyU1
   set speed 115200
   set phone "#777"
   set dial "TIMEOUT 30 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT"
   add! default HISADDR

of using device /dev/ttyU1 is only the correct device if your machine sees the USB device as:

uvisor0 at uhub1 port 1
uvisor0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2
ucom0 at uvisor0 portno 1: portno 1, Generic
ucom1 at uvisor0 portno 2: portno 2, HotSync

In my case the line that has been darkened shows portno 0: portno 0, so I needed to change set device /dev/ttyU1 to set device /dev/ttyU0. Yes, this is very obvious, unless you are not looking like I wasn't last night. As the page recommended, I pushed the hotsync button to test whether or not I could get the device to attach to the other side of the ppp link before the hotsync timed out and I couldn't . Everything looked like it was working as jcs had mentioned, but it seemed as if the hotsync kept timing out too quickly. So, I found my old, trusty copy of wmodem from NotifyMail and tried it out but kept getting errors that wmodem couldn't connect to the serial device.
Stupid me... I had the Laptop Connected Via: set to Wireless Modem and not usbd (which is the port I found works correctly - you have number of options and only by watching dmesg on the laptop was I able to figure out which port should be used). The Cradle port does not work.

So, to put this all together, here is what you need:
- Laptop with OpenBSD 3.7 (according to jcs's page, it sounds like this works in 3.5+)
- Free USB Port
- Sync Cable or Cradle
- wirelessmodem from NotifyMail

Configure /etc/ppp/ppp.conf:


sprintpcs:
   set device /dev/ttyU0
   set speed 115200
   set phone "#777"
   set dial "TIMEOUT 30 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT"
   add! default HISADDR

Turn on wireless modem and enable modem. And type:

$ sudo ppp -background sprintpcs

You should see:

Working in background mode
Using interface: tun0
Warning: No default entry found in config file.
PPP enabled

and away you go. I'll get jcs's permission to copy more of the info from his site and post it here, but this should at least get you up and running.

March 3, 2006

Fly-by Tech Notes: Q, MacBook Pro, AFPoverTCP on 802.11g Performance

While its late - so late that I should have been asleep a few hours ago, I have been toying with so many things over the past few weeks that I had to finally do some fly-by note taking:
Q: this is the latest QEMU emulator available for OS X (at Q [kju:]) and it rocks. I bought a new MacBook Pro - I couldn't wait for rev2 because I was dying to see how Intel performed (notes below) and the performance of OpenBSD under Q on OS X is fantastic. The only thing I still can't figure out is networking and why I can't get packets past the emulator, but I'll have to do more digging on that one later. As far as performance of moving around the system, adding packages, etc. is concerned, it is very impressive. Considering my thoughts under the PowerBook (even the 1.67GHz model) was less than appealing, I am happy (and the fact the VirtualPC won't work on the new Intel machines - and I'm not sure given my recent bout of problems with that application that I will invest in it again).
MacBook Pro: I love it. Period. People are complaining about different items missing from the hardware like the S-Video connection and modem. I could care less (modem... well, I do a bit, but not too much). The machine is stellar. I like the built-in iSight (yes, I actually use it) and the speed. No, not the speed with regards to non-universal apps - especially Microsoft Office and Adobe products. Yuck. The performance is no better than my PowerBook. Where I notice the difference is on Intel native (i.e. universal) applications and especially on unix related stuff that I compile. I honestly think the performance on compiling ports (vis a vis darwinports.org) is better than on my dual 2.0 G5. I haven't actually timed anything - yet - but it has thoroughly amazed me. I'm happy all around and hope to do more writing on the topic later.
AFPoverTCP: i.e. Apple native file sharing on an 802.11g network. Quick quips: Stream DVD's? Not unless you really monkey with buffer settings in VLC (set file buffering to 10,000 ms). At least it is not consistent. I really don't know what Apple is going to do to make streaming video over 802.11g any good. Unless they tweak all of their media programs to do better buffering, people will be sorely disappointed if they think they are going to network a small army of Mac Minis together to create a hodge-podge video and content streaming network. The throughput is so inconsistent (even if I'm sitting 2 ft. from the AP) that DVD's often drop out and/or become choppy. I finally tweaked VLC enough to get it working to my satisfaction, but that is not for Joe-Mac-User. I really can't figure out how Apple has let afp performance slide so horribly. Even when looking at file transfer performance on a gigabit network, the best I see is 367mbps on file transfers (yes, single large files). That is some overhead... ridiculous. I'm going to look more into seeing if there are system related tweaks one can make to get better performance out of the built-in networking devices, but who knows. With the theoretical speeds of today's networks, a lot of what we want to do should be possible - i.e. stream high(er) definition video content from machine to machine. Unfortunately, instead of focusing on making things better, we're stuck with developers and companies trying to add some new, unneeded button to already good hardware. 17mbps of real throughput on [advertised as] 54mbps network gear is ridiculous. That equates to around 2mBps - just around what a DVD showing full color frames will stream at. I love living on the edge...

March 13, 2006

"hacking" the network at the Atlantis (Nassau, Bahamas)

I thought I'd catch the attention of people with a somewhat out-of-line title. What I'm going to describe actually isn't anything that I did to do something that I wasn't paying for or that the Atlantis last week. I just figured out ways around the fact that you couldn't access the internet with your laptop in our hotel room. I should also note that this may not work in different parts of the Atlantis - the hotel is enormous and really is three or four hotels in one (something that made the trip all the more interesting) - it worked great in the Royal Towers and specifically the Imperial Club. One of the nicest things about the hotel, though, was that they had wifi where it counts: outside, at the pools and in a lot of the open lounge areas throughout the hotel. (The only thing they did wrong from a technical standpoint was overlapping 802.11b/g network channels all over the place - sometimes making it impossible to grab a good signal even if you were close to the AP.) I wrote the hotel back in January to figure out whether or not they had high speed access and they answered with:

"Dear Steve,

An adventure awaits you, inspired by the ocean and myth of the lost
continent.
Here are the details on Atlantis & Harborside Resorts’ internet services
presently offered.
Standard Guest Room Dial-up Service
• Standard Dial-up Service is available in guest rooms. $.50 per minute
upon connection.
• The fee is billed directly to the guest's room to be paid in full
at check-out.
• Bring your own modem cable to plug into the data port near the
phone.
• Instructions to connect are posted in all guest rooms.
Wireless Service
• Available at the Beach Tower lobby, Coral Lounge, Plato's Lounge and all
pool decks including Harborside Resort.
• A flat fee of $10 for up to 24 hours of service will be charged to the
guest's credit card
Complimentary Internet Access
• Available for 15 minutes per day, per person at 4 Stations in the Coral
Towers Library and Imperial Club Lounge.

* All prices, features, options and availability of Atlantis Internet
Services including “Dial-up, Wireless and Complimentary,” are subject to
change and availability at anytime without notice..."

Dial-up for $.50 a min? That's crazy talk - though not as crazy as the $1.00/min. I paid while on Grand Cayman some years ago. (I was happy with everything else, though.) What really got me, though, was the fact that wireless service was available everywhere but my room. So, being the wireless hack I am, I packed a 9 dBm 2.4GHz omni antenna, pigtails and two travel routers I have (the Linksys WRT54GC (no link because linksys.com isn't loading correctly, again) and the D-Link DWL-G730AP) hoping that because our rooms overlooked some of the pool decks that I'd be able to pull a signal from there and "bounce" it into my room ;) Steph was thrilled as she saw me pack everything... What I didn't realize was that the Linksys could not be set to client mode, so the omni and pigtails were no good. Plus, I didn't bring a 12' extension cord like I normally do - making it difficult to hang the D-Link over the side of the balcony. As a side note, I had to laugh as I was packing the omni into my bag - it looks like a pipe bomb unless you know what it is (and are oblivious to the N connector on the end of it), so I used a magic marker and wrote 2.4 GHz Antenna all over it to make sure that if someone unpacked it, they would come to their senses if they had any questions - and, of course, it would scan like a pipe with a piece of wire in it.
Well, the first thing I did when we got to our room was pull out the OQO (trying to be discrete so as to not anger Steph) and see if I could grab a wireless signal from our balcony. No dice. I didn't have anything urgent to do, so I left well enough alone and decided to experiment later. Later, when Steph was taking a nap, I took out the D-Link (which can be powered from your USB port), hooked it up to my MacBook and hung it over the balcony to see if directionality of the antenna had to be such to grab a signal. Again, no dice. I looked around the room to see if they had anything for broadband set up, but just hidden. I saw an RJ-45 jack, but decided not to play because I couldn't trace what it was going to and I had burnt out a NIC in the past "testing" a jack only to find that it was powered weird and my NIC couldn't handle it. Later, at the pool, I pulled the "pid-guest" ssid fine, hopped on, paid my $10 for 24/hrs and went to town. For all the problems we had with the telephone system at the Atlantis (it sucks, by the way - the phones are crackly, they don't hang up properly and a call to the States is $3/min. even using a Global Crossing calling card), the internet connection was blazing fast. Down by the pools, I was getting 3-6mbps up and down. (This is where I learned to use Gizmo and love it - and hate Skype.) Now that my wireless MAC was registered, I figured I could squeak out a signal from the room. I was right - only half of the time, though. With my MacBook perched as in the photo, I was only able to grab a signal sometimes (having to do with the overlapping network problems). Laptop BalconyBut, when I needed it, it worked, and if not, I went to the pool - which was the whole purpose of the vacation to begin with!
A bug got in me a few days before we left, though, to figure out how their IPTV stuff worked. So, I moved the hutch that the television (a 32" LG LCD - nice) perched on and took a peek at all of the wiring. Lo and behold! There was a VIA mini-itx PC mounted to the back of the hutch and controlled some of the streaming media and internet-over-tv stuff that they had set up. Ironically, I found out where that RJ-45 jack I had initially seen led to: a NIC labeled laptop on the mini-pc. The main NIC was being used to connect to what appeared to be a network. So, I started playing. The main jack to the room must be set up so that each computer grabs a statically assigned IP from the hotel network because while the connection went active on the MacBook, I wasn't able to pull an IP. I also wasn't able to figure out what subnet they were running on. On the other side of the mini-pc, though, when I plugged into the laptop NIC, I got an address and a gateway. A lot of times, the cheap and easy way for a hotel or airport to keep you from using their network for internet access is by not setting up DNS via the DHCP services. So, in order to grab a site, you have to know the IP or use your own DNS caching server. (Not a problem when you own a few, like me - or if you have a caching server set up on your laptop, like me.) I tested to see whether I could ping some known gateways, like that of Anywhere Technology or some boxes I know the IPs to on the net. What was really odd is that pings would go through, but the connection would be really, really lossy. So, it wasn't DNS. After playing for a bit, I opened up a browser window to see if anything would come up. To my delight a window showing a log-in screen and you-are-going-to-pay-for-this option. So, I tried to say okay to the $10/day charge and see if data would be routed correctly. Something went wrong every which way. Finally, it occurred to me that I had seen an internet-over-your-tv screen on the tv and went to look and see what was there. In the spendy mood, I okayed the $10/day charge to my room to access the internet via the tv and an IR keyboard they had. Mozilla popped up and I tested going to a few sites - and it worked. (The mini-pc was running some customized form of Linux that I had no desire to further figure out.) With general browsing working, I plugged the Linksys router into the secret laptop/RJ-45 port that I had seen when we first got there, got an IP on the router and went to town again... Nice. The only trick you had to figure out was how to get the min-pc to pass data - and that was easy - set up internet service through the television interface and suddenly your hidden RJ-45 jack becomes useful. Whew... that was a lot of work just to get on the net for a few days - all when I really only cared about it outside anyway. It was worth it, though. The connection was ridiculously fast - I ran a speed test a few times to Speakeasy in Atlanta (I learned that was one of the cable termination points to the undersea cables going to the Bahamas) and got 16mbps up and down. Hot damn... I've been on a connection that fast only a few times in my life and ironically, I had nothing to download ;) (Having ran and owned an ISP, I don't like to download crap just because.... I like having a purpose/reason.)
So, I effectively hacked the hotel networks in the room so that I could get internet in bed, which is what I didn't care about anyway. (Maybe this should really be labeled a "workaround.") Next time we go, I'll not only know better, but I'll bring some different gear so that I can simply use either the room connection or the one by the pool. It is nice to know, though, that the connections are reliable and available. I saved myself the $3/min phone calls by using Gizmo and paying $.01/min for my calls to the States. That's another thing I'm happy for - VoIP - but that's another story.

About Wifi/Wireless

This page contains an archive of all entries posted to steven n fettig's Jitterin' Thoughts in the Wifi/Wireless category. They are listed from oldest to newest.

photography is the previous category.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.33