owfs - bug in ow_w1_send.c

classic Classic list List threaded Threaded
14 messages Options
eni
Reply | Threaded
Open this post in threaded view
|

owfs - bug in ow_w1_send.c

eni
in my opinion there is a bug in ow_w1_send.c - that sequence number for
netlink can run over 0xFFFF.
this makes the problem that the message which is send (65536 & 0xFFFF),
has a different sequence number as the Response is watinting for (65536).

I've try the following patch to reset sequence number, when the number
is going greater then 0xFFFF - and it is working stable same days (20
times sequence number is running over 0xFFFF in this time).


test@linux-lbd2:~/owfs/owfs-3.1p4> diff
./module/owlib/src/c/ow_w1_send.c ./module/owlib/src/c/ow_w1_send.c.orig
71,77c71
<               // seq = ++in->master.w1.seq ;
<               // seq should not be zero or > 0xFFFF
<               seq = NL_SEQ(++in->master.w1.seq);
<               if(seq == 0) {
<                 seq = NL_SEQ(++in->master.w1.seq);
<                 LEVEL_DEBUG("NETLINK sequence number overrun");
<               }
---
 >               seq = ++in->master.w1.seq ;
test@linux-lbd2:~/owfs/owfs-3.1p4>

best regards
  eni

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

Jan Kandziora
Am 12.11.2016 um 19:31 schrieb Enrico Hoepfner:

> in my opinion there is a bug in ow_w1_send.c - that sequence number for
> netlink can run over 0xFFFF.
> this makes the problem that the message which is send (65536 & 0xFFFF),
> has a different sequence number as the Response is watinting for (65536).
>
> I've try the following patch to reset sequence number, when the number
> is going greater then 0xFFFF - and it is working stable same days (20
> times sequence number is running over 0xFFFF in this time).
>
>
> test@linux-lbd2:~/owfs/owfs-3.1p4> diff
> ./module/owlib/src/c/ow_w1_send.c ./module/owlib/src/c/ow_w1_send.c.orig
> 71,77c71
> <               // seq = ++in->master.w1.seq ;
> <               // seq should not be zero or > 0xFFFF
> <               seq = NL_SEQ(++in->master.w1.seq);
> <               if(seq == 0) {
> <                 seq = NL_SEQ(++in->master.w1.seq);
> <                 LEVEL_DEBUG("NETLINK sequence number overrun");
> <               }
> ---
>  >               seq = ++in->master.w1.seq ;
> test@linux-lbd2:~/owfs/owfs-3.1p4>
>
Thanks for playing with this.

You are rolling back a previous patch with your patch. There sure had
been a reason why Paul had inserted that test. We have to find out why.


BTW: diff -u is the preferred diff format - everywhere.

Kind regards

        Jan


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

eni
Hi Jan,

Thank you for the fast answer!
I dont understand exacly , which patch and test from Paul you mean.
Maybe I have take the diff in the wrong direction???? sorry for that!

this are the new lines

<               // seq = ++in->master.w1.seq ;
<               // seq should not be zero or > 0xFFFF
<               seq = NL_SEQ(++in->master.w1.seq);
<               if(seq == 0) {
<                 seq = NL_SEQ(++in->master.w1.seq);
<                 LEVEL_DEBUG("NETLINK sequence number overrun");
<               }


this is what should be replaced

  >               seq = ++in->master.w1.seq ;



diff -u ow_w1_send.c.orig ow_w1_send.c
--- ow_w1_send.c.orig    2016-02-04 21:09:53.000000000 +0100
+++ ow_w1_send.c        2016-11-08 20:55:51.351153464 +0100
@@ -68,7 +68,13 @@
         } else {
                 // w1 subsidiary bus
                 // this bus is locked
-               seq = ++in->master.w1.seq ;
+               // seq = ++in->master.w1.seq ;
+               // seq should not be zero or > 0xFFFF
+               seq = NL_SEQ(++in->master.w1.seq);
+               if(seq == 0) {
+                 seq = NL_SEQ(++in->master.w1.seq);
+                 LEVEL_DEBUG("NETLINK sequence number overrun");
+               }
                 bus = in->master.w1.id;
         }
 


Best regards
  eni

On 12.11.2016 22:34, Jan Kandziora wrote:

> Am 12.11.2016 um 19:31 schrieb Enrico Hoepfner:
>> in my opinion there is a bug in ow_w1_send.c - that sequence number for
>> netlink can run over 0xFFFF.
>> this makes the problem that the message which is send (65536 & 0xFFFF),
>> has a different sequence number as the Response is watinting for (65536).
>>
>> I've try the following patch to reset sequence number, when the number
>> is going greater then 0xFFFF - and it is working stable same days (20
>> times sequence number is running over 0xFFFF in this time).
>>
>>
>> test@linux-lbd2:~/owfs/owfs-3.1p4> diff
>> ./module/owlib/src/c/ow_w1_send.c ./module/owlib/src/c/ow_w1_send.c.orig
>> 71,77c71
>> <               // seq = ++in->master.w1.seq ;
>> <               // seq should not be zero or > 0xFFFF
>> <               seq = NL_SEQ(++in->master.w1.seq);
>> <               if(seq == 0) {
>> <                 seq = NL_SEQ(++in->master.w1.seq);
>> <                 LEVEL_DEBUG("NETLINK sequence number overrun");
>> <               }
>> ---
>>   >               seq = ++in->master.w1.seq ;
>> test@linux-lbd2:~/owfs/owfs-3.1p4>
>>
> Thanks for playing with this.
>
> You are rolling back a previous patch with your patch. There sure had
> been a reason why Paul had inserted that test. We have to find out why.
>
>
> BTW: diff -u is the preferred diff format - everywhere.
>
> Kind regards
>
> Jan
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

Jan Kandziora
Am 13.11.2016 um 00:53 schrieb Enrico Hoepfner:

> Hi Jan,
>
> Thank you for the fast answer!
> I dont understand exacly , which patch and test from Paul you mean.
> Maybe I have take the diff in the wrong direction???? sorry for that!
>
> this are the new lines
>
> <               // seq = ++in->master.w1.seq ;
> <               // seq should not be zero or > 0xFFFF
> <               seq = NL_SEQ(++in->master.w1.seq);
> <               if(seq == 0) {
> <                 seq = NL_SEQ(++in->master.w1.seq);
> <                 LEVEL_DEBUG("NETLINK sequence number overrun");
> <               }
>
>
> this is what should be replaced
>
>   >               seq = ++in->master.w1.seq ;
>
Aaaahhhh, that's why diff -u is preferred.


>
>
> diff -u ow_w1_send.c.orig ow_w1_send.c
> --- ow_w1_send.c.orig    2016-02-04 21:09:53.000000000 +0100
> +++ ow_w1_send.c        2016-11-08 20:55:51.351153464 +0100
> @@ -68,7 +68,13 @@
>          } else {
>                  // w1 subsidiary bus
>                  // this bus is locked
> -               seq = ++in->master.w1.seq ;
> +               // seq = ++in->master.w1.seq ;
> +               // seq should not be zero or > 0xFFFF
> +               seq = NL_SEQ(++in->master.w1.seq);
> +               if(seq == 0) {
> +                 seq = NL_SEQ(++in->master.w1.seq);
> +                 LEVEL_DEBUG("NETLINK sequence number overrun");
> +               }
>                  bus = in->master.w1.id;
>          }
>  
>
Could you explain what the patch does? Two sentences?

Do you think the DEBUG message is necessary? If it's a normal condition
which can happen anytime, it's likely nothing to be debugged.

Kind regards

        Jan

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

eni
Hello Jan,

  Sorry for the confusion.

What does the patch do:
Problem:
In case of overrun of seq over 0xFFFF, the owserver try 4 minutes to get
an answer from 1w-bus, but without success, because the expected
sequence number is not mach with the seqence-number he hve send and get
back. After this time the owserver reconnect the 1w-bus an set
sequence-number back to 0. In this 4 minutes the server is not accessible.


The sequence-number consists of two parts (bus and seq)

ow_w1.h:53:#define MAKE_NL_SEQ( bus, seq )  ((uint32_t)(( ((bus) &
0xFFFF) << 16 ) | ((seq) & 0xFFFF)))


The Patch protect seq to run over 0xFFFF, overrun would make a broken
seqence-number which dont match expected seq in

W1_Process_Response( touch, w1_send_touch(data,size,pn), &ts, pn)

In my Opinion the Debugmessage is not necessary, I've used this to check
that the patch is working.

Best regards
  eni

On 13.11.2016 11:10, Jan Kandziora wrote:

> Am 13.11.2016 um 00:53 schrieb Enrico Hoepfner:
>> Hi Jan,
>>
>> Thank you for the fast answer!
>> I dont understand exacly , which patch and test from Paul you mean.
>> Maybe I have take the diff in the wrong direction???? sorry for that!
>>
>> this are the new lines
>>
>> <               // seq = ++in->master.w1.seq ;
>> <               // seq should not be zero or > 0xFFFF
>> <               seq = NL_SEQ(++in->master.w1.seq);
>> <               if(seq == 0) {
>> <                 seq = NL_SEQ(++in->master.w1.seq);
>> <                 LEVEL_DEBUG("NETLINK sequence number overrun");
>> <               }
>>
>>
>> this is what should be replaced
>>
>>    >               seq = ++in->master.w1.seq ;
>>
> Aaaahhhh, that's why diff -u is preferred.
>
>
>>
>> diff -u ow_w1_send.c.orig ow_w1_send.c
>> --- ow_w1_send.c.orig    2016-02-04 21:09:53.000000000 +0100
>> +++ ow_w1_send.c        2016-11-08 20:55:51.351153464 +0100
>> @@ -68,7 +68,13 @@
>>           } else {
>>                   // w1 subsidiary bus
>>                   // this bus is locked
>> -               seq = ++in->master.w1.seq ;
>> +               // seq = ++in->master.w1.seq ;
>> +               // seq should not be zero or > 0xFFFF
>> +               seq = NL_SEQ(++in->master.w1.seq);
>> +               if(seq == 0) {
>> +                 seq = NL_SEQ(++in->master.w1.seq);
>> +                 LEVEL_DEBUG("NETLINK sequence number overrun");
>> +               }
>>                   bus = in->master.w1.id;
>>           }
>>    
>>
> Could you explain what the patch does? Two sentences?
>
> Do you think the DEBUG message is necessary? If it's a normal condition
> which can happen anytime, it's likely nothing to be debugged.
>
> Kind regards
>
> Jan
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

Stefano Miccoli
In reply to this post by Jan Kandziora
I don’t get the point.

Netlink sequence numbers are opaque and are needed only to correlate request/response. Netlink sequence numbers are build by this macro (module/owlib/src/include/ow_w1.h):

#define MAKE_NL_SEQ( bus, seq )  ((uint32_t)(( ((bus) & 0xFFFF) << 16 ) | ((seq) & 0xFFFF)))

This does not mean that one should have 0 < seq <= 0xFFFF, provided that when you parse the response you properly mask both the response netlink sequence number and the owlib seq (which originated the request) to check only the low 4 bytes, i.e.

NL_SEQ(netlink response sequence number) == NL_SEQ(owlib internal sequence number seq)

IMHO concrete evidence should be provided that there is a point in the source where this masking is not done properly, and that is the bug to be corrected. Fudging the sequence number in order to avoid a bug  surfacing in another point of the code is nooot good.

S.

On 13 Nov 2016, at 11:10, Jan Kandziora <[hidden email]> wrote:

Am 13.11.2016 um 00:53 schrieb Enrico Hoepfner:
Hi Jan,

Thank you for the fast answer!
I dont understand exacly , which patch and test from Paul you mean.
Maybe I have take the diff in the wrong direction???? sorry for that!

this are the new lines

<               // seq = ++in->master.w1.seq ;
<               // seq should not be zero or > 0xFFFF
<               seq = NL_SEQ(++in->master.w1.seq);
<               if(seq == 0) {
<                 seq = NL_SEQ(++in->master.w1.seq);
<                 LEVEL_DEBUG("NETLINK sequence number overrun");
<               }


this is what should be replaced

             seq = ++in->master.w1.seq ;

Aaaahhhh, that's why diff -u is preferred.




diff -u ow_w1_send.c.orig ow_w1_send.c
--- ow_w1_send.c.orig    2016-02-04 21:09:53.000000000 +0100
+++ ow_w1_send.c        2016-11-08 20:55:51.351153464 +0100
@@ -68,7 +68,13 @@
        } else {
                // w1 subsidiary bus
                // this bus is locked
-               seq = ++in->master.w1.seq ;
+               // seq = ++in->master.w1.seq ;
+               // seq should not be zero or > 0xFFFF
+               seq = NL_SEQ(++in->master.w1.seq);
+               if(seq == 0) {
+                 seq = NL_SEQ(++in->master.w1.seq);
+                 LEVEL_DEBUG("NETLINK sequence number overrun");
+               }
                bus = in->master.w1.id;
        }


Could you explain what the patch does? Two sentences?

Do you think the DEBUG message is necessary? If it's a normal condition
which can happen anytime, it's likely nothing to be debugged.

Kind regards

Jan

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

Stefano Miccoli
This line looks suspicious:

module/owlib/src/c/ow_w1_parse.c:235:           if ( NL_SEQ(nlp.nlm->nlmsg_seq) != (unsigned int) seq ) {

Hope this helps.

S.


On 13 Nov 2016, at 12:28, Stefano Miccoli <[hidden email]> wrote:

I don’t get the point.

Netlink sequence numbers are opaque and are needed only to correlate request/response. Netlink sequence numbers are build by this macro (module/owlib/src/include/ow_w1.h):

#define MAKE_NL_SEQ( bus, seq )  ((uint32_t)(( ((bus) & 0xFFFF) << 16 ) | ((seq) & 0xFFFF)))

This does not mean that one should have 0 < seq <= 0xFFFF, provided that when you parse the response you properly mask both the response netlink sequence number and the owlib seq (which originated the request) to check only the low 4 bytes, i.e.

NL_SEQ(netlink response sequence number) == NL_SEQ(owlib internal sequence number seq)

IMHO concrete evidence should be provided that there is a point in the source where this masking is not done properly, and that is the bug to be corrected. Fudging the sequence number in order to avoid a bug  surfacing in another point of the code is nooot good.

S.

On 13 Nov 2016, at 11:10, Jan Kandziora <[hidden email]> wrote:

Am 13.11.2016 um 00:53 schrieb Enrico Hoepfner:
Hi Jan,

Thank you for the fast answer!
I dont understand exacly , which patch and test from Paul you mean.
Maybe I have take the diff in the wrong direction???? sorry for that!

this are the new lines

<               // seq = ++in->master.w1.seq ;
<               // seq should not be zero or > 0xFFFF
<               seq = NL_SEQ(++in->master.w1.seq);
<               if(seq == 0) {
<                 seq = NL_SEQ(++in->master.w1.seq);
<                 LEVEL_DEBUG("NETLINK sequence number overrun");
<               }


this is what should be replaced

             seq = ++in->master.w1.seq ;

Aaaahhhh, that's why diff -u is preferred.




diff -u ow_w1_send.c.orig ow_w1_send.c
--- ow_w1_send.c.orig    2016-02-04 21:09:53.000000000 +0100
+++ ow_w1_send.c        2016-11-08 20:55:51.351153464 +0100
@@ -68,7 +68,13 @@
        } else {
                // w1 subsidiary bus
                // this bus is locked
-               seq = ++in->master.w1.seq ;
+               // seq = ++in->master.w1.seq ;
+               // seq should not be zero or > 0xFFFF
+               seq = NL_SEQ(++in->master.w1.seq);
+               if(seq == 0) {
+                 seq = NL_SEQ(++in->master.w1.seq);
+                 LEVEL_DEBUG("NETLINK sequence number overrun");
+               }
                bus = in->master.w1.id;
        }


Could you explain what the patch does? Two sentences?

Do you think the DEBUG message is necessary? If it's a normal condition
which can happen anytime, it's likely nothing to be debugged.

Kind regards

Jan

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

Stefano Miccoli
In reply to this post by Stefano Miccoli
Sorry for flooding the list short snippets: I have to correct myself:

obviously 0xFFFF are 16bits, two bytes (not four).

My mistake.

S.


On 13 Nov 2016, at 12:28, Stefano Miccoli <[hidden email]> wrote:

I don’t get the point.

Netlink sequence numbers are opaque and are needed only to correlate request/response. Netlink sequence numbers are build by this macro (module/owlib/src/include/ow_w1.h):

#define MAKE_NL_SEQ( bus, seq )  ((uint32_t)(( ((bus) & 0xFFFF) << 16 ) | ((seq) & 0xFFFF)))

This does not mean that one should have 0 < seq <= 0xFFFF, provided that when you parse the response you properly mask both the response netlink sequence number and the owlib seq (which originated the request) to check only the low 4 bytes, i.e.

NL_SEQ(netlink response sequence number) == NL_SEQ(owlib internal sequence number seq)

IMHO concrete evidence should be provided that there is a point in the source where this masking is not done properly, and that is the bug to be corrected. Fudging the sequence number in order to avoid a bug  surfacing in another point of the code is nooot good.

S.

On 13 Nov 2016, at 11:10, Jan Kandziora <[hidden email]> wrote:

Am 13.11.2016 um 00:53 schrieb Enrico Hoepfner:
Hi Jan,

Thank you for the fast answer!
I dont understand exacly , which patch and test from Paul you mean.
Maybe I have take the diff in the wrong direction???? sorry for that!

this are the new lines

<               // seq = ++in->master.w1.seq ;
<               // seq should not be zero or > 0xFFFF
<               seq = NL_SEQ(++in->master.w1.seq);
<               if(seq == 0) {
<                 seq = NL_SEQ(++in->master.w1.seq);
<                 LEVEL_DEBUG("NETLINK sequence number overrun");
<               }


this is what should be replaced

             seq = ++in->master.w1.seq ;

Aaaahhhh, that's why diff -u is preferred.




diff -u ow_w1_send.c.orig ow_w1_send.c
--- ow_w1_send.c.orig    2016-02-04 21:09:53.000000000 +0100
+++ ow_w1_send.c        2016-11-08 20:55:51.351153464 +0100
@@ -68,7 +68,13 @@
        } else {
                // w1 subsidiary bus
                // this bus is locked
-               seq = ++in->master.w1.seq ;
+               // seq = ++in->master.w1.seq ;
+               // seq should not be zero or > 0xFFFF
+               seq = NL_SEQ(++in->master.w1.seq);
+               if(seq == 0) {
+                 seq = NL_SEQ(++in->master.w1.seq);
+                 LEVEL_DEBUG("NETLINK sequence number overrun");
+               }
                bus = in->master.w1.id;
        }


Could you explain what the patch does? Two sentences?

Do you think the DEBUG message is necessary? If it's a normal condition
which can happen anytime, it's likely nothing to be debugged.

Kind regards

Jan

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

eni
Hello Stefano,

Thank you for the answer!

in my opinion the source looks like there are 2 upper Bytes for  bus  and 2 lower Bytes for  seq reserved in nlmsg_seq
... so seq can grow maximal to 0xFFFF.

In the case seq is greater 0xFFFF for instance seq = 0x10000 and bus = 0x1
./module/owlib/src/c/ow_w1_send.c:134    Netlink_Print( nlm, cn, w1m, w1c, pdata, data_size ) ;

send a message with nlmsg_seq = 0x00010000
./module/owlib/src/c/ow_w1_send.c:96    nlm->nlmsg_seq = MAKE_NL_SEQ( bus, seq );

function W1_send_msg returns 0x10000.

than the received message could never match.
module/owlib/src/c/ow_w1_parse.c:235:           if ( NL_SEQ(nlp.nlm->nlmsg_seq) != (unsigned int) seq )
=>

NL_SEQ(nlp.nlm->nlmsg_seq) = 0
seq =
0x10000


 btw. - the nlmsg_seq is not unique, when seq is greater then 0xFFFF.
seq = 0x10001, bus = 0x0002 =>
nlmsg_seq = 0x00030001
seq = 0x00001, bus = 0x0003 => nlmsg_seq = 0x00030001
seq = 0x20001, bus = 0x0001 => nlmsg_seq = 0x00030001
... and so it is not possible to check if this is the related answer.

best regards
 eni

the received message

On 13.11.2016 13:17, Stefano Miccoli wrote:
Sorry for flooding the list short snippets: I have to correct myself:

obviously 0xFFFF are 16bits, two bytes (not four).

My mistake.

S.


On 13 Nov 2016, at 12:28, Stefano Miccoli <[hidden email]> wrote:

I don’t get the point.

Netlink sequence numbers are opaque and are needed only to correlate request/response. Netlink sequence numbers are build by this macro (module/owlib/src/include/ow_w1.h):

#define MAKE_NL_SEQ( bus, seq )  ((uint32_t)(( ((bus) & 0xFFFF) << 16 ) | ((seq) & 0xFFFF)))

This does not mean that one should have 0 < seq <= 0xFFFF, provided that when you parse the response you properly mask both the response netlink sequence number and the owlib seq (which originated the request) to check only the low 4 bytes, i.e.

NL_SEQ(netlink response sequence number) == NL_SEQ(owlib internal sequence number seq)

IMHO concrete evidence should be provided that there is a point in the source where this masking is not done properly, and that is the bug to be corrected. Fudging the sequence number in order to avoid a bug  surfacing in another point of the code is nooot good.

S.

On 13 Nov 2016, at 11:10, Jan Kandziora <[hidden email]> wrote:

Am 13.11.2016 um 00:53 schrieb Enrico Hoepfner:
Hi Jan,

Thank you for the fast answer!
I dont understand exacly , which patch and test from Paul you mean.
Maybe I have take the diff in the wrong direction???? sorry for that!

this are the new lines

<               // seq = ++in->master.w1.seq ;
<               // seq should not be zero or > 0xFFFF
<               seq = NL_SEQ(++in->master.w1.seq);
<               if(seq == 0) {
<                 seq = NL_SEQ(++in->master.w1.seq);
<                 LEVEL_DEBUG("NETLINK sequence number overrun");
<               }


this is what should be replaced

             seq = ++in->master.w1.seq ;

Aaaahhhh, that's why diff -u is preferred.




diff -u ow_w1_send.c.orig ow_w1_send.c
--- ow_w1_send.c.orig    2016-02-04 21:09:53.000000000 +0100
+++ ow_w1_send.c        2016-11-08 20:55:51.351153464 +0100
@@ -68,7 +68,13 @@
        } else {
                // w1 subsidiary bus
                // this bus is locked
-               seq = ++in->master.w1.seq ;
+               // seq = ++in->master.w1.seq ;
+               // seq should not be zero or > 0xFFFF
+               seq = NL_SEQ(++in->master.w1.seq);
+               if(seq == 0) {
+                 seq = NL_SEQ(++in->master.w1.seq);
+                 LEVEL_DEBUG("NETLINK sequence number overrun");
+               }
                bus = in->master.w1.id;
        }


Could you explain what the patch does? Two sentences?

Do you think the DEBUG message is necessary? If it's a normal condition
which can happen anytime, it's likely nothing to be debugged.

Kind regards

Jan

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi


_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

eni
In reply to this post by Stefano Miccoli
Hello Stefano,

 reference to your suggestion, I've test an other patch, which is also working well for me.


[hidden email] $ diff -u module/owlib/src/c/ow_w1_parse.c.orig module/owlib/src/c/ow_w1_parse.c
--- module/owlib/src/c/ow_w1_parse.c.orig       2016-11-14 20:40:17.888223494 +0000
+++ module/owlib/src/c/ow_w1_parse.c    2016-11-14 20:40:54.986633988 +0000
@@ -232,7 +232,8 @@
                        // Don't need to free since nlm not set if BAD
                        return nrs_error ;
                }
-               if ( NL_SEQ(nlp.nlm->nlmsg_seq) != (unsigned int) seq ) {
+               //if ( NL_SEQ(nlp.nlm->nlmsg_seq) != (unsigned int) seq ) {
+               if ( NL_SEQ(nlp.nlm->nlmsg_seq) != NL_SEQ(seq) ) {
                        LEVEL_DEBUG("Netlink sequence number out of order");
                        owfree(nlp.nlm) ;
                        continue ;




On 13.11.2016 13:11, Stefano Miccoli wrote:
This line looks suspicious:

module/owlib/src/c/ow_w1_parse.c:235:           if ( NL_SEQ(nlp.nlm->nlmsg_seq) != (unsigned int) seq ) {

Hope this helps.

S.


On 13 Nov 2016, at 12:28, Stefano Miccoli <[hidden email]> wrote:

I don’t get the point.

Netlink sequence numbers are opaque and are needed only to correlate request/response. Netlink sequence numbers are build by this macro (module/owlib/src/include/ow_w1.h):

#define MAKE_NL_SEQ( bus, seq )  ((uint32_t)(( ((bus) & 0xFFFF) << 16 ) | ((seq) & 0xFFFF)))

This does not mean that one should have 0 < seq <= 0xFFFF, provided that when you parse the response you properly mask both the response netlink sequence number and the owlib seq (which originated the request) to check only the low 4 bytes, i.e.

NL_SEQ(netlink response sequence number) == NL_SEQ(owlib internal sequence number seq)

IMHO concrete evidence should be provided that there is a point in the source where this masking is not done properly, and that is the bug to be corrected. Fudging the sequence number in order to avoid a bug  surfacing in another point of the code is nooot good.

S.

On 13 Nov 2016, at 11:10, Jan Kandziora <[hidden email]> wrote:

Am 13.11.2016 um 00:53 schrieb Enrico Hoepfner:
Hi Jan,

Thank you for the fast answer!
I dont understand exacly , which patch and test from Paul you mean.
Maybe I have take the diff in the wrong direction???? sorry for that!

this are the new lines

<               // seq = ++in->master.w1.seq ;
<               // seq should not be zero or > 0xFFFF
<               seq = NL_SEQ(++in->master.w1.seq);
<               if(seq == 0) {
<                 seq = NL_SEQ(++in->master.w1.seq);
<                 LEVEL_DEBUG("NETLINK sequence number overrun");
<               }


this is what should be replaced

             seq = ++in->master.w1.seq ;

Aaaahhhh, that's why diff -u is preferred.




diff -u ow_w1_send.c.orig ow_w1_send.c
--- ow_w1_send.c.orig    2016-02-04 21:09:53.000000000 +0100
+++ ow_w1_send.c        2016-11-08 20:55:51.351153464 +0100
@@ -68,7 +68,13 @@
        } else {
                // w1 subsidiary bus
                // this bus is locked
-               seq = ++in->master.w1.seq ;
+               // seq = ++in->master.w1.seq ;
+               // seq should not be zero or > 0xFFFF
+               seq = NL_SEQ(++in->master.w1.seq);
+               if(seq == 0) {
+                 seq = NL_SEQ(++in->master.w1.seq);
+                 LEVEL_DEBUG("NETLINK sequence number overrun");
+               }
                bus = in->master.w1.id;
        }


Could you explain what the patch does? Two sentences?

Do you think the DEBUG message is necessary? If it's a normal condition
which can happen anytime, it's likely nothing to be debugged.

Kind regards

Jan

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi


_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

eni
Hello,

the patch below works perfectly! thank you all for your help!

how can I commit this patch to owfs source?
can this do someone of the developers or is there a description how I can do that?

best regards
 eni

On 15.11.2016 16:36, Enrico Hoepfner wrote:
Hello Stefano,

 reference to your suggestion, I've test an other patch, which is also working well for me.


[hidden email] $ diff -u module/owlib/src/c/ow_w1_parse.c.orig module/owlib/src/c/ow_w1_parse.c
--- module/owlib/src/c/ow_w1_parse.c.orig       2016-11-14 20:40:17.888223494 +0000
+++ module/owlib/src/c/ow_w1_parse.c    2016-11-14 20:40:54.986633988 +0000
@@ -232,7 +232,8 @@
                        // Don't need to free since nlm not set if BAD
                        return nrs_error ;
                }
-               if ( NL_SEQ(nlp.nlm->nlmsg_seq) != (unsigned int) seq ) {
+               //if ( NL_SEQ(nlp.nlm->nlmsg_seq) != (unsigned int) seq ) {
+               if ( NL_SEQ(nlp.nlm->nlmsg_seq) != NL_SEQ(seq) ) {
                        LEVEL_DEBUG("Netlink sequence number out of order");
                        owfree(nlp.nlm) ;
                        continue ;




On 13.11.2016 13:11, Stefano Miccoli wrote:
This line looks suspicious:

module/owlib/src/c/ow_w1_parse.c:235:           if ( NL_SEQ(nlp.nlm->nlmsg_seq) != (unsigned int) seq ) {

Hope this helps.

S.


On 13 Nov 2016, at 12:28, Stefano Miccoli <[hidden email]> wrote:

I don’t get the point.

Netlink sequence numbers are opaque and are needed only to correlate request/response. Netlink sequence numbers are build by this macro (module/owlib/src/include/ow_w1.h):

#define MAKE_NL_SEQ( bus, seq )  ((uint32_t)(( ((bus) & 0xFFFF) << 16 ) | ((seq) & 0xFFFF)))

This does not mean that one should have 0 < seq <= 0xFFFF, provided that when you parse the response you properly mask both the response netlink sequence number and the owlib seq (which originated the request) to check only the low 4 bytes, i.e.

NL_SEQ(netlink response sequence number) == NL_SEQ(owlib internal sequence number seq)

IMHO concrete evidence should be provided that there is a point in the source where this masking is not done properly, and that is the bug to be corrected. Fudging the sequence number in order to avoid a bug  surfacing in another point of the code is nooot good.

S.

On 13 Nov 2016, at 11:10, Jan Kandziora <[hidden email]> wrote:

Am 13.11.2016 um 00:53 schrieb Enrico Hoepfner:
Hi Jan,

Thank you for the fast answer!
I dont understand exacly , which patch and test from Paul you mean.
Maybe I have take the diff in the wrong direction???? sorry for that!

this are the new lines

<               // seq = ++in->master.w1.seq ;
<               // seq should not be zero or > 0xFFFF
<               seq = NL_SEQ(++in->master.w1.seq);
<               if(seq == 0) {
<                 seq = NL_SEQ(++in->master.w1.seq);
<                 LEVEL_DEBUG("NETLINK sequence number overrun");
<               }


this is what should be replaced

             seq = ++in->master.w1.seq ;

Aaaahhhh, that's why diff -u is preferred.




diff -u ow_w1_send.c.orig ow_w1_send.c
--- ow_w1_send.c.orig    2016-02-04 21:09:53.000000000 +0100
+++ ow_w1_send.c        2016-11-08 20:55:51.351153464 +0100
@@ -68,7 +68,13 @@
        } else {
                // w1 subsidiary bus
                // this bus is locked
-               seq = ++in->master.w1.seq ;
+               // seq = ++in->master.w1.seq ;
+               // seq should not be zero or > 0xFFFF
+               seq = NL_SEQ(++in->master.w1.seq);
+               if(seq == 0) {
+                 seq = NL_SEQ(++in->master.w1.seq);
+                 LEVEL_DEBUG("NETLINK sequence number overrun");
+               }
                bus = in->master.w1.id;
        }


Could you explain what the patch does? Two sentences?

Do you think the DEBUG message is necessary? If it's a normal condition
which can happen anytime, it's likely nothing to be debugged.

Kind regards

Jan

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi


_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



------------------------------------------------------------------------------


_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

Jan Kandziora
Am 17.11.2016 um 07:13 schrieb Enrico Hoepfner:
>
> the patch below works perfectly! thank you all for your help!
>
> how can I commit this patch to owfs source? can this do someone of
> the developers or is there a description how I can do that?
>
Install git and gitk.

Setup git:

$ git config --global user.name "Enrico Hoepfner"
$ git config --global user.email "[hidden email]"

Clone the owfs git repository from sf.net (or github, that's a mirror):
Use gitk to get an overview about commits.

$ git clone https://github.com/owfs/owfs.git
$ cd owfs
$ gitk&

(later: pull the newest version with "git pull" instead)

Bootstrap the repository to prepare it for your test compiles:

$ ./bootstrap
$ ./configure

*** Apply your patches ***

Do a test.

$ make
$ sudo make install

Commit your patches:

$ git commit -m "fix sequence number bug in w1 host adaptor code" modules/owlib/...

Export your patch in a format suitable for inclusion into the archive:

$ git format-patch master --stdout <old_id>..<new_id>

<old_id> and <new_id> are the SHA1 ids as shown by the git tools, e.g. gitk&

Paste that patch into an email (not as an attachment, just a plain pasting).
Give further explanations on the "why" *in front* of it, and end with a line

Signed-off: "Enrico Hoepfner <[hidden email]"

Make the email subject read "[PATCH 1/1]: fix sequence number bug in w1 host adaptor code"

That's the procedure as used by the Linux kernel maintainers. We have far less
patches than them so we can accept stray patches too, but adapting their procedure
sure helps you to get patches accepted everywhere. It's just good practice.


Kind regards

        Jan

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

eni
Hi Jan,

thank you for the Answer and the description!
I've never made this procedure.

I've try this steps, but where should I send the email to?
the output looks like this:


owserver hangs some minutes when sequence number run over 0xFFFF

$ git format-patch master --stdout
c14b0e446e686b4ab158bad2d6b4ac111df14c8f..79382f3e10c6566ae2e189fb708dade77e077fd2
 From 79382f3e10c6566ae2e189fb708dade77e077fd2 Mon Sep 17 00:00:00 2001
From: Enrico Hoepfner <[hidden email]>
Date: Thu, 17 Nov 2016 17:39:29 +0100
Subject: [PATCH] fix sequence number bug in w1 host adaptor code

---
  module/owlib/src/c/ow_w1_parse.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/module/owlib/src/c/ow_w1_parse.c
b/module/owlib/src/c/ow_w1_parse.c
index 3fd2e8f..611d3dc 100644
--- a/module/owlib/src/c/ow_w1_parse.c
+++ b/module/owlib/src/c/ow_w1_parse.c
@@ -232,7 +232,7 @@ enum Netlink_Read_Status W1_Process_Response( void
(* nrs_callback)( struct netl
                         // Don't need to free since nlm not set if BAD
                         return nrs_error ;
                 }
-               if ( NL_SEQ(nlp.nlm->nlmsg_seq) != (unsigned int) seq ) {
+               if ( NL_SEQ(nlp.nlm->nlmsg_seq) != NL_SEQ(seq) ) {
                         LEVEL_DEBUG("Netlink sequence number out of
order");
                         owfree(nlp.nlm) ;
                         continue ;
--
1.9.1

$

Signed-off: "Enrico Hoepfner <[hidden email]"



On 17.11.2016 11:21, Jan Kandziora wrote:

> Am 17.11.2016 um 07:13 schrieb Enrico Hoepfner:
>> the patch below works perfectly! thank you all for your help!
>>
>> how can I commit this patch to owfs source? can this do someone of
>> the developers or is there a description how I can do that?
>>
> Install git and gitk.
>
> Setup git:
>
> $ git config --global user.name "Enrico Hoepfner"
> $ git config --global user.email "[hidden email]"
>
> Clone the owfs git repository from sf.net (or github, that's a mirror):
> Use gitk to get an overview about commits.
>
> $ git clone https://github.com/owfs/owfs.git
> $ cd owfs
> $ gitk&
>
> (later: pull the newest version with "git pull" instead)
>
> Bootstrap the repository to prepare it for your test compiles:
>
> $ ./bootstrap
> $ ./configure
>
> *** Apply your patches ***
>
> Do a test.
>
> $ make
> $ sudo make install
>
> Commit your patches:
>
> $ git commit -m "fix sequence number bug in w1 host adaptor code" modules/owlib/...
>
> Export your patch in a format suitable for inclusion into the archive:
>
> $ git format-patch master --stdout <old_id>..<new_id>
>
> <old_id> and <new_id> are the SHA1 ids as shown by the git tools, e.g. gitk&
>
> Paste that patch into an email (not as an attachment, just a plain pasting).
> Give further explanations on the "why" *in front* of it, and end with a line
>
> Signed-off: "Enrico Hoepfner <[hidden email]"
>
> Make the email subject read "[PATCH 1/1]: fix sequence number bug in w1 host adaptor code"
>
> That's the procedure as used by the Linux kernel maintainers. We have far less
> patches than them so we can accept stray patches too, but adapting their procedure
> sure helps you to get patches accepted everywhere. It's just good practice.
>
>
> Kind regards
>
> Jan
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: owfs - bug in ow_w1_send.c

Jan Kandziora
Am 17.11.2016 um 18:00 schrieb Enrico Hoepfner:
> Hi Jan,
>
> thank you for the Answer and the description!
> I've never made this procedure.
>
> I've try this steps, but where should I send the email to?
> the output looks like this:
>
To the list.


>
> owserver hangs some minutes when sequence number run over 0xFFFF
>
> $ git format-patch master --stdout
>

> c14b0e446e686b4ab158bad2d6b4ac111df14c8f..79382f3e10c6566ae2e189fb708dade77e077fd2
>  From 79382f3e10c6566ae2e189fb708dade77e077fd2 Mon Sep 17 00:00:00 2001
> From: Enrico Hoepfner <[hidden email]>
> Date: Thu, 17 Nov 2016 17:39:29 +0100
> Subject: [PATCH] fix sequence number bug in w1 host adaptor code
>

Signed-Off: Enrico Hoepfner <[hidden email]>

> ---
>   module/owlib/src/c/ow_w1_parse.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/module/owlib/src/c/ow_w1_parse.c
> b/module/owlib/src/c/ow_w1_parse.c
> index 3fd2e8f..611d3dc 100644
> --- a/module/owlib/src/c/ow_w1_parse.c
> +++ b/module/owlib/src/c/ow_w1_parse.c
> @@ -232,7 +232,7 @@ enum Netlink_Read_Status W1_Process_Response( void
> (* nrs_callback)( struct netl
>                          // Don't need to free since nlm not set if BAD
>                          return nrs_error ;
>                  }
> -               if ( NL_SEQ(nlp.nlm->nlmsg_seq) != (unsigned int) seq ) {
> +               if ( NL_SEQ(nlp.nlm->nlmsg_seq) != NL_SEQ(seq) ) {
>                          LEVEL_DEBUG("Netlink sequence number out of
> order");
>                          owfree(nlp.nlm) ;
>                          continue ;
>
>--
>1.9.1


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers