ping6 sends packets to destination, kernel receives echo reply, but recvmsg() call gets just EAGAIN, seems like bug in kernel, (missing htons() or ntohs() call or that size_t is 8 ???) there is no firewall installed the kernel used is 2.4.21-sparc-r0, relevant parts from .config: # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_ROUTE_LARGE_TABLES=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y CONFIG_IPV6=m Reproducible: Always Steps to Reproduce: 1.modprobe ipv6 2.ping6 -c 5 ::1 Actual Results: PING ::1(::1) 56 data bytes --- ::1 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4014ms # /usr/sbin/tcpdump -i lo -n tcpdump: listening on lo 15:45:47.359586 ::1 > ::1: icmp6: echo request 15:45:47.359622 ::1 > ::1: icmp6: echo reply 15:45:48.376275 ::1 > ::1: icmp6: echo request 15:45:48.376293 ::1 > ::1: icmp6: echo reply 15:45:49.376289 ::1 > ::1: icmp6: echo request 15:45:49.376307 ::1 > ::1: icmp6: echo reply 15:45:50.376276 ::1 > ::1: icmp6: echo request 15:45:50.376293 ::1 > ::1: icmp6: echo reply 15:45:51.376275 ::1 > ::1: icmp6: echo request 15:45:51.376293 ::1 > ::1: icmp6: echo reply Expected Results: notify about echo replies Portage 2.0.48-r1 (default-sparc64-1.4, gcc-3.2.3, glibc-2.3.1-r4) ================================================================= System uname: 2.4.21-sparc-r0 sparc64 sun4u GENTOO_MIRRORS="ftp://gentoo.inode.at/source/ http://ftp.easynet.nl/mirror/gentoo/ http://194.83.57.11/sites/www.ibiblio.org/gentoo/" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/confi g /usr/kde/3/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="sparc apm avi encode esd fbcon imlib libwww mad mikmod motif nls oggvorbis oss opengl spell xv xml2 xmms gdbm berkdb slang readline tcpd perl python - 3dfx -3dnow aalib acl -alsa apache2 -arts -bonobo -cdr -cjk crypt -cups curl - dga doc -emacs gif -gnome gpm -gtk -gtk2 -imap innodb ipv6 java jpeg -kde - kerberos -krb4 maildir mbox -mozilla -mpeg mysql ncurses pam pdflib png -qt - samba -sdl snmp ssl -svga tetex truetype -X zlib" COMPILER="gcc3" CHOST="sparc-unknown-linux-gnu" CFLAGS="-mcpu=ultrasparc -O3 -pipe" CXXFLAGS="-mcpu=ultrasparc -O3 -pipe" ACCEPT_KEYWORDS="sparc ~sparc" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
I'm not a sparc or ipv6 user, but this bug is quite old and a newer version of sparc-sources (and presumably other involved packages as well) is available. Could you test again with the latest sources and report back?
I'll try this after the holiday, adding myself to the list so I don't forget.
This was a sparc64-specific kernel bug. Dave Miller fixed it shortly after the bug was entered, so it should definitely be fixed in the current sources.
This works with the latest stable kernel, sparc-sources-2.4.24.