mirror of https://gitee.com/openkylin/linux.git
uwb: add initial documentation
Documentation (and example utilities) for the UWB (and WUSB) stacks. Some of the documentation may be out-of-date. Signed-off-by: David Vrabel <david.vrabel@csr.com>
This commit is contained in:
Inaky Perez-Gonzalez
David Vrabel
parent
ccbe329bcd
commit
99d368bc9e
|
|
@ -0,0 +1,448 @@
|
|||
|
||||
Linux UWB + Wireless USB + WiNET
|
||||
|
||||
(C) 2005-2006 Intel Corporation
|
||||
Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License version
|
||||
2 as published by the Free Software Foundation.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
|
||||
02110-1301, USA.
|
||||
|
||||
|
||||
Please visit http://bughost.org/thewiki/Design-overview.txt-1.8 for
|
||||
updated content.
|
||||
|
||||
* Design-overview.txt-1.8
|
||||
|
||||
This code implements a Ultra Wide Band stack for Linux, as well as
|
||||
drivers for the the USB based UWB radio controllers defined in the
|
||||
Wireless USB 1.0 specification (including Wireless USB host controller
|
||||
and an Intel WiNET controller).
|
||||
|
||||
1. Introduction
|
||||
1. HWA: Host Wire adapters, your Wireless USB dongle
|
||||
|
||||
2. DWA: Device Wired Adaptor, a Wireless USB hub for wired
|
||||
devices
|
||||
3. WHCI: Wireless Host Controller Interface, the PCI WUSB host
|
||||
adapter
|
||||
2. The UWB stack
|
||||
1. Devices and hosts: the basic structure
|
||||
|
||||
2. Host Controller life cycle
|
||||
|
||||
3. On the air: beacons and enumerating the radio neighborhood
|
||||
|
||||
4. Device lists
|
||||
5. Bandwidth allocation
|
||||
|
||||
3. Wireless USB Host Controller drivers
|
||||
|
||||
4. Glossary
|
||||
|
||||
|
||||
Introduction
|
||||
|
||||
UWB is a wide-band communication protocol that is to serve also as the
|
||||
low-level protocol for others (much like TCP sits on IP). Currently
|
||||
these others are Wireless USB and TCP/IP, but seems Bluetooth and
|
||||
Firewire/1394 are coming along.
|
||||
|
||||
UWB uses a band from roughly 3 to 10 GHz, transmitting at a max of
|
||||
~-41dB (or 0.074 uW/MHz--geography specific data is still being
|
||||
negotiated w/ regulators, so watch for changes). That band is divided in
|
||||
a bunch of ~1.5 GHz wide channels (or band groups) composed of three
|
||||
subbands/subchannels (528 MHz each). Each channel is independent of each
|
||||
other, so you could consider them different "busses". Initially this
|
||||
driver considers them all a single one.
|
||||
|
||||
Radio time is divided in 65536 us long /superframes/, each one divided
|
||||
in 256 256us long /MASs/ (Media Allocation Slots), which are the basic
|
||||
time/media allocation units for transferring data. At the beginning of
|
||||
each superframe there is a Beacon Period (BP), where every device
|
||||
transmit its beacon on a single MAS. The length of the BP depends on how
|
||||
many devices are present and the length of their beacons.
|
||||
|
||||
Devices have a MAC (fixed, 48 bit address) and a device (changeable, 16
|
||||
bit address) and send periodic beacons to advertise themselves and pass
|
||||
info on what they are and do. They advertise their capabilities and a
|
||||
bunch of other stuff.
|
||||
|
||||
The different logical parts of this driver are:
|
||||
|
||||
*
|
||||
|
||||
*UWB*: the Ultra-Wide-Band stack -- manages the radio and
|
||||
associated spectrum to allow for devices sharing it. Allows to
|
||||
control bandwidth assingment, beaconing, scanning, etc
|
||||
|
||||
*
|
||||
|
||||
*WUSB*: the layer that sits on top of UWB to provide Wireless USB.
|
||||
The Wireless USB spec defines means to control a UWB radio and to
|
||||
do the actual WUSB.
|
||||
|
||||
|
||||
HWA: Host Wire adapters, your Wireless USB dongle
|
||||
|
||||
WUSB also defines a device called a Host Wire Adaptor (HWA), which in
|
||||
mere terms is a USB dongle that enables your PC to have UWB and Wireless
|
||||
USB. The Wireless USB Host Controller in a HWA looks to the host like a
|
||||
[Wireless] USB controller connected via USB (!)
|
||||
|
||||
The HWA itself is broken in two or three main interfaces:
|
||||
|
||||
*
|
||||
|
||||
*RC*: Radio control -- this implements an interface to the
|
||||
Ultra-Wide-Band radio controller. The driver for this implements a
|
||||
USB-based UWB Radio Controller to the UWB stack.
|
||||
|
||||
*
|
||||
|
||||
*HC*: the wireless USB host controller. It looks like a USB host
|
||||
whose root port is the radio and the WUSB devices connect to it.
|
||||
To the system it looks like a separate USB host. The driver (will)
|
||||
implement a USB host controller (similar to UHCI, OHCI or EHCI)
|
||||
for which the root hub is the radio...To reiterate: it is a USB
|
||||
controller that is connected via USB instead of PCI.
|
||||
|
||||
*
|
||||
|
||||
*WINET*: some HW provide a WiNET interface (IP over UWB). This
|
||||
package provides a driver for it (it looks like a network
|
||||
interface, winetX). The driver detects when there is a link up for
|
||||
their type and kick into gear.
|
||||
|
||||
|
||||
DWA: Device Wired Adaptor, a Wireless USB hub for wired devices
|
||||
|
||||
These are the complement to HWAs. They are a USB host for connecting
|
||||
wired devices, but it is connected to your PC connected via Wireless
|
||||
USB. To the system it looks like yet another USB host. To the untrained
|
||||
eye, it looks like a hub that connects upstream wirelessly.
|
||||
|
||||
We still offer no support for this; however, it should share a lot of
|
||||
code with the HWA-RC driver; there is a bunch of factorization work that
|
||||
has been done to support that in upcoming releases.
|
||||
|
||||
|
||||
WHCI: Wireless Host Controller Interface, the PCI WUSB host adapter
|
||||
|
||||
This is your usual PCI device that implements WHCI. Similar in concept
|
||||
to EHCI, it allows your wireless USB devices (including DWAs) to connect
|
||||
to your host via a PCI interface. As in the case of the HWA, it has a
|
||||
Radio Control interface and the WUSB Host Controller interface per se.
|
||||
|
||||
There is still no driver support for this, but will be in upcoming
|
||||
releases.
|
||||
|
||||
|
||||
The UWB stack
|
||||
|
||||
The main mission of the UWB stack is to keep a tally of which devices
|
||||
are in radio proximity to allow drivers to connect to them. As well, it
|
||||
provides an API for controlling the local radio controllers (RCs from
|
||||
now on), such as to start/stop beaconing, scan, allocate bandwidth, etc.
|
||||
|
||||
|
||||
Devices and hosts: the basic structure
|
||||
|
||||
The main building block here is the UWB device (struct uwb_dev). For
|
||||
each device that pops up in radio presence (ie: the UWB host receives a
|
||||
beacon from it) you get a struct uwb_dev that will show up in
|
||||
/sys/class/uwb and in /sys/bus/uwb/devices.
|
||||
|
||||
For each RC that is detected, a new struct uwb_rc is created. In turn, a
|
||||
RC is also a device, so they also show in /sys/class/uwb and
|
||||
/sys/bus/uwb/devices, but at the same time, only radio controllers show
|
||||
up in /sys/class/uwb_rc.
|
||||
|
||||
*
|
||||
|
||||
[*] The reason for RCs being also devices is that not only we can
|
||||
see them while enumerating the system device tree, but also on the
|
||||
radio (their beacons and stuff), so the handling has to be
|
||||
likewise to that of a device.
|
||||
|
||||
Each RC driver is implemented by a separate driver that plugs into the
|
||||
interface that the UWB stack provides through a struct uwb_rc_ops. The
|
||||
spec creators have been nice enough to make the message format the same
|
||||
for HWA and WHCI RCs, so the driver is really a very thin transport that
|
||||
moves the requests from the UWB API to the device [/uwb_rc_ops->cmd()/]
|
||||
and sends the replies and notifications back to the API
|
||||
[/uwb_rc_neh_grok()/]. Notifications are handled to the UWB daemon, that
|
||||
is chartered, among other things, to keep the tab of how the UWB radio
|
||||
neighborhood looks, creating and destroying devices as they show up or
|
||||
dissapear.
|
||||
|
||||
Command execution is very simple: a command block is sent and a event
|
||||
block or reply is expected back. For sending/receiving command/events, a
|
||||
handle called /neh/ (Notification/Event Handle) is opened with
|
||||
/uwb_rc_neh_open()/.
|
||||
|
||||
The HWA-RC (USB dongle) driver (drivers/uwb/hwa-rc.c) does this job for
|
||||
the USB connected HWA. Eventually, drivers/whci-rc.c will do the same
|
||||
for the PCI connected WHCI controller.
|
||||
|
||||
|
||||
Host Controller life cycle
|
||||
|
||||
So let's say we connect a dongle to the system: it is detected and
|
||||
firmware uploaded if needed [for Intel's i1480
|
||||
/drivers/uwb/ptc/usb.c:ptc_usb_probe()/] and then it is reenumerated.
|
||||
Now we have a real HWA device connected and
|
||||
/drivers/uwb/hwa-rc.c:hwarc_probe()/ picks it up, that will set up the
|
||||
Wire-Adaptor environment and then suck it into the UWB stack's vision of
|
||||
the world [/drivers/uwb/lc-rc.c:uwb_rc_add()/].
|
||||
|
||||
*
|
||||
|
||||
[*] The stack should put a new RC to scan for devices
|
||||
[/uwb_rc_scan()/] so it finds what's available around and tries to
|
||||
connect to them, but this is policy stuff and should be driven
|
||||
from user space. As of now, the operator is expected to do it
|
||||
manually; see the release notes for documentation on the procedure.
|
||||
|
||||
When a dongle is disconnected, /drivers/uwb/hwa-rc.c:hwarc_disconnect()/
|
||||
takes time of tearing everything down safely (or not...).
|
||||
|
||||
|
||||
On the air: beacons and enumerating the radio neighborhood
|
||||
|
||||
So assuming we have devices and we have agreed for a channel to connect
|
||||
on (let's say 9), we put the new RC to beacon:
|
||||
|
||||
*
|
||||
|
||||
$ echo 9 0 > /sys/class/uwb_rc/uwb0/beacon
|
||||
|
||||
Now it is visible. If there were other devices in the same radio channel
|
||||
and beacon group (that's what the zero is for), the dongle's radio
|
||||
control interface will send beacon notifications on its
|
||||
notification/event endpoint (NEEP). The beacon notifications are part of
|
||||
the event stream that is funneled into the API with
|
||||
/drivers/uwb/neh.c:uwb_rc_neh_grok()/ and delivered to the UWBD, the UWB
|
||||
daemon through a notification list.
|
||||
|
||||
UWBD wakes up and scans the event list; finds a beacon and adds it to
|
||||
the BEACON CACHE (/uwb_beca/). If he receives a number of beacons from
|
||||
the same device, he considers it to be 'onair' and creates a new device
|
||||
[/drivers/uwb/lc-dev.c:uwbd_dev_onair()/]. Similarly, when no beacons
|
||||
are received in some time, the device is considered gone and wiped out
|
||||
[uwbd calls periodically /uwb/beacon.c:uwb_beca_purge()/ that will purge
|
||||
the beacon cache of dead devices].
|
||||
|
||||
|
||||
Device lists
|
||||
|
||||
All UWB devices are kept in the list of the struct bus_type uwb_bus.
|
||||
|
||||
|
||||
Bandwidth allocation
|
||||
|
||||
The UWB stack maintains a local copy of DRP availability through
|
||||
processing of incoming *DRP Availability Change* notifications. This
|
||||
local copy is currently used to present the current bandwidth
|
||||
availability to the user through the sysfs file
|
||||
/sys/class/uwb_rc/uwbx/bw_avail. In the future the bandwidth
|
||||
availability information will be used by the bandwidth reservation
|
||||
routines.
|
||||
|
||||
The bandwidth reservation routines are in progress and are thus not
|
||||
present in the current release. When completed they will enable a user
|
||||
to initiate DRP reservation requests through interaction with sysfs. DRP
|
||||
reservation requests from remote UWB devices will also be handled. The
|
||||
bandwidth management done by the UWB stack will include callbacks to the
|
||||
higher layers will enable the higher layers to use the reservations upon
|
||||
completion. [Note: The bandwidth reservation work is in progress and
|
||||
subject to change.]
|
||||
|
||||
|
||||
Wireless USB Host Controller drivers
|
||||
|
||||
*WARNING* This section needs a lot of work!
|
||||
|
||||
As explained above, there are three different types of HCs in the WUSB
|
||||
world: HWA-HC, DWA-HC and WHCI-HC.
|
||||
|
||||
HWA-HC and DWA-HC share that they are Wire-Adapters (USB or WUSB
|
||||
connected controllers), and their transfer management system is almost
|
||||
identical. So is their notification delivery system.
|
||||
|
||||
HWA-HC and WHCI-HC share that they are both WUSB host controllers, so
|
||||
they have to deal with WUSB device life cycle and maintenance, wireless
|
||||
root-hub
|
||||
|
||||
HWA exposes a Host Controller interface (HWA-HC 0xe0/02/02). This has
|
||||
three endpoints (Notifications, Data Transfer In and Data Transfer
|
||||
Out--known as NEP, DTI and DTO in the code).
|
||||
|
||||
We reserve UWB bandwidth for our Wireless USB Cluster, create a Cluster
|
||||
ID and tell the HC to use all that. Then we start it. This means the HC
|
||||
starts sending MMCs.
|
||||
|
||||
*
|
||||
|
||||
The MMCs are blocks of data defined somewhere in the WUSB1.0 spec
|
||||
that define a stream in the UWB channel time allocated for sending
|
||||
WUSB IEs (host to device commands/notifications) and Device
|
||||
Notifications (device initiated to host). Each host defines a
|
||||
unique Wireless USB cluster through MMCs. Devices can connect to a
|
||||
single cluster at the time. The IEs are Information Elements, and
|
||||
among them are the bandwidth allocations that tell each device
|
||||
when can they transmit or receive.
|
||||
|
||||
Now it all depends on external stimuli.
|
||||
|
||||
*New device connection*
|
||||
|
||||
A new device pops up, it scans the radio looking for MMCs that give out
|
||||
the existence of Wireless USB channels. Once one (or more) are found,
|
||||
selects which one to connect to. Sends a /DN_Connect/ (device
|
||||
notification connect) during the DNTS (Device Notification Time
|
||||
Slot--announced in the MMCs
|
||||
|
||||
HC picks the /DN_Connect/ out (nep module sends to notif.c for delivery
|
||||
into /devconnect/). This process starts the authentication process for
|
||||
the device. First we allocate a /fake port/ and assign an
|
||||
unauthenticated address (128 to 255--what we really do is
|
||||
0x80 | fake_port_idx). We fiddle with the fake port status and /khubd/
|
||||
sees a new connection, so he moves on to enable the fake port with a reset.
|
||||
|
||||
So now we are in the reset path -- we know we have a non-yet enumerated
|
||||
device with an unauthorized address; we ask user space to authenticate
|
||||
(FIXME: not yet done, similar to bluetooth pairing), then we do the key
|
||||
exchange (FIXME: not yet done) and issue a /set address 0/ to bring the
|
||||
device to the default state. Device is authenticated.
|
||||
|
||||
From here, the USB stack takes control through the usb_hcd ops. khubd
|
||||
has seen the port status changes, as we have been toggling them. It will
|
||||
start enumerating and doing transfers through usb_hcd->urb_enqueue() to
|
||||
read descriptors and move our data.
|
||||
|
||||
*Device life cycle and keep alives*
|
||||
|
||||
Everytime there is a succesful transfer to/from a device, we update a
|
||||
per-device activity timestamp. If not, every now and then we check and
|
||||
if the activity timestamp gets old, we ping the device by sending it a
|
||||
Keep Alive IE; it responds with a /DN_Alive/ pong during the DNTS (this
|
||||
arrives to us as a notification through
|
||||
devconnect.c:wusb_handle_dn_alive(). If a device times out, we
|
||||
disconnect it from the system (cleaning up internal information and
|
||||
toggling the bits in the fake hub port, which kicks khubd into removing
|
||||
the rest of the stuff).
|
||||
|
||||
This is done through devconnect:__wusb_check_devs(), which will scan the
|
||||
device list looking for whom needs refreshing.
|
||||
|
||||
If the device wants to disconnect, it will either die (ugly) or send a
|
||||
/DN_Disconnect/ that will prompt a disconnection from the system.
|
||||
|
||||
*Sending and receiving data*
|
||||
|
||||
Data is sent and received through /Remote Pipes/ (rpipes). An rpipe is
|
||||
/aimed/ at an endpoint in a WUSB device. This is the same for HWAs and
|
||||
DWAs.
|
||||
|
||||
Each HC has a number of rpipes and buffers that can be assigned to them;
|
||||
when doing a data transfer (xfer), first the rpipe has to be aimed and
|
||||
prepared (buffers assigned), then we can start queueing requests for
|
||||
data in or out.
|
||||
|
||||
Data buffers have to be segmented out before sending--so we send first a
|
||||
header (segment request) and then if there is any data, a data buffer
|
||||
immediately after to the DTI interface (yep, even the request). If our
|
||||
buffer is bigger than the max segment size, then we just do multiple
|
||||
requests.
|
||||
|
||||
[This sucks, because doing USB scatter gatter in Linux is resource
|
||||
intensive, if any...not that the current approach is not. It just has to
|
||||
be cleaned up a lot :)].
|
||||
|
||||
If reading, we don't send data buffers, just the segment headers saying
|
||||
we want to read segments.
|
||||
|
||||
When the xfer is executed, we receive a notification that says data is
|
||||
ready in the DTI endpoint (handled through
|
||||
xfer.c:wa_handle_notif_xfer()). In there we read from the DTI endpoint a
|
||||
descriptor that gives us the status of the transfer, its identification
|
||||
(given when we issued it) and the segment number. If it was a data read,
|
||||
we issue another URB to read into the destination buffer the chunk of
|
||||
data coming out of the remote endpoint. Done, wait for the next guy. The
|
||||
callbacks for the URBs issued from here are the ones that will declare
|
||||
the xfer complete at some point and call it's callback.
|
||||
|
||||
Seems simple, but the implementation is not trivial.
|
||||
|
||||
*
|
||||
|
||||
*WARNING* Old!!
|
||||
|
||||
The main xfer descriptor, wa_xfer (equivalent to a URB) contains an
|
||||
array of segments, tallys on segments and buffers and callback
|
||||
information. Buried in there is a lot of URBs for executing the segments
|
||||
and buffer transfers.
|
||||
|
||||
For OUT xfers, there is an array of segments, one URB for each, another
|
||||
one of buffer URB. When submitting, we submit URBs for segment request
|
||||
1, buffer 1, segment 2, buffer 2...etc. Then we wait on the DTI for xfer
|
||||
result data; when all the segments are complete, we call the callback to
|
||||
finalize the transfer.
|
||||
|
||||
For IN xfers, we only issue URBs for the segments we want to read and
|
||||
then wait for the xfer result data.
|
||||
|
||||
*URB mapping into xfers*
|
||||
|
||||
This is done by hwahc_op_urb_[en|de]queue(). In enqueue() we aim an
|
||||
rpipe to the endpoint where we have to transmit, create a transfer
|
||||
context (wa_xfer) and submit it. When the xfer is done, our callback is
|
||||
called and we assign the status bits and release the xfer resources.
|
||||
|
||||
In dequeue() we are basically cancelling/aborting the transfer. We issue
|
||||
a xfer abort request to the HC, cancell all the URBs we had submitted
|
||||
and not yet done and when all that is done, the xfer callback will be
|
||||
called--this will call the URB callback.
|
||||
|
||||
|
||||
Glossary
|
||||
|
||||
*DWA* -- Device Wire Adapter
|
||||
|
||||
USB host, wired for downstream devices, upstream connects wirelessly
|
||||
with Wireless USB.
|
||||
|
||||
*EVENT* -- Response to a command on the NEEP
|
||||
|
||||
*HWA* -- Host Wire Adapter / USB dongle for UWB and Wireless USB
|
||||
|
||||
*NEH* -- Notification/Event Handle
|
||||
|
||||
Handle/file descriptor for receiving notifications or events. The WA
|
||||
code requires you to get one of this to listen for notifications or
|
||||
events on the NEEP.
|
||||
|
||||
*NEEP* -- Notification/Event EndPoint
|
||||
|
||||
Stuff related to the management of the first endpoint of a HWA USB
|
||||
dongle that is used to deliver an stream of events and notifications to
|
||||
the host.
|
||||
|
||||
*NOTIFICATION* -- Message coming in the NEEP as response to something.
|
||||
|
||||
*RC* -- Radio Control
|
||||
|
||||
Design-overview.txt-1.8 (last edited 2006-11-04 12:22:24 by
|
||||
InakyPerezGonzalez)
|
||||
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
#! /bin/bash
|
||||
#
|
||||
|
||||
set -e
|
||||
|
||||
progname=$(basename $0)
|
||||
function help
|
||||
{
|
||||
cat <<EOF
|
||||
Usage: $progname COMMAND DEVICEs [ARGS]
|
||||
|
||||
Command for manipulating the pairing/authentication credentials of a
|
||||
Wireless USB device that supports wired-mode Cable-Based-Association.
|
||||
|
||||
Works in conjunction with the wusb-cba.ko driver from http://linuxuwb.org.
|
||||
|
||||
|
||||
DEVICE
|
||||
|
||||
sysfs path to the device to authenticate; for example, both this
|
||||
guys are the same:
|
||||
|
||||
/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/1-4.4:1.1
|
||||
/sys/bus/usb/drivers/wusb-cbaf/1-4.4:1.1
|
||||
|
||||
COMMAND/ARGS are
|
||||
|
||||
start
|
||||
|
||||
Start a WUSB host controller (by setting up a CHID)
|
||||
|
||||
set-chid DEVICE HOST-CHID HOST-BANDGROUP HOST-NAME
|
||||
|
||||
Sets host information in the device; after this you can call the
|
||||
get-cdid to see how does this device report itself to us.
|
||||
|
||||
get-cdid DEVICE
|
||||
|
||||
Get the device ID associated to the HOST-CHDI we sent with
|
||||
'set-chid'. We might not know about it.
|
||||
|
||||
set-cc DEVICE
|
||||
|
||||
If we allow the device to connect, set a random new CDID and CK
|
||||
(connection key). Device saves them for the next time it wants to
|
||||
connect wireless. We save them for that next time also so we can
|
||||
authenticate the device (when we see the CDID he uses to id
|
||||
itself) and the CK to crypto talk to it.
|
||||
|
||||
CHID is always 16 hex bytes in 'XX YY ZZ...' form
|
||||
BANDGROUP is almost always 0001
|
||||
|
||||
Examples:
|
||||
|
||||
You can default most arguments to '' to get a sane value:
|
||||
|
||||
$ $progname set-chid '' '' '' "My host name"
|
||||
|
||||
A full sequence:
|
||||
|
||||
$ $progname set-chid '' '' '' "My host name"
|
||||
$ $progname get-cdid ''
|
||||
$ $progname set-cc ''
|
||||
|
||||
EOF
|
||||
}
|
||||
|
||||
|
||||
# Defaults
|
||||
# FIXME: CHID should come from a database :), band group from the host
|
||||
host_CHID="00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff"
|
||||
host_band_group="0001"
|
||||
host_name="Linux-WUSB"
|
||||
|
||||
devs="$(echo /sys/bus/usb/drivers/wusb-cbaf/[0-9]*)"
|
||||
hdevs="$(find /sys -name wusb_chid -printf "%h\n")"
|
||||
|
||||
result=0
|
||||
case $1 in
|
||||
start)
|
||||
for dev in ${2:-$hdevs}
|
||||
do
|
||||
uwb_rc=$(find $(dirname $(dirname $dev)) -iname uwb_rc:uwb*)
|
||||
if cat $uwb_rc/uwb_rc/beacon | grep -q "channel: -1"
|
||||
then
|
||||
echo 13 0 | cat > $uwb_rc/uwb_rc/beacon
|
||||
echo I: started beaconing on ch 13 in host $(basename $uwb_rc)
|
||||
fi
|
||||
echo $host_CHID | cat > $dev/wusb_chid
|
||||
echo I: started host $(basename $dev)
|
||||
done
|
||||
;;
|
||||
set-chid)
|
||||
shift
|
||||
for dev in ${2:-$devs}
|
||||
do
|
||||
echo "${2:-$host_CHID}" "${3:-$host_band_group}" "${4:-$host_name}" \
|
||||
| cat > $dev/wusb_host_info
|
||||
done
|
||||
;;
|
||||
get-cdid)
|
||||
for dev in ${2:-$devs}
|
||||
do
|
||||
cat $dev/wusb_cdid
|
||||
done
|
||||
;;
|
||||
set-cc)
|
||||
for dev in ${2:-$devs}
|
||||
do
|
||||
shift
|
||||
CDID="$(head --bytes=16 /dev/urandom | od -tx1 -An)"
|
||||
CK="$(head --bytes=16 /dev/urandom | od -tx1 -An)"
|
||||
cat > $dev/wusb_cc <<EOF
|
||||
CDID:$CDID
|
||||
CK:$CK
|
||||
EOF
|
||||
cat <<EOF
|
||||
I: CC set
|
||||
CHID: $host_CHID
|
||||
CDID:$CDID
|
||||
CK: $CK
|
||||
EOF
|
||||
done
|
||||
;;
|
||||
help|h|--help|-h)
|
||||
help
|
||||
;;
|
||||
*)
|
||||
echo "E: Unknown usage" 1>&2
|
||||
help 1>&2
|
||||
result=1
|
||||
esac
|
||||
exit $result
|
||||
Loading…
Reference in New Issue