Routing error messages from ppp
I get these two error messages in my PPP log every time I (re)connect, right after : tun0: Warning: 0.0.0.0/0: Change route failed: errno: No such process tun0: Warning: ff02:7::/32: Change route failed: errno: Network is unreachable They seem harmless, but I keep wondering what causes them... % netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire 80.203.47.180.203.243.180 UGH 12 tun0 127.0.0.1 127.0.0.1 UH 0 165970lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#5UHL lo0 ff01:5::/32 fe80::1%lo0 UC lo0 ff01:7::/32 link#7UGCtun0 ff02::%lo0/32 fe80::1%lo0 UC lo0 ff02::%tun0/32fe80::200:24ff:fec5:6d8%tun0 UGCtun0 % cat /etc/ppp/ppp.conf default: set log Phase Chat IPCP CCP tun command set socket /var/run/ppp/ctl ne2mivis 0177 NextGenTel: set device PPPoE:sis2 set authname set authkey set ifaddr 80.203.243.180/0 80.203.47.1/0 255.255.255.0 0.0.0.0 set mru max 1492 set mtu max 1492 add default HISADDR DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/120751: [netipsec] [patch] IPsec: kernel sends wrong pfkey expire message
Synopsis: [netipsec] [patch] IPsec: kernel sends wrong pfkey expire message Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 17 11:11:05 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=120751 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/120751: [netipsec] [patch] IPsec: kernel sends wrong pfkey expire message
Synopsis: [netipsec] [patch] IPsec: kernel sends wrong pfkey expire message Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sun Feb 17 12:28:30 UTC 2008 Responsible-Changed-Why: I'll take a look http://www.freebsd.org/cgi/query-pr.cgi?pr=120751 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: KAME IPsec spd_delete2 bug ...
On Thu, 14 Feb 2008, Matthew Grooms wrote: Hi, There is a bug in /usr/src/sys/netipsec/key.c in FreeBSD KAME IPsec sources. netipsec/ is not KAME IPsec. If an spd_delete2 message is submitted for an invalid policy id, the kernel crashes. Can someone please commit this trivial patch? I'm afraid its against 6.2 sources but its also only one line. I cannot today but hopefully during next week. Can you file a PR and get it assigned to me so this will not be lost. I'll go through the branches and get this fixed then. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ospf cost and route selection (openospfd)
Josef, good day.
Thu, Feb 14, 2008 at 06:15:09PM +0300, Eygene Ryabinkin wrote:
> > OK, I will up my gifX interfaces and will try to simulate your problem.
>
> OK, problem recreated. Will try to understand and fix the issue.
> Will drop a mail, once the situation will be more clear.
>
> Thinking, 20%... ;))
I should more carefully study current OpenBSD CVS: the fix for your
problem was committed 5 months ago. Claudio mentioned it (and he
is the author of the patch itself), but the fix didn't get into 4.2.
The funny thing is that I had wrote simular (but lower quality) fix
for the problem today and decided to look at the current OpenOSPFD
code. And looking at the last revision of ospfd/rde_spf.c I had
found calls to calc_nexthop() that were very simular to mine ones ;))
OK, to the point: the inlined patch should go to the 'files'
directory, named 'patch-p2p_interfaces'. I assume that all my
previous patches to make 4.2 to compile and run were applied.
--- begin files/patch-p2p_interfaces ---
===
RCS file: /usr/OpenBSD/cvs/src/usr.sbin/ospfd/rde_spf.c,v
retrieving revision 1.63
retrieving revision 1.64
diff -u -r1.63 -r1.64
--- ospfd/rde_spf.c 2007/08/06 11:32:34 1.63
+++ ospfd/rde_spf.c 2007/09/16 15:00:11 1.64
@@ -1,4 +1,4 @@
-/* $OpenBSD: rde_spf.c,v 1.63 2007/08/06 11:32:34 claudio Exp $ */
+/* $OpenBSD: rde_spf.c,v 1.64 2007/09/16 15:00:11 claudio Exp $ */
/*
* Copyright (c) 2005 Esben Norby <[EMAIL PROTECTED]>
@@ -37,7 +37,8 @@
voidcalc_nexthop_clear(struct vertex *);
voidcalc_nexthop_add(struct vertex *, struct vertex *, u_int32_t);
-voidcalc_nexthop(struct vertex *, struct vertex *);
+voidcalc_nexthop(struct vertex *, struct vertex *,
+struct area *, struct lsa_rtr_link *);
voidrt_nexthop_clear(struct rt_node *);
voidrt_nexthop_add(struct rt_node *, struct v_nexthead *,
struct in_addr);
@@ -134,7 +135,7 @@
if (d < w->cost) {
w->cost = d;
calc_nexthop_clear(w);
- calc_nexthop(w, v);
+ calc_nexthop(w, v, area, rtr_link);
/*
* need to readd to candidate list
* because the list is sorted
@@ -143,12 +144,12 @@
cand_list_add(w);
} else
/* equal cost path */
- calc_nexthop(w, v);
+ calc_nexthop(w, v, area, rtr_link);
} else if (w->cost == LS_INFINITY && d < LS_INFINITY) {
w->cost = d;
calc_nexthop_clear(w);
- calc_nexthop(w, v);
+ calc_nexthop(w, v, area, rtr_link);
cand_list_add(w);
}
}
@@ -384,54 +385,51 @@
}
void
-calc_nexthop(struct vertex *dst, struct vertex *parent)
+calc_nexthop(struct vertex *dst, struct vertex *parent,
+struct area *area, struct lsa_rtr_link *rtr_link)
{
- struct lsa_rtr_link *rtr_link = NULL;
struct v_nexthop*vn;
+ struct iface*iface;
int i;
/* case 1 */
if (parent == spf_root) {
switch (dst->type) {
case LSA_TYPE_ROUTER:
- for (i = 0; i < lsa_num_links(dst); i++) {
- rtr_link = get_rtr_link(dst, i);
- if (rtr_link->type == LINK_TYPE_POINTTOPOINT &&
- ntohl(rtr_link->id) == parent->ls_id) {
+ if (rtr_link->type != LINK_TYPE_POINTTOPOINT)
+ fatalx("inconsistent SPF tree");
+ LIST_FOREACH(iface, &area->iface_list, entry) {
+ if (rtr_link->data == iface->addr.s_addr) {
calc_nexthop_add(dst, parent,
- rtr_link->data);
- break;
+ iface->dst.s_addr);
+ return;
}
}
- return;
+ fatalx("no interface found for interface");
case LSA_TYPE_NETWORK:
- for (i = 0; i < lsa_num_links(parent); i++) {
- rtr_link = get_rtr_link(parent, i);
-
Re: Network device driver KPI/ABI and TOE
On Sun, 6 Jan 2008, Robert Watson wrote: Hi, [cutting a long mail short and randomly replying;-)] I came across dev/cxgb/ulp/tom/cxgb_tcp_subr.c vs. netinet/tcp_subr.c and I am a bit worried with the way things are done atm. For those functions copied over there are only changes like: - tp = cxgb_tcp_drop(tp, ECONNABORTED); + tp = tcp_drop(tp, ECONNABORTED); - notify = cxgb_tcp_drop_syn_sent; + notify = tcp_drop_syn_sent; - tcp_gen_listen_close(tp); + tcp_offload_listen_close(tp); - (void) tcp_gen_reset(tp); + (void) tcp_output_reset(tp); and SYSCTL stuff. This is a "problem" for following reasons: - code duplication - if one changes netinet/tcp_subr.c one has to change foo4_tcp_subr.c as well - if more drivers are going to implement things that way it'll be even more code duplication. - developers will have to check lots of different places they might not expect in first place. - those things might interfere with our locking as well. I assume (without looking) the other files in the tom directory expose similar behavior. So this is a more general problem: we need to seriously think about abstracting our tcp_subr.c (and other) functions to avoid this duplication or at least integrate things better by other ways. This is mostly asking networking people to think about this so we can iteratively improve things. cxgb has done a good first step in that direction, now is the time to further hone things. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
traceroute AS path patch
Hi, The attached patch ports a traceroute functionality from FreeBSD called AS path. The concept is simple. On each hop we query a whois server to find the corresponding hop AS number. I think it doesn't hurt if we have this functionality. An example output: traceroute to freebsd.org (69.147.83.40), 64 hops max, 72 byte packets ... 7 [AS6453] if-2-1.core1.PV9-Lisbon.teleglobe.net (195.219.187.21) 35.105 ms 34.008 ms 35.334 ms 8 [AS6453] 195.219.144.5 (195.219.144.5) 63.880 ms 60.448 ms 60.809 ms 9 [AS6453] 195.219.144.10 (195.219.144.10) 138.593 ms 193.709 ms 173.415 ms 10 [AS7199] if-2-0.core1.NJY-Newark.teleglobe.net (216.6.63.10) 133.912 ms 134.393 ms 144.071 ms 11 [AS9557] if-3-1.mcore3.NJY-Newark.teleglobe.net (216.6.57.1) 135.600 ms 144.979 ms 168.247 ms 12 [AS9557] if-12-0-0-741.core4.AEQ-Ashburn.teleglobe.net (216.6.57.70) 180.346 ms 138.718 ms 138.927 ms 13 [AS6453] 64.86.85.38 (64.86.85.38) 142.745 ms 143.163 ms 143.358 ms 14 [AS26085] so-0-0-0.pat2.pao.yahoo.com (216.115.101.130) 252.417 ms 213.377 ms 212.859 ms 15 [AS26085] ge-0-1-0-p301.pat1.sjc.yahoo.com (216.115.106.147) 214.709 ms 213.198 ms 235.253 ms 16 [AS26085] g-1-0-0-p160.msr1.sp1.yahoo.com (216.115.107.61) 219.091 ms [AS26085] g-0-0-0-p170.msr2.sp1.yahoo.com (216.115.107.81) 217.650 ms [AS26085] g-1-0-0-p160.msr1.sp1.yahoo.com (216.115.107.61) 286.376 ms 17 [AS36752] ge-1-45.bas-b2.sp1.yahoo.com (209.131.32.49) 213.747 ms [AS36752] ge-1-41.bas-b2.sp1.yahoo.com (209.131.32.33) 274.140 ms [AS36752] ge-1-45.bas-b2.sp1.yahoo.com (209.131.32.49) 213.341 ms 18 [AS36752] freebsd.org (69.147.83.40) 214.386 ms 223.515 ms 212.548 ms What do you think? Regards. -- Rui Paulo traceroute.diff Description: Binary data ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tcp_mss 'cleanup'
Hi, as part of a larger patch I have done some changes to tcp_mss to "cleanup" things that I'd like to get in before going on: http://sources.zabbadoz.net/freebsd/patchset/20080217-tcp_mss-cleanup-02.diff The 'case 0' case is questionable if it's a better solution but it would save us the extra #ifdef INET6 and ? : logic there. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: traceroute AS path patch
On Feb 17, 2008 9:30 PM, Rui Paulo <[EMAIL PROTECTED]> wrote: > Hi, > The attached patch ports a traceroute functionality from FreeBSD > called AS path. > The concept is simple. On each hop we query a whois server to find the > corresponding hop AS number. > Cute feature! How are rfc 1918 addresses handled though? BTW, the manpage date is a bit ahead of its time :) Nuno ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: traceroute AS path patch
On Feb 17, 2008, at 10:30 PM, Nuno Antunes wrote: On Feb 17, 2008 9:30 PM, Rui Paulo <[EMAIL PROTECTED]> wrote: Hi, The attached patch ports a traceroute functionality from FreeBSD called AS path. The concept is simple. On each hop we query a whois server to find the corresponding hop AS number. Cute feature! How are rfc 1918 addresses handled though? Well, there's no specific code to handle them. 1 [AS0] 10.0.0.1 (10.0.0.1) 0.870 ms 0.544 ms 0.510 ms BTW, the manpage date is a bit ahead of its time :) Eheh, thanks. :-) -- Rui Paulo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: traceroute AS path patch
On Feb 17, 2008, at 9:30 PM, Rui Paulo wrote: Hi, The attached patch ports a traceroute functionality from FreeBSD called AS path. I mean, "ported from NetBSD". -- Rui Paulo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: traceroute AS path patch
Rui Paulo wrote: On Feb 17, 2008, at 9:30 PM, Rui Paulo wrote: Hi, The attached patch ports a traceroute functionality from FreeBSD called AS path. I mean, "ported from NetBSD". AS lookup is already in the NANOG traceroute in ports -- however I like the look of this patch better, it looks much cleaner. +1 from me. cheers, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Routing error messages from ppp
Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > % netstat -rn > Routing tables > > Internet: > DestinationGatewayFlagsRefs Use Netif Expire I left out a line here: default80.203.47.1UGS 1 3184881 tun0 > 80.203.47.180.203.243.180 UGH 12 tun0 > 127.0.0.1 127.0.0.1 UH 0 165970lo0 DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: traceroute AS path patch
> From: Rui Paulo <[EMAIL PROTECTED]> > Date: Sun, 17 Feb 2008 23:25:58 + > Sender: [EMAIL PROTECTED] > > > On Feb 17, 2008, at 9:30 PM, Rui Paulo wrote: > > > Hi, > > The attached patch ports a traceroute functionality from FreeBSD > > called AS path. > > I mean, "ported from NetBSD". Is this different from the version of traceroute in ports (net/traceroute)? Looks functionally much the same to me, but I have not looked to see if the code is the same. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpHT4BdkFK7B.pgp Description: PGP signature
Re: traceroute AS path patch
Sounds like a really nice feature! What version is this a patch against, fails totally on 6.2 here. Regards Steve - Original Message - From: "Rui Paulo" <[EMAIL PROTECTED]> The attached patch ports a traceroute functionality from FreeBSD called AS path. The concept is simple. On each hop we query a whois server to find the corresponding hop AS number. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network device driver KPI/ABI and TOE
You might want to check out sys/modules/cxgb/tom/Makefile. -Kip On Feb 17, 2008 1:24 PM, Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote: > On Sun, 6 Jan 2008, Robert Watson wrote: > > Hi, > > [cutting a long mail short and randomly replying;-)] > > I came across dev/cxgb/ulp/tom/cxgb_tcp_subr.c vs. netinet/tcp_subr.c > and I am a bit worried with the way things are done atm. For those > functions copied over there are only changes like: > > - tp = cxgb_tcp_drop(tp, ECONNABORTED); > + tp = tcp_drop(tp, ECONNABORTED); > > - notify = cxgb_tcp_drop_syn_sent; > + notify = tcp_drop_syn_sent; > > - tcp_gen_listen_close(tp); > + tcp_offload_listen_close(tp); > > - (void) tcp_gen_reset(tp); > + (void) tcp_output_reset(tp); > > and SYSCTL stuff. > > > This is a "problem" for following reasons: > - code duplication > - if one changes netinet/tcp_subr.c one has to change foo4_tcp_subr.c >as well > - if more drivers are going to implement things that way it'll be >even more code duplication. > - developers will have to check lots of different places they might >not expect in first place. > - those things might interfere with our locking as well. > > I assume (without looking) the other files in the tom directory expose > similar behavior. So this is a more general problem: > > we need to seriously think about abstracting our tcp_subr.c (and > other) functions to avoid this duplication or at least integrate > things better by other ways. > > This is mostly asking networking people to think about this so we can > iteratively improve things. cxgb has done a good first step in that > direction, now is the time to further hone things. > > > /bz > > -- > Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT > Software is harder than hardware so better get it right the first time. > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
