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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: drvAsynIPPort Not receiving broadcast UDP [SEC=UNCLASSIFIED] |
From: | Mark Rivers via Tech-talk <[email protected]> |
To: | "CORNALL, Terry" <[email protected]> |
Cc: | "SAMARDZIC-BOBAN, Vesna" <[email protected]>, Andrew Price <[email protected]>, "CLIFT, Mark" <[email protected]>, "[email protected]" <[email protected]> |
Date: | Mon, 18 Mar 2019 13:48:00 +0000 |
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 <[email protected]>
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
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:
[email protected] <[email protected]> on behalf of CORNALL, Terry via Tech-talk <[email protected]> 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 |