* [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