* Re: [9fans] Wirelss bitsy peers? @ 2001-09-09 14:22 Sape Mullender 2001-09-09 19:23 ` Dan Cross 0 siblings, 1 reply; 5+ messages in thread From: Sape Mullender @ 2001-09-09 14:22 UTC (permalink / raw) To: 9fans [-- 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] Wirelss bitsy peers? 2001-09-09 14:22 [9fans] Wirelss bitsy peers? Sape Mullender @ 2001-09-09 19:23 ` Dan Cross 0 siblings, 0 replies; 5+ messages in thread From: Dan Cross @ 2001-09-09 19:23 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] Wirelss bitsy peers?
@ 2001-09-09 20:20 David Gordon Hogan
2001-09-10 1:57 ` Dan Cross
0 siblings, 1 reply; 5+ messages in thread
From: David Gordon Hogan @ 2001-09-09 20:20 UTC (permalink / raw)
To: 9fans
> 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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] Wirelss bitsy peers? 2001-09-09 20:20 David Gordon Hogan @ 2001-09-10 1:57 ` Dan Cross 0 siblings, 0 replies; 5+ messages in thread From: Dan Cross @ 2001-09-10 1:57 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [9fans] Wirelss bitsy peers? @ 2001-09-09 0:20 Dan Cross 0 siblings, 0 replies; 5+ messages in thread From: Dan Cross @ 2001-09-09 0:20 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-09-10 1:57 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-09-09 14:22 [9fans] Wirelss bitsy peers? Sape Mullender 2001-09-09 19:23 ` Dan Cross -- strict thread matches above, loose matches on Subject: below -- 2001-09-09 20:20 David Gordon Hogan 2001-09-10 1:57 ` Dan Cross 2001-09-09 0:20 Dan Cross
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).