Anuncio show de bola

Essa e’ pra descontrair (ou nao) no final da sexta-feira. De vez em quanto e’ bom postar algo “fora da casinha” como dizem meus amigos do sul.

Vejam este post no blog CyberVida sobre o anuncio do suco de laranja “Do Bem”:

http://cybervida.com.br/e-por-falar-em-anuncio-show-de-bola

Compartinho a mesma opiniao que o autor do post, nao gosto de funk, mas a propaganda ficou muito bem bolada.

Mais uma para categoria BrainDamage deste site!

Getting started to NFC

I am starting to develop NFC (Near Field Communication) solutions. At start it is so confusing, many terms, many ISOs (ISO14443, ISO18092, ect) and few documentation about this subject.
Currently I am using an evaluation board from NXP (PN531_USB) and using the driver HAL API from NXP. Driver compilation for Linux kernel worked fine, but I am getting some issues: the board is detected correctly, but the NFC_HAL_SDK_Example can’t to detect any cards (I am using virgin Mifare cards).

Happily I found the libNFC project: http://www.libnfc.org

It is an open source library to use with NFC devices and I am planning to use it on my project.

Visualizando fluxo PPP via terminal

Podemos facilmente usar o minicom para inicializar uma conexao com modem GPRS, mas tambem é possivel fazer isto via o prompt do terminal:

echo -ne "AT+CGDCONT=1,IP,tim.com.br\r" > /dev/ttyACM0
echo -ne "ATD*99***1#\r" > /dev/ttyACM0
cat /dev/ttyACM0

Testing uIP TCP/IP stack

This week I tested uIP communication using a GPRS modem. There is not a PPP stack to uIP but Instituto Atlantico developed this stack I am using now. All headers files have a license text saying it is open source (a BSD like), but I couldn’t find it at any place on the internet.
Well, it was hard to got working. I read the RFC1661 in order to understand more about the PPP, LCP and other procotols.
I found a very nice text describing about the PPP low level using examples to illustrate it:
http://www.geocities.com/SiliconValley/2072/bit60.txt

Happily yesterday I salved it on my computer because today geocities (Yahoo) tell me it is not available. Here goes it:

Establishing A PPP Link:

PPP begins with LCP (Link Control Protocol). The first step, after a
communications channel becomes active, is for each side to send a
Configure-Request packet. This is a standard type of LCP packet that means
the sender is requesting configuration information. Assuming all goes well,
each side should respond in turn with a Configure-ACK packet. As soon as both
sides have sent a Configure-ACK packet, the link is considered established,
and the exchange moves on to the authentication phase. (If one side does not
accept the other side's Configure-Request packet, it will respond with a
Configure-Reject or a Configure-NAK packet.)

Authentication is actually optional; However, virtually all PPP servers will
implement it, since otherwise anybody could log in and start using the system
without authorization to do so. If authentication is used, the type of
authentication required will actually have already been specified; It is part
of the Configure-Request packets that were exchanged earlier. The
Configure-Request packet must explicitly describe if (for example) PAP or
CHAP authentication is desired. Thus, both systems already know what kind of
authentication to use once the authentication phase is reached.

Once the authentication phase is complete, LCP has done its job, and the NCPs
(Network Control Protocols) which the client wishes to use may begin. For
most dial-up Internet access situations, the main NCP used would be IPCP (IP
Control Protocol).

So what exactly goes into an LCP packet? A very basic LCP Configure-Request
packet is this:

01 01 00 04

This is the shortest possible Configure-Request packet. The first byte of an
LCP packet indicates what type of message it contains. The code for
Configure-Request is 1, so the first byte of a Configure-Request packet must
always be 1. The next byte is an identifier. This must be unique for each
separate LCP packet sent over the connection, and can be arbitrarily set to
anything. In this case, we're using 1 (a logical choice for the first
packet). The next two bytes indicate the size of the entire LCP packet, in
bytes. In this case, the whole packet is 4 bytes (the smallest possible LCP
packet). Thus, 0004 is used, and we are left with a complete LCP packet.

Unfortunately, you cannot just dial in to your ISP and send a raw LCP packet,
because they must be encapsulated in PPP format, which is considerably more
complicated. The standard for dial-up ISPs is to use "PPP in HDLC-like
framing", defined in RFC 1662. Under this system, each byte of actual data to
be sent is to be preceded by a 7Dh character (called a "control escape"
character), and the actual bytes are to be XORed with 20h before sending. (I
know, who's the genius who came up with THAT arrangement? It seems ludicrous,
but that's how PPP works.) So, our original LCP byte pattern, under this
system, becomes this:

7D 21 7D 21 7D 20 7D 24

This is almost a complete PPP frame, except for two additions: The beginning
and the end. A PPP LCP frame is supposed to begin with the following six
bytes: 7E FF 7D 23 C0 21. Also, each frame is to be ended with a 7E
character. Adding these to the previous byte string, we now have:

7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 24 7E

This is a complete PPP frame, which you can transmit to a dial-up ISP as soon
as the modem has connected, which will be a valid Configure-Request LCP
packet to it. Sending this to the ISP will probably make it begin
transmitting Configure-Request packets back to you (if it doesn't
automatically do so upon modem connect), and assuming you send it a
Configure-ACK, and it sends you a Configure-ACK as well, an LCP link has been
established.

Now, of course, you've got to understand what the ISP sends you back. To
demonstrate, here's a fairly typical Configure-Request packet that you'll see
from a typical ISP. Slight variations are common, but this shows most of the
configuration options you'll see out there:

7E FF 7D 23 C0 21 7D 21 0F 7D xx xx 7D 22 7D 26 7D xx 7D xx 7D xx 7D xx
7D 23 7D 24 C0 23 7D 25 7D 26 xx xx xx xx 7D 27 7D 22 7D 28 7D 22
(If PPP Multilink Protocol (MP) is used): 7D 31 7D 24 7D xx xx
(If endpoint discriminator option is used): 7D 33 7D xx 7D 21 blah
(Final 3 bytes, consisting of FCS and closing 7E): xx xx 7E

The first six bytes are, again, a signal of the beginning of a PPP LCP frame.
Next, we have 7D 21, which is an LCP byte 1, meaning this is a
Configure-Request message. Immediately after the 21 is a byte 0F, which is
used for the identifier. (Different ISPs may choose different identifier
numbers, but it doesn't matter, it's just an arbitrary number for reference.)
Although technically, according to the RFC, the identifier number *should* be
preceded by another 7D character and XORed with 20, it seems to be in fashion
for ISPs to do neither. Thus, the identifier comes right after the 21, and is
transmitted in its true form, not XORed with 20.

After that comes two more LCP bytes; These are for the size of the entire LCP
packet, in bytes. The actual numbers are simply shown as xx here, since they
will vary. Although technically, you're supposed to use a 7D character for
each new character, it seems to be common practice among ISPs to transmit
both size bytes at once, so instead of 7D xx 7D xx, you might just see it
without the second 7D, to wit: 7D xx xx.

The first three standard LCP fields (packet code, packet identifier, and
packet length) have now been transmitted, and everything following are the
configuration options. You can tell which configuration option is being
configured by the first byte of it. In this case, the next byte after the
size bytes is an LCP byte 2, which is the code for an Async Control Character
Map (ACCM). Next is a 6, indicating that this whole option is 6 bytes long.
The 2 for the code and the 6 for the length count as part of that, meaning
the rest of the code is 4 bytes long. Following that are 4 LCP bytes, which
collectively form the actual ACCM. (Don't worry too much about what the ACCM
itself means right now.)

Next we have an LCP byte 3, which is the code for indicating authentication
protocol. After that is a 4, indicating this field is 4 bytes. The final 2
bytes come immediately without being 7D'd, and they are C0 23, which is the
code for PAP (Password Authentication Protocol). If CHAP were desired, C2 23
would have been used instead. (PAP and CHAP were originally documented in RFC
1334, "PPP Authentication Protocols". The CHAP specification was later
updated in RFC 1994.)

Next is an LCP byte 5, which is the code for a magic number. After that is a
6, meaning this field is 6 bytes long (including these actual code and length
bytes). Right after the 6 come four bytes which together make up the actual
magic number itself. (Does it seem odd that the ACCM had each byte preceded
by a 7D, while the magic number is transmitted directly and without
modification? It's rather silly, but that's how this stuff is implemented.)

Next comes LCP 7 and 2. These two bytes, together, are an indication that the
ISP is letting you know it wants to use Protocol Field Compression (PFC).
After that is an 8 and a 2, which lets you know it also wants to use Address
and Control Field Compression (ACFC).

There are other things which most ISPs nowadays include in the frame as well,
most of which are documented in RFC 1990, "The PPP Multilink Protocol (MP)".
Most common among these are the MRRU (Maximum Received Reconstructed Unit)
option and the endpoint discriminator option. The MRRU begins with an LCP
byte 11, which indicates the MRRU LCP option. (RFC 1990 states that it's a
17, but it's talking decimal, and we're talking hexadecimal here. 17 decimal
equals 11 hexadecimal.) After that is an LCP byte indicating the size of this
option, which is always 4. After that, two bytes in succession (which are not
separated by a 7D, although the first one is preceded by a 7D) which indicate
the actual MRRU size. If the system actually sends the MRRU option, this
indicates that the system sending it implements the PPP Multilink Protocol.
If not rejected, the system will continue to use the PPP MP.

The other PPP MP option commonly configured at this stage is the endpoint
discriminator option. This starts with an LCP byte 13. (Again, RFC 1990 says
this should be a 19, but it's talking decimal. 19 decimal equals 13
hexadecimal.) After that is an LCP byte stating the size of this option,
which is always 3 plus the length of the actual address specified in this
option (we'll get to the address in a moment). The next LCP byte is usually a
1, indicating a locally-assigned address. Immediately following the 1 is a
succession of bytes which are the actual address of the system specified in
this option. (These bytes are represented as "blah" in the sample PPP frame
above.)

The PPP frame closes with two bytes which you can safely ignore for now
(they're the FCS (Frame Check Sequence)). The final byte is 7E, which always
closes the PPP frame, just as it opens a new one. So, now you have seen a
fairly realistic PPP frame from an ISP, and you know what to expect in the
real world (pretty much). So how do we acknowledge this to the ISP? With a
Configure-ACK packet. Making a Configure-ACK packet is actually quite simple,
because all we need to do is mirror the options that were sent to us. In
fact, the complete packet would look almost exactly the same as the
Configure-Request packet it is acknowledging, except that instead of
beginning with an LCP byte 1, it begins with an LCP byte 2. The identifier
byte must be the same, the length will be the same, and all the options must
be transmitted back the same way, so the other side of the connection
understands that we are acknowledging all of them. Our complete PPP frame
that we transmit back, then, would look like this:

7E FF 7D 23 C0 21 7D 22 0F 7D xx xx 7D 22 7D 26 7D xx 7D xx 7D xx 7D xx
7D 23 7D 24 C0 23 7D 25 7D 26 xx xx xx xx 7D 27 7D 22 7D 28 7D 22
(If PPP Multilink Protocol (MP) is used): 7D 31 7D 24 7D xx xx
(If endpoint discriminator option is used): 7D 33 7D xx 7D 21 blah
xx xx 7E

Note that the only difference is, the eighth byte has been made 22 instead of
21, making it an LCP byte 2 instead of a 1. As soon as Configure-ACK packets
like this have been sent by each side, the LCP link is open and can continue
to authentication with PAP or CHAP, or to networking with an NCP if no
authentication was specified in the Configure packets.

I was getting an error during the Configurating Phase (when client and server exchange Configuration Options), the server was returning a NACK. After my tests I discovered the problem happened because the PPP server in the point can’t accept changing the MRU length.

Alternativa ao NetMeeting

Existem varias alternativas ao netmeeting para comunicacao de voz. Mas uma alternativa util para realizacao de palestras/treinamentos online e’ o yugma:

www.yugma.com

Ele suporta Windows, Linux e Mac.

Desvantagem: nao e’ software livre.

BigEndian or LittleEndian – Qual melhor para rede?

Qual tipo de arquitetura é melhor para usar em dispositivos que grande carga de rede, little endian ou big endian?

O padrao TCP/IP é big endian entao as plataformas big endian como Sparc, M68K e PowerPC são mais adequadas para aplicacoes em rede.

Mais info:
http://www.netrino.com/Embedded-Systems/How-To/Big-Endian-Little-Endian

Serial Scope

Sniffar a porta serial quando um sistema operacional (SO) esta rodando nao e’ uma tarefa simples, pois o SO ira’ pegar os dados da serial e jogar no buffer antes mesmo do sniffer conseguir detectar algum problema no protocolo.

Pensando em resolver este problema um desenvolvedor criou um software que funciona como um osciloscopio para visualizar os dados que estao trafegando no cabo serial. Para mais informacoes acesse:

http://www.gumbley.me.uk/scope.html

Compartilhando seu terminal com outros usuarios

Voce ja deve conhecer o comando screen, ele é muito útil para evitar o trabalho em execucao no servidor remoto onde voce logou via ssh. Mas ele pode ser usado para coisas mais interessantes que apenas manter seu terminal ativo caso sua conexao caia, voce pode usa-lo para trabalhos interativos com outros usuarios como em treinamentos.

Seu amigo “jose” está logado na maquina “metropole” e criou um sessão:

$ screen -S teste

Entao voce deverá logar na maquina “metropole” como root:
$ ssh root@metropole

Em seguida transforme-se no usuario “jose”:
# su – jose
$

Agora conecte na sessao que o usuario jose criou:
$ screen -x teste

Caso voce receba a mensagem de erro:
$ screen -x teste
Cannot open your terminal ‘/dev/pts/1′ – please check.

Dê permissão para /dev/pts/1:
# chmod 777 /dev/pts/1

Tente novamente, agora voce esta logado na mesma sessao que o usuario logado da maquina criou. O unico problema é que voce precisa logar como o mesmo usuario que abriu a sessao.

Fonte: http://tuxtraining.com/2009/01/16/collaboration-with-screen#more-1439

Como recuperar uma modificacao apos um “git reset –hard HEAD^”

Sem querer voce executou um “git reset –hard HEAD” para remover o ultimo patch que voce criou, só que voce esqueceu de salvar o patch e gostaria de ter novamente as modificacoes que voce fez.

Nao precisa comecar a chorar, basta seguir esta dica:

$ echo “added new file” > file2
$ git add file2
$ git commit -m ‘added file2′
Created commit f6e5064: added file2
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file2

$ git reset –hard HEAD^
HEAD is now at 1a75c1d… added file1

$ cat file2
cat: file2: No such file or directory

$ git reflog
1a75c1d… HEAD@{0}: reset –hard HEAD^: updating HEAD
f6e5064… HEAD@{1}: commit: added file2

$ git reset –hard f6e5064
HEAD is now at f6e5064… added file2

$ cat file2
added new file

Fonte: http://stackoverflow.com/questions/5473/undoing-a-git-reset-hard-head1

Clonando o git do kernel para processadores i.MX

Use o comando:

git clone git://git.pengutronix.de/git/imx/linux-2.6.git

Depois basta mudar para o branch remoto mxc-master.