[Linux-zigbee-devel] 802.15.4 based USB stick support
Hi I have been working on 802.15.4 stack and have them working on various USB sticks. But i find that there is no support for any of the USB sticks on Linux. I even searched in the mail for the same and couldn't find any. Can anybody please point me to any of the artifacts regarding the same -- Regards, Prajosh Premdas -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] 802.15.4 based USB stick support
Thanks a lot Alexander and Jon 2011/11/8 Alexander Smirnov > Hello, > > IIRC Werner (I added him to Cc) has reworked version of at91 driver for > USB support. > > To Werner: sorry if I'm wrong. > > With best regards, > Alex > > 08.11.2011, в 19:48, Prajosh Premdas > написал(а): > > > Hi > > > > I have been working on 802.15.4 stack and have them working on various > USB sticks. But i find that there is no support for any of the USB sticks > on Linux. I even searched in the mail for the same and couldn't find any. > > > > Can anybody please point me to any of the artifacts regarding the same > > > > -- > > Regards, > > > > Prajosh Premdas > > > -- > > RSA(R) Conference 2012 > > Save $700 by Nov 18 > > Register now > > http://p.sf.net/sfu/rsa-sfdev2dev1 > > ___ > > Linux-zigbee-devel mailing list > > Linux-zigbee-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel > -- Regards, Prajosh Premdas -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] 802.15.4 stack compliance
Hi I am planning to use this stack for some development in 802.15.4 based product. Can anybody please advice me whether the stack clears the compliance. If there is any report or any data can any body can share the same. If there is a deviation in compliance i am planning to fix the same for the 802.15.4 stack so if any data or test code is available it would really help me as a starting point. I have one more question, I find that only fake-hardware is part of the mainline kernel and not any of the standard available trans-receiver codes. Can you please advice how to add some standard trans-receiver available in market? -- Regards, Prajosh Premdas -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Evaluating ZigBee under Linux
the libnl version should be 1.1. In this particular libnl the iz tools compile On Wed, Dec 14, 2011 at 6:08 AM, Peter Naulls wrote: > > Hi guys, I'm looking at Zigbee options for Linux. In practical > terms, there seems to be this project and the stuff done by > EmberZNet. > > My most immediate problem however is that the linux-zigbee tools > don't compile for my eventual target (OpenWrt) since that has > a rather newer version of libnl than is in e.g, Ubuntu. So, > I need some patches there ;-) > > My target ZigBee hardware is the EM260 over a serial port and also some > other USB dongle, which I don't know the details of just yet, > which I guess will also be serial. > > I have the sources to the Ember stuff from the target hardware's > SDK, ported to OpenWrt without issue, and that seems to "just work", > but I really don't know enough about the parts and layers to > try stuff out. My most recent background is working with OpenZWave > which I've done a great deal improvement to. > > So, I could do with a primer of ZigBee (esp. vs Z-Wave) at this kind > of level, as well as a comparison of the two solutions. If linux-zigbee > seems right for us, then I'll hopefully be making contributions here > too. > > Regards. > > > > > -- > Cloud Computing - Latest Buzzword or a Glimpse of the Future? > This paper surveys cloud computing today: What are the benefits? > Why are businesses embracing it? What are its payoffs and pitfalls? > http://www.accelacomm.com/jaw/sdnl/114/51425149/ > ___ > Linux-zigbee-devel mailing list > Linux-zigbee-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel > -- Regards, Prajosh Premdas -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 2/9] ieee802154: added MAC PIB attribute ids
From: Felix Varghese Added #defines for MAC PIB attribute ids and default values for PIB attributes Signed-off-by: Felix Varghese Signed-off-by: Prajosh Premdas --- include/net/ieee802154.h | 148 ++ 1 files changed, 137 insertions(+), 11 deletions(-) diff --git a/include/net/ieee802154.h b/include/net/ieee802154.h index ee59f8b..5134f13 100644 --- a/include/net/ieee802154.h +++ b/include/net/ieee802154.h @@ -63,15 +63,137 @@ #define IEEE802154_MFR_SIZE2 /* 2 octets */ /* MAC's Command Frames Identifiers */ -#define IEEE802154_CMD_ASSOCIATION_REQ 0x01 -#define IEEE802154_CMD_ASSOCIATION_RESP0x02 -#define IEEE802154_CMD_DISASSOCIATION_NOTIFY 0x03 -#define IEEE802154_CMD_DATA_REQ0x04 -#define IEEE802154_CMD_PANID_CONFLICT_NOTIFY 0x05 -#define IEEE802154_CMD_ORPHAN_NOTIFY 0x06 -#define IEEE802154_CMD_BEACON_REQ 0x07 -#define IEEE802154_CMD_COORD_REALIGN_NOTIFY0x08 -#define IEEE802154_CMD_GTS_REQ 0x09 +#define IEEE802154_CMD_ASSOCIATION_REQ 0x01 +#define IEEE802154_CMD_ASSOCIATION_RESP0x02 +#define IEEE802154_CMD_DISASSOCIATION_NOTIFY 0x03 +#define IEEE802154_CMD_DATA_REQ0x04 +#define IEEE802154_CMD_PANID_CONFLICT_NOTIFY 0x05 +#define IEEE802154_CMD_ORPHAN_NOTIFY 0x06 +#define IEEE802154_CMD_BEACON_REQ 0x07 +#define IEEE802154_CMD_COORD_REALIGN_NOTIFY0x08 +#define IEEE802154_CMD_GTS_REQ 0x09 + +/* Section 7.4.1 of IEEE 802.15.4 Spec : MAC Layer Constants */ +#define aMaxPHYPacketSize (127) +#define aTurnaroundTime (12) +#define aBaseSlotDuration (60) +#define aBaseSuperframeDuration (aBaseSlotDuration * aNumSuperframeSlots) +#define aGTSDescPersistenceTime (4) +#define aMaxBeaconOverhead (75) +#define aMaxBeaconPayloadLength (aMaxPHYPacketSize - aMaxBeaconOverhead) +#define aMaxLostBeacons (4) +#define aMaxMACPayloadSize (aMaxPHYPacketSize - aMinMPDUOverhead) +#define aMaxMACSafePayloadSize (aMaxPHYPacketSize - aMaxMPDUUnsecuredOverhead) +#define aMaxMPDUUnsecuredOverhead (25) +#define aMaxSIFSFrameSize (18) +#define aMinCAPLength (440) +#define aMinMPDUOverhead (9) +#define aNumSuperframeSlots (16) +#define aUnitBackoffPeriod (20) + +/* Section 6.4.2 of IEEE 802.15.4 Spec : PHY PIB attributes */ +#define phyCurrentChannel (0x00) +#define phyChannelsSupported(0x01) +#define phyTransmitPower(0x02) +#define phyCCAMode (0x03) +#define phyCurrentPage (0x04) +#define phyMaxFrameDuration (0x05) +#define phySHRDuration (0x06) +#define phySymbolsPerOctet (0x07) +#define PHY_OVERHEAD(5) + +/* Section 7.4.2 of IEEE 802.15.4 Spec : MAC PIB Attributes */ +#define macAckWaitDuration (0x40) +#define macAckWaitDuration_def (54) + +#define macAssociationPermit(0x41) +#define macAssociationPermit_def(false) + +#define macAutoRequest (0x42) +#define macAutoRequest_def (true) + +#define macBattLifeExt (0x43) +#define macBattLifeExt_def (false) + +#define macBattLifeExtPeriods (0x44) +#define macBattLifeExtPeriods_def (6) + +#define macBeaconPayload(0x45) + +#define macBeaconPayloadLength (0x46) +#define macBeaconPayloadLength_def (0) + +#define macBeaconOrder (0x47) +#define macBeaconOrder_def (15) + +#define NON_BEACON_NWK (0x0F) + +#define macBeaconTxTime (0x48) +#define macBeaconTxTime_def (0x00) + +#define macBSN (0x49) +#define macCoordExtendedAddress (0x4A) + +#define macCoordShortAddress(0x4B) +#define macCoordShortAddress_def(0x) + +#define macDSN (0x4C) + +#define macGTSPermit(0x4D) +#define macGTSPermit_def(true) + +#define macMaxCSMABackoffs (0x4E) +#define macMaxCSMABackoffs_def (4) + +#define macMinBE(0x4F) +#define macMinBE_def(3) + +#define macPANId(0x50) +#define macPANId_def(0x) + +#define macPromiscuousMode (0x51) + +#define macRxOnWhenIdle (0x52) +#define macRxOnWhenIdle_def (false) + +#define macShortAddress (0x53) +#define macShortAddress_def (0x) + +#define macSuperframeOrder (0x54) +#define macSuperframeOrde
[Linux-zigbee-devel] [PATCH 6/9] mac802154: MLME PIB Implementation - Add new file mlme_pib.c
From: Felix Varghese
Adds new file mlme_pib.c and function for resetting all PIB attributes
to their default values
Signed-off-by: Felix Varghese
Signed-off-by: Prajosh Premdas
---
net/mac802154/mlme_pib.c | 152 ++
1 files changed, 152 insertions(+), 0 deletions(-)
create mode 100644 net/mac802154/mlme_pib.c
diff --git a/net/mac802154/mlme_pib.c b/net/mac802154/mlme_pib.c
new file mode 100644
index 000..e52a4c7
--- /dev/null
+++ b/net/mac802154/mlme_pib.c
@@ -0,0 +1,152 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Written by:
+ * Felix Varghese
+ * Prajosh Premdas
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include "mac802154.h"
+
+/* MLME_GET request worker structures */
+struct mlme_get_req_notify_work {
+ struct work_struct work;
+ struct net_device *dev;
+ u8 PIBattr;
+};
+
+/* MLME_SET request worker structures */
+struct mlme_set_req_notify_work {
+ struct work_struct work;
+ struct net_device *dev;
+ u8 PIBattr;
+ union pib_value_t PIBval;
+};
+
+/* MLME_GET request worker functions */
+static void internal_mlme_get_req_worker(struct work_struct *work);
+
+/* MLME_SET request worker functions */
+static void internal_mlme_set_req_worker(struct work_struct *work);
+
+void mac_pib_reset_def(struct net_device *dev)
+{
+ u8 pib_value_u8;
+ u16 pib_value_u16;
+ u32 pib_value_u32;
+ u64 pib_value_u64;
+
+ pib_value_u8 = macAckWaitDuration_def;
+ internal_set_mac_pib(dev, macAckWaitDuration, &pib_value_u8);
+
+ pib_value_u8 = macAssociationPermit_def;
+ internal_set_mac_pib(dev, macAssociationPermit, &pib_value_u8);
+
+ pib_value_u8 = macAutoRequest_def;
+ internal_set_mac_pib(dev, macAutoRequest, &pib_value_u8);
+
+ pib_value_u8 = macBattLifeExt_def;
+ internal_set_mac_pib(dev, macBattLifeExt, &pib_value_u8);
+
+ pib_value_u8 = macBattLifeExtPeriods_def;
+ internal_set_mac_pib(dev, macBattLifeExtPeriods, &pib_value_u8);
+
+ pib_value_u8 = macBeaconPayloadLength_def;
+ internal_set_mac_pib(dev, macBeaconPayloadLength, &pib_value_u8);
+
+ pib_value_u8 = macBeaconOrder_def;
+ internal_set_mac_pib(dev, macBeaconOrder, &pib_value_u8);
+
+ pib_value_u32 = macBeaconTxTime_def;
+ internal_set_mac_pib(dev, macBeaconTxTime, &pib_value_u32);
+
+ get_random_bytes(&pib_value_u8, sizeof(u8));
+ internal_set_mac_pib(dev, macBSN, &pib_value_u8);
+
+ pib_value_u64 = 0;
+ internal_set_mac_pib(dev, macCoordExtendedAddress, &pib_value_u64);
+
+ pib_value_u16 = macCoordShortAddress_def;
+ internal_set_mac_pib(dev, macCoordShortAddress, &pib_value_u16);
+
+ get_random_bytes(&pib_value_u8, sizeof(u8));
+ internal_set_mac_pib(dev, macDSN, &pib_value_u8);
+
+ pib_value_u8 = macGTSPermit_def;
+ internal_set_mac_pib(dev, macGTSPermit, &pib_value_u8);
+
+ pib_value_u8 = macMaxCSMABackoffs_def;
+ internal_set_mac_pib(dev, macMaxCSMABackoffs, &pib_value_u8);
+
+ pib_value_u8 = macMinBE_def;
+ internal_set_mac_pib(dev, macMinBE, &pib_value_u8);
+
+ pib_value_u16 = macPANId_def;
+ internal_set_mac_pib(dev, macPANId, &pib_value_u16);
+
+ pib_value_u8 = 0;
+ internal_set_mac_pib(dev, macPromiscuousMode, &pib_value_u8);
+
+ pib_value_u8 = macRxOnWhenIdle_def;
+ internal_set_mac_pib(dev, macRxOnWhenIdle, &pib_value_u8);
+
+ pib_value_u16 = macShortAddress_def;
+ internal_set_mac_pib(dev, macShortAddress, &pib_value_u16);
+
+ pib_value_u8 = macSuperframeOrder_def;
+ internal_set_mac_pib(dev, macSuperframeOrder, &pib_value_u8);
+
+ pib_value_u16 = macTransactionPersistenceTime_def;
+ internal_set_mac_pib(dev, macTransactionPersistenceTime,
&pib_value_u16);
+
+ pib_value_u8 = macAssociatedPANCoord_def;
+ internal_set_mac_pib(dev, macAssociatedPANCoord, &pib_value_u8);
+
+ pib_value_u8 = macMaxBE_def;
+ internal_set_mac_pib(dev, macMaxBE, &pib_value_u8);
+
+ pib_value_u16 = macMaxFrameTotalWaitTime_def;
+ internal_set_mac_pib(dev, macMaxFrameTotalWaitTime, &pib_va
[Linux-zigbee-devel] [PATCH 1/9] ieee802154: mlme reset for netlink interface
mlme reset functionality has been added for netlink socket interface
attributes mentioned are as per the IEEE 802.15.4 - 2006 specification
Tested on SAM9G20-EK board
Signed-off-by: Prajosh Premdas
---
include/linux/nl802154.h|2 +
include/net/ieee802154_netdev.h |2 +
include/net/nl802154.h |9 ++
net/ieee802154/nl-mac.c | 57 +-
net/ieee802154/nl_policy.c |2 +
5 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/include/linux/nl802154.h b/include/linux/nl802154.h
index fbd0fdf..69fe03a 100644
--- a/include/linux/nl802154.h
+++ b/include/linux/nl802154.h
@@ -70,6 +70,8 @@ enum {
IEEE802154_ATTR_PHY_NAME,
IEEE802154_ATTR_DEV_TYPE,
+ IEEE802154_ATTR_SET_DEFAULT_PIB,
+
__IEEE802154_ATTR_MAX,
};
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index b27730e..25cb045 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -92,6 +92,8 @@ struct wpan_phy;
* So 2 sets of mlme operations are needed
*/
struct ieee802154_mlme_ops {
+ int (*reset_req)(struct net_device *dev,
+u8 SetDefaultPIB);
int (*assoc_req)(struct net_device *dev,
struct ieee802154_addr *addr,
u8 channel, u8 page, u8 cap);
diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index 99d2ba1..23c2302 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -123,4 +123,13 @@ int ieee802154_nl_beacon_indic(struct net_device *dev, u16
panid,
*/
int ieee802154_nl_start_confirm(struct net_device *dev, u8 status);
+/**
+ * ieee802154_reset_confirm - Notify userland of completion of reset.
+ * @dev: The device which was instructed to scan.
+ * @status: The status of the scan operation.
+ *
+ * Note: This is in section 7.1.9.2 of the IEEE 802.15.4 document.
+ */
+int ieee802154_reset_confirm(struct net_device *dev, u8 status);
+
#endif
diff --git a/net/ieee802154/nl-mac.c b/net/ieee802154/nl-mac.c
index adaf462..2ace28b 100644
--- a/net/ieee802154/nl-mac.c
+++ b/net/ieee802154/nl-mac.c
@@ -1,8 +1,6 @@
/*
* Netlink inteface for IEEE 802.15.4 stack
*
- * Copyright 2007, 2008 Siemens AG
- *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2
* as published by the Free Software Foundation.
@@ -20,6 +18,8 @@
* Sergey Lapin
* Dmitry Eremin-Solenikov
* Maxim Osipov
+ * Felix Varghese
+ * Prajosh Premdas
*/
#include
@@ -519,6 +519,58 @@ static int ieee802154_scan_req(struct sk_buff *skb, struct
genl_info *info)
return ret;
}
+static int ieee802154_reset_req(struct sk_buff *skb, struct genl_info *info)
+{
+ struct net_device *dev;
+ u8 SetDefaultPIB;
+ int ret = -EINVAL;
+
+ if (!info->attrs[IEEE802154_ATTR_SET_DEFAULT_PIB])
+ return -EINVAL;
+
+ dev = ieee802154_nl_get_dev(info);
+ if (!dev)
+ return -ENODEV;
+
+ if (nla_get_u8(info->attrs[IEEE802154_ATTR_SET_DEFAULT_PIB]))
+ SetDefaultPIB = 1;
+ else
+ SetDefaultPIB = 0;
+
+ ret = ieee802154_mlme_ops(dev)->reset_req(dev, SetDefaultPIB);
+
+ if (ret == 0)
+ ieee802154_reset_confirm(dev, IEEE802154_SUCCESS);
+ else
+ ieee802154_reset_confirm(dev, IEEE802154_INVALID_PARAMETER);
+
+ dev_put(dev);
+ return ret;
+}
+
+int ieee802154_reset_confirm(struct net_device *dev, u8 status)
+{
+ struct sk_buff *msg;
+
+ msg = ieee802154_nl_create(0, IEEE802154_RESET_CONF);
+ if (!msg)
+ return -ENOBUFS;
+
+ NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
+ NLA_PUT_U32(msg, IEEE802154_ATTR_DEV_INDEX, dev->ifindex);
+ NLA_PUT(msg, IEEE802154_ATTR_HW_ADDR, IEEE802154_ADDR_LEN,
+ dev->dev_addr);
+
+ NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS, status);
+
+ return ieee802154_nl_mcast(msg, ieee802154_coord_mcgrp.id);
+
+nla_put_failure:
+ nlmsg_free(msg);
+ return -ENOBUFS;
+}
+EXPORT_SYMBOL(ieee802154_reset_confirm);
+
static int ieee802154_list_iface(struct sk_buff *skb,
struct genl_info *info)
{
@@ -581,6 +633,7 @@ cont:
}
static struct genl_ops ieee802154_coordinator_ops[] = {
+ IEEE802154_OP(IEEE802154_RESET_REQ, ieee802154_reset_req),
IEEE802154_OP(IEEE802154_ASSOCIATE_REQ, ieee802154_associate_req),
IEEE802154_OP(IEEE802154_ASSOCIATE_RESP, ieee802154_associate_resp),
IEEE802154_OP(IEEE802154_DISASSOCIATE_REQ, ieee802154_disassociate_req),
diff --git a/net/ieee802154/nl_policy.c b/net/ieee802154/nl_policy.c
index 6adda4d..9da1d72 100644
--- a/net/ieee802154/nl_policy.c
+++ b/net/ieee802154/nl_policy.c
@@ -52,5 +52,7 @@ const struct nla_policy ieee802154_policy[IEEE80
[Linux-zigbee-devel] [PATCH 3/9] ieee802154: Header file changes for PIB get/set via NL
From: Felix Varghese
Added function prototypes, structure definitions and netlink attributes for
supporting PIB get/set functionality
Signed-off-by: Felix Varghese
Signed-off-by: Prajosh Premdas
---
include/linux/nl802154.h|3 +++
include/net/ieee802154_netdev.h | 19 +++
include/net/nl802154.h | 23 +++
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl802154.h b/include/linux/nl802154.h
index 69fe03a..94ec8af 100644
--- a/include/linux/nl802154.h
+++ b/include/linux/nl802154.h
@@ -71,6 +71,9 @@ enum {
IEEE802154_ATTR_DEV_TYPE,
IEEE802154_ATTR_SET_DEFAULT_PIB,
+ IEEE802154_ATTR_PIB_ATTRIBUTE,
+ IEEE802154_ATTR_PIB_VALUE,
+ IEEE802154_ATTR_PIB_SIZE,
__IEEE802154_ATTR_MAX,
};
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index 25cb045..183b384 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -27,6 +27,21 @@
#define IEEE802154_NETDEVICE_H
#include
+#include
+
+/* PIB attribute value type */
+union pib_value_t {
+/* PIB attribute 8-bit */
+ u8 pib_value_8bit;
+ /* PIB attribute 16-bit */
+ u8 pib_value_16bit;
+ /* PIB attribute 32-bit */
+ u8 pib_value_32bit;
+ /* PIB attribute 64-bit */
+ u8 pib_value_64bit;
+ /* PIB attribute array */
+ u8 pib_array[aMaxBeaconPayloadLength];
+};
/*
* A control block of skb passed between the ARPHRD_IEEE802154 device
@@ -94,6 +109,10 @@ struct wpan_phy;
struct ieee802154_mlme_ops {
int (*reset_req)(struct net_device *dev,
u8 SetDefaultPIB);
+ int (*get_req)(struct net_device *dev,
+ u8 PIBattr);
+ int (*set_req)(struct net_device *dev,
+ u8 PIBattr, void *PIBval);
int (*assoc_req)(struct net_device *dev,
struct ieee802154_addr *addr,
u8 channel, u8 page, u8 cap);
diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index 23c2302..c3bec60 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -132,4 +132,27 @@ int ieee802154_nl_start_confirm(struct net_device *dev, u8
status);
*/
int ieee802154_reset_confirm(struct net_device *dev, u8 status);
+/**
+ * ieee802154_nl_get_confirm - Notify userland of completion of get confirm.
+ * @dev: The device which was instructed the get operation.
+ * @PIBattr:
+ * @PIBval:
+ * @size:
+ *
+ * Note: This is in section x of the IEEE 802.15.4 document.
+ */
+int ieee802154_nl_get_confirm(struct net_device *dev, u8 PIBattr,
+ void *PIBval, int size);
+
+/**
+ * ieee802154_nl_set_confirm - Notify userland of completion of set confirm.
+ * @dev: The device which was instructed the set operation.
+ * @PIBattr:
+ * @status:
+ *
+ * Note: This is in section x of the IEEE 802.15.4 document.
+ */
+int ieee802154_nl_set_confirm(struct net_device *dev, u8 PIBattr,
+ int status);
+
#endif
--
1.7.4.1
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 5/9] mac802154: Header file changes for MAC PIB set/get implementation
From: Felix Varghese
Adds structure definitions and function prototypes for implementing PIB
get and set primitives
Signed-off-by: Felix Varghese
Signed-off-by: Prajosh Premdas
---
include/net/mac802154.h | 10 +++
net/mac802154/mac802154.h | 58 ++---
2 files changed, 54 insertions(+), 14 deletions(-)
diff --git a/include/net/mac802154.h b/include/net/mac802154.h
index 5eaba60..e274414 100644
--- a/include/net/mac802154.h
+++ b/include/net/mac802154.h
@@ -142,6 +142,16 @@ struct ieee802154_ops {
unsigned long changed);
int (*ieee_addr)(struct ieee802154_dev *dev,
u8 addr[IEEE802154_ADDR_LEN]);
+
+ /* PLME-SAP */
+ int (*set_trx_state)(struct ieee802154_dev *dev,
+ int trx_state);
+ int (*get)(struct ieee802154_dev *dev,
+ u8 attribute_id,
+ u8 *attribute_val);
+ int (*set)(struct ieee802154_dev *dev,
+ u8 attribute_id,
+ u8 *attribute_val);
};
struct ieee802154_dev *
diff --git a/net/mac802154/mac802154.h b/net/mac802154/mac802154.h
index f0a0c08..0079a96 100644
--- a/net/mac802154/mac802154.h
+++ b/net/mac802154/mac802154.h
@@ -23,6 +23,8 @@
#ifndef MAC802154_H
#define MAC802154_H
+#include
+
struct mac802154_priv {
struct ieee802154_dev hw;
struct ieee802154_ops *ops;
@@ -54,6 +56,37 @@ struct mac802154_priv {
unsigned running:1;
};
+/* Section 7.4.2 MAC PIB attributes */
+struct mac_pib_t {
+ u8 AssociatedPANCoord;
+ u8 AssociationPermit;
+ u8 AutoRequest;
+ u8 BattLifeExt;
+ u8 BattLifeExtPeriods;
+ u8 BeaconPayload[aMaxBeaconPayloadLength];
+ u8 BeaconPayloadLength;
+ u8 BeaconOrder;
+ u32 BeaconTxTime;
+ u8 BSN;
+ u64 CoordExtendedAddress;
+ u16 CoordShortAddress;
+ u8 DSN;
+ u8 GTSPermit;
+ u8 MaxBE;
+ u8 MaxCSMABackoffs;
+ u16 MaxFrameTotalWaitTime;
+ u8 MaxFrameRetries;
+ u8 MinBE;
+ u16 PANId;
+ u8 PromiscuousMode;
+ u16 ResponseWaitTime;
+ u8 RxOnWhenIdle;
+ u8 SecurityEnabled;
+ u16 ShortAddress;
+ u8 SuperFrameOrder;
+ u16 TransactionPersistenceTime;
+};
+
enum {
MAC802154_DEVICE_STOPPED,
MAC802154_DEVICE_RUN,
@@ -70,18 +103,8 @@ struct mac802154_sub_if_data {
int type;
- spinlock_t mib_lock;
-
- __le16 pan_id;
- __le16 short_addr;
-
- u8 chan;
- u8 page;
-
- /* MAC BSN field */
- u8 bsn;
- /* MAC DSN field */
- u8 dsn;
+ struct mutex macPIB_lock;
+ struct mac_pib_t macPIB;
};
#define mac802154_to_priv(_hw) container_of(_hw, struct mac802154_priv, hw)
@@ -101,7 +124,14 @@ void mac802154_monitor_setup(struct net_device *dev);
netdev_tx_t mac802154_tx(struct mac802154_priv *priv, struct sk_buff *skb,
u8 page, u8 chan);
-/* MIB callbacks */
-void mac802154_dev_set_ieee_addr(struct net_device *dev);
+/* MLME_GET request and confirm function definitions */
+extern int mlme_get_req(struct net_device *dev, u8 PIBattr);
+extern int internal_get_mac_pib(struct net_device *dev,
+ u8 PIBattr, void *PIBval);
+
+/* MLME_SET request and confirm function definitions */
+extern int mlme_set_req(struct net_device *dev, u8 PIBattr, void *PIBval);
+extern int internal_set_mac_pib(struct net_device *dev,
+ u8 PIBattr, void *PIBval);
#endif /* MAC802154_H */
--
1.7.4.1
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 4/9] ieee802154: Adds PIB set/get request/confirm to NL interface
From: Felix Varghese
This patch adds functions for invoking PIB set and get to the Netlink interface.
Signed-off-by: Felix Varghese
Signed-off-by: Prajosh Premdas
---
net/ieee802154/nl-mac.c| 141
net/ieee802154/nl_policy.c |4 +
2 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/nl-mac.c b/net/ieee802154/nl-mac.c
index 2ace28b..c32c460 100644
--- a/net/ieee802154/nl-mac.c
+++ b/net/ieee802154/nl-mac.c
@@ -571,6 +571,145 @@ nla_put_failure:
}
EXPORT_SYMBOL(ieee802154_reset_confirm);
+int ieee802154_nl_get_confirm(struct net_device *dev, u8 PIBattr,
+ void *PIBval, int size)
+{
+ struct sk_buff *msg;
+
+ msg = ieee802154_nl_create(0, IEEE802154_GET_CONF);
+ if (!msg)
+ return -ENOBUFS;
+
+ NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
+ NLA_PUT_U8(msg, IEEE802154_ATTR_PIB_ATTRIBUTE, PIBattr);
+
+ if (size >= 0) {
+ NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS, IEEE802154_SUCCESS);
+ NLA_PUT(msg, IEEE802154_ATTR_PIB_VALUE, size, PIBval);
+ NLA_PUT_U8(msg, IEEE802154_ATTR_PIB_SIZE, size);
+ } else{
+ NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS,
+ IEEE802154_UNSUPPORTED_ATTR);
+ }
+
+ return ieee802154_nl_mcast(msg, ieee802154_coord_mcgrp.id);
+
+nla_put_failure:
+ nlmsg_free(msg);
+ return -ENOBUFS;
+}
+EXPORT_SYMBOL(ieee802154_nl_get_confirm);
+
+static int ieee802154_get_req(struct sk_buff *skb, struct genl_info *info)
+{
+ struct net_device *dev;
+ u8 PIB_Attribute;
+ int ret = 0;
+
+ if (!info->attrs[IEEE802154_ATTR_PIB_ATTRIBUTE])
+ return -EINVAL;
+
+ dev = ieee802154_nl_get_dev(info);
+ if (!dev) {
+ ret = -ENODEV;
+ goto error;
+ }
+
+ PIB_Attribute = nla_get_u8(info->attrs[IEEE802154_ATTR_PIB_ATTRIBUTE]);
+
+ if (!ieee802154_mlme_ops(dev)->get_req) {
+ ret = -EOPNOTSUPP;
+ goto error;
+ }
+
+ ret = ieee802154_mlme_ops(dev)->get_req(dev, PIB_Attribute);
+
+error:
+ dev_put(dev);
+ return ret;
+}
+
+int ieee802154_nl_set_confirm(struct net_device *dev, u8 PIBattr, int status)
+{
+ struct sk_buff *msg;
+
+ msg = ieee802154_nl_create(0, IEEE802154_SET_CONF);
+ if (!msg)
+ return -ENOBUFS;
+
+ NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
+ NLA_PUT_U8(msg, IEEE802154_ATTR_PIB_ATTRIBUTE, PIBattr);
+
+ switch (status) {
+ case 0:
+ NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS, IEEE802154_SUCCESS);
+ break;
+
+ case -EPERM:
+ NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS, IEEE802154_READ_ONLY);
+ break;
+
+ case -EINVAL:
+ NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS,
+ IEEE802154_INVALID_PARAMETER);
+ break;
+
+ case -EOPNOTSUPP:
+ NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS,
+ IEEE802154_UNSUPPORTED_ATTR);
+ break;
+ }
+
+ return ieee802154_nl_mcast(msg, ieee802154_coord_mcgrp.id);
+
+nla_put_failure:
+ nlmsg_free(msg);
+ return -ENOBUFS;
+}
+EXPORT_SYMBOL(ieee802154_nl_set_confirm);
+
+static int ieee802154_set_req(struct sk_buff *skb, struct genl_info *info)
+{
+ struct net_device *dev;
+ u8 PIB_Attribute;
+ char *PIBvalue;
+ int ret = 0;
+ u8 len;
+
+ if (!info->attrs[IEEE802154_ATTR_PIB_ATTRIBUTE])
+ return -EINVAL;
+
+ dev = ieee802154_nl_get_dev(info);
+ if (!dev) {
+ ret = -ENODEV;
+ goto error;
+ }
+
+ PIB_Attribute = nla_get_u8(info->attrs[IEEE802154_ATTR_PIB_ATTRIBUTE]);
+ len = nla_len(info->attrs[IEEE802154_ATTR_PIB_VALUE]);
+
+ PIBvalue = kmalloc(sizeof(union pib_value_t), GFP_ATOMIC);
+ if (!PIBvalue) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ nla_memcpy(PIBvalue, info->attrs[IEEE802154_ATTR_PIB_VALUE], len);
+
+ if (!ieee802154_mlme_ops(dev)->set_req) {
+ ret = -EOPNOTSUPP;
+ goto error_free_mem;
+ }
+
+ ret = ieee802154_mlme_ops(dev)->set_req(dev, PIB_Attribute, PIBvalue);
+
+error_free_mem:
+ kfree(PIBvalue);
+error:
+ dev_put(dev);
+ return ret;
+}
+
static int ieee802154_list_iface(struct sk_buff *skb,
struct genl_info *info)
{
@@ -634,6 +773,8 @@ cont:
static struct genl_ops ieee802154_coordinator_ops[] = {
IEEE802154_OP(IEEE802154_RESET_REQ, ieee802154_reset_req),
+ IEEE802154_OP(IEEE802154_GET_REQ, ieee802154_get_req),
+ IEEE802154_OP(IEEE802154_SET_REQ, iee
[Linux-zigbee-devel] [PATCH 9/9] mac802154: MLME PIB Implementation - remove mib
From: Felix Varghese
Replaces the existing mib implementation where only some of the
attributes are supported with the new MLME-PIB implementation.
Signed-off-by: Felix Varghese
Signed-off-by: Prajosh Premdas
---
net/mac802154/Makefile |3 ++-
net/mac802154/ieee802154_dev.c | 10 ++
net/mac802154/mac_cmd.c|8
net/mac802154/monitor.c|7 +++
4 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/net/mac802154/Makefile b/net/mac802154/Makefile
index ec1bd3f..a3cd602 100644
--- a/net/mac802154/Makefile
+++ b/net/mac802154/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_MAC802154)+= mac802154.o
-mac802154-objs := ieee802154_dev.o rx.o tx.o mac_cmd.o mib.o monitor.o
+mac802154-objs := ieee802154_dev.o rx.o tx.o mac_cmd.o
+mac802154-objs += monitor.o mib.o mlme_pib.o
diff --git a/net/mac802154/ieee802154_dev.c b/net/mac802154/ieee802154_dev.c
index cc85410..83fecb3 100644
--- a/net/mac802154/ieee802154_dev.c
+++ b/net/mac802154/ieee802154_dev.c
@@ -24,6 +24,8 @@
#include
#include
+#include
+
#include "mac802154.h"
int mac802154_slave_open(struct net_device *dev)
@@ -39,14 +41,6 @@ int mac802154_slave_open(struct net_device *dev)
goto err;
}
- if (ipriv->ops->ieee_addr) {
- res = ipriv->ops->ieee_addr(&ipriv->hw, dev->dev_addr);
- WARN_ON(res);
- if (res)
- goto err;
- mac802154_dev_set_ieee_addr(dev);
- }
-
netif_start_queue(dev);
return 0;
err:
diff --git a/net/mac802154/mac_cmd.c b/net/mac802154/mac_cmd.c
index 941c3e4..7406f5b 100644
--- a/net/mac802154/mac_cmd.c
+++ b/net/mac802154/mac_cmd.c
@@ -19,6 +19,8 @@
* Written by:
* Sergey Lapin
* Dmitry Eremin-Solenikov
+ * Felix Varghese
+ * Prajosh Premdas
*/
#include
@@ -41,3 +43,9 @@ struct wpan_phy *mac802154_get_phy(const struct net_device
*dev)
struct ieee802154_reduced_mlme_ops mac802154_mlme_reduced = {
.get_phy = mac802154_get_phy,
};
+
+struct ieee802154_mlme_ops mac802154_mlme_device = {
+ .get_req= mlme_get_req,
+ .set_req= mlme_set_req,
+ .get_phy= mac802154_get_phy
+};
diff --git a/net/mac802154/monitor.c b/net/mac802154/monitor.c
index d76e8d0..78fafc5 100644
--- a/net/mac802154/monitor.c
+++ b/net/mac802154/monitor.c
@@ -87,7 +87,7 @@ void mac802154_monitors_rx(struct mac802154_priv *priv,
struct sk_buff *skb)
static const struct net_device_ops mac802154_monitor_ops = {
.ndo_open = mac802154_slave_open,
.ndo_stop = mac802154_slave_close,
- .ndo_start_xmit = mac802154_monitor_xmit,
+ .ndo_start_xmit = mac802154_monitor_xmit,
};
void mac802154_monitor_setup(struct net_device *dev)
@@ -97,7 +97,7 @@ void mac802154_monitor_setup(struct net_device *dev)
dev->addr_len = 0;
dev->hard_header_len= 0;
dev->needed_tailroom= 2; /* FCS */
- dev->mtu= IEEE802154_MTU;
+ dev->mtu= aMaxPHYPacketSize;
dev->tx_queue_len = 10;
dev->type = ARPHRD_IEEE802154_MONITOR;
dev->flags = IFF_NOARP | IFF_BROADCAST;
@@ -110,6 +110,5 @@ void mac802154_monitor_setup(struct net_device *dev)
priv = netdev_priv(dev);
priv->type = IEEE802154_DEV_MONITOR;
- priv->chan = MAC802154_CHAN_NONE; /* not initialized */
- priv->page = 0; /* for compat */
+ mutex_init(&priv->macPIB_lock);
}
--
1.7.4.1
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 7/9] mac802154: MLME PIB Implementation - add MLME-GET
From: Felix Varghese
Adds the implementation for MLME-GET primitive in mac802154.
This is according to IEEE 802.15.4-2006 specification.
Signed-off-by: Felix Varghese
Signed-off-by: Prajosh Premdas
---
net/mac802154/mlme_pib.c | 211 +-
1 files changed, 209 insertions(+), 2 deletions(-)
diff --git a/net/mac802154/mlme_pib.c b/net/mac802154/mlme_pib.c
index e52a4c7..74573b4 100644
--- a/net/mac802154/mlme_pib.c
+++ b/net/mac802154/mlme_pib.c
@@ -42,8 +42,6 @@ struct mlme_set_req_notify_work {
/* MLME_GET request worker functions */
static void internal_mlme_get_req_worker(struct work_struct *work);
-/* MLME_SET request worker functions */
-static void internal_mlme_set_req_worker(struct work_struct *work);
void mac_pib_reset_def(struct net_device *dev)
{
@@ -137,9 +135,218 @@ void mac_pib_reset_def(struct net_device *dev)
int mlme_get_req(struct net_device *dev, u8 PIBattr)
{
+ struct mac802154_sub_if_data *priv = netdev_priv(dev);
+ struct mlme_get_req_notify_work *work;
+
+ work = kzalloc(sizeof(*work), GFP_ATOMIC);
+ if (!work) {
+ /* Out of memory */
+ return -ENOMEM;
+ }
+
+ INIT_WORK(&work->work, internal_mlme_get_req_worker);
+ work->dev = dev;
+ work->PIBattr = PIBattr;
+ queue_work(priv->hw->dev_workqueue, &work->work);
+
return 0;
}
+static void internal_mlme_get_req_worker(struct work_struct *work)
+{
+ struct mlme_get_req_notify_work *nw = container_of(work,
+ struct mlme_get_req_notify_work, work);
+
+ union pib_value_t *PIBvalue;
+ int ret;
+
+ PIBvalue = kmalloc(sizeof(union pib_value_t), GFP_ATOMIC);
+ if (!PIBvalue) {
+ /* Out of memory */
+ goto error_no_buff;
+ }
+
+ /*
+* Call the mlme_get_req with parameters
+* 1. struct dev : nw->dev
+* 2. attribute to be read: nw->PIBattr
+* 3. memory location where the value should be stored so that
+* can be communicated in te confirm: conf_work->PIBval
+*/
+
+ ret = internal_get_mac_pib(nw->dev, nw->PIBattr, (char *)(PIBvalue));
+
+ ieee802154_nl_get_confirm(nw->dev, nw->PIBattr, PIBvalue, ret);
+
+ kfree(PIBvalue);
+error_no_buff:
+
+ kfree(nw);
+}
+
+int internal_get_mac_pib(struct net_device *dev, u8 PIBattr, void *PIBval)
+{
+ struct mac802154_sub_if_data *priv = netdev_priv(dev);
+ struct mac802154_priv *trx = priv->hw;
+ int ret;
+
+ /*
+* Try the radio first so that it can override, in case it supports
+* some of MAC attributes also (eg., for address filtering).
+*/
+ ret = trx->ops->get(&trx->hw, PIBattr, PIBval);
+
+ /*
+* If radio doesnt support the attribute, try the MAC pib. In case
+* of any other error, or success, return the status back.
+*/
+ if (ret != -EOPNOTSUPP)
+ return ret;
+
+ mutex_lock(&priv->macPIB_lock);
+
+ switch (PIBattr) {
+ case macAssociatedPANCoord:
+ *((u8 *)PIBval) = priv->macPIB.AssociatedPANCoord;
+ ret = sizeof(priv->macPIB.AssociatedPANCoord);
+ break;
+
+ case macAssociationPermit:
+ *((u8 *)PIBval) = priv->macPIB.AssociationPermit;
+ ret = sizeof(priv->macPIB.AssociationPermit);
+ break;
+
+ case macAutoRequest:
+ *((u8 *)PIBval) = priv->macPIB.AutoRequest;
+ ret = sizeof(priv->macPIB.AutoRequest);
+ break;
+
+ case macBattLifeExt:
+ *((u8 *)PIBval) = priv->macPIB.BattLifeExt;
+ ret = sizeof(priv->macPIB.BattLifeExt);
+ break;
+
+ case macBattLifeExtPeriods:
+ *((u8 *)PIBval) = priv->macPIB.BattLifeExtPeriods;
+ ret = sizeof(priv->macPIB.BattLifeExtPeriods);
+ break;
+
+ case macBeaconPayload:
+ memcpy(PIBval,
+ priv->macPIB.BeaconPayload,
+ priv->macPIB.BeaconPayloadLength);
+ ret = priv->macPIB.BeaconPayloadLength;
+ break;
+
+ case macBeaconPayloadLength:
+ *((u8 *)PIBval) = priv->macPIB.BeaconPayloadLength;
+ ret = sizeof(priv->macPIB.BeaconPayloadLength);
+ break;
+
+ case macBeaconOrder:
+ *((u8 *)PIBval) = priv->macPIB.BeaconOrder;
+ ret = sizeof(priv->macPIB.BeaconOrder);
+ break;
+
+ case macBeaconTxTime:
+ *((u32 *)PIBval) = priv->macPIB.BeaconTxTime;
+ ret = sizeof(priv->macPIB.BeaconTxTime);
+ break;
+
+ case macBSN:
+ *((u8 *)PIBval) =
[Linux-zigbee-devel] [PATCH 8/9] mac802154: MLME PIB Implementation - add MLME-SET
From: Felix Varghese
Adds the implementation for MLME-SET primitive in mac802154.
This is according to IEEE 802.15.4-2006 specification.
Signed-off-by: Felix Varghese
Signed-off-by: Prajosh Premdas
---
net/mac802154/mlme_pib.c | 186 ++
1 files changed, 186 insertions(+), 0 deletions(-)
diff --git a/net/mac802154/mlme_pib.c b/net/mac802154/mlme_pib.c
index 74573b4..a1ed573 100644
--- a/net/mac802154/mlme_pib.c
+++ b/net/mac802154/mlme_pib.c
@@ -42,6 +42,8 @@ struct mlme_set_req_notify_work {
/* MLME_GET request worker functions */
static void internal_mlme_get_req_worker(struct work_struct *work);
+/* MLME_SET request worker functions */
+static void internal_mlme_set_req_worker(struct work_struct *work);
void mac_pib_reset_def(struct net_device *dev)
{
@@ -353,7 +355,191 @@ int internal_get_mac_pib(struct net_device *dev, u8
PIBattr, void *PIBval)
int mlme_set_req(struct net_device *dev, u8 PIBattr, void *PIBval)
{
+ struct mac802154_sub_if_data *priv = netdev_priv(dev);
+ struct mlme_set_req_notify_work *work;
int ret = 0;
+
+ work = kmalloc(sizeof(*work), GFP_ATOMIC);
+ if (!work) {
+ /* Out of memory */
+ ret = -ENOMEM;
+ goto error_no_mem;
+ }
+
+ INIT_WORK(&work->work, internal_mlme_set_req_worker);
+ work->dev = dev;
+ work->PIBattr = PIBattr;
+ memcpy(&(work->PIBval), PIBval, sizeof(union pib_value_t));
+
+ queue_work(priv->hw->dev_workqueue, &work->work);
+
+error_no_mem:
return ret;
}
+static void internal_mlme_set_req_worker(struct work_struct *work)
+{
+ struct mlme_set_req_notify_work *nw = container_of(work,
+ struct mlme_set_req_notify_work, work);
+
+ int ret;
+
+ /*
+* Call the mlme_get_req with parameters
+* 1. struct dev : nw->dev
+* 2. attribute to be read: nw->PIBattr
+* 3. memory location where the value is: nw->PIBval
+*/
+ ret = internal_set_mac_pib(nw->dev, nw->PIBattr,
+ (void *)(&(nw->PIBval)));
+
+ ieee802154_nl_set_confirm(nw->dev, nw->PIBattr, ret);
+
+ /* Work is done */
+ kfree(nw);
+}
+
+int internal_set_mac_pib(struct net_device *dev, u8 PIBattr, void *PIBval)
+{
+ struct mac802154_sub_if_data *priv = netdev_priv(dev);
+ struct mac802154_priv *trx = priv->hw;
+ int ret_from_radio;
+ int ret = 0;
+
+ /*
+* Try the radio's set primitive first in case it supports some of
+* the MAC attributes (eg., for address filtering).
+*/
+ ret_from_radio = trx->ops->set(&trx->hw, PIBattr, PIBval);
+
+ /*
+* If the return value indicates that the attribute is not supported
+* in the radio, see if MAC supports it.
+* If it is supported by both MAC & the radio, update MAC's copy so
+* that it can be used in case the radio does not implement a GET
+* for this attribute.
+* In case of any other return value, propagate the error back all
+* the way to user space.
+*/
+ if ((ret_from_radio < 0) && (ret_from_radio != -EOPNOTSUPP))
+ return ret_from_radio;
+
+ mutex_lock(&priv->macPIB_lock);
+
+ switch (PIBattr) {
+ case macAssociatedPANCoord:
+ priv->macPIB.AssociatedPANCoord = *((u8 *)PIBval);
+ break;
+
+ case macAssociationPermit:
+ priv->macPIB.AssociationPermit = *((u8 *)PIBval);
+ break;
+
+ case macAutoRequest:
+ priv->macPIB.AutoRequest = *((u8 *)PIBval);
+ break;
+
+ case macBattLifeExt:
+ priv->macPIB.BattLifeExt = *((u8 *)PIBval);
+ break;
+
+ case macBattLifeExtPeriods:
+ priv->macPIB.BattLifeExtPeriods = *((u8 *)PIBval);
+ break;
+
+ case macBeaconPayload:
+ memcpy(priv->macPIB.BeaconPayload, PIBval,
+ priv->macPIB.BeaconPayloadLength);
+ break;
+
+ case macBeaconPayloadLength:
+ priv->macPIB.BeaconPayloadLength = *((u8 *)PIBval);
+ break;
+
+ case macBeaconOrder:
+ priv->macPIB.BeaconOrder = *((u8 *)PIBval);
+ break;
+
+ case macBSN:
+ priv->macPIB.BSN = *((u8 *)PIBval);
+ break;
+
+ case macCoordExtendedAddress:
+ priv->macPIB.CoordExtendedAddress = *((u64 *)PIBval);
+ break;
+
+ case macCoordShortAddress:
+ priv->macPIB.CoordShortAddress = *((u16 *)PIBval);
+ break;
+
+ case macDSN:
+ priv->macPIB.DSN = *((u8 *)PIBval);
+
Re: [Linux-zigbee-devel] [PATCH 1/9] ieee802154: mlme reset for netlink interface
Hi
I wanted help in reviewing these patches. Could anybody please review these
patches . If i have made any mistake in the patch format please point it
out to me.
Sorry for any obvious mistakes.
Regards
Prajosh Premdas
On Fri, Feb 24, 2012 at 2:32 PM, Prajosh Premdas
wrote:
> mlme reset functionality has been added for netlink socket interface
> attributes mentioned are as per the IEEE 802.15.4 - 2006 specification
>
> Tested on SAM9G20-EK board
>
> Signed-off-by: Prajosh Premdas
> ---
> include/linux/nl802154.h|2 +
> include/net/ieee802154_netdev.h |2 +
> include/net/nl802154.h |9 ++
> net/ieee802154/nl-mac.c | 57
> +-
> net/ieee802154/nl_policy.c |2 +
> 5 files changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/nl802154.h b/include/linux/nl802154.h
> index fbd0fdf..69fe03a 100644
> --- a/include/linux/nl802154.h
> +++ b/include/linux/nl802154.h
> @@ -70,6 +70,8 @@ enum {
>IEEE802154_ATTR_PHY_NAME,
>IEEE802154_ATTR_DEV_TYPE,
>
> + IEEE802154_ATTR_SET_DEFAULT_PIB,
> +
>__IEEE802154_ATTR_MAX,
> };
>
> diff --git a/include/net/ieee802154_netdev.h
> b/include/net/ieee802154_netdev.h
> index b27730e..25cb045 100644
> --- a/include/net/ieee802154_netdev.h
> +++ b/include/net/ieee802154_netdev.h
> @@ -92,6 +92,8 @@ struct wpan_phy;
> * So 2 sets of mlme operations are needed
> */
> struct ieee802154_mlme_ops {
> + int (*reset_req)(struct net_device *dev,
> +u8 SetDefaultPIB);
>int (*assoc_req)(struct net_device *dev,
>struct ieee802154_addr *addr,
>u8 channel, u8 page, u8 cap);
> diff --git a/include/net/nl802154.h b/include/net/nl802154.h
> index 99d2ba1..23c2302 100644
> --- a/include/net/nl802154.h
> +++ b/include/net/nl802154.h
> @@ -123,4 +123,13 @@ int ieee802154_nl_beacon_indic(struct net_device
> *dev, u16 panid,
> */
> int ieee802154_nl_start_confirm(struct net_device *dev, u8 status);
>
> +/**
> + * ieee802154_reset_confirm - Notify userland of completion of reset.
> + * @dev: The device which was instructed to scan.
> + * @status: The status of the scan operation.
> + *
> + * Note: This is in section 7.1.9.2 of the IEEE 802.15.4 document.
> + */
> +int ieee802154_reset_confirm(struct net_device *dev, u8 status);
> +
> #endif
> diff --git a/net/ieee802154/nl-mac.c b/net/ieee802154/nl-mac.c
> index adaf462..2ace28b 100644
> --- a/net/ieee802154/nl-mac.c
> +++ b/net/ieee802154/nl-mac.c
> @@ -1,8 +1,6 @@
> /*
> * Netlink inteface for IEEE 802.15.4 stack
> *
> - * Copyright 2007, 2008 Siemens AG
> - *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2
> * as published by the Free Software Foundation.
> @@ -20,6 +18,8 @@
> * Sergey Lapin
> * Dmitry Eremin-Solenikov
> * Maxim Osipov
> + * Felix Varghese
> + * Prajosh Premdas
> */
>
> #include
> @@ -519,6 +519,58 @@ static int ieee802154_scan_req(struct sk_buff *skb,
> struct genl_info *info)
>return ret;
> }
>
> +static int ieee802154_reset_req(struct sk_buff *skb, struct genl_info
> *info)
> +{
> + struct net_device *dev;
> + u8 SetDefaultPIB;
> + int ret = -EINVAL;
> +
> + if (!info->attrs[IEEE802154_ATTR_SET_DEFAULT_PIB])
> + return -EINVAL;
> +
> + dev = ieee802154_nl_get_dev(info);
> + if (!dev)
> + return -ENODEV;
> +
> + if (nla_get_u8(info->attrs[IEEE802154_ATTR_SET_DEFAULT_PIB]))
> + SetDefaultPIB = 1;
> + else
> + SetDefaultPIB = 0;
> +
> + ret = ieee802154_mlme_ops(dev)->reset_req(dev, SetDefaultPIB);
> +
> + if (ret == 0)
> + ieee802154_reset_confirm(dev, IEEE802154_SUCCESS);
> + else
> + ieee802154_reset_confirm(dev,
> IEEE802154_INVALID_PARAMETER);
> +
> + dev_put(dev);
> + return ret;
> +}
> +
> +int ieee802154_reset_confirm(struct net_device *dev, u8 status)
> +{
> + struct sk_buff *msg;
> +
> + msg = ieee802154_nl_create(0, IEEE802154_RESET_CONF);
> + if (!msg)
> + return -ENOBUFS;
> +
> + NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
> + NLA_PUT_U32(msg, IEEE802154_ATTR_DEV_INDEX, dev->ifindex);
> + NLA_PUT(msg, IEEE802154_ATTR_HW_ADDR, IEEE802154_ADDR_LEN,
> + dev->dev_addr);
> +
> + NLA_PUT_U8(msg, IEE
[Linux-zigbee-devel] register net device during probe rather that add_iface
Hi All I have been using the code and have been adding functionality for the mac stack. I need certain inputs and have some doubts on the current code. I have listed out my doubts below 1. The network device is currently registered / created using the add_iface method, I would suggest to do the same during the driver probe (e.g. spi_probe function in radios over spi bus). Problem seen is, more than one nic devices or mac instance can be registered on a single radio and all of the can be controlled using different user space application. In affect more than one user space application can set parameters like channel or even invoke scan association commands on a single radio. This will definitely leads to to races. 2. RX path: All the command frames received are pushed to a common function ieee802154_rx_irqsafe and finally to mac802154_monitors_rx. Suppose if i have 2 radios one on Sub Ghz and another on 2.4Ghz both have the same PAN id and both are coordinators (Suppose my device is a gateway cum coordinators for 2 PANs) then the packets(mac commands) from both radios will be received will be both user space netlink based applications(you have a cross talk). If we map each of the radio to a network interface as described above it can be handled. Please review my observations and give me feedback on the same -- Regards, Prajosh Premdas -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] register net device during probe rather that add_iface
Sorry missed the group -- Forwarded message -- From: Prajosh Premdas Date: Fri, Mar 2, 2012 at 4:31 PM Subject: Re: [Linux-zigbee-devel] register net device during probe rather that add_iface To: Dmitry Eremin-Solenikov On Fri, Mar 2, 2012 at 3:26 PM, Dmitry Eremin-Solenikov wrote: > > Hello, > > On Fri, Mar 2, 2012 at 1:35 PM, Prajosh Premdas > wrote: > > Hi All > > > > I have been using the code and have been adding functionality for the > > mac > > stack. I need certain inputs and have some doubts on the current code. > > I'm sorry but your suggestions make nearly no sense. The current design > is targeted different applications and different types of interfaces which > can be bound to each radio. I had an understanding that this project is meant for Linux to have a 802.15.4 mac stack and my suggestions were based on the same. I want to add 802.15.4 mac stack in Linux as per the IEEE 802.15.4 specification-2006 so where will it fit? > > > > > I have listed out my doubts below > > > > 1. The network device is currently registered / created using the > > add_iface > > method, I would suggest to do the same during the driver probe (e.g. > > spi_probe function in radios over spi bus). Problem seen is, more than > > one > > nic devices or mac instance can be registered on a single radio and all > > of > > the can be controlled using different user space application. In affect > > more > > than one user space application can set parameters like channel or even > > invoke scan association commands on a single radio. This > > will definitely leads to to races. > > NO. The idea (as it is currently handled) is to be not so 802.15.4 centric > on those radios. In reality one doesn't have to have IEEE 802.15.4 > interface > on WPAN PHY at all! E.g. I can use WPAN PHY radios with simple mac (SMAC) > which meets my goals perfectly. I don't need 802.15.4 MAC code on that > PHY. > Or one can have two radios (PHYs) - one acting as 802.15.4 MAC, one acting > as passive (or active) monitor interface. > > > > > 2. RX path: All the command frames received are pushed to a common > > function > > ieee802154_rx_irqsafe and finally to mac802154_monitors_rx. Suppose if i > > have 2 radios one on Sub Ghz and another on 2.4Ghz both have the same > > PAN id > > and both are coordinators (Suppose my device is a gateway cum > > coordinators > > for 2 PANs) then the packets(mac commands) from both radios will be > > received > > will be both user space netlink based applications(you have a cross > > talk). > > If we map each of the radio to a network interface as described above it > > can > > be handled. > > First, as I said, radio can not (and should not) be mapped to the > network interface. > > Second. monitors_rx handle only monitoring interfaces on a radio. > There are other > types of interfaces and respective receive functions. > > Third. Netlink interface consists (currently) of two layers. One is more > or less > related to PHY handling (such as allocating/deallocating interfaces, > providing > page/channel information used by radio). Those notifications/commands > use PHY ID to select corresponding WPAN PHY instance. > Other type of commands are related to IEEE 802.15.4 PHY interface. They > are specific to IEEE 802.15.4 network devices (be it softmac or hardmac). > They use device id to communicate about particular device in question. > > Hope this makes things and design clear. > > It might make more sense to compare whole LoWPAN subsystem with > WiFi subsystem. The main difference is that for mac802.11 devices > we have sane default - most users would like a simple ethernet device > (other types are mesh, AP, monitor, maybe more). For LoWPAN we don't > have such sane default. LoWPAN != IEEE 802.15.4, so we don't want > to enforce users to have that interface by default. > > -- > With best wishes > Dmitry -- Regards, Prajosh Premdas -- Regards, Prajosh Premdas -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] register net device during probe rather that add_iface
Hi All & Dmitry
Now i see your point there and understand the design better. But i
have a few more doubts.
Case #1: synchronous mlme commands(mlme_reset, mlme_get, mlme_set)
We(currently Felix and my self) are adding mac functionality. I will
just briefly describe you
1. my test setup
2. code flow for pib set (eg. set channel page)
Please confirm me that flow as expected. This will reduce a lot of rework too.
1. Test setup: AT91SAM9G20-EK + AT86RF231(wsn-phy0) and all the
modules correctly loaded.i describe a new device type
IEEE802154_DEV_WPAN with the ops structure initialized as
struct ieee802154_mlme_ops mac802154_mlme_device = {
.reset_req = mlme_reset_req,
.get_req= mlme_get_req,
.set_req= mlme_set_req,
.assoc_req = mlme_associate_req,
.assoc_resp = mlme_associate_resp,
.get_phy= mac802154_get_phy
};
I have created 2 net device interface wsn0 and wsn1 from the single
wsn-phy0 radio. both are of device type IEEE802154_DEV_WPAN
2.code flow: I am running 2 configuration application one on each of
the net device interface and i set channel 11 for wsn0 and channel 15
for wsn1. Now the radio sets the channel which has been set the last.
same is the case for any pib.
It is ok to have one monitor and another device kind of wsn interfaces.
This flow i dont think is right. I think i have missed a major part in
your design. How do i stop multiple IEEE802154_DEV_WPAN type of
interfaces?
I hope you understood this problem.
Once this is fixed i will discuss on the case#2 mlme functions like association
On Sat, Mar 3, 2012 at 2:48 AM, Dmitry Eremin-Solenikov
wrote:
> On Fri, Mar 2, 2012 at 3:52 PM, Felix Varghese wrote:
>> Guys, I'd like to join the foray too :)
>>
>>> I'm sorry but your suggestions make nearly no sense. The current design
>>> is targeted different applications and different types of interfaces which
>>> can be bound to each radio.
>> Ability to bind different types of interfaces to the same radio is
>> desirable. However, is there any scenario where multiple interfaces
>> would be simultaneously bound to the same radio at the same time? Or
>> did I misunderstand the purpose of storing a list of slaves in
>> mac802154_priv? Also, wouldn't this cause some confusion as to which
>> specific interface should handle packets received over a particular
>> radio?
>
> Yes. I want to have ability to bind monitor together with _any_ other
> interface.
> We do not have that implemented, but most probably being a retransmitter
> (coordinator in one segment and a child node in another) would require two
> interfaces bound to single node. I like the ability to control SMAC and
> 802.15.4
> from single radio. Or another sample - participating in two different 802.15.4
> networks at the same time. This reqires two subinterfaces. So, this should
> stay as it is, unless I see strong arguments to do it another way.
>
> And no, this won't cause any confusion: all interfaces bound to radio
> receive all
> packets (by design). It is a part of the interface to understand if it
> should receive
> this packet and handle it accordingly (drop). Consider two PANs on single
> radio.
> Each subinterface will receive all packets and drop all packets which belong
> to
> other PAN.
>
>>
>>> other types are mesh, AP, monitor, maybe more). For LoWPAN we don't
>>> have such sane default. LoWPAN != IEEE 802.15.4, so we don't want
>>> to enforce users to have that interface by default.
>> Doesn't IEEE802.15.4 qualify as a sane default? Even if it doesn't,
>> and we require the user to explicitly add an interface before he can
>> use the radio, can we not restrict him to one interface per radio at
>> any given time, thereby preventing the aforementioned confusion?
>
> No. At this moment IEEE 802.15.4 does not qualify as a sane default,
> because MAC implementation is far from being complete. And no, we
> must not restrict user in allocating one interface per radio.
>
> BTW: mac80211 (which we used as a model to follow in some points)
> does not have any restrictions on its own in this area. Most of the
> restrictions
> come from hardware. And even in that case it is usually possible to allocate
> "ethernet" subif together with "monitor" subif.
>
> --
> With best wishes
> Dmitry
--
Regards,
Prajosh Premdas
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] register net device during probe rather that add_iface
On Sun, Mar 4, 2012 at 9:59 PM, Felix Varghese wrote: > Hi, > >> BTW: I remember rf231/rf212 chips having ACK/filter MAC acceleration. Does >> Atmel have a chip with support for beaconing or beaconed networks? > > You are right, they both support auto ACK, CSMA-CA, retries and > address filtering. They do support beacon-enabled networks in that > they can send out slotted auto-ACKs, etc. But in this case, the burden > of providing the exact timing falls on the micro-controller. It should > pulse a pin to trigger the actual sending of the ACK. This is probably > because of the fact that only the stack would know the relevant > timings such as slot-boundaries. > >>> As far as a single radio joining two PANs is concerned, in case the >>> aforementioned hardware acceleration is used, it cannot be done, >>> unless the radio itself supports dual addresses, pan ids, etc. If such >>> a radio does arrive in the market, can we not have two instances of >>> wpan phy itself, one bound to each such 'logical' radio? >> 76.164.216.197:8181 >> >> >> No, because it would be still a single radio with single channel settings. > > Ok, I think I got your point there, thanks. > >>>> No. At this moment IEEE 802.15.4 does not qualify as a sane default, >>>> because MAC implementation is far from being complete. >>> >>> We were hoping to help you guys rectify that problem :) >> >> We really appreciate your efforts. Maybe we should meet on IRC or on ML >> to discuss your intentions, your goals and your plan. What do you think? > > We think that is a good idea! In short, we are trying to get add a 802.15.4 stack to Linux to support various radios like at86rf23x/212 cc2420/2520, support modules like ZigBit and extend support for USB based sticks. So i think we should join forces and build this stack. We have completed the reset, get, set pib and associate functions in mac. We have so far send patches of nl based changes only. I think we should use IIRchat and sync up on the design before proceeding further. A new 802.15.4g std is in pipeline with a higher mpdu size and lots of additional modes. > > Regards, > Felix. -- Regards, Prajosh Premdas -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] register net device during probe rather that add_iface
On Sun, Mar 4, 2012 at 11:08 PM, jonsm...@gmail.com wrote: > On Sun, Mar 4, 2012 at 12:19 PM, Prajosh Premdas > wrote: >> On Sun, Mar 4, 2012 at 9:59 PM, Felix Varghese wrote: >>> Hi, >>> >>>> BTW: I remember rf231/rf212 chips having ACK/filter MAC acceleration. Does >>>> Atmel have a chip with support for beaconing or beaconed networks? >>> >>> You are right, they both support auto ACK, CSMA-CA, retries and >>> address filtering. They do support beacon-enabled networks in that >>> they can send out slotted auto-ACKs, etc. But in this case, the burden >>> of providing the exact timing falls on the micro-controller. It should >>> pulse a pin to trigger the actual sending of the ACK. This is probably >>> because of the fact that only the stack would know the relevant >>> timings such as slot-boundaries. >>> >>>>> As far as a single radio joining two PANs is concerned, in case the >>>>> aforementioned hardware acceleration is used, it cannot be done, >>>>> unless the radio itself supports dual addresses, pan ids, etc. If such >>>>> a radio does arrive in the market, can we not have two instances of >>>>> wpan phy itself, one bound to each such 'logical' radio? >>>> 76.164.216.197:8181 >>>> >>>> >>>> No, because it would be still a single radio with single channel settings. >>> >>> Ok, I think I got your point there, thanks. >>> >>>>>> No. At this moment IEEE 802.15.4 does not qualify as a sane default, >>>>>> because MAC implementation is far from being complete. >>>>> >>>>> We were hoping to help you guys rectify that problem :) >>>> >>>> We really appreciate your efforts. Maybe we should meet on IRC or on ML >>>> to discuss your intentions, your goals and your plan. What do you think? >>> >>> We think that is a good idea! >> >> In short, we are trying to get add a 802.15.4 stack to Linux to >> support various radios like at86rf23x/212 cc2420/2520, support modules >> like ZigBit and extend support for USB based sticks. So i think we >> should join forces and build this stack. > > Have you considered using SOC 802.15.4 chips attached to your Linux > host as a way of avoiding the real-time issues? Beaconed mode is going > to require some difficult code on the Linux side in order to maintain > the tight timing requirements. Most SOC 802.15.4 chips are available > in USB sticks making development easy. > > An approach would be to fully implement the 802.15.4 MAC in Contiki > (it is partially there). Then run the MAC on a dedicated SOC 802.15.4 > chip. Use Linux to talk to this hard MAC implementation. > Yes when we have to consider SOCs like ATmegaRF series and some from Ti too. This can be treated as a set of modules i mentioned. But the first priority i think should be on the native Linux > >> >> We have completed the reset, get, set pib and associate functions in >> mac. We have so far send patches of nl based changes only. >> >> I think we should use IIRchat and sync up on the design before >> proceeding further. >> >> A new 802.15.4g std is in pipeline with a higher mpdu size and lots of >> additional modes. >>> >>> Regards, >>> Felix. >> >> >> >> -- >> Regards, >> >> Prajosh Premdas >> >> -- >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> ___ >> Linux-zigbee-devel mailing list >> Linux-zigbee-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel > > > > -- > Jon Smirl > jonsm...@gmail.com -- Regards, Prajosh Premdas -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] register net device during probe rather that add_iface
On Sun, Mar 4, 2012 at 11:30 PM, jonsm...@gmail.com wrote: > On Sun, Mar 4, 2012 at 12:45 PM, Prajosh Premdas > wrote: >> On Sun, Mar 4, 2012 at 11:08 PM, jonsm...@gmail.com >> wrote: >>> On Sun, Mar 4, 2012 at 12:19 PM, Prajosh Premdas >>> wrote: >>>> On Sun, Mar 4, 2012 at 9:59 PM, Felix Varghese >>>> wrote: >>>>> Hi, >>>>> >>>>>> BTW: I remember rf231/rf212 chips having ACK/filter MAC acceleration. >>>>>> Does >>>>>> Atmel have a chip with support for beaconing or beaconed networks? >>>>> >>>>> You are right, they both support auto ACK, CSMA-CA, retries and >>>>> address filtering. They do support beacon-enabled networks in that >>>>> they can send out slotted auto-ACKs, etc. But in this case, the burden >>>>> of providing the exact timing falls on the micro-controller. It should >>>>> pulse a pin to trigger the actual sending of the ACK. This is probably >>>>> because of the fact that only the stack would know the relevant >>>>> timings such as slot-boundaries. >>>>> >>>>>>> As far as a single radio joining two PANs is concerned, in case the >>>>>>> aforementioned hardware acceleration is used, it cannot be done, >>>>>>> unless the radio itself supports dual addresses, pan ids, etc. If such >>>>>>> a radio does arrive in the market, can we not have two instances of >>>>>>> wpan phy itself, one bound to each such 'logical' radio? >>>>>> 76.164.216.197:8181 >>>>>> >>>>>> >>>>>> No, because it would be still a single radio with single channel >>>>>> settings. >>>>> >>>>> Ok, I think I got your point there, thanks. >>>>> >>>>>>>> No. At this moment IEEE 802.15.4 does not qualify as a sane default, >>>>>>>> because MAC implementation is far from being complete. >>>>>>> >>>>>>> We were hoping to help you guys rectify that problem :) >>>>>> >>>>>> We really appreciate your efforts. Maybe we should meet on IRC or on ML >>>>>> to discuss your intentions, your goals and your plan. What do you think? >>>>> >>>>> We think that is a good idea! >>>> >>>> In short, we are trying to get add a 802.15.4 stack to Linux to >>>> support various radios like at86rf23x/212 cc2420/2520, support modules >>>> like ZigBit and extend support for USB based sticks. So i think we >>>> should join forces and build this stack. >>> >>> Have you considered using SOC 802.15.4 chips attached to your Linux >>> host as a way of avoiding the real-time issues? Beaconed mode is going >>> to require some difficult code on the Linux side in order to maintain >>> the tight timing requirements. Most SOC 802.15.4 chips are available >>> in USB sticks making development easy. >>> >>> An approach would be to fully implement the 802.15.4 MAC in Contiki >>> (it is partially there). Then run the MAC on a dedicated SOC 802.15.4 >>> chip. Use Linux to talk to this hard MAC implementation. >>> >> Yes when we have to consider SOCs like ATmegaRF series and some from >> Ti too. This can be treated as a set of modules i mentioned. But the >> first priority i think should be on the native Linux > > cc2530, mc13224 and stm32w are all in common use. They don't cost that > much more than the non-SOC chips. > > Doing a full MAC on native Linux with radio-only chips is probably > going to require the real-time kernel in order to meet timing > restrictions. You also have to allow for the different speed links > into the chips - serial, SPI, USB, etc. It is much easier to move the > hard real-time code onto a SOC. 95% of the code will still run on > Linux, you just off-load the problem bits into the SOC. > I agree with you that SOCs are low cost. I think the support is already present as raw packets. If you create a raw 802.15.4 socket and then i think it can be extended for any SOC. There is some development required here as the format of raw frames being send to radio has to be designed. Since today most of the radios are smart the crucial timing parameters are handled by the radio. Rest of the timings are handle able by the linux box with not so real time os. >>> >>>> >>>> We have completed the reset, get
Re: [Linux-zigbee-devel] [PATCH 1/9] ieee802154: mlme reset for netlink interface
On Mon, Mar 5, 2012 at 12:31 AM, Dmitry Eremin-Solenikov wrote: > Hello, > > On Sun, Mar 4, 2012 at 9:05 PM, Felix Varghese wrote: >> On 3 March 2012 18:40, Dmitry Eremin-Solenikov wrote: >>> Summary on all the patchset below. >>> >>> Prajosh, Felix. Thanks for your work on IEEE 802.15.4 for Linux. Please >>> don't find my mails as discouraging or otherwise demoting your work. >>> There are some coding standards. There are some ideas behind code. There >>> is more than just blindly following standard text letter by letter. >> >> Firstly, thanks a lot for spending time to review these patches. We >> understand that we need put in a lot of work on them, and we are >> prepared to do that. > > :) > >> >>> First, your mixup of terms PIB and MIB leads to confusion. >> >> PIB, the way we meant it, stands for PAN Information Base, as defined >> in IEEE 802.15.4-2006. It is a collection of attributes, each of which >> has an attribute id and a corresponding value. It includes MAC PIB >> (stuff like short address, PAN ID, etc.) and PHY PIB (channel, channel >> page, etc.). > > Ah, ok. I'm sorry here. I've last read the standard about a year ago. Maybe > I mixed it up with some other standard. I had terms PIB and MIB in my mind. > >> This is the terminology we tried to follow consistently >> in the code. If we are aiming for IEEE compliance and >> interoperability, we would need to implement a get and set for each >> and every one of these attributes (although indeed the terminology >> wouldn't matter!). So, even if these attributes weren't actually got >> or set anywhere in the code (which they would be, as an when new >> features are implemented), their implementation is a significant step >> towards building an proper 802.15.4 implementation. > > Yes and no. First, do you plan to have standard compatibility on the > "procedure" level of things - I mean implementing all procedures as > defined by standard? They don't always fit the Linux model. E.g. > there are probably better ways to implement passing of scan results > to userspace, comparing to the standard text. I'm really not sure > that implementing PHY PIB as get/set is a "Goot Thing". Etc. > We may not or will not implement the complete 802.15.4 standard. We need to implement the basic functions like association, disassociation, all scans, direct and indirect data-tx, rx and beacon. GTS is some thing which we plan to leave out. but things like Beacon enabled network with indirect data comm is good to have. Once we implement these then we got to make sure they are interop with other golden nodes. Then we can have interested people can implement things like 6lowpan, zigbee or RF4CE over this. But if we are not inter-operate our stack cant be used by any body Can we fix up some IRC chat accounts as mentioned in previous mails, with you guys so that we can further discuss the design to the bottom. Things like code flow etc > Regarding unused/unimplemented things. There is no point in > implementing just the "get/set" operations. They will be the dead code. > It might be used in future. And might not. Or they might require > a different implementation. Usually there is little point in implementing > such "features". I would really prefer to have code that uses those > values, rather than just list of values. > >> The PIB also forms >> the backbone over which the rest of the features would fit in. The MAC >> primitives, when implemented, will use these attributes heavily. > > Yes, it is true. But strictly speaking PIB is not the most important > part of the standard to implement. It is true that we did not implement > GET/SET/RESET commands due to various reasons ranging from > problems with designing good interface to PIB. I'm not sure that > NetLink is well suited for such task. Could you please consult with > cfg80211 subsystem to check how they implemented access to > their information base variables? > > -- > With best wishes > Dmitry -- Regards, Prajosh Premdas -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] register net device during probe rather that add_iface
On Mon, Mar 5, 2012 at 12:46 AM, Dmitry Eremin-Solenikov wrote: > John, > > On 04/03/12 21:38, jonsm...@gmail.com wrote: >> On Sun, Mar 4, 2012 at 12:19 PM, Prajosh Premdas >> wrote: >>> On Sun, Mar 4, 2012 at 9:59 PM, Felix Varghese wrote: > >>>>>>> No. At this moment IEEE 802.15.4 does not qualify as a sane default, >>>>>>> because MAC implementation is far from being complete. >>>>>> >>>>>> We were hoping to help you guys rectify that problem :) >>>>> >>>>> We really appreciate your efforts. Maybe we should meet on IRC or on ML >>>>> to discuss your intentions, your goals and your plan. What do you think? >>>> >>>> We think that is a good idea! >>> >>> In short, we are trying to get add a 802.15.4 stack to Linux to >>> support various radios like at86rf23x/212 cc2420/2520, support modules >>> like ZigBit and extend support for USB based sticks. So i think we >>> should join forces and build this stack. >> >> Have you considered using SOC 802.15.4 chips attached to your Linux >> host as a way of avoiding the real-time issues? Beaconed mode is going >> to require some difficult code on the Linux side in order to maintain >> the tight timing requirements. Most SOC 802.15.4 chips are available >> in USB sticks making development easy. >> >> An approach would be to fully implement the 802.15.4 MAC in Contiki >> (it is partially there). Then run the MAC on a dedicated SOC 802.15.4 >> chip. Use Linux to talk to this hard MAC implementation. > > Implementing Full MAC in the SoC/stick/etc. code is a good idea. I had > plans implementing some parts of that code on Freescale eval boards > (HCS08 + MC13192 radio). I know several guys implemented some 802.15.4 > code on MC13224v boards. Probably one of the low hanging fruits would > be to implement HardMAC support for Philips SRM 7500 dongle. It > implements 802.15.4 protocol over USB and it is already reverse > engineered > (http://sourceforge.net/apps/mediawiki/srm7500-linux/index.php). However > that remote control costs :( > Some more off the shelf solutions The full mac is already implemented and the source code is available for ARM and AVR based usb sitcks http://www.dresden-elektronik.de/shop/cat4_33.html?XTCsid=f1a582c1645307d399c2ccc1157b175b and Raven USb sticks They are also available in packages with FCC certification in ZigBit http://www.mikrocontroller.net/articles/Meshnetics_Zigbee > -- > With best wishes > Dmitry -- Regards, Prajosh Premdas -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH 1/9] ieee802154: mlme reset for netlink interface
On Mon, Mar 5, 2012 at 12:57 AM, Dmitry Eremin-Solenikov wrote: > On 04/03/12 23:19, Prajosh Premdas wrote: >> On Mon, Mar 5, 2012 at 12:31 AM, Dmitry Eremin-Solenikov >> wrote: >>> Hello, >>> >>> On Sun, Mar 4, 2012 at 9:05 PM, Felix Varghese wrote: >>>> On 3 March 2012 18:40, Dmitry Eremin-Solenikov >>>> wrote: >>>>> Summary on all the patchset below. >>>>> >>>>> Prajosh, Felix. Thanks for your work on IEEE 802.15.4 for Linux. Please >>>>> don't find my mails as discouraging or otherwise demoting your work. >>>>> There are some coding standards. There are some ideas behind code. There >>>>> is more than just blindly following standard text letter by letter. >>>> >>>> Firstly, thanks a lot for spending time to review these patches. We >>>> understand that we need put in a lot of work on them, and we are >>>> prepared to do that. >>> >>> :) >>> >>>> >>>>> First, your mixup of terms PIB and MIB leads to confusion. >>>> >>>> PIB, the way we meant it, stands for PAN Information Base, as defined >>>> in IEEE 802.15.4-2006. It is a collection of attributes, each of which >>>> has an attribute id and a corresponding value. It includes MAC PIB >>>> (stuff like short address, PAN ID, etc.) and PHY PIB (channel, channel >>>> page, etc.). >>> >>> Ah, ok. I'm sorry here. I've last read the standard about a year ago. Maybe >>> I mixed it up with some other standard. I had terms PIB and MIB in my mind. >>> >>>> This is the terminology we tried to follow consistently >>>> in the code. If we are aiming for IEEE compliance and >>>> interoperability, we would need to implement a get and set for each >>>> and every one of these attributes (although indeed the terminology >>>> wouldn't matter!). So, even if these attributes weren't actually got >>>> or set anywhere in the code (which they would be, as an when new >>>> features are implemented), their implementation is a significant step >>>> towards building an proper 802.15.4 implementation. >>> >>> Yes and no. First, do you plan to have standard compatibility on the >>> "procedure" level of things - I mean implementing all procedures as >>> defined by standard? They don't always fit the Linux model. E.g. >>> there are probably better ways to implement passing of scan results >>> to userspace, comparing to the standard text. I'm really not sure >>> that implementing PHY PIB as get/set is a "Goot Thing". Etc. >>> >> We may not or will not implement the complete 802.15.4 standard. We >> need to implement the basic functions like association, >> disassociation, all scans, direct and indirect data-tx, rx and beacon. > > Assoc is kind of implemented (minor deviation from standard due to > missing pending rx/tx). Disassoc is implemented. Data RX/TX are > implemented but without "data pending" queues on coordinator. Beacons > are also supported (kind of). > >> >> GTS is some thing which we plan to leave out. but things like Beacon >> enabled network with indirect data comm is good to have. Once we >> implement these then we got to make sure they are interop with other >> golden nodes. > > GTS were just an example of a feature that was present in your code, but > is not really to be seen in the near future. > >> Then we can have interested people can implement things >> like 6lowpan, zigbee or RF4CE over this. But if we are not >> inter-operate our stack cant be used by any body > > 6lowpan is already implemented and present in recent kernels. > Zigbee/ZigBee RF4CE are to be implemented as userspace protocols > due to ZigBee standard licensing terms. > >> >> Can we fix up some IRC chat accounts as mentioned in previous mails, >> with you guys so that we can further discuss the design to the bottom. >> Things like code flow etc > > Sending a separate mail on the list. Thanks and perfect, We will sort out the features to be implemented > > -- > With best wishes > Dmitry > -- Regards, Prajosh Premdas -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] IRC meeting scheduling
On Mon, Mar 5, 2012 at 1:14 AM, Dmitry Eremin-Solenikov wrote: > Guys, > > I see an interest in an IRC meeting on the future of 802.15.4 for Linux, > current plans of different implementors and interested people. > > I would like to invite all people interested in such meeting to fill > the data in the table at > https://sourceforge.net/apps/trac/linux-zigbee/wiki/IRCMeetup (I think > you can use any sf account, not necessary linked to this project) or, if > you don't want to register sf account, > drop an a mail here in the response to this message. Lets select the > time afterwards. > Thanks for your time and effort > Also please state agenda topics (preferably on that page, but again you > can just drop a note here if you can't edit the page). > Can you please tell me the server name used for linux-zigbee IRC chat? > -- > With best wishes > Dmitry > > -- > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > ___ > Linux-zigbee-devel mailing list > Linux-zigbee-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel -- Regards, Prajosh Premdas -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] Prelude to the topics we will take up in IRC channel
Hi All I am trying to create a prelude to the topics we will take up in IRC channel. (They are already there in trac wiki) but to get stuff moving 1. Source code related 1. Work we (Felix and myself) have completed: mlme set, get, reset and association. We have only sent 6 patches out of our work(39 patches). 2. A base from where we can start integrating and resend the patches. Do you have any more code which have not been sent? need to find a way to share that code so that we can have a look. 2. Design related 1. understanding and adapting the 802.15.4 standard into the Linux 2. understanding of the existing work. 3. Create a common work plan We can finalize the topics and take a snap shot of this and place it in the trac wiki. -- Regards, Prajosh Premdas -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] IRC log for 2012-03-14 meeting
On Fri, Mar 16, 2012 at 9:34 PM, Stefan Schmidt wrote: > Hello. > > On Fri, 2012-03-16 at 16:16, Luca BRUNO wrote: >> >> 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. > > Thanks for this. Thanks a lot for the "minutes of IRC" > > regards > Stefan Schmidt > > -- > 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 > -- Regards, Prajosh Premdas -- 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
[Linux-zigbee-devel] devel branch in linux-zigbee project doesn't compile in latest net-next
Hi All The code in devel branch in linux-zigbee project, I find doesnot compile in latest net-next Reason : A lot of macros like NETIF_F_NO_CSUM is missing in net-next latest. If any body have a fixed copy of code could you please share it with me? If there are any other branch can you please share it with me? If above both conditions are NULL can any body can lend a hand(two hands) in fixing them :) -- Regards, Prajosh Premdas -- 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
Re: [Linux-zigbee-devel] Driver ATmega128RF1A
Hi Ivo You got to use a user space application http://sourceforge.net/apps/trac/linux-zigbee/wiki/GettingStarted-0.2 Read through this and run the driver in PC before you start the work on board Hope you understood. You will get a flow of the code etc from this Regards Prajosh On Thu, Sep 13, 2012 at 3:03 PM, Ivo Kunadt wrote: > Hello, > > i am trying to write a hardmac driver for the Atmega128RF1A (modul > AT-Any-2400-SC3-2). This is my first driver and i have not so much > experience with linux. > > First i written a SPI driver on base of the at86rf230 and register a > netdevice in the probe function. I use at the moment linux-3.6-rc1. > I can open a socket and send some messages to the device. > > My first question is : Who calls my ieee802154_mlme_ops functions? In the > at86rf230 driver is the ieee802154_rx_irqsafe function, but was is > counterpart in my case? > > Please let me know if you need more details. > > Regards, > Ivo > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Linux-zigbee-devel mailing list > Linux-zigbee-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel > -- Regards, Prajosh Premdas -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Antw: Re: Driver ATmega128RF1A
Hi
I have a few more information to share
http://code.google.com/p/linux-wsn/wiki/LinuxStack
Please go through this link
Prajosh
On Thu, Sep 13, 2012 at 6:03 PM, Ivo Kunadt wrote:
> Hi,
>
> i think you need some more information:
> Linux Controller: imx35
> Linux Kernel : 3.6.rc1
>
> "Zigbee" Device: AT-ANY-2400-SC-3
> Controller on the board: Atmega128rf1a
> The Zigbee Device run with the Atmel Mac Stack at the moment. The goal is to
> write a driver for the Atmega128rf1a that use a socket.
>
> My idea was now to take the at86rf230 SPI part and rewrite it:
>
> static int __devexit atmega128rfa1_remove(struct spi_device *spi){
> /*Device aus platform besorgen und deint*/
> dev_info(&spi->dev, "atmega128rfa1: remove");
> struct at86rf230_local *lp = spi_get_drvdata(spi);
> unregister_netdev(lp->dev);
> spi_set_drvdata(spi, NULL);
> mutex_destroy(&lp->bmux);
> return 0;
> }
>
> static struct spi_driver atmega128rfa1_driver = {
> .driver = {
> .name = "atmega128rf1a",
> .owner = THIS_MODULE,
> },
> .id_table = atm_dev_id,
> .remove = __devexit_p(atmega128rfa1_remove),
> .probe = tmega128rfa1_probe,
> };
>
>
> static __init int spi_atmega128fa1_init(void){
> printk( KERN_ALERT "atmega128rfa1: init");
>
> return spi_register_driver(&atmega128rfa1_driver);
> }
>
> static __exit void spi_atmega128fa1_exit(void){
> spi_unregister_driver(&atmega128rfa1_driver);
> }
>
> module_init(atmega128fa1_init);
> module_exit(atmega128fa1_exit);
> MODULE_DESCRIPTION("ATmega128RFA1 Controller/Transceiver Driver");
> MODULE_LICENSE("GPL2");
>
>
> In my prop function:
>
> alloc and register wpan_phy
> alloc and register net_device
> init a struct like the at86rf230_local in at86rf230.c
> init lock and mutex
> TODO: reqeust an gpio irq to get information from slave. The SPI Slave
> musst talk to the master e.g. lost the connection or something else.
>
> At the moment i send some bytes in the xmit function of the net_device_ops.
> Now i want to use the ieee802154_mlme_ops func e.g. to send a request. But
> how can i do that?
>
> Please let me know if you need more details.
>
> Regards,
> Ivo
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Linux-zigbee-devel mailing list
> Linux-zigbee-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
>
--
Regards,
Prajosh Premdas
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] 6LoWPAN and linux-zigbee (newbie)
Hi Alex Sorry I dont intend to be a wet blanket here. I would like to add rather than building the ZigBee stack on Linux user space it would be better to use a modem based approach. In todays market there are a lot of certified modules avaliable in the market and they are cheap too. So if i see from a user point of view i dont see a need for a userspace stack. >From my experience module as a modem is a better method for the following reasons 1. The cost and time for certifing the ZigBee stack is huge comapred to the module cost 2. ZigBee stack itself is not enough you need a lot of profiles to do any thing useful. Even the profiles need to be certified 3. You will need encryption libraries like the one from Certicom- even on module you have to pay extra 4. Even the mac is not certified in Linux A third party module has all these things inbuild all you need is an interface driver which can be USB,SPI or even UART Just to add but in case of 6Lowpan a good TCP-UDP-IP infrastructure exsists in Linux. On Tue, Sep 24, 2013 at 10:01 AM, Alexander Aring wrote: > Hi Sascha, > > On Mon, Sep 23, 2013 at 08:41:20PM +0200, Sascha Herrmann wrote: > > Hi, > > > > > Could it be related somehow to ZigBee lincense ? ( > http://www.zigbee.org/) > > > Moreover, I saw in a lecture: > > > > http://elinux.org/images/7/71/Wireless_Networking_with_IEEE_802.15.4_and_6LoWPAN.pdf > > > from 2012, by Alan Ott: > > > > Maybe you can get some more information about this issue from this > > article: > > > http://www.freaklabs.org/index.php/Blog/Zigbee/Zigbee-Linux-and-the-GPL.html > > The author had started developing an OpenSource ZigBee Stack and was > > Member of the ZA. If you dig somewhat deeper in his blog (I don't have > > the exact url at hand), you will find an article where he describes that > > he tried to start an discussion about removing the problematic part from > > the ZigBee License, but failed with this approach. After this he stopped > > the development of the stack and quit his ZA membership. > > > > If the information of this article holds, the ZigBee License is > > incompatible with the Linux Kernel. > > > > and here comes the point to switch into a userspace application (if > possible) to avoid license issues. I am not a big fan of that but we can > see this in several other projects at the linux kernel like usbdevfs > which allow to write userspace usb drivers which are not under GPL. > > My basic message is to say "it is possible", but we can't do anything > with that. Maybe it helps us to make a better userspace api. :-) > > - Alex > > > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > ___ > Linux-zigbee-devel mailing list > Linux-zigbee-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel > -- Regards, Prajosh Premdas -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
