Luca BRUNO | 16 Mar 16:16 2012

IRC log for 2012-03-14 meeting

Hi all,
attached here you will find the full raw IRClog of the #linux-wpan
meeting we had on 2012-03-14. 

A summary of the log has also been written and is available at

In case of any discrepancy, the attached raw log is to be considered
the primary source. 

Cheers, Luca

 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.    | lucab (AT)
`. `'`  			| GPG Key ID: 3BFB9FB3
  `- 	| Debian GNU/Linux Developer
**** LOG START Wed Mar  14 16:20:13 2012

mar 14 16:20:34 <lumag>	Hello all
mar 14 16:20:41 <lumag>	So agenda:
mar 14 16:20:57 <lumag>	Current status of code in the Linux kernel
mar 14 16:20:57 <lumag>	Current status of code in Linux-zigbee tree
mar 14 16:20:57 <lumag>	Next set of features
mar 14 16:20:57 <lumag>	Plan for compliance testing
mar 14 16:21:06 <lumag>	Let's begin step by step.
mar 14 16:21:33 <prajosh_>	ok
mar 14 16:22:49 <prajosh_>	lets start current status of the code
mar 14 16:23:36 <lumag>	I'll tell obvious things, maybe.
mar 14 16:24:04 <felix___>	go ahead
mar 14 16:24:46 <prajosh_>	its ok we will be in same page and we can fix our understandings too
mar 14 16:25:35 <lumag>	Currently in v3.2 we have some support code. It consists of socket interface
(support for datagram and raw sockets. Raw sockets are kind of deprecated.) and some parts of MLME.
mar 14 16:26:57 <lumag>	All management commands are implemented on top of NetLink messages family.
mar 14 16:27:24 <prajosh_>	ok
mar 14 16:27:59 <lumag>	Management commands consists of MAC control code (mostly resembling IEEE
802.15.4 MLME) and PHY control code.
mar 14 16:28:50 <lumag>	PHY control code (see net/ieee802154/nl-phy.c) consists of commands for
adding, removing and listing interfaces.
mar 14 16:29:23 <felix___>	raw is meant for hardmac devices?
mar 14 16:29:28 <lumag>	For now, mainline code supports only plain IEEE 802.15.4 interfaces. It even
doesn't have a notion of "interface type". More on that later.
mar 14 16:30:22 <lumag>	felix___, no. It was meant for capturing/sending raw frames (with header &
company, no FCS) over the RF link.
mar 14 16:30:57 <felix___>	ok
mar 14 16:31:08 <lumag>	However as we faced the HardMAC devices, we understood that we cannot promise that
such "raw" handling will work.
mar 14 16:31:41 <lumag>	In fact the major difference between dgram and raw is a call to dev_hard_header in
the handling of dgram messages.
mar 14 16:32:27 <lumag>	BSD socket interface supports sending messages directly to the other node. It can
use either long or short address. No association is required at this point.
mar 14 16:32:47 <lumag>	However it is expected that local devices is configured.
mar 14 16:34:00 <lumag>	Binding sockets to specific interfaces is supported (so I e.g. can say that
application will send data only through the second radio. Or from the interface that has address cafe:aaaa
mar 14 16:34:47 <lumag>	No real support is provided for "indirect messages". Also as we don't have a real
message queue, canceling messages is not supported.
mar 14 16:35:36 <lumag>	Another missing thing is support for message statuses. E.g. if sending of the
message fails somewhere downside, you won't be able to receive this status.
mar 14 16:35:51 <lumag>	* meaning error status
mar 14 16:36:36 <lumag>	However the code was submitted at that point in this state, as it actually permits
one to play with HardMAC device drivers.
mar 14 16:36:55 <lumag>	HardMAC (for the reference) is a device that implements all protocol handling on
its own.
mar 14 16:37:33 <lumag>	Examples include various ieee 802.15.4 modems, development kits, etc.
mar 14 16:38:04 <lumag>	We were promised by several parties, that they will work on device drivers for some
actual HardMAC devices, but since then we received no feedback.
mar 14 16:39:16 <lumag>	Mainline kernel contains a "fakehard" that can be used as a model to write such
device driver.
mar 14 16:39:40 <prajosh_>	i think we will have to work on hardmac based implementation if we have to get
beacon enabled network up
mar 14 16:40:00 <lumag>	prajosh, yes.
mar 14 16:40:15 <felix___>	a packet sent over a raw socket is just sent straight to the radio's transmit function
mar 14 16:40:45 <lumag>	yes. So if you have a softmac device, you are lucky and you can send all kinds of packets.
mar 14 16:40:53 <prajosh_>	lumag, so can i divert you to softmac
mar 14 16:41:02 <lumag>	HardMAC devices will wrap this packets into 802.15.4 frame anyway.
mar 14 16:41:08 <lumag>	prajosh, one moment please.
mar 14 16:42:10 <felix___>	ok
mar 14 16:42:25 <lumag>	John Smirl has ported 6lowpan code from Contiki OS. Unfortunately code had some
design problems, so it stagnated for a while.
mar 14 16:43:02 <lumag>	Later on Alexander updated this code, fixed most if not all design issues and I
blessed him on pushing this code to davem for inclusion into Linux kernel.
mar 14 16:44:02 <lumag>	v3.2 contains basic support for 6lowpan, v3.3 will contain more features like fragmentation.
mar 14 16:45:15 <lumag>	I think code still misses stateful compression, but that can be added later on demand.
mar 14 16:45:32 <lumag>	Code resides in net/ieee802154/6lowpan.[ch].
mar 14 16:45:50 <lumag>	Regarding other NextLevel entities.
mar 14 16:46:21 <lumag>	ZigBee and ZigBee RF4CE are not permitted to be included into the kernel, as the
license on the specification is permitted to be not compatible with GPL.
mar 14 16:46:57 <lumag>	WirelessHART requires hardware support for cryptoACK (ACK packet with security signature).
mar 14 16:47:13 <lumag>	I don't remember about other NLEs proposed.
mar 14 16:47:41 <lumag>	Any questions on this, or can move to the next point in agenda?
mar 14 16:47:50 <felix___>	ZigBee & RF4CE could come in as user-space stacks
mar 14 16:48:09 <lumag>	felix___, yes.
mar 14 16:48:18 <prajosh_>	but Zigbee IP can be a problem
mar 14 16:48:54 <lumag>	RF4CE brings some additional topics, as it requires channel hopping.
mar 14 16:49:33 <lumag>	IP can be a problem. Of course IANAL, but I think that as long as you don't create a
"product" and don't call it "ZigBee" you should be safe.
mar 14 16:49:59 <felix___>	actually the channel hopping in RF4CE is not a time-critical slot-based 'hopping'
mar 14 16:50:19 <prajosh_>	but we no one can use it for Smart Energy 2.0 edge router
mar 14 16:50:27 <felix___>	you can choose to send your data on one of three channels, that is all
mar 14 16:50:34 <lumag>	Several parties tried to receive license clarifications or confirmation if it
would be permitted to create open-source implementation, but no result were achieved.
mar 14 16:50:39 <felix___>	or all 3 too
mar 14 16:50:53 <lumag>	felix___, ah, I see. I don't remember RF4CE spec. I've read it too long ago.
mar 14 16:51:18 <lumag>	I think there was an effort to create BSD-licensed ZigBee implementation, but I
don't remember results.
mar 14 16:51:26 <felix___>	I'm not very thorough with it either, but this is one part I checked recently
mar 14 16:52:18 <prajosh_>	felix is right on RF4CE you can form a pan on channels 11,15 or <i forget the third
channel no>
mar 14 16:52:58 <malvira>
is BSD Zigbee
mar 14 16:53:00 <prajosh_>	if there is some channel acess failure then the pna hops to the next channel
mar 14 16:53:08 <malvira>	I ran it a while ago on things...
mar 14 16:53:24 <lumag>	So the most interesting NLE is 6lowpan with all possible bonuses like mesh
routing, RPL, 6lowapp, 6lowpan-ND, etc.
mar 14 16:53:25 <felix___>	oh the FreakUSB guys
mar 14 16:54:40 <lumag>	Good. But latest commit was nearly 2 years ago :(
mar 14 16:54:53 <malvira>	yes, he mostly stopped on it.
mar 14 16:55:13 <prajosh_>	that is the stack from Akiba ?
mar 14 16:55:16 <malvira>	yes
mar 14 16:55:57 <lumag>	Citing Akiba: ' I'm not sure if I'll continue supporting FreakZ though because of
the big Zigbee fiasco. I'm still considering.'
mar 14 16:56:13 <[florian]>	hi
mar 14 16:56:22 <lumag>	hello
mar 14 16:56:23 <[florian]>	sorry for being late at the meeting
mar 14 16:56:38 <prajosh_>	yaa he stopped 2 years ago or such.... I remmber
mar 14 16:56:57 <lumag>	np. we are trying to finish the first topic of agenda :)
mar 14 16:57:14 <prajosh_>	yes lets go to the next
mar 14 16:57:19 <prajosh_>	can we ...?
mar 14 16:57:41 <lumag>	prajosh, not yet. Sorry again.
mar 14 16:57:59 <lumag>	Next point is the current Linux-zigbee tree.
mar 14 16:58:07 <lumag>	And partial softmac implementation.
mar 14 16:58:38 <prajosh_>	we will have lots of questions here :)
mar 14 16:59:17 <lumag>	After submitting simple and reviewable generic part, we still had incomplete,
messy and sometimes working SoftMAC implementation in our pockets.
mar 14 16:59:38 <lumag>	It is fully present in the linux-zigbee tree on the
mar 14 17:00:13 <lumag>	It contains one small addition to the generic part - it adds a notion of device types
to the nl-phy handling.
mar 14 17:00:20 <lumag>	Repeating myself from the ML.
mar 14 17:00:48 <felix___>	just a small question.. was this intended to be an 'ieee compliant' mac implementation?
mar 14 17:01:03 <lumag>	felix___, in the distant future, yes.
mar 14 17:01:24 <lumag>	Idea is to follow mac80211 a little bit. There can be different protocols talking
on top of simple PHY interface.
mar 14 17:01:36 <lumag>	And different usefull things to handle.
mar 14 17:01:38 <prajosh_>	can you tell us which of the mlme functions are supported
mar 14 17:02:02 <lumag>	prajosh_, one minute later, ok?
mar 14 17:02:21 <prajosh_>	ok
mar 14 17:03:52 <lumag>	So for now the linux-zigbee code knows about monitor interfaces (one that are able
to pass frames exactly as the travel over the radio). PHY headers are not included. And if I remember it
correctly, FCS is also stripped.
mar 14 17:04:51 <lumag>	Then SMAC (simple MAC by Freescale - bare packet with 2 bytes fixed header). And the
most interesting part - 802.15.4 protocol handlers.
mar 14 17:05:59 <lumag>	Yes, the goal was to implement most (all) features of IEEE 802.15.4 standard. And
of course in a standard-compliant way.
mar 14 17:07:54 <lumag>	So now about supported features.
mar 14 17:08:57 <lumag>	Data frames are supported. Indirect data sending is not supported.
mar 14 17:09:10 <lumag>	DATA-REQUEST is also not supported.
mar 14 17:09:36 <lumag>	ASSOC and DISASSOC are supported and work.
mar 14 17:10:02 <kaeso>	lumag: for "indirect data sending" you mean data polling by the coordinator, correct?
mar 14 17:10:07 <lumag>	One simple note: as DATA-REQUEST is not supported, ASSOCIATION is implemented
with a non-standard quirk.
mar 14 17:10:31 <lumag>	kaeso, yes.
mar 14 17:10:36 <prajosh_>	lumag, can you please tell me how is ASSOC done
mar 14 17:10:52 <prajosh_>	i meant in the current code
mar 14 17:10:56 <felix___>	you just send the respose directly without waiting for poll?
mar 14 17:11:02 <lumag>	In the standard it is expected that device willing to associate polls for the
response using DATA-REQ.
mar 14 17:11:13 <lumag>	Our code just sends the answer back.
mar 14 17:11:42 <lumag>	beacon frames are somewhat supported.
mar 14 17:12:09 <lumag>	It is possible for a coordinator to create a standard-conformant frame and send it
in response to BEACON-REQUEST.
mar 14 17:12:24 <lumag>	Network nodes receive and process beacons.
mar 14 17:13:03 <lumag>	Beacons are added to the beacon_hash structure (net/mac802154/beacon_hash.[ch]).
mar 14 17:13:26 <lumag>	But beacons there do not expire. And I think there is no code that is able to query
that structure ATM.
mar 14 17:14:20 <lumag>	This code is tightly connected with scanning.
mar 14 17:16:08 <lumag>	Scanning is implemented mostly as a hack. It contains code that loops throught the
required channels, switches channels, taking pib_lock, and then waits for some time on the channel.
Active scan will send a beacon-req after switching to the channel. passive scans wont.
mar 14 17:17:47 <lumag>	This is one of the places where mlme would benefit from internal synchronization.
E.g. IIRC it is possible to run some other things in parallel with the scan.
mar 14 17:18:05 <lumag>	Instead frame processing should either wait for the scan to finish, or return -EBUSY.
mar 14 17:18:25 <lumag>	The same goes for the parallel scans.
mar 14 17:18:54 <lumag>	Another problem of scanning code is that ... they don't return results to the caller.
mar 14 17:19:13 <prajosh_>	lumag, are this functionality of code shared in any branch or repo
mar 14 17:19:17 <felix___>	can you send us a link to your repo or something?
mar 14 17:19:23 <lumag>;a=blob;f=net/mac802154/scan.c;h=4187a01cf9bbb881ddab1fb3f17afd2d425deb63;hb=refs/heads/devel-30
mar 14 17:19:35 <lumag>	This is the latest version of the code I touched.
mar 14 17:19:57 <lumag>	Alex has somewhat different piece of code, but I'll talk on this later.
mar 14 17:20:51 <prajosh_>	we were not aware of this piece of code
mar 14 17:21:01 <lumag>	scanning code has to be reworked. The problem is that there is no easy way to return
multiple values from single function. And just following MLME "procedures" here looked ugly for us.
mar 14 17:21:36 <lumag>	prajosh_, Strange. It should be mentioned on the project pages. I'm sorry, if this
caused efforts duplication from your side.
mar 14 17:21:56 <prajosh_>	yes we wrote this entire stuff again
mar 14 17:22:06 <felix___>	yes
mar 14 17:22:16 <prajosh_>	no problem we will work improve it out
mar 14 17:22:18 <lumag>	:(
mar 14 17:22:22 <felix___>	exactly  the same functionalities
mar 14 17:22:48 <felix___>	even implemented in a similar way (eg. assoc with no indirect queue!)
mar 14 17:22:51 <lumag>	Probably the code bases should be merged, as you clearly have advances on your own.
mar 14 17:23:08 <prajosh_>	we have completed the reset, pibs, association and working on scan
mar 14 17:23:32 <lumag>	The rest we have is implemented in this file:;a=blob;f=net/mac802154/mac_cmd.c;h=c763585df7ad14a7c6e76f12e28601b525d5188a;hb=refs/heads/devel-30
mar 14 17:24:25 <lumag>	IIRC your patches, pibs just have to reworked and then they can be applied to this tree.
mar 14 17:24:52 <lumag>	Now regarding the current status of the code and work by Alex.
mar 14 17:24:58 <kaeso>	lumag: looks like the tree contains five different branches... are they still all
in use?
mar 14 17:24:59 <felix___>	okay.. on the bright side, we hadn't completed scan :)
mar 14 17:25:29 <lumag>	felix___, on the other side, l-z also doesn't have complete scan also.
mar 14 17:27:29 <prajosh_>	yes we adding that
mar 14 17:28:23 <lumag>	Sergey and me wrote most of this code as a research project in Siemens. At some point
Sergey left Siemens. Somewhat later (around 2.6.36) I was switched to a different project.
mar 14 17:28:55 <lumag>	Alex is now employed by Siemens and as far as I know he is partially assigned to this project.
mar 14 17:29:14 <lumag>	He tries to cleanup main part of the code and push that to davem.
mar 14 17:29:39 <felix___>	hmm.. so is there a way we can work together on the l-z repo?
mar 14 17:29:58 <prajosh_>	rather in all the repo
mar 14 17:30:04 <lumag>	His activity can be seen on the netdev ML as well as on this ML.
mar 14 17:30:16 <lumag>	felix___, prajosh_ Yes, of course.
mar 14 17:31:15 <lumag>	Either me or Alex has to merge his last status into a git tree. I hope to work on this
during the weekend.
mar 14 17:31:59 <prajosh_>	oh once you guys have done that we can have a single code base
mar 14 17:32:02 <lumag>	Usual workflow (for most of the contributors) was to send patches to ML, then I will
apply them to the repo, if they look good.
mar 14 17:32:28 <prajosh_>	ok
mar 14 17:32:42 <felix___>	patches against your latest?
mar 14 17:32:46 <lumag>	Maybe at some point it will be simpler to give you commit access to the repo.
mar 14 17:32:48 <lumag>	felix___, yes.
mar 14 17:33:24 <lumag>	I just want to be sure that you understand the design ideas behind and that you won't
disturb the rest of the code.
mar 14 17:33:46 <prajosh_>	I see your point
mar 14 17:34:05 <felix___>	fair enough.. once you guys have updated your tree, we will try a merge at our end
mar 14 17:34:48 <felix___>	then send you patches (or RFCs) after resolving the chaos that would ensue
mar 14 17:34:54 <lumag>	:)
mar 14 17:35:04 <lumag>	Next point: development plans.
mar 14 17:35:13 <felix___>	ok
mar 14 17:35:38 <lumag>	I really hope that Alex will be able to push at least data frame handling, nl-phy
changes and monitor/smac to the davem.
mar 14 17:35:57 <felix___>	are we unanimous on the fact that we would aim for ieee compliance?
mar 14 17:36:24 <felix___>	i mean not in the PHY but at least in the MAC interface
mar 14 17:36:49 <lumag>	felix___, in my POV that really depends on what do you mean by ieee compliance.
mar 14 17:37:15 <lumag>	My goal was to be fully compatible from the networking point of view.
mar 14 17:37:23 <felix___>	i mean implement all the services that are expected from an IEEE 802.15.4-2006 MAC
mar 14 17:37:24 <lumag>	I think that is also your goal.
mar 14 17:37:43 <lumag>	So all commands, frames, etc. should be handled.
mar 14 17:38:05 <felix___>	i mean yes, with regard to frames over the air
mar 14 17:39:05 <felix___>	but also with services like get/set/scan/start/data etc.
mar 14 17:39:08 <lumag>	If we talk about MLME interface, I'm not that attached to this idea. the
MLME-COMM-STATUS is a nightmare to implement as is.
mar 14 17:39:29 <felix___>	:) i guess so
mar 14 17:40:05 <felix___>	but can't it be an nl message that only those who want will read?
mar 14 17:40:18 <lumag>	Also SCAN simply should not (and most probably can not) be implemented strictly
following the prototype as defined in the standard.
mar 14 17:40:23 <lumag>	It would be uneffective.
mar 14 17:40:53 <felix___>	can you elaborate?
mar 14 17:41:31 <lumag>	Probably you should be able to initiate scan (active or passive, with an optional
flag to clear the beacons db) and then after it finishes request a dump of beacons database.
mar 14 17:41:51 <lumag>	From my point of view it simply maps better onto the NetLink interface.
mar 14 17:42:02 <lumag>	It will have the same (or equivalent) results.
mar 14 17:42:18 <felix___>	yup that is fine
mar 14 17:42:25 <felix___>	as long as we don't omit anything that a NWK layer above would expect
mar 14 17:42:26 <lumag>	I'm not sure about ED scan.
mar 14 17:42:34 <lumag>	felix___, yes, of course.
mar 14 17:42:55 <[florian]>	lumag: just mimic what iw/nl80211 does
mar 14 17:42:56 <lumag>	do you know if prajosh is going to join back?
mar 14 17:43:09 <felix___>	oh has he dropped out?
mar 14 17:43:37 <felix___>	seems he didn't realize.. he'll join back now
mar 14 17:43:51 <lumag>	[florian], exactly. Note: I had not studied mac80211/iw code regarding scans, so
it might have better ideas than the one I expressed minutes ago.
mar 14 17:44:56 <[florian]>	it's basically behaving like you describe
mar 14 17:45:04 <felix___>	oh.. you mean to say you don't want a scan confirm with this list of beacons?
mar 14 17:45:07 <[florian]>	except that it unconditionnaly clears the beacons afair
mar 14 17:45:37 <lumag>	felix___, list of beacons can be larger than a message that is a scan-confirm.
mar 14 17:45:51 <felix___>	you want that to be returned as the result of another query?
mar 14 17:46:23 <lumag>	instead (please compare with list-phy interface) I'd prefer to have the db to be
queried in portions by NetLink.
mar 14 17:46:53 <[florian]>	you would filter the db results by pan id for instance?
mar 14 17:47:01 <felix___>	ok.. you just ask for a dump and you get this list of all phys
mar 14 17:47:44 <felix___>	so for scan, you do scan-req, get scan-conf with success and then ask for a dump
of all beacons?
mar 14 17:51:22 <lumag>	yes
mar 14 17:52:25 <lumag>	NetLink contains internal helpers to get such dumps
mar 14 17:53:02 <lumag>	felix___, prajosh_ do you know about MiWi?
mar 14 17:53:10 <prajosh_>	yes
mar 14 17:53:15 <prajosh_>	from microchip
mar 14 17:53:21 <lumag>	exactly
mar 14 17:53:38 <prajosh_>	is it still supported by microchip
mar 14 17:53:47 <lumag>	It mostly mimics 802.15.4, but is smaller in some points, as it omits some of the features.
mar 14 17:54:38 <[florian]>	prajosh_, felix___ do you guys have any plans for supporting rf4ce?
mar 14 17:55:02 <lumag>	In my opinion the first goal should be either to support data + data-req + assoc on
top of d-r + scan, or to run to the MiWi compatibility of some kind.
mar 14 17:55:10 <prajosh_>	RF4CE will be supported on user space
mar 14 17:55:14 <lumag>	Then should probably come security.
mar 14 17:55:28 <[florian]>	prajosh_: using either hard mac or soft-mac?
mar 14 17:55:45 <[florian]>	well, maybe we can discuss that later
mar 14 17:55:55 <lumag>	[florian], they are indistinguishable from the userspace. Or at least should be.
mar 14 17:55:56 <prajosh_>	softmac is the ideal candidate
mar 14 17:56:22 <prajosh_>	yes from user space they are not distinguishable
mar 14 17:56:59 <[florian]>	I am just asking because rf4ce requires channel hoping, not sure if that's
easily doable with hrtimers in the kernel for instance
mar 14 17:57:09 <[florian]>	of course you can disable it
mar 14 17:57:18 <prajosh_>	regarding security i have not seen any 802.15.4 networks using mac level
security rather its by upper layers
mar 14 17:57:30 <felix___>	like i mentioned, channel hopping in RF4CE is at a MAC level
mar 14 17:58:24 <felix___>	so there are no timing constraints.. it should work fine without any realtime
performance requirement
mar 14 17:58:39 <[florian]>	humm ok
mar 14 17:58:59 <prajosh_>	so security can be the last candidate - what is your say lumag
mar 14 18:01:12 <felix___>	ya.. it should be easier to build a full IEEE mac without security, without
beacon-enabled mode (such a MAC would support ZigBee/ZigBee pro/RF4CE/etc.)
mar 14 18:05:46 <prajosh_>	guys
mar 14 18:05:54 <prajosh_>	lets come out with a plan
mar 14 18:07:39 <lumag>	prajosh_, go on
mar 14 18:08:56 <felix___>	we have infrastructure here to perform automated testing for compliance
mar 14 18:10:29 <prajosh_>	let us have a single code base of all your code
mar 14 18:11:56 <prajosh_>	we already integrated a part of the system in compliance test jig
mar 14 18:12:42 <felix___>	this is where i guess we could help you guys the most.. as an when we implement new
features, we could also run the compliance suite to ensure that the stack works fine and most importantly,
interoperates well with other 15.4 devices
mar 14 18:12:52 <lumag>	:)
mar 14 18:14:55 <kaeso>	lumag: speaking of testing, would it be possible in theory to plug the
802.15.4+6lowpan stack on top of a tuntap to virtual route frames or inject them via pcap?
mar 14 18:15:41 <lumag>	Probably not directly.
mar 14 18:16:52 <lumag>	You can use fakelb driver from linux-zigbee tree. It allow one to create several
interconnected radios. Then you can have 802.15.4 on one of the radios and monitor on the other and use
monitor to inject frames via pcap.
mar 14 18:17:13 <kaeso>	(I'm not even sure if this is possible with mac80211, just an idea)
mar 14 18:18:19 <lumag>	fakelb was created to work with this kind of setups.
mar 14 18:20:04 <kaeso>	lumag: fine thanks
mar 14 18:20:12 <prajosh_>	i find that as the first step get a common code from lumax side
mar 14 18:21:30 <prajosh_>	after this we will run the test jig and fix all the compliance issues in the stack
mar 14 18:21:53 <prajosh_>	then we will add the indirect transmission
mar 14 18:24:37 <alan_o>	What is the status of 802.15.4 in libpcap/tcpdump/wireshark? Is this merged?
The website is ambiguous on this.
mar 14 18:25:23 <alan_o>	(I'm assuming it's ok to ask questions now, as we seem to have reached the end of the agenda)
mar 14 18:29:50 <lumag>	alan_o, libpcap has 802.15.4 merged. I don't remember about tcpdump, but
probably it was merged also.
mar 14 18:30:00 <prajosh_>	i think a company called Exigen has merged in wireshark
mar 14 18:30:02 <lumag>	You might be required to explicilty ask for frames printout.
mar 14 18:33:32 <alan_o>	As far as getting started on with this stuff, for hardware, kaeso recommended I
get the Econotag. That seems like the only USB one on the Supported Hardware page. Any other recommendations?
mar 14 18:34:55 <malvira>	I certainly like them :)
mar 14 18:35:25 <alan_o>	I'm looking at making a driver for the Microchip MRF24J40. I can talk to it via SPI,
and I've got the linux-zigbee changes built into my kernel. Now it's a matter of connecting the two, and of
course having something that's already supported (Econotag?) that I can test with.
mar 14 18:35:29 <lumag>	prajosh_, wireshark was working long ago. I remember we had to patch it so that it
uses wpan_nofcs instead of just wpan, but I remember, it was fixed later.
mar 14 18:36:36 <lumag>	alan_o, From my experience I can recommend either Atmel or TI radio (with Atmel
having better interface IMHO).
mar 14 18:37:00 <lumag>	I had not study the Microchip radios.
mar 14 18:37:31 <prajosh_>	ok can we freeze on the development statergy
mar 14 18:38:29 <lumag>	prajosh_, I agree with your plan.
mar 14 18:39:04 <[florian]>	alan_o: ti's cc2530 is also a pretty decent hw from my experience with it
mar 14 18:39:52 <kaeso>	yes, libpcap/tcpdump/wireshark should be all merged...there should be also
capture on wireshark wiki
mar 14 18:40:05 <kaeso>	*some captures
mar 14 18:41:42 <kaeso>	BTW I've put some raw notes from this chatlog on wiki:
mar 14 18:42:19 <prajosh_>	how about adding a table for timelines also
mar 14 18:43:11 <lumag>	kaeso, thank you. Small request: could you please merge them into one single page?
mar 14 18:44:20 <kaeso>	lumag: I'm also keeping full raw chatlog to be sent to the ML... would you still me to
merge the wikipages too?
mar 14 18:44:29 <lumag>	Yes.
mar 14 18:44:35 <kaeso>	fine
mar 14 18:45:02 <[florian]>	pwd
mar 14 18:45:09 <[florian]>	ermm, wrong terminal :)
mar 14 18:45:36 <kaeso>	lumag: as last thing, there are live five branches in current git tree; can you
please document which one contains what and remove ancient/unused ones?
mar 14 18:46:22 <lumag>	kaeso, I certainly don't want to remove old branches.
mar 14 18:46:43 <lumag>	master branch keeps track of latest Linus' tree at the moment of merge/push
mar 14 18:47:31 <lumag>	devel was a development branch. At some point I have branched a devel-30 to play
with 3.0 kernel, as I wasn't sure if those changes would disrupt the stability.
mar 14 18:47:41 <lumag>	Probably I'll merge devel-30 into devel and drop devel-30
mar 14 18:48:24 <prajosh_>	i think that is good
mar 14 18:49:04 <lumag>	6lowpan is an Alexanders branch. I don't know its status, so I won't touch it.
mar 14 18:49:15 <lumag>	devel-wpan-phy was a testbed for a sysfs wpan implementation.
mar 14 18:49:48 <felix___>	so as of now, devel-30 contains the latest code
mar 14 18:50:04 <lumag>	yes.
mar 14 18:52:01 <felix___>	so we will checkout that branch, and on your go (after Alex's merge), we'll
attempt a merge with ours..
mar 14 18:53:25 <lumag>	felix___, yes, please
mar 14 18:54:41 <lumag>	Another note, that might be interested to you: Please use current 0.3-git
versions of lowpan-tools. 0.2 do not support some of the features of current tree.
mar 14 18:55:29 <alan_o>	Forgive my git ignorance here, but what is the plan for getting devel-30 merged?
It seems like changes have been made by the linux-zigbee team, and then Linus's changes have been merged on
top o them, and then merge commits fixing the conflicts have been checked out on top of them. Since the
linux-zigbee changes are all mixed in, do you plan to be able to recover all that history for submission to
mainline, or do you plan to do a sim
mar 14 18:55:29 <alan_o>	ple diff against Linus's tree and create patches from that? Again, maybe this is
just my ignorance of git.
mar 14 19:00:30 <lumag>	alan_o, simple clean final commits. The history is only important if you care
about it - in the development tree.
mar 14 19:01:21 <lumag>	I'm sorry, colleagues, I got to go now.
mar 14 19:01:33 <[florian]>	thanks for your time
mar 14 19:01:35 <alan_o>	lumag: Thanks for the information
mar 14 19:02:05 <lumag>	I think we discussed and agreed on the most important things. If you have any other
questions, drop an e-mail to the ML, I'll try to answer as I have time.
mar 14 19:02:54 <lumag>	bye

**** LOG END Wed Mar 14 19:05:22 2012
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
Linux-zigbee-devel mailing list