loopback interface broken on current
27 views
Skip to first unread message
Manfred Antar
Dec 27, 2012, 12:05:26 PM12/27/12
to freebsd...@freebsd.org
For the past few days the loopback interface 127.0.0.1 is broken on current.
The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012
Here are some of the errors from current today:
Setting hostname: pozo.com.
ifa_del_loopback_route: deletion failed: 3
ifconfig: ioctl (SIOCAIFADDR): File exists
bge0: link state changed to DOWN
ifa_del_loopback_route: deletion failed: 3
Dec 27 07:21:30.617 [803] warn: server socket setup failed, retry 1: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:31.620 [803] warn: server socket setup failed, retry 2: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:32.622 [803] warn: server socket setup failed, retry 3: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:33.624 [803] warn: server socket setup failed, retry 4: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:34.626 [803] warn: server socket setup failed, retry 5: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:34.846 [803] warn: server socket setup failed, retry 6: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:35.848 [803] warn: server socket setup failed, retry 7: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:36.850 [803] warn: server socket setup failed, retry 8: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:37.852 [803] warn: server socket setup failed, retry 9: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:38.854 [803] error: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
/etc/rc: WARNING: failed to start spamd
Starting dccgrey.
no IPv4 support, connect(): Network is unreachable
Starting dccifd.
no IPv4 support, connect(): Network is unreachable
PING localhost (127.0.0.1): 56 data bytes
^C
--- localhost ping statistics ---
20 packets transmitted, 0 packets received, 100.0% packet loss
Manfred
========================
|| nu...@pozo.com ||
|| Ph. (415) 681-6235 ||
========================
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012
Here are some of the errors from current today:
Setting hostname: pozo.com.
ifa_del_loopback_route: deletion failed: 3
ifconfig: ioctl (SIOCAIFADDR): File exists
bge0: link state changed to DOWN
ifa_del_loopback_route: deletion failed: 3
Dec 27 07:21:30.617 [803] warn: server socket setup failed, retry 1: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:31.620 [803] warn: server socket setup failed, retry 2: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:32.622 [803] warn: server socket setup failed, retry 3: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:33.624 [803] warn: server socket setup failed, retry 4: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:34.626 [803] warn: server socket setup failed, retry 5: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:34.846 [803] warn: server socket setup failed, retry 6: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:35.848 [803] warn: server socket setup failed, retry 7: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:36.850 [803] warn: server socket setup failed, retry 8: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:37.852 [803] warn: server socket setup failed, retry 9: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
Dec 27 07:21:38.854 [803] error: spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
spamd: could not create INET socket on 127.0.0.1:783: Can't assign requested address
/etc/rc: WARNING: failed to start spamd
Starting dccgrey.
no IPv4 support, connect(): Network is unreachable
Starting dccifd.
no IPv4 support, connect(): Network is unreachable
PING localhost (127.0.0.1): 56 data bytes
^C
--- localhost ping statistics ---
20 packets transmitted, 0 packets received, 100.0% packet loss
Manfred
========================
|| nu...@pozo.com ||
|| Ph. (415) 681-6235 ||
========================
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Gleb Smirnoff
Jan 1, 2013, 5:22:55 AM1/1/13
to Manfred Antar, freebsd...@freebsd.org
Manfred,
On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote:
M> For the past few days the loopback interface 127.0.0.1 is broken on current.
M> The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012
M> Here are some of the errors from current today:
Can you please track this down to the specific revision that made the
regression? The timeframe is samll, so binary search probably won't
take long time.
--
Totus tuus, Glebius.
On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote:
M> For the past few days the loopback interface 127.0.0.1 is broken on current.
M> The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012
M> Here are some of the errors from current today:
Can you please track this down to the specific revision that made the
regression? The timeframe is samll, so binary search probably won't
take long time.
--
Totus tuus, Glebius.
Mark Atkinson
Jan 1, 2013, 12:45:45 PM1/1/13
to freebsd...@freebsd.org
On 1/1/2013 2:22 AM, Gleb Smirnoff wrote:
> Manfred,
>
> On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote:
> M> For the past few days the loopback interface 127.0.0.1 is broken on current.
> M> The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012
> M> Here are some of the errors from current today:
>
> Can you please track this down to the specific revision that made the
> regression? The timeframe is samll, so binary search probably won't
> take long time.
>
>
nc -l 127.0.0.1 <port>
> Manfred,
>
> On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote:
> M> For the past few days the loopback interface 127.0.0.1 is broken on current.
> M> The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012
> M> Here are some of the errors from current today:
>
> Can you please track this down to the specific revision that made the
> regression? The timeframe is samll, so binary search probably won't
> take long time.
>
>
works for me on r244911
Garrett Cooper
Jan 1, 2013, 1:06:29 PM1/1/13
to Mark Atkinson, freebsd...@freebsd.org
Maybe it's this commit?
HTH,
-Garrett
------------------------------------------------------------------------
r244678 | glebius | 2012-12-25 05:01:58 -0800 (Tue, 25 Dec 2012) | 17 lines
The SIOCSIFFLAGS ioctl handler runs if_up()/if_down() that notify
all interested parties in case if interface flag IFF_UP has changed.
However, not only SIOCSIFFLAGS can raise the flag, but SIOCAIFADDR
and SIOCAIFADDR_IN6 can, too. The actual |= is done not in the protocol
code, but in code of interface drivers. To fix this historical layering
violation, we will check whether ifp->if_ioctl(SIOCSIFADDR) raised the
IFF_UP flag, and if it did, run the if_up() handler.
This fixes configuring an address under CARP control on an interface
that was initially !IFF_UP.
P.S. I intentionally omitted handling the IFF_SMART flag. This flag was
never ever used in any driver since it was introduced, and since it
means another layering violation, it should be garbage collected instead
of pretended to be supported.
HTH,
-Garrett
------------------------------------------------------------------------
r244678 | glebius | 2012-12-25 05:01:58 -0800 (Tue, 25 Dec 2012) | 17 lines
The SIOCSIFFLAGS ioctl handler runs if_up()/if_down() that notify
all interested parties in case if interface flag IFF_UP has changed.
However, not only SIOCSIFFLAGS can raise the flag, but SIOCAIFADDR
and SIOCAIFADDR_IN6 can, too. The actual |= is done not in the protocol
code, but in code of interface drivers. To fix this historical layering
violation, we will check whether ifp->if_ioctl(SIOCSIFADDR) raised the
IFF_UP flag, and if it did, run the if_up() handler.
This fixes configuring an address under CARP control on an interface
that was initially !IFF_UP.
P.S. I intentionally omitted handling the IFF_SMART flag. This flag was
never ever used in any driver since it was introduced, and since it
means another layering violation, it should be garbage collected instead
of pretended to be supported.
Manfred Antar
Jan 1, 2013, 3:42:47 PM1/1/13
to Gleb Smirnoff, freebsd...@freebsd.org
At 11:48 AM 1/1/2013, Gleb Smirnoff wrote:
>On Tue, Jan 01, 2013 at 02:39:58AM -0800, Manfred Antar wrote:
>M> >On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote:
>M> >M> For the past few days the loopback interface 127.0.0.1 is broken on current.
>M> >M> The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012
>M> >M> Here are some of the errors from current today:
>M> >
>M> >Can you please track this down to the specific revision that made the
>M> >regression? The timeframe is samll, so binary search probably won't
>M> >take long time.
>M> Hi
>M> I'm not sure how to do this :(
>M> I just switched from CVS to SVN 2 weeks ago.
>M> I still have a current CVS tree on my machine.
>M> I guess i can try to check out a /usr/src/sys from the 25 on and see what changes were made.
>M> I'm just learning SVN so not sure how to do it with that.
>
>With SVN you don't need to care about dates, you just go through the
>sequential list of revisions. So you just seek between r244662 and the
>most recent revision tht didn't work for you. On first step you
>divide the bad revision (let it be 244768) and good one r244662:
>
>(244662 + 244768)/2 = 244715
>
>Ok, it is 244715. Let's take it and test:
>
>svn up -r 244715
>
>If it is fine, you check the one in the middle between 244715and
>244768. Otherwise you chek in between 244715 and 244662. And so on...
>
>--
>Totus tuus, Glebius.
OK
I tracked it down to revision 244678
244677 works
the files involved are:
(src)5012}svn up -r 244678
Updating '.':
U sys/netinet/in.c
U sys/netinet6/in6.c
Updated to revision 244678
It seems like the ip6 for localhost is configured but ip4 isn't:
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
From 244677:
Setting hostname: pozo.com.
Starting Network: lo0 bge0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Manfred
========================
|| nu...@pozo.com ||
|| Ph. (415) 681-6235 ||
========================
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
>On Tue, Jan 01, 2013 at 02:39:58AM -0800, Manfred Antar wrote:
>M> >On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote:
>M> >M> For the past few days the loopback interface 127.0.0.1 is broken on current.
>M> >M> The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012
>M> >M> Here are some of the errors from current today:
>M> >
>M> >Can you please track this down to the specific revision that made the
>M> >regression? The timeframe is samll, so binary search probably won't
>M> >take long time.
>M> Hi
>M> I'm not sure how to do this :(
>M> I just switched from CVS to SVN 2 weeks ago.
>M> I still have a current CVS tree on my machine.
>M> I guess i can try to check out a /usr/src/sys from the 25 on and see what changes were made.
>M> I'm just learning SVN so not sure how to do it with that.
>
>With SVN you don't need to care about dates, you just go through the
>sequential list of revisions. So you just seek between r244662 and the
>most recent revision tht didn't work for you. On first step you
>divide the bad revision (let it be 244768) and good one r244662:
>
>(244662 + 244768)/2 = 244715
>
>Ok, it is 244715. Let's take it and test:
>
>svn up -r 244715
>
>If it is fine, you check the one in the middle between 244715and
>244768. Otherwise you chek in between 244715 and 244662. And so on...
>
>--
>Totus tuus, Glebius.
OK
I tracked it down to revision 244678
244677 works
the files involved are:
(src)5012}svn up -r 244678
Updating '.':
U sys/netinet/in.c
U sys/netinet6/in6.c
Updated to revision 244678
It seems like the ip6 for localhost is configured but ip4 isn't:
Setting hostname: pozo.com.
ifa_del_loopback_route: deletion failed: 3
ifconfig: ioctl (SIOCAIFADDR): File exists
bge0: link state changed to DOWN
ifa_del_loopback_route: deletion failed: 3
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
ifa_del_loopback_route: deletion failed: 3
ifconfig: ioctl (SIOCAIFADDR): File exists
bge0: link state changed to DOWN
ifa_del_loopback_route: deletion failed: 3
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
From 244677:
Setting hostname: pozo.com.
Starting Network: lo0 bge0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Manfred
========================
|| nu...@pozo.com ||
|| Ph. (415) 681-6235 ||
========================
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
O. Hartmann
Jan 1, 2013, 5:56:51 PM1/1/13
to Manfred Antar, Gleb Smirnoff, freebsd...@freebsd.org
Am 01/01/13 21:42, schrieb Manfred Antar:
I have a similar issue here. It came out after a lot of problems with
the amd automounter which rendered a server completeley useless and the
very interesting issue is, that the loopback interface, lo0, has IPv6
configured, but it doesn't have IPv4 configured anymore.
After a recompilation of the kernel on the 31.12.2012 and a reboot, the
box is not responsive anymore (it a remote box I reach not before 07th
Jan). NAGIOS is still reporting ICMP ping is good, but every other
service is down.
On another server I do not face this problem - or have faced that
problem and I use the very same OS revisions on most of the CURRENT
boxes. But all machines started suffering from some amd automounter
issue before the problem got serious.
This is strange ...
oh
the amd automounter which rendered a server completeley useless and the
very interesting issue is, that the loopback interface, lo0, has IPv6
configured, but it doesn't have IPv4 configured anymore.
After a recompilation of the kernel on the 31.12.2012 and a reboot, the
box is not responsive anymore (it a remote box I reach not before 07th
Jan). NAGIOS is still reporting ICMP ping is good, but every other
service is down.
On another server I do not face this problem - or have faced that
problem and I use the very same OS revisions on most of the CURRENT
boxes. But all machines started suffering from some amd automounter
issue before the problem got serious.
This is strange ...
oh
Gleb Smirnoff
Jan 2, 2013, 3:13:30 PM1/2/13
to Manfred Antar, freebsd...@freebsd.org
On Tue, Jan 01, 2013 at 12:42:47PM -0800, Manfred Antar wrote:
M> OK
M> I tracked it down to revision 244678
M> 244677 works
M> the files involved are:
M> (src)5012}svn up -r 244678
M> Updating '.':
M> U sys/netinet/in.c
M> U sys/netinet6/in6.c
M> Updated to revision 244678
M>
M> It seems like the ip6 for localhost is configured but ip4 isn't:
M> Setting hostname: pozo.com.
M> ifa_del_loopback_route: deletion failed: 3
M> ifconfig: ioctl (SIOCAIFADDR): File exists
M> bge0: link state changed to DOWN
M> ifa_del_loopback_route: deletion failed: 3
M>
M> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
M> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
M> inet6 ::1 prefixlen 128
M> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
M> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
M>
M> From 244677:
M> Setting hostname: pozo.com.
M>
M> Starting Network: lo0 bge0.
M> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
M> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
M> inet 127.0.0.1 netmask 0xff000000
M> inet6 ::1 prefixlen 128
M> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
M> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Ok, so this is my failure. :( Sorry. I will look at it as soon as
I get to decent internet connection. Right now I am on very bad GPRS.
Can you please show your rc.conf (the network related part)?
--
Totus tuus, Glebius.
M> OK
M> I tracked it down to revision 244678
M> 244677 works
M> the files involved are:
M> (src)5012}svn up -r 244678
M> Updating '.':
M> U sys/netinet/in.c
M> U sys/netinet6/in6.c
M> Updated to revision 244678
M>
M> It seems like the ip6 for localhost is configured but ip4 isn't:
M> Setting hostname: pozo.com.
M> ifa_del_loopback_route: deletion failed: 3
M> ifconfig: ioctl (SIOCAIFADDR): File exists
M> bge0: link state changed to DOWN
M> ifa_del_loopback_route: deletion failed: 3
M>
M> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
M> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
M> inet6 ::1 prefixlen 128
M> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
M> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
M>
M> From 244677:
M> Setting hostname: pozo.com.
M>
M> Starting Network: lo0 bge0.
M> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
M> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
M> inet 127.0.0.1 netmask 0xff000000
M> inet6 ::1 prefixlen 128
M> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
M> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Ok, so this is my failure. :( Sorry. I will look at it as soon as
I get to decent internet connection. Right now I am on very bad GPRS.
Can you please show your rc.conf (the network related part)?
--
Totus tuus, Glebius.
Manfred Antar
Jan 2, 2013, 6:25:14 PM1/2/13
to Gleb Smirnoff, freebsd...@freebsd.org
>
>
>Ok, so this is my failure. :( Sorry. I will look at it as soon as
>I get to decent internet connection. Right now I am on very bad GPRS.
>
>Can you please show your rc.conf (the network related part)?
>
>
>--
>Totus tuus, Glebius.
/etc/hosts:
::1 localhost localhost.pozo.com
127.0.0.1 localhost localhost.pozo.com
/etc/rc.conf:
ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0"
defaultrouter="192.168.0.1" # Set to default gateway
ipv6_network_interfaces="auto" # List of IPv6 network interfaces
# (or "auto" or "none").
ipv6_activate_all_interfaces="NO" # If NO, interfaces which have no
ipv6_defaultrouter="NO" # Set to IPv6 default gateway (or NO).
ipv6_static_routes="" # Set to static route list (or leave empty).
#ipv6_static_routes="xxx" # An example to set fec0:0000:0000:0006::/64
# route toward loopback interface.
#ipv6_route_xxx="fec0:0000:0000:0006:: -prefixlen 64 ::1"
ipv6_gateway_enable="NO" # Set to YES if this host will be a gateway.
ipv6_cpe_wanif="NO" # Set to the upstram interface name if this
# node will work as a router to forward IPv6
# packets not explicitly addressed to itself.
ipv6_privacy="NO" # Use privacy address on RA-receiving IFs
# (RFC 4941)
route6d_enable="NO" # Set to YES to enable an IPv6 routing daemon.
route6d_program="/usr/sbin/route6d" # Name of IPv6 routing daemon.
route6d_flags="" # Flags to IPv6 routing daemon.
#route6d_flags="-l" # Example for route6d with only IPv6 site local
# addrs.
#route6d_flags="-q" # If you want to run a routing daemon on an end
# node, you should stop advertisement.
#ipv6_network_interfaces="ed0 ep0" # Examples for router
# or static configuration for end node.
# Choose correct prefix value.
#ipv6_prefix_ed0="fec0:0000:0000:0001 fec0:0000:0000:0002" # Examples for rtr.
#ipv6_prefix_ep0="fec0:0000:0000:0003 fec0:0000:0000:0004" # Examples for rtr.
ipv6_default_interface="NO" # Default output interface for scoped addrs.
# This works only with
# ipv6_gateway_enable="NO".
That pretty much it, nothing special
I haven't made any changes to it in over 2 years.
The only thing about 1 year ago I enabled:
### Network link/usability verification options
netwait_enable="YES" # Enable rc.d/netwait (or NO)
netwait_ip="192.168.0.1" # IP addresses to be pinged by netwait.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
KAHO Toshikazu
Jan 2, 2013, 10:09:10 PM1/2/13
to Manfred Antar, freebsd...@freebsd.org
Hello,
I have a similar problem if "ifconfig_lo0" line is exist in /etc/rc.conf.
Can you remove lo0 configure line from /etc/rc.conf.
> /etc/rc.conf:
> ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
--
vi...@elam.kais.kyoto-u.ac.jp
I have a similar problem if "ifconfig_lo0" line is exist in /etc/rc.conf.
Can you remove lo0 configure line from /etc/rc.conf.
> /etc/rc.conf:
> ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
vi...@elam.kais.kyoto-u.ac.jp
Manfred Antar
Jan 2, 2013, 10:54:59 PM1/2/13
to KAHO Toshikazu, freebsd...@freebsd.org, Gleb Smirnoff
At 07:09 PM 1/2/2013, KAHO Toshikazu wrote:
> Hello,
>
>I have a similar problem if "ifconfig_lo0" line is exist in /etc/rc.conf.
>Can you remove lo0 configure line from /etc/rc.conf.
>
>> /etc/rc.conf:
>> ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
Ok
> Hello,
>
>I have a similar problem if "ifconfig_lo0" line is exist in /etc/rc.conf.
>Can you remove lo0 configure line from /etc/rc.conf.
>
>> /etc/rc.conf:
>> ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
I commented out that line and it seems to work.
There is still ====>ifa_del_loopback_route: deletion failed: 3
that wasn't there before,but the 127.0.0.1 seems to be configured now:
Setting hostname: pozo.com.
bge0: link state changed to DOWN
ifa_del_loopback_route: deletion failed: 3
bge0: link state changed to UP
Starting Network: lo0 bge0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
ether 00:0e:7f:66:30:20
inet 192.168.0.5 netmask 0xffffff00 broadcast 192.168.0.255
inet6 fe80::20e:7fff:fe66:3020%bge0 prefixlen 64 scopeid 0x1
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
Starting devd.
add net default: gateway 192.168.0.1
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
add net fe80::: gateway ::1
add net ff02::: gateway ::1
Waiting for bge0 to have link.
Waiting for 192.168.0.1 to respond to ICMP.
#########################################################################
(~)4999}ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.039 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.050 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.045 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.042 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.044 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.047 ms
64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.045 ms
^C
--- localhost ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
--- localhost ping statistics ---
round-trip min/avg/max/stddev = 0.029/0.043/0.050/0.006 ms
(~)5000}
Manfred
========================
|| nu...@pozo.com ||
|| Ph. (415) 681-6235 ||
========================
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
KAHO Toshikazu
Jan 3, 2013, 6:30:18 AM1/3/13
to Manfred Antar, freebsd...@freebsd.org, Gleb Smirnoff
Hello,
> There is still ====>ifa_del_loopback_route: deletion failed: 3
> that wasn't there before,but the 127.0.0.1 seems to be configured now:
Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
If you have it, try to remove it.
I think something broken, but people using automatic configuration
don't notice the breakage.
--
ka...@elam.kais.kyoto-u.ac.jp
> There is still ====>ifa_del_loopback_route: deletion failed: 3
> that wasn't there before,but the 127.0.0.1 seems to be configured now:
If you have it, try to remove it.
I think something broken, but people using automatic configuration
don't notice the breakage.
--
ka...@elam.kais.kyoto-u.ac.jp
Manfred Antar
Jan 3, 2013, 8:07:07 AM1/3/13
to KAHO Toshikazu, freebsd...@freebsd.org, Gleb Smirnoff
At 03:30 AM 1/3/2013, KAHO Toshikazu wrote:
> Hello,
>
>> There is still ====>ifa_del_loopback_route: deletion failed: 3
>> that wasn't there before,but the 127.0.0.1 seems to be configured now:
>
> Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
>If you have it, try to remove it.
>
> I think something broken, but people using automatic configuration
>don't notice the breakage.
>
>--
>ka...@elam.kais.kyoto-u.ac.jp
>
> Hello,
>
>> There is still ====>ifa_del_loopback_route: deletion failed: 3
>> that wasn't there before,but the 127.0.0.1 seems to be configured now:
>
> Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
>If you have it, try to remove it.
>
> I think something broken, but people using automatic configuration
>don't notice the breakage.
>
>--
>ka...@elam.kais.kyoto-u.ac.jp
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
I have :
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
network_interfaces="auto"
ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0"
I will try to comment out the above line and see what happens.
But I think it might screw up my routing
========================
|| nu...@pozo.com ||
|| Ph. (415) 681-6235 ||
========================
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Manfred Antar
Jan 3, 2013, 8:17:34 AM1/3/13
to KAHO Toshikazu, freebsd...@freebsd.org, Gleb Smirnoff
At 03:30 AM 1/3/2013, KAHO Toshikazu wrote:
> Hello,
>
>> There is still ====>ifa_del_loopback_route: deletion failed: 3
>> that wasn't there before,but the 127.0.0.1 seems to be configured now:
>
> Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
>If you have it, try to remove it.
>
> I think something broken, but people using automatic configuration
>don't notice the breakage.
>
>--
>ka...@elam.kais.kyoto-u.ac.jp
>
>
>> There is still ====>ifa_del_loopback_route: deletion failed: 3
>> that wasn't there before,but the 127.0.0.1 seems to be configured now:
>
> Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
>If you have it, try to remove it.
>
> I think something broken, but people using automatic configuration
>don't notice the breakage.
>
>--
>ka...@elam.kais.kyoto-u.ac.jp
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
Hi
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
If I comment out :
ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0"
Network doesn't work.
========================
|| nu...@pozo.com ||
|| Ph. (415) 681-6235 ||
========================
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
KAHO Toshikazu
Jan 3, 2013, 9:10:35 AM1/3/13
to Manfred Antar, freebsd...@freebsd.org, Gleb Smirnoff
Hello,
> If I comment out :
> ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0"
> Network doesn't work.
Yes, you should not commnet out it,
you cannot connect from/to outside.
network_interfaces="auto" is same as /etc/default/rc.conf,
so that you can remove it safely from /etc/rc.conf.
I cannot identify the problematic line caused the problem.
--
vi...@elam.kais.kyoto-u.ac.jp
> If I comment out :
> ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0"
> Network doesn't work.
you cannot connect from/to outside.
network_interfaces="auto" is same as /etc/default/rc.conf,
so that you can remove it safely from /etc/rc.conf.
I cannot identify the problematic line caused the problem.
--
vi...@elam.kais.kyoto-u.ac.jp
Gary Jennejohn
Jan 4, 2013, 3:45:32 AM1/4/13
to KAHO Toshikazu, freebsd...@freebsd.org, Gleb Smirnoff
On Thu, 03 Jan 2013 20:30:18 +0900
KAHO Toshikazu <vi...@elam.kais.kyoto-u.ac.jp> wrote:
> Hello,
>
> > There is still ====>ifa_del_loopback_route: deletion failed: 3
> > that wasn't there before,but the 127.0.0.1 seems to be configured now:
>
> Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
> If you have it, try to remove it.
>
> I think something broken, but people using automatic configuration
> don't notice the breakage.
>
Something is definitely broken because I don't have network_interfaces
KAHO Toshikazu <vi...@elam.kais.kyoto-u.ac.jp> wrote:
> Hello,
>
> > There is still ====>ifa_del_loopback_route: deletion failed: 3
> > that wasn't there before,but the 127.0.0.1 seems to be configured now:
>
> Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
> If you have it, try to remove it.
>
> I think something broken, but people using automatic configuration
> don't notice the breakage.
>
in /etc/rc.conf but my lo0 does not have even ipv6 addresses assigned.
--
Gary Jennejohn
Hartmann, O.
Jan 9, 2013, 3:56:25 AM1/9/13
to gljen...@googlemail.com, freebsd...@freebsd.org, Gleb Smirnoff
On 01/04/13 09:45, Gary Jennejohn wrote:
> On Thu, 03 Jan 2013 20:30:18 +0900
> KAHO Toshikazu <vi...@elam.kais.kyoto-u.ac.jp> wrote:
>
>> Hello,
>>
>>> There is still ====>ifa_del_loopback_route: deletion failed: 3
>>> that wasn't there before,but the 127.0.0.1 seems to be configured now:
>>
>> Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
>> If you have it, try to remove it.
>>
>> I think something broken, but people using automatic configuration
>> don't notice the breakage.
>>
>
> Something is definitely broken because I don't have network_interfaces
> in /etc/rc.conf but my lo0 does not have even ipv6 addresses assigned.
>
Same here.
> On Thu, 03 Jan 2013 20:30:18 +0900
> KAHO Toshikazu <vi...@elam.kais.kyoto-u.ac.jp> wrote:
>
>> Hello,
>>
>>> There is still ====>ifa_del_loopback_route: deletion failed: 3
>>> that wasn't there before,but the 127.0.0.1 seems to be configured now:
>>
>> Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
>> If you have it, try to remove it.
>>
>> I think something broken, but people using automatic configuration
>> don't notice the breakage.
>>
>
> Something is definitely broken because I don't have network_interfaces
> in /etc/rc.conf but my lo0 does not have even ipv6 addresses assigned.
>
The OS: FreeBSD 10.0-CURRENT/amd64 r245218. Since I have three boxes
running approximately the same configurations (I share my configs
between lab and home), but different hardware, I'm confused.
The symptoms in my case are:
Booting the box is all right until it comes to the start of nfsuserd.
Prior to that, ntp adjusts the clock properly with an external time
server - so this implies network connectivity. Start of nfsuserd is
stuck forever.
Interrupting the start of nfsuserd restarts several other services, but
winbindd and slapd (OpenLDAP) get stuck again. In case I also interrupt
them, there are other services which will not start.
Trying to login as root on the console fails - I never get a password
tag after having issued the root login name. Since this machine is bound
to a local and remote OpenLDAP backend, I'm used to have an emergency
local user which usually works - but this time, neither root nor this
user can login!
Bringing up the box in SINGLEUSER allows me to login. Investigating the
network interfaces with ifconfig reveals, that the loopback did not get
assigned to any inet 127.0.0.1 address. Sometimes there is only inet6
linklocal address, some nd6 options, but sometimes even IPv6 assignments
do not show up.
In a desperate move I tried to recompile a kernel. In /etc/src.conf, I
recompile also the kernel module for the most recent virtual-box kernel
module. While the kernel and module (*.ko) get installed properly, the
recompilation of the VirtualBox port gets stuck when the system unfolds
the source tarball. Hitting Ctrl-T say "sbwait" for the process. Other
processes seem to have trouble getting a proper ownership or UID for a
file - this is my naiv interpretation what I see at the surface.
The funny thing is, that after several reboots, the box gets up as normal.
I revealed this issue approx. two weeks ago when out of the sudden the
amd automounter stopped working and the NFSv4 network drives didn't
attach properly and made the whole box being stuck.
Sorry for the more superficial description of the problem ...
Has the problem been identified? Is there a solution? Since it affects
only my very modern hardware (i7-3930, 32GB RAM, ASUS P9X79 WS
mainboard), while a very same setup on older hardware (our local server
is Intel Q6600 with 8GB RAM and and oldish Intel P45-chipset based
mainboard), both systems do have Intel NICs, I'm a bit confused.
Regards,
Oliver
Gleb Smirnoff
Jan 9, 2013, 3:59:07 AM1/9/13
to Hartmann, O., freebsd...@freebsd.org
On Wed, Jan 09, 2013 at 09:56:25AM +0100, Hartmann, O. wrote:
H> Same here.
H> The OS: FreeBSD 10.0-CURRENT/amd64 r245218. Since I have three boxes
H> running approximately the same configurations (I share my configs
H> between lab and home), but different hardware, I'm confused.
H>
H> The symptoms in my case are:
H>
H> Booting the box is all right until it comes to the start of nfsuserd.
H> Prior to that, ntp adjusts the clock properly with an external time
H> server - so this implies network connectivity. Start of nfsuserd is
H> stuck forever.
H> Interrupting the start of nfsuserd restarts several other services, but
H> winbindd and slapd (OpenLDAP) get stuck again. In case I also interrupt
H> them, there are other services which will not start.
H>
H> Trying to login as root on the console fails - I never get a password
H> tag after having issued the root login name. Since this machine is bound
H> to a local and remote OpenLDAP backend, I'm used to have an emergency
H> local user which usually works - but this time, neither root nor this
H> user can login!
H>
H> Bringing up the box in SINGLEUSER allows me to login. Investigating the
H> network interfaces with ifconfig reveals, that the loopback did not get
H> assigned to any inet 127.0.0.1 address. Sometimes there is only inet6
H> linklocal address, some nd6 options, but sometimes even IPv6 assignments
H> do not show up.
H>
H> In a desperate move I tried to recompile a kernel. In /etc/src.conf, I
H> recompile also the kernel module for the most recent virtual-box kernel
H> module. While the kernel and module (*.ko) get installed properly, the
H> recompilation of the VirtualBox port gets stuck when the system unfolds
H> the source tarball. Hitting Ctrl-T say "sbwait" for the process. Other
H> processes seem to have trouble getting a proper ownership or UID for a
H> file - this is my naiv interpretation what I see at the surface.
H>
H> The funny thing is, that after several reboots, the box gets up as normal.
H>
H> I revealed this issue approx. two weeks ago when out of the sudden the
H> amd automounter stopped working and the NFSv4 network drives didn't
H> attach properly and made the whole box being stuck.
H>
H> Sorry for the more superficial description of the problem ...
H>
H> Has the problem been identified? Is there a solution? Since it affects
H> only my very modern hardware (i7-3930, 32GB RAM, ASUS P9X79 WS
H> mainboard), while a very same setup on older hardware (our local server
H> is Intel Q6600 with 8GB RAM and and oldish Intel P45-chipset based
H> mainboard), both systems do have Intel NICs, I'm a bit confused.
This looks unrelated to the problem discussed, because r245218 is
later than r244989 which backed out my change.
Can you do a binary search to identify which revision broke things?
--
Totus tuus, Glebius.
H> Same here.
H> The OS: FreeBSD 10.0-CURRENT/amd64 r245218. Since I have three boxes
H> running approximately the same configurations (I share my configs
H> between lab and home), but different hardware, I'm confused.
H>
H> The symptoms in my case are:
H>
H> Booting the box is all right until it comes to the start of nfsuserd.
H> Prior to that, ntp adjusts the clock properly with an external time
H> server - so this implies network connectivity. Start of nfsuserd is
H> stuck forever.
H> Interrupting the start of nfsuserd restarts several other services, but
H> winbindd and slapd (OpenLDAP) get stuck again. In case I also interrupt
H> them, there are other services which will not start.
H>
H> Trying to login as root on the console fails - I never get a password
H> tag after having issued the root login name. Since this machine is bound
H> to a local and remote OpenLDAP backend, I'm used to have an emergency
H> local user which usually works - but this time, neither root nor this
H> user can login!
H>
H> Bringing up the box in SINGLEUSER allows me to login. Investigating the
H> network interfaces with ifconfig reveals, that the loopback did not get
H> assigned to any inet 127.0.0.1 address. Sometimes there is only inet6
H> linklocal address, some nd6 options, but sometimes even IPv6 assignments
H> do not show up.
H>
H> In a desperate move I tried to recompile a kernel. In /etc/src.conf, I
H> recompile also the kernel module for the most recent virtual-box kernel
H> module. While the kernel and module (*.ko) get installed properly, the
H> recompilation of the VirtualBox port gets stuck when the system unfolds
H> the source tarball. Hitting Ctrl-T say "sbwait" for the process. Other
H> processes seem to have trouble getting a proper ownership or UID for a
H> file - this is my naiv interpretation what I see at the surface.
H>
H> The funny thing is, that after several reboots, the box gets up as normal.
H>
H> I revealed this issue approx. two weeks ago when out of the sudden the
H> amd automounter stopped working and the NFSv4 network drives didn't
H> attach properly and made the whole box being stuck.
H>
H> Sorry for the more superficial description of the problem ...
H>
H> Has the problem been identified? Is there a solution? Since it affects
H> only my very modern hardware (i7-3930, 32GB RAM, ASUS P9X79 WS
H> mainboard), while a very same setup on older hardware (our local server
H> is Intel Q6600 with 8GB RAM and and oldish Intel P45-chipset based
H> mainboard), both systems do have Intel NICs, I'm a bit confused.
This looks unrelated to the problem discussed, because r245218 is
later than r244989 which backed out my change.
Can you do a binary search to identify which revision broke things?
--
Totus tuus, Glebius.
O. Hartmann
Jan 10, 2013, 10:48:18 AM1/10/13
to Gleb Smirnoff, freebsd...@freebsd.org
Am 01/09/13 09:59, schrieb Gleb Smirnoff:
Sorry for the delay.
Today I realized that the problems occured and described are due to the
fact that I use jumbo frames (mtu 9100 or mtu 6150) on the em0-device
(em0@pci0:0:25:0: class=0x020000 card=0x844e1043 chip=0x15038086
rev=0x05 hdr=0x00
vendor = 'Intel Corporation'
device = '82579V Gigabit Network Connection'
class = network
subclass = ethernet
). Using the default of mtu 1500 does not make the problem occur.
My time constraints disallow to do further or deeper investigations - at
least until the end of next week, I'm sorry. The problems arose around
Christmas, it might be even earlier, since I didn't access the machine
since 10th December.
I have other boxes with Intel NICs - different chiptypes. They do not
show this problem.
Oliver
Today I realized that the problems occured and described are due to the
fact that I use jumbo frames (mtu 9100 or mtu 6150) on the em0-device
(em0@pci0:0:25:0: class=0x020000 card=0x844e1043 chip=0x15038086
rev=0x05 hdr=0x00
vendor = 'Intel Corporation'
device = '82579V Gigabit Network Connection'
class = network
subclass = ethernet
). Using the default of mtu 1500 does not make the problem occur.
My time constraints disallow to do further or deeper investigations - at
least until the end of next week, I'm sorry. The problems arose around
Christmas, it might be even earlier, since I didn't access the machine
since 10th December.
I have other boxes with Intel NICs - different chiptypes. They do not
show this problem.
Oliver
Reply all
Reply to author
Forward
0 new messages