Linux bluetooth development
 help / color / mirror / Atom feed
* [Bluez-devel] [PATCH] New keytab storage
@ 2004-01-30 23:56 Fredrik Noring
  2004-01-31  0:32 ` Marcel Holtmann
  0 siblings, 1 reply; 12+ messages in thread
From: Fredrik Noring @ 2004-01-30 23:56 UTC (permalink / raw)
  To: BlueZ Mailing List

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

Hi

Attached patch implements link key storage in /etc/bluetooth/keytab and
/etc/bluetooth/keytab.shadow. The old /etc/bluetooth/link_key file is
converted automatically.

I think a config option to change the default location would be useful.
This is not implemented yet. ("man" pages for hcid and hcid.conf is
badly needed btw.)

hcid is a bit more dynamic now so dmalloc and similar memory debugging
tools would be interesting to run. :)

I'd happy if anybody would like to test it.

Fredrik


[-- Attachment #2: hcid-keytab.patch.bz2 --]
[-- Type: application/x-bzip, Size: 11124 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-30 23:56 [Bluez-devel] [PATCH] New keytab storage Fredrik Noring
@ 2004-01-31  0:32 ` Marcel Holtmann
  2004-01-31  0:55   ` Fredrik Noring
  2004-01-31 10:47   ` Fredrik Noring
  0 siblings, 2 replies; 12+ messages in thread
From: Marcel Holtmann @ 2004-01-31  0:32 UTC (permalink / raw)
  To: Fredrik Noring; +Cc: BlueZ Mailing List

Hi Fredrik,

> Attached patch implements link key storage in /etc/bluetooth/keytab and
> /etc/bluetooth/keytab.shadow. The old /etc/bluetooth/link_key file is
> converted automatically.

I haven't reviewed the complete patch and at the moment and I am not
convinced in doing such a big change to the old code. But I have some
general comments.

Please send every patch as plain text and not compressed, because this
makes it easy to take a first look at it within the email client. If you
got oversize reports from the mailing list manager, don't worry I will
approve the email by hand.

If you do such a big change show us the output of diffstat so everybody
can see what files are going to be changed.

 Makefile.am |    4 
 Makefile.in |  548 ++++++++++++++++++++++++++++++++++++------------------------
 file.c      |   92 ++++++++++
 file.h      |   18 +
 hcid.h      |   21 +-
 keytab.c    |  459 ++++++++++++++++++++++++++++++++++++++++++++++++++
 keytab.h    |   14 +
 lib.h       |    4 
 main.c      |    2 
 security.c  |  108 ++---------
 10 files changed, 952 insertions(+), 318 deletions(-)

Don't include files that are generated by autoconf/automake. In your
case this is Makefile.in. diffstat or lsdiff helps here to check the
patch for unwanted files.

Follow the coding style. Read the paper from Greg Kroah-Hartman. It is
very good. Here are my notes:

The comment should be above the function declaration. Some goes for any
other statement.

	static int parse_hex_digit(char c)
	       /* Returns binary 0-15 for hex '0'-'a' and '0'-'A'.
	        * Returns -1 for invalid hex digits. */
	{

The parenthese must be behind the "if", "for" and "while" statement.

       fd = open(filename, O_RDONLY);
       if (fd < 0)
       {

Include a whitespace after "if", "for", "while" etc.

       for(;;)
       {

Typedefs are ugly, but if you use them, than the *_t version must match
the structure and not define something complete different.

	typedef uint8_t        link_key_t[16];

	struct link_key {

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-31  0:32 ` Marcel Holtmann
@ 2004-01-31  0:55   ` Fredrik Noring
  2004-01-31  1:18     ` Marcel Holtmann
  2004-01-31 10:47   ` Fredrik Noring
  1 sibling, 1 reply; 12+ messages in thread
From: Fredrik Noring @ 2004-01-31  0:55 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: BlueZ Mailing List

Hi Marcel,

lör 2004-01-31 klockan 01.32 skrev Marcel Holtmann:
> I haven't reviewed the complete patch and at the moment and I am not
> convinced in doing such a big change to the old code. But I have some
> general comments.

Can I ask where the new code is?

> Please send every patch as plain text and not compressed, because this
> makes it easy to take a first look at it within the email client. If you
> got oversize reports from the mailing list manager, don't worry I will
> approve the email by hand.

OK, I'll do that.

> If you do such a big change show us the output of diffstat so everybody
> can see what files are going to be changed.

Sure.

> Don't include files that are generated by autoconf/automake. In your
> case this is Makefile.in. diffstat or lsdiff helps here to check the
> patch for unwanted files.

I'd be happy to skip them. The original source (bluez-utils-2.4.tar.gz)
contains these files for some reason though.

> Follow the coding style. Read the paper from Greg Kroah-Hartman. It is
> very good. 

OK.

> Typedefs are ugly, but if you use them, 

The main reason for this typedef is that the original code did things
like this:

    unint8_t link_key_t[16];
    ...
    memcpy(key0, key1, 16);

which, I think, is a lot worse than:

    memcpy(key0, key1, sizeof(link_key_t));

Don't you agree? (An alternative is to use #define LINK_KEY_SIZE 16
instead of course.)

> than the *_t version must match the structure and not define something 
> complete different.

What do you mean?

Many thanks for your comments,
Fredrik

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-31  0:55   ` Fredrik Noring
@ 2004-01-31  1:18     ` Marcel Holtmann
  2004-01-31  9:27       ` Fredrik Noring
  0 siblings, 1 reply; 12+ messages in thread
From: Marcel Holtmann @ 2004-01-31  1:18 UTC (permalink / raw)
  To: Fredrik Noring; +Cc: BlueZ Mailing List

Hi Fredrik,

> Can I ask where the new code is?

I started already coding the new device manager, but accidentally I
deleted that code from my harddisk.

However you should talk a look at libs2 and utils2 from CVS.

> I'd be happy to skip them. The original source (bluez-utils-2.4.tar.gz)
> contains these files for some reason though.

Generate the diffs againt the CVS sources.

> The main reason for this typedef is that the original code did things
> like this:
> 
>     unint8_t link_key_t[16];
>     ...
>     memcpy(key0, key1, 16);
> 
> which, I think, is a lot worse than:
> 
>     memcpy(key0, key1, sizeof(link_key_t));
> 
> Don't you agree? (An alternative is to use #define LINK_KEY_SIZE 16
> instead of course.)

I am not sure how to handle this link key issue in general, but that was
not the argument. See below.

> > than the *_t version must match the structure and not define something 
> > complete different.
> 
> What do you mean?

If you typedef something and it ends with "_t" you should avoid to have
a struct with the same prefix, but different meaning. This example is
ok, but it is not good coding style (typedefs are ugly).

	struct abc {
		int a;
		int b;
		int c;
	};

	typedef struct abc abc_t;

Hope you get my point.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-31  1:18     ` Marcel Holtmann
@ 2004-01-31  9:27       ` Fredrik Noring
  2004-01-31 15:23         ` Marcel Holtmann
  0 siblings, 1 reply; 12+ messages in thread
From: Fredrik Noring @ 2004-01-31  9:27 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: BlueZ Mailing List

Hi Marcel

lör 2004-01-31 klockan 02.18 skrev Marcel Holtmann:
> However you should talk a look at libs2 and utils2 from CVS.

I haven't looked closely at libs2 but the hcid parts in utils2 appears
to be a copy of the original utils, except the files are renamed and put
in a "compat" directory with lots of other utilities. Why is that?

A "hcid" directory (as in the old "libs") would be better I think.

> Generate the diffs againt the CVS sources.

Maybe this a FAQ but I only get this:

   $ cvs -d:pserver:anonymous@cvs.bluez.org:/cvsroot/bluez login
   Logging in to :pserver:anonymous@cvs.bluez.org:2401/cvsroot/bluez
   CVS password:
   cvs [login aborted]: end of file from server (consult above messages if any)
   $

Any hints, please?

> Hope you get my point.

Yes, thanks.

Fredrik

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-31  0:32 ` Marcel Holtmann
  2004-01-31  0:55   ` Fredrik Noring
@ 2004-01-31 10:47   ` Fredrik Noring
  1 sibling, 0 replies; 12+ messages in thread
From: Fredrik Noring @ 2004-01-31 10:47 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: BlueZ Mailing List

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

Hi Marcel

lör 2004-01-31 klockan 01.32 skrev Marcel Holtmann:
> Follow the coding style.

Attached patch contains a bunch of cleanups.

 file.c     |   41 ++++++----------
 file.h     |   18 +++----
 hcid.h     |   12 ++--
 keytab.c   |  154 ++++++++++++++++++++++++++++++-------------------------------
 keytab.h   |   18 +++----
 lib.h      |    4 -
 security.c |   11 ++--
 7 files changed, 124 insertions(+), 134 deletions(-)

Fredrik


[-- Attachment #2: hcid-cleanups.patch --]
[-- Type: text/x-patch, Size: 15677 bytes --]

diff -Naur bluez-utils-2.4.orig/hcid/file.c bluez-utils-2.4/hcid/file.c
--- bluez-utils-2.4.orig/hcid/file.c	2004-01-31 11:38:18.000000000 +0100
+++ bluez-utils-2.4/hcid/file.c	2004-01-31 11:29:16.000000000 +0100
@@ -1,13 +1,13 @@
 /* 
-   BlueZ - Bluetooth protocol stack for Linux
-   Copyright (C) 2004 Fredrik Noring
-   
-   Written 2004 by Fredrik Noring <noring@nocrew.org>
-   
-   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;
-*/
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *  Copyright (C) 2004 Fredrik Noring
+ *  
+ *  Written 2004 by Fredrik Noring <noring@nocrew.org>
+ *  
+ *  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.
+ */
 
 #include <stdio.h>
 #include <stdlib.h>
@@ -17,15 +17,7 @@
 #include <fcntl.h>
 #include <syslog.h>
 #include <errno.h>
-#include <time.h>
 #include <fcntl.h>
-#include <time.h>
-
-#include <sys/ioctl.h>
-#include <sys/socket.h>
-#include <sys/time.h>
-#include <sys/stat.h>
-#include <asm/types.h>
 
 #include "file.h"
 #include "lib.h"
@@ -37,24 +29,24 @@
 	free(file);
 }
 
+/*
+ * Files are always terminated with 0.
+ */
 struct file *read_file(const char *filename)
-	/* Files are always terminated with 0. */
 {
 	struct file *file = 0;
 	size_t size = 0;
 	int fd;
 
 	fd = open(filename, O_RDONLY);
-	if (fd < 0)
-	{
+	if (fd < 0) {
 		if(errno != ENOENT)
 			syslog(LOG_ERR, "%s open failed. %s(%d)",
 					filename, strerror(errno), errno);
 		return 0;
 	}
 
-	for(;;)
-	{
+	for(;;) {
 		ssize_t r;
 
 		file = realloc(file, sizeof(struct file) +
@@ -65,7 +57,7 @@
 			exit(1);
 		}
 
-		r = read_n(fd, file->data + size, BUFFER_READ_SIZE);
+		r = read_sigsafe(fd, file->data + size, BUFFER_READ_SIZE);
 		
 		if (!r)
 			break;
@@ -80,8 +72,7 @@
 
 	close(fd);
 	
-	if(file)
-	{
+	if(file) {
 		file->size = size;
 
 		/* Always terminate files with 0. */
diff -Naur bluez-utils-2.4.orig/hcid/file.h bluez-utils-2.4/hcid/file.h
--- bluez-utils-2.4.orig/hcid/file.h	2004-01-31 11:38:19.000000000 +0100
+++ bluez-utils-2.4/hcid/file.h	2004-01-31 11:29:29.000000000 +0100
@@ -1,13 +1,13 @@
 /* 
-   BlueZ - Bluetooth protocol stack for Linux
-   Copyright (C) 2004 Fredrik Noring
-   
-   Written 2004 by Fredrik Noring <noring@nocrew.org>
-   
-   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;
-*/
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *  Copyright (C) 2004 Fredrik Noring
+ *  
+ *  Written 2004 by Fredrik Noring <noring@nocrew.org>
+ *  
+ *  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.
+ */
 
 struct file {
 	size_t size;
diff -Naur bluez-utils-2.4.orig/hcid/hcid.h bluez-utils-2.4/hcid/hcid.h
--- bluez-utils-2.4.orig/hcid/hcid.h	2004-01-31 11:38:19.000000000 +0100
+++ bluez-utils-2.4/hcid/hcid.h	2004-01-31 11:33:06.000000000 +0100
@@ -55,14 +55,14 @@
 	struct device_opts opts;
 };
 
-typedef uint8_t	link_key_t[16];
+#define LINK_KEY_SIZE 16
 
 struct link_key {
-	bdaddr_t   sba;
-	bdaddr_t   dba;
-	link_key_t key;
-	uint8_t    type;
-	time_t	   time;
+	bdaddr_t sba;
+	bdaddr_t dba;
+	uint8_t  key[LINK_KEY_SIZE];
+	uint8_t  type;
+	time_t	 time;
 };
 
 struct link_key_list {
diff -Naur bluez-utils-2.4.orig/hcid/keytab.c bluez-utils-2.4/hcid/keytab.c
--- bluez-utils-2.4.orig/hcid/keytab.c	2004-01-31 11:38:19.000000000 +0100
+++ bluez-utils-2.4/hcid/keytab.c	2004-01-31 11:34:37.000000000 +0100
@@ -1,13 +1,13 @@
 /* 
-   BlueZ - Bluetooth protocol stack for Linux
-   Copyright (C) 2004 Fredrik Noring
-   
-   Written 2004 by Fredrik Noring <noring@nocrew.org>
-   
-   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;
-*/
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *  Copyright (C) 2004 Fredrik Noring
+ *  
+ *  Written 2004 by Fredrik Noring <noring@nocrew.org>
+ *  
+ *  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.
+ */
 
 #include <stdio.h>
 #include <stdlib.h>
@@ -17,15 +17,9 @@
 #include <fcntl.h>
 #include <syslog.h>
 #include <errno.h>
-#include <time.h>
 #include <fcntl.h>
-#include <time.h>
 
-#include <sys/ioctl.h>
 #include <sys/socket.h>
-#include <sys/time.h>
-#include <sys/stat.h>
-#include <asm/types.h>
 
 #include <bluetooth/bluetooth.h>
 #include <bluetooth/hci.h>
@@ -35,9 +29,11 @@
 #include "lib.h"
 #include "file.h"
 
+/*
+ * Returns binary 0-15 for hex '0'-'a' and '0'-'A'. Returns -1 for
+ * invalid hex digits.
+ */
 static int parse_hex_digit(char c)
-	/* Returns binary 0-15 for hex '0'-'a' and '0'-'A'.
-	 * Returns -1 for invalid hex digits. */
 {
 	if('0' <= c && c <= '9')
 		return c - '0';
@@ -48,9 +44,11 @@
 	return -1;
 }
 
+/*
+ * Returns a character pointer to the character after the next newline
+ * or after end-of-file.
+ */
 static const char *goto_next_line(const char *str)
-	/* Returns a character pointer to the character after the next
-	 * newline or after end-of-file. */
 {
 	while(*str)
 		if(*str++ == '\n')
@@ -58,18 +56,20 @@
 	return str;
 }
 
+/*
+ * Allocate a new link_key item and put it on the top of the link
+ * structure.
+ */
 static struct link_key *allocate_link_key(struct link_key_list **link_key_list)
-	/* Allocate a new link_key item and put it on the top of the
-	 * link structure. */
 {
 	struct link_key_list *item;
 	
 	item = malloc(sizeof(struct link_key_list));
-	if (!item)
-	{
+	if (!item) {
 		/* A good reason for exit: We don't want to lose any
 		 * data when saving because we happened to fail
-		 * allocating a link_key. */
+		 * allocating a link_key.
+		 */
 		syslog(LOG_INFO, "Can't allocate link_key_list. Exit. %s(%d)",
 		       strerror(errno), errno);
 		exit(1);
@@ -89,16 +89,16 @@
 {
 	struct link_key_list *next;
 
-	for( ; list; list = next)
-	{
+	for( ; list; list = next) {
 		next = list->next;
 		free(list);
 	}
 }
 
+/*
+ * Load deprecated keys, typically from /etc/bluetooth/link_key.
+ */
 static struct link_key_list *load_deprecated_link_keys(void)
-	/* Load deprecated keys, typically from
-	 * /etc/bluetooth/link_key. */
 {
 	struct link_key_list *deprecated_link_key_list = 0;
 	struct file *key_file;
@@ -110,8 +110,7 @@
 
 	for(offset = 0;
 	    offset + sizeof(struct link_key) <= key_file->size;
-	    offset += sizeof(struct link_key))
-	{
+	    offset += sizeof(struct link_key)) {
 		struct link_key *deprecated_link_key;
 
 		deprecated_link_key =
@@ -126,13 +125,14 @@
 	return deprecated_link_key_list;
 }
 
+/*
+ * Parse keytab file, typically in /etc/bluetooth/keytab.
+ */
 static void parse_keytab(const char *str, struct link_key_list **link_key_list)
-	/* Parse keytab file, typically in /etc/bluetooth/keytab. */
 {
 	int line = 1;
 	
-	while(*str)
-	{
+	while(*str) {
 		struct link_key *link_key;
 		char sba_str[18], dba_str[18];
 		int type;
@@ -143,9 +143,8 @@
 			goto skip_row;
 
 		if(sscanf(str, "%17s %17s %d %ld",
-			  sba_str, dba_str, &type, &time) != 4)
+			  sba_str, dba_str, &type, &time) != 4) {
 			/* Skip unparsable row. */
-		{
 			syslog(LOG_ERR, "keytab:%d: Parse error", line);
 			goto skip_row;
 		}
@@ -161,24 +160,23 @@
 	}
 }
 
+/*
+ * Parse hex encoding of 16 bytes binary key.
+ */
 static int parse_key(const char *key_str, unsigned char *key, int line)
-	/* Parse hex encoding of 16 bytes binary key. */
 {
 	int i, hi, lo;
 	
-	for(i = 0; i < sizeof(link_key_t); i++)
-	{
+	for(i = 0; i < LINK_KEY_SIZE; i++) {
 		hi = parse_hex_digit(*key_str++);
-		if(hi == -1)
-		{
+		if(hi == -1) {
 			syslog(LOG_ERR,
 			       "keytab.shadow:%d: Key malformed", line);
 			return 0;
 		}
 
 		lo = parse_hex_digit(*key_str++);
-		if(lo == -1)
-		{
+		if(lo == -1) {
 			syslog(LOG_ERR,
 			       "keytab.shadow:%d: Key malformed", line);
 			return 0;
@@ -190,31 +188,33 @@
 	return 1;
 }
 
+/*
+ * Find matching sba/dba key pairs and attach the key to it. If there
+ * are several identical key pairs, attach the key to all of them.
+ */
 static void attach_key(struct link_key_list *link_key_list,
 		       const bdaddr_t *sba, const bdaddr_t *dba,
-		       const link_key_t key)
-	/* Find matching sba/dba key pairs and attach the key to it.
-	 * If there are several identical key pairs, attach the key to
-	 * all of them. */
+		       const uint8_t key[LINK_KEY_SIZE])
 {
-	for( ; link_key_list; link_key_list = link_key_list->next)
-	{
+	for( ; link_key_list; link_key_list = link_key_list->next) {
 		if(bacmp(&link_key_list->link_key.sba, sba) ||
 		   bacmp(&link_key_list->link_key.dba, dba))
 			continue;
 
 		link_key_list->has_key = 1;
-		memcpy(link_key_list->link_key.key, key, sizeof(link_key_t));
+		memcpy(link_key_list->link_key.key, key, LINK_KEY_SIZE);
+		
 		/* Let's continue because there might be duplicate entries. */
 	}
 }
 
+/*
+ * Find first matching sba/dba key pair.
+ */
 static struct link_key *get_key(struct link_key_list *link_key_list,
 				const bdaddr_t *sba, const bdaddr_t *dba)
-	/* Find first matching sba/dba key pair. */
 {
-	for( ; link_key_list; link_key_list = link_key_list->next)
-	{
+	for( ; link_key_list; link_key_list = link_key_list->next) {
 		if(!link_key_list->has_key ||
 		   bacmp(&link_key_list->link_key.sba, sba) ||
 		   bacmp(&link_key_list->link_key.dba, dba))
@@ -226,16 +226,17 @@
 	return 0;
 }
 
+/*
+ * Parse shadow file, typically in /etc/bluetooth/keytab.shadow.
+ */
 static void parse_shadow(const char *str, struct link_key_list *link_key_list)
-	/* Parse shadow file, typically in /etc/bluetooth/keytab.shadow. */
 {
 	int line = 1;
 	
-	while(*str)
-	{
+	while(*str) {
 		char sba_str[18], dba_str[18];
-		char key_str[2 * sizeof(link_key_t) + 1];
-		link_key_t key;
+		char key_str[2 * LINK_KEY_SIZE + 1];
+		uint8_t key[LINK_KEY_SIZE];
 		bdaddr_t sba, dba;
 		
 		if(*str == '#')
@@ -243,9 +244,8 @@
 			goto skip_row;
 
 		if(sscanf(str, "%17s\t%17s\t%32s",
-			  sba_str, dba_str, key_str) != 3)
+			  sba_str, dba_str, key_str) != 3) {
 			/* Skip unparsable row. */
-		{
 			syslog(LOG_ERR, "keytab.shadow:%d: Parse error", line);
 			goto skip_row;
 		}
@@ -261,9 +261,11 @@
 	}
 }
 
+/*
+ * Load keytab and associated shadow file. Returns 0 if the file
+ * couldn't be loaded.
+ */
 static struct link_key_list *load_keys(void)
-	/* Load keytab and associated shadow file. Returns 0 if the
-	 * file couldn't be loaded. */
 {
 	struct link_key_list *link_key_list;
 	struct file *key_file;
@@ -306,25 +308,22 @@
 	
 	*s++ = '\t';
 	
-	if(is_shadow)
-	{
+	if(is_shadow) {
 		int i;
 		
 		/* The link key */
-		for(i = 0; i < sizeof(key->key); i++)
-		{
+		for(i = 0; i < sizeof(key->key); i++) {
 			sprintf(s, "%02x", key->key[i]);
 			s += 2;
 		}
 		
 		*s++ = '\n';
 		*s++ = 0;
-	}
-	else
+	} else
 		/* Key type and time. FIXME: Use key type symbol? */
 		sprintf(s, "%d\t%ld\n", key->type, key->time);
 	
-	if (write_n(fd, row, strlen(row)) < 0) {
+	if (write_sigsafe(fd, row, strlen(row)) < 0) {
 		syslog(LOG_ERR, "keytab write failed. %s(%d)",
 		       strerror(errno), errno);
 		return 0;
@@ -333,8 +332,10 @@
 	return 1;
 }
 
+/*
+ * Save keytab and associated shadow file.
+ */
 static void save_keys(struct link_key_list *link_key_list)
-	/* Save keytab and associated shadow file. */
 {
 	struct link_key_list *list_item;
 	int keytab_fd, shadow_fd;
@@ -360,8 +361,7 @@
 	    list_item->next;
 	    list_item = link_key_list->next)
 		;
-	for( ; list_item; list_item = list_item->prev)
-	{
+	for( ; list_item; list_item = list_item->prev) {
 		if(!list_item->has_key)
 			continue;
 		if(!write_keytab_row(keytab_fd, &list_item->link_key, 0))
@@ -371,7 +371,8 @@
 	}
 
 	/* The following scheme is designed to make keytab and
-	 * keytab.shadow readable at all times. */
+	 * keytab.shadow readable at all times.
+	 */
 	
 	/* Remove backups and link new backups. */
 	unlink(HCID_KEYTAB_FILE"-");
@@ -397,11 +398,9 @@
 
 	/* Convert deprecated key_list file if needed. */
 	link_key_list = load_keys();
-	if(!link_key_list)
-	{
+	if(!link_key_list) {
 		link_key_list = load_deprecated_link_keys();
-		if(link_key_list)
-		{
+		if(link_key_list) {
 			syslog(LOG_INFO, "Converting deprecated link_keys "
 			       "file to keytab format.");
 			save_keys(link_key_list);
@@ -437,8 +436,7 @@
 
 	link_key_list = load_keys();
 
-	if(link_key_list)
-	{
+	if(link_key_list) {
 		k = get_key(link_key_list, &key->sba, &key->dba);
 		if(k)
 			exists = 1;
diff -Naur bluez-utils-2.4.orig/hcid/keytab.h bluez-utils-2.4/hcid/keytab.h
--- bluez-utils-2.4.orig/hcid/keytab.h	2004-01-31 11:38:19.000000000 +0100
+++ bluez-utils-2.4/hcid/keytab.h	2004-01-31 11:29:40.000000000 +0100
@@ -1,13 +1,13 @@
 /* 
-   BlueZ - Bluetooth protocol stack for Linux
-   Copyright (C) 2004 Fredrik Noring
-   
-   Written 2004 by Fredrik Noring <noring@nocrew.org>
-   
-   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;
-*/
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *  Copyright (C) 2004 Fredrik Noring
+ *  
+ *  Written 2004 by Fredrik Noring <noring@nocrew.org>
+ *  
+ *  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.
+ */
 
 void init_link_key(void);
 void set_link_key(struct link_key *key);
diff -Naur bluez-utils-2.4.orig/hcid/lib.h bluez-utils-2.4/hcid/lib.h
--- bluez-utils-2.4.orig/hcid/lib.h	2004-01-31 11:38:19.000000000 +0100
+++ bluez-utils-2.4/hcid/lib.h	2004-01-31 11:21:37.000000000 +0100
@@ -47,7 +47,7 @@
 }
 
 /* Read exactly len bytes (Signal safe)*/
-static inline int read_n(int fd, void *buf, int len)
+static inline int read_sigsafe(int fd, void *buf, int len)
 {
 	register int t = 0, w;
 
@@ -68,7 +68,7 @@
 }
 
 /* Write exactly len bytes (Signal safe)*/
-static inline int write_n(int fd, void *buf, int len)
+static inline int write_sigsafe(int fd, void *buf, int len)
 {
 	register int t = 0, w;
 
diff -Naur bluez-utils-2.4.orig/hcid/security.c bluez-utils-2.4/hcid/security.c
--- bluez-utils-2.4.orig/hcid/security.c	2004-01-31 11:38:19.000000000 +0100
+++ bluez-utils-2.4/hcid/security.c	2004-01-31 11:33:19.000000000 +0100
@@ -86,10 +86,11 @@
 		hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_REPLY,
 				LINK_KEY_REPLY_CP_SIZE, &lr);
 		/* Apparently the original author intended to save
-		   the request time for this key, but no call to the
-		   save function was made so this was lost.
-
-		   key.time = time(0); */
+		 * the request time for this key, but no call to the
+		 * save function was made so this was lost.
+		 * 
+		 * key.time = time(0);
+		 */
 	} else {
 		/* Link key not found */
 		hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_NEG_REPLY, 6, dba);
@@ -106,7 +107,7 @@
 	ba2str(sba, sa);
 	syslog(LOG_INFO, "link_key_notify (sba=%s)\n", sa);
 
-	memcpy(key.key, evt->link_key, sizeof(link_key_t));
+	memcpy(key.key, evt->link_key, LINK_KEY_SIZE);
 	bacpy(&key.sba, sba);
 	bacpy(&key.dba, dba);
 	key.type = evt->key_type;

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-31  9:27       ` Fredrik Noring
@ 2004-01-31 15:23         ` Marcel Holtmann
  2004-01-31 15:40           ` Fredrik Noring
  0 siblings, 1 reply; 12+ messages in thread
From: Marcel Holtmann @ 2004-01-31 15:23 UTC (permalink / raw)
  To: Fredrik Noring; +Cc: BlueZ Mailing List

Hi Fredrik,

> I haven't looked closely at libs2 but the hcid parts in utils2 appears
> to be a copy of the original utils, except the files are renamed and put
> in a "compat" directory with lots of other utilities. Why is that?
> 
> A "hcid" directory (as in the old "libs") would be better I think.

the compat directories contains the old code until all parts are
replaced. This is why it is called compat. Don't focus on it.

> Maybe this a FAQ but I only get this:
> 
>    $ cvs -d:pserver:anonymous@cvs.bluez.org:/cvsroot/bluez login
>    Logging in to :pserver:anonymous@cvs.bluez.org:2401/cvsroot/bluez
>    CVS password:
>    cvs [login aborted]: end of file from server (consult above messages if any)
>    $
> 
> Any hints, please?

We ran into a SF problem, again. Even my latest update failed and now
the developer access is also blocked. We have to wait until they solved
it.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-31 15:23         ` Marcel Holtmann
@ 2004-01-31 15:40           ` Fredrik Noring
  2004-01-31 15:52             ` Marcel Holtmann
  0 siblings, 1 reply; 12+ messages in thread
From: Fredrik Noring @ 2004-01-31 15:40 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: BlueZ Mailing List

Hi Marcel

lör 2004-01-31 klockan 16.23 skrev Marcel Holtmann:
> the compat directories contains the old code until all parts are
> replaced. This is why it is called compat. Don't focus on it.

Since the "new" hcid was lost and there is no replacement, I'll work 
on the old code. I think it's very useful. I'm currently cleaning up 
the mess in "glib-ectomy" and preparing it for a DBus connection.

Fredrik

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-31 15:40           ` Fredrik Noring
@ 2004-01-31 15:52             ` Marcel Holtmann
  2004-01-31 16:03               ` Fredrik Noring
  0 siblings, 1 reply; 12+ messages in thread
From: Marcel Holtmann @ 2004-01-31 15:52 UTC (permalink / raw)
  To: Fredrik Noring; +Cc: BlueZ Mailing List

Hi Fredrik,

> > the compat directories contains the old code until all parts are
> > replaced. This is why it is called compat. Don't focus on it.
> 
> Since the "new" hcid was lost and there is no replacement, I'll work 
> on the old code. I think it's very useful. I'm currently cleaning up 
> the mess in "glib-ectomy" and preparing it for a DBus connection.

it is not very hard to replace this code, but I am a little bit busy and
the CVS is dead at the moment. But I think we should discuss some design
goals of the new device manager.

I don't see what kind of mess in "glib-ectomy" you mean, but go ahead
and send a patch for it. The D-Bus support is one of the things I
definitively want to have in the next release, so every patch would help
here. Please keep both separate, because small patches are easier to
review.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-31 15:52             ` Marcel Holtmann
@ 2004-01-31 16:03               ` Fredrik Noring
  2004-01-31 18:01                 ` Marcel Holtmann
  0 siblings, 1 reply; 12+ messages in thread
From: Fredrik Noring @ 2004-01-31 16:03 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: BlueZ Mailing List

lör 2004-01-31 klockan 16.52 skrev Marcel Holtmann:
> But I think we should discuss some design goals of the new device manager.

Great idea. What's your plan for it?

> I don't see what kind of mess in "glib-ectomy" you mean, but go ahead
> and send a patch for it. 

Some bads, I think:

  - The API can be improved
  - Tons of ugly (even in opionon) typedef:s
  - No style

Fredrik

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-31 16:03               ` Fredrik Noring
@ 2004-01-31 18:01                 ` Marcel Holtmann
  2004-01-31 18:15                   ` Fredrik Noring
  0 siblings, 1 reply; 12+ messages in thread
From: Marcel Holtmann @ 2004-01-31 18:01 UTC (permalink / raw)
  To: Fredrik Noring; +Cc: BlueZ Mailing List

Hi Fredrik,

> > But I think we should discuss some design goals of the new device manager.
> 
> Great idea. What's your plan for it?

one of my big goals is to have a library with a much improved API. This
means that all HCI related functions use the hci_* prefix and follow the
naming scheme from the HCI part of the Bluetooth specification. But the
HCI part should not be used for common applications. These applications
should use bt_* functions that offer an enhanced functionality. For
example setting the local name. The hci_* part only send the HCI
command, while the bt_* stuff also stores the name in a database so it
can be restored after reboot. I think you get the idea.

> > I don't see what kind of mess in "glib-ectomy" you mean, but go ahead
> > and send a patch for it. 
> 
> Some bads, I think:
> 
>   - The API can be improved
>   - Tons of ugly (even in opionon) typedef:s
>   - No style

in the early days the hcid depends on glib and this code is a small
compat layer to be free from the glib. I wrote a similar replacement for
utils2. May you want to take a look at the helper library.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Bluez-devel] [PATCH] New keytab storage
  2004-01-31 18:01                 ` Marcel Holtmann
@ 2004-01-31 18:15                   ` Fredrik Noring
  0 siblings, 0 replies; 12+ messages in thread
From: Fredrik Noring @ 2004-01-31 18:15 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: BlueZ Mailing List

lör 2004-01-31 klockan 19.01 skrev Marcel Holtmann:
> I think you get the idea.

The idea sounds excellent.

Fredrik

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2004-01-31 18:15 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-30 23:56 [Bluez-devel] [PATCH] New keytab storage Fredrik Noring
2004-01-31  0:32 ` Marcel Holtmann
2004-01-31  0:55   ` Fredrik Noring
2004-01-31  1:18     ` Marcel Holtmann
2004-01-31  9:27       ` Fredrik Noring
2004-01-31 15:23         ` Marcel Holtmann
2004-01-31 15:40           ` Fredrik Noring
2004-01-31 15:52             ` Marcel Holtmann
2004-01-31 16:03               ` Fredrik Noring
2004-01-31 18:01                 ` Marcel Holtmann
2004-01-31 18:15                   ` Fredrik Noring
2004-01-31 10:47   ` Fredrik Noring

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox