Re: pvxs Access/list problem

["Heinz Junkes \(FHI\) via Tech-talk" <tech-talk@aps.anl.gov>]

The patches I mentioned are already built into main (RTEMS7). And that gives us the problem
that UDP traffic stops after I establish a TCP connection on port 5075 and then close it.



> On 19. Nov 2025, at 16:04, Heinz Junkes (FHI) via Tech-talk <tech-talk@aps.anl.gov> wrote:
> 
> Ok, I applied the patch from Chris
> 
> remotes/kiwiIOP/chris/close-optional-on-ref-count
> 
> Then the correction from SEB
> 
> remotes/seb/rtems-6-fix-libio-iop-ref-count
> 
> and that is the result at the moment :
> 
> 
> RTEMS Shell on /dev/console. Use 'help' to list commands.
> erSHLL [/] # r: fcntl: Bad file number
> err: fcntl: Bad file number
> err: fcntl: Bad file number
> err: fcntl: Bad file number
> err: mve0: set_mtu: Bad file number
> err: no valid interfaces found
> warning: no interfaces have a carrier
> err: poll: Bad file number
> err: BSD Program: Could not close file 24 or could not remove it from list of open files
> err: BSD Program: Could not close file 23 or could not remove it from list of open files
> err: BSD Program: Could not close file 22 or could not remove it from list of open files
> 
> :-(
> 
> Heinz
> 
>> On 19. Nov 2025, at 03:26, Michael Davidsaver <mdavidsaver@gmail.com> wrote:
>> 
>> On 11/14/25 8:21 AM, Heinz Junkes (FHI) wrote:
>>> I have now narrowed it down a little further (hopefully)
>>> 
>>> When I boot the target and use the debug messages, I get a constant stream of events:
>> ...
>>> 
>>> When I now display pvlist on another host, I see the target (141.14.128.12):
>>> (I can repeat this several times)
>>> 
>>> (base) hactar:~ junkes$ pvlist
>>> GUID 0x0224EB2FE0ED7782E367B71A version 2: tcp@[ 141.14.128.12:5075 ]
>>> 
>> ...
>>> 
>>> However, when I run pvlist with GUID, the debug output on the target stops immediately:
>>> 
>>> on the client:
>>> 
>>> (base) hactar:~ junkes$ pvlist 0x0224EB2FE0ED7782E367B71A
>> When in "guid" mode, pvlist first sends a UDP discovery ping (same as the no argument case), then opens a TCP connection if it receives a reply with a matching GUID.  So the network traffic of the preceding should be the same as:
>>> pvlist
>>> pvlist 141.14.128.12:5075
>> 
>> If a TCP connection is the trigger, you could try to open a connection with eg. "telnet" or "netcat" and see if the UDP traffic stop coincides on TCP connect or disconnect?  Or maybe you have to send some bytes?
>> 
>