Re: [9fans] Wirelss bitsy peers?

Re: [9fans] Wirelss bitsy peers?

[David Gordon Hogan]

> 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).

Is it leaving a Broken process behind?  Can you do a snap(4)
and send me the snapshot as an attachment?

Re: [9fans] Wirelss bitsy peers?

[Dan Cross]

In article <20010909202053.B995319A16@mail.cse.psu.edu> you write:
>> 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).
>
>Is it leaving a Broken process behind?  Can you do a snap(4)
>and send me the snapshot as an attachment?

No, unfortunately, it was leaving nothing behind.  :-(  However, on
the bright side, I was a) wrong that ppp was crashing in the sense of
a suicide (though it was terminating), and b) I seem to have `fixed'
it (or at least, made the problem significantly less acute).

As I understand it, what was happening is that the terminate() routine
in /sys/src/cmd/ip/ppp/ppp.c was being called with the ``kill'' argument
set to 1 (as would happen when either mediainproc() or ipinproc()
returns; in this case, mediainproc() was returning).

Anyway, what happens in this case is that terminate() calls
postnote(PNGROUP, getpid(), "die");, which I believe is intended to kill
the ppp worker processes that are forked at some point.  This was what
was killing the rio window (or probably just rc; I didn't bother to check
much further after realizing that it was making the rio window ``go
away'').  Commenting out the call to postnote made the rio window stick
around.

As it turns out, mediainproc() was returning because pppread() was
returning nil.  In turn, pppread() was returning nil because getframe()
was returning nil.  Here's where I inserted my `fix'; instead of just
returning as soon as getframe() returns nil, I added a loop so that
getframe() is called from one to five times.  Frequently, it seems
that getframe() needs to be called twice before something actually
comes back (a read() inside getframe() is returning something weird
in this case), so the loop is masking whatever is wrong.  For this
particular demo, that's just fine with me, but I don't know that this
is a good long-term fix.  Maybe.

At anyrate, I'm happy to report that my bitsy now is passing adhoc
packets between a wireless LAN and a PPP link set up through a cell
phone on behalf of a dorky Windows CE application.  The Bitsy sure
is cool in this capacity (I'd even have room in my apartment for a
router this size!), even if the WinCE application is not.  :-)

Yea; it looks like we can use Plan 9 for this demo instead of Linux.

	- Dan C.

Re: [9fans] Wirelss bitsy peers?

[Sape Mullender]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

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.

On the bitsy, in the params page, set
	wvmode=adhoc
	wvcrypt=off
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

	Sape


[-- Attachment #2: Type: message/rfc822, Size: 1721 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] Wirelss bitsy peers?
Date: Sat, 08 Sep 2001 20:20:18 -0400
Message-ID: <200109090020.UAA09410@math.psu.edu>

Hey everyone,
   Has anyone ever tried to use a Bitsy in a wireless peer-to-peer
802.11b network (that is, an ad-hoc network, with ``mode adhoc'' being
echoed to the appropriate place)?  I'm trying to set this up for a
demo, but can't quite seem to get it to go.  Looking at the code (and
comparing against the BSD code) I don't see where the distinction
really matters that much, but it's not working.  Thanks for any info!

	- Dan C.

Re: [9fans] Wirelss bitsy peers?

[Dan Cross]

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.

[9fans] Wirelss bitsy peers?

[Dan Cross]

Hey everyone,
   Has anyone ever tried to use a Bitsy in a wireless peer-to-peer
802.11b network (that is, an ad-hoc network, with ``mode adhoc'' being
echoed to the appropriate place)?  I'm trying to set this up for a
demo, but can't quite seem to get it to go.  Looking at the code (and
comparing against the BSD code) I don't see where the distinction
really matters that much, but it's not working.  Thanks for any info!

	- Dan C.