Error 127.0.0.1: no route to host
Renato Botelho
to get errors like this
127.0.0.1: no route to host
I boot using kernel.old and everything back to normal. I don't know
exactly revision of my kernel.old because last change made on
sys/conf/newvers.sh simply removed this information from my
uname, see:
FreeBSD botelhor.bplab.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Mon
Mar 8 15:52:59 BRT 2010
ro...@botelhor.bplab.local:/usr/obj/usr/src/sys/GARGA amd64
I just know it was built yesterday about 18:00 UTC
Is there any other way to get this information?
Let me know if you need more information about my environment.
Regards
--
Renato Botelho
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Li, Qing
-- Qing
> To unsubscribe, send any mail to "freebsd-current-
> unsub...@freebsd.org"
Li, Qing
Please try patch at
http://people.freebsd.org/~qingli/route.h.diff
Renato Botelho
> This error was caused by my commit r204902 from yesterday.
>
> Please try patch at
>
> http://people.freebsd.org/~qingli/route.h.diff
Patch fixed the problem, thanks for the quick reply and fix.
--
Renato Botelho
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Julian Elischer
> This error was caused by my commit r204902 from yesterday.
>
I remember saying "well the patch itself is basically ok but I don't
know about the side effects". (about the ARPv2 change in general)
I'm guessing you have had a rather interesting learning experience
about how much simple changes can become complicated. :-)
Julian Elischer
> Li, Qing wrote:
>> This error was caused by my commit r204902 from yesterday.
>>
> [...]
>
>
> I remember saying "well the patch itself is basically ok but I don't
> know about the side effects". (about the ARPv2 change in general)
>
> I'm guessing you have had a rather interesting learning experience
> about how much simple changes can become complicated. :-)
oops this was meant to be a private email
Sorry Qing Li!
Doug Barton
> This error was caused by my commit r204902 from yesterday.
>
This doesn't appear to be committed yet, is it still the best fix?
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
Michael Butler
Hash: SHA1
On 03/09/10 21:00, Doug Barton wrote:
> On 03/09/10 12:14, Li, Qing wrote:
>> This error was caused by my commit r204902 from yesterday.
>>
>> Please try patch at
>>
>> http://people.freebsd.org/~qingli/route.h.diff
>
> This doesn't appear to be committed yet, is it still the best fix?
Even with this patch, I can't ping the ipv4 address at the other end of
an openvpn tunnel :-(
imb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkuXjkAACgkQQv9rrgRC1JLSgwCeP1DbEdkiI4tLyteNhHS4q1yM
u4YAn0qdGCZLPDRsiRWlXRzyG1Wl4wlA
=L4+B
-----END PGP SIGNATURE-----
Li, Qing
ifconfig and netstat output? What's the error message?
Asking the obvious question, you updated to r204902?
Thanks,
--Qing
> -----Original Message-----
> From: owner-free...@freebsd.org [mailto:owner-freebsd-
> To unsubscribe, send any mail to "freebsd-current-
> unsub...@freebsd.org"
Li, Qing
> This error was caused by my commit r204902 from yesterday.
>
> Please try patch at
>
> http://people.freebsd.org/~qingli/route.h.diff
>
The route.h.diff patch warrants some explanation.
What I did here is basically excluding "if_link_state" checks
against loopback interfaces and point-to-point interfaces.
The loopback interface does not modify this variable and
conceptually it is always up. The bug was due to the check
was also performed on the loopback interface, and broke all
self destined traffic (127.0.0.1 and all local IPs).
The route.h.diff fixes this bug.
The story for the point-to-point interfaces is slightly
different. For example, if_tun interface updates the
if_link_state but I am not sure about the other ppp pseudo
interface.
By excluding the PPP interfaces from the link state check,
the behavior may be when ECMP is enabled and a PPP link is
actually down, traffic would go into blackhole, but that's
exactly the current behavior.
So with r204902 and ECMP enabled, you can failover and
load-balance across physical interfaces and those dependent
interface types such as if_vlan and if_lagg, but not PPP
link types (for now, which I will fix in time).
Your comments are welcome.
-- Qing
>
>
> > -----Original Message-----
> > From: owner-free...@freebsd.org [mailto:owner-freebsd-
> > cur...@freebsd.org] On Behalf Of Li, Qing
> > Sent: Tuesday, March 09, 2010 11:05 AM
> > To: Renato Botelho; FreeBSD Current
> > Subject: RE: Error 127.0.0.1: no route to host
> >
> > Thanks for the report, I am looking at it and will get back to you.
> >
> > -- Qing
> >
> >
> > > -----Original Message-----
> > > From: owner-free...@freebsd.org [mailto:owner-freebsd-
> > > cur...@freebsd.org] On Behalf Of Renato Botelho
> > > Sent: Tuesday, March 09, 2010 10:47 AM
> > > To: FreeBSD Current
> > > Subject: Error 127.0.0.1: no route to host
> > >
> > > I updated my 9.0-current amd64 today on rev. 204915 and start
> > > to get errors like this
> > >
> > > 127.0.0.1: no route to host
> > >
> > > I boot using kernel.old and everything back to normal. I don't
know
> > > exactly revision of my kernel.old because last change made on
> > > sys/conf/newvers.sh simply removed this information from my
> > > uname, see:
> > >
> > > FreeBSD botelhor.bplab.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1:
> Mon
> > > Mar 8 15:52:59 BRT 2010
> > > ro...@botelhor.bplab.local:/usr/obj/usr/src/sys/GARGA amd64
> > >
> > > I just know it was built yesterday about 18:00 UTC
> > >
> > > Is there any other way to get this information?
> > >
> > > Let me know if you need more information about my environment.
> > >
> > > Regards
> > > --
> > > Renato Botelho
Michael Butler
Hash: SHA1
On 03/10/10 12:18, Li, Qing wrote:
> Could you please provide me with more information, such as your
> ifconfig and netstat output? What's the error message?
With or without r204902, I do not see any difference in ifconfig or
netstat output. Addresses and routes are added as normal.
Without the route.h patch, I can't ping 127.0.0.1 or the local or remote
address of the OpenVPN tunnel (on tap0). In fact, you can't even build
OpenVPN from ports as it'll fail its self-test.
With the route.h patch, I can ping all local addresses but not the far
end of the tunnel.
Backing out r204902 restores normal operation of the tunnel.
> Asking the obvious question, you updated to r204902?
FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD
9.0-CURRENT #1 r204949M: Wed Mar 10 07:22:22 EST 2010
The 'M' signifies only that I've added my Nikon camera to the usbdev
list and added aquirk for it,
imb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkuYA0cACgkQQv9rrgRC1JL0bgCgqte+e7snRtr9uA/u0q5XaYLm
OvoAn0o6Att5R8I2da8HyNiZnDCT/NHQ
=BW8c
-----END PGP SIGNATURE-----
Li, Qing
> Without the route.h patch, I can't ping 127.0.0.1 or the local or
> remote address of the OpenVPN tunnel (on tap0). In fact, you
> can't even build OpenVPN from ports as it'll fail its self-test.
>
Please see my previous clarification email on the what and the why
about the "route.h.diff" patch.
I spent some time looking into the issue and found the problem
is the if_tap interface turns out to be one of those interfaces
that claims to be of IFT_ETHER type, but does not touch the
"if_link_state" variable.
>
> With the route.h patch, I can ping all local addresses but not the
> far end of the tunnel.
>
Please try the new patch at
http://people.freebsd.org/~qingli/ecmp-tap.diff
Let me know how it works out for you.
-- Qing
P.S. You really just need the 2-line fix in the if_tap.c file.
route.h is slightly touch to be (ifp) instead of just ifp in
the macro.
Michael Butler
Hash: SHA1
On 03/11/10 05:52, Li, Qing wrote:
> I spent some time looking into the issue and found the problem
> is the if_tap interface turns out to be one of those interfaces
> that claims to be of IFT_ETHER type, but does not touch the
> "if_link_state" variable.
[ .. ]
> Please try the new patch at
>
> http://people.freebsd.org/~qingli/ecmp-tap.diff
>
> Let me know how it works out for you.
This solves all the noted issues - thanks!
imb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkuY/BAACgkQQv9rrgRC1JLoxACeLApgw4GJzTpukzV4AHzp9ffm
4XwAn1GbXEojETUiXgAze7hIfgNcJSDF
=5iWa
-----END PGP SIGNATURE-----
Anton Shterenlikht
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/11/10 05:52, Li, Qing wrote:
> > I spent some time looking into the issue and found the problem
> > is the if_tap interface turns out to be one of those interfaces
> > that claims to be of IFT_ETHER type, but does not touch the
> > "if_link_state" variable.
>
> [ .. ]
>
> > Please try the new patch at
> >
> > http://people.freebsd.org/~qingli/ecmp-tap.diff
> >
> > Let me know how it works out for you.
>
> This solves all the noted issues - thanks!
same here
many thanks
anton
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423