Re: [9fans] Wirelss bitsy peers?

[Dan Cross <cross@math.psu.edu>]

In article <20010909141831.8084E199EC@mail.cse.psu.edu> you write:
>Yes, we have run the bitsies in ad hoc mode, typically connected to a laptop.
>We would run a dhcp daemon, auth server, and file server on the laptop.
>We did not try to reconfigure ad hic mode dynamically; i.e., we configured
>the card ad hoc at start-up time.  I'm almost sure we had crypto turned off.
>
>Somebody at the labs tried to connect a bitsy to a Linux box in ad hoc mode.
>I don't know the exact details, but I gather he could not get Linux to run ad
>hoc without configuring it for a base station first; in other words, he had to
>do the Linux ad hoc config in the presence of a base station.  That's not too
>useful.

Thanks Sape, for the info; this helps out a bit.  As it turns out, what
I really want isn't ``adhoc'' mode, but IBSS mode.  Apparantly, adhoc was
a proprietary Lucent thing for demos using the wavelan cards, and support
for that mode is absent from newer orinoco cards.  Apparantly, IBSS is
the IEEE sanctioned One True Way to do peer-to-peer 802.11b networks.  At
anyrate, I couldn't get the bitsy to talk to another iPAQ running
Win-no-goes CE.

However, I was able to crib the information on putting the card into IBSS
mode from the BSD driver, and make the necessary changes (which are minimal)
to the Plan 9 driver.  After doing so, everything appears to work, and I
am now talking to all sorts of devices (iPAQ's, a laptop running Windows
2000, an HP Jornada, etc).  I'm not entirely certain that everything is
quite right yet, though, because I'm doing all this in close proximity to
a base station (I just need to get up the energy to walk to a near-by park
and test there).

Anyway, here is a diff for the ibss patches, plus a fix from the PC
wavelan driver for not using ctlr->txkey to decide wether to print
keys in ifstats):

diff -n /n/dump/2001/0906/sys/src/9/bitsy/etherwavelan.c /sys/src/9/bitsy/etherwavelan.c
/n/dump/2001/0906/sys/src/9/bitsy/etherwavelan.c:108 a /sys/src/9/bitsy/etherwavelan.c:109
> 	WTyp_CreateIBSS	= 0xfc81,
/n/dump/2001/0906/sys/src/9/bitsy/etherwavelan.c:276 a /sys/src/9/bitsy/etherwavelan.c:278
> 	int	createibss;
/n/dump/2001/0906/sys/src/9/bitsy/etherwavelan.c:539 a /sys/src/9/bitsy/etherwavelan.c:542
> 	ltv_outs(ctlr, WTyp_CreateIBSS, ctlr->createibss);
/n/dump/2001/0906/sys/src/9/bitsy/etherwavelan.c:916 c /sys/src/9/bitsy/etherwavelan.c:919
< 	if (ctlr->txkey){
---
> 	if (ctlr->hascrypt){
/n/dump/2001/0906/sys/src/9/bitsy/etherwavelan.c:1036 a /sys/src/9/bitsy/etherwavelan.c:1040,1045
> 	else if(cistrcmp(cb->f[0], "ibss") == 0){
> 		if(cistrcmp(cb->f[1], "on") == 0)
> 			ctlr->createibss = 1;
> 		else
> 			ctlr->createibss = 0;
> 	}
/n/dump/2001/0906/sys/src/9/bitsy/etherwavelan.c:1196 a /sys/src/9/bitsy/etherwavelan.c:1206
> 	ctlr->createibss = 0;

Sape also wrote:
>On the bitsy, in the params page, set
>	wvmode=adhoc
>	wvcrypt=off

Okay; one thing I noticed is there there are some errors in
/sys/src/9/bitsy/sacfiles/cpurc; in particular, what is echoed into
/net/ether0/clone for ``wvmode'' is `txkey xxx', not `mode xxx', which
is not correct.  Also, mode should be set before the nework name,
otherwise the wrong driver-internal variable is set.  Finally, I added
the ``wvibss'' variable to control wether or not one is using IEEE
peer-to-peer networking.  A patch follows:

diff -n /n/dump/2001/0909/sys/src/9/bitsy/sacfiles/cpurc /sys/src/9/bitsy/sacfiles/cpurc
/n/dump/2001/0909/sys/src/9/bitsy/sacfiles/cpurc:98 a /sys/src/9/bitsy/sacfiles/cpurc:99,104
> 	switch($wvmode){
> 	case ''
> 		;
> 	case *
> 		echo -n 'mode '^$wvmode >/net/ether0/clone
> 	}
/n/dump/2001/0909/sys/src/9/bitsy/sacfiles/cpurc:111 c /sys/src/9/bitsy/sacfiles/cpurc:117
< 	switch($wvmode){
---
> 	switch($wvibss){
/n/dump/2001/0909/sys/src/9/bitsy/sacfiles/cpurc:115 c /sys/src/9/bitsy/sacfiles/cpurc:121
< 		echo -n 'txkey '^$wvmode >/net/ether0/clone
---
> 		echo -n 'ibss '^$wvibss >/net/ether0/clone


Sape also wrote:
>You can set
>	ipaddr=n.n.n.n
>	ipmask=255.255.255.0
>	auth=n.n.n.n
>	dns=n.n.n.n
>	dnsdomain=xxx.com
>if you don't want to use dhcp

Yes, I definately don't want to do DHCP, and so am doing the above.

Actually, the application of this particular bitsy is kind of neat;
we're doing a demo where we're setting up a wireless network and
connecting it to our office LAN via a dial-up PPP connection thru a
cell phone into a portmaster (SprintPCS will sell you a serial cable
to connect your phone to a serial port; most phones have 14.4kbps
Hayes compatible modem built in; con will allow you to talk to it).

At first, the team doing all this wanted to use a laptop running
Windows 2000 as a router, but I brought up the idea of using a bitsy
running Plan 9 to do it, and everyone thought it would be really cool,
so we went out and bought one, and I installed Plan 9 on it and got
it configured and mostly working.  Having the wavelan talk to the
other devices (most of which are running Windows CE) was enough to
allow me to test it, but it's really, really slow (latencies near
one second are normal, and above one second is not unusual).  The
bandwidth and latency, however, is just fine for the application we
want to demo on it.

However, I have another problem in that ip/ppp keeps crashing (usually
taking the rio window it's running in with it, so I can't see any
residual log messages).  I used to see something similar with my
ricochet wireless modem, but haven't messed with PPP under Plan 9
since well before metricom went out of business.  :-(  If anyone knows
of any weak points in ip/ppp please let me know and I'll take a look
at them.  Unfortunately, if I don't get this working within the next
hour or so, I've been told that I'll have to put Linux on the bitsy
for the demo.  :-(

That would be a bummer, because Plan 9 is just so much cooler.

	- Dan C.