Re: [CUL] weird ping replies (SOLVED)
Ernst Cozijnsen
mentioned problem below (and more) where solved.
Cheers,
Ernst
@ Rudolph: Would it be an idea to post a change calender for changes /
fixes made to the culfw?
On Sun, Mar 20, 2011 at 8:14 PM, Ernst Cozijnsen
<ernst.c...@gmail.com> wrote:
> I have a similair problem and more
>
> ernst@devbak:~$ ping -c 20 192.168.10.2
> PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
> 64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=10.0 ms
> 64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=1.47 ms
> 64 bytes from 192.168.10.2: icmp_seq=3 ttl=64 time=1.47 ms
> 64 bytes from 192.168.10.2: icmp_seq=4 ttl=64 time=1.47 ms
> 64 bytes from 192.168.10.2: icmp_seq=5 ttl=64 time=1.52 ms
> 64 bytes from 192.168.10.2: icmp_seq=6 ttl=64 time=1.47 ms
> 64 bytes from 192.168.10.2: icmp_seq=7 ttl=64 time=1.45 ms
> 64 bytes from 192.168.10.2: icmp_seq=8 ttl=64 time=1.53 ms
> 64 bytes from 192.168.10.2: icmp_seq=9 ttl=64 time=1.45 ms
> 64 bytes from 192.168.10.2: icmp_seq=10 ttl=64 time=1.48 ms
> 64 bytes from 192.168.10.2: icmp_seq=11 ttl=64 time=1.52 ms
>
> --- 192.168.10.2 ping statistics ---
> 20 packets transmitted, 11 received, 45% packet loss, time 19015ms
> rtt min/avg/max/mdev = 1.454/2.268/10.082/2.471 ms
> ernst@devbak:~$ ping -c 20 192.168.10.2
>
> ernst@devbak:~$ ping -c 20 192.168.10.2
> PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
> 64 bytes from 192.168.10.2: icmp_seq=17 ttl=64 time=1.45 ms
> 64 bytes from 192.168.10.2: icmp_seq=18 ttl=64 time=1.51 ms
> 64 bytes from 192.168.10.2: icmp_seq=19 ttl=64 time=1.51 ms
> 64 bytes from 192.168.10.2: icmp_seq=20 ttl=64 time=1.50 ms
>
> --- 192.168.10.2 ping statistics ---
> 20 packets transmitted, 4 received, 80% packet loss, time 19008ms
> rtt min/avg/max/mdev = 1.457/1.498/1.519/0.045 ms
>
> Major packet loss!!
>
>
> in the fhem logfile if often find these lines
>
> 2011.03.20 19:17:03 2: FHEMWEB port 8083 opened
> 2011.03.20 19:17:03 2: FHEMWEB port 8084 opened
> 2011.03.20 19:17:03 3: CUL opening CUNO1 device 192.168.10.2:2323
> 2011.03.20 19:17:06 3: Can't connect to 192.168.10.2:2323: No route to host
> 2011.03.20 19:17:06 0: Server started (version =VERS= from =DATE= ($Id:
> fhem.pl,v 1.132 2011-02-12 11:27:16 rudolfkoenig Exp $), pid 2157)
>
> This happens almost every day and i need to coldboot the CUNO to get it back
> to life.
>
> I'm very open to sugestions here.
>
> Ernst
>
>
> On Sun, Mar 20, 2011 at 2:23 PM, Jelle Kalf <j.r....@gmail.com> wrote:
>>
>> Hi,
>>
>> I'm getting weird ping replies from my CUNO as listed below:
>> ----------------------
>> root@elmo:~# ping -c 20 192.168.12.110
>> PING 192.168.12.110 (192.168.12.110) 56(84) bytes of data.
>> 64 bytes from 192.168.12.110: icmp_req=1 ttl=64 time=1.50 ms
>> 64 bytes from 192.168.12.110: icmp_req=2 ttl=64 time=1.49 ms
>> 64 bytes from 192.168.12.110: icmp_req=3 ttl=64 time=1.51 ms
>> 64 bytes from 192.168.12.110: icmp_req=4 ttl=64 time=1.51 ms
>> 64 bytes from 192.168.12.110: icmp_req=5 ttl=64 time=1.50 ms
>> 64 bytes from 192.168.12.110: icmp_req=6 ttl=64 time=1.46 ms
>> 64 bytes from 192.168.12.110: icmp_req=7 ttl=64 time=1.51 ms
>> 64 bytes from 192.168.12.110: icmp_req=8 ttl=64 time=1.46 ms
>> 64 bytes from 192.168.12.110: icmp_req=9 ttl=64 time=1.50 ms
>> 64 bytes from 192.168.12.110: icmp_req=10 ttl=64 time=1.47 ms
>> 64 bytes from 192.168.12.110: icmp_req=11 ttl=64 time=1.49 ms
>> 64 bytes from 192.168.12.110: icmp_req=12 ttl=64 time=1.51 ms
>> 64 bytes from 192.168.12.110: icmp_req=13 ttl=64 time=1.48 ms
>> 64 bytes from 192.168.12.110: icmp_req=14 ttl=64 time=1.45 ms
>> 64 bytes from 192.168.12.110: icmp_req=15 ttl=64 time=1.47 ms
>> wrong data byte #40 should be 0x28 but was 0xa8
>> #8 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e
>> 1f 20 21 22 23 24 25 26 27
>> #40 a8 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
>> 64 bytes from 192.168.12.110: icmp_req=16 ttl=64 time=1.49 ms
>> 64 bytes from 192.168.12.110: icmp_req=17 ttl=64 time=1.50 ms
>> 64 bytes from 192.168.12.110: icmp_req=18 ttl=64 time=1.50 ms
>> 64 bytes from 192.168.12.110: icmp_req=19 ttl=64 time=1.49 ms
>> wrong data byte #40 should be 0x28 but was 0xa8
>> #8 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e
>> 1f 20 21 22 23 24 25 26 27
>> #40 a8 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
>> 64 bytes from 192.168.12.110: icmp_req=20 ttl=64 time=1.45 ms
>>
>> --- 192.168.12.110 ping statistics ---
>> 20 packets transmitted, 20 received, 0% packet loss, time 19028ms
>> rtt min/avg/max/mdev = 1.451/1.490/1.512/0.041 ms
>> ------------------
>>
>> - This happens when regardless of a fresh reboot of the cuno device or
>> a long time since I've rebooted it.
>> - I'm running the latest 1.40 firmware.
>> - I've tried running the latest cvs firmware as well (4 weeks back),
>> same issue
>>
>> There are 2 switches (not hubs) in between my fhem hosts, no link
>> agregation or anything. Just a single connection between the switches.
>> One is a simple 8port GB switch, un managed. The other is a Cisco
>> 3750g. I haven't found any port issues on both switches.
>>
>> any suggestions?
>>
>> --
>> Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe CUL
>> fans beigetreten sind.
>> Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine
>> E-Mail an cul-...@googlegroups.com.
>> Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an
>> cul-fans+u...@googlegroups.com.
>> Besuchen Sie die Gruppe unter
>> http://groups.google.com/group/cul-fans?hl=de, um weitere Optionen zu
>> erhalten.
>>
>
>
Rudolf Koenig
> fixes made to the culfw?
This is such a good idea, that we are doing it since the beginning :)
See the culfw/CHANGED file.
Jelle Kalf
I think he ment a change calendar for planned changes. Sort of a
bugtracker in which people can track open bugs, requested changed,
planned changes etc.
The culfw/CHANGED file shows in place changes rather then the above
mentioned items.
The CHANGED file also seems to indicate nothing has been changed on
the general culfw code rather some InterTechno and newer Cul version
support. Hasn't anything been changed on the underlying code like
network etc? this culfw 1.42 seems to behave rather well for something
that hasn't been changed. ;-)
Jelle
Rudolf Koenig
> changed. ;-)
Thats what I'm telling. I am not the only one with a write access to the CVS
repository, and I have not done a thorough diff either, but as far as I know
there is no reason for "old" hardware (i.e not CULV4) to upgrade to the
current (1.42) firmware.
Olaf Droegehorn
being one of the developers for CULFW, Rudolf is fully right. For
CULV3.x and below there is no need to update to FW 1.42.
Corrections to InterTechno have been done in 1.41, since there most of
us have not touched the code.
And that has been listed in the CHANGED file.
If somebody wants a calendar of PLANNED changes, than somebody should
put money on the table and pay developers.
Otherwise we are doing those things in our free time, for good of all of
us. And in that model, things will come up, when they are ready.
Best,
Olaf
------------------------------------------------------------------------
Prof. Dr. Olaf Droegehorn
General Manager Tel. : +49-561-82020-410
DHS - Computertechnik GmbH Fax. : +49-561-82020-399
Carlsdorfer Stra�e 3 E-Mail: O.Droegehorn@dhs-
computertechnik.de
D-34128 Kassel WEB: www.dhs-computertechnik.de
------------------------------------------------------------------------
Ernst Cozijnsen
> repository, and I have not done a thorough diff either, but as far as I know
> there is no reason for "old" hardware (i.e not CULV4) to upgrade to the
> current (1.42) firmware.
I truly believe you on your nice smile ;-) but the fact is that the
problems i had ALL disappeared an that cannot be a coincidence right?