Hi Dojo,
Sharing this trace from a WS capture: is it known why the DMA attempts to use port 23404?
By default, shouldn't this be in the dynamic range [49152;65535]?
I've hidden IP addresses, but it's DMA as source & CUBE client as destination.
The trace is captured on the NIC of the client running CUBE, when connecting to the DMA.
DM release 10.3.0.0-13184-CU5
Thanks
![](https://community.dataminer.services/wp-content/uploads/wp-user-manager-uploads/2020/10/nomnom.jpg)
Hi Alberto,
From this screenshot alone there is no conclusion that traffic on ports 23404 <-> 64398 is related to DataMiner traffic. Is this a phenomenon that you can reliably reproduce? If so, can you capture the entire lifespan of that TCP connection (I would expect to see atleast one preceding SYN connection handshake attempt) and/or find out to which processes those TCP ports belong on either end?
![](https://community.dataminer.services/wp-content/uploads/wp-user-manager-uploads/2022/05/PIC_al.jpg)
Thanks Bert, will double check the full capture for the SYN, I should be able to reproduce this again. Anything else I can do to identify the process?
The reason why I’m led to think it’s DataMiner traffic is that the capture was done on the NIC of the client, by filtering on the DMA IP address as destination: as such, no row was displayed in WS until I launched CUBE towards the DMA IP.
The additional thing noticed during the test was that the client connection falls back to “polling” mode when this port is not allowed on the local Windows firewall of the client (the restriction wasn’t explicit though, was just “all port allowed” VS “allow only the eventing dynamic port range”).
Hi Alberto,
Do you still need help with this question? If not, could you select the answer to indicate that the question is resolved?