Ok on my mac test client I added Heartbeat to myself.conf and the director has 
it also,  it eventaully dropped off compeltely (doesn’t even show up in status 
dir)  and just prints:

macfu-fd (120): filed/dir_cmd.cc:619-0 Waiting for data from Director 
"myth-dir" (timeout: 60s)

Over and over, 


Brock Palen
[email protected]
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting



> On Feb 17, 2026, at 8:39 AM, 'Brock Palen' via bareos-users 
> <[email protected]> wrote:
> 
> Ok I thought that was the case, but even after cracking the ESTABLISHED 
> timeout on my router very high from 40 minutes to 5 days the remote clients 
> (that don’t have Heartbeat Interval set)  still fail.
> 
> What’s intersting is that the router still shows the established connection 
> on it’s tracking table.
> 
> This is from a macos client running -d 1000 -f 
> 
> It just prints over and over:
> 
> macfu-fd (200): filed/heartbeat.cc:125-0 wait_intr=0 stop=0
> macfu-fd (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned 
> want-write
> macfu-fd (200): filed/heartbeat.cc:125-0 wait_intr=0 stop=0
> macfu-fd (200): filed/heartbeat.cc:125-0 wait_intr=0 stop=0
> macfu-fd (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned 
> want-write
> macfu-fd (120): filed/dir_cmd.cc:619-0 Waiting for data from Director 
> "myth-dir" (timeout: 60s)
> macfu-fd (200): filed/heartbeat.cc:125-0 wait_intr=0 stop=0
> macfu-fd (200): filed/heartbeat.cc:125-0 wait_intr=0 stop=0
> macfu-fd (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned 
> want-write
> 
> (The Director does have heartbeat set)
> 
> I’ll add Heartbeat Interval to the client and see how it behaves.  It still 
> just bugs me this worked for years with this same asus merlin router/firewall.
> 
> 
> Brock Palen
> [email protected]
> www.mlds-networks.com
> Websites, Linux, Hosting, Joomla, Consulting
> 
> 
> 
>> On Feb 11, 2026, at 5:05 PM, Brock Palen <[email protected]> wrote:
>> 
>> 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/C4625309-C26F-4A86-AD73-26D5801257BF%40mlds-networks.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/F573D8F5-0BEB-41CE-A998-C0264C65CB28%40mlds-networks.com.

Reply via email to