Bluetooth Documentation

In the past I got to know that motivation comes by streams, I did not worry too much, and said to myself that it was just a matter of waiting for the next stream. The problem is that it has been near 2 years of non activity, awaiting for one of those streams to come.

Real life temptations, and the increasing responsibilities during these years, have eclipsed the free time. I always had backup plan, but the Economical situation in my country has made think about having another back-up plan, of the backup plan.

And a third reason is some property I just acquired to accomplish a life dream, which is taking all of the creativity remaining on me. It is a piece of land in the mountain, with a ruin house where I am trying to build my little own paradise. Much in the style of Frank Herbert (Dune writer), coexisting with nature and environment converting a dry and abandoned place in such little paradise. This is also explanation why this blog might change radically its topic.

Back in third quarter of 2006 after leaving yellowTAB and Germany, kind of decided to leave the BeOS scene, but then I was back 1 year later in 2007, writing a Bluetooth Stack. So it could happen again, I have been and I will keep subscribed in mail lists, follow the news, reply questions and offer all support I can. I’ll be around as I was up to now, just not likely developing.

So here is a piece of overview documentation of all I have been doing these years(dia format):

L2cap under network/protocols/l2cap:  Provides socket interface to have l2cap channels. L2CAP offers connection oriented and connectionless sockets. But bluetooth stack as this point has no interchangeability with TCP/IP, A Higher level Bluetooth profile must be implemented

HCI under  src/add-ons/kernel/bluetooth : Here we have 2 modules, one for handling global bluetooth data structures such as connection handles and L2cap channels, and frames

H2generic under src/add-ons/kernel/drivers/bluetoothThe USB driver, implementing the H2 transport

Bluetooth kit under src/kit/bluetoothC++ implementation based on JSR82 api

Bluetooth Server under src/servers/bluetoothBasically handling opened devices (local connected fisically in our system) and forwaring kit calls to them

Bluetooth Preferences under src/preferences/bluetooth
Configuration using the kit


Test applications under src/tests/kits/bluetooth

There is a small prototype component which is not here documented below  src/add-ons/bluetooth/ResetLocalDevice. Its intention was to be an add-on of bluetooth preferences, So that new HCI commands could be customized by users or external developers. I did not like at the end the idea, I did not find the flexibility I wanted.

Whoever is interested can contact me and I can share more documentation such as roadmaps and TODOs.

Thank you all

L2CAP next steps

Summer is still here, productivity in code is one of the lowest ones since I remember. Summer is to blame, hardly remember which update i need to give now.

Related my development I did a small incrusion in Caya development, implementing some features I needed to feel comfortable regarding the chat windows behaviour. BTW last release with MSN support!

But focusing on bluetooth L2CAP and its sockets interface has been a bit improved. As we said in the previous post, Haiku could initiate a pairing process and establish a communication link.

The next step was to allow Haiku act as a client to request opening a channel in the given communication link to finally interchange real user information from node to node.

There has been implemented a test application in src/test/kits/bluetooth/l2capClient. I was able to request pairing with a device (a Motorola V5), open a communication channel and send dummy data to him. the phone obviously did not understand information, and closed the communication.

Still unmature and some configuration parameters are unsupported, but if both nodes are Haiku, they could send information that each other understand. Therefore with that implemented some small applications could be implemented to have 2 haiku nodes interchanging normal user data wireless through bluetooth. This opens possibilities to implement small custom and non standard applications to:

• Chat between 2 nodes.
• Send flattened BMessages
• File exchanges

between 2 Haiku nodes.

Por fin!

Haiku initiating encrypted pairing

A bit of status update,

During the last months I have been working stabilizing the HCI layer, and the user interaction to pair. Up to now I was using the remote device to be the master of the communication therefore using that incoming information to guide the implementation.

Haiku could before search for remote devices, but could not decide by itself to communicate with them. Then a "Pair" button has been implemented in preferences. Implementing encrypted and non encrypted pairing with them. Additionally there is a new checkbox in preferences(with an unfortunate location at the moment) to indicate that Haiku requires, that link to be placed between devices, to be encrypted:

This is maybe the most complex messages interchange in HCI layer together with scanning devices. There was then work rewriting and refactoring code in the server to be able to see clearly how sequences flowed.

Here we can see how Haiku forces my phone to match a pincode, hardly readeable as usual, but it says in Spanish "haiku-bluetooth, Add to My Devices?"

Next step is make the same at L2cap layer. Haiku more or less handles l2cap channels as slave, so now it is turn to act as master too...

Some Internal features

There was a bug I carried since long ago, It was hard to detect and its reproduction was depending very much on how well the Slab allocator worked for net_buffers. The debugging shown like trying to send a buffer that was already sent... all fake as it was a reused one.

There were important internal features to be implemented as to have a dedicated thread to handle all incomming RX data, before it was done almost all in interrupt context, therefore the USB or transport bus usage is more responsible now.

Bluetooth Tasks for a GSoC project ...

Haiku Bluetooth Stack implements basic functionality on lower and middle layers, this functionality needs to be completed and all Bluetooth 2.X possibilities explored.

Requirement: Bluetooth enabled Haiku system

Skill set: C++ kernel development, userland development, overview bluetooth stack knowledge(optional)

• New Tasks: 
• RemoteDevices Database
• Manage server existence depending of LocalDevices
• Fixes:
• Fix monitoring of incoming LocalDevices(USB)
• Use LayoutManager for debug console + codestyle it
• LocalDevices allocation/leaking LocalDevice::GetLocalDevice
• Improvements
• UI
• Improve Deskbar Addon
• Improve PinCode Window
• Add Remaining Features in DeviceView
• Put non relevant information under a ToolTip
• Functionality
• UserLand tools(Preferences)
• Retrieve Discovery and DevClass (other settings?) in Startup
• Store information
• Window position
• Default LocalDevice
• Settings (Inquiry time, Policy)
• Pairing/Auth/Encryption use cases ...

Windows 7 overwrites Haiku partitions!

As my Christmas holiday were really long, I decided to use the occasion to reorganize all my hardware, with the new pieces I got during the last months. I started by putting all together moving RAM here and there, HD's and so on.

Once the candidate final machine was set, it was the time to start installing operating systems.

The first idea was to replace my Haiku development machine with this new one, but this, was to have had 60GB(20+40) so, it was enough space to have all of them: Haiku, Linux, and if all was ok, try a Windows 7. I would not expect that guys from Redmond were going to punish me so much for setting Windows the last in the queue.

So I started with Linux, to get the grub ready, and create within Linux all the partition. Then I went with 2 installations of Haiku: First one, the Alpha release and the second one with a fresh build.

All fine, all so nice with my new desktop, resynced all SVNs did some commits.

Then there was the 40GB HD reserved ONLY for the gigantic OS (even the HD was set as first HD in the IDE bus). After installation I was still happy as Win7 was more or less running smoothly in a moderate machine (Athlon Thunderbird 1,2GHz 768RAM).

All problems came or better said, they showed up trying to set Grub to boot Windows7.

Although I was sure I was pointing to the same partition I keep getting a message "BOOTMGR Missing".

Browsing and browsing I arrived to a really concerning post in the Ubuntu forums:

Quoting Belboz99:

"Just now I realized that Win7 creates at least 2 partitions when you install it, even though you may have only one selected and formatted for it's use."

Ok I thought, no way, I already checked the table and there is no new partition on that disk(40GB windows dedicated one with spare unpartitioned space), Also is impossible to fit another partition on the other disk as it is full with Linux and Haiku.

Checking 2 posts below I can quote from ramzai:

"And what is even worse, Win7 may put its bootloader to other existing FAT or NTFS partitions, even on the other hd, as it was in my case. I installed Win7 to (hd1,2) and then found bootmgr file on the (hd0,2) partition with music and video files."

Oh oh... then I started reviewing carefully all partitions... and there you are, a BFS one, suddenly became a NTFS...

WIN7 installation just went over my disk, even having free unpartitioned space on the same disk it was getting installed it went to the other disk, Found a partition of an unrelevant type (BFS, the first Haiku one), set it to NTFS, FORMATTED IT, and wrote there a bootloader. Win7 just overwrote my Haiku development partition, for just placing its bootloader!!

yeah Microsoft, while fixing all the mess and reinstalling, no opensource was written, you achieved it. I am just really thankful that you did not choose to crash my critical haiku data partition, or the sources one.