1.9.1 - outnettcp got tcp error -1

Unbound
1

On OpenWRT with:

Version 1.9.1
linked libs: pluggable-event internal (it uses select), OpenSSL 1.0.2r 26 Feb 2019
linked modules: dns64 subnetcache respip validator iterator

the log is full of:

outnettcp got tcp error -1

and I am at loss what to make of that and thus to rectify? Help to get this sorted would be appreciated.

2

It seems that there is no TCP traffic for unbound with DS-Lite over native DHCPv6 Prefix-Delegation on the WAN. With native ipv4 and no ipv6 on the WAN the error is not present.

Is there a way to debug this? Should this be reported as issue on Github?

3

Just guessing where to trouble shoot here. There might be something more to how dslite is configured, subsequent RA and DHCP fields are formulated, or routes are inserted on WAN with DHCP scripts. In packaging Unbound for OpenWrt I have not had problems testing with native IPv6 ISP or he.net tunnel.
- Eric

4

Hi,

It seems that there is no TCP traffic for unbound with DS-Lite over
native DHCPv6 Prefix-Delegation on the WAN. With native ipv4 and no
ipv6 on the WAN the error is not present.

Is there a way to debug this? Should this be reported as issue on Github?

Here works too.

On OpenWRT with:

Version 1.9.1
linked libs: pluggable-event internal (it uses select), OpenSSL
1.0.2r 26 Feb 2019
linked modules: dns64 subnetcache respip validator iterator

the log is full of:

outnettcp got tcp error -1

and I am at loss what to make of that and thus to rectify? Help to
get this sorted would be appreciated.

Just guessing where to trouble shoot here. There might be something more
to how dslite is configured, subsequent RA and DHCP fields are
formulated, or routes are inserted on WAN with DHCP scripts. In
packaging Unbound for OpenWrt I have not had problems testing with
native IPv6 ISP or he.net tunnel.

Set verbosity to 4, if not already. Unbound prints errors that cause
the error message you print, a little above. Like "read (in tcp r): <..
some system error message>" and an IP address. And stuff like that. If
it is timeouts, "tcp took too long". If it does not print anything,
there should be extra debug printout for that return error path, perhaps
then print it with strace.

Best regards, Wouter