Hi,
thaks for the info.
[r...@titan owfs-2.8p2]# pwd
/usr/src/owfs-2.8p2
[r...@titan owfs-2.8p2]# find . | grep ruby
[r...@titan owfs-2.8p2]#
Found nothing
Though this is indeed there:
[r...@titan src]# find . -type f -exec grep ruby {} \; -print
ruby Pedro Côrte-Real
./owfs-2.8p2/AUTHORS
[r...@titan src]#
But this is all there seems to be there.
I guess you calling these clients ownet clients explains another
undocumented behavior - why the OWNET flag is set by owfs when
connecting the owserver in the message, though looking at the server it
does not seem to use it for anything.
Doma
On 09/27/2010 05:51 PM, Paul Alfille wrote:
> You are right. The ping is every second or so. If there is no return
> packet within 2 seconds (plus network latency) then owserver isn't
> responding.
>
> There is a ruby entry in the OwNet choices ( owfs/mondule/ownet/ruby )
> that may have already done the owserver protocol parsing work. At the
> very least, it would be worth your time to compare and add any
> features that aren't included.
>
> To review, the ownet modules are much lighter weight. They don't
> include the full library, can only communicate with owserver, and
> really don't know anything about 1-wire. Ownet packages merely send a
> read/write or directory request with a given path name, and get the
> response. That makes the modules easy to write, and allows them to be
> very portable.
>
> Paul Alfille
>
> On Mon, Sep 27, 2010 at 9:00 AM, Domokos MOLNÁR <kret...@freemail.hu
> <mailto:kret...@freemail.hu>> wrote:
>
> Hi Paul,
>
> thanks for the info. Now it's clear.
>
> I guess it is rather a second than a minute.
>
> Thanks anyway.
>
> I use Ruby - there is only PHP and Perl out there if I recall
> correctly.
> I may put this in a Ruby gem later.
>
> This is actually the same setup that yields the owfs file
> unavailability
> I posted recently. It happens on an "always busy" 1wire network.
> Actually my "own client" approach is to work it around to make a
> cleaner
> and certainly safer way from the point of view of my application to
> handle issues than having to kill everything from cron and restart
> when
> the mounted filesystem fails to respond. I guess the filesystem
> approach
> is better suited for not-so-timing-critical applications.
>
> Cheers,
> Doma
>
>
> On 09/27/2010 03:33 AM, Paul Alfille wrote:
> > Hi Molnár
> >
> > It looks like you have written your own program for reading and
> > writing owserver network messages. I think you are seeing the "ping"
> > messages (which should be documented) that have a payload of -1.
> >
> > The ping messages are extra "wait for me" messages from owserver
> when
> > there is a response pending but the 1-wire data is not yet ready
> after
> > a minute. In your case, you are making the bus very busy with an
> > uncached 1Hz polling script, so owserver tells your program to wait.
> >
> > The point of the ping messages is to tell you that your response is
> > still pending; that owserver still is functioning.
> >
> > Indeed 4294967295 is 0xFFFFFFFF or "-1" (granted I'm playing a
> little
> > fast and loose since network encoded longs are really unsigned
> > integers). So check for that magic number in the payload length and
> > discard the packet (it will have no payload data).
> >
> > Paul Alfille
> >
> > On Sun, Sep 26, 2010 at 3:06 PM, Molnár
> Domokos<kret...@freemail.hu <mailto:kret...@freemail.hu>> wrote:
> >> Hi,
> >>
> >> my setup is as follows:
> >>
> >> 1. owserver - uncached
> >>
> >> 2. owfs using owserver
> >>
> >> 3. "client program" using owserver
> >>
> >>
> >> If only the "client program" is running it communicates with
> owserver fine. However, when owfs is also running (doing uncached
> queries @ 1Hz, temp conversion every time on the bus) the "client
> program" sometimes - seemingly in a random manner - receives
> interesting data in about 40% of the cases in front of the correct
> server answer.
> >>
> >> I use owserver and owsf 2.8p2 - failly recent.
> >>
> >> The below session shows the client program run twice in a row,
> the first run succeeds, the second one fails (tries to read
> payload length nr. of chars from the TCP data)
> >>
> >> [r...@titan kazan]# ./owcltest
> >> TCP data:
> 000000000000000c0000000c000000000000000c00000000202020202035332e38313235
> >> version: 0
> >> payloadlength: 12
> >> retval: 12
> >> controlflags: 0
> >> size: 12
> >> offset: 0
> >> payload: 53.8125
> >> [r...@titan kazan]# ./owcltest
> >> TCP data:
>
> 00000000ffffffff00000000000000000000000000000000000000000000000c0000000c000000000000000c00000000202020202035332e38313235
> >> ./owcltest:35:in `[]': bignum too big to convert into `long'
> (RangeError)
> >> from ./owcltest:35
> >> [r...@titan kazan]#
> >>
> >> The second read fails as the string:
> >> "00000000ffffffff00000000000000000000000000000000"
> >> Is added to the response by owserver.
> >>
> >> Looking at: http://owfs.org/index.php?page=tcp-messages
> >>
> >> "RETURN" message
> >>
> >> tcp message
> >> return from caller, to client eventually
> >> includes data if appropriate
> >> includes return code
> >>
> >> Header
> >> version 4bytes network order
> >> "0"
> >> payload 4bytes network order length in bytes of payload field
> >> ret 4bytes network order return value
> >> controlflags 4bytes network order various flags
> >> size 4bytes network order expected size of data read or
> written
> >> offset 4bytes network order location in read or write field
> that data starts
> >> Payload data string. Either just a filename path (for
> directory element, or data read
> >>
> >>
> >>
> >>
> >> tells me its a message with a payload length of 4,294,967,295,
> which causes the client to bail out, and of course is in no way
> compliant with the above message format.
> >>
> >>
> >> The extra header comes in a different IP frame. Here is the
> corresponding interface capture - 3 frames (not the same session
> as above but the same happens here):
> >>
> >> Frame 12 (90 bytes on wire, 90 bytes captured)
> >> Arrival Time: Sep 26, 2010 20:09:39.105727000
> >> [Time delta from previous captured frame: 0.492290000 seconds]
> >> [Time delta from previous displayed frame: 0.492290000
> seconds]
> >> [Time since reference or first frame: 1.186131000 seconds]
> >> Frame Number: 12
> >> Frame Length: 90 bytes
> >> Capture Length: 90 bytes
> >> [Frame is marked: False]
> >> [Protocols in frame: eth:ip:tcp:data]
> >> Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst:
> 00:00:00_00:00:00 (00:00:00:00:00:00)
> >> Destination: 00:00:00_00:00:00 (00:00:00:00:00:00)
> >> Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
> >> .... ...0 .... .... .... .... = IG bit: Individual
> address (unicast)
> >> .... ..0. .... .... .... .... = LG bit: Globally
> unique address (factory default)
> >> Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
> >> Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
> >> .... ...0 .... .... .... .... = IG bit: Individual
> address (unicast)
> >> .... ..0. .... .... .... .... = LG bit: Globally
> unique address (factory default)
> >> Type: IP (0x0800)
> >> Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1
> (127.0.0.1)
> >> Version: 4
> >> Header length: 20 bytes
> >> Differentiated Services Field: 0x00 (DSCP 0x00: Default;
> ECN: 0x00)
> >> 0000 00.. = Differentiated Services Codepoint: Default
> (0x00)
> >> .... ..0. = ECN-Capable Transport (ECT): 0
> >> .... ...0 = ECN-CE: 0
> >> Total Length: 76
> >> Identification: 0x320a (12810)
> >> Flags: 0x04 (Don't Fragment)
> >> 0... = Reserved bit: Not set
> >> .1.. = Don't fragment: Set
> >> ..0. = More fragments: Not set
> >> Fragment offset: 0
> >> Time to live: 64
> >> Protocol: TCP (0x06)
> >> Header checksum: 0x0aa0 [correct]
> >> [Good: True]
> >> [Bad : False]
> >> Source: 127.0.0.1 (127.0.0.1)
> >> Destination: 127.0.0.1 (127.0.0.1)
> >> Transmission Control Protocol, Src Port: owserver (4304), Dst
> Port: 33988 (33988), Seq: 1, Ack: 54, Len: 24
> >> Source port: owserver (4304)
> >> Destination port: 33988 (33988)
> >> Sequence number: 1 (relative sequence number)
> >> [Next sequence number: 25 (relative sequence number)]
> >> Acknowledgement number: 54 (relative ack number)
> >> Header length: 32 bytes
> >> Flags: 0x18 (PSH, ACK)
> >> 0... .... = Congestion Window Reduced (CWR): Not set
> >> .0.. .... = ECN-Echo: Not set
> >> ..0. .... = Urgent: Not set
> >> ...1 .... = Acknowledgment: Set
> >> .... 1... = Push: Set
> >> .... .0.. = Reset: Not set
> >> .... ..0. = Syn: Not set
> >> .... ...0 = Fin: Not set
> >> Window size: 32768 (scaled)
> >> Checksum: 0xfe40 [incorrect, should be 0xf9a8 (maybe
> caused by "TCP checksum offload"?)]
> >> [Good Checksum: False]
> >> [Bad Checksum: True]
> >> Options: (12 bytes)
> >> NOP
> >> NOP
> >> Timestamps: TSval 169128930, TSecr 169127930
> >> Data (24 bytes)
> >>
> >> 0000 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00
> ................
> >> 0010 00 00 00 00 00 00 00 00 ........
> >> Data: 00000000FFFFFFFF00000000000000000000000000000000
> >>
> >>
> >> Frame 13 (66 bytes on wire, 66 bytes captured)
> >> [...Lines removed...]
> >> [SEQ/ACK analysis]
> >> [This is an ACK to the segment in frame: 12]
> >> [The RTT to ACK the segment was: 0.000132000 seconds]
> >>
> >>
> >> Frame 14 (102 bytes on wire, 102 bytes captured)
> >> Arrival Time: Sep 26, 2010 20:09:39.298353000
> >> [Time delta from previous captured frame: 0.192494000 seconds]
> >> [Time delta from previous displayed frame: 0.192494000
> seconds]
> >> [Time since reference or first frame: 1.378757000 seconds]
> >> Frame Number: 14
> >> Frame Length: 102 bytes
> >> Capture Length: 102 bytes
> >> [Frame is marked: False]
> >> [Protocols in frame: eth:ip:tcp:data]
> >> Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst:
> 00:00:00_00:00:00 (00:00:00:00:00:00)
> >> Destination: 00:00:00_00:00:00 (00:00:00:00:00:00)
> >> Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
> >> .... ...0 .... .... .... .... = IG bit: Individual
> address (unicast)
> >> .... ..0. .... .... .... .... = LG bit: Globally
> unique address (factory default)
> >> Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
> >> Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
> >> .... ...0 .... .... .... .... = IG bit: Individual
> address (unicast)
> >> .... ..0. .... .... .... .... = LG bit: Globally
> unique address (factory default)
> >> Type: IP (0x0800)
> >> Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1
> (127.0.0.1)
> >> Version: 4
> >> Header length: 20 bytes
> >> Differentiated Services Field: 0x00 (DSCP 0x00: Default;
> ECN: 0x00)
> >> 0000 00.. = Differentiated Services Codepoint: Default
> (0x00)
> >> .... ..0. = ECN-Capable Transport (ECT): 0
> >> .... ...0 = ECN-CE: 0
> >> Total Length: 88
> >> Identification: 0x320b (12811)
> >> Flags: 0x04 (Don't Fragment)
> >> 0... = Reserved bit: Not set
> >> .1.. = Don't fragment: Set
> >> ..0. = More fragments: Not set
> >> Fragment offset: 0
> >> Time to live: 64
> >> Protocol: TCP (0x06)
> >> Header checksum: 0x0a93 [correct]
> >> [Good: True]
> >> [Bad : False]
> >> Source: 127.0.0.1 (127.0.0.1)
> >> Destination: 127.0.0.1 (127.0.0.1)
> >> Transmission Control Protocol, Src Port: owserver (4304), Dst
> Port: 33988 (33988), Seq: 25, Ack: 54, Len: 36
> >> Source port: owserver (4304)
> >> Destination port: 33988 (33988)
> >> Sequence number: 25 (relative sequence number)
> >> [Next sequence number: 61 (relative sequence number)]
> >> Acknowledgement number: 54 (relative ack number)
> >> Header length: 32 bytes
> >> Flags: 0x18 (PSH, ACK)
> >> 0... .... = Congestion Window Reduced (CWR): Not set
> >> .0.. .... = ECN-Echo: Not set
> >> ..0. .... = Urgent: Not set
> >> ...1 .... = Acknowledgment: Set
> >> .... 1... = Push: Set
> >> .... .0.. = Reset: Not set
> >> .... ..0. = Syn: Not set
> >> .... ...0 = Fin: Not set
> >> Window size: 32768 (scaled)
> >> Checksum: 0xfe4c [incorrect, should be 0x00bc (maybe
> caused by "TCP checksum offload"?)]
> >> [Good Checksum: False]
> >> [Bad Checksum: True]
> >> Options: (12 bytes)
> >> NOP
> >> NOP
> >> Timestamps: TSval 169129122, TSecr 169128930
> >> [SEQ/ACK analysis]
> >> [This is an ACK to the segment in frame: 13]
> >> [The RTT to ACK the segment was: 0.192494000 seconds]
> >> Data (36 bytes)
> >>
> >> 0000 00 00 00 00 00 00 00 0c 00 00 00 0c 00 00 00 00
> ................
> >> 0010 00 00 00 0c 00 00 00 00 20 20 20 20 20 20 33 31
> ........ 31
> >> 0020 2e 36 32 35 .625
> >> Data: 000000000000000C0000000C000000000000000C00000000...
> >>
> >>
> >> Does someone have an idea what's going on here?
> >>
> >> Thanks,
> >> Doma
> >>
> >>
> >>
>
> ------------------------------------------------------------------------------
> >> Start uncovering the many advantages of virtual appliances
> >> and start using them to simplify application deployment and
> >> accelerate your shift to cloud computing.
> >> http://p.sf.net/sfu/novell-sfdev2dev
> >> _______________________________________________
> >> Owfs-developers mailing list
> >> Owfs-developers@lists.sourceforge.net
> <mailto:Owfs-developers@lists.sourceforge.net>
> >> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> >>
> >
>
> ------------------------------------------------------------------------------
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Owfs-developers mailing list
> > Owfs-developers@lists.sourceforge.net
> <mailto:Owfs-developers@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
> >
> >
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> <mailto:Owfs-developers@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
