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 https://sourceforge.net/apps/trac/linux-zigbee/wiki/Status20120314 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) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | 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> http://freaklabs.org/index.php/FreakZ-Open-Source-Zigbee-Stack.html 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 sf.net. 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> http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;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: http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;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: https://sourceforge.net/apps/trac/linux-zigbee/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
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
