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

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?

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

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.

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.

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

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

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.

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.

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.