| WRAP Access Server: User's and Developer's Guide | ||
|---|---|---|
| <<< Previous | Next >>> | |
This chapter describes the basic features of a Bluegiga WRAP Access Server and their usage. This includes information on using the Access Server board as a Bluetooth LAN/PAN Access Point or a Bluetooth Serial Port Cable Replacer, using the Web Server, ObexSender, WRAP Package Management System and the various ways for uploading content for browsing and/or downloading, as well as getting familiar with the utility applications.
Using the features described in this chapter does not require the WRAP Access Server Software Development Environment to be installed.
Note: The default username is root with password buffy.
Note: Most of the configuration files are in Linux text file format, where the lines end with a single Line Feed (LF, "\n") character. Some applications will not work if the configuration file format is changed to MS-DOS format (happens for example if you transfer the files to the Windows for editing with Notepad), where the lines end with both Carriage Return and Line Feed (CR+LF, "\r\n") characters.
The network interface in the WRAP Access Servers are described in Table 3-1.
Table 3-1. WRAP Access Server Network Interfaces
| Interface | Description |
|---|---|
| nap | Dynamic virtual Ethernet ("cable") device. This is the device having an IP address. All the programs should use this device instead of eth0. |
| eth0 | Real Ethernet device, dynamically linked to nap device. Do not use this, use nap instead! |
| eth1 | WiFi device for the Orinoco driver (client mode only). |
| wlan0 | WiFi device for the Hostap driver. In client mode this device has an IP address, in access point mode it is dynamically linked to nap device. |
| wifi0 | Virtual control device for wlan0. Do not use. |
| gn | Virtual device for PAN-GN connections. |
| bnep# | These devices are used for incoming and outgoing PAN connections. They are created, deleted and linked (to nap or gn) dynamically. |
| ppp# | These devices are used for incoming and outgoing LAP connections. They are created and deleted dynamically. By default data coming from ppp# is masqueraded to nap device. |
The iWRAP servers (one in WRAP Access Server 2291, three in WRAP Access Server 2293) are started automatically at power-up. By default, the Serial Port, PAN and Object Push and File Transfer Profiles are activated. The iWRAP servers can be accessed and controlled (by applications or even interactively with a telnet client) using the iWRAP interface, described in section 9. Currently, there can be up to 14 simultaneous Bluetooth connections between a single master iWRAP server and up to 7 simultaneous slaves.
The access to the iWRAP can be password protected. By default it's buffy, but it can be unset or changed with the setup application (see Section 2.4). The password is case sensitive. The password must be typed in as the first command after the server has replied with "READY."
This profile is not automatically started at boot. The default settings can be changed with the setup application (see section Section 2.4), or runtime with the iWRAP interface (see Chapter 6).
The Access Server board can also act as a LAN Access Client, but in this case it must be controlled manually using iWRAP commands, described in Chapter 6.
Note: Since Bluetooth specification 1.2, LAN Access Profile has been deprecated.
The Serial Port Profile is used to replace an RS-232 serial cable between two devices with a Bluetooth connection. The physical setup is shown in Figure 3-1.
State A) in the figure is the starting situation with a serial cable connecting the devices. This cable is to be replaced with a Bluetooth connection.
In state B) the long serial connection is replaced with a Bluetooth Serial Port Profile connection between the two Access Server devices. These Access Server devices are then connected locally to the user devices with (short) serial cables. The cable between user device A and Access Server device A must be a cross-over cable. The cable between user device B and Access Server device B must be similar (direct or cross-over) to the one used in state A).
If RTS/CTS handshaking is used to ensure correct data transfer, the serial cables must have these pins connected. Note: This handshaking is "local": it takes place between the user device and the Access Server board. No handshaking between user device A and user device B on the other end of the Bluetooth connection is provided.
If RTS/CTS handshaking is not used, CTS must be connected to DTR.
DCD, DTR, and DSR signals are not supported. This also means that user devices A and B will not be able to tell whether or not the Bluetooth connection is up.
When the physical setup is ready, you can create the Bluetooth connection. By default, the Serial Port Profile is started up at boot with the default settings. That is, listening in DevB mode, at 115200 bps, 8 data bits, no parity, 1 stop bit, and RTS/CTS enabled. To change these settings, use the setup application or the WWW Setup interface, as described in Section 2.4.
Note: To disable Serial Port Profile, navigate to Setup → Applications → Default bootup applications in the WWW Setup interface, and switch serialport application to off.
Disabling can also be done from command prompt with command chkconfig --del serialport.
Access Server has two OBEX profiles: Object Push Profile (ObjP) and File Transfer Profile (FTP). You can use these profiles to transfer files easily between different Access Server devices and other devices supporting ObjP/FTP.
These profiles are handled by forwarding incoming calls to obexserver program, which handles both profiles. The working directory is /tmp/obex, and users have full read and write access there. By default, the default contact card /etc/default.vcf is copied there at boot.
In ObjP mode obexserver will prefix received files with sender's Bluetooth address and iWRAP port number.
Two simple command line utilities, obexput and obexget, are provided. They can be used to send and retrieve files to and from another Bluetooth device supporting ObjP/FTP.
Usage: obexput [parameters] bdaddr channel file(s)
Note: You can use the friendly name instead of Bluetooth address as the "bdaddr" parameter and keywords "OBJP" and "FTP" as the "channel" parameter for automatic service discovery.
Enter either of these commands without parameters to get a short help for using the command.
A non-zero return value means error. Reason for this error is printed to terminal.
The WRAP Access Server has support for all PAN profile modes: Personal Area Network User (PANU), Network Access Point (NAP) and Generic Networking (GN).
The device creating the PAN connection decides, which of these modes are to be used. Incoming connections are handled automatically by the Access Server. The Access Server board can also act as a PAN client, but in this case it must be controlled manually using the iWRAP interface, described in the Chapter 6.
The transmit power of the WRAP Access Server is configurable. By default, class 1 (100 meter range) settings are used. The settings can be changed down to "class 2" settings (10 meter range) with b2b_class2 command or even less with b2b_class3 command. The class 1 settings can be restored with b2b_class1 command.
After b2b_class# is given, it is recommended to reboot the Access Server once to restart ObexSender and other applications connected to the iWRAP server(s).
Note: When the operation is successful, you should get one Can't open baseband message with WRAP Access Server model 2293 and three messages with 2291.
You can send commands to a iWRAP server using the btcli application.
Usage: btcli [options] command
To see the options, enter the command btcli --help.
The specified command is sent to a Access Server iWRAP server (default: first server at port 10101) and all replies are echoed to the standard output. The application waits and prints the replies for a certain amount of time (default: 10 seconds) and exits.
The iWRAP commands are described in Chapter 6.
It is also possible to control the first iWRAP server (at port 10101) via RS-232 with the serialbluetooth application. Note: When you want to use this application, you must first disable the Bluetooth Serial Port Profile and the WRAP SMS Gateway Server with the setup application, as described in Section 2.4.
Usage: serialbluetooth [options]
To see the options, enter the command serialbluetooth --help.
Basically, serialbluetooth takes commands from a serial port and forwards them to the iWRAP server. All the commands available via iWRAP are also available via serial port.
There are two exceptions:
After making an outgoing RFCOMM data call, all input from the serial port is forwarded to the data socket, not the control socket. To close the data socket, you have to write +++ with a 200ms pause before each character. There is no way to have two concurrent RFCOMM calls.
All incoming RFCOMM calls are answered automatically. Again, to close the data socket, write +++ as with the outgoing call.
In case of rare failures in the Bluetooth baseband level, it is possible to give hardware reset for the basebands while the other system services are running with the following command sequence at the command line interface of WRAP Access Server:
[root@wrap /]$ /etc/init.d/bluetooth stop
[root@wrap /]$ echo ABCD > /dev/bbreset
[root@wrap /]$ sleep 1
[root@wrap /]$ echo abcd > /dev/bbreset
[root@wrap /]$ sleep 2
[root@wrap /]$ /etc/init.d/bluetooth start
|
WRAP Access Server functionality can be extended using GSM/GPRS, WiFi and GPS Compact Flash cards. The supported compact flash cards are listed in Appendix D.
The Compact Flash GPRS card is identified automatically by the operating system when inserted. The WRAP Access Server can use the GPRS card to connect to the GPRS network or to act as an SMS gateway (to send and receive SMS messages).
The GPRS mode is enabled and settings like SIM card's PIN code are configured using the setup application or its WWW interface, see Section 2.4 and documentation for Setup → Network settings → Enable GPRS interface in Appendix B.
Using the WRAP SMS Gateway Server is documented in Section 3.5.3.
If needed for special use, the Compact Flash GPRS card can also be accessed directly from /dev/ttyS0, a device file which exists when the GPRS card is successfully initialized.
The Compact Flash GPS card is identified automatically by the operating system when inserted. At that time, the device file /dev/ttyS0 is created and the GPS card can be accessed using that device with the serial port settings in use by the GPS card.
The supported compact flash cards are listed in Appendix D.
WRAP Access Server has support for Prism II/III based CF WiFi cards. The supported compact flash cards are listed in Appendix D.
Depending on the firmware version, two different drivers must be used. The firmware version can be seen after the insertion of the card in the system log file /var/log/messages, which can be viewed with the WWW Setup interface at Setup → Advanced settings → Show system log file.
You need to use the Hostap driver, if you can see the following line in the log:
eth1: Looks like an Intersil firmware version 1.7.4
|
If the firmware version is below 1.7.4, you must use the Orinoco driver.
Selection of the driver and configuration is done with the setup application or its WWW interface at Setup → Network settings.
Standard set of wireless utilities are provided to fine-tune your WiFi configuration:
iwconfig
iwlist
iwpriv
For more info see: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
Access Server's persistent memory storage can be extended using an USB memory dongle. The USB memory dongles are also used by the The WRAP Access Server Remote Management System (see Section 3.5.5) - each time a dongle is inserted, it is automatically mounted, scanned for management packets which are processed and unmounted.
To use the USB dongle for own applications it must be mounted manually with command
[root@wrap /]$ mount -t vfat usbdevice /mnt/usb
|
The usbdevice parameter is a path to the USB dongle filesystem device. For the first dongle inserted after a reboot, it is /dev/scsi/host0/bus0/target0/lun0/part1, if the dongle is partitioned and and /dev/scsi/host0/bus0/target0/lun0/disc, if the dongle has no partition table. If you have used several dongles after reboot, the host0 part of the path must be changed to host1 or host2 and so on. Example of finding the correct device automatically can be seen in script /usr/sbin/hotplub.usb.
Note: Remember always to unmount the memory dongle with the command
[root@wrap /]$ umount /mnt/usb
Note: Dongles with several partition tables do not fully work with the WRAP Access Server. In case of problems, please contact
<[email protected]>.
The Access Server server applications are started automatically at system power-up or when needed by the iWRAP server or the Internet services daemon. The servers and their purposes are described in Table 3-2.
Table 3-2. Access Server Servers
| Server | Description |
|---|---|
| bluetooth | WRAP Access Server iWRAP Server, described in detail in Chapter 6. |
| finder | WRAP Finder Service. |
| obexsender | WRAP ObexSender server. |
| smsgw | WRAP SMS gateway server, described in detail in Section 3.5.3. Note: By default, this is disabled. Use setup application or chkconfig --add smsgw command to enable it. |
| watchdog | WRAP user level watchdog. |
| wpkgd | WRAP remote management system daemon. |
| cardmgr | Daemon to monitor Compact Flash cards. |
| crond | Daemon to execute scheduled commands. Configurable with /var/spool/cron/crontabs/root in the same way as any Linux crond. Note: By default, this is disabled. Use the WWW interface of the setup application or chkconfig --add crond command to enable it. |
| ftpd | Internet File Transfer Protocol Server. Configurable with setup application. Note: By default, this is disabled. Use the WWW interface of the setup application or chkconfig --add ftpd command to enable it. |
| dhcpcd | DHCP client daemon for automatic network configuration. |
| inetd | Internet services daemon. Note: By default, this is disabled. Use setup application or chkconfig --add inetd command to enable it. |
| httpd | Web server, described in detail in Section 3.5.7. |
| pppd | Point to Point Protocol daemon. Used by the iWRAP server. Can be used manually over the user serial port (/dev/ttyAT1). |
| snmpd | SNMP daemon. |
| sshd | SSH daemon. |
| syslogd | System logging daemon. Configurable with the setup application. |
| telnetd | Telnet protocol server. Note: By default, this is disabled. Use setup application or chkconfig --add telnetd command to enable it. |
The Finder service is a small service, which listens for UDP broadcast queries from the WRAP Access Server Finder applications and responses to those queries with identification information (IP address, model, serial number, etc.) about the Access Server.
The ObexSender application is started automatically in the WRAP Access Server. Its purpose is to receive business cards (vCards), images or other files, and analyze their content and send files back selecting them based on configured keywords found.
ObexSender can also inquiry for bluetooth devices, and automatically send one or more files to all new devices found.
ObexSender can be configured with setup application or by editing /etc/obexsender.conf file (see Section 2.4).
The WRAP SMS Gateway server supports Nokia 20, Nokia 30 or Wavecom WMOD2 compatible GSM terminals and the supported GSM/GPRS Compact Flash cards for sending and receiving SMS messages. By default the Compact Flash card is used. The PIN code query of the SIM-card at power-up must be disabled.
The WRAP SMS Gateway Server is disabled by default. To enable it, use the setup application's WWW interface, as described in section Section 2.4. Enabling is done at Setup → Applications → Default bootup applications → smsgw.
To use Nokia terminals the device must be connected to the user serial port when the server starts up and the terminal must be configured to operate in RS-232/AT-command. The Nokia terminals are configured with the N20 or N30 Configurator application.
The WRAP SMS Gateway is configured to use the terminal connected to the user serial port with the setup application or its WWW interface by changing the setting at Setup → Applications → SMS gateway settings → Comport device to /dev/ttyAT1 from the default /dev/ttyS0.
Note: If you are using user serial port you have to disable the Bluetooth Serial Port Profile, as they share the same physical user serial port.
For further information on using smsgw, see the makesms example in Section 5.3.1.
The WRAP User Level Watchdog daemon listens on UDP port 4266 for "id timeout" messages. "id" is an ASCII string, without spaces. If "timeout" equals to 0 (zero), the "id" is removed from the list of processes to wait. If "timeout" is greater than 0 (zero), the "id" is added or updated.
When there is no message for "id" received within the "timeout" seconds, the user level watchdog dies and the WRAP Access Server is rebooted by the kernel watchdog.
The watchdog command can be used to send messages to the watchdog daemon. This is done via command watchdog id timeout, for example watchdog test 5.
The WRAP Access Server contains simple tools that provide base for full and secure remote management of the device.
The basic remote management can be performed using the WWW Setup interface, SSH command line access and SCP and SFTP file transfer protocols.
In addition to them, the Access Server contains the WRAP Remote Management System for transferring management packets over different medium to the Access Server and automatically sending response packets back.
The management packets (*.wpk) are processed automatically when they are transferred to the autoinstall directory in the WRAP Access Server (/tmp/obex by default, configurable with setup application or WWW interface at Setup → Applications → wpkgd settings). Easiest way to transfer a management packet to this directory is to upload it from WWW Setup at Setup → Advanced settings → Upload a software update.
The WRAP Remote Management System top level architecture is shown in Figure 3-2.
A management action is performed using the following protocol:
A management packet (*.wpk) is prepared by the customer system.
The management packet is delivered to Access Server, into packaging daemon's inbox directory. One can currently use Bluetooth, SCP, SFTP and plain FTP to do this. The packet can also be transmitted using a USB memory dongle or via the WWW Setup interface.
The Access Server packaging daemon processes the management packet, possibly generating reply packet.
(optional) Reply packet is delivered to the customer system.
Package name must be of format name.wpk, where "name" can be user defined.
Package must be tar -archive that is compressed with gzip (like files named *.tar.gz or *.tgz).
Package should contain package information file called wpkg.pif in package root (contents described later), otherwise built-in defaults for wpkg.pif are used.
All other files, if exist, should be data files, scripts or executables required for the management operation
The management packet information file (wpkg.pif) consists of tags and their data, described here
%wpkg-version: 2
Contains information for version checking. 2 is currently the only supported version. This is also the default.
%wpkg-prepare: [command line[s]]
One or more commands (all lines until next tag are interpreted as command lines) to execute. Commands may contain parameters, redirections and job control as well.
Built-in default for this is /usr/bin/dpkg -i *.deb || echo ERROR: Installation failed.. This enables the special case of creating .wpk packets from .deb packets simply with tar czf foo.wpk foo.deb. (wpkg.pif is not needed in this special case).
%wpkg-reply: method
Where the generated reply packet is sent. By default it's sent to where it came from. Possible values are:
default
file:///path/filename
scp://remote:file
objp://bdaddr/
none
%wpkg-format: type
What kind of reply packet will be generated. Possible values are:
ascii (the default, everything echoed by prepare-section will be sent).
tgz (all files in current directory will be sent).
vcf (same as ascii, but assume it's vCard).
vmg (same as ascii, but assume it's vMessage).
vnt (same as ascii, but assume it's vNote).
vcs (same as ascii, but assume it's vCalendar).
html (same as ascii, but assume it's HTML).
%wpkg-auth: auth
Optional authentication string required by wpkgd.
The simplest example of wpkg.pif is:
%wpkg-version: 2
%wpkg-prepare:
echo Hello world
|
This will generate reply packet containing text "Hello world". You can generate the wpk-file simply giving the command tar czf hello.wpk wpkg.pif.
More complex example of wpkg.pif is:
%wpkg-version: 2
%wpkg-prepare:
FOO=`pwd`
cd /
tar xzf ${FOO}/files.tar.gz
echo Done.
|
This example will extract files from included files.tar.gz. You can generate wpk-file with command tar czf update.wpk wpkg.pif files.tar.gz.
In this example we build a simple packet that can be used with Bluetooth-enabled phone to retrieve IP Address of the WRAP Access Server. File wpkg.pif is:
%wpkg-version: 2
%wpkg-format: vcf
%wpkg-prepare:
ipaddr() {
echo `ifconfig nap | grep "inet addr" | awk -F [:] \
\\{print\\$2\\} | awk \\{print\\$1\\}`
}
serialno() {
echo `wrapid | grep Hardware | awk \\{print\\$5\\}`
}
echo -e "BEGIN:VCARD\r"
echo -e "VERSION:2.1\r"
echo -e "N:`serialno`\r"
echo -e "TEL:`ipaddr`\r"
echo -e "URL:`hostname`\r"
echo -e "END:VCARD\r"
|
This example will send the reply back as vCard (contact card). Please note that you have to include all required vCard formatting by yourself. You can generate wpk-file simply giving the command tar czf ipquery.wpk wpkg.pif.
To use this example, send the file ipquery.wpk to the inbox of you Bluetooth phone. Check that you have Bluetooth enabled in the phone. Then from the phone's inbox, send the file ipquery.wpk via Bluetooth to the WRAP Access Server.
When an USB memory dongle is inserted, the WRAP Access Server automatically tries to mount it (using VFAT type). When the mount is successful, the root directory is searched for a *.wpk packets and if a packet is found, it will be handled by the WRAP Package daemon. Optional reply packets are saved back to the root folder (if not otherwise stated in the %wpkg-reply tag).
If you enable FTP server then users can use it to log in in anonymously to /tmp/obex directory with download access or as root with password buffy to the root directory with full access. The password and other settings can be changed on the Access Server with setup application or by editing /etc/ftpd.conf file (see Section 2.4).
Note: Do not enable FTP because it's insecure. Use SSH (SCP or SFTP) instead. A nice client with a graphical user interface is for example WinSCP (http://winscp.net/).
The integrated web server in the Access Server supports HTTP/1.0 methods GET and POST, and has light user authentication capabilities. The content can be either static or dynamic - the WWW server is CGI/1.1 compatible.
The web server is always running and the content (http://wrap-ip-address/) is located in the /var/www/html/ directory in the Access Server file system.
The web server is configured to protect the WWW Setup interface with username and password. The default username and password can be changed as instructed in Section 2.4. For further information about using the web server for your own applications, see the web examples in Section 5.3.1.
A separate software update package is available from Bluegiga Techforum (https://www.bluegiga.com/techforum/), which adds the Net-SNMP suite of applications to the WRAP Access Server. Current implementation for the Access Server is limited and will be extended in the future. However, it can be used to poll the basic status of the Access Server.
Configuration details can be found and altered in the configuration file /etc/snmp/snmpd.conf accessible as described in Section 2.4.
For more information about the Net-SNMP suite, see http://net-snmp.sourceforge.net/
A separate software update package is available from Bluegiga Techforum (https://www.bluegiga.com/techforum/), which adds the OpenVPN™, a full-featured SSL VPN solution to the WRAP Access Server.
For more information about the OpenVPN™, see http://openvpn.net/.
By default, users can use SSH to log in (or SCP and SFTP to transfer files) as user root with password buffy. The password can be changed on the Access Server using the command passwd or with the setup application.
If you enable telnet then users can use it to log in as user root with password buffy. The password can be changed on the Access Server using the command passwd or with the setup application.
Note: Do not enable telnet because it's insecure. Use SSH instead.
The Access Server is basically a small Linux system. Whether logged in from the management console or with SSH, your shell session starts as the root user in the root directory. After that, you have the option to use most of the standard Linux utilities, briefly listed and described in Table 3-3. Most of the commands have a small built-in usage help that can be seen by executing the command with the -h or --help parameter.
Table 3-3. WRAP Access Server Utilities
| Application | Description |
|---|---|
| adduser | Add user to the system. |
| arping | Ping hosts by ARP requests/replies. |
| awk | Pattern scanning and processing language. |
| b2b_class1 | WRAP Board2Board module control script (set basebands to class 1). |
| b2b_class2 | WRAP Board2Board module control script (set basebands to class 2). |
| b2b_class3 | WRAP Board2Board module control script (set basebands to shortest possible range). |
| b2b_default | WRAP Board2Board module control script (restore all factory defaults, class 1). |
| basename | Strip directory and suffix from filenames. |
| bash | Bourne-Again SHell. |
| btcli | WRAP iWRAP Server Command Line Interface utility. |
| btproxy | WRAP iWRAP Proxy for Access Servers (test revision). |
| bunzip2 | Decompress bzip2-compressed files. |
| bzcat | Decompress bzip2-compressed files to stdout. |
| cardctl | Monitor and control the state of PCMCIA sockets. |
| cat | Concatenate files and print on the standard output. |
| chat | Automated conversational script with a modem. |
| chgrp | Change group ownership. |
| chkconfig | Updates and queries runlevel information for system services. |
| chmod | Change file access permissions. |
| chown | Change file owner and group. |
| chroot | Run command or interactive shell with special root directory. |
| clear | Clear the terminal screen. |
| cmp | Compare two files. |
| cp | Copy files and directories. |
| cpio | Copy files to and from archives. |
| crontab | Maintain crontab files for individual users. |
| cut | Remove sections from each line of files. |
| date | Print or set the system date and time. Note: The date command does not store the date into the battery powered real time clock. Use hwclock application instead. |
| dd | Convert and copy a file. |
| deluser | Delete user from the system. |
| df | Report file system disk space usage. |
| dfu | WRAP Board2Board module firmware upgrade tool. |
| dialup | WRAP iWRAP helper application. |
| dirname | Strip non-directory suffix from file name. |
| dmesg | Prints of controls the kernel ring buffer. |
| dpkg | A medium-level package manager for (.deb) packages. |
| dpkg-deb | Debian package archive (.deb) manipulation tool . |
| du | Estimate file space usage. |
| dump_cis | Retrieves and parses the Card Information Structures for inserted PCMCIA devices, or optionally, parses CIS information from a file. |
| dun | WRAP iWRAP helper application. |
| egrep | Print lines matching a pattern. |
| encode_keychange | Produce the KeyChange string for SNMPv3. |
| env | Run a command in a modified environment. |
| expr | Evaluate expressions. |
| false | Do nothing, unsuccessfully. |
| fgrep | Print lines matching pattern. |
| find | Search for files in a directory hierarchy. |
| free | Display the amount of free and used memory in the system. |
| ftp | Internet file transfer program. |
| gdbserver | Remote server for GDB debugger. |
| getty | Opens a tty, prompts for a login name, then invokes /bin/login. |
| grep | Print lines matching a pattern. |
| gunzip | Expand gzip compressed files. |
| gzip | Compress files into gzip format. |
| head | Output the first part of files. |
| hexdump | A filter which displays the specified files, or the standard input, if no files are specified, in a user specified format. |
| hostid | Print out a unique 32-bit identifier for the machine (not yet implemented). |
| hostname | Show or set the system's host name. |
| hwclock | Query and set the hardware clock. |
| id | Print information for username or current user. |
| ide_info | IDE device information. |
| ifconfig | Configure a network interface. |
| ifport | Select the transceiver type for a network interface. |
| ifuser | Checks to see if any of the listed hosts or network addresses are routed through the specified interface. |
| insmod | Loads the specified kernel modules into the kernel. |
| ip | TCP/IP interface configuration and routing utility. |
| iptables, ip6tables | IP packet filter administration. |
| kill | Terminate a program. |
| killall | Kill processes by name. |
| ln | Make links between files. |
| logger | Make entries into the system log. |
| login | Sign on. |
| ls | List directory contents. |
| lsmod | List loaded modules. |
| md5sum | Compute and check MD5 message digest. |
| mkdir | Make directories. |
| mknod | Make block or character special files. |
| mktemp | Make a temporary file name (unique). |
| modprobe | High level handling of loadable modules. |
| more | File perusal filter for crt viewing. |
| mount | Mount a file system. |
| mv | Move (rename) files. |
| net-snmp-config | Net-SNMP tool. |
| nslookup | Queries the nameserver for IP address of given host. |
| ntpclient | Simple NTP client application. |
| obexbrowser | The WRAP obexbrowser. A command line OBEX client interface. |
| obexget | The WRAP OBEX tool for retrieving a file from a remote device with ObjP/FTP support. |
| obexput | The WRAP OBEX tool for sending a file to a remote device with ObjP/FTP support. |
| pack_cis | Convert a text description of a PCMCIA Card Information Structure (CIS) to its packed binary representation. |
| passwd | Update a user's authentication token(s). |
| picocom | Minimal dumb-terminal emulation program. |
| pidof | Find a process ID of a running program. |
| ping, ping6 | Send ICMP ECHO_REQUEST packets to network hosts. |
| ps | Report process status. |
| pwd | Print the name of the current/working directory. |
| rb, rx, rz, sb, sx, sz | Xmodem, Ymodem, Zmodem file receive and send. |
| rdate | Get and possibly set the system date and time from a remote HOST. |
| reboot | Reboot the system. |
| renice | Alter the priority of running processes. |
| reset | Resets the screen. |
| rm | Remove files or directories. |
| rmdir | Remove empty directories. |
| rmmod | Unload loadable modules. |
| route | Show / manipulate the IP routing table. |
| scp | Secure copy (remote file copy program). |
| scsi_info | SCSI device description tool. |
| sed | A Stream EDitor. |
| setup | The WRAP Setup Application. See Section 2.4. |
| sftp | Secure file transfer program. |
| sleep | Delay for a specified amount of time. |
| snmp* | Set of standard SNMP command line applications. |
| sort | Sort lines of text files. |
| ssh, slogin | OpenSSH SSH client (remote login program). |
| ssh-keygen | SSH authentication key generation, management and conversion. |
| strace | Utility to trace system calls and signals. |
| strings | Display printable strings in binary file. |
| stty | Change and print terminal line settings. |
| su | Run a shell with substitute user and group IDs. |
| sulogin | Single-user login. |
| sync | Flush filesystem buffers. |
| tail | Output the last part of files. |
| tar | Tar archiving utility. |
| tcpdump | Utility for dumping traffic on a network. |
| telnet | User interface to the TELNET protocol. |
| test | Check file types and compare values. |
| time | Run command and display it's resource usage information when finished. |
| top | Provides view of processor activity in real time. |
| touch | Change file timestamps. |
| tr | Translate or delete characters. |
| traceroute | Trace the route ip packets follow going to host. |
| true | Do nothing, successfully. |
| tty | Print the filename of the terminal connected to standard input. |
| uartmode | WRAP Uartmode: Change the mode of the user serial port (DTE or DCE). |
| umount | Unmount file systems. |
| uname | Print system information. |
| uniq | Remove duplicate lines from sorted lines. |
| unzip | List, test, and extract compressed files in a ZIP archive. |
| uptime | Tell how long the system has been running. |
| uudecode | Decode a file create by uuencode. |
| uuencode | Encode a binary file. |
| wc | Print the number of bytes, words, and lines in files. |
| vi | A text editor. |
| wget | A utility to retrieve files from the World Wide Web. |
| wrapfinder | Finds other Access Servers in the network. |
| wrapid | The WRAP Access Server identification program. Shows build and hardware configuration information. |
| which | Shows the full path of (shell) commands. |
| whoami | Prints the user name associated with the current effective user id. |
| zcat | Expand gzip compressed files to the standard output. |
| zeroconf | Zero Configuration Networking application. |
| xargs | Build and execute command lines from the standard input. |
The system clock is read from the battery operated real time clock during boot. The time between the system time and the real time clock can synchronized using the hwclock application. Give command hwclock --help for more information.
The default time zone in the WRAP Access Server is UTC. You can change the timezone by replacing the file /etc/localtime with the correct file from your desktop Linux system (using your /etc/localtime or a wanted zone from /usr/share/zoneinfo).
Access Server can be re-installed with the latest software version. The latest software updates and instructions are available at https://www.bluegiga.com/techforum/.
Most of the software updates are delivered as wpk file.
The easiest way to install these is:
Start Access Server.
Copy wpk file or files to an empty USB memory dongle.
Insert the dongle into Access Server
LEDs will turn on, and after 10-60 seconds they will turn off.
Remove the dongle and reboot Access Server.
All done.
See Section 3.5.5 for detailed description for other options and how to create your own wpk files.
| <<< Previous | Home | Next >>> |
| Getting Started with the Access Server | Bluetooth Technology Overview |