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> 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 >> 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
