EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: ca client cannot connect server
From: "M.C.Shao" <[email protected]>
To: "Tech-talk" <[email protected]>
Date: Fri, 28 Mar 2003 16:45:31 +0800
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  <20032004  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  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·