Net2WG/Notes/20080725

---

---

Agenda

---

* Testing and release updates
* Berkeley 6lowpan implementation

Participants

---

* Phil, Stanford
* Matus
* Om, USC
* Mike, JHU
* Razvan, JHU

Discussion Notes

---

Testing and release updates

Om: From the net2 side the only remaining thing is the simulation script from TestNetwork. The Python script is there and I tried to test it but I had difficulties. Razvan will help with that. You got my email?

Razvan: Yes, I'll check immediately after the meeting.

Phil: I have not tested that. I have to hop on a airplane to Ireland so I'll not have time to test right now. It looks that there is going to be an RC4 because there were some bugs found and fixed in the CC2420 stack.

Om: Are they serious?

Phil: There is one when you have a short packet you can have an our of bound memory error. Some corrupted packets can corrupt the memory state of the mote.

Razvan: These were found using Safe TinyOS?

Phil: Yup.

Om: I just start testing with it. Any idea when RC4 will be out?

Phil: Probably this weekend.

Om: Something else: we should probably delete TestTymo entry, right?

Phil: Ok. You can go on the wiki and remove it.

Om: One more thing before moving to 6lowpan. Does micaz simulation falls into the micaz platform?

Phil: ?? is the person to talk to.

Om: Ok, I'll send him an email if I encounter any problems.

Berkeley 6lowpan implementation

Om: Just to bring everyone up to date: we have a 6lowpan implementation in lib/net and now there is recently another in contrib from Berkeley. I asked Matus to call in and talk about the differences.

Matus: Stephen has not called in?

Om: He has not, unfortunately.

Matus: Ok. I think he can tell more about his implementation. It seems to be a bit fancier than mine. He also has additional feature for routing.

Om: Routing is not really central to 6lowpan, is it?

Phil: No. There is a working group for this to which I'm flying to.

Om: Beside routing is something else in the Berkeley implementation we should look for?

Matus: The code he committed is doing the compression according to the 6lowpan HC draft which I think is different from RFC 4944. He said he also have a version of the RFC 4944 which he could committed.

Om: Should we, in the distance future, use his implementation? Or should we update or upgrade your code?

Matus: I think he did something a little bit wiser than me. The code for parsing the 6lowpan header can be used by both the mote and the daemon on the PC. This is something I haven't done. In my case they are two pieces of code. Buffer handling is also different.

Phil: Om, have you asked Stephen to call in?

Om: I did. He said he is kind of busy right now. We can try to have the meeting next week.

Phil: This has to do with the fact if it's going to be a 6lowpan working group.

Om: Ok. This a much bigger wider conversation.

Phil: Yeah.

[...]

Om: How about the AMless radio? Did you guy discuss about this in core?

Matus: I talked with Stephen and we both agree that we need a way to send message without the AM ID. To my knowledge there is no such thing yet in TinyOS.

Om: Phil, are their any plans for this?

Phil: The person to talk about the radio is Moss.