I just downloaded last version (2.8p17) but it does not have this little
patch...
There is another way to submit it?
Thanks :)
2012/4/21 Paul Alfille <paul.alfi...@gmail.com>
> Perfect. Thank you!
>
> On Fri, Apr 20, 2012 at 9:18 AM, Giulio Carabetta <
> giulio.carabe...@gmail.com> wrote:
>
>> Digging deep into the problem, I solved my problem with this little
>> patch.
>> Briefly, in shortcircuit situation _FromServer returns " " and not undef.
>>
>> I think this patch is ok for me, but I suppose it can be good for
>> others...
>> Also, I don't know if this is the best way to solve, or if it necessary
>> to inspect more deeply the _FromServer subroutine.
>>
>> root@oscarbuntu:~# diff -c -N -r
>> /home/oscar/Downloads/owfs-2.8p14/module/ownet/perl5/OWNet/lib/OWNet.pm .
>> ***
>> /home/oscar/Downloads/owfs-2.8p14/module/ownet/perl5/OWNet/lib/OWNet.pm
>> 2011-03-24 02:40:39.000000000 +0100
>> --- ./OWNet.pm 2012-04-20 15:05:22.713276093 +0200
>> ***************
>> *** 615,620 ****
>> --- 615,621 ----
>> # new MSG_DIRALL method -- single packet
>> _ToServer($self,$MSG_DIRALL,$DEFAULT_BLOCK_LENGTH,$NO_OFFSET,$path)
>> || return ;
>> my @r = _FromServer($self) ;
>> + return if !@r ;
>> if (@r) {
>> $self->{SOCK} = undef if $self->{PERSIST} == 0 ;
>> return $r[6] ;
>>
>>
>>
>>
>>
>> Il giorno 18 aprile 2012 17:01, <
>> owfs-developers-ow...@lists.sourceforge.net> ha scritto:
>>
>>
>>> I'm doing a little "access control" based on iButton (DS1990A). It is
>>> read with an usb key (DS9490R). The usb is accessed via owserver, and my
>>> perl script uses OWNet.pm library.
>>>
>>> While scripting I encountered this error:
>>>
>>> Use of uninitialized value $r[1] in numeric eq (==) at
>>> /usr/local/share/perl/5.10.1/OWNet.pm line 630.
>>> substr outside of string at /usr/local/share/perl/5.10.1/OWNet.pm line
>>> 632.
>>>
>>> After such error, my script goes wrong, getting inconsistent data from
>>> owserver. I noticed that in reply of a $owserver->dir("/") loop, data are
>>> returned 1 at time instead of all-together, or the iButton result present
>>> randomly for a long time after I detached it...
>>>
>>> After a lot of test I can replicate the error short circuiting the
>>> iButton probe. I encountered it the first time while testing the script:
>>> sometimes attaching/detaching rapidly the iButton can do it, because while
>>> it is non perfectly inserted the border... :( As a confirm, I also found
>>> (later... :( ) this log from owserver:
>>>
>>> CALL: ow_dir.c:(98) path=/
>>> DATA: ow_usb_msg.c:(183) Status byte[0]: A
>>> DATA: ow_usb_msg.c:(186) short detected
>>> CONNECT: ow_reset.c:(36) 1-wire bus short circuit.
>>> DATA: ow_ds9490.c:(687) CRC error
>>>
>>>
>>> I also tried to solve it inserting a little resistance in series of the
>>> probe, but the error is still there.
>>> May be the resistance too little? Mmm, I don't think it: I tested
>>> different resistance: if it is big, I don't see the iButton, else I got the
>>> error...
>>> On the other hand, is correct: is part of the "resistance" of the
>>> protocol recognize this type of problems.
>>> Only I did not expect to find traces, in another way, in my script: (
>>>
>>> I'd like to know if the lib error is a "correct" behavior (or
>>> uncorrectable).
>>>
>>>
>>> I'm working on Ubuntu 11.04 - Perl 5.10 and owfs 2.8p14
>>>
>>> A simplified script I used to replicate my error is this:
>>>
>>> #!/usr/bin/perl
>>> use strict;
>>> #use warnings;
>>> use FileHandle;
>>> use POSIX;
>>> use Time::HiRes qw(usleep);
>>> use OWNet ;
>>>
>>> use constant DEBUG => 1;
>>>
>>> my $owserver = OWNet->new( "localhost:4304" ) ;
>>>
>>> # Workaround for buffer problem
>>> my $new_stdout = FileHandle->new_from_fd(dup(fileno(STDOUT)), 'w');
>>> $new_stdout->autoflush(1);
>>>
>>>
>>> my @key_found;
>>>
>>> sub scan_bus {
>>> my $dir_list = $owserver->dir('/');
>>> if ( defined($dir_list) ) {
>>> @key_found = split /,/ , $dir_list;
>>> }
>>> print { $new_stdout } "\ndir_list @key_found\n" if DEBUG; }
>>>
>>> while ( 1 ) {
>>> &scan_bus;
>>> usleep(100000);
>>> print { $new_stdout } ".\n" if DEBUG;
>>> }
>>>
>>> -----------------------
>>>
>>> For completeness, I use this /etc/owfs.conf file:
>>>
>>> usb
>>> link=127.0.0.1:4304
>>> Celsius
>>> pid_file = /var/run/owserver.pid
>>> uncached
>>> foreground
>>> error_print 2
>>> error_level 4
>>> # Timeouts (all in seconds)
>>> # cache for values that change on their own timeout_volatile = 1 #
>>> seconds "volatile" values remain in cache # cache for values that change on
>>> command timeout_stable = 4 # seconds "stable" values remain in cache #
>>> cache for directory lists (non-alarm) timeout_directory = 1 # seconds
>>> "directory" values remain in cache # cache for 1-wire device location
>>> timeout_presence = 4 # seconds "device presence" (which bus)
>>> timeout_ha7 = 1
>>> timeout_w1 = 1
>>>
>>> Thanks
>>>
>>> Giulio Carabetta
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> _______________________________________________
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
------------------------------------------------------------------------------
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/
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
