On 10/18/22 17:51, Bill Arlofski via Bacula-users wrote:
Hello Josh (everyone else too),
I can confirm that if the FD --> DIR connection is opened, then the
Director does use this socket to communicate to the FD.
Excellent!
However, the "Connecting to Client..." message does not change, and
incorrectly (IMHO) reports that it is making an outbound
connection to the IP:port specified in the Director's resource for
this Client:
----8<----
*s client=stinky-fd
Connecting to Client stinky-fd at 10.1.1.222:9102
----8<----
I did an `estimate` and then ran a job. Packet traces confirm that the
connection(s) created by the client are used and the
Director does not actually call out to it. A nice feature request
would be to change this Connecting message to something like:
----8<----
*s client=stinky-fd
Connecting to Client stinky-fd on inbound connection opened by Client
----8<----
Yes. That would be less confusing.
Interestingly, if the Client's connection into the Director is down
(ie: kill the FD), then the Director does actually make
the attempt to connect to the C
lient on it's defined IP:port, which of course fails. :)
I think this is also incorrect behavior, or at least it is not
behaving as documented, or in the way I would expect/want it
to for Clients behind NAT when we know the Director will never be able
to make the connection.
That seems like a bug to me too. If 'Connect to Director = yes', the Dir
should never attempt to open a connection to FD.
This is all nice information and it proves this feature is (mostly)
working as documented, but now we still need to solve
Wanderlei's issue. :)
Yes. It seems like the FD > Dir connection is not active or is
firewalled. Yet, Rodrigo tested with telnet from the client to port 9101
on the Director and that worked, even though 'status client' in bconsole
times out. This is why I still wonder if 802.3az EEE is not waking up as
expected on the client's router or the client is on WiFi and going into
sleep mode. I don't know if that is the case, but it might explain why
telnet from the client works, but bconsole commands do not. A quick test
would be to use bconsole from the client machine and see if a status
client is possible.
I am guessing one or more of a few things are the possible culprit:
- Port forwarding at the firewall is not working as expected
- The `Address = xxxx` in the Director{} section of the FD is not correct
- The FD has not been restarted (I have seen systemctl restart
bacula-fd not always work)
@Wanderlei, I would recommend to do a tcpdump on the Director when
things are quiet (ie: no jobs running) to see if this
inbound connection from the client is actually making it to the
Director through your firewall:
First stop the FD.
Then start a tcp
dump session as root on the Director:
----8<----
# tcpdump -i any tcp port 9101 or 9102 -vvv -w bacula.dump
----8<----
Then, start the FD. The "Got #" message should increment. If it does
not, we have our answer. If it does, do a 'status
client=xxxx' in bconsole for this client. The "Got #" should increment
some...
Kill the tcpdump and open the dump file in Wireshark to see what was
happening.
You can even start the FD in foreground and debug mode to see what it
is doing and look for its outbound connection
attempt(s) to the Director to confirm it is trying to do the right thing:
----8<----
# killall bacula-fd
# /path/to/bacula-fd -f -d100 -c /path/to/bacula-fd.conf
----8<----
Let us know what you find!
Best regards,
Bill
--
Bill Arlofski
w...@protonmail.com
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
