Firewalll is simple it’s a asus consumer router. Been the same one for a while
though I do keep the firmware up to date. But I think it is the router and the
obvious issue all along. It’s just weird it’s happening now.
The client config on the director does have Heartbeat set:
Client {
Name = sue-hp-touch-fd
FDport = 9102
Address = 192.168.10.6
Catalog = myth_catalog
Password = “<snip>"
Connection From Client To Director = yes
Heartbeat Interval = 60
}
But it was not set on the clients in the myself.conf
These were all windows clients that worked for many years without issues and
still run their normal jobs without issue,
Some are scheudled some use
Run On Incoming Connect Interval
All are still running their jobs. It’s funny though because if a client is
idle and I know it’s online and status dir shows it connected, and I do ether:
run <job that runs fine on schedule>
estimate job=<job>
They also hang.
I noticed I was getting stuff stuck in mesage uses when looking at netstat
tcp 0 32 192.168.84.7:9101 <snip>:52371 ESTABLISHED
I looked in the NAT and mapped connections to port 9101 on the baroes server to
ones that would work randomly, they had NAT entries the others did not. So it
smells like what Hearbeat was setup for.
I did get access to 2 of the remote clients, and added
Heartbeat Interval = 60
To their myself.conf
and am going to see if those clients stay reliable.
If they do and the others don’t (they are not easy to get to update) I’ll try
adjusting the TCP Establsihed timeout on the router which is set to 40 minutes
to something much higher.
IDK if in a firmware update they adjusted that value or there was a bug so it
wasn’t enforced. But I verified I was running this way for the last 3 years
without major changes other than enable ipv6 (issue arose after enabling on
the local network) and regular updates to the server.
I’ll keep an eye on it and report back so other may find this thread later.
Brock Palen
[email protected]
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting
> On Feb 10, 2026, at 10:53 AM, Andreas Rogge <[email protected]> wrote:
>
> Hi Brock,
>
> just a wild guess, but maybe your firewall times out the (idle) tcp session
> and both sides (i.e. director and fd) think they are still connected.
> Do you have heartbeat enabled or your system's keepalive timeouts
> reconfigured?
>
> Am 07.02.26 um 21:19 schrieb 'Brock Palen' via bareos-users:
>> I can’t reliably create the issue on local clients (LAN)
>> But it’s almost 100% reliable on remote clients, I’ll schedule a time with
>> one of remote people and setup a remote desktop session.
>> Brock Palen
>> [email protected]
>> www.mlds-networks.com
>> Websites, Linux, Hosting, Joomla, Consulting
>>> On Feb 6, 2026, at 2:45 AM, Sebastian Sura <[email protected]>
>>> wrote:
>>>
>>> Do the clients show up when you do `status dir` ?
>>>
>>> *status dir
>>> ...
>>> Client Initiated Connections (waiting for jobs):
>>> Connect time Protocol Authenticated Name
>>> ====================================================================================================
>>> 06-Feb-26 08:40 54 1 client-initiated-fd
>>> ====
>>>
>>> If they do, you could try finding out what bareos thinks by starting the
>>> client with debugging enabled, i.e.
>>>
>>> bareos-fd -f -d1000
>>>
>>> and see what it spits out when you try connecting via the director. If the
>>> connection does _not_ show up,
>>> you can still do the same and check what the filed says when _it_ tries to
>>> connect.
>>> Similarly you can do
>>> *setdebug dir trace=1 level=1000
>>> To see what the director reports during the connection attempt. Let me know
>>> if something interesting showed up.
>>>
>>> Kind Regards
>>> Sebastian Sura
>>>
>>> Am 05.02.26 um 20:57 schrieb 'Brock Palen' via bareos-users:
>>>> I have tried both clients with jobs already running and ones that don’t
>>>> and the hang is reliable.
>>>>
>>>> Up until recently I could check the status of any client initiated
>>>> connection without issue. If this isn’t a problem for others this is a
>>>> head scratcher about my site (other than enabling IPv6 on the WAN address
>>>> of the NAT) what hange might have impacted baroes.
>>>>
>>>>
>>>> Brock Palen
>>>> [email protected]
>>>> www.mlds-networks.com
>>>> Websites, Linux, Hosting, Joomla, Consulting
>>>>
>>>>
>>>>
>>>>> On Feb 4, 2026, at 10:51 AM, Bruno Friedmann (bruno-at-bareos)
>>>>> <[email protected]> wrote:
>>>>>
>>>>> Hi Brock,
>>>>>
>>>>> We use that feature all the time here to backup remote worker, and it
>>>>> works. But beware only when there's no jobs running, (otherwise it would
>>>>> need another connection which doesn't exists).
>>>>> Would that make sense in your case ?
>>>>>
>>>>> On Thursday, 29 January 2026 at 21:48:39 UTC+1 Brock Palen wrote:
>>>>> So opening this back up, I don’t think it’s IPv6 related at all.
>>>>>
>>>>> I have disabled ipv6 for the director and storage. I have confirmed they
>>>>> are not listening using netstat I also removed the AAAA DNS record for
>>>>> the server.
>>>>>
>>>>> Clients using configs like:
>>>>> Client {
>>>>> Name = sue-hp-touch-fd
>>>>> FDport = 9102
>>>>> Address = 192.168.10.6
>>>>> #Address = 192.168.67.21
>>>>> Catalog = myth_catalog
>>>>> Password = “<snip>"
>>>>> Connection From Client To Director = yes
>>>>> Heartbeat Interval = 60
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> setdebug level=1000 trace=1 dir
>>>>>
>>>>> I’m getting errors like:
>>>>> myth-dir (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned
>>>>> want-read
>>>>> myth-dir (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned
>>>>> want-read
>>>>> myth-dir (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned
>>>>> want-read
>>>>> myth-dir (800): dird/job.cc:732-0 JobMonitorWatchdog 0x565b9f0369e0 called
>>>>>
>>>>> When I do
>>>>>
>>>>> status client=<client>
>>>>>
>>>>> For clients that use client initiated connection. Ironically their jobs
>>>>> still run, but status fails and just hangs, and I have to break out of
>>>>> bconsole using Ctl+C
>>>>>
>>>>> I have been using this for years I have tried giving the client a valid
>>>>> IP on the local network (even though that’s not the hots address) and
>>>>> random addreses. Behavior is the same.
>>>>>
>>>>> Machines that don’t use this or are on the same local LAN work fine. It’s
>>>>> only the road warriors. It’s more annoying but I don’t htink it’s
>>>>> expected behavior.
>>>>>
>>>>> Details:
>>>>> *status client=sue-hp-touch-fd
>>>>> Connecting to Client sue-hp-touch-fd at 192.168.10.6:9102
>>>>> Probing client protocol... (result will be saved until config reload)
>>>>> Handshake: Immediate TLS, Encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>>>>>
>>>>> <hang>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Brock Palen
>>>>> [email protected]
>>>>> www.mlds-networks.com
>>>>> Websites, Linux, Hosting, Joomla, Consulting
>>>>>
>>>>>
>>>>>
>>>>>> On Jan 5, 2026, at 3:24 AM, Bruno Friedmann (bruno-at-bareos)
>>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> Hi, Just for information, I'm using ipv6 since years (>5) here on my
>>>>>> network, and I've started 2 years ago to only use ipv6 for the backup,
>>>>>> so bareos here is using 100% of the time ipv6.
>>>>>> So for most of the task it works well, but I don't use the client
>>>>>> initiated feature.
>>>>>>
>>>>>> I might give it a try next week-end ...
>>>>>>
>>>>>> On Saturday, 3 January 2026 at 23:29:36 UTC+1 Brock Palen wrote:
>>>>>> We were modernizing some and rolling out ipv6
>>>>>> The bareos server always had ipv6 but it was not part of DNS nor allowed
>>>>>> through the firewall.
>>>>>>
>>>>>> After adding it to DNS and opening up the firewall clients that connect
>>>>>> directly over the wan (not over the VPN or local network) all use client
>>>>>> initiated connections.
>>>>>>
>>>>>> They should show up even trigger backups but if you do:
>>>>>>
>>>>>> status client=<client>
>>>>>>
>>>>>> A large fraction would fail and drop the connection and come back later.
>>>>>>
>>>>>> Telling bareos director to only listen on ipv4 things started working
>>>>>> again.
>>>>>>
>>>>>> I’m guessing I have created some sort of resolution/routing loop, and
>>>>>> were actaully ok with ipv4 just more curious as rolling out ipv6 for our
>>>>>> mail and everything else has been a learning experience.
>>>>>>
>>>>>>
>>>>>> Brock Palen
>>>>>> [email protected]
>>>>>> www.mlds-networks.com
>>>>>> Websites, Linux, Hosting, Joomla, Consulting
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "bareos-users" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>>> an email to [email protected].
>>>>>> To view this discussion visit
>>>>>> https://groups.google.com/d/msgid/bareos-users/f45c79ae-c09e-477d-983f-525fad705cb9n%40googlegroups.com.
>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups
>>>>> "bareos-users" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>>> email to [email protected].
>>>>> To view this discussion visit
>>>>> https://groups.google.com/d/msgid/bareos-users/ddb950cf-fab8-4bba-8bd8-7becd4bac142n%40googlegroups.com.
>>>
>>> --
>>> Sebastian Sura [email protected]
>>> Bareos GmbH & Co. KG Phone: +49 221 630693-0
>>> https://www.bareos.com
>>> Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
>>> Komplementär: Bareos Verwaltungs-GmbH
>>> Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "bareos-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to [email protected].
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/bareos-users/63e00a08-53a1-4062-932e-ee0b138596ad%40bareos.com.
>
> --
> Andreas Rogge [email protected]
> Bareos GmbH & Co. KG Phone: +49 221-630693-86
> http://www.bareos.com
>
> Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
> Komplementär: Bareos Verwaltungs-GmbH
> Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz
>
> --
> You received this message because you are subscribed to the Google Groups
> "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion visit
> https://groups.google.com/d/msgid/bareos-users/5b3eabc9-bdb9-4069-9394-3c36e2171816%40bareos.com.
--
You received this message because you are subscribed to the Google Groups
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/bareos-users/3C599D99-32A4-454F-95B5-A25F619C1660%40mlds-networks.com.