hi,friends,
I am writing to you to ask for a solution to a "ca client cannot connect server" situation, untill now I think it's base's internal problem based on the following facts:
EPICS BASE VERSION: baseR3.14.0beta2, baseR3.14-cvs-snapshot-20030312
Target Arch: i386-rtems
Host Arch: linux-x86
(As you see, I didn't list baseR3.14.1. Because there is a problem when i try to run its application on my target, seeming
to be some cpu module initialization problem.I asked about this before through teck-talk, but not resolved.The two
versions listed here is the two running normally on i386-rtems target, and both of them have this CA connection problem. )
Here, I will let "caEventRate" represent CA Clients, for there're similar situations with other CA Clients.
After an application booted on the target(I am using ehterboot to do this, accorrding to Eric Norum's method.),use
"caEventRate" to connect to the server:
------------------------------------------------
[root@Ashao root]# caEventRate root:aiExample
Connecting to CA Channel "root:aiExample" 1 times.CA.Client.Exception...............................................
Warning: "Virtual circuit disconnect"
Context: "166.111.32.231:5064"
Source File: ../cac.cpp line 1534
Current Time: Thu Mar 27 2003 15:29:47.220285000
..................................................................
CA.Client.Exception...............................................
Warning: "Virtual circuit disconnect"
Context: "166.111.32.231:5064"
Source File: ../cac.cpp line 1534
Current Time: Thu Mar 27 2003 15:30:22.258417000
..................................................................
---------------------------------------------
During this, use a network analyzer "Ethereal" to monitor the rtems ioc's network activity.
Here is parts of the logs, I cut this part because I think this is correspoding to one "CA.Client.Exception"
period as above:(target IP address is 166.111.32.231, host IP address is 166.111.32.242, their broadcast address is 166.111.32.255.)
-------------------------------------------------
No. Time Source Destination Protocol Info
... ...
2967 125.313024 166.111.32.231 166.111.32.255 UDP Source port:1025 Destination port:5065
2968 125.988879 166.111.32.231 166.111.32.242 UDP Source port:5064 Destination port:32784
2969 125.994271 166.111.32.242 166.111.32.231 TCP 32819>5064 [SYN] Seq=2627596724 Ack=0 Win=5840 Len=0 MSS=1460 TSV=1235268 TSER=0 WS=0
2970 125.994425 166.111.32.231 166.111.32.242 TCP 5064>32819 [SYN,ACK] Seq=21757906 Ack=2627596725 Win=17376 Len=0 MSS=1460 WS=0
TSV=229 TSER=1235268
2971 125.994481 166.111.32.242 166.111.32.231 TCP 32819>5064 [ACK] Seq=2627596725 Ack=21757907 Win=5840 Len=0 TSV=1235268 TSER=229
2972 125.995207 166.111.32.242 166.111.32.231 SMPP SMPP Outbind [trailing data][Unreassembled Packet]
2973 126.196246 166.111.32.242 166.111.32.231 SMPP SMPP Outbind [trailing data][Unreassembled Packet]
2974 126.598567 166.111.32.242 166.111.32.231 SMPP SMPP Outbind [trailing data][Unreassembled Packet]
2975 127.403201 166.111.32.242 166.111.32.231 SMPP SMPP Outbind [trailing data][Unreassembled Packet]
2976 129.012476 166.111.32.242 166.111.32.231 SMPP SMPP Outbind [trailing data][Unreassembled Packet]
2977 132.231015 166.111.32.242 166.111.32.231 SMPP SMPP Outbind [trailing data][Unreassembled Packet]
2978 137.315911 166.111.32.231 166.111.32.255 UDP Source port:1025 Destination port:5065
2979 138.668100 166.111.32.242 166.111.32.231 SMPP SMPP Outbind [trailing data][Unreassembled Packet]
2980 151.542280 166.111.32.242 166.111.32.231 SMPP SMPP Outbind [trailing data][Unreassembled Packet]
2981 152.318720 166.111.32.231 166.111.32.255 UDP Source port:1025 Destination port:5065
2982 160.998987 166.111.32.242 166.111.32.231 TCP 32819>5064 [FIN,PSH,ACK] Seq=2627596821 Ack=21757907 Win=5840 Len=16 TSV=1253192 TSER=229
2983 160.999109 166.111.32.231 166.111.32.242 TCP 5064>32819 [ACK] Seq=21757907 Ack=2627596725 Win=17376 Len=0 TSV=299 TSER=1235268
2984 160.999177 166.111.32.242 166.111.32.231 TCP 32819>5064 [RST,ACK] Seq=2627596838 Ack=21757907 Win=5840 Len=0 TSV=1253192 TSER=299
2985 161.057211 166.111.32.231 166.111.32.242 UDP Source port:5064 Destination port:32784
2986 161.059848 166.111.32.242 166.111.32.231 TCP 32820>5064 [SYN] Seq=2668597640 Ack=0 Win=5840 Len=0 MSS=1460 TSV=12353223 TSER=0 WS=0
----------------------------------------------
I cann't explain all these transport explicitly. Hope for your help. Let me go on to describe the situation.
After this, I trun to the CA refference manual. First, check the environment viariables, I make sure that all these ca
related environment viariables are set correctly.Secondly, CA command line utilities have similiar situations with
caEventRate, except for casw. For casw, if I reboot the ioc, it can capture beacons from ioc. But when ioc running,
casw will not see any beacons, should it? Then i follow the "trouble shooting" section in CAref.html:
1) Client and server have the same broadcast address: 166.111.32.255, This can be testified by netstat on RTEMS and ifconfig on Linux.
2)Client and server are using the same UDP port:5064(default).
3)About beacons, as described for casw.
4) Server has enough unused mbufs. I say this because, If I start iocLogServer on linux host and issue iocLogInit command
on ioc, ioc could send its logs to host correctly.I have set log file and log server's ip
in $(EPICS_BASE)/configure/CONFIG_SITE_ENV. And issure netstat <level> on ioc, most of the mbufs are not used yet.
So far, I think it's base CA's internal reseasons which causing this problem, I have tried several base versions mentioned
in the beginning.Or maybe, my knowledgement restricts my scope on this problem.
Ok, I have tried to describe the situation more clearly, hope that I have shown you clearly too.Any suggestions on any
part of this situation are appreciated.Thanks in advance.
regrads,
--
Shao Mingchao
Engineering Physics Department
Tsinghua University
Beijing,100084,China
Tel:86-10-62784552
- Navigate by Date:
- Prev:
Re: medm unable to contact CA repeater after 50 tries M.C.Shao
- Next:
Re: "assert (!plink->value.pv_link.pvt)" failed Marty Kraimer
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: "assert (!plink->value.pv_link.pvt)" failed Feng, Shuchen
- Next:
Building 3.14.1 for MVME5100 (Internal compiler error) Zoltan Kakucs
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|