Mailing List Archive

Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD
I'm trying to build this package on FreeBSD 9.1 amd64 so I can use ipv6 address
rules.

It builds OK, but it can't resolve host names. Poking around in the code,
dns_ip6() calls dns_resolve(q,DNS_T_AAAA), and the result packet doesn't have
any answer records.

ucspi-tcp 0.88 with the usual v6 patches, built from the port, works fine. I'm
running unbound, the cache handles AAAA records just fine.

Is this a known problem? TIA.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
Re: Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD [ In reply to ]
Hi John,

--On 2. November 2013 01:39:09 -0400 "John R. Levine" <johnl@iecc.com>
wrote:

> I'm trying to build this package on FreeBSD 9.1 amd64 so I can use ipv6
> address rules.
>
> It builds OK, but it can't resolve host names. Poking around in the
> code, dns_ip6() calls dns_resolve(q,DNS_T_AAAA), and the result packet
> doesn't have any answer records.
>
> ucspi-tcp 0.88 with the usual v6 patches, built from the port, works
> fine. I'm running unbound, the cache handles AAAA records just fine.
>
> Is this a known problem? TIA.

The 'problem' is mentioned on UCSPI-TCP6 web-site and in the man-page.

Incoming IPv6 connections and DNS lookups happen asynchronously.

Check your IP addresses in /etc/resolv.conf.
You can use $DNSCACHEIP to proved IPv6 enabled resolvers.

Pls. point me to 'usual IPv6 patches' which don't have the 'problem'.
There is still some headroom for improvements.

regards.
--eh.

>
> Regards,
> John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. http://jl.ly



Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ | PGP-Key-Id: 7E4034BE
Re: Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD [ In reply to ]
>The 'problem' is mentioned on UCSPI-TCP6 web-site and in the man-page.
>
>Incoming IPv6 connections and DNS lookups happen asynchronously.
>
>Check your IP addresses in /etc/resolv.conf.
>You can use $DNSCACHEIP to proved IPv6 enabled resolvers.

I have it set to fe80::2, which is an another FreeBSD box running
unbound. It works fine when I poke at it with dig.

>Pls. point me to 'usual IPv6 patches' which don't have the 'problem'.
>There is still some headroom for improvements.

I'm currently using the FreeBSD port, which uses the patches here:

PATCH_SITES+= http://www.fefe.de/ucspi/:ipv6
PATCHFILES+= ucspi-tcp-0.88-ipv6.diff19.bz2:ipv6

They resolve v6 addresss without trouble even with dnscache.

R's,
John
Re: Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD [ In reply to ]
Hi John,

I'm investigating the problem you have mentioned.

Actually, I'm (still) lacking IPv6 support for djbdns ... It is on my
agenda, but I need some more time.

There are some issues, I can confirm and one other where I need your help:

1. FreeBSD behaves a little strange with the loopback address. tcpserver
can not bind to '::1' but '::' is allowed. Not good. I'm running FreeBSD
9.1 on my main server. Rebooting an old 6.3 machine, the loopback IF has
the IPv6 'fe80::1'. Oh gosh.

2. tcpserver/tcpclient on FreeBSD do not lookup a IPv6 address in
/etc/hosts. In particular not 'localhost' which makes package/rts fail.

3. Invoking tcpserver with '-h', I see the PTR lookups in my dnscache log
for incoming connections; thus in general /etc/resolv.conf is consulted.

Q:

4. Your observation was triggered by tcpclient -6 -I ifidx 'hostname' port
; and hostname was not found ?


Best regards.
--eh.

PS. Your mail server is not accepting me, thus I need to communicate thru
the qmail list.

--On 2. November 2013 22:33:44 +0000 John Levine <johnl@iecc.com> wrote:

>> The 'problem' is mentioned on UCSPI-TCP6 web-site and in the man-page.
>>
>> Incoming IPv6 connections and DNS lookups happen asynchronously.
>>
>> Check your IP addresses in /etc/resolv.conf.
>> You can use $DNSCACHEIP to proved IPv6 enabled resolvers.
>
> I have it set to fe80::2, which is an another FreeBSD box running
> unbound. It works fine when I poke at it with dig.
>
>> Pls. point me to 'usual IPv6 patches' which don't have the 'problem'.
>> There is still some headroom for improvements.
>
> I'm currently using the FreeBSD port, which uses the patches here:
>
> PATCH_SITES+= http://www.fefe.de/ucspi/:ipv6
> PATCHFILES+= ucspi-tcp-0.88-ipv6.diff19.bz2:ipv6
>
> They resolve v6 addresss without trouble even with dnscache.
>
> R's,
> John
>



--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ | PGP-Key-Id: 7E4034BE
Re: Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD [ In reply to ]
>1. FreeBSD behaves a little strange with the loopback address. tcpserver
>can not bind to '::1' but '::' is allowed. Not good. I'm running FreeBSD
>9.1 on my main server. Rebooting an old 6.3 machine, the loopback IF has
>the IPv6 'fe80::1'. Oh gosh.

On 9.1 the loopback device has both the loopback address ::1 and the link
local fe80::1. Nothing unusual about that.

>4. Your observation was triggered by tcpclient -6 -I ifidx 'hostname' port
>; and hostname was not found ?

That's right.

R's,
John
Re: Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD [ In reply to ]
Hi,



--On 10. November 2013 18:31:18 +0000 John Levine <johnl@iecc.com> wrote:

>> 1. FreeBSD behaves a little strange with the loopback address. tcpserver
>> can not bind to '::1' but '::' is allowed. Not good. I'm running FreeBSD
>> 9.1 on my main server. Rebooting an old 6.3 machine, the loopback IF has
>> the IPv6 'fe80::1'. Oh gosh.
>
> On 9.1 the loopback device has both the loopback address ::1 and the link
> local fe80::1. Nothing unusual about that.

Yup. If you consider lo0 as 'real' interface ... and if it would work that
way:

$ ./tcpserver -v -I lo0 fe80::1 50000 cat
tcpserver: fatal: unable to bind: device not configured

$ ./tcpserver -v :: 40000 cat
tcpserver: status: 0/40


$ ./tcpserver -v ::1 40000 cat
tcpserver: fatal: unable to bind: address not available



>
>> 4. Your observation was triggered by tcpclient -6 -I ifidx 'hostname'
>> port ; and hostname was not found ?
>
> That's right.

A: Found the bug. The fdqn was not correctly terminated (ip6_dns.c).
Some arbitrary character was added (see Query in tcpdump):

19:39:19.103018 IP bigchief.fehnet.de.29806 > router1.fehnet.de.domain:
57336+ AAAA? artigo.fehnet.de^@. (35)

---

Let me do some more investigations and I will issue a fix asap.

Thank you for the bug report.

regards.
--eh.



>
> R's,
> John



--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ | PGP-Key-Id: 7E4034BE
Re: Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD [ In reply to ]
>> On 9.1 the loopback device has both the loopback address ::1 and the link
>> local fe80::1. Nothing unusual about that.
>
> Yup. If you consider lo0 as 'real' interface ... and if it would work that
> way:

ping6 can find it. Perhaps you need to dig deeper. There's something
strange about addresses and interfaces that I don't entirely understand.

$ ping6 fe80::1%lo0
PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::1%lo0
16 bytes from fe80::1%lo0, icmp_seq=0 hlim=64 time=0.066 ms
16 bytes from fe80::1%lo0, icmp_seq=1 hlim=64 time=0.050 ms
16 bytes from fe80::1%lo0, icmp_seq=2 hlim=64 time=0.055 ms
16 bytes from fe80::1%lo0, icmp_seq=3 hlim=64 time=0.049 ms
^C
--- fe80::1%lo0 ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.049/0.055/0.066/0.007 ms


> $ ./tcpserver -v -I lo0 fe80::1 50000 cat
> tcpserver: fatal: unable to bind: device not configured
>
> $ ./tcpserver -v :: 40000 cat
> tcpserver: status: 0/40
>
>
> $ ./tcpserver -v ::1 40000 cat
> tcpserver: fatal: unable to bind: address not available

R's,
John
Re: Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD [ In reply to ]
Hi (once again),

--On 10. November 2013 15:51:09 -0500 "John R. Levine" <johnl@iecc.com>
wrote:

>>> On 9.1 the loopback device has both the loopback address ::1 and the
>>> link local fe80::1. Nothing unusual about that.
>>
>> Yup. If you consider lo0 as 'real' interface ... and if it would work
>> that way:
>
> ping6 can find it. Perhaps you need to dig deeper. There's something
> strange about addresses and interfaces that I don't entirely understand.
>
> $ ping6 fe80::1%lo0
> PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::1%lo0
> 16 bytes from fe80::1%lo0, icmp_seq=0 hlim=64 time=0.066 ms
> 16 bytes from fe80::1%lo0, icmp_seq=1 hlim=64 time=0.050 ms
> 16 bytes from fe80::1%lo0, icmp_seq=2 hlim=64 time=0.055 ms
> 16 bytes from fe80::1%lo0, icmp_seq=3 hlim=64 time=0.049 ms
> ^C
> --- fe80::1%lo0 ping6 statistics ---
> 4 packets transmitted, 4 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 0.049/0.055/0.066/0.007 ms

Clearly, ping6 is a customized command. On Linux it works differently.

Anyway:

$ tcpserver -6 -v fe80::1%lo0 50000 cat
tcpserver: fatal: no IP address for fe80::1%lo0

% tcpserver -6 -v ::1%lo0 50000 cat
tcpserver: fatal: no IP address for ::1%lo0

These different understandings of IF indexes and syntax is a pain.

As I said: There is still some headroom for improvement and adjustments
here.
Solution: Parse input IPv6 address and split it into two pieces (ip +
ifidx).

However, this would not solve the problems, as I did report previously.
Maybe I need to check the ping6 code ....

Have a nice Sunday.

regards.
--eh.

>
>
>> $ ./tcpserver -v -I lo0 fe80::1 50000 cat
>> tcpserver: fatal: unable to bind: device not configured
>>
>> $ ./tcpserver -v :: 40000 cat
>> tcpserver: status: 0/40
>>
>>
>> $ ./tcpserver -v ::1 40000 cat
>> tcpserver: fatal: unable to bind: address not available
>
> R's,
> John



--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ | PGP-Key-Id: 7E4034BE
Re: Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD [ In reply to ]
>> --- fe80::1%lo0 ping6 statistics ---
>> 4 packets transmitted, 4 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 0.049/0.055/0.066/0.007 ms
>
>Clearly, ping6 is a customized command. On Linux it works differently.

The source code for ping6 says it's from the WIDE project, dating from
1996 or earlier. I expect it's more likely that whatever linux
program you're using does something funky that solved someone's short
term problem.

R's,
John
Re: Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD [ In reply to ]
Hi John,

thanks again for you input and bug report. Meanwhile, I was able to sort
out the problems:

a) The wrong DNS call was triggered by a malformated hostname in ip6_dns.c.

b) The problem with the binding to '::1' and 'fe80::1' has its cause in a
in the wrong propagation of the 'netif' variable to socket_bind6_reuse.

After fixing these issues, all is working smoothly.

Strange enough: These problems are not apparent in ucspi-ssl, which
includes IPv6 support as well.
In need to consolidate both versions.

You will find a correct version my web-site at the usual place
(ucspi-tcp6-0.99.1).

Thank you again.

Best regards.
--eh.

PS: I checked ping6.c from the KAME source code. On the first look, it just
support referencing the interface by means of '-I ...' and not via
concatenating it with the IP address; thus this seems to be BSD semantic.




>
> R's,
> John



--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ | PGP-Key-Id: 7E4034BE
Re: Trouble with fehcom ucspi-tcp6 0.99a on FreeBSD [ In reply to ]
I found that for IPv6 connections, tcpserver wasn't setting some of the
TCP6xxxx environment variables. With a few patches to add them it now
seems to work well with mailfront on an IPv6 connection.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

*** ucspi-tcp6-0.99.1/src/tcpserver.c 2013-11-11 12:55:29.000000000 -0500
--- ucspi-tcp6-0.99.1a/src/tcpserver.c 2014-01-05 17:22:40.000000000 -0500
***************
*** 1,4 ****
--- 1,5 ----
#include <sys/types.h>
+ #include <unistd.h>
#include <sys/param.h>
#include <netdb.h>
#include "uint16.h"
***************
*** 167,173 ****
socket_tcpnodelay(t);

if (*banner) {
! buffer_init(&b,write,t,bspace,sizeof bspace);
if (buffer_putsflush(&b,banner) == -1)
strerr_die2sys(111,DROP,"unable to print banner: ");
}
--- 168,174 ----
socket_tcpnodelay(t);

if (*banner) {
! buffer_init(&b,(int (*)())write,t,bspace,sizeof bspace);
if (buffer_putsflush(&b,banner) == -1)
strerr_die2sys(111,DROP,"unable to print banner: ");
}
***************
*** 196,204 ****

env("TCPLOCALPORT",localportstr);
env("TCPLOCALHOST",localhost);
! if (!mappedv4 && scope_id)
! env("TCP6INTERFACE",socket_getifname(scope_id));
!
if (flagremotehost)
if (dns_name6(&remotehostsa,remoteip) == 0)
if (remotehostsa.len) {
--- 197,209 ----

env("TCPLOCALPORT",localportstr);
env("TCPLOCALHOST",localhost);
! if(!mappedv4) {
! env("TCP6LOCALIP",localipstr);
! env("TCP6LOCALHOST",localhost);
! env("TCP6LOCALPORT",localportstr);
! if (scope_id)
! env("TCP6INTERFACE",socket_getifname(scope_id));
! }
if (flagremotehost)
if (dns_name6(&remotehostsa,remoteip) == 0)
if (remotehostsa.len) {
***************
*** 327,336 ****
}
}

main(int argc,char **argv)
{
char *hostname;
! char *portname;
int opt;
struct servent *se;
char *x;
--- 332,342 ----
}
}

+ int
main(int argc,char **argv)
{
char *hostname;
! /* char *portname; */
int opt;
struct servent *se;
char *x;
***************
*** 432,438 ****
localipstr[ip6_compactaddr(localipstr,localip)]= 0;
localportstr[fmt_ulong(localportstr,localport)] = 0;
if (flag1) {
! buffer_init(&b,write,1,bspace,sizeof bspace);
buffer_puts(&b,localipstr);
buffer_puts(&b," : ");
buffer_puts(&b,localportstr);
--- 438,444 ----
localipstr[ip6_compactaddr(localipstr,localip)]= 0;
localportstr[fmt_ulong(localportstr,localport)] = 0;
if (flag1) {
! buffer_init(&b,(int (*)())write,1,bspace,sizeof bspace);
buffer_puts(&b,localipstr);
buffer_puts(&b," : ");
buffer_puts(&b,localportstr);