Forum Discussion

peterdcross's avatar
15 years ago
Solved

Status 57 Connection refused

I have followed the "in-depth fault find paper 277596 for Status Code 57" yet still have a problem.

I  have a master and media server telnet whose connections are correctly opening on port 13782 on a windows client that lies behind a firewall, traceroute NSlookup etc work.

Everything on the client appears to be correctly installed, with host files and persistent routes, NSlookup for all servers is correct, services using local account.

The backup policy kicks off OK resources are granted the snapshot process starts then client connection refused occurs.

The paper says this cannot be firewall issue, and that no logging is available, so at what point is the connection being refused as all the servers allowed access are viewable in the host properties so the connection can be made to bring this configuration into view.

  • I found a fix for the problem, in the client universal settings I entered the address for the backup network NIC and it kicked off straight away, this is strange because all the name resolution ping tracerout etc resolved correctly to this interface and the client had persistent routes set to use the gateway on this interface. It is now working that is the main thing. I hope this helps some else in the future.

5 Replies

  • Which O/S on the client? Which NBU version?

    Have you confirmed that vnetd and bpcd are both 'listening' on the client?

  • Is port 13724 and not 13782.

    Not that I believe it makes a big difference, master/media servers will first try 13724 and then fall backup to 13782. But when debugging client connection problems this is worth knowing.

  • The client is windows 2003, services all listening

    bpcd 13782/tcp

    bprd/ 13720tcp

    vnetd13724/tcp

    Netbackup Version 6.5

  • I found a fix for the problem, in the client universal settings I entered the address for the backup network NIC and it kicked off straight away, this is strange because all the name resolution ping tracerout etc resolved correctly to this interface and the client had persistent routes set to use the gateway on this interface. It is now working that is the main thing. I hope this helps some else in the future.