ll-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 versio
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
>
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 su
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 R
lease 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 currentl
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 t
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
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):
>
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 a
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 fo
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
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
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, an
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 ma
44cbd 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
tch 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 chang
orry 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
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
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 in
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.
Firs
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 ass
nt: 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 li
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 baud
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 ot
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
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. Beca
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
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 change
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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 current
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
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).
O
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 thi
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 c
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 ha
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
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/li
> 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 whic
ologies, 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 h
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
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
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
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
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
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
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
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
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
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
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
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
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
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://ma
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
or 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 deleti
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
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 a
L). 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 20
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,
> whi
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
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 unfortunat
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
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 implem
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 pa
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
ncountered?
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 e
nd 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 20
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
,
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
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
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/seri
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
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
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
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/seri
ing
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
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 ex
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
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/seri
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
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
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
é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
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", s
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
1 - 100 of 110 matches
Mail list logo
