EPICS Home

Experimental Physics and Industrial Control System


 
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  <20192020  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  <20192020 
<== Date ==> <== Thread ==>

Subject: RE: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED]
From: "CORNALL, Terry via Tech-talk" <tech-talk@aps.anl.gov>
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: "SAMARDZIC-BOBAN, Vesna" <vesnas@ansto.gov.au>, "CLIFT, Mark" <cliftm@ansto.gov.au>, "'tech-talk@aps.anl.gov'" <tech-talk@aps.anl.gov>
Date: Mon, 18 Mar 2019 22:53:59 +0000

I confirm what Mark said. To listen for broadcasts, you do need to put in a localport, something like:

drvAsynIPPortConfigure("BD","255.255.255.255:3957:3956 UDP*",0,0,0)

BTW, the device this is to be used for is a Oxford Cryosystems CS800 which has an Ethernet port (obviously) as well as the serial port that their 700 series devices have.

Terry

From: Mark Rivers <rivers@cars.uchicago.edu>
Sent: Tuesday, 19 March 2019 7:07 AM
To: CORNALL, Terry <terryc@ansto.gov.au>
Cc: SAMARDZIC-BOBAN, Vesna <vesnas@ansto.gov.au>; 'Andrew Price' <drarprice@gmail.com>; CLIFT, Mark <cliftm@ansto.gov.au>; 'tech-talk@aps.anl.gov' <tech-talk@aps.anl.gov>
Subject: RE: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED]

 

I realized that there is no requirement that the “port” and “localPort” in the drvAsynIPPortConfigure command be the same.  “port” is the port that asyn will send broadcast messages on, localPort is the port that it will listen for broadcast messages on.

 

I just tried this, the send port is is 3957, the receive port is 3956.  It should listen for broadcast messages on port 3956 and send 3 broadcast messages on port 3957.

 

drvAsynIPPortConfigure("BD","255.255.255.255:3957:3956 UDP*",0,0,0)

asynSetTraceIOMask("BD", 0, 2)

asynSetTraceMask("BD", 0, 9)

iocInit

asynOctetConnect BD1 BD 0 10  200  #address 0, timeout of 10 sec, buffer 200

asynOctetRead BD1 100

asynOctetWrite BD1 "test1"

asynOctetWrite BD1 "test2"

asynOctetWrite BD1 "test3"

 

This is the output:

 

iocRun: All initialization complete

2019-03-18T14:43:49.044 Using dynamically assigned TCP port 53809.

 

asynOctetConnect BD1 BD 0 10  200  #address 0, timeout of 10 sec, buffer 200

asynOctetRead BD1 100

2019/03/18 14:43:49.045 255.255.255.255:3957:3956 UDP* (from 164.54.160.93:4311) read 8

\300\177\363\000\000\000\000\004

2019/03/18 14:43:49.045 255.255.255.255:3957:3956 UDP* (from 164.54.160.118:54121) read 8

B\021\000\002\000\000)\266

2019/03/18 14:43:49.045 255.255.255.255:3957:3956 UDP* (from 164.54.160.173:59185) read 8

B\021\000\002\000\000_\377

2019/03/18 14:43:49.046 255.255.255.255:3957:3956 UDP* (from 164.54.160.150:4311) read 8

B\021\000\002\000\000\000\001

2019/03/18 14:43:49.136 255.255.255.255:3957:3956 UDP* (from 164.54.160.150:4311) read 8

\300\177\363\000\000\000\000\004

2019/03/18 14:43:49.340 255.255.255.255:3957:3956 UDP* (from 164.54.160.162:62189) read 8

B\021\000\002\000\000\334\372

2019/03/18 14:43:49.385 255.255.255.255:3957:3956 UDP* (from 164.54.160.93:4310) read 8

B\021\000\002\000\000\000\001

2019/03/18 14:43:49.510 255.255.255.255:3957:3956 UDP* (from 164.54.160.93:4310) read 8

\300\177\363\000\000\000\000\004

2019/03/18 14:43:49.535 255.255.255.255:3957:3956 UDP* (from 164.54.160.173:52160) read 8

B\021\000\002\000\000_\377

2019/03/18 14:43:49.681 255.255.255.255:3957:3956 UDP* (from 164.54.160.118:54121) read 8

B\021\000\002\000\000)\267

2019/03/18 14:43:49.944 255.255.255.255:3957:3956 UDP* (from 164.54.160.47:63488) read 8

B\021\000\002\000\000_\377

2019/03/18 14:43:49.994 255.255.255.255:3957:3956 UDP* (from 164.54.160.150:4310) read 8

B\021\000\002\000\000\000\001

2019/03/18 14:43:50.119 255.255.255.255:3957:3956 UDP* (from 164.54.160.150:4310) read 8

\300\177\363\000\000\000\000\004

eomReason 0x1

\300\177\363\000\000\000\000\004B\021\000\002\000\000)\266B\021\000\002\000\000_\377B\021\000\002\000\000\000\001\300\177\363\000\000\000\000\004B\021\000\002\000\000\334\372B\021\000\002\000\000\000\001\300\177\363\000\000\000\000\004B\021\000\002\000\000_\377B\021\000\002\000\000)\267B\021\000\002\000\000_\377B\021\000\002\000\000\000\001\300\177\363\000

asynOctetWrite BD1 "test1"

2019/03/18 14:43:50.120 255.255.255.255:3957:3956 UDP* write 5

test1

asynOctetWrite BD1 "test2"

2019/03/18 14:43:50.120 255.255.255.255:3957:3956 UDP* write 5

test2

asynOctetWrite BD1 "test3"

2019/03/18 14:43:50.120 255.255.255.255:3957:3956 UDP* write 5

test3

epics>

 

This is part of the capture from tcpdump.

 

This is the packet received from 164.54.160.118 at 14:43:49.681 reported above.  This proves it is listening on port 3956 correctly.

 

14:43:49.681290 IP viper.cars.aps.anl.gov.54121 > 255.255.255.255.gvcp: UDP, length 8

     0x0000:  4500 0024 069b 4000 4011 ef81 a436 a076  E..$..@.@....6.v

     0x0010:  ffff ffff d369 0f74 0010 6c79 4211 0002  .....i.t..lyB...

     0x0020:  0000 29b7 0000 0000 0000 0000 0000       ..)...........

 

These are the 3 broadcast messages that asyn sent on port 3957, which is the officially registered port for the mqe-broker.  The message contents are test1, test2, test3 as expected.

 

14:43:50.119680 IP corvette.cars.aps.anl.gov.gvcp > 255.255.255.255.mqe-broker: UDP, length 5

     0x0000:  4500 0021 f2b2 4000 4011 0391 a436 a052  E..!..@.@....6.R

     0x0010:  ffff ffff 0f74 0f75 000d 44a7 7465 7374  .....t.u..D.test

     0x0020:  31                                       1

14:43:50.120012 IP corvette.cars.aps.anl.gov.gvcp > 255.255.255.255.mqe-broker: UDP, length 5

     0x0000:  4500 0021 f2b3 4000 4011 0390 a436 a052  E..!..@.@....6.R

     0x0010:  ffff ffff 0f74 0f75 000d 44a7 7465 7374  .....t.u..D.test

     0x0020:  32                                       2

14:43:50.120307 IP corvette.cars.aps.anl.gov.gvcp > 255.255.255.255.mqe-broker: UDP, length 5

     0x0000:  4500 0021 f2b4 4000 4011 038f a436 a052  E..!..@.@....6.R

     0x0010:  ffff ffff 0f74 0f75 000d 44a7 7465 7374  .....t.u..D.test

     0x0020:  33                                       3

 

I will update the asyn documentation to note that “port” and “localport” can be different for UDP broadcasts,

 

Mark

 

From: Mark Rivers
Sent: Monday, March 18, 2019 8:48 AM
To: CORNALL, Terry <terryc@ansto.gov.au>
Cc: SAMARDZIC-BOBAN, Vesna <vesnas@ansto.gov.au>; Andrew Price <drarprice@gmail.com>; CLIFT, Mark <cliftm@ansto.gov.au>; tech-talk@aps.anl.gov
Subject: RE: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED]

 

Hi Terry,

 

I just verified that my suggestion works.  This is from my startup script:

 

drvAsynIPPortConfigure("BD","255.255.255.255:3956:3956 UDP",0,0,0)

asynSetTraceIOMask("BD", 0, 2)

asynSetTraceMask("BD", 0, 9)

iocInit

asynOctetConnect BD1 BD 0 10  200  #address 0, timeout of 10 sec, buffer 200

asynOctetRead BD1 100

 

So I am listening for broadcasts on port 3956, which is the GigeVision Control Port (gvcp).

 

When I run the IOC I see the following:

 

drvAsynIPPortConfigure("BD","255.255.255.255:3956:3956 UDP",0,0,0)

 

asynSetTraceIOMask("BD", 0, 2)

asynSetTraceMask("BD", 0, 9)

iocInit

Starting iocInit

############################################################################

## EPICS R7.0.2

## EPICS Base built Dec 21 2018

############################################################################

drvStreamInit: Warning! STREAM_PROTOCOL_PATH not set. Defaults to "."

cas warning: Configured TCP port was unavailable.

cas warning: Using dynamically assigned TCP port 40596,

cas warning: but now two or more servers share the same UDP port.

cas warning: Depending on your IP kernel this server may not be

cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)

iocRun: All initialization complete

2019-03-18T08:38:32.152 Using dynamically assigned TCP port 50457.

 

asynOctetConnect BD1 BD 0 10  200  #address 0, timeout of 10 sec, buffer 200

asynOctetRead BD1 100

2019/03/18 08:38:32.153 255.255.255.255:3956:3956 UDP (from 164.54.160.118:54121) read 8

B\021\000\002\000\000\324\030

2019/03/18 08:38:32.153 255.255.255.255:3956:3956 UDP (from 164.54.160.15:59139) read 8

B\021\000\002\000\000_\377

2019/03/18 08:38:32.269 255.255.255.255:3956:3956 UDP (from 164.54.160.162:62189) read 8

B\021\000\002\000\000\207]

2019/03/18 08:38:32.376 255.255.255.255:3956:3956 UDP (from 164.54.160.150:4311) read 8

B\021\000\002\000\000\000\001

2019/03/18 08:38:32.493 255.255.255.255:3956:3956 UDP (from 164.54.160.93:4310) read 8

B\021\000\002\000\000\000\001

2019/03/18 08:38:32.501 255.255.255.255:3956:3956 UDP (from 164.54.160.150:4311) read 8

\300\177\363\000\000\000\000\004

2019/03/18 08:38:32.617 255.255.255.255:3956:3956 UDP (from 164.54.160.93:4310) read 8

\300\177\363\000\000\000\000\004

2019/03/18 08:38:32.681 255.255.255.255:3956:3956 UDP (from 164.54.160.118:54121) read 8

B\021\000\002\000\000\324\031

2019/03/18 08:38:32.708 255.255.255.255:3956:3956 UDP (from 164.54.160.47:63488) read 8

B\021\000\002\000\000_\377

2019/03/18 08:38:33.273 255.255.255.255:3956:3956 UDP (from 164.54.160.162:62189) read 8

B\021\000\002\000\000\207^

2019/03/18 08:38:33.343 255.255.255.255:3956:3956 UDP (from 164.54.160.150:4310) read 8

B\021\000\002\000\000\000\001

2019/03/18 08:38:33.442 255.255.255.255:3956:3956 UDP (from 164.54.160.173:52160) read 8

B\021\000\002\000\000_\377

2019/03/18 08:38:33.460 255.255.255.255:3956:3956 UDP (from 164.54.160.93:4311) read 8

B\021\000\002\000\000\000\001

eomReason 0x1

B\021\000\002\000\000\324\030B\021\000\002\000\000_\377B\021\000\002\000\000\207]B\021\000\002\000\000\000\001B\021\000\002\000\000\000\001\300\177\363\000\000\000\000\004\300\177\363\000\000\000\000\004B\021\000\002\000\000\324\031B\021\000\002\000\000_\377B\021\000\002\000\000\207^B\021\000\002\000\000\000\001B\021\000\002\000\000_\377B\021\000\002

 

 

So I am correctly seeing the broadcast messages from a number of machines on that port.

 

I reproduced your result that it does not work if I omit the localPort parameter in the drvAsynIPPort command.

 

I verified that it works with either UDP or UDP* in the drvAsynIPPort configure command.

 

I will update the documentation to say that the localPort parameter is required to receive UDP broadcasts.

 

Mark

 

 

From: Mark Rivers <rivers@cars.uchicago.edu>
Sent: Monday, March 18, 2019 7:14 AM
To: CORNALL, Terry <terryc@ansto.gov.au>
Cc: SAMARDZIC-BOBAN, Vesna <vesnas@ansto.gov.au>; Andrew Price <drarprice@gmail.com>; CLIFT, Mark <cliftm@ansto.gov.au>; tech-talk@aps.anl.gov
Subject: Re: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED]

 

Hi Terry,

 

I just looked at the code for drvAsynIPPort.  It only calls bind() if you specify the localPort in your hostInfo string.  So I think this should be


drvAsynIPPortConfigure("CRYOREAD01","255.255.255.255:30304:30304 UDP*",0,0,0) 

 

I think you maybe should use UPD and not UDP*.  UDP* is meant for sending broadcasts, not receiving them.

 

I am not sure anyone has used drvAsynIPPort for receiving broadcasts, only for sending them.  Please give the above a try and if it does not work I will fix the driver.

 

Mark

 

 


From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on behalf of CORNALL, Terry via Tech-talk <tech-talk@aps.anl.gov>
Sent: Sunday, March 17, 2019 11:31 PM
To: tech-talk@aps.anl.gov
Cc: SAMARDZIC-BOBAN, Vesna; Andrew Price; CLIFT, Mark
Subject: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED]

 

Hi All.

I have a device that sends its status as a UDP broadcast with port 30304 and I’d like to use asynIP to get it but can’t get it working using simple interactive commands in EPICS iocsh.

 

I have successfully tested the server and host in question  using a little python socket program, essentially:

 

########### start PYTHON CODE###############

broadcastIP = '255.255.255.255'   #note that 10.6.255.255 doesn’t work, though I expected it to…

idBroadcast = (broadcastIP,30304)

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)

s.bind(idBroadcast)

m, reportedAddress = s.recvfrom(bufMax)  #m gets the data and reportedAddress indicates where it was broadcast from

################END PYTHON CODE######################

and it works, gets the status every second. So no firewalls getting in the way and the port number is OK and status is being broadcast every second as expected.

 

Trying to use asynIP in EPICS, I do the following to test, using asynDriver release 4.34:

 

#########start EPICS IOCSH commands############

drvAsynIPPortConfigure("CRYOREAD01","255.255.255.255:30304 UDP*",0,0,0)  #Have also tried the specific subnet broadcast 10.6.0.255 and 10.6.255.255 with no luck

…… #no errors reported

iocInit()

asynSetTraceMask  ("CRYOREAD01",-1,0xFF)  

asynSetTraceIOMask("CRYOREAD01",-1,0xFF)

…..#no errors reported

epics>

#Then ran the following interactively

epics> asynOctetConnect CR CRYOREAD01 0 10  200  #address 0, timeout of 10 sec, buffer 200

epics> asynOctetRead CR 100

From asynTrace I get:

 

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort locking port

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort created queueLockPortPvt=0x183c0f0

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort created queueLockPortPvt=0x183c0f0, event=0x183c110, mutex=0x18318c0

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort taking mutex 0x18318c0

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort queueing request

2019/03/18 15:10:17.359 CRYOREAD01 addr -1 queueRequest priority 0 not lockHolder

2019/03/18 15:10:17.359 CRYOREAD01 schedule queueRequest timeout

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort waiting for event

2019/03/18 15:10:17.359 asynManager::portThread port=CRYOREAD01 callback

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPortCallback signaling begin event

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort got event from callback

2019/03/18 15:10:17.359 255.255.255.255:30304 UDP* read.

…..waits 10 sec

2019/03/18 15:10:27.369 CRYOREAD01 read from low-level driver returned 1

2019/03/18 15:10:27.369 CRYOREAD01 queueUnlockPort

2019/03/18 15:10:27.369 CRYOREAD01 asynManager::queueUnlockPort waiting for event

2019/03/18 15:10:27.369 CRYOREAD01 queueUnlockPort unlock mutex 0x18318c0 complete.

2019/03/18 15:10:27.369 Error reading, ninp=0 error 255.255.255.255:30304 UDP* timeout: Resource temporarily unavailable

and it always timesout with nothing received.

 

 

I also tried asynReport 4 CRYOREAD01 and got the following. Somewhat suspicious of nDevices=0 but this might be ok for a nonMultiDevice?

CRYOREAD01 multiDevice:No canBlock:Yes autoConnect:Yes

    enabled:Yes connected:Yes numberConnects 1

    nDevices 0 nQueued 0 blocked:No

    asynManagerLock:No synchronousLock:No

    exceptionActive:No exceptionUsers 1 exceptionNotifys 0

    traceMask:0xff traceIOMask:0xff traceInfoMask:0x1

    interposeInterfaceList

        asynOctet pinterface 0x7f986797d6e0 drvPvt 0x16d1410

    interfaceList

        asynCommon pinterface 0x7f986797a750 drvPvt 0x16cd7c0

        asynOption pinterface 0x7f986797a770 drvPvt 0x16cd7c0

        asynOctet pinterface 0x16cd8e0 drvPvt 0x16cd7c0

    Port 255.255.255.255:30304 UDP*: Connected

                    fd: 4

    Characters written: 0

       Characters read: 0

 

 

Can anyone suggest why this isn’t working or what I should do to better test it? (I did see comment in techtalk about UDP broadcast issues, but I think they were for versions older than the one I am using)

 

Thanks,

Terry


References:
drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED] CORNALL, Terry via Tech-talk
Re: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED] Mark Rivers via Tech-talk
RE: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED] Mark Rivers via Tech-talk
RE: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED] Mark Rivers via Tech-talk

Navigate by Date:
Prev: RE: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED] Mark Rivers via Tech-talk
Next: asyn R4-35 available Mark Rivers via Tech-talk
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  <20192020 
Navigate by Thread:
Prev: RE: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED] Mark Rivers via Tech-talk
Next: [no subject] VASU PADSUMBIA via Tech-talk
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  <20192020