BlueZ on GSoC: Accepted students announced

Yesterday Google released the accepted students for this year’s Google Summer of Code and BlueZ will be participating with 4 students:

Project: Bluetooth Replayer
Student: Anton Weber
Mentor: Anderson Lizardo

Project: OBEX Filesystem In Userspace
Student: Michał Poczwardowski
Mentor: Vinicius Gomes

Project: Implement AVRCP 1.3 Controller Role
Student: Rafael Fonseca
Mentor: Luiz Augusto von Dentz

Project: Visualization of Bluetooth traffic
Student: Thiago da Silva Arruda
Mentor: Gustavo Padovan

It is now community bonding time, where students get know their mentors and the community. We wish a great summer to all students.  :-)

 

BlueZ on Google Summer of Code 2012

BlueZ was accepted to take part in GSoC 2012, if you don’t know what GSoC is, please go  to its page and learn about.

We have already published our list of ideas, so if you are a student  take a look there and check what might interest you. Then you can talk to one of our mentors to learn more about and work on a GSoC proposal.
You can get more information about BlueZ on GsoChere. Our contact info is on the same page.

We hope to have a great summer in this year’s Google Summer of Code.

GSoC: BlueZ projects sucessfullly finished

During this summer four students took part in Google Summer of Code with BlueZ. All four have passed the final term and produced a lot of code. Each of them the wrote a report about their projects. The reports were posted in bluez.org. Here follows the links:

Improve EDS backend of Phone Book Access Profile (PBAP)
Student: Bartosz Szatkowski
Mentor: Claudio Takahasi

Nintendo Wii Remote Device Driver
Student: David Herrmann
Mentor: Gustavo Padovan

Implementing the Basic Imaging Profile(BIP)
Student: Jakub Adamek
Mentor: Vinicius Gomes

Implement the Video Distribution Profile(VDP)
Student: Prasad Bhat
Mentor: Luiz Augusto von Dentz

That is it for this summer, I’m hoping to have another great summer on GSoC next year.

BlueZ: GSoC students announced

Last Monday Google announced the students accepted to take part in 2011 edition of Google Summer of Code. BlueZ this time got four slots. Our projects, and students, for this year are:

Improve EDS backend of Phone Book Access Profile (PBAP)
Student: Bartosz Szatkowski
Mentor: Claudio Takahasi

Nintendo Wii Remote Device Driver
Student: David Herrmann
Mentor: Gustavo Padovan

Implementing the Basic Imaging Profile(BIP)
Student: Jakub Adamek
Mentor: Vinicius Gomes

Implement the Video Distribution Profile(VDP)
Student: Prasad Bhat
Mentor: Luiz Augusto von Dentz

Besides the mentors, Johan Hedberg and Marcel Holtmann along with whole community will also support the students helping them with doubts and technical decisions. We expect to have a very productive summer, happy hacking to all students. ;)

Google Summer of Code: List of Ideas for BlueZ

As many of you may already know Google announced the accepted organizations for Google Summer of Code and BlueZ[0] was accepted again! If you a student and know nothing about it go to the Google Summer of Code page[1] and learn about it.

We are already accepting projects proposal, check our ideas list[2] or propose some new good idea you want to implement in BlueZ. Discuss them with the BlueZ mentors and submit your project proposal.  Our freenode  irc channel for GSoC is #bluez-gsoc.

We will be very glad to accept the best students proposals to take part of GSoC 2011 with BlueZ.

[0] http://www.bluez.org
[1] http://code.google.com/soc/
[2] http://www.bluez.org/development/gsoc/gsoc-ideas-list/

Google Summer of Code has come. Again!

For the second year I got accepted on the Google Summer of Code project to work with the BlueZ organization. My project this year is to work on the DUN Client. DUN is the Dial-up Network Profile, it provides access to the Internet and other dial-up services via Bluetooth.  My project intends to do the DUN client only, but if I have time at the end of the project I’ll work on the DUN Server too.

The implementation will make changes in BlueZ, ConnMan and oFono. Most of the changes will be inside oFono. There, we need to use the AT command parser and the  PPP stack (recently added to the oFono repo). The work consist on integrate everything and implement the missing parts of the AT command parser and the PPP stack, and the DUN agent.

On the BlueZ part the work will be the service export for DUN Data Terminal role and and the DUN Agent server to register agents and pass the RFCOMM file descriptor. For testing purposes we can use the Serial API in the beginning. That work is very similar to what we did for the HFP this year.

The ConnMan integration: ConnMan will setup the NAT and the  Internet connection. The DUN integration on ConnMan is similar to the PAN integration(still a work in progress) , so we can reuse part of that implementation.

That’s it.  I’ll post updates here during the development of the project. Now let me code. ;-)

Also, congratulation to the others Unicamp (University of Campinas) students that were accepted on GSoC too. :-)

GSoC meet-up at Unicamp

Last Wednesday (March 3rd) we did a talk about Google Summer of Code at Unicamp. The talk was part of the weekly talk about Free Software in the University. It was presented by mentors and students from past GSoCs. We explained how GSoC works and how one can take part on it this year. I’ll post here some photos:

Google Summer of Code 2009: Final stats

Google Open Source team has just published yesterday a set of stats[1] about Google Summer of Code 2009 and Google Summer of Code during the years. The good news is that University of Campinas (Unicamp) is on the second place in number of accepted students to GSoC 2009, with 12 projects.  We also are the second place in the history of the program with 37 projects. Congratulations to all guys from University of Campinas that take part on GSoC. We’ve been done a great job. Unicamp rocks! :-)

[1] http://google-opensource.blogspot.com/2009/09/tasty-new-google-summer-of-code-stats.html

BlueZ: status update into the L2CAP layer

Since the last post here (it was a long time ago :-) too much work was done, but ERTM isn’t fully implemented yet. So, what did I do last month?
I’ll explain each of the features I implemented on the next paragraphs, but if this are boring for you just take a look at the roadmap at the end of this post.

First I did the support to send and receive I-frames (the data frames) and created the support to RR S-frames to acknowledge the received I-frames. It first worked with a txWindow=1 (which means only one packet can be send without receive acknowledge from the receiver side). The next step was support a txWindow up to 63 (the maximum value specified). To bring this support I have been using sk_buff lists from the net core implementation.

Support for Segmentation and Reassembly(SAR) of L2CAP SDUs: this feature allows upper applications to use a buffer greater than the L2CAP size packet. The buffer is break down in many packet on the transmitter side and then reassembled on the receiver side and pushed to the upper layer.

REJ frame exception: When a packet is lost we need to start the recoveries procedures. BlueZ won’t support raise of REJ exception (we support only raise of SREJ exception by now, spec says that we can choose one of them). But we need to support the receipt of a REJ-exception (i.e. receive a REJ frame). On the receipt of a REJ frame the L2CAP entity needs to stop the transmission and starts to retransmit the requested packets.  A REJ frame tells the ReqSeq(packet id sequence) and all packets up to ReqSeq – 1 shall be considered acknowledged, the others shall be retransmitted.

SREJ frame exception: BlueZ starts a SREJ exception when it detects lost packets. It sets its state to SREJ_SENT(It means that L2CAP entity is under recovery proccess) and sends a SREJ S-frame for each lost packets. The transmitter side shall resend the packets requested in the SREJ frames without stops transmission of new frames. SREJ exception saves retransmission of unneeded frames.

Retransmission And Monitor Timers: The Retransmission Timer shall be (re)started each time we send a I-frame. If it expires we send a RR-frame and start the Monitor Timer. The other side should response the RR frame immediately, if the the other side do not response and the Monitor Timer expires we resend the RR frame. A maximum value for the of Monitor Timer’s timeouts can be defined. If a L2CAP entity exceeds this value the channel shall be disconnected.

Busy condition on the remote side: If the remote side enters in a busy condition it will send a RNR frame. So, when the local side receives this frame it should mark the remote busy flag as true and stop the transmission of packets. It restarts the sending of packets only when the remote sides send a REJ, SREJ or RR frame. This says the remote busy condition was cleared.

Streaming mode: This mode of operation is useful to the Bluetooth Streaming Profiles such as A2DP and VDP(not yet implemented). It can take advantages of the Segmentation and Reassembly features.

FCS Option: It is a crc16 check for L2CAP packets. It is the default if both sides support it. If a L2CAP entity receives a packet with a broken crc16 it will drop. The receive procedure will miss it and start the recovery procedure.

Roadmap updated:

  1. Implement ERTM with txWindow=1 and retransmission disabled.
    1. send I-frames
    2. receive I-frames
    3. support RR S-frames to acknowledge I-frames received
    4. acknowledge I-frames
  2. Support txWindow up to 63
  3. Support segmentation and reassembly of L2CAP SDUs
  4. Enable retransmission
    1. support receipt REJ S-Frame
    2. support receipt SREJ S-Frame
    3. support raise of SREJ exception
  5. Support busy conditions exceptions
  6. Enable Retransmission Timer
  7. Enable Monitor Timer
  8. Implement Streaming Mode
  9. Implement FCS Option
  10. Support duplex channel
  11. Use SOCK_STREAM as default for Enhanced Retransmission and Streaming Modes.
  12. Test BlueZ against others stacks

What’s next?

Now I’m working the busy condition exception and the support for the ERTM duplex channel. Today, just one side can send data packets. Then I’ll put ERTM as default when SOCK_STREAM is selected. I expect finish these issues on the coming weeks. After, I’ll spend my time fixing the bugs I find trough the code.

ps: Sorry for my too not bad English ;-)