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

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 ;-)

[1] http://padovan.org/blog/2009/07/bluez-first-patch-was-merged/

How to use:

Put it into ~/.vim/plugin to autoload the plugin every time you open VIM. You can also source it manually:

:source /path/to/pastebin.vim

You can set your favorite pastebin site and your name editing the pastebin.vim

From [1]: “To use the script is very simple. Just visually block (Shift-v) the lines of code you want to send to the Pastebin and enter the command :PasteCode. The blocked text will be sent to the Pastebin and the new URL will be shown on the Vim statusline.”

[1] http://djcraven5.blogspot.com/2006/10/vimpastebin-post-to-pastebin-from.html
[2] http://www.las.ic.unicamp.br/~gustavo/pub/vim/vim-pastebin/plugin/pastebin.vim
[3] http://github.com/pao/vim-pastebin/tree/master

Bluetooth: Add configuration support for ERTM and Streaming mode

Add support to config_req and config_rsp to configure ERTM and Streaming
mode. If the remote device specifies ERTM or Streaming mode, then the
same mode is proposed. Otherwise ERTM or Basic mode is used. And in case
of a state 2 device, the remote device should propose the same mode. If
not, then the channel gets disconnected.

Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Now I’m going to implement support to send and receive I-frames and S-frames. Some part of the code for that . First I’m going to add support to transmissions with txWindow = 1 (i.e., only one packet can be sent per time without acknowledgment from the other side) and no retransmission support and I intend to finish it during this week.

Here is a quick roadmap for my work:

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 REJ S-Frame
   2. support SREJ S-Frame
   3. support RNR S-Frame to indicate busy condition
   4. use RR S-frame to show that is ready to receive I-frames
5. Enable Retransmission Timer
6. Enable Monitor Timer
7. Test BlueZ against others stack that implement ERTM

I expect that until end of August finish all this topics. So, let’s hack. =)

A arena durou 3 dias. Às 22 horas do terceiro dia deveríamos entregar o servidor e o cache com DNSCurve para o Daniel. Meu grupo era formado por mim, pelo João Paulo Rechi Vita[4], que também é aluno aqui da Unicamp e assim como eu, está no Google Summer of Code pelo projeto BlueZ. E por Rodrigo Exterckötter Tjäder, aluno de Ciência da Computação da UFSM – Universidade Federal de Santa Maria.

Ficamos sabendo o que teríamos que fazer apenas no início do primeiro dia, então passamos as primeiras horas descobrindo do que se tratava o DNSCurve (principalmente eu, que não estudei Redes formalmente na Unicamp ainda). Após entendermos o DNSCurve fomos atrás de implementações de DNS para tomarmos como ponto de partida para nossa implementação. Partimos preferencialmente para implementações em python, pois seria bem mais rápido e tranquilo desenvolver.

Rechi Vita encontrou uma implementação de servidor DNS em python, chamada pymds[5] e uma implementação de cache chamada PyDNSCache[6]. Ambas as implementações são extremamente pequenas, o que facilitou o nosso entendimento e a expansão desses códigos para suportar o DNSCurve.

Para a parte cripotográfica do DNSCurve usamos a slownacl[7] biblioteca que implementa a todo calculo criptográfico do DNSCurve. Acompanhavam a slowsalt pequenas bibliotecas para manipulação pacotes DNS, isto é, funções prontas pra descriptografar e criptografar pacotes DNS que são enviados e recebidos pelos servidor e cache.

Passamos os dois primeiros dias integrando esses 3 códigos: pymds, PyDNSCache e slownacl. No final do segundo dia tinhamos um servidor e um cache funcionando para o envio e recebimento de pacotes. Mas esse cache nao resolvia nomes recursivamente e como ia dar muito trabalho implementar isso no nosso cache, resolvemos abandoná-lo e partir para uma nova implementação de cache usando a biblioteca dnspython[8]. Com esse novo código foi possível fazer o cache resolver nomes recursivamente e consequentemente conseguir pegar a chave pública do servidor DNS.

O Resultado desses três dias de maratona foi recompesado com a vitória. Nossa solução foi eleita a melhor e recebemos um celular G1 rodando Android cada e muitos elogios do djb sobre o nosso código. =)

Nosso código está aqui[9] e abaixo coloco a descrição sobre a implementação que enviamos ao Daniel junto com nosso código:

We implemented the two proposed parts separately.

(1) DNS Server — pymdscurve.tar.bz2

We based our implementation on pymds [5], a modular python DNS server
licensed under the MIT license. It’s a standalone DNS server, in terms
it doesn’t resolve any names it doesn’t know. For the NaCl functions,
we used the slownacl lib from dnscurve [1]. Despite it doesn’t says on
the website, we contacted the authors (both Matthew and Angel) and
both of them told us the is public domain and a note on the project
page is missing. Matthew even added a README to the code which says
it’s public domain and updated some code on the lib to make it
compliant with NaCl spec (article on your website).

(2) DNS Cache

For the cache we tried two different approaches.

(i) PyDNSCacheCurve.tar.bz2 — First we added the DNSCurve messages to
PyDNSCache [6], which is a very simple DNS cache written in python and
intended to be used as a python library. This code didn’t had any
license note on the project page either, but we contacted the author
and he licensed it under Creative Commons Attribution 3.0 United
States License. Since it’s just a cache of DNS information, it used
gethostbyname() from the socket module. We changed it to use a
function we implemented, gethostfromDNS(), to send the necessary DNS
messages to get the information from a server. For the cryptography
part we’ve also used slownacl from dnscurve [1]. We didn’t implemented
the ability to resolve names recursively on PyDNSCache, so we
hardcoded the server public key inside the code.

(ii) dnspythoncurve.tar.bz2 — Since solution (i) was unable to
resolve names recursively, we decided to use dnspython [8], which
provides a lot of helper functions to deal with DNS. We’ve added
DNSCurve extensions to it and also added a recursive resolver.
dnspython [4] is released under a BSD-style license. Since recursive
resolution works we can get the server name to check if it a DNSCurve
enabled server and, if so, obtain it’s public key.

We’ve tested pymdscurve and dnspythoncurve under a scenery with two
servers, one configured as authority for .com and other as authority
for example.com, in order to test recursive resolution. Both config
files are shipped in pymdscurve package.

We plan to send patches back to all projects we’ve added code to. We
have also added some code to some dns helper functions on dnscurve
[1], outside of slownacl

[0] http://fisl.softwarelivre.org
[1] http://dnscurve.org
[2] http://cr.yp.to/djb.html
[3] http://cr.yp.to/djbdns.html
[4] http://jprvita.wordpress.com
[5] http://sourceforge.net/projects/pymds/
[6] http://www.rbgrn.net/projects
[7] http://github.com/mrd/dnscurve/tree/master
[8] http://www.dnspython.org/
[9] http://www.las.ic.unicamp.br/~joaopaulo/arena/

About GSoC 2009 in Brazil:
Leslie Hawthorn has posted yesterday on Google Open Source Blog some statistics about GSoC 2009, and Brazil is the top 5 country for accepted student applicants , with 43 students. I’m too happy to hear that, but I’m also waiting for the statistic about students accepted per University. Last year my university (Unicamp – University of Campinas) was the 2nd in the whole world.

And I wanna congratulate my friends of University of Campinas that were accepted on GSoC 2009 too. They are João Paulo Rechi Vita, working on BlueZ with me and Vudentz is his mentor too; Bruno Cardoso working on LLVM for the third time. Helder Ribeiro on ReviewBoard; João “lvwr” Correa on NMAP and Thiago “bolaum” Abdnur.  We will hack togheter for next four months to accomplish our Google Summer of Code project.

Getting deeper on Bluetooth:
For a first read you can read [1] e [2] , if wanna more you can go to [3] e and look thought the spec.

[1] http://en.wikipedia.org/wiki/Bluetooth

[2] http://bluetooth.com/Bluetooth/Technology/Works/Overview_of_Operation.htm

[3] http://bluetooth.com/Bluetooth/Technology/Building/Specifications/

ps: if you find errors in my English, please tell me, I’m learning yet. =)