lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110609083345.GA2894@dell.ccr.corp.intel.com>
Date:	Thu, 9 Jun 2011 17:33:45 +0900
From:	Johan Hedberg <johan.hedberg@...il.com>
To:	Waldemar.Rymarkiewicz@...to.com
Cc:	keithp@...thp.com, padovan@...fusion.mobi, marcel@...tmann.org,
	linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Regression caused by "Bluetooth: Map sec_level to link key
 requirements"

Hi,

On Thu, Jun 09, 2011, Waldemar.Rymarkiewicz@...to.com wrote:
> >Patch 13d39315c22b128f4796fc008b04914a7c32bb1a is causing a 
> >regression From 2.6.39. I cannot communicate with my Nokia 
> >N900 using either the SyncML or DUN RFCOMM services.  I get a 
> >connection reset error shortly after startup.
> >
> >I've reverted this patch on top of something past -rc2 (to be 
> >precise, I'm branching from ef2398019b305827ea7130ebaf7bf521b444530e).
> >With the following fix-up to make things build again, my 
> >bluetooth works again.
> 
> Logs from kernel and bluez would be much appreciated to see what happend.
> As I remember this was pretty well tested with BITE test by Johan.

The patch was not only fine but actually *needed* by the BITE. So
reverting it will make some qualification tests fail.

There's no DUN support in the N900 by default and the only package I'm
aware that provides it uses the command line rfcomm tool with high
security on the socket to block just-works SSP pairing (since the rfcomm
tool doesn't use the authorization framework to guarantee a user pop-up
dialog). The SyncML code I can't comment on since I haven't seen it.

So potentially this might be limited to high security sockets.
Speculating further, if the device connecting to the N900 has a pre-2.1
Bluetooth controller this could simply be about not having a 16-digit
PIN which high security services require. So could whoever is able to
reproduce the issue try repairing and entering a 16-digit PIN to see if
the problem goes away? And if this is in fact the case then the kernel
code is working exactly as it should; the only issue is that these
services should really be using medium security level instead of high.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ