---- *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
