dect 00/09: beginning of a DECT stack

Patrick McHardy kaber at trash.net
Mon Jan 19 14:04:25 CET 2009


I've done some work on the COA driver and a DECT protocol stack and this
is what I've currently got. Protocol stack is grossly overstated since
we're missing TX support, so the only thing that could be reasonably
implemented is monitor mode support. Especially the MAC patch needs
serious cleanup, but since I'm short on time today, I'm mainly interested
in getting out what I've got.

Anyways, a few words about the following patches:

The first five patches contain the DECT protocol core, a generic
tranceiver infrastructure, a netlink control interface and a PF_DECT
socket family, implementing DECT RAW sockets. The last four patches
contain a cleaned up version of the Com-on-Air driver, supporting both
the PCMCIA and the PCI devices and using the DECT transceiver
infrastructure. The individual changelog entries contain some more
information.

The second batch of patches add support for the netlink control interface
to libnl and some basic example programs.

Usage example (dect programs from libnl/src):

# dect-transceiver-list
dect transceiver trx0:
        type sc14422

# dect-device-add --name monitor --mode monitor \
		  --transceiver trx0 --rfpi <RFPI>

<check kernel ringbuffer for messages, will start printing a lot of
 information once synced>

# dect-transceiver-list
dect transceiver trx0:
        type sc14422
        channel 0: <active> carrier 0 RSSI 61
            RX: bytes 48177 packets 909
        channel 2: <active> carrier 5 RSSI 63
            RX: bytes 636742 packets 12014
        channel 4: <active> carrier 2 RSSI 40
            RX: bytes 2934239 packets 55363
        channel 6: <scanning> carrier 3
            RX: bytes 5989 packets 113
        channel 8: <scanning> carrier 3
            RX: bytes 19981 packets 377
        channel 10: <scanning> carrier 3
            RX: bytes 8533 packets 161
        channel 12: <scanning> carrier 2
            RX: bytes 0 packets 0
        channel 14: <scanning> carrier 2
            RX: bytes 0 packets 0
        channel 16: <scanning> carrier 2
            RX: bytes 0 packets 0
        channel 18: <scanning> carrier 2
            RX: bytes 0 packets 0
        channel 20: <scanning> carrier 2
            RX: bytes 2173 packets 41
        channel 22: <scanning> carrier 2
            RX: bytes 0 packets 0

# dect-device-list
dect device monitor:
        mode: fp
        rfpi: 00-8b-8b-00-68
        transceiver: trx0

# dect-device-delete --name monitor

Usage of the DECT sockets is similar to any other socket family, basically:

	struct sockaddr dummy;

	fd = socket(PF_DECT, SOCK_RAW, 0);
	if (fd < 0)
		return NULL;
	if (bind(fd, &dummy, sizeof(dummy)) < 0) {
		close(fd);
		return NULL;
	}

The dummy bind is currently required to bind the socket, struct sockaddr_dect
is not exported yet. Then:

	struct iovec iov;
	struct msghdr msg;
	struct cmsghdr *cmsg;
	union {
		struct cmsghdr		cmsg;
		char			buf[CMSG_SPACE(sizeof(struct dect_auxdata))];
	} cmsg_buf;
	struct dect_auxdata *aux;
	size_t size;

	msg.msg_name		= NULL;
	msg.msg_namelen		= 0;
	msg.msg_iov		= &iov;
	msg.msg_iovlen		= 1;
	msg.msg_control		= &cmsg_buf;
	msg.msg_controllen	= sizeof(cmsg_buf);
	msg.msg_flags		= 0;

	iov.iov_len		= sizeof(pkt.buf) - 5;
	iov.iov_base		= &pkt.buf[5];
	memset(pkt.buf, 0, sizeof(pkt.buf));

	size = recvmsg(fd, &msg, 0);
...
	for (cmsg = CMSG_FIRSTHDR(&msg); cmsg != NULL;
	     cmsg = CMSG_NXTHDR(&msg, cmsg)) {
		if (cmsg->cmsg_level != SOL_DECT ||
		    cmsg->cmsg_type != DECT_AUXDATA ||
		    cmsg->cmsg_len < CMSG_LEN(sizeof(*aux)))
			continue;

		aux = (struct dect_auxdata *)CMSG_DATA(cmsg);
		pkt.frame = aux->frame;
		pkt.slot  = aux->slot;
		pkt.rssi  = aux->rssi;
		pkt.channel = 0;
	}

The only difference to the character device is that the dummy header is
not existant, so to use with the existing tools you need to (as in the
example) receive the data with an offset of 5 bytes.

One question to the dedected.org people is how you plan to proceed with
the driver development. I have no problem maintaining this myself as I
continue to work on this, but it seesm to be a waste of resources to
maintain two code bases. So is there any interesting in joining forces?

Comments welcome ...


 drivers/Kconfig                       |    2 +
 drivers/Makefile                      |    1 +
 drivers/dect/.gitignore               |    4 +
 drivers/dect/Kconfig                  |   10 +
 drivers/dect/Makefile                 |    1 +
 drivers/dect/coa/Kconfig              |   28 ++
 drivers/dect/coa/Makefile             |   38 +++
 drivers/dect/coa/bin2c.c              |   57 ++++
 drivers/dect/coa/com_on_air.h         |   52 ++++
 drivers/dect/coa/com_on_air_cs.c      |  300 +++++++++++++++++++
 drivers/dect/coa/com_on_air_pci.c     |  164 ++++++++++
 drivers/dect/coa/dip_opcodes.h        |  157 ++++++++++
 drivers/dect/coa/sc14421.c            |  526 +++++++++++++++++++++++++++++++++
 drivers/dect/coa/sc14421_firmware.asm |  308 +++++++++++++++++++
 drivers/dect/coa/sc14421_firmware.c   |   73 +++++
 drivers/dect/coa/sc14421_firmware.h   |   38 +++
 include/linux/Kbuild                  |    1 +
 include/linux/dect.h                  |  190 ++++++++++++
 include/linux/dect_netlink.h          |   71 +++++
 include/linux/netlink.h               |    1 +
 include/linux/socket.h                |    5 +-
 include/net/dect.h                    |  350 ++++++++++++++++++++++
 net/Kconfig                           |    1 +
 net/Makefile                          |    1 +
 net/dect/Kconfig                      |    6 +
 net/dect/Makefile                     |    3 +
 net/dect/af_dect.c                    |  217 ++++++++++++++
 net/dect/core.c                       |  179 +++++++++++
 net/dect/dect_netlink.c               |  499 +++++++++++++++++++++++++++++++
 net/dect/mac.c                        |  429 +++++++++++++++++++++++++++
 net/netlink/af_netlink.c              |    1 +
 31 files changed, 3712 insertions(+), 1 deletions(-)
 create mode 100644 drivers/dect/.gitignore
 create mode 100644 drivers/dect/Kconfig
 create mode 100644 drivers/dect/Makefile
 create mode 100644 drivers/dect/coa/Kconfig
 create mode 100644 drivers/dect/coa/Makefile
 create mode 100644 drivers/dect/coa/bin2c.c
 create mode 100644 drivers/dect/coa/com_on_air.h
 create mode 100644 drivers/dect/coa/com_on_air_cs.c
 create mode 100644 drivers/dect/coa/com_on_air_pci.c
 create mode 100644 drivers/dect/coa/dip_opcodes.h
 create mode 100644 drivers/dect/coa/sc14421.c
 create mode 100644 drivers/dect/coa/sc14421_firmware.asm
 create mode 100644 drivers/dect/coa/sc14421_firmware.c
 create mode 100644 drivers/dect/coa/sc14421_firmware.h
 create mode 100644 include/linux/dect.h
 create mode 100644 include/linux/dect_netlink.h
 create mode 100644 include/net/dect.h
 create mode 100644 net/dect/Kconfig
 create mode 100644 net/dect/Makefile
 create mode 100644 net/dect/af_dect.c
 create mode 100644 net/dect/core.c
 create mode 100644 net/dect/dect_netlink.c
 create mode 100644 net/dect/mac.c

Patrick McHardy (9):
      dect: add DECT protocol core
      dect: add DECT transceiver infrastructure
      dect: add DECT device support
      dect: add DECT MAC layer
      dect: add PF_DECT protocol family
      dect: com-on-air: device driver core
      dect: com-on-air: support for rebuilding firmware
      dect: com-on-air: add PCMCIA driver
      dect: com-on-air: add PCI driver



More information about the dedected mailing list