Amanda fails because client thinks server is IPv6 when it's IPv4.

[Ken D'Ambrosio]

The below issue was at least worked around by installilng xinetd. I don't know if the root cause is a bug in amanda, or in inetutils-inetd. Note, however, that I tried several different versions of amanda -- including known-good ones from my stock Debian boxes -- all with the same result.

[Repost from mail sent to amanda support list:]

Hi, all. Just recently, I added an Ubuntu Linux box to my series of Debian servers. All the stock Debian servers had backed up fine. However, my Ubuntu box fails miserably. Going through the client's debug log, the thing
that really stands out is this:

amandad: time 0.000: sending ack:
----
Amanda 2.4 ACK HANDLE 001-B8CA0608 SEQ 1137474902
----
amandad: time 0.000: dgram_send_addr: sendto(0.0.0.0.858) failed: Invalid
argument

A "strace" run on the client's amandad shows the following interesting
snippet:

sendto(0, "Amanda 2.4 REP HANDLE 001-F0B70608 SEQ 1137547581\nERROR [addr
0.0.0.0: hostname lookup failed]\n", 95, 0, {sa_family=AF_INET6,
sin6_port=htons(847), inet_pton(AF_INET6, "::58d0:f6bf:c927:f6b7",
&sin6_addr), sin6_flowinfo=0, sin6_scope_id=134513844}, 16) = -1 EINVAL
(Invalid argument)

It looks to me like the client -- which *is* IPv6 enabled, but has no IPv6 interfaces -- is thinking IPv6-ish thoughts. Some Googling showed a thread on this back in '03, and implied that a patch had been merged. Since I'm running amanda 2.4.5, I would have thought that would be yesterday's news.

[Michael Gellman (michael-spam-launchpad)]

I'm also suffering exactly the same error (although I wasn't able to successfully use xinetd to get around it). Could you post the xinetd configuration that you are using? Or is there some debugging I could help with to fix the bug?

[Ken D'Ambrosio (ken-jots)]

On Tue, April 18, 2006 11:16 am, Michael Gellman wrote:
> I'm also suffering exactly the same error (although I wasn't able to
> successfully use xinetd to get around it). Could you post the xinetd
> configuration that you are using? Or is there some debugging I could help
> with to fix the bug?

Alas, I'm just a user, not a debugger; here's my /etc/xinetd.d/amanda file:
(Note that I can't take the credit; I swiped the majority of this from
someone else...)

Good luck!

-Ken

# default: off
# description: Amanda stuff

service amanda
{
    disable = no
    socket_type = dgram
    protocol = udp
    wait = yes
    user = root
    group = root
    groups = yes
    server = /usr/lib/amanda/amandad
}

service amandaidx
{
    disable = no
    socket_type = stream
    protocol = tcp
    wait = no
    user = root
    group = root
    groups = yes
    server = /usr/lib/amanda/amindexd
}

service amidxtape
{
    disable = no
    socket_type = stream
    protocol = tcp
    wait = no
    user = root
    group = root
    groups = yes
    server = /usr/lib/amanda/amidxtaped

[Pavel Pergamenshchik (ppergame)]

In its endless wisdom, ipv6-supporting inetutils-inetd defaults to AF_INET6 sockets unless explicitly specified. I'm sure this breaks all sorts of stuff (atftpd, in my case).

From the looks of it, you can specify "tcp4" as a workaround.

[PaulSchulz (paulschulz)]

After installation of 'tftpd-hpa', the configuration line in '/etc/inetd.conf' looks like:
  tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot

This causes the folloing error in '/var/log/syslog'
  received address was not AF_INET, please check your inetd config

Changing the configuration line in '/etc/inetd.conf' to read:
  tftp dgram udp4 wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot
causes this error to go away, but it is then replaced with..
tftp: server says: File not found

This is correct, as file geing asked for does not exist yet.

When the file is put in the '/var/lib/tftpboot' directory, with 'chmod 666' privs, the following error is reported..
  tftpd: read(ack): Connection refused
(I should probably file this as a separate bug.)

NOTE: If testing, care need to be taken that all the 'in.tftpd' processes are killed off before restarting inetd.

[sven (post-svennielsen)]

in reply to: Also causes installation of 'tftpd-hpa' to fail (out of the box).

Package introduces a typo! Change tftp line in inetd.conf to:

tftp dgram udp4 wait root /usr/sbin/in.tcpd /usr/sbin/in.tftpd -s /var/lib/tftpboot

[sven (post-svennielsen)]

sorry, it should of course be:

tftp dgram udp4 wait root /usr/sbin/tcpd /usr/sbin/in.tftpd -s /var/lib/tftpboot

so, its _/usr/sbin/tcpd_ , not _/usr/sbin/in.tftpd_ as first daemon string, which, of course, is simply a typo since tcpd is supposed to _start_ in.tftpd

[aboaboit (andrea-borgia-deactivatedaccount)]

Using 9.04 here and this bug is still alive and kicking: installing xinetd does not solve the problem, but a reasonable workaround is to comment out the IPv6 parts of /etc/hosts.

[Chaim Krause (tinjaw)]

I am experiencing this problem with 9.04. I noticed it while trying to get PXE boot working.

In my case altering the line in inetd.conf doesn't solve the problem.

tftp dgram udp4 wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot

and tftpd never starts. I restart xinetd and get an OK status message, but I don't get a connection and netstat -a doesn't show anything listening.

If I run tftpd standalone via

/usr/sbin/in.tftpd -Ls /var/lib/tftpboot

it shows as running in IP v4.

[Ken D'Ambrosio (ken-jots)]

Someone else recently mentioned -- on the same bug at launchpad -- a
different fix. It might have been to delete the IPv6 entries in
/etc/hosts (IIRC), but you'll want to check the bug to be sure.

Let us know if it works, and good luck!

-Ken

On Tue, June 2, 2009 8:40 am, Chaim Krause wrote:
> I am experiencing this problem with 9.04. I noticed it while trying to
> get PXE boot working.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.