Dear Maycon. Thanks for you answer! Yes! Just only after installing pppd works the communication with my sink mote, and now I'm getting the sensor values from it!. In this sense is more simple the communication in Blip2.0 than Blip1.0.
Thanks again. Alejandro. > ---- > *Maycon Maia Vitali* (aka 0ut0fBound) > Offensive Security Certified Expert (OSCE) > Security Researcher @ Hack'n Roll > http://maycon.hacknroll.com > Hack'n Roll > > > > 2012/4/17 <[email protected]> > >> Dear all. >> >> I am trying to install the driver for Blip 2.0 in a computer with >> constrained resources in order to communicate it with the mote >> BaseStation >> (telosb). I managed to run Blip 1.0 with sheevaplug (based on ARM) but >> for >> Blip 2.0 is a bit complicated. So I have a question. >> >> The pppd come by default with tinyos-2.x or my computer must have >> installed it before run Blip 2.0? >> > > The pppd is a common tool on linux OS. Each distribution has a simples way > to instasll it. > > >> >> According to the tutorials, I can't do : >> >> pppd debug passive noauth nodetach 115200 /dev/ttyUSB0 nocrtscts >> nocdtrcts >> lcp-echo-interval 0 noccp noip ipv6 ::23,::24 >> >> > You need to install ppp tool. On ArchLinux I did pacman -S ppp and got > installed. > > >> Thanks in advance, >> >> Alejandro. >> >> >> >> >> >> > On Mon, Apr 16, 2012 at 5:14 AM, Daniel Bimschas < >> > [email protected]> wrote: >> > >> >> Hi list, >> >> >> >> I've read http://www.tinyos.net/tinyos-2.1.0/doc/html/tep113.html and >> I >> >> want to make sure that I understood everything correctly / ask some >> >> questions: >> >> >> >> 1) SerialP CRC field: The guide says "CR = Two-byte CRC over S to end >> of >> >> Payload: SerialP". Does this mean that the CRC includes the S >> (sequence >> >> number) field? >> >> >> > >> > That was my understanding but from taking a close look at the source >> code, >> > it looks like it also includes the Proto byte in front of the sequence >> > field. And the CRC should include the PROTO byte too. >> > >> > Phil is that correct? >> > >> > >> >> 2) The SerialP documentation states that PC-to-mote communication >> >> can/does >> >> use acknowledgements. >> >> >> > >> > I've never understood the SerialP ack implementation. Not sure >> exactly >> > what it does or how it works. >> > >> > >> >> a) Are acknowledgements mandatory or optional? >> >> >> > >> > From what I've seen they are optional. I've got serial >> communications >> > (transmit only from the mote) and there is nothing on the other side >> that >> > is sending asks back. >> > >> > b) I can't find out how the acknowledgments are represented in the >> packet >> >> format (3.6). How do you request an acknowledgment? Are they always >> >> send? >> >> c) How does the actual acknowledgment message look like (packet >> >> format)? >> >> >> > >> > Not sure but I suspect that it uses just the Proto field and the >> sequence >> > number. If they are actually used, it would be good if it were >> properly >> > documented. >> > >> > >> > 3) The SerialP description states "SerialP uses SerialFrameComm to >> send a >> >> delimiter between frames". Does this mean that a fragmented packet on >> >> application layer will result in several packets encapsulated in >> >> HdlcTranslateC, using different sequence number fields in the SerialP >> >> payload of HdlcTranslateC? >> >> >> > >> > SerialP and the AM layer does not do any fragmentation. There is no >> > fragmentation implemented. It is one of the reasons I'm interested >> in >> > the >> > 6lowpan IPv6 implementation. The problem is IPv6 is rather fat and >> I'm >> > almost out of space on my mote. >> > >> > >> >> 4) The SerialP description states "SerialP uses SerialFrameComm to >> send >> >> a >> >> delimiter between frames, a serial-level type field, [...]". >> >> a) Is the "serial-level type field" the same field as "P = Protocol >> >> byte: >> >> SerialP" in "3.6 Packet Format"? Or is this referring to "D = Packet >> >> format >> >> dispatch byte: SerialDispatcherC"? >> >> >> > >> > I believe the "serial-level type field" being referred to is the type >> > field that is part of the payload. If D is 0 then the Payload is an >> > Active Message packet and the payload looks like >> > >> > dst src len grp type data >> > >> > The example packet in the TEP is wrong. It says that the packet >> looks >> > like: >> > >> > 7e 40 09 00 be ef 05 7d 5d 06 01 02 03 04 05 7e >> > >> > It is missing the SRC field which is normally is included. And it is >> > also >> > missing the CRC. Given a dispatch byte of 00 the following data is >> an >> AM >> > packet and should have dst, src, len, grp, am_type, data. The low >> level >> > serial encapsulation doesn't have any inherent addressing. So as >> soon >> > as >> > the example starts to talk about a destination address and given that >> the >> > dispatch byte is a 0, it is talking about the AM encapsulation. >> > >> > >> >> b) In case the "serial-level type field" is not the same as "P = >> >> Protocol >> >> byte: SerialP": What's the purpose of P? What values can it take? >> >> >> > >> > P is different than the serial-level type field. It can have... >> > >> > 67 PROTO_ACK >> > 68 PROTO_PACKET_ACK >> > 69 PROTO_PACKET_NOACK >> > >> > The whole protocol is underspecified so I have no idea how it works or >> > what >> > these values do. The only one that seems to currently be implemented >> is >> > PROTO_PACKET_ACK. >> > >> > But like I said above it is unclear to me how the ack mechanism works. >> I >> > think it is used as flow control in one direction only.... (host to >> mote, >> > ie. when the mote receives). >> > >> > >> > >> >> >> >> ======= >> >> Some background why I'm asking these questions: >> >> >> >> I'm currently developing TinyOS support for the WISEBED wireless >> sensor >> >> network testbeds (see. http://wisebed.eu). The specific function is >> that >> >> the testbed backend shall be able to read individual packets from the >> >> nodes >> >> stream and forward the individual packets to the remote experimenter >> >> using >> >> the testbed. >> >> >> > >> > Okay. I don't see why you want to expose yourself to the low level >> serial >> > protocols on the mote or going between the host and mote. It is >> really >> > ugly and was a quick and dirty implementation to get simple >> communications >> > working. It isn't well documented nor very well specified. >> > >> > Rather it looks like you probably want to actually start at a higher >> level >> > and want to interface to a gateway function of some sort. Check out >> > TinyOS's SerialForwarder, support/sdk/c/sf. I've also reimplemented >> > using sockets in motenet. Motenet can be found in >> support/sdk/c/motenet >> > but you have to get it from the tinyprod sources located at >> > github.com/tp-freeforall/prod(motenet-rel) >> > [README]< >> https://github.com/tp-freeforall/prod/blob/motenet_rel/support/sdk/c/motenet/README >> > >> > . >> > >> > Motenet provides a sockets interface to AM packets on the motenet/host >> > gateway. >> > >> > >> >> >> >> As our testbed backend implementation (see >> >> https://github.com/itm/testbed-runtime) is based on Java and uses >> >> framing/deframing algorithms implemented using the Netty framework >> (see >> >> http://netty.io) I need to re-implement the (de-)framing algorithms >> used >> >> for the TinyOS serial communication. >> >> >> > >> > I don't understand your conclusion. Actually it seems to me that you >> > need >> > to be able to receive frames from the motenet and be able to inject >> > packets >> > into the motenet. What does that have to do with reimplementing >> > framing/deframing algorithms? >> > >> > Look at the serial forwarder and take a look at motenet (libmotenet, >> > support/sdk/c/motenet). Perhaps you'll see what I'm getting at. >> > >> > >> >> ======= >> >> >> >> Best regards, >> >> Daniel Bimschas >> >> >> >> -- >> >> Daniel Bimschas, M.Sc. >> >> >> >> >> >> UNIVERSITÄT ZU LÜBECK >> >> INSTITUT FÜR TELEMATIK >> >> >> >> Ratzeburger Allee 160 >> >> 23538 Lübeck >> >> >> >> Tel +49 451 500 5387 >> >> Fax +49 451 500 5382 >> >> [email protected] >> >> >> >> http://www.itm.uni-luebeck.de/users/bimschas >> >> >> >> >> >> _______________________________________________ >> >> Tinyos-help mailing list >> >> [email protected] >> >> >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> >> >> > >> > >> > >> > -- >> > Eric B. Decker >> > Senior (over 50 :-) Researcher >> > _______________________________________________ >> > Tinyos-help mailing list >> > [email protected] >> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> >> >> _______________________________________________ >> Tinyos-help mailing list >> [email protected] >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
