What's new

Asuswrt-Merlin 384.10_2 + Entware BIND 9.12.3-P4 - TCP_FASTOPEN fail

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

protogen

Occasional Visitor
EDIT: I have removed all references to 32bit and 64bit in this post - I made as assumption regarding the new Entware repo and my router model. Everything is 32bit - old repo, new repo, all binaries. The problem reported below still exists.

Over the last two days I completely rebuilt my RT-AC88U on 384.10_2. I did a factory reset and reformatted both JFFS and USB before reinstalling Entware.

Upon starting BIND 9.12.3-P4 I saw the following error in my logs.
Code:
named[2126]: [daemon.info]  listening on IPv6 interfaces, port 53
named[2126]: [daemon.err]  socket.c:5683: unexpected error:
named[2126]: [daemon.err]  setsockopt(21, TCP_FASTOPEN) failed with Protocol not available
named[2126]: [daemon.info]  listening on IPv4 interface lo, 127.0.0.1#53
named[2126]: [daemon.err]  socket.c:5683: unexpected error:
named[2126]: [daemon.err]  setsockopt(22, TCP_FASTOPEN) failed with Protocol not available
named[2126]: [daemon.info]  listening on IPv4 interface eth0, <my external IP>#53
named[2126]: [daemon.err]  socket.c:5683: unexpected error:
named[2126]: [daemon.err]  setsockopt(23, TCP_FASTOPEN) failed with Protocol not available
named[2126]: [daemon.info]  listening on IPv4 interface br0, 192.168.9.1#53
named[2126]: [daemon.err]  socket.c:5683: unexpected error:
named[2126]: [daemon.err]  setsockopt(24, TCP_FASTOPEN) failed with Protocol not available
...
named[2126]: [daemon.err]  socket.c:5683: unexpected error:
named[2126]: [daemon.err]  setsockopt(25, TCP_FASTOPEN) failed with Protocol not available
named[2126]: [daemon.notice]  command channel listening on 127.0.0.1#953

The BIND server process (named) was running, but the output of netstat -anp showed it was not listening on any interface. DNS resolution was not working at all.

To get around this problem, I ended up staying on 384.10_2 and created a modified entware-setup.sh which used the old repository (http://pkg.entware.net/binaries/armv7). I then re-installed Entware from scratch, including BIND 9.11.2-3. This version of BIND started without error and is running perfectly.

This result is confusing because BIND has used TCP_FASTOPEN since version 9.11.0 - so why does 9.11.2-3 work but 9.12.3-P4 fail?

From my research, it appears that for TCP_FASTOPEN to work it requires kernel support. I'm unclear whether this means there is a problem with how kernel 384.10_2 has been compiled, or there's a problem with how BIND 9.12.3-P4 has been compiled.

Can anyone shed any light on this?
 
Last edited:
Over the last two days I completely rebuilt my RT-AC88U on 384.10_2. I did a factory reset and reformatted both JFFS and USB before reinstalling Entware (64bit).

Upon starting BIND 9.12.3-P4 I saw the following error in my logs.
Code:
named[2126]: [daemon.info]  listening on IPv6 interfaces, port 53
named[2126]: [daemon.err]  socket.c:5683: unexpected error:
named[2126]: [daemon.err]  setsockopt(21, TCP_FASTOPEN) failed with Protocol not available
named[2126]: [daemon.info]  listening on IPv4 interface lo, 127.0.0.1#53
named[2126]: [daemon.err]  socket.c:5683: unexpected error:
named[2126]: [daemon.err]  setsockopt(22, TCP_FASTOPEN) failed with Protocol not available
named[2126]: [daemon.info]  listening on IPv4 interface eth0, <my external IP>#53
named[2126]: [daemon.err]  socket.c:5683: unexpected error:
named[2126]: [daemon.err]  setsockopt(23, TCP_FASTOPEN) failed with Protocol not available
named[2126]: [daemon.info]  listening on IPv4 interface br0, 192.168.9.1#53
named[2126]: [daemon.err]  socket.c:5683: unexpected error:
named[2126]: [daemon.err]  setsockopt(24, TCP_FASTOPEN) failed with Protocol not available
...
named[2126]: [daemon.err]  socket.c:5683: unexpected error:
named[2126]: [daemon.err]  setsockopt(25, TCP_FASTOPEN) failed with Protocol not available
named[2126]: [daemon.notice]  command channel listening on 127.0.0.1#953

The BIND server process (named) was running, but the output of netstat -anp showed it was not listening on any interface. DNS resolution was not working at all.

To get around this problem, I ended up staying on 384.10_2 and created a modified entware-setup.sh which used the old 32bit repository (http://pkg.entware.net/binaries/armv7). I then re-installed Entware from scratch, including BIND 9.11.2-3 (32bit). This version of BIND started without error and is running perfectly.

This result is confusing because BIND has used TCP_FASTOPEN since version 9.11.0 - so why does 9.11.2-3 (32bit) work but 9.12.3-P4 (64bit) fail? Is it something to do with 32bit vs 64bit?

From my research, it appears that for TCP_FASTOPEN to work it requires kernel support. I'm unclear whether this means there is a problem with how kernel 384.10_2 has been compiled, or there's a problem with how BIND 9.12.3-P4 (64bit) has been compiled.

Or is it a problem with one of the Entware 64bit libraries?

Can anyone shed any light on this?
The AC88U is not a 64bit router.
 
The only 64bit routers are the AC86U and the new AX88U.
 
The AC88U is not a 64bit router.
Sorry, I've made a mistake. The new Entware repository is actually 32bit for the RT-AC88U. I misread the CHANGELOG.
Code:
CHANGELOG
  - NEW: Support the new Entware 64-bit repo on the RT-AC86U.

Thanks for pointing this out. I incorrectly believed it was 64bit. I've edited my original post.

My problem still stands though.

This version of bind fails to open sockets.
Code:
[591] admin@router:/mnt/entware/entware-old_2019-04-20_08-29/sbin # strings named | grep 'version: BIND'
named version: BIND 9.12.3-P4 <a3d2ae0> (Mar 22 2019)
[592] admin@router:/mnt/entware/entware-old_2019-04-20_08-29/sbin # file named
named: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /opt/lib/ld-linux.so.3, for GNU/Linux 2.6.32, stripped
This version of bind successfully open sockets.
Code:
[625] admin@router:/mnt/entware/entware/sbin # strings named | grep 'version: BIND'
named version: BIND 9.11.2 <0a2b929> (Jan 10 2018)
[626] admin@router:/mnt/entware/entware/sbin # file named
named: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /opt/lib/ld-linux.so.3, for GNU/Linux 2.6.32, stripped
 
Last edited:
Sorry, I've made a mistake. The new Entware repository is actually 32bit for the RT-AC88U. I misread the CHANGELOG.
Code:
   - NEW: Support the new Entware 64-bit repo on the RT-AC86U.

Thanks for pointing this out. I had incorrectly assumed it was 64bit.

Code:
[591] admin@router:/mnt/entware/entware-old_2019-04-20_08-29/sbin # strings named | grep 'version: BIND'
named version: BIND 9.12.3-P4 <a3d2ae0> (Mar 22 2019)
[592] admin@router:/mnt/entware/entware-old_2019-04-20_08-29/sbin # file named
named: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /opt/lib/ld-linux.so.3, for GNU/Linux 2.6.32, stripped

My problem still stands though.
I'm not sure how complex your Entware install is but I would wipe and reinstall.
 
I'm not sure how complex your Entware install is but I would wipe and reinstall.
I have done so. I installed and reinstalled Entware four times (from scratch) using the current repository to give me BIND 9.12.3-P4. Each time the result was the same. BIND failed to open any sockets.

After I switched Entware to use the old repository, I re-installed Entware from scratch to give me BIND 9.11.2-3. BIND started first time without error. I'm still using that version now.
 
I have to apologize, I don't know the first thing about Bind other than it functions similar to dnsmasq. Sorry.
 
I have to apologize, I don't know the first thing about Bind other than it functions similar to dnsmasq. Sorry.
No apology necessary. I appreciate anyone providing input.

This issue is not specific to BIND. Any Entware binary that uses TCP_FASTOPEN (in the same way as BIND 9.12.3-P4) is likely to have this problem.

The cause is probably due to how either kernel 384.10_2 was compiled, or how BIND 9.12.3-P4 was compiled. I'm just not sure which. This probably needs comment from @RMerlin himself.
 
Last edited:
I would recommend that you backup your current configuration from your USB drive, including any files you may need from the jffs partition and then do the following.
  • With your files safely backed up to your computer. Format the USB drive to NTFS.
  • Enable the 'Format the jffs partition on next boot' option, make sure you hit Apply at the bottom of the page.
  • Then, reboot the router 3 times in the next 15 minutes or so. Waiting for at least 5 to 10 minutes between reboots.
  • Install amtm to the jffs partition. https://diversion.ch/amtm.html
  • Insert the USB drive into the router.
  • Using amtm, use 'fd' to format the USB drive to Ext4 with journaling enabled. Make sure to label the drive too.
  • After the router has rebooted, create a swap file using amtm 'sw', I would recommend the maximum, 2GB option.
  • Using amtm 'dc' to enable the USB disk checker script.
  • Using amtm, install Diversion and allow it to also install Entware and pixelserv-tls too. If you don't want to use diversion, simply disable it afterward.
  • Make sure you didn't use the Entware installer on the main amtm page. This will probably break your install if you want to use any other amtm (or other) scripts. This is why using Diversion to install Entware is recommended.
  • After the above is installed and working, reboot the router and check the amtm disk checker log to see if there are any errors found on the disk.
At this point, install the script(s) you want as you normally would.

What the above ensures is that the USB drive is formatted as expected by the supported scripts. Important! :)

What this also ensures is that Entware is properly installed too.

Your scripts should now run without issues. :)
 
From my research, it appears that for TCP_FASTOPEN to work it requires kernel support. I'm unclear whether this means there is a problem with how kernel 384.10_2 has been compiled, or there's a problem with how BIND 9.12.3-P4 has been compiled.

TCP Fast Open requires Linux 3.7. Your router runs 2.6.36, so Fast Open was never supported on that model.
 
TCP Fast Open requires Linux 3.7. Your router runs 2.6.36, so Fast Open was never supported on that model.
Okay, good to know. Thank you for clarifying.

So, given BIND has used TCP_FASTOPEN since version 9.11.0 - can you shed any light on why BIND 9.11.2-3 works fine but BIND 9.12.3-P4 fails when running on the same kernel?

It's got to be something to do with the way each version has been compiled - correct?
 
So, given BIND has used TCP_FASTOPEN since version 9.11.0 - can you shed any light on why BIND 9.11.2-3 works fine

It probably wasn't compiled with Fast Open support, or it properly ignored it when failing to initialize it. TFO was definitely NOT working under that older Bind version either.
 
It probably wasn't compiled with Fast Open support, or it properly ignored it when failing to initialize it. TFO was definitely NOT working under that older Bind version either.
Thank you Merlin. As always, your answers light the way.

I'll speak with the Entware team and see if they're able to explain and/or fix the issue.
 
Thank you Merlin. As always, your answers light the way.

I'll speak with the Entware team and see if they're able to explain and/or fix the issue.

I believe Entware now targets a 3.x kernel (I forgot the exact version), that might be why.

Did you check if there's a runtime option to disable it in Bind?
 
I've received a response from @zyxmon, one of the main Entware contributors/maintainers.
Given my router kernel does not support TCP Fast Open why is BIND 9.12.3-P4 trying to use it?
Because it is defined at compile time, not at run time.

I guess it (your Entware feed) is armv7sf-k2.6. I'll probably make a fix for 2.6.36 and BIND today.

Once BIND is updated, I'll reinstall Entware from the current repository, test and report back with the results.
 
@zyxmon responded overnight that he'd recompiled BIND with TCP_FASTOPEN disabled.

I re-installed Entware from scratch this morning (using the current repository).
BIND 9.12.3-P4-1a started without error and is running perfectly.
Code:
named[1187]: [daemon.notice]  starting BIND 9.12.3-P4 <id:a3d2ae0>
...
named[1187]: [daemon.info]  listening on IPv4 interface lo, 127.0.0.1#53
named[1187]: [daemon.info]  listening on IPv4 interface eth0, <my external IP>#53
named[1187]: [daemon.info]  listening on IPv4 interface br0, 192.168.9.1#53
...
named[1187]: [daemon.notice]  command channel listening on 127.0.0.1#953
Code:
[504] admin@router:~ # netstat -anp | grep ':53 '
tcp        0      0 192.168.9.1:53          0.0.0.0:*               LISTEN      1187/named
tcp        0      0 <my external IP>:53     0.0.0.0:*               LISTEN      1187/named
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1187/named
udp        0      0 192.168.9.1:53          0.0.0.0:*                           1187/named
udp        0      0 <my external IP>:53     0.0.0.0:*                           1187/named
udp        0      0 127.0.0.1:53            0.0.0.0:*                           1187/named
Thank you to everyone who provided input and assistance, especially @RMerlin.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top