[Linux-zigbee-devel] Unable to compile latest git revision of the lowpan-tools
Good afternoon folks,
I tried compiling the lowpan-tools on Fedora 15 and CentOS 6.2 systems
but I
could not pass the "./configure" step (called by autogen.sh) and I
would be
grateful if anyone could help me figure out why. I cloned the git repo
and am
using the latest version available at the time I write these lines
(revision
6d4636d57f87a14).
Here is the last lines of the output of the ./configure:
checking for python script directory...
${prefix}/lib/python2.7/site-packages
checking for python extension module directory...
${exec_prefix}/lib64/python2.7/site-packages
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for NL... yes
checking whether libnl requires additional libraries... failure
configure: error: in `/users/tcheneau/sources/linux-zigbee':
configure: error: failed to link program with libnl
See `config.log' for more details
I attached the corresponding (gzip'd) config.log to this mail if it can
help.
The libnl3, as well as the corresponding development files, are
installed on my system as shown below (output of the Fedora 15):
$ rpm -qa "libnl*"
libnl3-cli-3.2.7-1.fc15.x86_64
libnl3-3.2.7-1.fc15.x86_64
libnl3-devel-3.2.7-1.fc15.x86_64
libnl-1.1-14.fc15.x86_64
Note that I cannot remove libnl (version 1) because it is a dependency
for a lot of packages, but I do not believe it should cause any trouble
(as I do not have the *-devel).
I tried to modify the configure.ac file in order to remove this test. I
believe this test has very small influence on the build (presence of
the
"-lm" flag), but I'm far from being an autotool guru, so I'm not
certain. Basically, I commented out the following lines that made the
"./configure" fail previously:
AC_MSG_CHECKING([whether libnl requires additional libraries])
_libnl_save_libs="$LIBS"
LIBS="$NL_LIBS $LIBS"
AC_LINK_IFELSE([AC_LANG_CALL([], [genl_connect])], libnl_add="none"
,
libnl_add="fail")
if test "$libnl_add" = fail
then
LIBS="$NL_LIBS -lm $_libnl_save_libs"
AC_LINK_IFELSE([AC_LANG_CALL([], [genl_connect])], libnl_add="-lm"
,
libnl_add="fail")
fi
LIBS="$_libnl_save_libs"
if test "$libnl_add" = fail
then
AC_MSG_RESULT(failure)
dnl AC_MSG_RESULT([failed])
AC_MSG_FAILURE([failed to link program with libnl])
else if test "$libnl_add" = none
then
AC_MSG_RESULT([none required])
else
AC_MSG_RESULT([$libnl_add])
NL_LIBS="$NL_LIBS $libnl_add"
fi
fi
The configure succeed, but the make fails with the following error:
[...]
Making all in src
make[2]: Entering directory
`/users/tcheneau/sources/linux-zigbee/src'
CC izchat.o
CCLD izchat
CC serial.o
CCLD izattach
CC izcoordinator-coordinator.o
CCLD izcoordinator
izcoordinator-coordinator.o: In function `parse_cb':
/users/tcheneau/sources/linux-zigbee/src/coordinator.c:185: undefined
reference to `genlmsg_parse'
izcoordinator-coordinator.o: In function `coordinator_associate':
/users/tcheneau/sources/linux-zigbee/src/coordinator.c:116: undefined
reference to `genlmsg_put'
izcoordinator-coordinator.o: In function `main':
/users/tcheneau/sources/linux-zigbee/src/coordinator.c:407: undefined
reference to `genl_connect'
/users/tcheneau/sources/linux-zigbee/src/coordinator.c:410: undefined
reference to `genl_ctrl_resolve'
izcoordinator-coordinator.o: In function `mlme_start':
/users/tcheneau/sources/linux-zigbee/src/coordinator.c:79: undefined
reference to `genlmsg_put'
../lib/.libs/libcommon.a(libcommon_la-genl.o): In function
`family_handler':
/users/tcheneau/sources/linux-zigbee/lib/genl.c:67: undefined
reference to `genlmsg_attrlen'
/users/tcheneau/sources/linux-zigbee/lib/genl.c:67: undefined
reference to `genlmsg_attrdata'
../lib/.libs/libcommon.a(libcommon_la-genl.o): In function
`nl_get_multicast_id':
/users/tcheneau/sources/linux-zigbee/lib/genl.c:112: undefined
reference to `genl_ctrl_resolve'
/users/tcheneau/sources/linux-zigbee/lib/genl.c:114: undefined
reference to `genlmsg_put'
collect2: ld returned 1 exit status
make[2]: *** [izcoordinator] Error 1
make[2]: Leaving directory `/users/tcheneau/sources/linux-zigbee/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/users/tcheneau/sources/linux-zigbee'
make: *** [all] Error 2
I do not know where the linking errors come from (and I do not know how
to obtain the full compilation command that cause the error either).
Should I use a more recent version of libnl3 (git version?) or was I
wrong to believe that the git tree of lowpan-tools can be compiled? I
must admit that I'm a bit lost here.
Thank you in advance for all your advice and sug
Re: [Linux-zigbee-devel] Unable to compile latest git revision of the lowpan-tools
Hi again,
(replying to myself)
I found out the problem to my compilation issues. I did the following
change in the configure.ac (one line fix):
-PKG_CHECK_MODULES([NL], [libnl-3.0])
+PKG_CHECK_MODULES([NL], [libnl-3.0, libnl-genl-3.0])
Still, I do not know if my problem is/was Fedora/CentOS related or not.
Regards,
Tony
Le 04.04.2012 22:53, Tony Cheneau a écrit :
> Good afternoon folks,
>
> I tried compiling the lowpan-tools on Fedora 15 and CentOS 6.2
> systems
> but I
> could not pass the "./configure" step (called by autogen.sh) and I
> would be
> grateful if anyone could help me figure out why. I cloned the git
> repo
> and am
> using the latest version available at the time I write these lines
> (revision
> 6d4636d57f87a14).
>
> Here is the last lines of the output of the ./configure:
>> checking for python script directory...
>> ${prefix}/lib/python2.7/site-packages
>> checking for python extension module directory...
>> ${exec_prefix}/lib64/python2.7/site-packages
>> checking for pkg-config... /usr/bin/pkg-config
>> checking pkg-config is at least version 0.9.0... yes
>> checking for NL... yes
>> checking whether libnl requires additional libraries... failure
>> configure: error: in `/users/tcheneau/sources/linux-zigbee':
>> configure: error: failed to link program with libnl
>> See `config.log' for more details
>
> I attached the corresponding (gzip'd) config.log to this mail if it
> can help.
>
> The libnl3, as well as the corresponding development files, are
> installed on my system as shown below (output of the Fedora 15):
>> $ rpm -qa "libnl*"
>> libnl3-cli-3.2.7-1.fc15.x86_64
>> libnl3-3.2.7-1.fc15.x86_64
>> libnl3-devel-3.2.7-1.fc15.x86_64
>> libnl-1.1-14.fc15.x86_64
>
> Note that I cannot remove libnl (version 1) because it is a
> dependency
> for a lot of packages, but I do not believe it should cause any
> trouble
> (as I do not have the *-devel).
>
> I tried to modify the configure.ac file in order to remove this test.
> I
> believe this test has very small influence on the build (presence of
> the
> "-lm" flag), but I'm far from being an autotool guru, so I'm not
> certain. Basically, I commented out the following lines that made the
> "./configure" fail previously:
> AC_MSG_CHECKING([whether libnl requires additional libraries])
> _libnl_save_libs="$LIBS"
> LIBS="$NL_LIBS $LIBS"
> AC_LINK_IFELSE([AC_LANG_CALL([], [genl_connect])],
> libnl_add="none"
> ,
> libnl_add="fail")
> if test "$libnl_add" = fail
> then
> LIBS="$NL_LIBS -lm $_libnl_save_libs"
> AC_LINK_IFELSE([AC_LANG_CALL([], [genl_connect])],
> libnl_add="-lm" ,
> libnl_add="fail")
> fi
> LIBS="$_libnl_save_libs"
> if test "$libnl_add" = fail
> then
> AC_MSG_RESULT(failure)
> dnl AC_MSG_RESULT([failed])
> AC_MSG_FAILURE([failed to link program with libnl])
> else if test "$libnl_add" = none
> then
> AC_MSG_RESULT([none required])
> else
> AC_MSG_RESULT([$libnl_add])
> NL_LIBS="$NL_LIBS $libnl_add"
> fi
> fi
>
> The configure succeed, but the make fails with the following error:
>> [...]
>> Making all in src
>> make[2]: Entering directory
>> `/users/tcheneau/sources/linux-zigbee/src'
>> CC izchat.o
>> CCLD izchat
>> CC serial.o
>> CCLD izattach
>> CC izcoordinator-coordinator.o
>> CCLD izcoordinator
>> izcoordinator-coordinator.o: In function `parse_cb':
>> /users/tcheneau/sources/linux-zigbee/src/coordinator.c:185:
>> undefined
>> reference to `genlmsg_parse'
>> izcoordinator-coordinator.o: In function `coordinator_associate':
>> /users/tcheneau/sources/linux-zigbee/src/coordinator.c:116:
>> undefined
>> reference to `genlmsg_put'
>> izcoordinator-coordinator.o: In function `main':
>> /users/tcheneau/sources/linux-zigbee/src/coordinator.c:407:
>> undefined
>> reference to `genl_connect'
>> /users/tcheneau/sources/linux-zigbee/src/coordinator.c:410:
>> undefined
>> reference to `genl_ctrl_resolve'
>> izcoordinator-coordinator.o: In function `mlme_start':
>> /users/tcheneau/sources/linux-zigbee/src/coordinator.c:79: undefined
>> reference to `genlmsg_put'
>> ../lib/.libs/libcommon.a(libcommon_la-genl.o): In function
>> `family_handler':
>> /users/tcheneau/sources/linu
Re: [Linux-zigbee-devel] [PATCH] izoordinator: Fixes to error handling
Hello Alan,
Thank you for your patch. It did the trick for me. Prior to applying
the patch, izcoordinator would return instantaneously.
Regards,
Tony
Le 05.04.2012 06:28, Alan Ott a écrit :
> Some of the error handling was checking for != 0 on functions which
> returned
> positive values on success.
>
> Someone should have a look at the last one. I'm not sure what it was
> supposed to do, since it failed every single time.
>
> Signed-off-by: Alan Ott
> ---
> src/coordinator.c |8 +---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/src/coordinator.c b/src/coordinator.c
> index a09633a..fe7d092 100644
> --- a/src/coordinator.c
> +++ b/src/coordinator.c
> @@ -94,7 +94,8 @@ static int mlme_start(uint16_t short_addr, uint16_t
> pan, uint8_t channel, uint8_
> nla_put_u8(msg, IEEE802154_ATTR_COORD_REALIGN, 0);
> #endif
> int err = nl_send_auto_complete(nl, msg);
> - log_msg_nl_perror("nl_send_auto_complete", err);
> + if (err < 0)
> + log_msg_nl_perror("nl_send_auto_complete", err);
> return 0;
> }
>
> @@ -129,7 +130,8 @@ static int coordinator_associate(struct
> genlmsghdr *ghdr, struct nlattr **attrs)
>
> int err = nl_send_auto_complete(nl, msg);
>
> - log_msg_nl_perror("nl_send_auto_complete", err);
> + if (err < 0)
> + log_msg_nl_perror("nl_send_auto_complete", err);
>
> return 0;
> }
> @@ -408,7 +410,7 @@ int main(int argc, char **argv)
> log_msg_nl_perror("genl_connect", err);
>
> family = genl_ctrl_resolve(nl, IEEE802154_NL_NAME);
> - log_msg_nl_perror("genl_ctrl_resolve", NLE_NOMEM);
> + //log_msg_nl_perror("genl_ctrl_resolve", NLE_NOMEM);
>
> nl_socket_add_membership(nl, nl_get_multicast_id(nl,
> IEEE802154_NL_NAME, IEEE802154_MCAST_COORD_NAME));
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [SPAM] Status of the 6LoWPAN module in the zigbee-linux kernel tree (devel branch)
Good afternoon, I'm still trying to figure out if I have the latest version of the 6LowPAN module. I'm currently using the devel branch of the Linux Zigbee kernel (rev: 9155ba3a1c13ba, slightly patched the autofs4 files so that it compiles) and I did not managed to get the 6LoWPAN part working (izchat works great). It is crashing any of the two testbed computers each time I try to set up a 6LoWPAN network (the crash message on the console seems to be changing all the time and does not point toward any error in the 802154 or 6LoWPAN subsystem, but I'll investigate it further if needed). I've been using the serial driver (with an econotag) and the fakehard driver, both yield the same outcome: the system hangs. Here is how I reproduce the crash: > # this line is one with the serial driver > izattach /dev/ttyUSB1 > iz add wpan-phy0 > ip link set wpan0 address ca:fe:ca:fe:ca:fe:ca:fe > ifconfig wpan0 up > izcoordinator -i wpan0 -s 1 -p 777 -c 11 -l lease & > modprobe 6lowpan > ip link add link wpan0 name lowpan0 type lowpan > ip link set lowpan0 address de:ad:be:ef:ca:fe:ca:fe > ifconfig lowpan0 up At this point (ifconfig lowpan0 up), the system stops functioning and the SSH access is frozen. Perhaps there is a step that I'm missing, I do not know. But I start wondering if I am the only one experiencing this issue. Please let me know if you need more information on my system in order to help me debug them. As always, help, in any form, is greatly appreciated. Regards, Tony Cheneau -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [SPAM] Status of the 6LoWPAN module in the zigbee-linux kernel tree (devel branch)
Hi Alexander, Yes, I did read the documentation, this is how I came up with the series of command I pasted in my original mail. The documentation says: "1. Add IEEE802.15.4 interface and initialize PANid;", which I translated by: > izattach /dev/ttyUSB1 > iz add wpan-phy0 > ip link set wpan0 address ca:fe:ca:fe:ca:fe:ca:fe > ifconfig wpan0 up > izcoordinator -i wpan0 -s 1 -p 777 -c 11 -l lease & I guess it should be compatible with the use of 6LoWPAN. And then, step 2 to 4 are just copy and paste from the documentation. Could you confirm that this should work? As for the status of the Linux-zigbee kernel, there is only one change in the 6lowpan.* files: lowpan_set_address has been replaced by eth_mac_addr. I overwrote the 6lowpan.* files with the corresponding files of the mainline kernel (Linus branch), but it didn't do me any good and my laptops are still crashing when I "up" the interface. Perhaps, were you implying that some important ieee802154 files have changed as well? I'll give a try to a mainline kernel, and I'll let you know. In case you are interested, I attached after my signature the two call trace I mostly obtain when the kernel crash (perhaps depending on the other application that are running at the moment of the crash). Regards, Tony #1: Call Trace: [] ? _raw_spin_lock+0xd/0x10 [] ? sch_direct_xmit+0x47/0x180 [] ? mac802154_header_create+0x13b/0x220 [mac802154] [] ? dev_queue_xmit+0x184/0x3a0 [] ? lowpan_xmit+0x137/0x1f0 [6lowpan] [] ? netif_skb_features+0xaf/0xc0 [] ? dev_hard_start_xmit+0x228/0x4b0 [] ? dev_queue_xmit+0x184/0x3a0 [] ? update_curr+0x24e/0x2b0 [] ? update_curr+0x24e/0x2b0 [] ? enqueue_sleeper+0x1a7/0x240 [] ? enqueue_entity+0x145/0x2b0 [] ? set_next_buddy+0x35/0x40 [] ? check_preempt_wakeup+0x18e/0x220 [] ? check_preempt_curr+0x6a/0x80 [] ? ttwu_do_wakeup+0x30/0x110 [] ? try_to_wake_up+0x1cd/0x230 [] ? wake_up_process+0x14/0x20 [] ? wake_up_worker+0x1e/0x30 [] ? __queue_work+0xf3/0x3c0 [] ? mod_timer+0x134/0x260 [] ? delayed_work_timer_fn+0x26/0x30 [] ? call_timer_fn+0x2f/0xe0 [] ? irq_exit+0x59/0xc0 [] ? do_IRQ+0x4b/0xc0 [] ? _raw_spin_unlock_irq+0xd/0x20 [] ? run_timer_softirq+0x12e/0x1f0 [] ? common_interrupt+0x30/0x38 [] ? __queue_work+0x3c0/0x3c0 [] ? __do_softirq+0xf8/0x1a0 [] ? irq_enter+0x70/0x70 [] ? futex_wait+0x196/0x260 [] ? kfree_debugcheck+0x13/0x40 [] ? update_rmtp+0x80/0x80 [] ? hrtimer_start_range_ns+0x26/0x30 [] ? do_futex+0xea/0x220 [] ? sys_futex+0x6e/0x120 [] ? __audit_syscall_exit+0x386/0x3d0 [] ? sysenter_do_call+0x12/0x28 #2: Call Trace: [] ? __kfree_skb+0x3d/0x90 [] ? __kfree_skb+0x3d/0x90 [] ? tcp_data_queue+0x105/0xa40 [] ? tcp_data_snd_check+0x40/0x50 [] ? tcp_rcv_established+0x303/0x640 [] ? __inet_lookup_established+0x9d/0x2c0 [1]more> [] ? tcp_v4_do_rcv+0xed/0x1c0 [] ? _raw_spin_unlock+0xd/0x10 [] ? tcp_v4_rcv+0x53b/0x770 [] ? nf_iterate+0x63/0x90 [] ? ip_rcv+0x330/0x330 [] ? nf_hook_slow+0x62/0x110 [] ? ip_local_deliver_finish+0xa7/0x2a0 [] ? ip_local_deliver+0x7f/0x90 [] ? ip_rcv+0x330/0x330 [] ? ip_rcv_finish+0xfb/0x3c0 [] ? ip_rcv+0x25d/0x330 [] ? inet_del_protocol+0x30/0x30 [] ? __netif_receive_skb+0x1c9/0x420 [] ? netif_receive_skb+0x27/0x80 [] ? napi_skb_finish+0x37/0x50 [] ? napi_gro_receive+0x109/0x140 [] ? __alloc_skb+0x60/0x110 [] ? tg3_rx+0x71a/0x740 [tg3] [] ? alternatives_smp_module_add+0x150/0x150 [] ? tg3_poll_work+0x5a/0x140 [tg3] [] ? sch_direct_xmit+0x47/0x180 [] ? put_cred_rcu+0x67/0xa0 [1]more> [] ? _raw_spin_unlock_irq+0xd/0x20 [] ? run_timer_softirq+0x12e/0x1f0 [] ? __do_softirq+0xf8/0x1a0 [] ? irq_enter+0x70/0x70 [] ? schedule+0x35/0x50 [] ? do_syslog+0x43f/0x4b0 [] ? wake_up_bit+0x30/0x30 [] ? kmsg_poll+0x40/0x40 [] ? kmsg_read+0x30/0x70 [] ? proc_reg_read+0x66/0xa0 [] ? vfs_read+0x9f/0x170 [] ? proc_reg_write+0xa0/0xa0 [] ? sys_read+0x42/0x70 [] ? sysenter_do_call+0x12/0x28 Le 09.04.2012 21:14, Alexander Smirnov a écrit : > Hi Tony, > > First of all I'm not sure that the 6LowPAN fully merged to > linux-zigbee tree due to I worked with mainline kernel, so it may be > a > point. > > Moreover, have you red about 6lowpan in kernel documentation > (Documentation folder in sources)? Here I put some notes how to bring > up ipv6 interface. > > Please feel free to ask me. > > With best regards, > Alexander > > 9 апреля 2012 г. 23:05 пользователь Tony Cheneau > написал: >> Good afternoon, >> >> I'm still trying to figure out if I have the latest version of the >> 6LowPAN module. I'm currently using the devel branch of the Linux >> Zigbee >> kernel (rev: 9155ba3a1c13ba, slightly patched the autofs4 files so >> that >> it compiles) and I did not managed to get the
[Linux-zigbee-devel] Unreachable code in serial.c (bug?)
Hello, I was reading the drivers/ieee802154/serial.c file (in the devel branch) and found the following code to be unreachable in function ieee802154_tty_open(), near line 889: > [...] > return 0; > > ieee802154_unregister_device(zbdev->dev); > > out_free: > [...] I believe the call to ieee802154_unregister_device() should be placed after the out_free label (or else, it is never reached). Can you confirm? Regards, Tony -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] iz list command not working correctly when a lowpan0 interface exists
Hello, I noted that iz list never returns the proper result (or any result) when 6lowpan is loaded and a lowpan0 interface exists. This is true for the Linus' git tree (at least in rev:0034102808e0dbbf3a2394b82b1bb40b5778de9e, but I haven't seen any changes in the more recent revisions). Here are the steps to reproduce the "bug": > modprobe fakehard > modprobe 6lowpan > iz add wpan-phy0 > ip link set hardwpan0 address ca:fe:ca:fe:ca:fe:ca:fe > ifconfig hardwpan0 up > izcoordinator -i hardwpan0 -s 1 -p 777 -c 11 -l lease & > ip link add link hardwpan0 name lowpan0 type lowpan > ip link set lowpan0 address de:ad:be:ef:ca:fe:ca:fe > ip link set lowpan0 up > iz list I hooked a debugger to the kernel. The problem lies in the ieee802154_dump_iface() function, at the line 262: > phy = ieee802154_mlme_ops(dev)->get_phy(dev); Here, function ieee802154_mlme_ops(dev) always returns NULL, because the 6lowpan module does not register dev->ml_priv (and set ARPHRD_IEEE802154 as dev->type value). Maybe this is not the proper list to report the bug (given that the 6lowpan code is now part of the mainstream kernel). In that case, please redirect me to the proper mailing list. Please let me know if you need more details. Regards, Tony -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] Bug when setting the hop limit in 6lowpan.c
Hello,
I'm reading the 6lowpan.c file and I find the following code very odd.
I believe a bug lies in it. I cannot test at the moment because the
serial driver I plan on using does not work with the 6lowpan stack.
In lowpan_header_create(), there is the following switch (around line
495):
> switch (hdr->hop_limit) {
> case 1:
> iphc0 |= LOWPAN_IPHC_TTL_1;
> break;
> case 64:
> iphc0 |= LOWPAN_IPHC_TTL_64;
> break;
> case 255:
> iphc0 |= LOWPAN_IPHC_TTL_255;
> break;
> default:
> *hc06_ptr = hdr->hop_limit;
> break;
> }
I believe the code in the default block should be:
> default:
> *hc06_ptr = hdr->hop_limit;
> hc06_ptr += 1;
> break;
> }
Can you confirm this is indeed a bug?
Regards,
Tony
--
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] Bug when setting the hop limit in 6lowpan.c
Hi,
Here is the patch. I am not too familiar with git, so I do not know if
the patch is formatted correctly or not, if not, you can produce your
own patch and cc me.
The patch was created against the latest version of the net-next
(82981930125abfd39d7c8378a9cfdf5e1be2002b at the moment I write these
lines).
Hope it helps.
Regards,
Tony
Le 27.04.2012 09:18, Alexander Smirnov a écrit :
Hi Tony,
27 апреля 2012 г. 1:46 пользователь Tony Cheneau
написал:
Hello,
I'm reading the 6lowpan.c file and I find the following code very
odd.
I believe a bug lies in it. I cannot test at the moment because the
serial driver I plan on using does not work with the 6lowpan stack.
In lowpan_header_create(), there is the following switch (around
line
495):
switch (hdr->hop_limit) {
case 1:
iphc0 |= LOWPAN_IPHC_TTL_1;
break;
case 64:
iphc0 |= LOWPAN_IPHC_TTL_64;
break;
case 255:
iphc0 |= LOWPAN_IPHC_TTL_255;
break;
default:
*hc06_ptr = hdr->hop_limit;
break;
}
I believe the code in the default block should be:
default:
*hc06_ptr = hdr->hop_limit;
hc06_ptr += 1;
break;
}
Can you confirm this is indeed a bug?
yeah, it seems you are right! thanks for the finding..
BTW: are you going to make a patch? Or I can do it (with you in cc)
and sent with my next set.
With best regards,
Alex
Regards,
Tony
--
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
From 40b6fa4495a1775fa1825b37fc19cf51e991cc13 Mon Sep 17 00:00:00 2001
From: Tony Cheneau
Date: Fri, 27 Apr 2012 10:26:08 -0400
Subject: [PATCH] 6lowpan: fixes a bug in lowpan_header_create(). If the hop
limit value was not 1, 64 or 255, the value would not have
been set correctly.
---
net/ieee802154/6lowpan.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 4b5701c..9f6d6d7 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -490,6 +490,7 @@ static int lowpan_header_create(struct sk_buff *skb,
break;
default:
*hc06_ptr = hdr->hop_limit;
+ hc06_ptr += 1;
break;
}
--
1.7.6.5
--
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] [PATCH 2/2] net/ieee802154/6lowpan.c: reuse eth_mac_addr()
Hello,
I believe the following patch should not have been applied and should
now be reverted.
The reason is because eth_mac_addr() is not functionally equivalent to
lowpan_set_address() that it replaces:
- lowpan_set_address() copies dev->addr_len bytes, where dev->addr_len
is set to 8 bytes for IEEE802154 devices (this is an IEEE EUI-64
address). Hence, the function copies the full 8 bytes of the address.
- eth_mac_addr() copies ETH_ALEN bytes, where ETH_ALEN is set to 6.
Hence, the function copies only 6 bytes of the 8 bytes address. So, 2
bytes of the address are never copied.
Does this sound reasonable?
Regards,
Tony
Le 22.02.2012 14:36, Danny Kukawka a écrit :
> Use eth_mac_addr() for .ndo_set_mac_address, remove
> lowpan_set_address since it do currently the same as
> eth_mac_addr(). Additional advantage: eth_mac_addr() already
> checks if the given address is valid
>
> Signed-off-by: Danny Kukawka
> ---
> net/ieee802154/6lowpan.c | 16 ++--
> 1 files changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
> index e4ecc1e..3685158 100644
> --- a/net/ieee802154/6lowpan.c
> +++ b/net/ieee802154/6lowpan.c
> @@ -55,6 +55,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -924,19 +925,6 @@ drop:
> return -EINVAL;
> }
>
> -static int lowpan_set_address(struct net_device *dev, void *p)
> -{
> - struct sockaddr *sa = p;
> -
> - if (netif_running(dev))
> - return -EBUSY;
> -
> - /* TODO: validate addr */
> - memcpy(dev->dev_addr, sa->sa_data, dev->addr_len);
> -
> - return 0;
> -}
> -
> static int lowpan_get_mac_header_length(struct sk_buff *skb)
> {
> /*
> @@ -1062,7 +1050,7 @@ static struct header_ops lowpan_header_ops = {
>
> static const struct net_device_ops lowpan_netdev_ops = {
> .ndo_start_xmit = lowpan_xmit,
> - .ndo_set_mac_address= lowpan_set_address,
> + .ndo_set_mac_address= eth_mac_addr,
> };
>
> static void lowpan_setup(struct net_device *dev)
--
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
[Linux-zigbee-devel] Bug in 6lowpan 16-bit short address detection code
Hello, Last week, I was analyzing some 6lowpan packet with Wireshark and got notified by the tool that the checksum (TCP, UDP or ICMPv6) was wrong. Some investigations showed me that this issue has been discussed and solved in Contiki, as pointed out in the following thread: http://comments.gmane.org/gmane.os.contiki.devel/7053 In my case, the issue was triggered by the format of the address I assigned to my nodes. They were assigned with addresses fe80::1 and fe80::2 and the 6lowpan code wrongly interpreted them as being 16-bit short address mapped an EUI-64 address (although the ff:fe part was missing). It turns out that the lowpan_is_iid_16_bit_compressable macro in net/ieee802154/6lowpan.h is not correct and does not behave according to RFC6282. I attached a patch that intend to correct this behavior. Regards, Tony From 84a884346b175d2c2890249d122e2f34735d433a Mon Sep 17 00:00:00 2001 From: Tony Cheneau Date: Thu, 17 May 2012 17:13:06 -0400 Subject: [PATCH 1/1] lowpan_is_iid_16_bit_compressable() would not detect compressable address correctly (at least, not in a RFC6282 compliant way). This issue has been witnessed and solved in the past in Contiki. This patch is basicaly a port of their fix. --- net/ieee802154/6lowpan.h | 16 +--- 1 files changed, 9 insertions(+), 7 deletions(-) diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h index 8c2251f..9aa3c41 100644 --- a/net/ieee802154/6lowpan.h +++ b/net/ieee802154/6lowpan.h @@ -87,14 +87,16 @@ #define is_addr_link_local(a) (((a)->s6_addr16[0]) == 0x80FE) /* - * check whether we can compress the IID to 16 bits, - * it's possible for unicast adresses with first 49 bits are zero only. - */ +* check whether we can compress the IID to 16 bits, +* it's possible for unicast adresses with first 49 bits are zero only. +*/ #define lowpan_is_iid_16_bit_compressable(a) \ - a)->s6_addr16[4]) == 0) && \ -(((a)->s6_addr16[5]) == 0) && \ -(((a)->s6_addr16[6]) == 0) && \ -a)->s6_addr[14]) & 0x80) == 0)) +a)->s6_addr16[4]) == 0) && \ + (((a)->s6_addr[10]) == 0)&& \ + (((a)->s6_addr[11]) == 0xff)&&\ + (((a)->s6_addr[12]) == 0xfe)&&\ + (((a)->s6_addr[13]) == 0)) + /* multicast address */ #define is_addr_mcast(a) (((a)->s6_addr[0]) == 0xFF) -- 1.7.6.5 -- 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
[Linux-zigbee-devel] Bug in 6lowpan when uncompressing UDP datagram
Hello again,
When running some connectivity tests, I discovered that UDP
communication would not work between my nodes. Looking at the various
printk() in the kernel, I found out that the IPv6 next header field is
not set (set to 0) upon decompression and thus prevented correct
processing of the decompressed packet at the upper layer (IPv6 layer).
When the next header is UDP, IPHC next header compression applies (as
defined in Section 4.1 of RFC6282). The compression code in 6lowpan.c
seems to behave correctly. However, upon decompression code (in
lowpan_process_data()) fails to properly restore/set the next header
field.
I attached a (very small) patch for this issue to this mail. It works
in my configuration and enables the two nodes to communicate. I do not
believe it will introduce any side-effects.
Regards,
TonyFrom d3a296699f98a74b560476e3b5baa53aec13302a Mon Sep 17 00:00:00 2001
From: Tony Cheneau
Date: Mon, 21 May 2012 14:40:24 -0400
Subject: [PATCH 1/1] Next header was not properly set upon decompression of
a UDP header.
---
net/ieee802154/6lowpan.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 34c7dda..079b0e7 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -936,8 +936,12 @@ lowpan_process_data(struct sk_buff *skb)
/* UDP data uncompression */
if (iphc0 & LOWPAN_IPHC_NH_C)
+{
if (lowpan_uncompress_udp_header(skb))
goto drop;
+ hdr.nexthdr = UIP_PROTO_UDP;
+}
+
/* Not fragmented package */
hdr.payload_len = htons(skb->len);
--
1.7.6.5
--
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
[Linux-zigbee-devel] Is 6lowpan fragmentation working?
Hello, I'm currently playing with the 6lowpan code and was wondering if the fragmentation support is supposed to be operational. The reason I ask is because when my packets grow too big (when fragmentation should kick in), my communications stop working. I sniffed the traffic with Wireshark, and found out the first fragment (FRAG1) is always 25 bytes long and does not contain any payload. A quick look at the code seems to confirm that the first fragment carries no payload (see lowpan_skb_fragmentation()). I fail to see where RFC 4944 indicates that the first fragment should be empty (and I fail to see what would be the benefit of this behavior anyway). So, is that the intended behavior? Did I miss something? Either way, I'll look more into it, maybe this is only specific to my system (I ported the serial driver and applied some patches to it, so the packets might be mangled somewhere else). Thank you in advance. Regards, Tony -- 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
[Linux-zigbee-devel] Results of a small experiment: improve serial driver latency by increasing the baud rate (with econotags)
Good afternoon, By default, the Econotag and izattach (part of the linux-zigbee userspace tools) expects the communications to run at 115200 bps. I wanted to know of it was affecting the performances, so I tried different values (by recompiling the firmware and the tools accordingly). I was mainly interested in reducing latency, this is why I exclusively used ping6 for my tests, but I guess the throughput should improve as well. Here is the average round-trip time reported by ping6 between two nodes: - at 115200 bps: ~ 400ms - at 921600 bps: ~ 20ms (yes , 20 times faster) - at 1843200 bps (maximum baudrate supported by the econotag): ~ 20 ms (same number as above) As a side note, 1843200 bps is not a "standard" baud rate supported by the Linux kernel, which make it more complex to set on the software side. Given that there is not performance gain compared to 921600 bps, there seem to be no benefit in using this baud rate (but I might be wrong). I do not believe my changes should make it to the kernel (some serial devices might still need to operate at 115200), but I can post my patches if people are interested. Regards, Tony -- 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
[Linux-zigbee-devel] Bugfixes for 6lowpan
Hello,
While playing with the 6lowpan code, I found a few more bugs. Some a
not very serious as long as interoperability is not required, some other
are more serious and prevent the fragment reassembly to be performed
correctly (after 256 fragments have been sent) or mangle the packet
length field.
I attached a patch to this mail. I hope it applies correctly, as I'm
also modifying the code so that it behaves as described in the RFC (see
my previous mail).
Please let me know what you think, and if you need more details.
Regards,
TonyFrom e15083579d7e2b853aa022c4b84edbd091644cbd Mon Sep 17 00:00:00 2001
From: Tony Cheneau
Date: Tue, 5 Jun 2012 17:26:54 -0400
Subject: [PATCH 1/1] Fixes various u8/u16 storage/usage bugs in the 6lowpan
code: - tag would not be passed down correctly in
lowpan_alloc_new_frame() (pass down a u16 to the
function when it only accepts a u8) -
lowpan_skb_fragmentation() and lowpan_fetch_skb_u16()
would not store/retrieve the data correctly -
lowpan_process_data() and lowpan_alloc_new_frame():
frame length would get corrupted
---
net/ieee802154/6lowpan.c | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 245d765..c9428b9 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -313,7 +313,7 @@ static inline int lowpan_fetch_skb_u16(struct sk_buff *skb,
u16 *val)
if (WARN_ON_ONCE(!pskb_may_pull(skb, 2)))
return -EINVAL;
- *val = skb->data[0] | (skb->data[1] << 8);
+ *val = (skb->data[0] << 8) | skb->data[1];
skb_pull(skb, 2);
return 0;
@@ -660,7 +660,7 @@ static void lowpan_fragment_timer_expired(unsigned long
entry_addr)
}
static struct lowpan_fragment *
-lowpan_alloc_new_frame(struct sk_buff *skb, u8 iphc0, u8 len, u8 tag)
+lowpan_alloc_new_frame(struct sk_buff *skb, u16 len, u16 tag)
{
struct lowpan_fragment *frame;
@@ -671,7 +671,7 @@ lowpan_alloc_new_frame(struct sk_buff *skb, u8 iphc0, u8
len, u8 tag)
INIT_LIST_HEAD(&frame->list);
- frame->length = (iphc0 & 7) | (len << 3);
+ frame->length = len;
frame->tag = tag;
/* allocate buffer for frame assembling */
@@ -729,14 +729,15 @@ lowpan_process_data(struct sk_buff *skb)
case LOWPAN_DISPATCH_FRAGN:
{
struct lowpan_fragment *frame;
- u8 len, offset;
- u16 tag;
+ u8 slen, offset = 0; /* slen is short length */
+ u16 len, tag;
bool found = false;
- if (lowpan_fetch_skb_u8(skb, &len) || /* frame length */
+ if (lowpan_fetch_skb_u8(skb, &slen) || /* 8 LSB of frame length
*/
lowpan_fetch_skb_u16(skb, &tag)) /* fragment tag */
goto drop;
+len = ((iphc0 & 7) << 8) | slen; /* adds the 3 MSB to the 8 LSB to
obtain the 11 bits length */
/*
* check if frame assembling with the same tag is
* already in progress
@@ -751,7 +752,10 @@ lowpan_process_data(struct sk_buff *skb)
/* alloc new frame structure */
if (!found) {
- frame = lowpan_alloc_new_frame(skb, iphc0, len, tag);
+#ifdef DEBUG
+printk(KERN_DEBUG "%s first fragment received for tag %d, begin packet
reassembly", __func__, tag);
+#endif /* DEBUG */
+ frame = lowpan_alloc_new_frame(skb, len, tag);
if (!frame)
goto unlock_and_drop;
}
@@ -1014,10 +1018,10 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
tag = fragment_tag++;
/* first fragment header */
- head[0] = LOWPAN_DISPATCH_FRAG1 | (payload_length & 0x7);
- head[1] = (payload_length >> 3) & 0xff;
- head[2] = tag & 0xff;
- head[3] = tag >> 8;
+ head[0] = LOWPAN_DISPATCH_FRAG1 | ((payload_length >> 8) & 0x7);
+ head[1] = payload_length & 0xff;
+ head[2] = tag >> 8;
+ head[3] = tag & 0xff;
err = lowpan_fragment_xmit(skb, head, header_length, 0, 0);
--
1.7.6.5
--
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
[Linux-zigbee-devel] [PATCH net-next 0/4] 6lowpan: set of bug fixes
Hello,
(This is my first time submitting patches. If I fail to apply to
some rules in here, please let me know)
After reading the 6lowpan code, I found a few issues. This patchset
fixes them. This patchset should apply cleanly against the current
net-next. It contains only bug fixes, I'll send later on a few other
patches that will offer new functionalities.
This is a set of 4 small patches that correct bugs in 6lowpan:
- patch 1 fixes a potential crash when reassembling UDP fragments
- patch 2 fixes a type issues that prevent the fragmentation reassembly
to operate properly.
- patch 3 and 4 corrects field encoding issues
Hope it helps.
Regards,
Tony Cheneau
--
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] [PATCH net-next 0/4] 6lowpan: set of bug fixes
Hello, As Jan pointed out, it seems that the third patch of my patchset is not formatted properly. Moreover, I got my own email address wrong. Please disregard the whole patchset as I need to investigate the issue. I'll repost the complete patchset when it will be resolved. I'm sorry if it caused any of you to waste your time on it. Regards, Tony Le 11.06.2012 06:37, Tony Cheneau a écrit : > Hello, > > (This is my first time submitting patches. If I fail to apply to > some rules in here, please let me know) > > After reading the 6lowpan code, I found a few issues. This patchset > fixes them. This patchset should apply cleanly against the current > net-next. It contains only bug fixes, I'll send later on a few other > patches that will offer new functionalities. > > This is a set of 4 small patches that correct bugs in 6lowpan: > - patch 1 fixes a potential crash when reassembling UDP fragments > - patch 2 fixes a type issues that prevent the fragmentation > reassembly > to operate properly. > - patch 3 and 4 corrects field encoding issues > > Hope it helps. > > Regards, > Tony Cheneau > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] [PATCH net-next 3/4] 6lowpan: the two bytes of u16 tag needs to be stored/accessed the other way around
Hello Alexander, Please see my response inline. Le Tue, 12 Jun 2012 22:07:12 +0400, Alexander Smirnov a écrit : > 2012/6/11 Tony Cheneau : > > Or else, tag values, as displayed with a trafic analyser, such a > > Wireshark, are not properly displayed (e.g. 0x01 00 insted of 0x00 > > 01, and so on). --- > > net/ieee802154/6lowpan.c | 6 +++--- > > 1 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c > > index af4f29b..af2f12e 100644 > > --- a/net/ieee802154/6lowpan.c > > +++ b/net/ieee802154/6lowpan.c > > @@ -307,7 +307,7 @@ static u16 lowpan_fetch_skb_u16(struct sk_buff > > *skb) > > > > BUG_ON(!pskb_may_pull(skb, 2)); > > > > - ret = skb->data[0] | (skb->data[1] << 8); > > + ret = (skb->data[0] << 8) | skb->data[1]; > > This function aimed to obtain u16 from skb, why did you change the > byte-order here instead of 'tag' variable byte-shifting? This probably reflects my lack of practice in writing/reading network code. I witnessed in my network that the byte order was wrong when sending/receiving packet (using Wireshark) and though it would be a quick fix. Also, I assumed skb->data would store data using network ordering, so that skb->data[0] would have been the MSB and skb->data[1] would have been the LSB. I'll look more into that. > Will this > code work properly on the both little and big-endian machines? I haven't checked that. But, just for clarification, if my changes are not working properly on both architectures, it means that the original code doesn't either, right? > Please > rework this to keep order properly for all the architectures. I will read some more network code to see how it is handled in other part of the kernel and rewrite the patch accordingly (if at all needed). Thank you for your advises. > > skb_pull(skb, 2); > > return ret; > > } > > @@ -1002,8 +1002,8 @@ lowpan_skb_fragmentation(struct sk_buff *skb) > > /* first fragment header */ > > head[0] = LOWPAN_DISPATCH_FRAG1 | (payload_length & 0x7); > > head[1] = (payload_length >> 3) & 0xff; > > - head[2] = tag & 0xff; > > - head[3] = tag >> 8; > > + head[2] = tag >> 8; > > + head[3] = tag & 0xff; > > > > err = lowpan_fragment_xmit(skb, head, header_length, 0, 0); > > > > -- > > 1.7.3.4 > > > > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Regards, Tony -- 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] [PATCH net-next 4/4] 6lowpan: len field is not stored and accessed properly
Hi again,
Thank you for your comment. See my answer inline.
Le Tue, 12 Jun 2012 22:20:13 +0400,
Alexander Smirnov a écrit :
> 2012/6/11 Tony Cheneau :
> > Lenght field should be encoded (and accessed) the other way around.
> > As it is currently written, it could lead to interroperability
> > issues.
>
> What kind of "interroperability issues" can occur? Please describe it
> in details, I can't read your mind. And again, can these problems be
> caused by the byte-order mismatch?
Sorry if I wasn't clear. Yes, I believe it is a byte-order mismatch.
I wasn't able to verify interoperability with other implementations
myself, but I compared with some packet capture I obtained from some
other implementations, where the byte-order was different. I'll double
check that when I'll have access to my lab again.
The reason I choose the term "interoperability issues" is that this
patch focuses on the length field where patch 3 focused on the tag
field. If you encode the tag field incorrectly, it is not a big deal,
because the recipient will decode wrongly, but all fragment of a same
packet will share a same tag (regardless of you decode it properly or
not). However, when the same thing happen with the length field, if you
endianness is wrong, the recipient will interpret a totally different
length and will reserve a wrong amount of memory in order to store the
packet (this is mainly a matter of concern if you are performing
fragment reassembly and do not allocate enough memory for the complete
frame). Do that make sense?
Just like the previous patch, I'll rework it as well.
As a side note, do you have any opinions on the first two patches
Regards,
Tony
> >
> > Also, I rewrote the code so that iphc0 argument of
> > lowpan_alloc_new_frame could be removed.
> > ---
> > net/ieee802154/6lowpan.c | 20
> > 1 files changed, 12 insertions(+), 8 deletions(-)
> >
> > diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
> > index af2f12e..b400156 100644
> > --- a/net/ieee802154/6lowpan.c
> > +++ b/net/ieee802154/6lowpan.c
> > @@ -654,7 +654,7 @@ static void
> > lowpan_fragment_timer_expired(unsigned long entry_addr) }
> >
> > static struct lowpan_fragment *
> > -lowpan_alloc_new_frame(struct sk_buff *skb, u8 iphc0, u8 len, u16
> > tag) +lowpan_alloc_new_frame(struct sk_buff *skb, u16 len, u16 tag)
> > {
> > struct lowpan_fragment *frame;
> >
> > @@ -665,7 +665,7 @@ lowpan_alloc_new_frame(struct sk_buff *skb, u8
> > iphc0, u8 len, u16 tag)
> > INIT_LIST_HEAD(&frame->list);
> >
> > - frame->length = (iphc0 & 7) | (len << 3);
> > + frame->length = len;
> > frame->tag = tag;
> >
> > /* allocate buffer for frame assembling */
> > @@ -721,13 +721,17 @@ lowpan_process_data(struct sk_buff *skb)
> > case LOWPAN_DISPATCH_FRAGN:
> > {
> > struct lowpan_fragment *frame;
> > - u8 len, offset;
> > - u16 tag;
> > + /* slen stores the rightmost 8 bits of the 11 bits
> > length */
> > + u8 slen, offset;
> > + u16 len, tag;
> > bool found = false;
> >
> > - len = lowpan_fetch_skb_u8(skb); /* frame length */
> > + slen = lowpan_fetch_skb_u8(skb); /* frame length */
> > tag = lowpan_fetch_skb_u16(skb);
> >
> > + /* adds the 3 MSB to the 8 LSB to retrieve the 11
> > bits length */
> > + len = ((iphc0 & 7) << 8) | slen;
> > +
> > /*
> > * check if frame assembling with the same tag is
> > * already in progress
> > @@ -742,7 +746,7 @@ lowpan_process_data(struct sk_buff *skb)
> >
> > /* alloc new frame structure */
> > if (!found) {
> > - frame = lowpan_alloc_new_frame(skb, iphc0,
> > len, tag);
> > + frame = lowpan_alloc_new_frame(skb, len,
> > tag); if (!frame)
> > goto unlock_and_drop;
> > }
> > @@ -1000,8 +1004,8 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
> > tag = fragment_tag++;
> >
> > /* first fragment header */
> > - head[0] = LOWPAN_DISPATCH_FRAG1 | (payload_length & 0x7);
> > - head[1] = (payload_length >> 3) & 0xff;
> > + head[0] = LOWPAN_DISPATCH_FRAG1 | ((payload_length >> 8) &
[Linux-zigbee-devel] Simplifying/extending of the serial protocol?
Good afternoon, I'm currently working on improving/cleaning the serial driver [1] which implement the serial protocol [2] on some Econotag board. During this work, a few question and comments popped to my mind, and I believe this ML is the proper place to foster a interesting conversation. First, I'm wondering if the Econotag is the only board that relies on the serial protocol. The linux-zigbee wiki mentions the "MC13192 eval. boards", but I do not know how widely that is used and if the firmware part can be modified (in case there is some changes to the serial protocol). Secondly, I'm wondering if there would be room (and interests of the community) in a serial protocol v2 (more about this below). The way, I see it, there is some limitations in the current protocol and, I believe some improvements could be done on both driver and firmware sides. If only the Econotag is using the serial driver, then it does not cost much to modify the serial protocol, because the firmware can easily be modified as well. If other devices make use of this code, then it might be more problematic. For example, the CCA command is not very useful (IMHO), because some timing requirements can never be met: If I look at the current serial.c code, in order to send a packet I would: - run a CCA - wait for the status of the CCA (not implemented in the Econotag, so it always returns OK) - send my packet to the board By doing this, it seems hard to respect the CCA timing at all (assuming the link to the board is running at 115200 bauds), because: - 4 bytes for the CCA response: ~ 34 us - 80 bytes for a transmission block packet (for a 76 bytes long packet): ~ 694us The time it takes after a successful CCA to get the board to actually try to send the packet is way more that the CCA + Turnaround time (8 + 12 symbols or 128 + 192 us) in the protocol. For example, in this case, I suggest a simplification of the protocol. That is the CCA command is removed and is instead placed within the firmware, at the beginning the "Transmit Block" command. In the case of the Econotag, CCA is not implemented anyway so that would not make any difference. Another example, this time, to introduce a new feature: automatic hardware acknowledgment. In order to make use of the auto-acknowledgment feature (which I implemented on the Econotag linux serial firmware), I propose three new commands (and the corresponding responses): - set PANID - set short address - set 64-bit address In the end, I came up with a list of changes I'd like to see in the serial protocol/serial driver: - remove Set State command (not needed, device is always receiving, except when it's trying to send; the device can take care of changing the mode by itself) - remove CCA command (included in the Transmit Block, that should do a full CSMA-CA if possible) - add a Set PANID command (MAC filtering/auto-ack feature) - add a Set short address command (MAC filtering/auto-ack feature) - add a Set long address command (MAC filtering/auto-ack feature) - a return status that say the command is not implemented I might be completely off, that's why I'm trying to get others people opinion here. Ultimately, my questions are: would anyone be interested in seeing these kind of changes? Would it make sense for me to contribute these changes once I've done them? Regards, Tony [1]: the one in drivers/ieee802154/serial.c [2]: http://sourceforge.net/apps/trac/linux-zigbee/wiki/SerialV1 -- 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] Getting started with the linux zigbee stack
Hi Christian, I had the exact same problem before. Currently, the net-next kernel does not fill struct ieee802154_mlme_ops mac802154_mlme_wpan completely (in net/mac802154/mac_cmd.c). The current code does not set the assoc_req member to a function (hence, it remains NULL). When trying to send association request (and I believe association response), it produces a NULL pointer dereference. You may work around this problem, like I did, by not using iz assoc to build your kernel. You can use exclusively izcoordinator instead (which make no use of the association messages). Here is how I set up my network on two different nodes: - on node 1: izcoordinator -d 1 -l lease -i wpan0 -p 0x777 -s 1 -c 11 [... 6lowpan stuffs ...] - on node 2: izcoordinator -d 1 -l lease -i wpan0 -p 0x777 -s 2 -c 11 [... 6lowpan stuffs ...] The documentation you pointed out works for the linux-zibgee and may not apply entirely to the linux net-next (yet). You may want to have a look at [1], which is more recent (see how it carefully not use iz assoc). Hope it helps. Regards, Tony [1]: https://code.google.com/p/linux-wsn/wiki/LinuxStart Le Fri, 27 Jul 2012 13:26:43 +0200, Christian Groeger a écrit : > Hi everyone, > > what do I need to do to get the IEEE802.15.4 and 6LoWPAN stack > working on my computer? I built the net-next kernel [1] with all the > drivers compiled as modules and the linux-zigbee userspace tools [2]. > Everything compiles without errors. > > Then I more or less follow the Getting started guide in your wiki > [3], I use the fakelb driver for testing. Everything seems to work > fine, I bring up my wpan0 interface and see a "ieee802154fakelb: > added ieee802154 hardware" in the kernel log. > > Then I try an 'iz assoc', which is killed immediately and I get a > kernel oops in the kernel logfile (see below for logfile). > > Can anyone help get this working? > > Thanks. > > [1] > http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=tree > [2] > http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/linux-zigbee;a=summary > [3] > http://sourceforge.net/apps/trac/linux-zigbee/wiki/GettingStarted-0.2 > > > > [ 199.830666] BUG: unable to handle kernel NULL pointer dereference > at (null) > [ 199.830677] IP: [< (null)>] (null) > [ 199.830686] PGD 1d2cb067 PUD 1d3cc067 PMD 0 > [ 199.830691] Oops: 0010 [#1] SMP > [ 199.830695] Modules linked in: fakelb mac802154 ieee802154 > crc_ccitt joydev ppdev microcode snd_intel8x0 psmouse snd_ac97_codec > ac97_bus serio_raw snd_pcm hid_generic i2c_piix4 snd_timer parport_pc > snd soundcore mac_hid snd_page_alloc lp parport usbhid hid e1000 > [ 199.830719] CPU 0 > [ 199.830724] Pid: 1162, comm: iz Not tainted > 3.5.0-net-next-next-20120726+ #3 innotek GmbH VirtualBox > [ 199.830729] RIP: 0010:[<>] [< > (null)>] (null) > [ 199.830733] RSP: 0018:88001d2579b0 EFLAGS: 00010246 > [ 199.830736] RAX: a0138000 RBX: 88001c2c5000 RCX: > > [ 199.830739] RDX: 000b RSI: 88001d2579c0 RDI: > 88001c2c5000 > [ 199.830743] RBP: 88001d2579f8 R08: 008a R09: > 88001d25798f > [ 199.830746] R10: R11: 0246 R12: > 88001d2579c0 > [ 199.830749] R13: 88001d257a18 R14: 88001cc23e00 R15: > 81caa6c0 > [ 199.830758] FS: 7fd84e5e5700() GS:88001fc0() > knlGS: > [ 199.830763] CS: 0010 DS: ES: CR0: 80050033 > [ 199.830766] CR2: CR3: 1d5b7000 CR4: > 06f0 > [ 199.830775] DR0: DR1: DR2: > > [ 199.830779] DR3: DR6: 0ff0 DR7: > 0400 > [ 199.830783] Process iz (pid: 1162, threadinfo 88001d256000, > task 88001d3d5b40) > [ 199.830787] Stack: > [ 199.830789] a0128648 88001d2579c8 000107770002 > 88001d2579e8 > [ 199.830795] 42cd25bf a012c000 a012c100 > a012c000 > [ 199.830800] 88001f20b414 88001d257aa8 815822da > 8814 > [ 199.830806] Call Trace: > [ 199.830814] [] ? > ieee802154_associate_req+0xd8/0x150 [ieee802154] > [ 199.830823] [] genl_rcv_msg+0x21a/0x2b0 > [ 199.830828] [] ? __alloc_skb+0x8b/0x2a0 > [ 199.830833] [] ? genl_rcv+0x40/0x40 > [ 199.830838] [] netlink_rcv_skb+0xa9/0xd0 > [ 199.830842] [] genl_rcv+0x25/0x40 > [ 199.830846] [] netlink_unicast+0x1ad/0x230 > [ 199.830851] [] netlink_sendmsg+0x2b6/0x310 > [ 199.830856] [] sock_sendmsg+0xdc/0xf0 > [ 199.830861] [] ? move_addr_to_kernel+0x5a/0xa0 > [ 199.830865] [] __sys_sendmsg+0x38c/0x3a0 > [ 199.830871] [] ? handle_mm_fault+0x259/0x340 > [ 199.830877] [] ? krealloc+0x1b/0x60 > [ 199.830883] [] ? do_page_fault+0x210/0x520 > [ 199.830888] [] ? __wake_up+0x53/0x70 > [ 199.830893] [] sys_sendmsg+0x49/0x90 > [ 199.830898] [
Re: [Linux-zigbee-devel] [mc1322x] Econotag Linux 802.15.4 issues
Hi all, (Just answering to that last mail quickly, and I'll come back to the other ones when I'll have more time.) I found out that the baudrate is very important when experimenting with the Econotag (I wrote about that on the zigbee list a few months ago). A ping6 (on a heavily patched kernel) would initially take me around 400ms at 115200 bps. At 926000, it takes me around 20ms (agreed, there might have been something else wrong before). As a side note, when doing a lot of exchanges between devices running at 926000, one has to be careful about having the rftest-rx firmware used for sniffing being built at 926000 bps too, or else some packets won't get through and the packet capture will not reflect what is actually sent. However, the rftestrx2pcap.py throw an exception pretty quickly at this speed (I'll need to find out why exactly and fix it). Regards, Tony Le 02.08.2012 22:04, David Kopf a écrit : > Is there any difference between 115200 and 921600 baud? If using flow > control, does it hang in interrupt when the output buffer is full? > The econotag can send packets very rapidly if the tx queue is used, > not leaving enough time for the receiver to unload the fifo. The > standard for long interframe spacing is 640 usec; accumulate the > minimum difference between tx's using the mac clock and subtract the > RF time to see what is the LIFS. > > > -Original Message- From: Alan Ott > Sent: Thursday, August 02, 2012 3:22 PM > To: Mariano Alvira ; Tony Cheneau > Cc: mc13...@devl.org ; Alexander Smirnov ; > linux-zigbee-devel@lists.sourceforge.net > Subject: [mc1322x] Econotag Linux 802.15.4 issues > > Hello, > > I have an Econotag that I'm running with the linux802154-serialdev[1] > firmware and using the serial.c driver from the linux-zigbee[2] > project. > I'm running the latest kernel (linux-next, with serial.c manually > ported > over). I've also run with the 3.3-rc5[2] kernel (+patches) which is > hosted at the linux-zigbee[2] project. > > I'm currently able to talk between two systems, one system with the > Econotag and serial.c, and the other system with an MRF24J40 and a > driver I wrote[3] and am trying to test. I can ping6 between the two > systems with high reliability, but there seems to be trouble when > packets are sent too quickly from the Econotag. For example, if I > change > the ping interval (-i) to 0.1, most of the packets get lost. An > interval > of 0.2 works fine though. This issue also seems to present itself > when > sending real 6lowpan traffic, such as using ssh. I am completely > unable > to ssh between the two systems, and wireshark of wpan0 on the > Econotag > PC shows a lot of retransmission-related packets. > > I put in some printk()'s and found that sometimes the > ieee802154_serial_xmit() function returns -110 (-ETIMEDOUT). It > doesn't > seem like that happens as often as packets are lost though. I need to > investigate further to find out which command is failing and when. > > The above is all with the linux-next kernel using the instructions at > [4]. However, I also noticed some dropping of packets when using the > linux-zigbee kernel[2] and izchat[5] if I typed and hit enter really > quickly a few times from the Econotag PC. > > My question is, have any of you done any stress testing with the > Econotag, the linux802154-serialdev firmware, and serial.c using a > protocol analyzer or other method? Do any of you have 6lowpan working > with the Econotag in this configuration (with linux802154-serialdev)? > > I'm not trying to point fingers. I'm just in a situation where I have > too many unknowns, and I'm trying to make sense of it. The issue > could > very well be on my side. I do however have some things which could > possibly to point to Econotag firmware/driver issues, and I'd like to > know what experiences others have had with this configuration. > > Thanks, > > Alan. > > [1] http://mc1322x.devl.org/linux802154-serialdev.html > [2] > > http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=summary > [3] http://permalink.gmane.org/gmane.linux.network.zigbee.devel/1135 > [4] http://code.google.com/p/linux-wsn/wiki/Mainline > [5] > http://sourceforge.net/apps/trac/linux-zigbee/wiki/GettingStarted-0.2 > > > ___ > mc1322x mailing list > mc13...@devl.org > http://devl.org/cgi-bin/mailman/listinfo/mc1322x -- 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. Disc
Re: [Linux-zigbee-devel] [mc1322x] Econotag Linux 802.15.4 issues
Hi Alan, See my response inline. > I haven't changed the baud rate (so it's 115200), and my pings are > certainly not 400ms, so I'm not seeing that issue (whatever it > is/was). I'm not too certain that the baudrate gave a 20 times performance increase. However, I believe that a 115200 bps baudrate to transfer data to and from a 250kbps radio can be a bottleneck (and I clearly see it when my capturing device is set to only 115200 bps). > Another quick question... When you do a wireshark of something with > 6lowpan fragmentation, are you getting malformed packet errors for > the > first packet? I'm trying to decide whether this is something that > could > hold me up, or whether it's a wireshark issue with 6lowpan. I > uploaded a > capture file[1] from my embedded board. :1 is the PC with econotag > and > :2 is the embedded board with mrf24j40. As you can see, not all the > packets are making it through. I'll do some testing with the rftest > tools. The current 6lowpan code for the first fragment is wrong (i.e. it should be more that 25 bytes or so). When I dug in the source code, I found out that the first fragment is always empty (i.e. no payload). I fixed that, but I haven't found the time to release a patch yet. I'm sorry about that. However, in my initial test, without the fix, I could still manage to log into SSH (sporadically, due to a failing serial driver). > This example capture [2] shows an HC1 header (for example, packet 4) > that we don't have, but my quick look at the 6lowpan RFC hasn't been > able to convince me that it's required in any way. Like I said, it > could > be a Wireshark issue. HC1 header is required in order to "compress" the IPv6 header (from 40 bytes to something like 20 bytes in your case). It saves bandwidth and prevent the need for fragmentation. This is not required so to speak, but your packet go through the 6lowpan module, they will have the HC1 compression applied to them. While I'm at it, you might find this kind of issues as you play with the linux net-next kernel: - crash due to memory allocation in 6lowpan: on "my" kernel, I changed the kzalloc() call from GFP_KERNEL to GFP_ATOMIC. The backtrace was not always useful as it would point to random network code. - the serial driver itself has some bugs (in the linux-zigbee tree). Some patches sent to linux-zigbee mailing list were never applied. - during packet burst, packets can be sent in the wrong order: this is due to the way the queue was implemented in the MAC layer (net/mac802154/tx.c): if the device is busy, the packet is rescheduled to be send, but at the end of the queue. - UDP header compression is broken: the header is compressed correctly, however both compressed and uncompressed header are sent on the air. Because the code is broken on the sender and the receiver, it still works. I have a patch for that (saves a few bytes in the packet). You currently don't have L2 acknowledgment with the current Econotag firmware. I need to release my "additions": I enabled auto-ack in my firmware and go it to work between two devices. It requires modification in the 6lowpan and the MAC codes as well (so that the ACK flag can be passed down). I plan on releasing all of that, but I've been pretty busy lately. Besides, some code needs to be cleaned and cannot be released as is (e.g. I implemented a reset mechanism on the serial driver to reset the econotag when it stops responding, this is not needed anymore because the bug has since then been fixed in the firmware). Regards, Tony -- 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] [mc1322x] Econotag Linux 802.15.4 issues
Hi David, > The sequence numbers in your pcap are not incrementing, may or may > not be a problem but some software will ignore duplicates. This is because the 6lowpan code, when building the 802.15.4 header, does not set the sequence number field. I plan on releasing this patch alongside the other patches I wrote for the linux kernel. Regards, Tony -- 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] [mc1322x] Econotag Linux 802.15.4 issues
Hi, Answers inline. > >> Another quick question... When you do a wireshark of something with > >> 6lowpan fragmentation, are you getting malformed packet errors for > >> the first packet? I'm trying to decide whether this is something > >> that could hold me up, or whether it's a wireshark issue with > >> 6lowpan. I uploaded a capture file[1] from my embedded board. :1 > >> is the PC with econotag and :2 is the embedded board with > >> mrf24j40. As you can see, not all the packets are making it > >> through. I'll do some testing with the rftest tools. > > The current 6lowpan code for the first fragment is wrong (i.e. it > > should be more that 25 bytes or so). When I dug in the source code, > > I found out that the first fragment is always empty (i.e. no > > payload). I fixed that, but I haven't found the time to release a > > patch yet. I'm sorry about that. > > However, in my initial test, without the fix, I could still manage > > to log into SSH (sporadically, due to a failing serial driver). > > > > Ok, that makes sense then. I guess that answers my question. Wireshark > is reporting an error, and there is an error, but it should still > work. Note that event with my fix, wireshark will complain about overlapping fragment (but will reassemble correctly), even through the (first) fragment seems OK. > >> This example capture [2] shows an HC1 header (for example, packet > >> 4) that we don't have, but my quick look at the 6lowpan RFC hasn't > >> been able to convince me that it's required in any way. Like I > >> said, it could be a Wireshark issue. > > HC1 header is required in order to "compress" the IPv6 header (from > > 40 bytes to something like 20 bytes in your case). It saves > > bandwidth and prevent the need for fragmentation. This is not > > required so to speak, but your packet go through the 6lowpan > > module, they will have the HC1 compression applied to them. > > > > That's strange then, since I'm _not_ seeing the HC1 header in packets > sent from Linux. It is only present in that sample capture I got from > Wireshark's website that I linked to. My bad. It's using IPHC encoding format (RFC6282). > > While I'm at it, you might find this kind of issues as you play with > > the linux net-next kernel: > > - crash due to memory allocation in 6lowpan: on "my" kernel, I > > changed the kzalloc() call from GFP_KERNEL to GFP_ATOMIC. The > > backtrace was not always useful as it would point to random network > > code. > > Yes, I found this and changed it to use stack arrays, since the > lengths were fixed-size and small. > > Interestingly, this only stack dumps on the PC, not on my Beaglebone. > On the Beaglebone I get a pretty serious warning about deadlock > though. See [1] below. I haven't had a chance to look at that one yet. > > > - the serial driver itself has some bugs (in the linux-zigbee tree). > > Some patches sent to linux-zigbee mailing list were never applied. > > I'd be very happy to test any patches you have. I think those must > have been before I subscribed to the mailing list. I'll try to get something out during the week-end. > > - during packet burst, packets can be sent in the wrong order: this > > is due to the way the queue was implemented in the MAC layer > > (net/mac802154/tx.c): if the device is busy, the packet is > > rescheduled to be send, but at the end of the queue. > > Does this cause a problem? I don't know the 6lowpan spec very well, > but for UDP fragmentation it's my understanding that the fragments > can come in any order. True, but the node can run into some problem when the transmitter tries to send Neighbor Discovery packet and they are mixed into its own UDP packets. In some of my packet captures, I witnessed such a scenario, and the Neighbor Solicitation is sent multiple times when there is not reason to. > In the capture, sometimes the first packet does show up last, but that > confuses me now, since it's packets _from_ the mrf24j40, which is the > slower device, and the Econotag is setup to auto-ack (but not > _request_ an ack). For a packet to be rescheduled by the MAC, your device driver only has to say that the device is busy when trying to TX. Maybe that's what happen with your first packet. > > - UDP header compression is broken: the header is compressed > > correctly, however both compressed and uncompressed header are sent > > on the air. Because the code is broken on the sender and the > > receiver, it still works. I have a patch for that (saves a few > > bytes in the packet). > > > > I'd be happy to test it if you want me to. OK, I really need to get my patches out, rather that detailing what they do. :) > > You currently don't have L2 acknowledgment with the current Econotag > > firmware. I need to release my "additions": I enabled auto-ack in my > > firmware and go it to work between two devices. It requires > > modification in the 6lowpan and the MAC codes as well (so that the > > ACK flag can be passed down). > > Yes, I'd ver
Re: [Linux-zigbee-devel] [mc1322x] Econotag Linux 802.15.4 issues
Hi Alan, I've never experience that error. But as I mentioned before, I patched the UDP code path, so I might have fix this bug. Also, there is two interesting things in your capture: - in the first packet (UDP), the compressed UDP header is followed by the uncompressed header - in the second packet (ICMP error message), the copy of the original packet that triggered the error omit the compressed UDP header. Also, it shows the packet the way it has been decoded internally; the next header and the payload length field do not seem to match Regards, Tony Le Sat, 04 Aug 2012 12:43:43 -0400, Alan Ott a écrit : > On 08/03/2012 07:25 PM, Tony Cheneau wrote: > >>> - UDP header compression is broken: the header is compressed > >>> correctly, however both compressed and uncompressed header are > >>> sent on the air. Because the code is broken on the sender and the > >>> receiver, it still works. I have a patch for that (saves a few > >>> bytes in the packet). > >>> > > Hi Tony, > > As far as UDP goes, I made a simple UDP client/server to see if I can > get one packet across the link that wasn't ICMP6. > > The packet[1] is sent and looks good in wireshark, but the receiver > bounces it back with an ICMP6 packet which Wireshark dissects as > saying "Parameter Problem, unrecognized next header encountered." > That seems different than the UDP issue you described. Is this > something you've seen before? > > Alan. > > [1] http://www.signal11.us/~alan/next-header.pcap.gz > -- 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] [mc1322x] Econotag Linux 802.15.4 issues
Hello Ralph, The code part of the Linux vanilla kernel (which I believe is the one packaged in Ubuntu) is cleanup effort of the linux-zigbee kernel. Meaning that some bugs have been fixed, but some other features have not been imported/reimplemented yet. For example, the serial driver (that is used to control the econotag board) is missing. This is why izattach fails in your case. If you are looking for the latest code base, you should definitely look at the linux net-next branch, this is where the work is done. However, the serial driver is still missing here. I've some patches to get the serial driver working on a recent version of linux net-next that I am currently cleaning up. I'll try to post them in this list as soon as I can. Regards, Tony Le 20.08.2012 15:07, Ralph Droms (rdroms) a écrit : > I'm trying to use an Econotag with the linux802154-serialdev firmware > and the Linux 802.15.4 user and kernel code. I've compiled and run > the firmware, and compiled the Linux user code. I see that the Linux > system I'm using: > > Linux ubuntu 3.2.0-29-generic-pae > > has an ieee802154 module already available. Is this module the same > as the module at: > > git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee/kernel > > izattach fails at this ioctl call: > > arg = N_IEEE802154; > ret = ioctl(fd, TIOCSETD, &arg); > > - Ralph > > > > -- > 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 -- 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] Device for use with linux zigbee
Hi Jean-Eric, Actually, some of these devices are USB based. This is the case of the RedBee Econotag (MC1322x board). This is device is supported by the linux-zigbee kernel (now slightly old). I'm working on "importing" the serial driver within the linux net-next kernel (where the latest changes on the IEEE 802.15.4 stack are being made). I hope I can release my patches soon. Regards, Tony Le 20.09.2012 14:27, Jean-Eric Cuendet a écrit : >> You can find a hardware support list from >> http://sourceforge.net/apps/trac/linux-zigbee/wiki/HardwareSupport >> [1] > > Thanks. > If I understand well, none of these are "easy" devices, easy meaning > USB/PCI, right? > > > > Links: > -- > [1] > http://sourceforge.net/apps/trac/linux-zigbee/wiki/HardwareSupport -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 00/15] 6lowpan: Some more bug fixes
Hello, This patch serie fixes a few bugs within the 6lowpan modules and prepares the integration of the serial driver that will be submitted in a subsequent patch serie. It should apply cleanly on the latest net-next. Regards, Tony Cheneau Tony Cheneau (15): 6lowpan: lowpan_is_iid_16_bit_compressable() does not detect compressable address correctly 6lowpan: next header is not properly set upon decompression of a UDP header. 6lowpan: always enable link-layer acknowledgments mac802154: turn on ACK when enabled by the upper layers 6lowpan: use short IEEE 802.15.4 addresses for broadcast destination 6lowpan: fix first fragment (FRAG1) handling 6lowpan: store fragment tag values per device instead of net stack wide 6lowpan: obtain IEEE802.15.4 sequence number from the MAC layer 6lowpan: add a new parameter in sysfs to turn on/off ACK request at MAC layer 6lowpan: use the PANID provided by the device instead of a static value 6lowpan: modify udp compression/uncompression to match the standard 6lowpan: make memory allocation atomic during 6lowpan header creation mac802154: make mem alloc ATOMIC to prevent "scheduling while atomic" crashes mac802154: remove unnecessary spinlocks mac802154: re-introduce MAC primitives required to send/receive packets net/ieee802154/6lowpan.c | 144 - net/ieee802154/6lowpan.h | 14 +++-- net/mac802154/mac802154.h |2 + net/mac802154/mac_cmd.c | 22 +++- net/mac802154/mib.c | 33 +++ net/mac802154/wpan.c |4 +- 6 files changed, 172 insertions(+), 47 deletions(-) -- 1.7.8.6 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 01/15] 6lowpan: lowpan_is_iid_16_bit_compressable() does not detect compressable address correctly
The current test is not RFC6282 compliant. The same issue has been found out and fixed in Contiki. This patch is basicaly a port of their fix. Signed-off-by: Tony Cheneau --- net/ieee802154/6lowpan.h | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h index 8c2251f..efd1a57 100644 --- a/net/ieee802154/6lowpan.h +++ b/net/ieee802154/6lowpan.h @@ -87,14 +87,16 @@ #define is_addr_link_local(a) (((a)->s6_addr16[0]) == 0x80FE) /* - * check whether we can compress the IID to 16 bits, - * it's possible for unicast adresses with first 49 bits are zero only. - */ +* check whether we can compress the IID to 16 bits, +* it's possible for unicast adresses with first 49 bits are zero only. +*/ #define lowpan_is_iid_16_bit_compressable(a) \ a)->s6_addr16[4]) == 0) && \ -(((a)->s6_addr16[5]) == 0) && \ -(((a)->s6_addr16[6]) == 0) && \ -a)->s6_addr[14]) & 0x80) == 0)) +(((a)->s6_addr[10]) == 0) && \ +(((a)->s6_addr[11]) == 0xff) &&\ +(((a)->s6_addr[12]) == 0xfe) &&\ +(((a)->s6_addr[13]) == 0)) + /* multicast address */ #define is_addr_mcast(a) (((a)->s6_addr[0]) == 0xFF) -- 1.7.8.6 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 02/15] 6lowpan: next header is not properly set upon decompression of a UDP header.
This causes a drop of the UDP packet.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 6d42c17..b53a71a4 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -913,9 +913,12 @@ lowpan_process_data(struct sk_buff *skb)
}
/* UDP data uncompression */
- if (iphc0 & LOWPAN_IPHC_NH_C)
+ if (iphc0 & LOWPAN_IPHC_NH_C) {
if (lowpan_uncompress_udp_header(skb))
goto drop;
+ hdr.nexthdr = UIP_PROTO_UDP;
+ }
+
/* Not fragmented package */
hdr.payload_len = htons(skb->len);
--
1.7.8.6
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 03/15] 6lowpan: always enable link-layer acknowledgments
This feature is especially important when using fragmentation, because the reassembly mechanism can not recover from the loss of a fragment. Note that some hardware ignore this flag and not will not transmit any acknowledgments if this is set. Signed-off-by: Tony Cheneau --- net/ieee802154/6lowpan.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index b53a71a4..49d91df 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -589,6 +589,10 @@ static int lowpan_header_create(struct sk_buff *skb, mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA; + /* request acknowledgment when possible */ + if (!lowpan_is_addr_broadcast(daddr)) + mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ; + return dev_hard_header(skb, lowpan_dev_info(dev)->real_dev, type, (void *)&da, (void *)&sa, skb->len); } -- 1.7.8.6 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 05/15] 6lowpan: use short IEEE 802.15.4 addresses for broadcast destination
It is intended that the IEEE 802.15.4 standard uses the 0x short address (2
bytes) for message broadcasting.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 49d91df..8a2ee95 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -577,21 +577,26 @@ static int lowpan_header_create(struct sk_buff *skb,
* this isn't implemented in mainline yet, so currently we assign 0xff
*/
{
+ mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+
/* prepare wpan address data */
sa.addr_type = IEEE802154_ADDR_LONG;
sa.pan_id = 0xff;
-
- da.addr_type = IEEE802154_ADDR_LONG;
- da.pan_id = 0xff;
-
- memcpy(&(da.hwaddr), daddr, 8);
memcpy(&(sa.hwaddr), saddr, 8);
- mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+ da.pan_id = 0xff;
+ /* if the destination address is the broadcast address,
+ use short address */
+ if (lowpan_is_addr_broadcast(daddr)) {
+ da.addr_type = IEEE802154_ADDR_SHORT;
+ da.short_addr = IEEE802154_ADDR_BROADCAST;
+ } else {
+ da.addr_type = IEEE802154_ADDR_LONG;
+ memcpy(&(da.hwaddr), daddr, 8);
- /* request acknowledgment when possible */
- if (!lowpan_is_addr_broadcast(daddr))
+ /* request acknowledgment */
mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
+ }
return dev_hard_header(skb, lowpan_dev_info(dev)->real_dev,
type, (void *)&da, (void *)&sa, skb->len);
--
1.7.8.6
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 04/15] mac802154: turn on ACK when enabled by the upper layers
Signed-off-by: Tony Cheneau
---
net/mac802154/wpan.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/mac802154/wpan.c b/net/mac802154/wpan.c
index f30f6d4..d6aea7f 100644
--- a/net/mac802154/wpan.c
+++ b/net/mac802154/wpan.c
@@ -149,6 +149,8 @@ static int mac802154_header_create(struct sk_buff *skb,
head[pos++] = mac_cb(skb)->seq; /* DSN/BSN */
fc = mac_cb_type(skb);
+ if (mac_cb_is_ackreq(skb))
+ fc |= IEEE802154_FC_ACK_REQ;
if (!saddr) {
spin_lock_bh(&priv->mib_lock);
--
1.7.8.6
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 07/15] 6lowpan: store fragment tag values per device instead of net stack wide
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 38cecaf..eb8003b 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -104,6 +104,7 @@ static const u8 lowpan_llprefix[] = {0xfe, 0x80};
struct lowpan_dev_info {
struct net_device *real_dev; /* real WPAN device ptr */
struct mutexdev_list_mtx; /* mutex for list ops */
+ unsigned short fragment_tag;
};
struct lowpan_dev_record {
@@ -120,7 +121,6 @@ struct lowpan_fragment {
struct list_headlist; /* fragments list */
};
-static unsigned short fragment_tag;
static LIST_HEAD(lowpan_fragments);
static DEFINE_SPINLOCK(flist_lock);
@@ -1022,14 +1022,14 @@ lowpan_fragment_xmit(struct sk_buff *skb, u8 *head,
}
static int
-lowpan_skb_fragmentation(struct sk_buff *skb)
+lowpan_skb_fragmentation(struct sk_buff *skb, struct net_device *dev)
{
int err, header_length, payload_length, tag, offset = 0;
u8 head[5];
header_length = lowpan_get_mac_header_length(skb);
payload_length = skb->len - header_length;
- tag = fragment_tag++;
+ tag = lowpan_dev_info(dev)->fragment_tag++;
/* first fragment header */
head[0] = LOWPAN_DISPATCH_FRAG1 | ((payload_length >> 8) & 0x7);
@@ -1095,7 +1095,7 @@ static netdev_tx_t lowpan_xmit(struct sk_buff *skb,
struct net_device *dev)
}
pr_debug("frame is too big, fragmentation is needed\n");
- err = lowpan_skb_fragmentation(skb);
+ err = lowpan_skb_fragmentation(skb, dev);
error:
dev_kfree_skb(skb);
out:
@@ -1216,6 +1216,7 @@ static int lowpan_newlink(struct net *src_net, struct
net_device *dev,
return -ENODEV;
lowpan_dev_info(dev)->real_dev = real_dev;
+ lowpan_dev_info(dev)->fragment_tag = 0;
mutex_init(&lowpan_dev_info(dev)->dev_list_mtx);
entry = kzalloc(sizeof(struct lowpan_dev_record), GFP_KERNEL);
--
1.7.8.6
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 06/15] 6lowpan: fix first fragment (FRAG1) handling
The first fragment, FRAG1, must contain some payload according to the
specs. However, as it is currently written, the first fragment will
remain empty and only contain the 6lowpan headers.
This patch also extract the transport layer information from the first
fragment. This information is later on use when uncompressing UDP
header.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 54 +++--
1 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 8a2ee95..38cecaf 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -654,7 +654,7 @@ static void lowpan_fragment_timer_expired(unsigned long
entry_addr)
}
static struct lowpan_fragment *
-lowpan_alloc_new_frame(struct sk_buff *skb, u8 len, u16 tag)
+lowpan_alloc_new_frame(struct sk_buff *skb, u16 len, u16 tag)
{
struct lowpan_fragment *frame;
@@ -735,6 +735,18 @@ lowpan_process_data(struct sk_buff *skb)
/* adds the 3 MSB to the 8 LSB to retrieve the 11 bits length */
len = ((iphc0 & 7) << 8) | slen;
+ if ((iphc0 & LOWPAN_DISPATCH_MASK) == LOWPAN_DISPATCH_FRAG1) {
+ pr_debug("%s received a FRAG1 packet (tag: %d, "
+"size of the entire IP packet: %d)"
+, __func__, tag, len);
+ } else { /* FRAGN */
+ if (lowpan_fetch_skb_u8(skb, &offset))
+ goto unlock_and_drop;
+ pr_debug("%s received a FRAGN packet (tag: %d, "
+"size of the entire IP packet: %d, "
+"offset: %d)", __func__, tag, len, offset * 8);
+ }
+
/*
* check if frame assembling with the same tag is
* already in progress
@@ -749,17 +761,13 @@ lowpan_process_data(struct sk_buff *skb)
/* alloc new frame structure */
if (!found) {
+ pr_debug("%s first fragment received for tag %d, "
+"begin packet reassembly", __func__, tag);
frame = lowpan_alloc_new_frame(skb, len, tag);
if (!frame)
goto unlock_and_drop;
}
- if ((iphc0 & LOWPAN_DISPATCH_MASK) == LOWPAN_DISPATCH_FRAG1)
- goto unlock_and_drop;
-
- if (lowpan_fetch_skb_u8(skb, &offset)) /* fetch offset */
- goto unlock_and_drop;
-
/* if payload fits buffer, copy it */
if (likely((offset * 8 + skb->len) <= frame->length))
skb_copy_to_linear_data_offset(frame->skb, offset * 8,
@@ -777,6 +785,10 @@ lowpan_process_data(struct sk_buff *skb)
list_del(&frame->list);
spin_unlock_bh(&flist_lock);
+ pr_debug("%s successfully reassembled fragment "
+"(tag %d)", __func__, tag);
+
+
dev_kfree_skb(skb);
skb = frame->skb;
kfree(frame);
@@ -976,13 +988,13 @@ static int lowpan_get_mac_header_length(struct sk_buff
*skb)
static int
lowpan_fragment_xmit(struct sk_buff *skb, u8 *head,
- int mlen, int plen, int offset)
+ int mlen, int plen, int offset, int type)
{
struct sk_buff *frag;
int hlen, ret;
- /* if payload length is zero, therefore it's a first fragment */
- hlen = (plen == 0 ? LOWPAN_FRAG1_HEAD_SIZE : LOWPAN_FRAGN_HEAD_SIZE);
+ hlen = (type == LOWPAN_DISPATCH_FRAG1 ? LOWPAN_FRAG1_HEAD_SIZE :
+ LOWPAN_FRAGN_HEAD_SIZE);
lowpan_raw_dump_inline(__func__, "6lowpan fragment header", head, hlen);
@@ -1025,7 +1037,18 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
head[2] = tag >> 8;
head[3] = tag & 0xff;
- err = lowpan_fragment_xmit(skb, head, header_length, 0, 0);
+ err = lowpan_fragment_xmit(skb, head, header_length, LOWPAN_FRAG_SIZE,
+ 0, LOWPAN_DISPATCH_FRAG1);
+
+ if (err) {
+#if DEBUG
+ pr_debug("%s unable to send FRAG1 packet (tag: %d)",
+__func__, tag);
+#endif /* DEBUG */
+ goto exit;
+ }
+
+ offset = LOWPAN_FRAG_SIZE;
/* next fragment header */
head[0] &= ~LOWPAN_DISPATCH_FRAG1;
@@ -1040,10 +1063,17 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
len = payload_length - offset;
err = lowpan_fragme
[Linux-zigbee-devel] [PATCH net-next 08/15] 6lowpan: obtain IEEE802.15.4 sequence number from the MAC layer
This patch sets the sequence number in the frame format. Without this
fix, the sequence number is always set to 0. This makes trafic analysis
very hard.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index eb8003b..24b83fa 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -578,6 +578,7 @@ static int lowpan_header_create(struct sk_buff *skb,
*/
{
mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+ mac_cb(skb)->seq = ieee802154_mlme_ops(dev)->get_dsn(dev);
/* prepare wpan address data */
sa.addr_type = IEEE802154_ADDR_LONG;
@@ -1123,6 +1124,12 @@ static u16 lowpan_get_short_addr(const struct net_device
*dev)
return ieee802154_mlme_ops(real_dev)->get_short_addr(real_dev);
}
+static u8 lowpan_get_dsn(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_dsn(real_dev);
+}
+
static struct header_ops lowpan_header_ops = {
.create = lowpan_header_create,
};
@@ -1136,6 +1143,7 @@ static struct ieee802154_mlme_ops lowpan_mlme = {
.get_pan_id = lowpan_get_pan_id,
.get_phy = lowpan_get_phy,
.get_short_addr = lowpan_get_short_addr,
+ .get_dsn = lowpan_get_dsn,
};
static void lowpan_setup(struct net_device *dev)
--
1.7.8.6
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 09/15] 6lowpan: add a new parameter in sysfs to turn on/off ACK request at MAC layer
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 24b83fa..f8fcdae 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -62,6 +62,8 @@
#include "6lowpan.h"
+static bool req_802154_ack;
+
/* TTL uncompression values */
static const u8 lowpan_ttl_values[] = {0, 1, 64, 255};
@@ -596,7 +598,8 @@ static int lowpan_header_create(struct sk_buff *skb,
memcpy(&(da.hwaddr), daddr, 8);
/* request acknowledgment */
- mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
+ if (req_802154_ack)
+ mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
}
return dev_hard_header(skb, lowpan_dev_info(dev)->real_dev,
@@ -1366,6 +1369,10 @@ static void __exit lowpan_cleanup_module(void)
}
module_init(lowpan_init_module);
+
+module_param(req_802154_ack, bool, 0644);
+MODULE_PARM_DESC(req_802154_ack, "request link-layer (i.e. IEEE 802.15.4)
acknowledgments");
+
module_exit(lowpan_cleanup_module);
MODULE_LICENSE("GPL");
MODULE_ALIAS_RTNL_LINK("lowpan");
--
1.7.8.6
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 10/15] 6lowpan: use the PANID provided by the device instead of a static value
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index f8fcdae..9711038 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -584,10 +584,12 @@ static int lowpan_header_create(struct sk_buff *skb,
/* prepare wpan address data */
sa.addr_type = IEEE802154_ADDR_LONG;
- sa.pan_id = 0xff;
+ sa.pan_id = ieee802154_mlme_ops(dev)->get_pan_id(dev);
+
memcpy(&(sa.hwaddr), saddr, 8);
+ /* intra-PAN communications */
+ da.pan_id = ieee802154_mlme_ops(dev)->get_pan_id(dev);
- da.pan_id = 0xff;
/* if the destination address is the broadcast address,
use short address */
if (lowpan_is_addr_broadcast(daddr)) {
--
1.7.8.6
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 11/15] 6lowpan: modify udp compression/uncompression to match the standard
The previous code would just compress the UDP header and send the compressed
UDP header along with the uncompressed one.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 36 +---
1 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 9711038..9c7ac2e 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -286,6 +286,9 @@ lowpan_compress_udp_header(u8 **hc06_ptr, struct sk_buff
*skb)
/* checksum is always inline */
memcpy(*hc06_ptr, &uh->check, 2);
*hc06_ptr += 2;
+
+ /* skip the UDP header */
+ skb_pull(skb, sizeof(struct udphdr));
}
static inline int lowpan_fetch_skb_u8(struct sk_buff *skb, u8 *val)
@@ -311,9 +314,8 @@ static inline int lowpan_fetch_skb_u16(struct sk_buff *skb,
u16 *val)
}
static int
-lowpan_uncompress_udp_header(struct sk_buff *skb)
+lowpan_uncompress_udp_header(struct sk_buff *skb, struct udphdr *uh)
{
- struct udphdr *uh = udp_hdr(skb);
u8 tmp;
if (!uh)
@@ -354,12 +356,19 @@ lowpan_uncompress_udp_header(struct sk_buff *skb)
break;
}
+
pr_debug("uncompressed UDP ports: src = %d, dst = %d\n",
uh->source, uh->dest);
/* copy checksum */
memcpy(&uh->check, &skb->data[0], 2);
skb_pull(skb, 2);
+
+ /* UDP lenght needs to be infered from the lower layers
+ here, we obtain the hint from the remaining size of the
+ frame */
+ uh->len = htons(skb->len + sizeof(struct udphdr));
+ pr_debug("uncompressed UDP length: src = %d", uh->len);
} else {
pr_debug("ERROR: unsupported NH format\n");
goto err;
@@ -941,8 +950,29 @@ lowpan_process_data(struct sk_buff *skb)
/* UDP data uncompression */
if (iphc0 & LOWPAN_IPHC_NH_C) {
- if (lowpan_uncompress_udp_header(skb))
+ struct udphdr uh;
+ struct sk_buff *new;
+ if (lowpan_uncompress_udp_header(skb, &uh))
goto drop;
+
+ /* place the real UDP header instead of the
+ compressed UDP header */
+ new = skb_copy_expand(skb, sizeof(struct udphdr),
+ skb_tailroom(skb), GFP_ATOMIC);
+ kfree_skb(skb);
+
+ if (!new)
+ return -ENOMEM;
+
+ skb = new ;
+
+ skb_push(skb, sizeof(struct udphdr));
+ skb_reset_transport_header(skb);
+ skb_copy_to_linear_data(skb, &uh, sizeof(struct udphdr));
+
+ lowpan_raw_dump_table(__func__, "raw UDP header dump",
+ (u8 *)&uh, sizeof(uh));
+
hdr.nexthdr = UIP_PROTO_UDP;
}
--
1.7.8.6
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 12/15] 6lowpan: make memory allocation atomic during 6lowpan header creation
This is prevent various crashes when using the serial driver (not yet in the tree). Signed-off-by: Tony Cheneau --- net/ieee802154/6lowpan.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index 9c7ac2e..70ff171 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -396,7 +396,7 @@ static int lowpan_header_create(struct sk_buff *skb, /* TODO: * if this package isn't ipv6 one, where should it be routed? */ - head = kzalloc(100, GFP_KERNEL); + head = kzalloc(100, GFP_ATOMIC); if (head == NULL) return -ENOMEM; -- 1.7.8.6 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 13/15] mac802154: make mem alloc ATOMIC to prevent "scheduling while atomic" crashes
These crashes occur mainly with the serial driver (not yet in the tree). Signed-off-by: Tony Cheneau --- net/mac802154/wpan.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/mac802154/wpan.c b/net/mac802154/wpan.c index d6aea7f..49ba8df 100644 --- a/net/mac802154/wpan.c +++ b/net/mac802154/wpan.c @@ -143,7 +143,7 @@ static int mac802154_header_create(struct sk_buff *skb, if (!daddr) return -EINVAL; - head = kzalloc(MAC802154_FRAME_HARD_HEADER_LEN, GFP_KERNEL); + head = kzalloc(MAC802154_FRAME_HARD_HEADER_LEN, GFP_ATOMIC); if (head == NULL) return -ENOMEM; -- 1.7.8.6 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 14/15] mac802154: remove unnecessary spinlocks
These spinlock protects an int variable, that is always accessible in an
atomic fashion.
Signed-off-by: Tony Cheneau
---
net/mac802154/mib.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/net/mac802154/mib.c b/net/mac802154/mib.c
index f47781a..2339f8d 100644
--- a/net/mac802154/mib.c
+++ b/net/mac802154/mib.c
@@ -103,15 +103,10 @@ void mac802154_dev_set_short_addr(struct net_device *dev,
u16 val)
u16 mac802154_dev_get_short_addr(const struct net_device *dev)
{
struct mac802154_sub_if_data *priv = netdev_priv(dev);
- u16 ret;
BUG_ON(dev->type != ARPHRD_IEEE802154);
- spin_lock_bh(&priv->mib_lock);
- ret = priv->short_addr;
- spin_unlock_bh(&priv->mib_lock);
-
- return ret;
+ return priv->short_addr;
}
void mac802154_dev_set_ieee_addr(struct net_device *dev)
@@ -131,15 +126,10 @@ void mac802154_dev_set_ieee_addr(struct net_device *dev)
u16 mac802154_dev_get_pan_id(const struct net_device *dev)
{
struct mac802154_sub_if_data *priv = netdev_priv(dev);
- u16 ret;
BUG_ON(dev->type != ARPHRD_IEEE802154);
- spin_lock_bh(&priv->mib_lock);
- ret = priv->pan_id;
- spin_unlock_bh(&priv->mib_lock);
-
- return ret;
+ return priv->pan_id;
}
void mac802154_dev_set_pan_id(struct net_device *dev, u16 val)
--
1.7.8.6
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 15/15] mac802154: re-introduce MAC primitives required to send/receive packets
- mlme_assoc_req() and mlme_assoc_resp() are just place holder for the
moment (they prevent the two corresponding function pointers in the
mac802154_mlme_wpan structure to be left uninitialized)
- mac802514_dev_get_bsn() and mac802514_dev_get_dsn() MAC primitives
were present in the Linux-Zigbee kernel and are being re-introduced.
Signed-off-by: Tony Cheneau
---
net/mac802154/mac802154.h |2 ++
net/mac802154/mac_cmd.c | 22 +-
net/mac802154/mib.c | 19 +++
3 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/net/mac802154/mac802154.h b/net/mac802154/mac802154.h
index a4dcaf1..18d4044 100644
--- a/net/mac802154/mac802154.h
+++ b/net/mac802154/mac802154.h
@@ -114,5 +114,7 @@ void mac802154_dev_set_ieee_addr(struct net_device *dev);
u16 mac802154_dev_get_pan_id(const struct net_device *dev);
void mac802154_dev_set_pan_id(struct net_device *dev, u16 val);
void mac802154_dev_set_page_channel(struct net_device *dev, u8 page, u8 chan);
+u8 mac802154_dev_get_dsn(const struct net_device *dev);
+u8 mac802154_dev_get_bsn(const struct net_device *dev);
#endif /* MAC802154_H */
diff --git a/net/mac802154/mac_cmd.c b/net/mac802154/mac_cmd.c
index d8d2770..8e46e7b 100644
--- a/net/mac802154/mac_cmd.c
+++ b/net/mac802154/mac_cmd.c
@@ -33,6 +33,22 @@
#include "mac802154.h"
+static int mac802154_mlme_assoc_req(struct net_device *dev,
+ struct ieee802154_addr *addr,
+ u8 channel, u8 page, u8 cap)
+{
+ /* TBD */
+ return 0;
+}
+
+static int mac802154_mlme_assoc_resp(struct net_device *dev,
+ struct ieee802154_addr *addr,
+ u16 short_addr, u8 status)
+{
+ /* TBD */
+ return 0;
+}
+
static int mac802154_mlme_start_req(struct net_device *dev,
struct ieee802154_addr *addr,
u8 channel, u8 page,
@@ -70,7 +86,11 @@ struct ieee802154_reduced_mlme_ops mac802154_mlme_reduced = {
struct ieee802154_mlme_ops mac802154_mlme_wpan = {
.get_phy = mac802154_get_phy,
- .start_req = mac802154_mlme_start_req,
.get_pan_id = mac802154_dev_get_pan_id,
.get_short_addr = mac802154_dev_get_short_addr,
+ .get_dsn = mac802154_dev_get_dsn,
+ .get_bsn = mac802154_dev_get_bsn,
+ .start_req = mac802154_mlme_start_req,
+ .assoc_req = mac802154_mlme_assoc_req,
+ .assoc_resp = mac802154_mlme_assoc_resp
};
diff --git a/net/mac802154/mib.c b/net/mac802154/mib.c
index 2339f8d..70ab6ca 100644
--- a/net/mac802154/mib.c
+++ b/net/mac802154/mib.c
@@ -149,6 +149,25 @@ void mac802154_dev_set_pan_id(struct net_device *dev, u16
val)
}
}
+u8 mac802154_dev_get_dsn(const struct net_device *dev)
+{
+ struct mac802154_sub_if_data *priv = netdev_priv(dev);
+
+ BUG_ON(dev->type != ARPHRD_IEEE802154);
+
+ return priv->dsn++;
+}
+
+u8 mac802154_dev_get_bsn(const struct net_device *dev)
+{
+ struct mac802154_sub_if_data *priv = netdev_priv(dev);
+
+ BUG_ON(dev->type != ARPHRD_IEEE802154);
+
+ return priv->bsn++;
+}
+
+
static void phy_chan_notify(struct work_struct *work)
{
struct phy_chan_notify_work *nw = container_of(work,
--
1.7.8.6
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
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 net-next 06/15] 6lowpan: fix first fragment (FRAG1) handling
Hello Jan,
Thank you for all your comments. See my answer inline.
Le 23.10.2012 09:19, Jan Ceuleers a écrit :
> On 10/23/2012 06:09 AM, Tony Cheneau wrote:
>> The first fragment, FRAG1, must contain some payload according to
>> the
>> specs. However, as it is currently written, the first fragment will
>> remain empty and only contain the 6lowpan headers.
>>
>> This patch also extract the transport layer information from the
>> first
>> fragment. This information is later on use when uncompressing UDP
>> header.
>>
>> Signed-off-by: Tony Cheneau
>> ---
>> net/ieee802154/6lowpan.c | 54
>> +++--
>> 1 files changed, 42 insertions(+), 12 deletions(-)
>>
>> diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
>> index 8a2ee95..38cecaf 100644
>> --- a/net/ieee802154/6lowpan.c
>> +++ b/net/ieee802154/6lowpan.c
>> @@ -654,7 +654,7 @@ static void
>> lowpan_fragment_timer_expired(unsigned long entry_addr)
>> }
>>
>> static struct lowpan_fragment *
>> -lowpan_alloc_new_frame(struct sk_buff *skb, u8 len, u16 tag)
>> +lowpan_alloc_new_frame(struct sk_buff *skb, u16 len, u16 tag)
>> {
>> struct lowpan_fragment *frame;
>>
>> @@ -735,6 +735,18 @@ lowpan_process_data(struct sk_buff *skb)
>> /* adds the 3 MSB to the 8 LSB to retrieve the 11 bits length */
>> len = ((iphc0 & 7) << 8) | slen;
>>
>> +if ((iphc0 & LOWPAN_DISPATCH_MASK) == LOWPAN_DISPATCH_FRAG1) {
>> +pr_debug("%s received a FRAG1 packet (tag: %d, "
>> + "size of the entire IP packet: %d)"
>> + , __func__, tag, len);
>
> There are several schools of thought on the relative importance of
> observing the 80-character line limit versus breaking up string
> constants (in an attempt to maintain grepability). I think the above
> is
> fine but others (whose opinion matters more than mine) may or may not
> agree. Whatever you decide here, please apply consistently
> throughout.
Yes, I've seen that particular issues when running checkpatch.pl. I
decided to break down line, but I can easily be convinced to do things
differently. Anyway, I'll make sure that all my patches are consistent
in breaking up string after 80 characters the same way.
> However, the comma ahead of the __func__ should be at the end of the
> previous line.
Will do.
>
>> -/* if payload length is zero, therefore it's a first fragment */
>> -hlen = (plen == 0 ? LOWPAN_FRAG1_HEAD_SIZE :
>> LOWPAN_FRAGN_HEAD_SIZE);
>> +hlen = (type == LOWPAN_DISPATCH_FRAG1 ? LOWPAN_FRAG1_HEAD_SIZE :
>> +LOWPAN_FRAGN_HEAD_SIZE);
>
> The second line of this statement should be aligned as follows:
>
> + hlen = (type == LOWPAN_DISPATCH_FRAG1 ? LOWPAN_FRAG1_HEAD_SIZE :
> + LOWPAN_FRAGN_HEAD_SIZE);
>
> So the L for LOWPAN_FRAGN_HEAD_SIZE should be underneath the t for
> type.
Will do as well.
Again, thank you for all your detailed comments.
Regards,
Tony
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
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 net-next 01/15] 6lowpan: lowpan_is_iid_16_bit_compressable() does not detect compressable address correctly
Hello David, Le 23.10.2012 08:49, David Miller a écrit : [...] > > It's really demoralizing to sit down to read a large 15 entry > patch series and this is the first thing I see: > >> /* >> - * check whether we can compress the IID to 16 bits, >> - * it's possible for unicast adresses with first 49 bits are zero >> only. >> - */ >> +* check whether we can compress the IID to 16 bits, >> +* it's possible for unicast adresses with first 49 bits are zero >> only. >> +*/ > > Don't break the comment indentation, it was perfectly fine. > > I'm not reviewing the rest of the series, you'll need to repost > the entire thing after you fix this. > > And if you're smart you'll make sure there aren't similar coding > style issues in the rest of your patches, else it's going to take > a long time to merge this crap into the tree. Sorry about that, I failed to catch that mistake of mine (and several other ones that Jan spotted). I'll rework my patchset and resubmit. Thank you for pointing out this issue. Regards, Tony -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ 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 net-next 00/15] 6lowpan: Some more bug fixes
Hello Alexander, Thank you for your comments. See my answer inline. Le 25.10.2012 06:52, Alexander Smirnov a écrit : > Hi, > [...] > 1. The series is quite huge what makes it difficult for the review. > It > would be better to split it into one-two and submit separately (not > simultaneously). OK. Will do. > 2. Could you also please provide some notes about how have you tested > these changes (logs, plain text)? Do I need to check your changes > locally on my desk? If so I need some instructions. I'm not sure what you are asking here. There was some more debugging printk, that I removed because they were too verbose. Mostly, I test my patch with few userspace program, like ping6, iperf (both for TCP and UDP) and ssh. I also wrote a TCP and a UDP echo server, so as to test fragmentation in more details. For most functional patches, I usually confirm through wireshark that the packets indeed look the way they should (this, I've done it for patch 11 for example). But I don't have any automated scripts to check for regression. I can provide you the script I use to configure nodes if needed (but it pretty straighward and should look like your own scripts). I'm not sure that really answers your question. > 3. Please DO NOT submit patches like: this patch fixes blablabla > which > isn't in the kernel yet (like patch 13,15). I have no clue what you > have locally on your laptop and what you will send in some time. I'd > like to see here the working code, not a references to TBD. I'm OK with removing patch 13 (I'll introduce it alongside the serial driver later on). I'm not so OK with removing patch 15, or at least, it would require some more testing in other parts of the code. Basically, the TBD are placeholder for when the Association Request/Response will be reimplemented. I introduced it because otherwise, .assoc_req and .assoc_resp entries of mac802154_mlme_wpan would go uninitialized and would cause kernel crash when called. I could have modified the calling code to deal with that, but I thought these primitives were meant to be re-implemented soon anyway. > 4. The reference to linux-zigbee project isn't an occasion for me to > apply this code to this tree. I have no goal to merge all this fun to > mainline due to several things in linux-zigbee kernel work NOT > according to the standard (mostly it's a timing problems) and global > refactoring needed. I don't understand what you are talking about here. I would guess that you are talking about patch 15. If so, my answer is the following, while I understand your effort to refactor linux-zigbee code and fix things along the way, some code went through net-next that cause crashes. My pragmatic approach is to try to fix it before more people use it, even through it might not always be the most elegant way to do it. Regards, Tony -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Status and Path Forward
Hi Alan, (Before I start, I'd like to say that I'm grateful to everyone for their efforts. Also, I'm not trying to point a finger at anyone here). Thanks for your email. You raised a pretty valid point. When I first took interest in IEEE 802.15.4, I went to the linux-zigbee website. I thought this was the place where new code will go... and weeks later I found out that the newest code was ported to net-next. Too many people on the list seems to repeat the same "mistake". It seems a lot of the key actors are currently very busy, so I would suggest a few "quick" changes that, I believe, would make life easier for newcomers: - linux-zigbee.sf.net: placing a banner on each pages advertising that new efforts are on http://code.google.com/p/linux-wsn/ - updating the hardware support page on linux-zigbee. Some devices, like the econotag are marked as "supported" but it takes a few patches to get them to work reliably. Indicate that the driver has not been ported to net-next yet when it applies. - if it does not require too much effort: provide a working tree derived from net-next, where we would apply our patches on it for everyone to test - upgrade the userspace tools to fix the issue with libnl (so far, I've seen two patches for this on the linux-zigbee the mailing list). I guess the tools are currently working for very little people. - this mailing list is fine, we should keep it; even through the legacy "zigbee" portion of the name is confusing I also agree that the name linux-wsn, or any other name that does not contain "zigbee", would be more appropriate and less misleading. Regards, Tony Le Tue, 13 Nov 2012 19:09:08 -0500, Alan Ott a écrit : > Hello, > > I'd like to get some clarification and start some discussion on what > the path forward is for the linux-zigbee project and team. Currently > I see our situation as follows: > > 1. linux-zigbee.sf.net (first website) > * Mailing list (this one) > * Userspace tools > * recently updated, some patches are still outstanding (Tony's > Github tree). > * kernel > * Not updated in 6 months > * documentation > * mostly related to the linux-zigbee project kernel. Some out > of date. > > 2. http://code.google.com/p/linux-wsn/ (second website) > * information related to the implementation which is in the > mainline kernel. > * no code currently hosted. > * documentation > * related to the mainline kernel implementation > > It seems to me like we have some work to do regarding our front-facing > presentation to the world. Currently the two projects and websites > are a source of confusion for many newcomers. The first website is > likely what people will land on first when searching, but the second > more accurately describes the most recent developments of the project > (ie: code in the mainline kernel). > > The other issue of course is the misnomer of Linux-Zigbee, since we > are not and likely will not ever be implementing the Zigbee protocol. > > How do you, the maintainers and contributors, feel we should remedy > this situation? > > My feeling is that the websites should definitely be merged, and the > current linux-zigbee kernel be marked as legacy (for reference, and > as a temporary repository of features and drivers which have not been > merged upstream yet). Further, since the linux-zigbee name has been a > misnomer for years, my opinion would be that we start using the > linux-wsn (or some other) name for this project. Current website > links can of course be maintained from linux-zigbee.sf.net, but > anything with the words linux-zigbee on them should clearly reference > the new name (whatever that may be), and link to the new site. > > So the above is just one man's opinion, and I'm happy to be told to go > pound sand or "we like it the way it is" or whatever. It just seems > that there's a lot of confusion being presented from our community's > online presence, and I think there are some good opportunities to > make it better. > > I hope this email can stir up some discussion, and I'm happy to help > in whatever way possible, as I know the maintainers are very busy. > > Alan. > -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] linux-zigbee and 6lowpan.c
Hello Ralph, I want to provide a quick reply to your mail as I won't have time to provide an elaborated answer. You are right, the current stack does not interroperate correctly with other stack right now. If I'm not mistaken, Alan made just enough modifications to the stack so that it can communicate with Contiki (when disabling address compression on the Contiki side). "linux-next" is not the place where changes arrive first. You should track "net-next" instead [1]. I also have a bunch of patches that fix multiples blocking issues. I need to clean them before I resubmit them to the net-next kernel, but they should be functional already. I attached them to this mail. They should apply cleanly against the current "net-next" head. Regards, Tony [1]: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git Le 2013-02-11 17:19, Ralph Droms a écrit : I'm trying to bring up the linux-zigbee stack and I'm running into problems with 6lowpan.c I'm concerned about tracking down and fixing these problems, because they seem pretty fundamental and, as far as i can tell, would prevent this stack from interoperating with other RFC-compliant stacks. For example, it appears that the latest version of 6lowpan.c doesn't uncompress the "unspecified" (::/128) address, the link-local address format in which the IID is taken from the MAC header address or one of the multicast address formats correctly. I saw the fix for using the short hardware address for broadcast, which seemed to be required for interoperability, but that fix then broke fragmentation. Now, I'm seeing TCP and UDP checksum errors with 6lowpan-fragmented datagrams. I'm working from the 6lowpan.c code in the linux-next kernel: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Right place to start? I'm happy to contribute my fixes ... I want to make sure I'm not wasting your time and my time by trying to debug problems that are already solved. - Ralph = Ralph Droms Distinguished Engineer Research and Advanced Development Cisco rdr...@cisco.com Phone: +1 978 936 1674 Mobile: +1 978 376 3731 -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel 6lowpan-patches.tar.gz Description: GNU Zip compressed data -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] linux-zigbee and 6lowpan.c
Hi, Sorry for the delay, I wanted to check the code first. See my answer inline. Le 2013-03-05 21:20, Alan Ott a écrit : On 03/05/2013 02:38 PM, Ralph Droms (rdroms) wrote: On Mar 5, 2013, at 10:59 AM 3/5/13, Wolf-Bastian Pöttner wrote: Hi! Am 20.02.2013 um 03:00 schrieb Ralph Droms (rdroms) : What I want to do is update the header compression and fragmentation code so it interoperates using header compression. I think I have code for header compression and send-side fragmentation. I still need to work on the receive-side fragmentation. Am I right in assuming, that fragmentation between two linux devices is not supposed to work at the moment? The most recent version of 6lowpan.c that I pulled will interoperate with other instances of that same code, but not with different codebases. 6lowpan.c inserts a fragment offset based on the compressed header, while as I read the relevant RFCs, the offset should be based on the uncompressed header. Yes, it should be based on the uncompressed header. That's one of the things Tony Cheneau fixed. I'm not sure whether that's in his patch set that's not upstream yet. Actually, the patch I have for fragmentation (not integrated in net-next yet) does not cover this particular issue. The current code leaves the first fragment empty (i.e. with no payload), this is what it fixed in my patch. Ralph is right when he says that the datagram_size field (as per RFC 4944 Section 5.3) is not correctly set (it is currently computed over the compressed 6LoWPAN header). I attached a capture of a fragmentation when using my current patches. Reported datagram size is 227, while it should be 248 (I believe). Because both the fragment generation and fragment reassembly code use the offset in the same way, 6lowpan.c will interoperate with itself but not, e.g., Contiki or XINU code. I'm sure we fixed that (at least in some case). Tony can confirm. I wonder why it works, but it might be just out of pure luck. As I wrote, I have a fix for fragment generation that has been tested with Contiki (but has not been committed). I haven't had time to get back to the code to fix the fragment reassembly code. Regards, Tony 6lowpan-wrong-datagram-size.pcap Description: application/vnd.tcpdump.pcap -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Serial driver
Hi, No particular reason aside from the fact that no one submitted it yet. I have a slightly modified version in my patchset [1], just need to make sure it is clean and meet the kernel guidelines. It includes patches from Mariano Alvira and a few modifcations of mine (so that the driver call CLOSE and OPEN to the devices upon initialization, in order to reset it). Regards, Tony Cheneau [1]: https://github.com/linux-wpan/linux-net-next/commit/546618171de2be30236aab86f3ee323b425e2bf5 Le Mon, 18 Mar 2013 19:07:50 -0400, "jonsm...@gmail.com" a écrit : > Why isn't the serial driver in mainline? > > -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Econotag + serial driver + azattach error.
Hello, I don't know which kernel version or branch you use, but I'll assume that you are using the net-next branch. If so, the serial driver is missing. However, you can find it in my repo (you just have to apply this patch on top of your kernel tree or use my repo directly): https://github.com/linux-wpan/linux-net-next/commit/546618171de2be30236aab86f3ee323b425e2bf5 Regards, Tony Le Wed, 20 Mar 2013 03:03:25 +, sjs205 a écrit : > Hello all, > > I'm trying to get an econotag flashed with linux802154-serialdev > attached to my linux server using the 'azattach' command, however, I > am constantly getting the following error: > > /usr/local/sbin/izattach /dev/ttyUSB1 > ioctl: TIOCSETD: Invalid argument > > This is obviously the same as: > > http://comments.gmane.org/gmane.linux.network.zigbee.devel/653 > > Which suggests using the 'serial' module. but I can seem to find it, > Is this still about? > > > sjs205 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Econotag + serial driver + azattach error.
Hello, The latest 6LoWPAN bug fixes are sent first to the net-next branch of the linux kernel. It is generally a good habit to start using this branch of the kernel. You can find it here: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git To answer your initial question, I'm not sure the patch would apply cleanly on the Fedora kernel. If you are interested mainly in net-next + bugfixes, you can use my kernel tree directly (while I haven't merge it into net-next). Regards, Tony Le Wed, 20 Mar 2013 10:03:34 +, sjs205 a écrit : > Hello Tony, > > Thank you for getting back to me. I'm actually using a fedora kernel, > 3.7.9-104.fc17.x86_64. > > Based on this, would/should the patch still work? > > sjs205 > > On 03/20/2013 03:20 AM, Tony Cheneau wrote: > > Hello, > > > > I don't know which kernel version or branch you use, but I'll assume > > that you are using the net-next branch. If so, the serial driver is > > missing. However, you can find it in my repo (you just have to apply > > this patch on top of your kernel tree or use my repo directly): > > https://github.com/linux-wpan/linux-net-next/commit/546618171de2be30236aab86f3ee323b425e2bf5 > > > > Regards, > > Tony > > > > Le Wed, 20 Mar 2013 03:03:25 +, > > sjs205 a écrit : > > > >> Hello all, > >> > >> I'm trying to get an econotag flashed with linux802154-serialdev > >> attached to my linux server using the 'azattach' command, however, > >> I am constantly getting the following error: > >> > >> /usr/local/sbin/izattach /dev/ttyUSB1 > >> ioctl: TIOCSETD: Invalid argument > >> > >> This is obviously the same as: > >> > >> http://comments.gmane.org/gmane.linux.network.zigbee.devel/653 > >> > >> Which suggests using the 'serial' module. but I can seem to find > >> it, Is this still about? > >> > >> > >> sjs205 > -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Econotag + serial driver + azattach error.
Hello, Your issue seems familiar but I really think that using net-next instead of the stock kernel is the way forward. To me, backporting changes and bugfixes would be mostly a waste of time/energy. As Jon pointed out, you can easily configure your bootloader to register two or more kernels to boot from. Hope it helps. Regards, Tony Le Wed, 20 Mar 2013 13:23:13 +, sjs205 a écrit : > Hello Tony, > > I've just patched the serial driver into the stock fedora kernel > without issue, compilation and installation went okay too... But - > there is always a but - I'm now getting a different error: > > # /usr/local/sbin/izattach /dev/ttyUSB0 > socket: Address family not supported by protocol > > I think I have all the modules required installed: > $ lsmod > ... > ieee802154 25999 1 mac802154 > mac802154 24114 1 serial > crc_ccitt 12614 1 mac802154 > ieee802154 25999 1 mac802154 > 6lowpan23669 0 > ... > > Do you think this is probably due to something else missing in the > stock kernel? > > Regarding the net-next branch, I am using this on my main PC so need > it to be quite stable, I also wouldn't mind keeping to the fedora > kernel, at least for this system if at all possible; I could always > VM it. Is it possible that one could create a patch against the 3.7.9 > from the next-net branch? Apologies, my knowledge of git is quite > limited. > > BR > > sjs205 > > On 03/20/2013 01:07 PM, Tony Cheneau wrote: > > Hello, > > > > The latest 6LoWPAN bug fixes are sent first to the net-next branch > > of the linux kernel. It is generally a good habit to start using > > this branch of the kernel. You can find it here: > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git > > > > To answer your initial question, I'm not sure the patch would apply > > cleanly on the Fedora kernel. If you are interested mainly in > > net-next + bugfixes, you can use my kernel tree directly (while I > > haven't merge it into net-next). > > > > Regards, > > Tony > > > > Le Wed, 20 Mar 2013 10:03:34 +, > > sjs205 a écrit : > > > >> Hello Tony, > >> > >> Thank you for getting back to me. I'm actually using a fedora > >> kernel, 3.7.9-104.fc17.x86_64. > >> > >> Based on this, would/should the patch still work? > >> > >> sjs205 > >> > >> On 03/20/2013 03:20 AM, Tony Cheneau wrote: > >>> Hello, > >>> > >>> I don't know which kernel version or branch you use, but I'll > >>> assume that you are using the net-next branch. If so, the serial > >>> driver is missing. However, you can find it in my repo (you just > >>> have to apply this patch on top of your kernel tree or use my > >>> repo directly): > >>> https://github.com/linux-wpan/linux-net-next/commit/546618171de2be30236aab86f3ee323b425e2bf5 > >>> > >>> Regards, > >>> Tony > >>> > >>> Le Wed, 20 Mar 2013 03:03:25 +, > >>> sjs205 a écrit : > >>> > >>>> Hello all, > >>>> > >>>> I'm trying to get an econotag flashed with linux802154-serialdev > >>>> attached to my linux server using the 'azattach' command, > >>>> however, I am constantly getting the following error: > >>>> > >>>> /usr/local/sbin/izattach /dev/ttyUSB1 > >>>> ioctl: TIOCSETD: Invalid argument > >>>> > >>>> This is obviously the same as: > >>>> > >>>> http://comments.gmane.org/gmane.linux.network.zigbee.devel/653 > >>>> > >>>> Which suggests using the 'serial' module. but I can seem to find > >>>> it, Is this still about? > >>>> > >>>> > >>>> sjs205 > -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 01/12] 6lowpan: lowpan_is_iid_16_bit_compressable() does not detect compressible address correctly
The current test is not RFC6282 compliant. The same issue has been found and fixed in Contiki. This patch is basically a port of their fix. Signed-off-by: Tony Cheneau --- net/ieee802154/6lowpan.h | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h index bba5f83..4b8f917 100644 --- a/net/ieee802154/6lowpan.h +++ b/net/ieee802154/6lowpan.h @@ -92,9 +92,10 @@ */ #define lowpan_is_iid_16_bit_compressable(a) \ a)->s6_addr16[4]) == 0) && \ -(((a)->s6_addr16[5]) == 0) && \ -(((a)->s6_addr16[6]) == 0) && \ -a)->s6_addr[14]) & 0x80) == 0)) +(((a)->s6_addr[10]) == 0) && \ +(((a)->s6_addr[11]) == 0xff) &&\ +(((a)->s6_addr[12]) == 0xfe) &&\ +(((a)->s6_addr[13]) == 0)) /* multicast address */ #define is_addr_mcast(a) (((a)->s6_addr[0]) == 0xFF) -- 1.7.12.4 -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 00/12] 6lowpan: Some more bug fixes
Hello, This patchset fixes serious bugs within the 6LoWPAN modules. I wrote a script (available at [1]) to prove the issues are real. One can try and see that without these patches, most of the test fail (e.g. packet dropped by the receiver or node crashing). With all patches applied, all tests succeed. The tests themselves are very basic: sending ICMP packets, sending UDP packets, sending TCP packets, varying size of the packets. This actually triggers some 6LoWPAN specific code, namely fragmentation, packet reassembly and header compression. This code passed the checkpatch.pl tool with a few warnings, that I believe are OK. It should apply cleanly on the latest net-next. Regards, Tony Cheneau [1]: https://github.com/tcheneau/linux802154-regression-tests Tony Cheneau (12): 6lowpan: lowpan_is_iid_16_bit_compressable() does not detect compressible address correctly 6lowpan: next header is not properly set upon decompression of a UDP header. 6lowpan: always enable link-layer acknowledgments mac802154: turn on ACK when enabled by the upper layers 6lowpan: use short IEEE 802.15.4 addresses for broadcast destination 6lowpan: fix first fragment (FRAG1) handling 6lowpan: add debug messages for 6LoWPAN fragmentation 6lowpan: store fragment tag values per device instead of net stack wide mac802154: re-introduce mac802154_dev_get_dsn() 6lowpan: obtain IEEE802.15.4 sequence number from the MAC layer 6lowpan: use the PANID provided by the device instead of a static value 6lowpan: modify udp compression/uncompression to match the standard net/ieee802154/6lowpan.c | 136 +- net/ieee802154/6lowpan.h | 7 ++- net/mac802154/mac802154.h | 1 + net/mac802154/mac_cmd.c | 1 + net/mac802154/mib.c | 9 +++ net/mac802154/wpan.c | 2 + 6 files changed, 127 insertions(+), 29 deletions(-) -- 1.7.12.4 -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 03/12] 6lowpan: always enable link-layer acknowledgments
This feature is especially important when using fragmentation, because the reassembly mechanism cannot recover from the loss of a fragment. Note that some hardware ignore this flag and not will not transmit acknowledgments even if this is set. Signed-off-by: Tony Cheneau --- net/ieee802154/6lowpan.c | 4 1 file changed, 4 insertions(+) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index 9f53904..e7f61de 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -584,6 +584,10 @@ static int lowpan_header_create(struct sk_buff *skb, mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA; + /* request acknowledgment when possible */ + if (!lowpan_is_addr_broadcast(daddr)) + mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ; + return dev_hard_header(skb, lowpan_dev_info(dev)->real_dev, type, (void *)&da, (void *)&sa, skb->len); } -- 1.7.12.4 -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 02/12] 6lowpan: next header is not properly set upon decompression of a UDP header.
This causes a drop of the UDP packet.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 43b95ca..9f53904 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -918,9 +918,11 @@ lowpan_process_data(struct sk_buff *skb)
}
/* UDP data uncompression */
- if (iphc0 & LOWPAN_IPHC_NH_C)
+ if (iphc0 & LOWPAN_IPHC_NH_C) {
if (lowpan_uncompress_udp_header(skb))
goto drop;
+ hdr.nexthdr = UIP_PROTO_UDP;
+ }
/* Not fragmented package */
hdr.payload_len = htons(skb->len);
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 05/12] 6lowpan: use short IEEE 802.15.4 addresses for broadcast destination
The IEEE 802.15.4 standard uses the 0x short address (2 bytes) for message
broadcasting.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index e7f61de..0eebb96 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -572,21 +572,28 @@ static int lowpan_header_create(struct sk_buff *skb,
* this isn't implemented in mainline yet, so currently we assign 0xff
*/
{
+ mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+
/* prepare wpan address data */
sa.addr_type = IEEE802154_ADDR_LONG;
sa.pan_id = 0xff;
-
- da.addr_type = IEEE802154_ADDR_LONG;
- da.pan_id = 0xff;
-
- memcpy(&(da.hwaddr), daddr, 8);
memcpy(&(sa.hwaddr), saddr, 8);
- mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+ da.pan_id = 0xff;
+ /*
+* if the destination address is the broadcast address, use the
+* corresponding short address
+*/
+ if (lowpan_is_addr_broadcast(daddr)) {
+ da.addr_type = IEEE802154_ADDR_SHORT;
+ da.short_addr = IEEE802154_ADDR_BROADCAST;
+ } else {
+ da.addr_type = IEEE802154_ADDR_LONG;
+ memcpy(&(da.hwaddr), daddr, 8);
- /* request acknowledgment when possible */
- if (!lowpan_is_addr_broadcast(daddr))
+ /* request acknowledgment */
mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
+ }
return dev_hard_header(skb, lowpan_dev_info(dev)->real_dev,
type, (void *)&da, (void *)&sa, skb->len);
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 04/12] mac802154: turn on ACK when enabled by the upper layers
Signed-off-by: Tony Cheneau
---
net/mac802154/wpan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac802154/wpan.c b/net/mac802154/wpan.c
index d20c6d3..7d3f659 100644
--- a/net/mac802154/wpan.c
+++ b/net/mac802154/wpan.c
@@ -145,6 +145,8 @@ static int mac802154_header_create(struct sk_buff *skb,
head[pos++] = mac_cb(skb)->seq; /* DSN/BSN */
fc = mac_cb_type(skb);
+ if (mac_cb_is_ackreq(skb))
+ fc |= IEEE802154_FC_ACK_REQ;
if (!saddr) {
spin_lock_bh(&priv->mib_lock);
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 07/12] 6lowpan: add debug messages for 6LoWPAN fragmentation
Add pr_debug() call in order to debug 6LoWPAN fragmentation and
reassembly.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 4a62289..61eee9d 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -742,10 +742,16 @@ lowpan_process_data(struct sk_buff *skb)
/* adds the 3 MSB to the 8 LSB to retrieve the 11 bits length */
len = ((iphc0 & 7) << 8) | slen;
- /* FRAGN */
- if ((iphc0 & LOWPAN_DISPATCH_MASK) != LOWPAN_DISPATCH_FRAG1) {
+ if ((iphc0 & LOWPAN_DISPATCH_MASK) == LOWPAN_DISPATCH_FRAG1) {
+ pr_debug("%s received a FRAG1 packet (tag: %d, "
+"size of the entire IP packet: %d)",
+__func__, tag, len);
+ } else { /* FRAGN */
if (lowpan_fetch_skb_u8(skb, &offset))
goto unlock_and_drop;
+ pr_debug("%s received a FRAGN packet (tag: %d, "
+"size of the entire IP packet: %d, "
+"offset: %d)", __func__, tag, len, offset * 8);
}
/*
@@ -762,6 +768,8 @@ lowpan_process_data(struct sk_buff *skb)
/* alloc new frame structure */
if (!found) {
+ pr_debug("%s first fragment received for tag %d, "
+"begin packet reassembly", __func__, tag);
frame = lowpan_alloc_new_frame(skb, len, tag);
if (!frame)
goto unlock_and_drop;
@@ -784,6 +792,9 @@ lowpan_process_data(struct sk_buff *skb)
list_del(&frame->list);
spin_unlock_bh(&flist_lock);
+ pr_debug("%s successfully reassembled fragment "
+"(tag %d)", __func__, tag);
+
dev_kfree_skb(skb);
skb = frame->skb;
kfree(frame);
@@ -1034,8 +1045,11 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
err = lowpan_fragment_xmit(skb, head, header_length, LOWPAN_FRAG_SIZE,
0, LOWPAN_DISPATCH_FRAG1);
- if (err)
+ if (err) {
+ pr_debug("%s unable to send FRAG1 packet (tag: %d)",
+__func__, tag);
goto exit;
+ }
offset = LOWPAN_FRAG_SIZE;
@@ -1053,8 +1067,11 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
err = lowpan_fragment_xmit(skb, head, header_length,
len, offset, LOWPAN_DISPATCH_FRAGN);
- if (err)
+ if (err) {
+ pr_debug("%s unable to send a subsequent FRAGN packet "
+"(tag: %d, offset: %d", __func__, tag, offset);
goto exit;
+ }
offset += len;
}
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 06/12] 6lowpan: fix first fragment (FRAG1) handling
The first fragment, FRAG1, must contain some payload according to the
specs. However, as it is currently written, the first fragment will
remain empty and only contain the 6lowpan headers.
This patch also extracts the transport layer information from the first
fragment. This information is used later on when uncompressing UDP
header.
Thanks to Wolf-Bastian Pöttner for noticing that the offset value was
not properly initialized.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 0eebb96..4a62289 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -661,7 +661,7 @@ static void lowpan_fragment_timer_expired(unsigned long
entry_addr)
}
static struct lowpan_fragment *
-lowpan_alloc_new_frame(struct sk_buff *skb, u8 len, u16 tag)
+lowpan_alloc_new_frame(struct sk_buff *skb, u16 len, u16 tag)
{
struct lowpan_fragment *frame;
@@ -731,7 +731,7 @@ lowpan_process_data(struct sk_buff *skb)
{
struct lowpan_fragment *frame;
/* slen stores the rightmost 8 bits of the 11 bits length */
- u8 slen, offset;
+ u8 slen, offset = 0;
u16 len, tag;
bool found = false;
@@ -742,6 +742,12 @@ lowpan_process_data(struct sk_buff *skb)
/* adds the 3 MSB to the 8 LSB to retrieve the 11 bits length */
len = ((iphc0 & 7) << 8) | slen;
+ /* FRAGN */
+ if ((iphc0 & LOWPAN_DISPATCH_MASK) != LOWPAN_DISPATCH_FRAG1) {
+ if (lowpan_fetch_skb_u8(skb, &offset))
+ goto unlock_and_drop;
+ }
+
/*
* check if frame assembling with the same tag is
* already in progress
@@ -761,12 +767,6 @@ lowpan_process_data(struct sk_buff *skb)
goto unlock_and_drop;
}
- if ((iphc0 & LOWPAN_DISPATCH_MASK) == LOWPAN_DISPATCH_FRAG1)
- goto unlock_and_drop;
-
- if (lowpan_fetch_skb_u8(skb, &offset)) /* fetch offset */
- goto unlock_and_drop;
-
/* if payload fits buffer, copy it */
if (likely((offset * 8 + skb->len) <= frame->length))
skb_copy_to_linear_data_offset(frame->skb, offset * 8,
@@ -982,13 +982,13 @@ static int lowpan_get_mac_header_length(struct sk_buff
*skb)
static int
lowpan_fragment_xmit(struct sk_buff *skb, u8 *head,
- int mlen, int plen, int offset)
+ int mlen, int plen, int offset, int type)
{
struct sk_buff *frag;
int hlen, ret;
- /* if payload length is zero, therefore it's a first fragment */
- hlen = (plen == 0 ? LOWPAN_FRAG1_HEAD_SIZE : LOWPAN_FRAGN_HEAD_SIZE);
+ hlen = (type == LOWPAN_DISPATCH_FRAG1) ?
+ LOWPAN_FRAG1_HEAD_SIZE : LOWPAN_FRAGN_HEAD_SIZE;
lowpan_raw_dump_inline(__func__, "6lowpan fragment header", head, hlen);
@@ -1031,7 +1031,13 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
head[2] = tag >> 8;
head[3] = tag & 0xff;
- err = lowpan_fragment_xmit(skb, head, header_length, 0, 0);
+ err = lowpan_fragment_xmit(skb, head, header_length, LOWPAN_FRAG_SIZE,
+ 0, LOWPAN_DISPATCH_FRAG1);
+
+ if (err)
+ goto exit;
+
+ offset = LOWPAN_FRAG_SIZE;
/* next fragment header */
head[0] &= ~LOWPAN_DISPATCH_FRAG1;
@@ -1046,10 +1052,14 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
len = payload_length - offset;
err = lowpan_fragment_xmit(skb, head, header_length,
- len, offset);
+ len, offset, LOWPAN_DISPATCH_FRAGN);
+ if (err)
+ goto exit;
+
offset += len;
}
+exit:
return err;
}
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 08/12] 6lowpan: store fragment tag values per device instead of net stack wide
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 61eee9d..f952451 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -104,6 +104,7 @@ static const u8 lowpan_llprefix[] = {0xfe, 0x80};
struct lowpan_dev_info {
struct net_device *real_dev; /* real WPAN device ptr */
struct mutexdev_list_mtx; /* mutex for list ops */
+ unsigned short fragment_tag;
};
struct lowpan_dev_record {
@@ -120,7 +121,6 @@ struct lowpan_fragment {
struct list_headlist; /* fragments list */
};
-static unsigned short fragment_tag;
static LIST_HEAD(lowpan_fragments);
static DEFINE_SPINLOCK(flist_lock);
@@ -1027,14 +1027,14 @@ lowpan_fragment_xmit(struct sk_buff *skb, u8 *head,
}
static int
-lowpan_skb_fragmentation(struct sk_buff *skb)
+lowpan_skb_fragmentation(struct sk_buff *skb, struct net_device *dev)
{
int err, header_length, payload_length, tag, offset = 0;
u8 head[5];
header_length = lowpan_get_mac_header_length(skb);
payload_length = skb->len - header_length;
- tag = fragment_tag++;
+ tag = lowpan_dev_info(dev)->fragment_tag++;
/* first fragment header */
head[0] = LOWPAN_DISPATCH_FRAG1 | ((payload_length >> 8) & 0x7);
@@ -1099,7 +1099,7 @@ static netdev_tx_t lowpan_xmit(struct sk_buff *skb,
struct net_device *dev)
}
pr_debug("frame is too big, fragmentation is needed\n");
- err = lowpan_skb_fragmentation(skb);
+ err = lowpan_skb_fragmentation(skb, dev);
error:
dev_kfree_skb(skb);
out:
@@ -1243,6 +1243,7 @@ static int lowpan_newlink(struct net *src_net, struct
net_device *dev,
return -ENODEV;
lowpan_dev_info(dev)->real_dev = real_dev;
+ lowpan_dev_info(dev)->fragment_tag = 0;
mutex_init(&lowpan_dev_info(dev)->dev_list_mtx);
entry = kzalloc(sizeof(struct lowpan_dev_record), GFP_KERNEL);
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 09/12] mac802154: add mac802154_dev_get_dsn()
Bring-over mac802154_dev_get_dsn() function that was present in the
Linux ZigBee kernel. This function is called by the 6LoWPAN code in
order to properly set the DSN (Data Sequence Number) value in the IEEE
802.15.4 frame.
Signed-off-by: Tony Cheneau
---
net/mac802154/mac802154.h | 1 +
net/mac802154/mac_cmd.c | 1 +
net/mac802154/mib.c | 9 +
3 files changed, 11 insertions(+)
diff --git a/net/mac802154/mac802154.h b/net/mac802154/mac802154.h
index a4dcaf1..21fa386 100644
--- a/net/mac802154/mac802154.h
+++ b/net/mac802154/mac802154.h
@@ -114,5 +114,6 @@ void mac802154_dev_set_ieee_addr(struct net_device *dev);
u16 mac802154_dev_get_pan_id(const struct net_device *dev);
void mac802154_dev_set_pan_id(struct net_device *dev, u16 val);
void mac802154_dev_set_page_channel(struct net_device *dev, u8 page, u8 chan);
+u8 mac802154_dev_get_dsn(const struct net_device *dev);
#endif /* MAC802154_H */
diff --git a/net/mac802154/mac_cmd.c b/net/mac802154/mac_cmd.c
index d8d2770..a99910d 100644
--- a/net/mac802154/mac_cmd.c
+++ b/net/mac802154/mac_cmd.c
@@ -73,4 +73,5 @@ struct ieee802154_mlme_ops mac802154_mlme_wpan = {
.start_req = mac802154_mlme_start_req,
.get_pan_id = mac802154_dev_get_pan_id,
.get_short_addr = mac802154_dev_get_short_addr,
+ .get_dsn = mac802154_dev_get_dsn,
};
diff --git a/net/mac802154/mib.c b/net/mac802154/mib.c
index f47781a..f03e55f 100644
--- a/net/mac802154/mib.c
+++ b/net/mac802154/mib.c
@@ -159,6 +159,15 @@ void mac802154_dev_set_pan_id(struct net_device *dev, u16
val)
}
}
+u8 mac802154_dev_get_dsn(const struct net_device *dev)
+{
+ struct mac802154_sub_if_data *priv = netdev_priv(dev);
+
+ BUG_ON(dev->type != ARPHRD_IEEE802154);
+
+ return priv->dsn++;
+}
+
static void phy_chan_notify(struct work_struct *work)
{
struct phy_chan_notify_work *nw = container_of(work,
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 10/12] 6lowpan: obtain IEEE802.15.4 sequence number from the MAC layer
Sets the sequence number in the frame format. Without this fix, the sequence
number is always set to 0. This makes trafic analysis very hard.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index f952451..d1d4ee6 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -573,6 +573,7 @@ static int lowpan_header_create(struct sk_buff *skb,
*/
{
mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+ mac_cb(skb)->seq = ieee802154_mlme_ops(dev)->get_dsn(dev);
/* prepare wpan address data */
sa.addr_type = IEEE802154_ADDR_LONG;
@@ -1127,6 +1128,12 @@ static u16 lowpan_get_short_addr(const struct net_device
*dev)
return ieee802154_mlme_ops(real_dev)->get_short_addr(real_dev);
}
+static u8 lowpan_get_dsn(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_dsn(real_dev);
+}
+
static struct header_ops lowpan_header_ops = {
.create = lowpan_header_create,
};
@@ -1140,6 +1147,7 @@ static struct ieee802154_mlme_ops lowpan_mlme = {
.get_pan_id = lowpan_get_pan_id,
.get_phy = lowpan_get_phy,
.get_short_addr = lowpan_get_short_addr,
+ .get_dsn = lowpan_get_dsn,
};
static void lowpan_setup(struct net_device *dev)
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 11/12] 6lowpan: use the PANID provided by the device instead of a static value
Signed-off-by: Tony Cheneau --- net/ieee802154/6lowpan.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index d1d4ee6..276971b 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -577,10 +577,12 @@ static int lowpan_header_create(struct sk_buff *skb, /* prepare wpan address data */ sa.addr_type = IEEE802154_ADDR_LONG; - sa.pan_id = 0xff; + sa.pan_id = ieee802154_mlme_ops(dev)->get_pan_id(dev); + memcpy(&(sa.hwaddr), saddr, 8); + /* intra-PAN communications */ + da.pan_id = ieee802154_mlme_ops(dev)->get_pan_id(dev); - da.pan_id = 0xff; /* * if the destination address is the broadcast address, use the * corresponding short address -- 1.7.12.4 -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 net-next 12/12] 6lowpan: modify udp compression/uncompression to match the standard
The previous code would just compress the UDP header and send the compressed
UDP header along with the uncompressed one.
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 39 ---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 276971b..c9c3f3d 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -284,6 +284,9 @@ lowpan_compress_udp_header(u8 **hc06_ptr, struct sk_buff
*skb)
/* checksum is always inline */
memcpy(*hc06_ptr, &uh->check, 2);
*hc06_ptr += 2;
+
+ /* skip the UDP header */
+ skb_pull(skb, sizeof(struct udphdr));
}
static inline int lowpan_fetch_skb_u8(struct sk_buff *skb, u8 *val)
@@ -309,9 +312,8 @@ static inline int lowpan_fetch_skb_u16(struct sk_buff *skb,
u16 *val)
}
static int
-lowpan_uncompress_udp_header(struct sk_buff *skb)
+lowpan_uncompress_udp_header(struct sk_buff *skb, struct udphdr *uh)
{
- struct udphdr *uh = udp_hdr(skb);
u8 tmp;
if (!uh)
@@ -358,6 +360,14 @@ lowpan_uncompress_udp_header(struct sk_buff *skb)
/* copy checksum */
memcpy(&uh->check, &skb->data[0], 2);
skb_pull(skb, 2);
+
+ /*
+* UDP lenght needs to be infered from the lower layers
+* here, we obtain the hint from the remaining size of the
+* frame
+*/
+ uh->len = htons(skb->len + sizeof(struct udphdr));
+ pr_debug("uncompressed UDP length: src = %d", uh->len);
} else {
pr_debug("ERROR: unsupported NH format\n");
goto err;
@@ -944,8 +954,31 @@ lowpan_process_data(struct sk_buff *skb)
/* UDP data uncompression */
if (iphc0 & LOWPAN_IPHC_NH_C) {
- if (lowpan_uncompress_udp_header(skb))
+ struct udphdr uh;
+ struct sk_buff *new;
+ if (lowpan_uncompress_udp_header(skb, &uh))
goto drop;
+
+ /*
+* replace the compressed UDP head by the uncompressed UDP
+* header
+*/
+ new = skb_copy_expand(skb, sizeof(struct udphdr),
+ skb_tailroom(skb), GFP_ATOMIC);
+ kfree_skb(skb);
+
+ if (!new)
+ return -ENOMEM;
+
+ skb = new;
+
+ skb_push(skb, sizeof(struct udphdr));
+ skb_reset_transport_header(skb);
+ skb_copy_to_linear_data(skb, &uh, sizeof(struct udphdr));
+
+ lowpan_raw_dump_table(__func__, "raw UDP header dump",
+ (u8 *)&uh, sizeof(uh));
+
hdr.nexthdr = UIP_PROTO_UDP;
}
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
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] net/ieee802154/6lowpan: Fix initialization for fragment offset
Hi Wolf-Bastien,
I sent my patchset yesterday to the netdev mailing list and it was
merged into net-next today. Given that you patch was based on one of my
changes, I added it to the corresponding patch. I hope you don't mind.
Here is the link to the patch where I incorporated your fix:
http://marc.info/?l=linux-netdev&m=136427109431193&w=2
Thank you a lot for your patch, without it, it would probably have gone
unnoticed for quite some time.
Regards,
Tony
Le Fri, 8 Mar 2013 13:18:14 +0100,
Wolf-Bastian Pöttner a écrit :
>
> offset has to be initialized, otherwise the *first* fragment will
> be discarded and reassembly cannot happen.
> ---
> net/ieee802154/6lowpan.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
> index ed3debe..2db7261 100644
> --- a/net/ieee802154/6lowpan.c
> +++ b/net/ieee802154/6lowpan.c
> @@ -745,7 +745,7 @@ lowpan_process_data(struct sk_buff *skb)
> {
> struct lowpan_fragment *frame;
> /* slen stores the rightmost 8 bits of the 11 bits
> length */
> - u8 slen, offset;
> + u8 slen, offset = 0;
> u16 len, tag;
> bool found = false;
>
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 1/2] 6lowpan: fix a small formatting issue
This formatting issue was introduced with commit
d4ac32365dcbfd341a87eae444c26679f889249a
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index c9c3f3d..f4969d7 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -104,7 +104,7 @@ static const u8 lowpan_llprefix[] = {0xfe, 0x80};
struct lowpan_dev_info {
struct net_device *real_dev; /* real WPAN device ptr */
struct mutexdev_list_mtx; /* mutex for list ops */
- unsigned short fragment_tag;
+ unsigned short fragment_tag;
};
struct lowpan_dev_record {
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 0/2] 6lowpan: fix minor issues introduced with the previous patch set
Few minor issues were reported by Alexander Aring and Sergei Shtylyov on my
previous 6lowpan patch set (named "6lowpan: Some more bug fixes").
Sadly, I didn't had time to address them before the code was merged into
net-next. These two (short) patches fix them.
I'm sorry for the mess I caused.
Regards,
Tony Cheneau
Tony Cheneau (2):
6lowpan: fix a small formatting issue
6lowpan: use IEEE802154_ADDR_LEN instead of a magic number
net/ieee802154/6lowpan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next 2/2] 6lowpan: use IEEE802154_ADDR_LEN instead of a magic number
Signed-off-by: Tony Cheneau
---
net/ieee802154/6lowpan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index f4969d7..e1b4580 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -602,7 +602,7 @@ static int lowpan_header_create(struct sk_buff *skb,
da.short_addr = IEEE802154_ADDR_BROADCAST;
} else {
da.addr_type = IEEE802154_ADDR_LONG;
- memcpy(&(da.hwaddr), daddr, 8);
+ memcpy(&(da.hwaddr), daddr, IEEE802154_ADDR_LEN);
/* request acknowledgment */
mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
--
1.7.12.4
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] Announcing the first public release of SimpleRPL
Hello, I'm glad to announce the first release of SimpleRPL, a Linux-based implementation of the Routing Protocol for Low-Power and Lossy Networks (RPL). This protocol has been developed at the IETF as an attempt to define a routing protocol suitable for lossy and low bandwidth link-layer (such as IEEE 802.15.4). It operates on top of IPv6 using ICMPv6 messages. You can learn more about it in RFC 6550. This implementation is a fully functional (and hopefully fully compliant) implementation of the standard. I tested it on both wired and wireless links and it ran just fine, although you might want to adjust some constant value (as I picked the default values from the RFC and did not performed any fine tuning to it). I could not test simpleRPL against the Contiki' implementation of RPL (due to the current 6LoWPAN interrop issues between Linux and Contiki). The GitHub project page provide more information concerning the limitations and various design choices. Once I'm confident it runs correctly (through your feedback), I'll announce it to a wider audience. The implementation is currently hosted on GitHub: https://github.com/tcheneau/simpleRPL Thanks in advance for all your feedback. Regards, Tony -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
Hi Robert, Thanks for your comment, I knew someone would raise that point. Allow me clarify things a little (in no particular order): - I wanted an implementation of RPL that could run on Linux that that I could turn a Linux box into a 6LoWPAN border router. There was no such implementation, so I wrote one. - I wanted to check how long it would take me to prototype a routing protocol in Python. - I think people would mostly using SimpleRPL as a DODAG Root (and be the data "sink" in a WSN). It is commonly acknowledged that the "sink" in Wireless Sensor Networks has more computational power than the sensors themselves. - finally, I wanted to point out that my main target is a PC, not an embedded board. That being said, the implementation currently uses 12MB of RAM, without any particular optimizations. Now, let's look at some potential targets (i.e. embedded hardware that people use around here): - Raspberry Pi: 256MB of RAM (for Model A and Model B rev1) - Beaglebone: 256MB of RAM - Ben-Nanonote: 32MB of RAM - A wireless router using OpenWRT (such as the TP-Link TL-WR1043ND): 32MB of RAM - (obviously, there is plenty OpenWRT enabled routers with way less RAM, and these ones won't be able to run SimpleRPL) - RedBee M12: 32MB of RAM (note that this device is a 6LoWPAN Border Router) Sensor devices with only a few kB of RAM are expected to run a sensor operating system, and have specific RPL implementation (such as Contiki RPL). The "gap", where SimpleRPL would not run, is for devices that have less than 32MB of RAM (they obviously still qualify as embedded, but it's just not my target). As for the need for computational power, it's RPL, it does not need much (by design). Regards, Tony Cheneau Le 2013-04-04 08:17, Robert Schwebel a écrit : > On Thu, Apr 04, 2013 at 12:02:30AM +0200, Tony Cheneau wrote: >> I'm glad to announce the first release of SimpleRPL, a Linux-based >> implementation of the Routing Protocol for Low-Power and Lossy >> Networks (RPL). > > You do that in ... Python? How does that fit with the fact that a lot > of > 802.15.4 devices will be deeply embedded, highly optimized for power > and > thus hardly have more ressources than necessary? > > However, a python implementation is in any case a good start, and > optimization or a port to C can of course be done later (TM). > > rsc -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
Hi Ralph, I would *definitely* test your patches if you were to release them. Regards, Tony Le 2013-04-04 17:19, Ralph Droms (rdroms) a écrit : > I've seen several mentions of Contiki-Linux interoperability issues. > I have some preliminary fixes for address compression and > fragletting, > which seem to work OK when tested against a couple of (fairly old) > Contiki builds. Would anyone be interesting in testing these fixes > if > I publish a few patches? > > - Ralph > > > > -- > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > ___ > Linux-zigbee-devel mailing list > Linux-zigbee-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
Hi Markus, I'd be very interested if you had any thoughts on retrieving the link quality metrics. My understanding is that Contiki uses it for its Objective Function (both OF0 and ETX). In my SimpleRPL, I don't retrieve anything for now, because I haven't figured out a proper way to pass it to the userspace. (Also, it's great to learn that someone is working on a competing implementation. :) ) Regards, Tony Le 2013-04-04 16:46, Markus Becker a écrit : > Hi, > > some time ago I started porting Contiki's RPL implementation to > Linux. Because > of the same Contiki/linux-154 interop issues mentioned below, I > stopped > progressing further. The current state of it is, that it compiles > with some > most likely necessary stuff commented out. > > The repository is at: https://github.com/markushx/librpl > > Once I get the RPi kernel compiles with the latest 6lowpan changes, I > might > try to run it again against Contiki. > > Markus > >> Hello, >> >> I'm glad to announce the first release of SimpleRPL, a Linux-based >> implementation of the Routing Protocol for Low-Power and Lossy >> Networks >> (RPL). >> This protocol has been developed at the IETF as an attempt to define >> a >> routing >> protocol suitable for lossy and low bandwidth link-layer (such as >> IEEE >> 802.15.4). It operates on top of IPv6 using ICMPv6 messages. You can >> learn more >> about it in RFC 6550. >> >> This implementation is a fully functional (and hopefully fully >> compliant) >> implementation of the standard. I tested it on both wired and >> wireless >> links >> and it ran just fine, although you might want to adjust some >> constant >> value (as >> I picked the default values from the RFC and did not performed any >> fine >> tuning >> to it). I could not test simpleRPL against the Contiki' >> implementation >> of RPL >> (due to the current 6LoWPAN interrop issues between Linux and >> Contiki). >> The >> GitHub project page provide more information concerning the >> limitations >> and >> various design choices. >> >> Once I'm confident it runs correctly (through your feedback), I'll >> announce it >> to a wider audience. >> >> The implementation is currently hosted on GitHub: >> https://github.com/tcheneau/simpleRPL >> >> Thanks in advance for all your feedback. >> >> Regards, >> Tony >> >> >> --- >> --- Minimize network downtime and maximize team effectiveness. >> Reduce network management and security costs.Learn how to hire >> the most talented Cisco Certified professionals. Visit the >> Employer Resources Portal >> http://www.cisco.com/web/learning/employer_resources/index.html >> ___ >> Linux-zigbee-devel mailing list >> Linux-zigbee-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel > > | Dipl.-Ing. Markus Becker > | Communication Networks > | TZI - Center for Computing Technologies > | University Bremen > | Germany > > | web: http://www.comnets.uni-bremen.de/~mab/ > | mailto: m...@comnets.uni-bremen.de > | telephone: +49 421 218 62379 > | building: NW1 room: N2260 > > > > -- > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > ___ > Linux-zigbee-devel mailing list > Linux-zigbee-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
Hi, >> I'd be very interested if you had any thoughts on retrieving the >> link >> quality metrics. My understanding is that Contiki uses it for its >> Objective Function (both OF0 and ETX). > > Yes, RPL uses link-layer information (ETX). It uses it for both, OF0 > and MRHOF > (latter unfortunately named rpl-of-etx.c). Thanks for the information. It's true that the name is rather misleading. >> In my SimpleRPL, I don't retrieve >> anything for now, because I haven't figured out a proper way to pass >> it >> to the userspace. > > I haven't even started thinking about that. But is the link-layer > information > really needed at the RPL DODAG root? SimpleRPL also aims to provide a RPL router function (i.e. node that doesn't act as the DODAG Root). > I thought the routes are installed by > DAOs which are sent by the non-root nodes (which are basing their > parent > selection on the link-layer information). The link-layer information > of the > DAO is not used AFAIK. Then there would be no need for passing it to > userspace. Yes, DAO are used to build the downward routes. DAO messages are sent to routers belonging to the DAO parent set (which is a subset of the DODAG parent set). The DODAG parent set is computed using the node's own rank and the rank of its neighbors. In the case of the OF0, the rank computation is influenced by the link quality (when available). Regards, Tony -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
Hi Ralph, I'll test it over the course of the week-end or at the beginning of the next week. Thanks. Regards, Tony Le 2013-04-05 14:33, Ralph Droms (rdroms) a écrit : > Attached are the patches for fixing link-local address decompression. > Comments welcome... > > - Ralph -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
Hi Jon, From the last talk I had with Michael Richardson on his implementation, it was not functional. It can send some of the RPL messages, but no code logic is present to interpret them, etc. Regards, Tony Le 2013-04-05 18:50, jonsm...@gmail.com a écrit : > There is another Linux RPL implementation here. > https://github.com/mcr/unstrung > > How does these relate to each other? -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ 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 0/3] Patches to 6lowpan.c to fix link-local address uncompression
Hi Ralph, First, thank you for your patches. I've tested them yesterday. Because I didn't had enough hardware to perform a proper packet capture, so I just checked the connectivity. I could run all my regression tests (ICMP, TCP, UDP, varying packet length) between two linux hosts with your patches applied. They all passed and looked fine. I could also do basic interrop with Contiki (yeah!). Using one linux host with your patches, I could ping a Contiki device on its Link-Local Address (I could not ping the global address though, but I guess it's not supposed to be fixed by this patch, and I'll need to look more into it). I did not modify the Contiki example much, so I could not check that UDP/TCP would work as well (those are done using the global addresses by default). Still, I can also confirm that without the patches, the ping echo requests are just not answered. From a functional perspective, your patches look fine. I didn't checked that your patches are good from a logical point of view (making sure they indeed match the RFC better). I'll try to read both RFC 4944 and RFC 6282 today, and provide additional comments. Regards, Tony Le 2013-04-11 13:51, Ralph Droms a écrit : > These patches fix link-local address uncompression, for both source > and destination addresses. > > - Ralph > > Ralph Droms (3): > net/ieee802154: 6lowpan.c: Fixes for stateless address > decompression > to use MAC address > net/ieee802154: 6lowpan.c: This patch fixes source address > uncompression to send the MAC address to lowpan_uncompress_addr > net/ieee802154: 6lowpan.c: This patch fixes destination address > uncompression to send the MAC address to lowpan_uncompress_addr > > net/ieee802154/6lowpan.c | 53 > +++-- > 1 files changed, 32 insertions(+), 21 deletions(-) -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ 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/3] net/ieee802154: 6lowpan.c: Fixes for stateless address decompression to use MAC address
Hi Ralph, Just a quick comment. Le 2013-04-11 13:51, Ralph Droms a écrit : > Stateless decompression mode 3 combines the MAC address from the MAC > header > with link-local prefix FE80::/64 to reconstruct the original IPv6 > address. > This patch corrects comments, variable llconf and > lowpan_uncompress_addr > to be compatible with RFC 4644. I believe you mean RFC 4944 here. Regards, Tony -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ 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 0/3] Patches to 6lowpan.c to fix link-local address uncompression
Hi Christophe, I assigned the fe80::/64 addresses manually because I need to know them for the script. Because they are derived from the MAC address, it could have happened that I don't know them at the time I run the script. However, you're right: in my specific setup, I have the control over the MAC address that is assigned on the node, so I should be able to derive the fe80:: address easily. Now, you say that assigned addresses and SLAAC addresses behave differently. I thought it was a sorted out not that long ago. Could you be more specific about the issue you encountered? Regards, Tony Le 2013-04-11 16:22, Christophe Aeschlimann a écrit : > Hi Tony, > > Le 11.04.2013 15:57, Tony Cheneau a écrit : >> Hi Ralph, >> >> First, thank you for your patches. I've tested them yesterday. >> Because >> I didn't had enough hardware to perform a proper packet capture, so >> I >> just checked the connectivity. >> >> I could run all my regression tests (ICMP, TCP, UDP, varying packet >> length) between two linux hosts with your patches applied. They all >> passed and looked fine. > > I had a look at your regression test script, cool stuff. I adapted it > a > bit to allow to remote control my units (not full PC). Is there a > reason > why you configure the fe80:: addresses manually ? Shouldn't you use > the > one automatically generated ? I've seen differences here between the > two > cases. > > Best regards, -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ 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 0/3] Patches to 6lowpan.c to fix link-local address uncompression
Hi, Replying to myself. Christophe's email made me realize that I use additional Link-Local addresses that are not obtained through SLAAC. This means that my test between the two Linux hosts are completely useless (as it might have not made any use of your new code). I'll perform some additional tests tonight and let you know the outcome. The test I performed with Contiki stands, because it verifies that a Linux host can understand a compressed header sent from a Contiki-enabled mote. As a side note, I read RFC 4944 and RFC 6282 (this is what you implemented actually) and I'd say the current code pretty much follow the standard. I'm not too sure it would work well with short addresses, but that not part of your patch anyway. The whole address uncompression would need to be rewritten IMHO (and I believe Alexander Arig is on it). Regards, Tony Le 2013-04-11 15:57, Tony Cheneau a écrit : > Hi Ralph, > > First, thank you for your patches. I've tested them yesterday. > Because > I didn't had enough hardware to perform a proper packet capture, so I > just checked the connectivity. > > I could run all my regression tests (ICMP, TCP, UDP, varying packet > length) between two linux hosts with your patches applied. They all > passed and looked fine. > > I could also do basic interrop with Contiki (yeah!). Using one linux > host with your patches, I could ping a Contiki device on its > Link-Local > Address (I could not ping the global address though, but I guess it's > not supposed to be fixed by this patch, and I'll need to look more > into > it). I did not modify the Contiki example much, so I could not check > that UDP/TCP would work as well (those are done using the global > addresses by default). Still, I can also confirm that without the > patches, the ping echo requests are just not answered. > > From a functional perspective, your patches look fine. I didn't > checked > that your patches are good from a logical point of view (making sure > they indeed match the RFC better). I'll try to read both RFC 4944 and > RFC 6282 today, and provide additional comments. > > Regards, > Tony > > > Le 2013-04-11 13:51, Ralph Droms a écrit : >> These patches fix link-local address uncompression, for both source >> and destination addresses. >> >> - Ralph >> >> Ralph Droms (3): >> net/ieee802154: 6lowpan.c: Fixes for stateless address >> decompression >> to use MAC address >> net/ieee802154: 6lowpan.c: This patch fixes source address >> uncompression to send the MAC address to lowpan_uncompress_addr >> net/ieee802154: 6lowpan.c: This patch fixes destination address >> uncompression to send the MAC address to lowpan_uncompress_addr >> >> net/ieee802154/6lowpan.c | 53 >> +++-- >> 1 files changed, 32 insertions(+), 21 deletions(-) > > > -- > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for > building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free > account! > http://www2.precog.com/precogplatform/slashdotnewsletter > ___ > Linux-zigbee-devel mailing list > Linux-zigbee-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ 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/3] net/ieee802154: 6lowpan.c: Fixes for stateless address decompression to use MAC address
Hi again,
Just nitpicking here:
Le 2013-04-11 13:51, Ralph Droms a écrit :
> Stateless decompression mode 3 combines the MAC address from the MAC
> header
> with link-local prefix FE80::/64 to reconstruct the original IPv6
> address.
> This patch corrects comments, variable llconf and
> lowpan_uncompress_addr
> to be compatible with RFC 4644.
>
> Signed-off-by: Ralph Droms
> ---
> net/ieee802154/6lowpan.c | 50
> +++--
> 1 files changed, 30 insertions(+), 20 deletions(-)
>
> diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
> index 55e1fd5..a7bac63 100644
> --- a/net/ieee802154/6lowpan.c
> +++ b/net/ieee802154/6lowpan.c
> @@ -68,32 +68,32 @@ static const u8 lowpan_ttl_values[] = {0, 1, 64,
> 255};
> static LIST_HEAD(lowpan_devices);
>
> /*
> - * Uncompression of linklocal:
> + * Uncompression of stateless unicast:
> * 0 -> 16 bytes from packet
> * 1 -> 2 bytes from prefix - bunch of zeroes and 8 from packet
> * 2 -> 2 bytes from prefix - zeroes + 2 from packet
> - * 3 -> 2 bytes from prefix - infer 8 bytes from lladdr
> + * 3 -> 2 bytes from prefix - IID == MAC
IID is derived from MAC but is not equal to the MAC (with the whole u/g
bit flipping business). You might want to change your comment to reflect
that.
> * NOTE: => the uncompress function does change 0xf to 0x10
> * NOTE: 0x00 => no-autoconfig => unspecified
> */
> -static const u8 lowpan_unc_llconf[] = {0x0f, 0x28, 0x22, 0x20};
> +static const u8 lowpan_unc_slconf[] = {0x0f, 0x28, 0x22, 0x20};
>
> /*
> * Uncompression of ctx-based:
> * 0 -> 0 bits from packet [unspecified / reserved]
> * 1 -> 8 bytes from prefix - bunch of zeroes and 8 from packet
> * 2 -> 8 bytes from prefix - zeroes + 2 from packet
> - * 3 -> 8 bytes from prefix - infer 8 bytes from lladdr
> + * 3 -> 8 bytes from prefix - IID == MAC
Probably the same thing here.
[...]
> - pr_debug("dest: stateless compression\n");
> + pr_debug("stateless compression\n");
I think it would be better for the comment to be "stateless destination
compression\n" (perhaps this is what you intended to write, judging from
your previous comments).
Hope it helps.
Regards,
Tony
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
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 0/3] Patches to 6lowpan.c to fix link-local address uncompression
Hi, Replying to myself again. I made some tests, using only Link-Local addresses this time. Ping worked just fine (between two Linux host and between a Contiki mote and a Linux host). I did not test other transport protocols, as they should not be affected by the patchset anyway. Regards, Tony Le 2013-04-11 22:26, Tony Cheneau a écrit : > Hi, > > Replying to myself. Christophe's email made me realize that I use > additional Link-Local addresses that are not obtained through SLAAC. > This means that my test between the two Linux hosts are completely > useless (as it might have not made any use of your new code). I'll > perform some additional tests tonight and let you know the outcome. > The test I performed with Contiki stands, because it verifies that a > Linux host can understand a compressed header sent from a > Contiki-enabled mote. > > As a side note, I read RFC 4944 and RFC 6282 (this is what you > implemented actually) and I'd say the current code pretty much follow > the standard. I'm not too sure it would work well with short > addresses, > but that not part of your patch anyway. The whole address > uncompression > would need to be rewritten IMHO (and I believe Alexander Arig is on > it). > > Regards, > Tony > > Le 2013-04-11 15:57, Tony Cheneau a écrit : >> Hi Ralph, >> >> First, thank you for your patches. I've tested them yesterday. >> Because >> I didn't had enough hardware to perform a proper packet capture, so >> I >> just checked the connectivity. >> >> I could run all my regression tests (ICMP, TCP, UDP, varying packet >> length) between two linux hosts with your patches applied. They all >> passed and looked fine. >> >> I could also do basic interrop with Contiki (yeah!). Using one linux >> host with your patches, I could ping a Contiki device on its >> Link-Local >> Address (I could not ping the global address though, but I guess >> it's >> not supposed to be fixed by this patch, and I'll need to look more >> into >> it). I did not modify the Contiki example much, so I could not check >> that UDP/TCP would work as well (those are done using the global >> addresses by default). Still, I can also confirm that without the >> patches, the ping echo requests are just not answered. >> >> From a functional perspective, your patches look fine. I didn't >> checked >> that your patches are good from a logical point of view (making sure >> they indeed match the RFC better). I'll try to read both RFC 4944 >> and >> RFC 6282 today, and provide additional comments. >> >> Regards, >> Tony >> >> >> Le 2013-04-11 13:51, Ralph Droms a écrit : >>> These patches fix link-local address uncompression, for both source >>> and destination addresses. >>> >>> - Ralph >>> >>> Ralph Droms (3): >>> net/ieee802154: 6lowpan.c: Fixes for stateless address >>> decompression >>> to use MAC address >>> net/ieee802154: 6lowpan.c: This patch fixes source address >>> uncompression to send the MAC address to lowpan_uncompress_addr >>> net/ieee802154: 6lowpan.c: This patch fixes destination address >>> uncompression to send the MAC address to lowpan_uncompress_addr >>> >>> net/ieee802154/6lowpan.c | 53 >>> +++-- >>> 1 files changed, 32 insertions(+), 21 deletions(-) >> >> >> >> -- >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for >> building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free >> account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> ___ >> Linux-zigbee-devel mailing list >> Linux-zigbee-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel > > > -- > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for > building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free > account! > http://www2.precog.com/precogplatform/slashdotne
[Linux-zigbee-devel] [PATCH 0/1] Enable izattach to change the baudrate
This is a small patch for the izattach (part of the linux-zigbee userspace tools). It enables the user to select the baudrate when communicating with their IEEE 802.15.4 serial device. To the best of my knowledge, the only device making use of the izattach tool for the moment is the Redbee Econotag (whose default speed is the same as the default speed of the izattach). However is easy to modify the Econotag firmware to increase the baudrate of the UART. When that happens, izattach must also communicate at the same speed. Comments are welcomed. Regards, Tony Tony Cheneau (1): izattach: enable custom baudrate src/serial.c | 109 ++- 1 file changed, 85 insertions(+), 24 deletions(-) -- 1.8.1.5 -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 1/1] izattach: enable custom baudrate
Add a "baudrate" parameter on the CLI that enables the user to choose
from different baudrates. If no parameter is passed, the baudrate is set
to 115200 (retaining the previous behavior).
Signed-off-by: Tony Cheneau
---
src/serial.c | 109 ++-
1 file changed, 85 insertions(+), 24 deletions(-)
diff --git a/src/serial.c b/src/serial.c
index 252f3d9..2dd2228 100644
--- a/src/serial.c
+++ b/src/serial.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
@@ -32,33 +33,93 @@
#include
#include
#include
+#include
#include "ieee802154.h"
+#ifdef HAVE_GETOPT_LONG
+static const struct option iz_long_opts[] = {
+ { "baudrate", optional_argument, NULL, 'b' },
+ { "help", no_argument, NULL, 'h' },
+ { NULL, 0, NULL, 0 },
+};
+#endif
+
+void serial_help(const char * pname) {
+printf("Usage: %s [options] SERIAL_DEV\n", pname);
+printf("Attach serial devices via UART to IEEE 802.15.4/ZigBee stack\n\n");
+ printf("Options:\n");
+ printf(" -b, --baudrate[=115200]set the baudrate\n");
+ printf(" -h, --help print help\n");
+printf(" SERIAL_DEV this specifies the serial device
to attach.\n");
+printf("Report bugs to " PACKAGE_BUGREPORT "\n\n");
+printf(PACKAGE_NAME " homepage <" PACKAGE_URL ">\n");
+}
+
+speed_t baudrate_to_speed(long baudrate) {
+switch(baudrate) {
+case 9600: return B9600;
+case 19200: return B19200;
+case 38400: return B38400;
+case 57600: return B57600;
+case 115200: return B115200;
+case 230400: return B230400;
+case 460800: return B460800;
+case 921600: return B921600;
+default:
+printf("Unrecognized baudrate %ld\n", baudrate);
+exit(EXIT_FAILURE);
+}
+}
+
int main(int argc, char **argv) {
- int fd, ret, s;
-
- if (argc == 1 || !strcmp(argv[1], "--version")) {
- printf( "izattach " VERSION "\n"
- "Copyright (C) 2008, 2009 by Siemens AG\n"
- "License GPLv2 GNU GPL version 2
<http://gnu.org/licenses/gpl.html>.\n"
- "This is free software: you are free to change and
redistribute it.\n"
- "There is NO WARRANTY, to the extent permitted by
law.\n"
- "\n"
- "Written by Dmitry Eremin-Solenikov, Sergey Lapin and
Maxim Osipov\n");
- return 0;
+ int fd, ret, s, c;
+long baudrate;
+char * endptr;
+speed_t speed = B115200;
+
+ /* Parse options */
+ while (1) {
+#ifdef HAVE_GETOPT_LONG
+ int opt_idx = -1;
+ c = getopt_long(argc, argv, "b:h", iz_long_opts, &opt_idx);
+#else
+ c = getopt(argc, argv, "b:h");
+#endif
+ if (c == -1)
+ break;
+
+ switch(c) {
+case 'h':
+serial_help(argv[0]);
+return 0;
+ case 'b':
+baudrate = strtol(optarg, &endptr, 10);
+if (* endptr == '\0')
+speed = baudrate_to_speed(baudrate);
+ break;
+ case 'v':
+printf("izattach " VERSION "\n"
+"Copyright (C) 2008, 2009 by Siemens AG\n"
+"License GPLv2 GNU GPL version 2
<http://gnu.org/licenses/gpl.html>.\n"
+"This is free software: you are free to change and
redistribute it.\n"
+"There is NO WARRANTY, to the extent permitted by law.\n"
+"\n"
+"Written by Dmitry Eremin-Solenikov, Sergey Lapin and Maxim
Osipov\n");
+return 0;
+ default:
+ serial_help(argv[0]);
+ return 1;
+ }
}
- if (argc != 2 || (argc >= 1 && !strcmp(argv[1], "--help"))) {
- printf("Usage: %s SERIAL_DEV\n", argv[0]);
- printf("Attach serial devices via UART to IEEE 802.15.4/ZigBee
stack\n\n");
- printf(" SERIAL_DEV This specifies the serial device to
attach.\n");
- printf("Report bugs to " PACKAGE_BUGREPORT "\n\n");
- printf(PACKAGE_NAME " homepage <" PACKAGE_URL ">\n");
- return 1;
- }
+if (a
Re: [Linux-zigbee-devel] [PATCH 1/1] izattach: enable custom baudrate
Hi,
Thanks Alan. I'll correct the spacing issue and split the patch in two:
one for getopt, and one for the baudrate setting.
Regards,
Tony
Le 2013-04-19 15:03, Alan Ott a écrit :
> On 04/17/2013 05:23 PM, Tony Cheneau wrote:
>> Add a "baudrate" parameter on the CLI that enables the user to
>> choose
>> from different baudrates. If no parameter is passed, the baudrate is
>> set
>> to 115200 (retaining the previous behavior).
>>
>> Signed-off-by: Tony Cheneau
>> ---
>
> It looks like your editor is indenting 4 spaces instead of a tab.
>
>
>> src/serial.c | 109
>> ++-
>> 1 file changed, 85 insertions(+), 24 deletions(-)
>>
>> diff --git a/src/serial.c b/src/serial.c
>> index 252f3d9..2dd2228 100644
>> --- a/src/serial.c
>> +++ b/src/serial.c
>> @@ -25,6 +25,7 @@
>>
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -32,33 +33,93 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "ieee802154.h"
>>
>> +#ifdef HAVE_GETOPT_LONG
>> +static const struct option iz_long_opts[] = {
>> +{ "baudrate", optional_argument, NULL, 'b' },
>> +{ "help", no_argument, NULL, 'h' },
>> +{ NULL, 0, NULL, 0 },
>> +};
>> +#endif
>> +
>> +void serial_help(const char * pname) {
>> +printf("Usage: %s [options] SERIAL_DEV\n", pname);
>> +printf("Attach serial devices via UART to IEEE 802.15.4/ZigBee
>> stack\n\n");
>> +printf("Options:\n");
>> +printf(" -b, --baudrate[=115200]set the baudrate\n");
>> +printf(" -h, --help print help\n");
>> +printf(" SERIAL_DEV this specifies the
>> serial device to attach.\n");
>> +printf("Report bugs to " PACKAGE_BUGREPORT "\n\n");
>> +printf(PACKAGE_NAME " homepage <" PACKAGE_URL ">\n");
>> +}
>> +
>> +speed_t baudrate_to_speed(long baudrate) {
>> +switch(baudrate) {
>> +case 9600: return B9600;
>> +case 19200: return B19200;
>> +case 38400: return B38400;
>> +case 57600: return B57600;
>> +case 115200: return B115200;
>> +case 230400: return B230400;
>> +case 460800: return B460800;
>> +case 921600: return B921600;
>> +default:
>> +printf("Unrecognized baudrate %ld\n", baudrate);
>> +exit(EXIT_FAILURE);
>> +}
>> +}
>> +
>> int main(int argc, char **argv) {
>> -int fd, ret, s;
>> -
>> -if (argc == 1 || !strcmp(argv[1], "--version")) {
>> -printf( "izattach " VERSION "\n"
>> -"Copyright (C) 2008, 2009 by Siemens AG\n"
>> -"License GPLv2 GNU GPL version 2
>> <http://gnu.org/licenses/gpl.html>.\n"
>> -"This is free software: you are free to change and
>> redistribute
>> it.\n"
>> -"There is NO WARRANTY, to the extent permitted by
>> law.\n"
>> -"\n"
>> -"Written by Dmitry Eremin-Solenikov, Sergey Lapin and
>> Maxim
>> Osipov\n");
>> -return 0;
>> +int fd, ret, s, c;
>> +long baudrate;
>> +char * endptr;
>> +speed_t speed = B115200;
>> +
>> +/* Parse options */
>> +while (1) {
>> +#ifdef HAVE_GETOPT_LONG
>> +int opt_idx = -1;
>> +c = getopt_long(argc, argv, "b:h", iz_long_opts, &opt_idx);
>> +#else
>> +c = getopt(argc, argv, "b:h");
>> +#endif
>> +if (c == -1)
>> +break;
>> +
>> +switch(c) {
>> +case 'h':
>> +serial_help(argv[0]);
>> +return 0;
>> +case 'b':
>> +baudrate = strtol(optarg, &endptr, 10);
>> +if (* endptr == '\0')
>> +speed = baudrate_to_speed(baudrate);
>> +break;
>> +case 'v':
>> +printf( "izattach " VERSION "\n"
>> +"Copyright (C) 2008, 2009 by Siemens AG\
[Linux-zigbee-devel] [PATCH v2 1/2] izattach: remove extra whitespace
Signed-off-by: Tony Cheneau
---
src/serial.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/serial.c b/src/serial.c
index 252f3d9..ab76aea 100644
--- a/src/serial.c
+++ b/src/serial.c
@@ -76,8 +76,8 @@ int main(int argc, char **argv) {
tbuf.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
tbuf.c_iflag &= ~(INPCK | ISTRIP);
tbuf.c_oflag &= ~OPOST;
- tbuf.c_cc[VTIME] = 5;
-
+ tbuf.c_cc[VTIME] = 5;
+
/*
tbuf.c_cflag |= CLOCAL;
tbuf.c_lflag = 0;
--
1.8.1.5
--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 0/2] Enable izattach to change the baudrate
This is a small patch for the izattach (part of the linux-zigbee userspace tools). It enables the user to select the baudrate when communicating with their IEEE 802.15.4 serial device. This is the 2nd version of these patches. Here is the list of changes since the previous version: - split the initial patch in two, extra whitespace fix has now its separate patch - fix the issue where my text editor replaced the tab to 4 spaces Thanks Alan for your review. Regards, Tony Tony Cheneau (2): izattach: remove extra whitespace izattach: enable custom baudrate src/serial.c | 107 ++- 1 file changed, 84 insertions(+), 23 deletions(-) -- 1.8.1.5 -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v2 2/2] izattach: enable custom baudrate
Add a "baudrate" parameter on the CLI that enables the user to choose
from different baudrates. If no parameter is passed, the baudrate is set
to 115200 (retaining the previous behavior).
Signed-off-by: Tony Cheneau
---
src/serial.c | 103 +++
1 file changed, 82 insertions(+), 21 deletions(-)
diff --git a/src/serial.c b/src/serial.c
index ab76aea..d42ea5b 100644
--- a/src/serial.c
+++ b/src/serial.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
@@ -32,33 +33,93 @@
#include
#include
#include
+#include
#include "ieee802154.h"
+#ifdef HAVE_GETOPT_LONG
+static const struct option iz_long_opts[] = {
+ { "baudrate", optional_argument, NULL, 'b' },
+ { "help", no_argument, NULL, 'h' },
+ { NULL, 0, NULL, 0 },
+};
+#endif
+
+void serial_help(const char * pname) {
+ printf("Usage: %s [options] SERIAL_DEV\n", pname);
+ printf("Attach serial devices via UART to IEEE 802.15.4/ZigBee
stack\n\n");
+ printf("Options:\n");
+ printf(" -b, --baudrate[=115200]set the baudrate\n");
+ printf(" -h, --help print help\n");
+ printf(" SERIAL_DEV this specifies the serial
device to attach.\n");
+ printf("Report bugs to " PACKAGE_BUGREPORT "\n\n");
+ printf(PACKAGE_NAME " homepage <" PACKAGE_URL ">\n");
+}
+
+speed_t baudrate_to_speed(long baudrate) {
+ switch(baudrate) {
+ case 9600: return B9600;
+ case 19200: return B19200;
+ case 38400: return B38400;
+ case 57600: return B57600;
+ case 115200: return B115200;
+ case 230400: return B230400;
+ case 460800: return B460800;
+ case 921600: return B921600;
+ default:
+ printf("Unrecognized baudrate %ld\n", baudrate);
+ exit(EXIT_FAILURE);
+}
+}
+
int main(int argc, char **argv) {
- int fd, ret, s;
-
- if (argc == 1 || !strcmp(argv[1], "--version")) {
- printf( "izattach " VERSION "\n"
- "Copyright (C) 2008, 2009 by Siemens AG\n"
- "License GPLv2 GNU GPL version 2
<http://gnu.org/licenses/gpl.html>.\n"
- "This is free software: you are free to change and
redistribute it.\n"
- "There is NO WARRANTY, to the extent permitted by
law.\n"
- "\n"
- "Written by Dmitry Eremin-Solenikov, Sergey Lapin and
Maxim Osipov\n");
- return 0;
+ int fd, ret, s, c;
+ long baudrate;
+ char * endptr;
+ speed_t speed = B115200;
+
+ /* Parse options */
+ while (1) {
+#ifdef HAVE_GETOPT_LONG
+ int opt_idx = -1;
+ c = getopt_long(argc, argv, "b:h", iz_long_opts, &opt_idx);
+#else
+ c = getopt(argc, argv, "b:h");
+#endif
+ if (c == -1)
+ break;
+
+ switch(c) {
+ case 'h':
+ serial_help(argv[0]);
+ return 0;
+ case 'b':
+ baudrate = strtol(optarg, &endptr, 10);
+ if (* endptr == '\0')
+ speed = baudrate_to_speed(baudrate);
+ break;
+ case 'v':
+ printf( "izattach " VERSION "\n"
+ "Copyright (C) 2008, 2009 by Siemens AG\n"
+ "License GPLv2 GNU GPL version 2
<http://gnu.org/licenses/gpl.html>.\n"
+ "This is free software: you are free to change
and redistribute it.\n"
+ "There is NO WARRANTY, to the extent permitted
by law.\n"
+ "\n"
+ "Written by Dmitry Eremin-Solenikov, Sergey
Lapin and Maxim Osipov\n");
+ return 0;
+ default:
+ serial_help(argv[0]);
+ return 1;
+ }
}
- if (argc != 2 || (argc >= 1 && !strcmp(argv[1], "--help"))) {
- printf("Usage: %s SERIAL_DEV\n", argv[0]);
- printf("Attach serial devices via UART to IEEE 802.15.4/ZigBee
stack\n\n");
- printf(" SERIAL_DEV This specifies the serial d
Re: [Linux-zigbee-devel] [PATCH v2 2/2] izattach: enable custom baudrate
Hi Alex,
Thanks your for your comments. They make plenty of sense. I'll
update the patches accordingly. However, I won't change the return
values: there might be some scripts that depends on these return values
(or it could be that using various return values here makes debugging
easier).
Regards,
Tony
Le Thu, 25 Apr 2013 07:01:03 +0200,
Alexander Aring a écrit :
> Dear Tony,
>
> On Wed, Apr 24, 2013 at 10:49:16AM -0400, Tony Cheneau wrote:
> > Add a "baudrate" parameter on the CLI that enables the user to
> > choose from different baudrates. If no parameter is passed, the
> > baudrate is set to 115200 (retaining the previous behavior).
> >
> > Signed-off-by: Tony Cheneau
> > ---
> > src/serial.c | 103
> > +++ 1 file
> > changed, 82 insertions(+), 21 deletions(-)
> >
> > diff --git a/src/serial.c b/src/serial.c
> > index ab76aea..d42ea5b 100644
> > --- a/src/serial.c
> > +++ b/src/serial.c
> > @@ -25,6 +25,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -32,33 +33,93 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "ieee802154.h"
> >
> > +#ifdef HAVE_GETOPT_LONG
> > +static const struct option iz_long_opts[] = {
> > + { "baudrate", optional_argument, NULL, 'b' },
> > + { "help", no_argument, NULL, 'h' },
> Maybe we should add "version" and 'v' here.
> > + { NULL, 0, NULL, 0 },
> > +};
> > +#endif
> > +
> > +void serial_help(const char * pname) {
> > + printf("Usage: %s [options] SERIAL_DEV\n", pname);
> > + printf("Attach serial devices via UART to IEEE
> > 802.15.4/ZigBee stack\n\n");
> > + printf("Options:\n");
> > + printf(" -b, --baudrate[=115200]set the
> > baudrate\n");
> > + printf(" -h, --help print help\n");
> Same here.
> > + printf(" SERIAL_DEV this specifies
> > the serial device to attach.\n");
> > + printf("Report bugs to " PACKAGE_BUGREPORT "\n\n");
> > + printf(PACKAGE_NAME " homepage <" PACKAGE_URL ">\n");
> > +}
> > +
> > +speed_t baudrate_to_speed(long baudrate) {
> > + switch(baudrate) {
> > + case 9600: return B9600;
> > + case 19200: return B19200;
> > + case 38400: return B38400;
> > + case 57600: return B57600;
> > + case 115200: return B115200;
> > + case 230400: return B230400;
> > + case 460800: return B460800;
> > + case 921600: return B921600;
> Intend here like linux kernel?
> it's
>
> switch(foo) {
> case bar:
> ...
> }
> > + default:
> > + printf("Unrecognized baudrate %ld\n",
> > baudrate);
> > + exit(EXIT_FAILURE);
> > +}
> > +}
> > +
> > int main(int argc, char **argv) {
> > - int fd, ret, s;
> > -
> > - if (argc == 1 || !strcmp(argv[1], "--version")) {
> > - printf( "izattach " VERSION "\n"
> > - "Copyright (C) 2008, 2009 by Siemens AG\n"
> > - "License GPLv2 GNU GPL version 2
> > <http://gnu.org/licenses/gpl.html>.\n"
> > - "This is free software: you are free to
> > change and redistribute it.\n"
> > - "There is NO WARRANTY, to the extent
> > permitted by law.\n"
> > - "\n"
> > - "Written by Dmitry Eremin-Solenikov,
> > Sergey Lapin and Maxim Osipov\n");
> > - return 0;
> > + int fd, ret, s, c;
> > + long baudrate;
> > + char * endptr;
> > + speed_t speed = B115200;
> > +
> > + /* Parse options */
> > + while (1) {
> > +#ifdef HAVE_GETOPT_LONG
> > + int opt_idx = -1;
> > + c = getopt_long(argc, argv, "b:h", iz_long_opts,
> > &opt_idx); +#else
> > + c = getopt(argc, argv, "b:h");
> > +#endif
> > + if (c == -1)
> > + break;
> > +
> > + switch(c) {
> > + case 'h':
> > + serial_help(argv
[Linux-zigbee-devel] [PATCH v3 0/2] Enable izattach to change the baudrate
This is a small patch for the izattach (part of the linux-zigbee userspace tools). It enables the user to select the baudrate when communicating with their IEEE 802.15.4 serial device. This is the 3rd version of these patches. Here is the list of changes since the previous version: - add "usage" text for the "-v" argument as well as the long argument "--version" - fix indenting in a switch/case - fix an issue where the "-v" argument would not be parsed properly Thanks Alex for your review. Regards, Tony Tony Cheneau (2): izattach: remove extra whitespace izattach: enable custom baudrate src/serial.c | 109 ++- 1 file changed, 86 insertions(+), 23 deletions(-) -- 1.8.1.5 -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v3 1/2] izattach: remove extra whitespace
Signed-off-by: Tony Cheneau
---
src/serial.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/serial.c b/src/serial.c
index 252f3d9..ab76aea 100644
--- a/src/serial.c
+++ b/src/serial.c
@@ -76,8 +76,8 @@ int main(int argc, char **argv) {
tbuf.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
tbuf.c_iflag &= ~(INPCK | ISTRIP);
tbuf.c_oflag &= ~OPOST;
- tbuf.c_cc[VTIME] = 5;
-
+ tbuf.c_cc[VTIME] = 5;
+
/*
tbuf.c_cflag |= CLOCAL;
tbuf.c_lflag = 0;
--
1.8.1.5
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH v3 2/2] izattach: enable custom baudrate
Add a "baudrate" parameter on the CLI that enables the user to choose
from different baudrates. If no parameter is passed, the baudrate is set
to 115200 (retaining the previous behavior).
Signed-off-by: Tony Cheneau
---
src/serial.c | 105 +++
1 file changed, 84 insertions(+), 21 deletions(-)
diff --git a/src/serial.c b/src/serial.c
index ab76aea..d7cc6c1 100644
--- a/src/serial.c
+++ b/src/serial.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
@@ -32,33 +33,95 @@
#include
#include
#include
+#include
#include "ieee802154.h"
+#ifdef HAVE_GETOPT_LONG
+static const struct option iz_long_opts[] = {
+ { "baudrate", required_argument, NULL, 'b' },
+ { "help", no_argument, NULL, 'h' },
+ { "version", no_argument, NULL, 'v' },
+ { NULL, 0, NULL, 0 },
+};
+#endif
+
+void serial_help(const char * pname) {
+ printf("Usage: %s [options] SERIAL_DEV\n", pname);
+ printf("Attach serial devices via UART to IEEE 802.15.4/ZigBee
stack\n\n");
+ printf("Options:\n");
+ printf(" -b, --baudrate[=115200]set the baudrate\n");
+ printf(" -h, --help print help\n");
+ printf(" -v, --version print program version\n");
+ printf(" SERIAL_DEV this specifies the serial
device to attach.\n");
+ printf("Report bugs to " PACKAGE_BUGREPORT "\n\n");
+ printf(PACKAGE_NAME " homepage <" PACKAGE_URL ">\n");
+}
+
+speed_t baudrate_to_speed(long baudrate) {
+ switch(baudrate) {
+ case 9600: return B9600;
+ case 19200: return B19200;
+ case 38400: return B38400;
+ case 57600: return B57600;
+ case 115200: return B115200;
+ case 230400: return B230400;
+ case 460800: return B460800;
+ case 921600: return B921600;
+ default:
+ printf("Unrecognized baudrate %ld\n", baudrate);
+ exit(EXIT_FAILURE);
+}
+}
+
int main(int argc, char **argv) {
- int fd, ret, s;
-
- if (argc == 1 || !strcmp(argv[1], "--version")) {
- printf( "izattach " VERSION "\n"
- "Copyright (C) 2008, 2009 by Siemens AG\n"
- "License GPLv2 GNU GPL version 2
<http://gnu.org/licenses/gpl.html>.\n"
- "This is free software: you are free to change and
redistribute it.\n"
- "There is NO WARRANTY, to the extent permitted by
law.\n"
- "\n"
- "Written by Dmitry Eremin-Solenikov, Sergey Lapin and
Maxim Osipov\n");
- return 0;
+ int fd, ret, s, c;
+ long baudrate;
+ char * endptr;
+ speed_t speed = B115200;
+
+ /* Parse options */
+ while (1) {
+#ifdef HAVE_GETOPT_LONG
+ int opt_idx = -1;
+ c = getopt_long(argc, argv, "b:hv", iz_long_opts, &opt_idx);
+#else
+ c = getopt(argc, argv, "b:hv");
+#endif
+ if (c == -1)
+ break;
+
+ switch(c) {
+ case 'h':
+ serial_help(argv[0]);
+ return 0;
+ case 'b':
+ baudrate = strtol(optarg, &endptr, 10);
+ if (* endptr == '\0')
+ speed = baudrate_to_speed(baudrate);
+ break;
+ case 'v':
+ printf( "izattach " VERSION "\n"
+ "Copyright (C) 2008, 2009 by Siemens AG\n"
+ "License GPLv2 GNU GPL version 2
<http://gnu.org/licenses/gpl.html>.\n"
+ "This is free software: you are free to change
and redistribute it.\n"
+ "There is NO WARRANTY, to the extent permitted
by law.\n"
+ "\n"
+ "Written by Dmitry Eremin-Solenikov, Sergey
Lapin and Maxim Osipov\n");
+ return 0;
+ default:
+ serial_help(argv[0]);
+ return 1;
+ }
}
- if (argc != 2 || (argc >= 1 && !strcmp(argv[1], "--help"))) {
- printf("Usage: %s SERIAL_DEV\n", argv[0]);
- printf("Attach serial devices via UART to IEEE 802.15.4/ZigBee
stack\n\n");
- pri
[Linux-zigbee-devel] [RFC] IEEE 802.15.4 serial protocol version 2 (for Econotags and others).
Hello everyone, I just uploaded a draft version of a version 2 of the serial protocol that is used to command the Redbee Econotags with the "serial" driver on Linux. You can find the text here [1]. The specification for the version 1 can be found here [2] for a comparison (although I discussed the changes in the draft). I think an update of the serial protocol is needed for the following reasons: - Econotag's capabilities have evolved since the serial protocol version 1 has been written (hardware auto-ACK comes to mind). - it's important to clean the protocol up a little, before trying to send the serial driver upstream (removing the "zb" -> zigbee reference for example). - more devices and/or OS could make use of the protocol in the future, a more formal specification and some more flexibility could be a good thing. - some current text description in the version 1 [2] is ambiguous/under-specified; for example the "Get 64-bit address" returns an 8-byte address, but the byte ordering is not clear. - the current serial driver protocol is named "Serial protocol version 1". Obviously, it only makes sense if there is a version 2. I have not yet updated the code that currently makes use of the serial protocol (Econotag's firmware, serial driver, the virtual serial device [3] (currently experimental)), because I intend to do so when this draft document becomes more stable. Please don't hesitate to provide some feedback (preferably on the linux-zigbee mailing list). Regards, Tony P.-S.: I cc'ed the mc1322x mailing list, because I believe Econotag's user might be interested as well. [1]: https://github.com/linux-wpan/ieee802154-serial-protocol-version2/blob/master/ieee802154-serial-protocol-2.md [3]: https://github.com/tcheneau/virtual-ieee802154-serial [2]: http://sourceforge.net/apps/trac/linux-zigbee/wiki/SerialV1 -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [mc1322x] [RFC] IEEE 802.15.4 serial protocol version 2 (for Econotags and others).
Hello Jim, Thanks for your comments. Please see my response inline. [...] > A few comments: > > - It could use some more clarification for whether transmission is > blocking or nonblocking, i.e. whether the dongle should wait for > transmission to complete before returning a response. Yes. I guess it could use some clarification. I would tend to favor blocking TX, so that the device can return the status of the TX. This is especially true when use auto-acknowledgments: the sender can know if the receiver actually received the packet or if the transmission failed. Also, without any flow control logic, I believe the network stack would flood the device at a speed that is higher than TX speed (thus leading to very high packet loss). Unless the device warns the host when it's internal buffer is full. > - What happens if there's no response? For example, if the dongle > sends "receive block" but never gets a response from the host, > should it keep sending them anyway? How long should it wait before > deciding no response is coming back? Similarly, what should each > side do if a bad response comes back in either direction? Currently, there is some timeout mechanisms (on both the driver and the device), so as to recover from this situation. I should probably add some default timeout values in the text, either based on the current ones or by computing maybe more "optimal" values depending on the communication speed with the device. I'm not sure what you qualify as a "bad response": - if it's an status indicating "FAILURE", the error_code provides information on the reason of the failure (when possible). This can be reported by the driver to the system. - when the host or the dongle response does not match the request, the requester should detect the mismatch. If the "bad response" occurs after the cmdId, I guess there is two possibilities: the response is shorter than the expected response, a timeout will kick in, and the request will fail. If the response is of equal or longer size than the expected response, I guess it gets misinterpreted by the receiving end. So far, I haven't seen any of these two failure scenarios. > - This protocol seems terrible for throughput due to turnaround > latency. USB, for example, will necessarily introduce a one frame > (1ms) or one microframe (125μs) latency every time you're waiting > on > a direction change. The FT2232 (used in the Econotag) will also > add > a 16ms latency before flushing short transfers to the host, by > default. So any time you transmit a packet, you could end up > waiting an extra 16ms for the response. Instead of trying to tweak > those types of details on a per-device basis, it would be better to > not require a per-packet direction change in the protocol. You > could add fancy pipelining that allows multilpe outstanding > unacknowledged requests, or maybe just add some "transmit > unacknowledged" and "receive unacknowledged" style commands > that don't require waiting on a response. I don't know much about the USB protocol, so I take your word for it. I don't think the "fancy pipelining" is easily possible, and I'm not sure if it would be desirable. Currently, the kernel process only one packet at a time. It would require some internal queuing mechanism within the device. The unacknowledged requests, for both "transmit block" and "receive block" commands seems like a very good idea. Actually, I can't seem to find a scenario where the device would required a "receive block" command to be acknowledged. I'll try to implement it soon in order to check how it behaves, and I'll post the results here. Again, thank you for all your valuable comments. Regards, Tony -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [RFC] IEEE 802.15.4 serial protocol version 2 (for Econotags and others).
Hello Dmitry,
Thanks for your comments. They are especially appreciated since you
designed the version 1 of the protocol. Please see my comments inline.
[...]
> Sometimes we had problems with synchronisation/recovery/etc. If a
> character is lost,
> it takes some (1-2) packets to resync kernel and a device.
I don't doubt your word, but I don't think I have witnessed such
issues. It could be because the Econotag's UART code has been improved
lately. Regardless, it's good to design robust protocol and we can't
account for upcoming devices, so your point makes sense.
> Second topic is protocol upgrades/compatibility. Having no clear
> field
> for packet length/
> fast resync makes impossible for the device/host to quickly drop
> unsupported packets
> (and report them back to the other partner).
Yes, that's right. I have never gave to much thoughts on the
unsupported commands. I'll add a length field on the next revision (or
move it at the beginning of the command in the commands where it's
already present).
> I have two suggestions (we can agree on either of them or on both).
>
> 1) I suggest for 's' to be used only as a packet start character.
> Let's pick up something like
> SLIP/PPP have:
>
> For transmitter:
> 's' = start of the packet. If it happens in the packet, transmitter
> should replace it. 's' => 'ec'
> 'e' = escape char. If it happens in the packet, replace it with 'e'
> => 'ee'
>
> For the receiver:
> 's' => start of the packet. If it is found, finish the current packet
> (possibly truncated/damaged)
> and start parsing new packet
> 'e' => escape char. Replace:
> 'ee' => 'e'
> 'ec' => 's'
>
> After 's' comes protocol version ('s' '2').
Byte stuffing makes perfect sense here. I would tend to favor Mariano's
suggestion and use Consistent Overhead Byte Stuffing (COBS). I haven't
read the paper in details yet, but the implementation seems lightweight
and it does not add much overhead.
>
> 2) Packet length. I would suggest to change the protocol a bit:
> After command id comes packet length (after unescaping all characters
> if we agree to escape them).
> Thus it will be possible to skip 'till the next packet'.
>
> Examples:
> Command: 0x00[=NOOP] 0x00[=no args]
> Response: 0x80[=rNOOP] 0x01[=1 byte] 0x80[=SUCCESS]
>
> Command: 0x04[=XMIT] 0x33[=len] .[=0x33 bytes]
> Response: 0x84[=rXMIT] 0x02[=2 bytes] 0x80[=status] 0xed[=level]
Agreed. I'll add this one in the next version of the text.
> Also what is the point of reversing the high bit in the 'received
> block' event/response?
It makes it extra easy to match a request to its response and to
compute the response message in the case you don't even support the
command (provided that all your command have the same "header", such as
"s2" and , you can indicate a failure). Perhaps that not needed
if you report errors in a different manner.
Regards,
Tony
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [RFC] IEEE 802.15.4 serial protocol version 2 (for Econotags and others).
Hi, Yes, the page is already part of the parameters of the "set channel" command on the draft. I haven't looked at the latest PHYs available, so it could be that devices that use a channel page != 0 already exist. Regards, Tony Le 2013-06-06 10:13, Dmitry Eremin-Solenikov a écrit : > Hello, > > On Thu, Jun 6, 2013 at 2:02 AM, Tony Cheneau > wrote: >> Please don't hesitate to provide some feedback (preferably on the >> linux-zigbee mailing list). > > Also I would suggest to include channel page in the set channel > command. For most of the > devices it should be 0 (so maybe we can have that as a default), but > I'm sure that sooner > or later we will be create devices which use other channel pages, > won't we? -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [RFC] IEEE 802.15.4 serial protocol version 2 (for Econotags and others).
Hello Dmitry, Just answering that last one (I took note of the other ones). [...] >> It makes it extra easy to match a request to its response and to >> compute the >> response message in the case you don't even support the command >> (provided >> that all your command have the same "header", such as "s2" and >> , you >> can indicate a failure). Perhaps that not needed if you report >> errors in a >> different manner. > > I know why both V1 and V2 have that | 0x80 ;) > > I was asking especially about received-block event. V2 has that 0x80 > inverted > in received-block (if compared to V1). OK, I get it now. I swapped the logic a little here unintentionally when I was renumbering the various commands. However, on a second though I think the inversion is preferable here because it respects the property that the response cmdId is the "|0x80"'ed of the request cmdID. Given that the version 2 does not intend to be backward compatible, that does not seem to raise any issues. Does that seems fair to you? Do you see any problem with this approach? I always though the serial protocol V1 was designed for the Econotag in mind, thanks for showing me wrong. :) Regards, Tony -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
Hi Werner, Thanks a lot for your email and your patches. I'm sorry it took me so long to reply. > Good news: I got it to talk to Contiki. While I'm not sure it's > working perfectly, a lot of things look right and pings between > the two systems pass nicely. This is a excellent news indeed! > I tried a two-node setup with a Contiki leaf and a Linux root, > and didn't experiment with any more complex topology. This is a very encouraging start. I'm working on a IEEE 802.15.4 PHY emulator. Once this is done, I should be able to build some complex topologies, mixing Contiki and Linux nodes. Also, are you sure that you meant to say "leaf" here? A leaf node in RPL is a node that implements a pretty limited subset of RPL. See Section 8.5 of RFC 6550 [1]. > There are two bugs left that complicate things. First, I had to > change the order of linker arguments to get RplIcmp to load > properly: > > > https://github.com/frtos-wpan/frtos-wpan/blob/master/patches/rplicmp-fix-shlib-dep.patch Applied. Thanks! Let me know if the commit message is OK with you [2]. If you find it easier/faster, please don't hesitate to send my a pull request next time. > The other bug seems to be in the Linux kernel: it assumes that an > ICMPv6 message is at least 8 bytes. The DODAG Information > Solicitation (DIS) Contiki sends is only 6 bytes, and I haven't > found anything in RFC 4443 and RFC 6550 that would disallow having > such a short ICMPv6 message. I agree with your interpretation of the RFC. It's a good catch. > The short RPL DIS is rejected by the kernel and thus never reaches > simpleRPL. simpleRPL eventually reveals its presence and the two > then start talking, but losing the DIS can delay node bringup > considerably (minutes if not hours instead of seconds). In my test environment setup, using KVM, the DIS seemed to work correctly. I'll have to investigate a bit more, after a few quick checks, it appears that a similar size limitation exists when sending ICMP packets (i.e. kernel would increase the size of DIS message before sending). > A tentative fix is here: > > https://github.com/wpwrak/ben-wpan-linux/commit/2532be747cc973b1a36f80bc773c6784ae9b0ffe This patch will cause some side effects. It seems that some other code relies on the union in the "struct icmp6hdr" (defined in uapi/linux/icmpv6.h) being filled correctly. I would need a refresher on the skb structure before I could improve your patch. > Thanks a lot for simpleRPL ! Thank you! Regards, Tony [1]: https://tools.ietf.org/html/rfc6550#section-8.5 [2]: https://github.com/tcheneau/RplIcmp/commit/8fd6125d82e30b4b5d92d0acaa2e2ff469e4cde4 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
