New HCI-USB device, no MAC?

I just acquired a new USB Bluetooth dongle.
Upon attachment it is correctly recognised as USB HCI but strangely it does not carry any valid MAC address:

Requesting information ...
BD Address: 11:11:11:11:11:11
Device Name: piwi-1
LMP Version: 1.2 (0x2) LMP Subversion: 0x1fe
Manufacturer: Integrated System Solution Corp. (57)
Features: 0xbf 0xfe 0x8d 0x78 0x08 0x18 0x00 0x00
<3-slot packets> <5-slot packets> <encryption> <slot
offset>
<timing accuracy> <role switch> <sniff mode> <RSSI> <channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <power control> <transparent SCO> <broadcast encrypt> <enhanced iscan> <interlaced iscan> <interlaced pscan> <inquiry with RSSI> <AFH cap. slave> <AFH cap. master> <AFH class. master>

Is this a known issue for that chipset?

In fact I bought two dongles with the same chipset (but different casing) and both start with the above default MAC.
Is there a tool to set a valid MAC?

And if so, to which MAC should I set it?
Or would probably the Windows driver program an initial MAC if first connected to Windows?

Hi Nils,

Quoted 3 lines

And if so, to which MAC should I set it?
Or would probably the Windows driver program an initial MAC if first connected to Windows?

I need information from ISSC on this, but you might wanna stick it into a Windows machine and see if the address changes and you see a different address from a Linux machine. Maybe it is kinda ROM version of the chip.

Regards
Marcel

Windows did not change it :(
Also the tools that com eon the CDROM seem not to be able to change it.

Have you contacted ISSC about that issue already?

It should be forbidden to release hardware without valid BDADDR into the market... That is kind of stupid and dangerous.

Hi Nils,

Quoted 7 lines

Windows did not change it :(
Also the tools that com eon the CDROM seem not to be able to change it.

Have you contacted ISSC about that issue already?

It should be forbidden to release hardware without valid BDADDR into the market... That is kind of stupid and dangerous.

I think it isn't really the fault of ISSC. It is a stupid module manufacturer that has not clue that an BD_ADDR suppose to be unique.

Regards

Marcel

Did anyone ever find a solution/workaround for these ISSC-based dongles? I seem to have acquired two dongles with a BD_ADDR of 11:11:11:11:11:11 and from searching Google, it seems that a lot of other people are in the same boat.

Hi Evan,

Quoted 1 line

Did anyone ever find a solution/workaround for these ISSC-based

dongles? I seem

Quoted 1 line

to have acquired two dongles with a BD_ADDR of 11:11:11:11:11:11 and

from

Quoted 1 line

searching Google, it seems that a lot of other people are in the same

boat.

no idea. The ISSC guys need to contact me and they haven't so far. From my point I am no longer running after the manufacturers. Simply buy a device with a CSR chip and you are happy.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel...
Even I was facing similar problems with the ISSC dongles... but I guess in India there is a shortage of CSR chipset based dongles.........

Indians anyone who have CSR bluetooth dongle please let me know whr u can find it...,,,,,,,,,,, this is a SOS message....
i have one CSR one which is bought 4 yrs back but not able to find the sources of the manufacturer.... I hope someone staying in India will help me out in this....

Quoted 35 lines · Marcel Holtmann

Hi Evan,

Quoted 1 line

Did anyone ever find a solution/workaround for these ISSC-based

dongles? I seem

Quoted 1 line

to have acquired two dongles with a BD_ADDR of 11:11:11:11:11:11 and

from

Quoted 1 line

searching Google, it seems that a lot of other people are in the same

boat.

no idea. The ISSC guys need to contact me and they haven't so far. From my point I am no longer running after the manufacturers. Simply buy a device with a CSR chip and you are happy.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Quoted 9 lines · Marcel Holtmann <marcel <at> holtmann.org> writes:

Hi Nils,

Quoted 5 lines

Windows did not change it :(
Also the tools that com eon the CDROM seem not to be able to change it. Have you contacted ISSC about that issue already?
It should be forbidden to release hardware without valid BDADDR into the market... That is kind of stupid and dangerous.

I think it isn't really the fault of ISSC. It is a stupid module manufacturer that has not clue that an BD_ADDR suppose to be unique.

Quoted 2 lines

Regards
Marcel

Hi Marcel,

Did anyone ever find a solution/workaround for these ISSC-based dongles? I seem to have acquired two dongles with a BD_ADDR of 11:11:11:11:11:11 and from searching Google, it seems that a lot of other people are in the same boat.

Cheers,
Evan Paul Fletcher

Quoted 3 lines

Did anyone ever find a solution/workaround for these ISSC-based dongles? I seem to have acquired two dongles with a BD_ADDR of 11:11:11:11:11:11 and from searching Google, it seems that a lot of other people are in the same boat.

I have contacted ISSC about that issue.

Hopefully the will reply and send the HCI or whatever commands necessary... I have two of those dongles which renders at least one useless (I guess two times the same BDADDR will not work in a piconet ;)

Quoted 24 lines

Dear Sir:

Very thank you for your kindly and useful reponds and suggestion. We will pass your mail to our manager seriously.

Thank you very much again!!

Sincerely yours,
I.S.S.C./W
2006/4/28

----- Original Message -----
From: "Nils Faerber" <[email protected]>
To: "ISSC Sales" <[email protected]>
Sent: Thursday, April 27, 2006 6:58 PM
Subject: Re: Inquiry Form[BT Dongle issue]

Quoted 4 lines

Quoted 4 lines

Quoted 1 line · ISSC Sales

Quoted 1 line

Dear Sir:

Hello!

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Thanks for your quick response!

Quoted 3 lines

Quoted 3 lines

I.S.S.C. is a IC Vendor.
We offer BT IC with IVT sw together only.
We do not manufacture or sell any end product.

Yes, I know.
But the described issue does not only occur with a specific

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

with *most* ISSC based products.

Quoted 2 lines

Quoted 2 lines

Therefor,Your bluetooth dongle is not I.S.S.C.'s product. They just use I.S.S.C.'s chip and solution.

Yes, correct.

Quoted 7 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Your dongle should be NG product, please contact your original seller/manufactur to solve end product issue for more support.[ From the item "KY-BT100 ", here help you to find their

original

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

web-site

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Hope it will be much helpful to you. Thank you very much! ]

Frankly, no, it was not helpful.

You are the manufatcurer of the chipset and baseband software,

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

have the knowledge of the verdor specific HCI commands of your chips. Most manufacturers will not deal with such details and just implement your provided solution.

But even if, I still think that it is your responsibility to get your product based end user products right. ISSC is currently the only chipset manufacturer with the problem of not providing correct

Quoted 1 line

Quoted 1 line

Quoted 1 line

addresses. So this must be also your problem not only the

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

The only simple thing I am asking you for is the single simple HCI command to set a correct Bluetooth MAC address.

Please have a look on the market today and test-buy some products

Quoted 1 line

Quoted 1 line

Quoted 1 line

implement your ISSC Bluetooth chipset. I would bet that more than

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

not carry a valid Bluetooth address which is a violation of the Bluetooth specification.

So please rethink your position and provide the HCI command or at

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

a ready made tool (e.g. for Windows-OS) to set the Bluetooth address. Also please get in contact with your customers so that they pay

Quoted 1 line

Quoted 1 line

Quoted 1 line

attention to this issue! There are numerous reports about e.g.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

headsets that all have the same Bluetooth address (i.e. 11:11:11:11:11:11). In such a situation it would be impossible to

Quoted 1 line

Quoted 1 line

Quoted 1 line

more than one of those in the same piconet. An unacceptable

Quoted 16 lines

Quoted 16 lines

Quoted 16 lines

This has never been reported with chipsets e.g. from CSR.

Quoted 3 lines

Quoted 3 lines

Sincerely yours,
I.S.S.C./W.
2006/4/27

Best regards
nils faerber

Quoted 7 lines

Quoted 7 lines

----- Original Message -----
From: "Nils Faerber" <[email protected]>
To: <[email protected]>
Sent: Wednesday, April 26, 2006 5:35 PM
Subject: Inquiry Form

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Interested in=Bluetooth Product
Solution=USB Dongle
Product=
Enquiry for=FAE
Company=kernel concepts
product=Operating software development
URL=http://www.kernelconcepts.de
Country=DE

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Address=Dreisbachstr. 24, D-57250 Netphen person=Nils Faerber
job=CTO
[email protected] Tel=+49-271-77109112
Fax=+49-271-77109119
Description=Dear ladies an gentlemen!
We are a software development company concentrated on Linux

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

system development. We are member of the Bluetooth SIG since

Quoted 2 lines

(early

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

adopter) and have been part in the Linux Bluetooth stack

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

from the very early beginning.

A customer of ours wants to deploy a device that uses your

Quoted 7 lines

USB

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

chipset:

ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth

Adapter

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

The problem we currently have with those devices is that

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

contain a valid Bluetooth MAC address, they come with a

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

11:11:11:11:11:11. We have seen this with all ISSC dongles.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

USB-HCI description for CSR based modules to change the MAC

Quoted 4 lines

a

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

correct value but not for your modules.

So we would like to ask for your kind assistance! We just

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

the HCI command to set the MAC (Bluetooth) address of thode

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

This would help us a lot and our customer can continue to

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

chips.

Many thanks in advance for any information you can provide!

Kind regards
nils faerber

PS: If we need to sign an NDA to get this information I

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

Quoted 11 lines

so.

Quoted 9 lines

Quoted 9 lines

Result=Send

--
kernel concepts Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen Mob: +49-176-21024535
--

Quoted 7 lines

Quoted 6 lines

Quoted 6 lines

--
kernel concepts Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen Mob: +49-176-21024535
--

The issue was that some Bluetooth dongles do not contain a valid Bluetooth MAC address. Well, this is against the spec and so the dongles are bad but sometimes users cannot avoid to get such. So I still see the need that we do as good as we can to help those users and get those bad dongles working.

Long story short, Marcel's bdaddr application contained in the latest release of bluez-utils works, at least for the two dongles I have with ISS chipsets. So the BDADDR can be set now.

I wanted an automatic solution so that when I plug the dongle in it is automatically assigned "an" address. So first I created an udev rule that calls an application when the specific USB device with the vendorid:deviceid I know to be bad is inserted - in my case 1131:1001 (plaease let me know more!).

Then I created a small shell script which sets a "more correct" address than the default 11:11:11:11:11:11. I assume in this script that an ethernet device is present in the system as eth0 and use its MAC for the Bluetooth dongle too.

I did this for two reasons:
1. On the same machine I always want to have the same BDADDR, so random was no choice.
2. The ethernet addresses also have to follow the same rules as Bluetooth MAC addresses, i.e. they have to be unique. So the probability of a collision is very low.

Hi Nils,

Quoted 11 lines

Then I created a small shell script which sets a "more correct" address than the default 11:11:11:11:11:11. I assume in this script that an ethernet device is present in the system as eth0 and use its MAC for the Bluetooth dongle too.

I did this for two reasons:
1. On the same machine I always want to have the same BDADDR, so random was no choice.
2. The ethernet addresses also have to follow the same rules as Bluetooth MAC addresses, i.e. they have to be unique. So the probability of a collision is very low.

and now PAN will stop working, because the eth0 and bnep0 will have the same MAC address. Not a good idea.

Regards
Marcel

Hi Nils,
=

Quoted 6 lines

Then I created a small shell script which sets a "more correct" address than the default 11:11:11:11:11:11. I assume in this script that an ethernet device is present in the system as eth0 and use its MAC for the Bluetooth dongle too.
=

Quoted 6 lines

I did this for two reasons:
1. On the same machine I always want to have the same BDADDR, so random was no choice.
2. The ethernet addresses also have to follow the same rules as Bluetooth MAC addresses, i.e. they have to be unique. So the probability of a collision is very low.

=

and now PAN will stop working, because the eth0 and bnep0 will have the same MAC address. Not a good idea.

Quoted 12 lines

Quoted 11 lines

Then I created a small shell script which sets a "more correct" address than the default 11:11:11:11:11:11. I assume in this script that an ethernet device is present in the system as eth0 and use its MAC for the Bluetooth dongle too.

I did this for two reasons:
1. On the same machine I always want to have the same BDADDR, so random was no choice.
2. The ethernet addresses also have to follow the same rules as Bluetooth MAC addresses, i.e. they have to be unique. So the probability of a collision is very low.

Quoted 2 lines

and now PAN will stop working, because the eth0 and bnep0 will have the same MAC address. Not a good idea.

Well, after reading http://en.wikipedia.org/wiki/MAC_address i guess that we just could set bit 1 of the 6th byte to signal "locally administered" _and_ distinguish that address from the ethernet MAC address.

Or is this totally wrong?

But then, what happens if you plug two of those adapters into one machine?