From owner-freebsd-net@FreeBSD.ORG Sun Jul 18 21:38:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1727116A4CE for ; Sun, 18 Jul 2004 21:38:52 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF7CD43D46 for ; Sun, 18 Jul 2004 21:38:51 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i6ILcM4q039314; Sun, 18 Jul 2004 17:38:22 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i6ILcMpL039311; Sun, 18 Jul 2004 17:38:22 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 18 Jul 2004 17:38:22 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Don Bowman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "'net@freebsd.org'" Subject: Re: Question on SOCK_RAW, implement a bpf->other host tee X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2004 21:38:52 -0000 On Sat, 17 Jul 2004, Don Bowman wrote: > I'm trying to implement a 'tee' which reads from bpf, and sends matching > packets to another layer-2 adjacent host. Just FYI, I would normally do this by writing back out to BPF on the interface you're "teeing" to, perhaps with some rewriting of the ethernet layer header. Since I don't have a big picture of what your application is actually doing, I can't speak to the details there :-). > I'm doing this with SOCK_RAW to try and write the packet back out. The > 'sendto' passes, but i don't see a packet anywhere. > > Am i correct that i can hand an arbitrarily crafted IP packet into > sendto, and the stack will write the ethernet header on, pick an > interface, etc, based on the address in the sendto? Hmm. I'm not 100% sure that this is correct. When you don't set IP_HDRINCL, the raw IP output code will indeed do the route lookup on the requested address, as well as insert an IP header that includes the requested address. However, when you use IP_HDRINCL to provide your own IP address, I believe that the target address argument to sendto() will be ignored, and the address in the IP header you provide used as the destination instead. What could well be happening is that you're re-injecting the packet at the IP forwarding layer, and it is being forwarded to the original destination IP (possibly localhost) and processed as a dup packet. I.e., you are making copies of the packet, but they're not being sent where you think. If you're sniffing packets destined for the local IP, you might well be able to see the tee'd packets by running tcpdump on lo0. > I have swapped the ip_len, ip_off fields. Are you sure you need to do this? I thought BPF/PCAP provided those fields in network byte order already, in which case you shouldn't need to touch these fields unless you need to adjust them. Also, I notice that you don't appear to be initializing the 'sin_len' field of struct sockaddr_in, which should be set to sizeof(to) when you initialize the structure. Generally speaking, the notion of "tee" is a little poorly defined. I think what you want to do is what I suggest above -- use BPF to write the packet out another interface, and do the link layer routing yourself, rewriting packet header fields if you want to. That is, basically write the new target ethernet address into the BPF layer ethernet header, and write it out on a BPF device attached to the network interface you're teeing to. This will leave all the IP layer stuff intact. I've previously written a BPF layer bridging application that uses this technique to do filtered bridging and stateful TCP transformation in user space. You don't get the performance of the kernel, but it's a lot easier to debug. One caution: be careful of bridging loops and the like. If you do mean to be changing the IP layer addresses, remember that you'll need to recalculate header checksums for IP, TCP/UDP, etc. If you change any other IP layer fields, you may need to just recalculate the IP layer checksum. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > The program I have is below. This is on 4.7. > The handler gets called, the packet there looks > correct, no error on any system call, yet no > output :( > > Suggestions? > > /* > * Copyright 2004 Sandvine Incorporated. All rights reserved > */ > > #include > #include > #include > #include > #include > #include > #include > #include > > void > usage(const char *name) > { > fprintf(stderr, "Usage: %s [-I input_interface] [-O output_interface] > [-i output_ip(arp for mac)] [-v]\n", name); > exit(1); > } > > typedef struct > { > int s; > struct in_addr output_ip; > } > context; > > static int verbose; > > static void > handler(unsigned char *ct, > const struct pcap_pkthdr *hdr, > const unsigned char *pkt) > { > struct ip *ip = (struct ip *)(pkt + 14); > context *ctxt = (context *)ct; > struct sockaddr_in to; > memset(&to,0,sizeof(to)); > to.sin_family = AF_INET; > to.sin_addr = ctxt->output_ip; > if (verbose) > { > fprintf(stderr, "Send %d byte packet\n", hdr->len); > } > ip->ip_len = htons(ip->ip_len); > ip->ip_off = htons(ip->ip_off); > if (sendto(ctxt->s, > ip, > hdr->len-14, > 0, > (struct sockaddr *)&to, > sizeof(to)) != (hdr->len-14) ) > { > err(1, "sendto"); > } > } > > static int > doit(const char *input_interface, > const char *output_interface, > struct in_addr output_ip) > { > char errbuf[PCAP_ERRBUF_SIZE]; > pcap_t *in_d, *out_d; > context ctxt; > int on = 1; > struct bpf_program fp; > > in_d = pcap_open_live((char *)input_interface, 1600, 1, 20, errbuf); > if (in_d == 0) > { > errx(1, "open of %s failed: %s", input_interface, errbuf); > } > > ctxt.output_ip.s_addr = htonl(output_ip.s_addr); > ctxt.s = socket(PF_INET, SOCK_RAW, IPPROTO_RAW); > if (ctxt.s < 0) > errx(1, "can't open raw socket"); > if (setsockopt(ctxt.s, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on)) > < 0) > { > err(1,"setsockopt"); > } > > memset(&fp,0,sizeof(fp));/ > if (pcap_compile(in_d, &fp, "ip", 0, 0xfffffff0) < 0) > { > errx(1, "failed to compile: %s",pcap_geterr(in_d)); > } > if (pcap_setfilter(in_d, &fp) < 0) > { > errx(1, "failed to set filter"); > } > > pcap_loop(in_d, -1, handler, (unsigned char *)&ctxt); > } > > int > main(int argc, char *argv[]) > { > int ch; > char *input_interface = "ipfw0"; > char *output_interface = "em2"; > struct in_addr output_ip; > output_ip.s_addr = 0; > > while ((ch = getopt(argc, argv, "I:O:i:vh?")) != -1) > { > switch (ch) > { > case 'I': > input_interface = optarg; > break; > case 'O': > output_interface = optarg; > break; > case 'i': > if (inet_aton(optarg,&output_ip) < 0) > { > errx(1, "unknown ip %s", optarg); > } > break; > case 'v': > verbose = 1; > break; > case 'h': > case '?': > default: > usage(argv[0]); > } > } > if (verbose) > fprintf(stderr, "%s->%s(%s)\n", > input_interface,output_interface,inet_ntoa(output_ip)); > return doit(input_interface,output_interface,output_ip); > } > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Jul 18 22:19:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D41AE16A4CE; Sun, 18 Jul 2004 22:19:29 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DC1743D45; Sun, 18 Jul 2004 22:19:29 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 3565A65473; Sun, 18 Jul 2004 23:19:27 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 89263-02; Sun, 18 Jul 2004 23:19:26 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 5DC9D653E6; Sun, 18 Jul 2004 23:19:26 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 26ECA61AA; Sun, 18 Jul 2004 23:19:25 +0100 (BST) Date: Sun, 18 Jul 2004 23:19:25 +0100 From: Bruce M Simpson To: Robert Watson Message-ID: <20040718221925.GE87575@empiric.dek.spc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: "'net@freebsd.org'" Subject: Re: Question on SOCK_RAW, implement a bpf->other host tee X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2004 22:19:29 -0000 On Sun, Jul 18, 2004 at 05:38:22PM -0400, Robert Watson wrote: > > I have swapped the ip_len, ip_off fields. > > Are you sure you need to do this? I thought BPF/PCAP provided those > fields in network byte order already, in which case you shouldn't need to > touch these fields unless you need to adjust them. I think Don is referring to the fact that IP_HDRINCL in our stack expects to see these fields in host byte order (as per my update of the ip(4) manual page quite recently). Raw socket stuff being different from bpf stuff. BMS From owner-freebsd-net@FreeBSD.ORG Mon Jul 19 04:44:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7BF116A4CE for ; Mon, 19 Jul 2004 04:44:05 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 888E243D2F for ; Mon, 19 Jul 2004 04:44:05 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i6J4hZkI042785; Mon, 19 Jul 2004 00:43:35 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i6J4hZan042782; Mon, 19 Jul 2004 00:43:35 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 19 Jul 2004 00:43:35 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bruce M Simpson In-Reply-To: <20040718221925.GE87575@empiric.dek.spc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "'net@freebsd.org'" Subject: Re: Question on SOCK_RAW, implement a bpf->other host tee X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2004 04:44:06 -0000 On Sun, 18 Jul 2004, Bruce M Simpson wrote: > On Sun, Jul 18, 2004 at 05:38:22PM -0400, Robert Watson wrote: > > > I have swapped the ip_len, ip_off fields. > > > > Are you sure you need to do this? I thought BPF/PCAP provided those > > fields in network byte order already, in which case you shouldn't need to > > touch these fields unless you need to adjust them. > > I think Don is referring to the fact that IP_HDRINCL in our stack > expects to see these fields in host byte order (as per my update of the > ip(4) manual page quite recently). Raw socket stuff being different from > bpf stuff. Yes, indeed I misunderstood. However, I think my explanation for the packets not arriving where expected probably remains valid. The only other thing that came to mind was dealing with ip_id -- when the raw IP code sees an ID of 0, it will substitute its own value. I'm not sure how many packets on the wire end up having ID's of zero, but that will be a case where the packet is modified by virtue of being resent using the raw socket interface. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Mon Jul 19 11:01:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FEE816A4DF for ; Mon, 19 Jul 2004 11:01:50 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ABE543D49 for ; Mon, 19 Jul 2004 11:01:50 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i6JB1n8X015468 for ; Mon, 19 Jul 2004 11:01:49 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i6JB1nq8015462 for freebsd-net@freebsd.org; Mon, 19 Jul 2004 11:01:49 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 19 Jul 2004 11:01:49 GMT Message-Id: <200407191101.i6JB1nq8015462@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2004 11:01:50 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [1999/11/26] kern/15095 net TCP's advertised window is not scaled imm o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 3 problems total. From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 02:12:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A9E916A4CE; Tue, 20 Jul 2004 02:12:39 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB92443D39; Tue, 20 Jul 2004 02:12:38 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 16C4A2F961; Mon, 19 Jul 2004 22:12:38 -0400 (EDT) Date: Mon, 19 Jul 2004 22:12:38 -0400 From: James To: Andre Oppermann Message-ID: <20040720021237.GA74977@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2004 02:12:39 -0000 Andre, et al: Previously, in "My planned work on networking stack" thread, Andre made a patch which allows loose-check uRPF verification using ipfw2. The command syntax is versrcreach as opposed to verrevpath. The versrcreach simply checks if the source address has a route other than default. In other words, pass the packet if the source address is reachable via any interface available where there is a route for. This is useful in multihomed BGP environment (mostly for service providers using FreeBSD as routing platform). The message in which Andre posted patch is below this email, quoted. Anyhow, getting straight to business: The uRPF loose-check implementation by the industry vendors, at least on Cisco and possibly Juniper, will fail the check if the route of the source address is pointed to Null0 (on Juniper, discard or reject route). What this means is, even if uRPF Loose-check finds the route, if the route is pointed to blackhole, uRPF loose-check must fail. This allows people to utilize uRPF loose-check mode as a pseudo-packet-firewall without using any manual filtering configuration -- one can simply inject a IGP or BGP prefix with next-hop set to a static route that directs to null/discard facility. This results in uRPF Loose-check failing on all packets with source addresses that are within the range of the nullroute. Under verify_path() in ip_fw2.c patch Andre provided, I'd like to propose possibly including the following line of change I'm thinking about in my head right now. /* if no ifp provided, check if rtentry is not default route */ if (ifp == NULL && satosin(rt_key(ro.ro_rt))->sin_addr.s_addr == INADDR_ANY) { RTFREE(ro.ro_rt); return 0; } + /* by this point a route is found. check if this is pointed + * to blackhole/reject */ + if (ifp == NULL && ro.ro_rt->rt_flags & (RTF_REJECT|RTF_BLACKHOLE) ) { + RTFREE(ro.ro_rt); + return 0; + } Haven't tested this yet, but will do tomorrow after I finish some other stuff I need done before rebooting w/ a test kernel. Anyway the idea is to fail the check if the route has RTF_REJECT or RTF_BLACKHOLE flag, under loose-check (ifp set to NULL) operation, which is an easy straight forward change. Thanks, -J -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net > > Here you go: > > http://www.nrg4u.com/freebsd/ipfw_versrcreach.diff > > This one implements the standard functionality, the definition of an > interface through which it has to be reachable is not (yet) supported. > > Using this option only makes sense when you don't have a default route > which naturally always matches. So this is useful for machines acting > as routers with a default-free view of the entire Internet as common > when running a BGP daemon (Zebra/Quagga or OpenBSD bgpd). > > One useful way of enabling it globally on a router looks like this: > > ipfw add xxxx deny ip from any to any not versrcreach > > or for an individual interface only: > > ipfw add xxxx deny ip from any to any not versrcreach recv fxp0 > > I'd like to get some feedback (and a man page draft) before I commit it > to -CURRENT. > > -- > Andre From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 07:18:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF90A16A4CE; Tue, 20 Jul 2004 07:18:03 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1141943D5A; Tue, 20 Jul 2004 07:18:03 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i6K7HxG7054696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2004 11:18:00 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i6K7Hxgm054695; Tue, 20 Jul 2004 11:17:59 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 20 Jul 2004 11:17:59 +0400 From: Gleb Smirnoff To: James Message-ID: <20040720071759.GA54281@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , James , Andre Oppermann , freebsd-net@freebsd.org References: <20040720021237.GA74977@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040720021237.GA74977@scylla.towardex.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: Andre Oppermann Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2004 07:18:04 -0000 On Mon, Jul 19, 2004 at 10:12:38PM -0400, James wrote: J> /* if no ifp provided, check if rtentry is not default route */ J> if (ifp == NULL && J> satosin(rt_key(ro.ro_rt))->sin_addr.s_addr == INADDR_ANY) { J> RTFREE(ro.ro_rt); J> return 0; J> } J> J> + /* by this point a route is found. check if this is pointed J> + * to blackhole/reject */ J> + if (ifp == NULL && ro.ro_rt->rt_flags & (RTF_REJECT|RTF_BLACKHOLE) ) { J> + RTFREE(ro.ro_rt); J> + return 0; J> + } J> J> J> Haven't tested this yet, but will do tomorrow after I finish some other stuff J> I need done before rebooting w/ a test kernel. J> Anyway the idea is to fail the check if the route has RTF_REJECT or J> RTF_BLACKHOLE flag, under loose-check (ifp set to NULL) operation, which is J> an easy straight forward change. Seems reasonable from my viewpoint. P.S. GNU zebra null-routes into lo0, always setting RTF_BLACKHOLE flag. What software uses RTF_REJECT flag? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 08:04:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D71F116A4CE for ; Tue, 20 Jul 2004 08:04:42 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11E3F43D45 for ; Tue, 20 Jul 2004 08:04:42 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 23589 invoked from network); 20 Jul 2004 08:02:38 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 Jul 2004 08:02:38 -0000 Message-ID: <40FCD21B.40CB83ED@freebsd.org> Date: Tue, 20 Jul 2004 10:04:43 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James References: <20040720021237.GA74977@scylla.towardex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2004 08:04:43 -0000 James wrote: > > Andre, et al: > > Previously, in "My planned work on networking stack" thread, Andre made a patch > which allows loose-check uRPF verification using ipfw2. The command syntax is > versrcreach as opposed to verrevpath. The versrcreach simply checks if the > source address has a route other than default. In other words, pass the packet > if the source address is reachable via any interface available where there is a > route for. This is useful in multihomed BGP environment (mostly for service > providers using FreeBSD as routing platform). The message in which Andre posted > patch is below this email, quoted. > > Anyhow, getting straight to business: > The uRPF loose-check implementation by the industry vendors, at least on Cisco > and possibly Juniper, will fail the check if the route of the source address > is pointed to Null0 (on Juniper, discard or reject route). What this means is, > even if uRPF Loose-check finds the route, if the route is pointed to blackhole, > uRPF loose-check must fail. This allows people to utilize uRPF loose-check mode > as a pseudo-packet-firewall without using any manual filtering configuration -- > one can simply inject a IGP or BGP prefix with next-hop set to a static route > that directs to null/discard facility. This results in uRPF Loose-check failing > on all packets with source addresses that are within the range of the nullroute. > > Under verify_path() in ip_fw2.c patch Andre provided, I'd like to propose > possibly including the following line of change I'm thinking about in my head > right now. > > /* if no ifp provided, check if rtentry is not default route */ > if (ifp == NULL && > satosin(rt_key(ro.ro_rt))->sin_addr.s_addr == INADDR_ANY) { > RTFREE(ro.ro_rt); > return 0; > } > > + /* by this point a route is found. check if this is pointed > + * to blackhole/reject */ > + if (ifp == NULL && ro.ro_rt->rt_flags & (RTF_REJECT|RTF_BLACKHOLE) ) { > + RTFREE(ro.ro_rt); > + return 0; > + } > > Haven't tested this yet, but will do tomorrow after I finish some other stuff > I need done before rebooting w/ a test kernel. Tell me what the test results are. > Anyway the idea is to fail the check if the route has RTF_REJECT or > RTF_BLACKHOLE flag, under loose-check (ifp set to NULL) operation, which is > an easy straight forward change. How do you set the RTF_REJECT or RTF_BLACKHOLE flags on a route with Zebra/ Quagga and friends? -- Andre > Thanks, > -J > > -- > James Jun TowardEX Technologies, Inc. > Technical Lead Network Design, Consulting, IT Outsourcing > james@towardex.com Boston-based Colocation & Bandwidth Services > cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net > > > > > Here you go: > > > > http://www.nrg4u.com/freebsd/ipfw_versrcreach.diff > > > > This one implements the standard functionality, the definition of an > > interface through which it has to be reachable is not (yet) supported. > > > > Using this option only makes sense when you don't have a default route > > which naturally always matches. So this is useful for machines acting > > as routers with a default-free view of the entire Internet as common > > when running a BGP daemon (Zebra/Quagga or OpenBSD bgpd). > > > > One useful way of enabling it globally on a router looks like this: > > > > ipfw add xxxx deny ip from any to any not versrcreach > > > > or for an individual interface only: > > > > ipfw add xxxx deny ip from any to any not versrcreach recv fxp0 > > > > I'd like to get some feedback (and a man page draft) before I commit it > > to -CURRENT. > > > > -- > > Andre From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 09:03:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D3A916A4CE; Tue, 20 Jul 2004 09:03:38 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93B1643D2D; Tue, 20 Jul 2004 09:03:37 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i6K93X8X055680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2004 13:03:34 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i6K93XTD055679; Tue, 20 Jul 2004 13:03:33 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 20 Jul 2004 13:03:32 +0400 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20040720090332.GB55577@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Andre Oppermann , James , freebsd-net@freebsd.org References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <40FCD21B.40CB83ED@freebsd.org> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: James Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2004 09:03:38 -0000 On Tue, Jul 20, 2004 at 10:04:43AM +0200, Andre Oppermann wrote: A> > Anyway the idea is to fail the check if the route has RTF_REJECT or A> > RTF_BLACKHOLE flag, under loose-check (ifp set to NULL) operation, which is A> > an easy straight forward change. A> A> How do you set the RTF_REJECT or RTF_BLACKHOLE flags on a route with Zebra/ A> Quagga and friends? When you have "ip route x.x.x.x/y Null0" in configuration this actually means adding route to lo0 with RTF_BLACKHOLE flag. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 00:32:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 331B816A4CE; Wed, 21 Jul 2004 00:32:43 +0000 (GMT) Received: from CPE000103d44c07-CM000f9f7ae88c.cpe.net.cable.rogers.com (CPE000103d44c07-CM000f9f7ae88c.cpe.net.cable.rogers.com [69.193.41.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E16FC43D39; Wed, 21 Jul 2004 00:32:42 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from localhost (localhost [127.0.0.1]) with ESMTP id AE55D2954C4; Tue, 20 Jul 2004 20:32:44 -0400 (EDT) Received: from CPE000103d44c07-CM000f9f7ae88c.cpe.net.cable.rogers.com ([127.0.0.1])10024) with ESMTP id 00508-02; Tue, 20 Jul 2004 20:32:42 -0400 (EDT) Received: from 192.168.0.1 (localhost [127.0.0.1]) with ESMTP id 869422954C3; Tue, 20 Jul 2004 20:32:42 -0400 (EDT) Received: from 192.168.0.200 (SquirrelMail authenticated user mikej); by 192.168.0.1 with HTTP; Tue, 20 Jul 2004 20:32:42 -0400 (EDT) Message-ID: <1407.192.168.0.200.1090369962.squirrel@192.168.0.200> Date: Tue, 20 Jul 2004 20:32:42 -0400 (EDT) From: "Mike Jakubik" To: freebsd-current@freebsd.org, freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at fbsd.wettoast.net Subject: NATD no longer works for outgoing PPTP VPN? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 00:32:43 -0000 Hello, I have recently discovered, after long periods of trying to debug a VPN server, that i can not establish PPTP VPN connections any more. The culprit seems to be natd not forwarding GRE properly. I have tried adding a 'redirect_proto gre' option to natd, but same behaviour occurs. I could swear that not too long ago all my PPTP connection worked fine, as i have a few clients defined in my windows pc. I have tried 3 different VPN server, ranging from Windows 2000 server to FBSD with MPD, none work. Plugging Internet directly to my PC works fine. Here is what the setup looks like: Me (Windows XP) FreeBSD 5-C w/ NATD Internet VPN server 192.168.0.200 192.168.0.1 69.193.41.53 66.11.183.182 Here is rc.conf --- gateway_enable="YES" natd_enable="YES" natd_interface="xl0" natd_flags="-f /etc/natd.conf" Here is natd.conf: --- interface xl0 dynamic yes use_sockets yes same_ports yes redirect_port tcp win2000:3389 3389 #redirect_proto gre win2000 And here is a log from natd -v when trying to estabish a VPN connection (it looks like GRE is not being aliased correctly, windows pc just sits at 'Verifying username...'): --- natd[32158]: Aliasing to 69.193.41.53, mtu 1500 bytes Out {default} 0000ffff[TCP] [TCP] 192.168.0.200:1108 -> 66.11.183.182:1723 aliased to [TCP] 69.193.41.53:1108 -> 66.11.183.182:1723 In {default} 0000ffff[TCP] [TCP] 66.11.183.182:1723 -> 69.193.41.53:1108 aliased to [TCP] 66.11.183.182:1723 -> 192.168.0.200:1108 Out {default} 0000ffff[TCP] [TCP] 192.168.0.200:1108 -> 66.11.183.182:1723 aliased to [TCP] 69.193.41.53:1108 -> 66.11.183.182:1723 In {default} 0000ffff[TCP] [TCP] 66.11.183.182:1723 -> 69.193.41.53:1108 aliased to [TCP] 66.11.183.182:1723 -> 192.168.0.200:1108 Out {default} 0000ffff[TCP] [TCP] 192.168.0.200:1108 -> 66.11.183.182:1723 aliased to [TCP] 69.193.41.53:1108 -> 66.11.183.182:1723 In {default} 0000ffff[TCP] [TCP] 66.11.183.182:1723 -> 69.193.41.53:1108 aliased to [TCP] 66.11.183.182:1723 -> 192.168.0.200:1108 In {default} 0000ffff[47] [47] 66.11.183.182 -> 69.193.41.53 aliased to [47] 66.11.183.182 -> 69.193.41.53 Out {default} 0000ffff[TCP] [TCP] 192.168.0.200:1108 -> 66.11.183.182:1723 aliased to [TCP] 69.193.41.53:1108 -> 66.11.183.182:1723 Out {default} 0000ffff[47] [47] 192.168.0.200 -> 66.11.183.182 aliased to [47] 192.168.0.200 -> 66.11.183.182 In {default} 0000ffff[TCP] [TCP] 66.11.183.182:1723 -> 69.193.41.53:1108 aliased to [TCP] 66.11.183.182:1723 -> 192.168.0.200:1108 Out {default} 0000ffff[47] [47] 192.168.0.200 -> 66.11.183.182 aliased to [47] 192.168.0.200 -> 66.11.183.182 In {default} 0000ffff[47] [47] 66.11.183.182 -> 69.193.41.53 aliased to [47] 66.11.183.182 -> 69.193.41.53 In {default} 0000ffff[47] [47] 66.11.183.182 -> 69.193.41.53 aliased to [47] 66.11.183.182 -> 69.193.41.53 Out {default} 0000ffff[47] [47] 192.168.0.200 -> 66.11.183.182 aliased to [47] 192.168.0.200 -> 66.11.183.182 In {default} 0000ffff[47] [47] 66.11.183.182 -> 69.193.41.53 aliased to [47] 66.11.183.182 -> 69.193.41.53 In {default} 0000ffff[47] [47] 66.11.183.182 -> 69.193.41.53 aliased to [47] 66.11.183.182 -> 69.193.41.53 Out {default} 0000ffff[47] [47] 192.168.0.200 -> 66.11.183.182 aliased to [47] 192.168.0.200 -> 66.11.183.182 In {default} 0000ffff[47] [47] 66.11.183.182 -> 69.193.41.53 aliased to [47] 66.11.183.182 -> 69.193.41.53 In {default} 0000ffff[47] [47] 66.11.183.182 -> 69.193.41.53 aliased to [47] 66.11.183.182 -> 69.193.41.53 Out {default} 0000ffff[47] [47] 192.168.0.200 -> 66.11.183.182 aliased to [47] 192.168.0.200 -> 66.11.183.182 In {default} 0000ffff[47] [47] 66.11.183.182 -> 69.193.41.53 aliased to [47] 66.11.183.182 -> 69.193.41.53 In {default} 0000ffff[47] [47] 66.11.183.182 -> 69.193.41.53 aliased to [47] 66.11.183.182 -> 69.193.41.53 Out {default} 0000ffff[47] [47] 192.168.0.200 -> 66.11.183.182 aliased to [47] 192.168.0.200 -> 66.11.183.182 In {default} 0000ffff[47] [47] 66.11.183.182 -> 69.193.41.53 aliased to [47] 66.11.183.182 -> 69.193.41.53 In {default} 0000ffff[TCP] [TCP] 66.11.183.182:1723 -> 69.193.41.53:1108 aliased to [TCP] 66.11.183.182:1723 -> 192.168.0.200:1108 Out {default} 0000ffff[TCP] [TCP] 192.168.0.200:1108 -> 66.11.183.182:1723 aliased to [TCP] 69.193.41.53:1108 -> 66.11.183.182:1723 In {default} 0000ffff[TCP] [TCP] 66.11.183.182:1723 -> 69.193.41.53:1108 aliased to [TCP] 66.11.183.182:1723 -> 192.168.0.200:1108 In {default} 0000ffff[TCP] [TCP] 66.11.183.182:1723 -> 69.193.41.53:1108 aliased to [TCP] 66.11.183.182:1723 -> 192.168.0.200:1108 Out {default} 0000ffff[TCP] [TCP] 192.168.0.200:1108 -> 66.11.183.182:1723 aliased to [TCP] 69.193.41.53:1108 -> 66.11.183.182:1723 In {default} 0000ffff[TCP] [TCP] 66.11.183.182:1723 -> 69.193.41.53:1108 aliased to [TCP] 66.11.183.182:1723 -> 192.168.0.200:1108 Thank You. From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 02:04:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6C7A16A4CE; Wed, 21 Jul 2004 02:04:19 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DBC543D1F; Wed, 21 Jul 2004 02:04:19 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 239C82F8FF; Tue, 20 Jul 2004 22:04:19 -0400 (EDT) Date: Tue, 20 Jul 2004 22:04:19 -0400 From: James To: Andre Oppermann Message-ID: <20040721020418.GA53214@scylla.towardex.com> References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40FCD21B.40CB83ED@freebsd.org> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org cc: James Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 02:04:20 -0000 [Note: aggregate reply] Hi, > Tell me what the test results are. I just tested this out on the lab freebsd router using that exact line I emailed earlier in ip_fw2.c. And it is working (test result is pasted bottom of this email) on both -blackhole and -reject flags :) [from Gleb] > P.S. GNU zebra null-routes into lo0, always setting RTF_BLACKHOLE flag. What > software uses RTF_REJECT flag? The "ip route a.b.c.d/cidr Null0" installs a blackhole route. However if you "ip route a.b.c.d/32 reject" (at least on Quagga 0.96.5), it will install -reject route with -iface pointing to lo0. It is worth noting that there is rather a buggy implementation on Quagga (havent tested on zebra) where recursive routing does not work with Null0. If you have a static route for example: ip route 192.0.2.0/24 Null0 on Quagga config, and if you have BGP injecting a remote triggered null-route using next-hop of 192.0.2.x, it will not install that onto kernel table. However, the good news is it is simple enough issue to fix. Under zebra_rib.c, simply ensure that NEXTHOP_TYPE_BLACKHOLE gets installed using nexthop_blackhole_add(rib) instead of having it search for recursive nexthop on a blackhole/non-existant "Null0" ifp. Quagga-dev is a better place for discussing this so I'll continue this discussion there hopefully, or on offlist if anyone is interested. Furthermore, it is right that RTF_REJECT is almost not used. It is also good to note that even on Juniper, almost every network operator uses discard, not reject. Same deal with Cisco, most ensure ICMP unreachables are not generated with a packet hitting Null0. However, from time to time, REJECT becomes a quite a bit useful tool for debugging the network. REJECT becomes very valuable if you want to temporarily use backscatter search technique to find the source throughout your network, as routers with reject route will emit icmp signals at you. [Test Outputs] Test #1: Route 1.1.1.2/32 to a dummy interface and test uRPF. This should permit the packet. lab-gw# route add -host 1.1.1.2/32 -iface ds0 add host 1.1.1.2: gateway ds0 lab-gw# ipfw zero Accounting cleared. workstation# ifconfig lo0 inet 1.1.1.2/32 alias workstation# ping -S 1.1.1.2 3.3.3.3 PING 3.3.3.3 (3.3.3.3) from 1.1.1.2: 56 data bytes ^C lab-gw# ipfw show 20001 | grep versrc 20001 0 0 deny ip from any to any not versrcreach Packets are permitted through as 1.1.1.2/32 is a valid host route, to a dummy interface. -- Test #2: Route 1.1.1.2/32 with RTF_BLACKHOLE. This should kill the packet. lab-gw# route delete -host 1.1.1.2 delete host 1.1.1.2 lab-gw# route add -host 1.1.1.2/32 -iface lo0 -blackhole add host 1.1.1.2: gateway lo0 lab-gw# ipfw show 20001 | grep versrc 20001 0 0 deny ip from any to any not versrcreach workstation# ping -S 1.1.1.2 3.3.3.3 PING 3.3.3.3 (3.3.3.3) from 1.1.1.2: 56 data bytes ^C lab-gw# ipfw show 20001 | grep versrc 20001 2 168 deny ip from any to any not versrcreach lab-gw# ipfw show 20001 | grep versrc 20001 3 252 deny ip from any to any not versrcreach lab-gw# ipfw show 20001 | grep versrc 20001 4 336 deny ip from any to any not versrcreach Loose-check uRPF is failing as expected and packets are being denied sourced from 1.1.1.2/32 RTF_BLACKHOLE. -- Test #3: Route 1.1.1.2/32 with RTF_REJECT. This should kill the packet as well. lab-gw# route add -host 1.1.1.2/32 -iface lo0 -reject add host 1.1.1.2: gateway lo0 lab-gw# ipfw zero Accounting cleared. lab-gw# ipfw show 20001 | grep versrc 20001 0 0 deny ip from any to any not versrcreach workstation# ping -S 1.1.1.2 3.3.3.3 PING 3.3.3.3 (3.3.3.3) from 1.1.1.2: 56 data bytes ^C lab-gw# ipfw show 20001 | grep versrc 20001 3 252 deny ip from any to any not versrcreach lab-gw# ipfw show 20001 | grep versrc 20001 4 336 deny ip from any to any not versrcreach lab-gw# ipfw show 20001 | grep versrc 20001 4 336 deny ip from any to any not versrcreach uRPF is again failing. Packets are being dropped as exactly as expected. -J -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 10:20:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B08116A4CE for ; Wed, 21 Jul 2004 10:20:22 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8248743D2F for ; Wed, 21 Jul 2004 10:20:21 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 29891 invoked from network); 21 Jul 2004 10:18:06 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Jul 2004 10:18:06 -0000 Message-ID: <40FE4367.AA7B0A7F@freebsd.org> Date: Wed, 21 Jul 2004 12:20:23 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> <20040721020418.GA53214@scylla.towardex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: James Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 10:20:22 -0000 James wrote: > > [Note: aggregate reply] > > Hi, > > > Tell me what the test results are. > > I just tested this out on the lab freebsd router using that exact line I > emailed earlier in ip_fw2.c. > > And it is working (test result is pasted bottom of this email) on both > -blackhole and -reject flags :) James, it just occured to me; but what is the purpose of versrcreach denying a packet that will be discarded a few cycles later anyway? When I mark a route with -reject I want the ICMPs go out and still use the versrcreach functionality in ipfw. So I don't think this is something that should be included into ipfw's versrcreach because it is redundant. -- Andre > [from Gleb] > > P.S. GNU zebra null-routes into lo0, always setting RTF_BLACKHOLE flag. What > > software uses RTF_REJECT flag? > > The "ip route a.b.c.d/cidr Null0" installs a blackhole route. However if you > "ip route a.b.c.d/32 reject" (at least on Quagga 0.96.5), it will install > -reject route with -iface pointing to lo0. > > It is worth noting that there is rather a buggy implementation on Quagga (havent > tested on zebra) where recursive routing does not work with Null0. If you have > a static route for example: ip route 192.0.2.0/24 Null0 on Quagga config, and > if you have BGP injecting a remote triggered null-route using next-hop of > 192.0.2.x, it will not install that onto kernel table. However, the good news is > it is simple enough issue to fix. Under zebra_rib.c, simply ensure that > NEXTHOP_TYPE_BLACKHOLE gets installed using nexthop_blackhole_add(rib) instead > of having it search for recursive nexthop on a blackhole/non-existant "Null0" > ifp. Quagga-dev is a better place for discussing this so I'll continue this > discussion there hopefully, or on offlist if anyone is interested. > > Furthermore, it is right that RTF_REJECT is almost not used. It is also good > to note that even on Juniper, almost every network operator uses discard, not > reject. Same deal with Cisco, most ensure ICMP unreachables are not generated > with a packet hitting Null0. However, from time to time, REJECT becomes a quite > a bit useful tool for debugging the network. REJECT becomes very valuable if > you want to temporarily use backscatter search technique to find the source > throughout your network, as routers with reject route will emit icmp signals at > you. > > [Test Outputs] > Test #1: Route 1.1.1.2/32 to a dummy interface and test uRPF. This should permit > the packet. > > lab-gw# route add -host 1.1.1.2/32 -iface ds0 > add host 1.1.1.2: gateway ds0 > lab-gw# ipfw zero > Accounting cleared. > > workstation# ifconfig lo0 inet 1.1.1.2/32 alias > workstation# ping -S 1.1.1.2 3.3.3.3 > PING 3.3.3.3 (3.3.3.3) from 1.1.1.2: 56 data bytes > ^C > > lab-gw# ipfw show 20001 | grep versrc > 20001 0 0 deny ip from any to any not versrcreach > > Packets are permitted through as 1.1.1.2/32 is a valid host route, to a dummy > interface. > > -- > Test #2: Route 1.1.1.2/32 with RTF_BLACKHOLE. This should kill the packet. > > lab-gw# route delete -host 1.1.1.2 > delete host 1.1.1.2 > lab-gw# route add -host 1.1.1.2/32 -iface lo0 -blackhole > add host 1.1.1.2: gateway lo0 > lab-gw# ipfw show 20001 | grep versrc > 20001 0 0 deny ip from any to any not versrcreach > > workstation# ping -S 1.1.1.2 3.3.3.3 > PING 3.3.3.3 (3.3.3.3) from 1.1.1.2: 56 data bytes > ^C > > lab-gw# ipfw show 20001 | grep versrc > 20001 2 168 deny ip from any to any not versrcreach > lab-gw# ipfw show 20001 | grep versrc > 20001 3 252 deny ip from any to any not versrcreach > lab-gw# ipfw show 20001 | grep versrc > 20001 4 336 deny ip from any to any not versrcreach > > Loose-check uRPF is failing as expected and packets are being denied sourced > from 1.1.1.2/32 RTF_BLACKHOLE. > > -- > Test #3: Route 1.1.1.2/32 with RTF_REJECT. This should kill the packet as > well. > > lab-gw# route add -host 1.1.1.2/32 -iface lo0 -reject > add host 1.1.1.2: gateway lo0 > lab-gw# ipfw zero > Accounting cleared. > lab-gw# ipfw show 20001 | grep versrc > 20001 0 0 deny ip from any to any not versrcreach > > workstation# ping -S 1.1.1.2 3.3.3.3 > PING 3.3.3.3 (3.3.3.3) from 1.1.1.2: 56 data bytes > ^C > > lab-gw# ipfw show 20001 | grep versrc > 20001 3 252 deny ip from any to any not versrcreach > lab-gw# ipfw show 20001 | grep versrc > 20001 4 336 deny ip from any to any not versrcreach > lab-gw# ipfw show 20001 | grep versrc > 20001 4 336 deny ip from any to any not versrcreach > > uRPF is again failing. Packets are being dropped as exactly as expected. > > -J > -- > James Jun TowardEX Technologies, Inc. > Technical Lead Network Design, Consulting, IT Outsourcing > james@towardex.com Boston-based Colocation & Bandwidth Services > cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 11:22:22 2004 Return-Path: Delivered-To: freebsd-net@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADD2916A4CE for ; Wed, 21 Jul 2004 11:22:22 +0000 (GMT) Received: from quick.recoil.org (quick.recoil.org [194.70.3.133]) by mx1.FreeBSD.org (Postfix) with SMTP id 0BFED43D46 for ; Wed, 21 Jul 2004 11:22:22 +0000 (GMT) (envelope-from avsm@quick.recoil.org) Received: (qmail 25698 invoked by uid 10000); 21 Jul 2004 11:22:20 -0000 Date: Wed, 21 Jul 2004 12:22:20 +0100 From: Anil Madhavapeddy To: freebsd-net@lists.freebsd.org Message-ID: <20040721112220.GA11621@quick.recoil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Subject: Set device BD_ADDR via ng_bluetooth X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 11:22:22 -0000 This is a long shot, but is it possible to set a Bluetooth device's BD_ADDR to a custom value using ng_bluetooth? I couldn't spot anything in the ng_btsocket(4) man page, or in the Bluez stack on Linux. -- Anil Madhavapeddy http://anil.recoil.org University of Cambridge http://www.cl.cam.ac.uk From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 11:44:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BE5616A4CE; Wed, 21 Jul 2004 11:44:56 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DB9C43D2F; Wed, 21 Jul 2004 11:44:56 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id AF0372F900; Wed, 21 Jul 2004 07:44:55 -0400 (EDT) Date: Wed, 21 Jul 2004 07:44:55 -0400 From: James To: Andre Oppermann Message-ID: <20040721114455.GA47249@scylla.towardex.com> References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> <20040721020418.GA53214@scylla.towardex.com> <40FE4367.AA7B0A7F@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40FE4367.AA7B0A7F@freebsd.org> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org cc: James Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 11:44:56 -0000 Andre, > > James, > > it just occured to me; but what is the purpose of versrcreach denying a > packet that will be discarded a few cycles later anyway? When I mark > a route with -reject I want the ICMPs go out and still use the versrcreach > functionality in ipfw. The point is to have uRPF loose-check *drop* the packets sourced from IP's that are null-routed. A null route would discard the packet destined *to* the null route, but it would never drop a packet *sourced* with an IP within the null route. uRPF should not emit an ICMP when it drops a -reject route. Even with ip unreachables, Cisco won't emit ICMP when uRPF is killing a packet. The source that triggered uRPF drop condition cannot be trusted as it may have spoofed the packet. -J -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 11:53:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E0D616A4CE for ; Wed, 21 Jul 2004 11:53:28 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B28BB43D1D for ; Wed, 21 Jul 2004 11:53:27 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 30390 invoked from network); 21 Jul 2004 11:51:12 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Jul 2004 11:51:12 -0000 Message-ID: <40FE5938.6890EC8C@freebsd.org> Date: Wed, 21 Jul 2004 13:53:28 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> <20040721020418.GA53214@scylla.towardex.com> <40FE4367.AA7B0A7F@freebsd.org> <20040721114455.GA47249@scylla.towardex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: James Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 11:53:28 -0000 James wrote: > > Andre, > > > > > James, > > > > it just occured to me; but what is the purpose of versrcreach denying a > > packet that will be discarded a few cycles later anyway? When I mark > > a route with -reject I want the ICMPs go out and still use the versrcreach > > functionality in ipfw. > > The point is to have uRPF loose-check *drop* the packets sourced from IP's that > are null-routed. A null route would discard the packet destined *to* the null > route, but it would never drop a packet *sourced* with an IP within the null > route. Yea, sorry, you are right. Wasn't really up to speed this morning... ;-) > uRPF should not emit an ICMP when it drops a -reject route. Even with > ip unreachables, Cisco won't emit ICMP when uRPF is killing a packet. The source > that triggered uRPF drop condition cannot be trusted as it may have spoofed the > packet. Ok, I'll go ahead and commit this to ipfw2 later today. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 11:56:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A911516A4CE; Wed, 21 Jul 2004 11:56:59 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C0B843D4C; Wed, 21 Jul 2004 11:56:59 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 37BC02F8FB; Wed, 21 Jul 2004 07:56:59 -0400 (EDT) Date: Wed, 21 Jul 2004 07:56:59 -0400 From: James To: Andre Oppermann Message-ID: <20040721115659.GA70511@scylla.towardex.com> References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> <20040721020418.GA53214@scylla.towardex.com> <40FE4367.AA7B0A7F@freebsd.org> <20040721114455.GA47249@scylla.towardex.com> <40FE5938.6890EC8C@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40FE5938.6890EC8C@freebsd.org> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org cc: james@towardex.com Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 11:56:59 -0000 > > Yea, sorry, you are right. Wasn't really up to speed this morning... ;-) > > Not a problem at all :) Thanks for committing this! -J -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 17:54:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 708DA16A4CE; Wed, 21 Jul 2004 17:54:13 +0000 (GMT) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25C7443D53; Wed, 21 Jul 2004 17:54:12 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by rms04.rommon.net (8.12.10/8.12.9) with ESMTP id i6LHs93v000427; Wed, 21 Jul 2004 20:54:09 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <40FEADC1.8070400@he.iki.fi> Date: Wed, 21 Jul 2004 20:54:09 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> <20040721020418.GA53214@scylla.towardex.com> <40FE4367.AA7B0A7F@freebsd.org> <20040721114455.GA47249@scylla.towardex.com> In-Reply-To: <20040721114455.GA47249@scylla.towardex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: James Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 17:54:13 -0000 James wrote: > >uRPF should not emit an ICMP when it drops a -reject route. Even with >ip unreachables, Cisco won't emit ICMP when uRPF is killing a packet. The source >that triggered uRPF drop condition cannot be trusted as it may have spoofed the >packet. > > > Where would the ICMP go anyway because you either donīt have a route to where you would point the packet to or the route points to null. Pete From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 18:14:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AACE016A4CE; Wed, 21 Jul 2004 18:14:10 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8550143D41; Wed, 21 Jul 2004 18:14:10 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 1D2EB2F919; Wed, 21 Jul 2004 14:14:10 -0400 (EDT) Date: Wed, 21 Jul 2004 14:14:10 -0400 From: James To: Petri Helenius Message-ID: <20040721181410.GA5511@scylla.towardex.com> References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> <20040721020418.GA53214@scylla.towardex.com> <40FE4367.AA7B0A7F@freebsd.org> <20040721114455.GA47249@scylla.towardex.com> <40FEADC1.8070400@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40FEADC1.8070400@he.iki.fi> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: James Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 18:14:10 -0000 > > > Where would the ICMP go anyway because you either don?t have a route to > where you would point the packet to or the route points to null. Under uRPF drop condition, ICMP should not happen b/c the source of the route is null route. Under normal, non-uRPF drop condition, ICMP unreachable will go to the *source* who is _not_ part of the null route. For example: If you are host 10.10.10.2 behind a router 10.10.10.1, and you run traceroute to 3.3.3.3 and if your router does not have a route for 3.3.3.3 (not even default route), the router will generate !N/!H icmp message back to the source, that being 10.10.10.2, and that being you. If you are host 10.10.10.2, and you spoof your IP address to 1.1.1.1, and the router runs loose-check uRPF and has 1.1.1.1 as RTF_REJECT, the router will obviously cannot generate ICMP back at you, b/c you are claiming to be 1.1.1.1 which is routed to null. -J -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 18:17:45 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0E1616A4CE for ; Wed, 21 Jul 2004 18:17:45 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8397943D4C for ; Wed, 21 Jul 2004 18:17:45 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 4FC7A2F8FB; Wed, 21 Jul 2004 14:17:45 -0400 (EDT) Date: Wed, 21 Jul 2004 14:17:45 -0400 From: James To: Petri Helenius Message-ID: <20040721181745.GB5511@scylla.towardex.com> References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> <20040721020418.GA53214@scylla.towardex.com> <40FE4367.AA7B0A7F@freebsd.org> <20040721114455.GA47249@scylla.towardex.com> <40FEADC1.8070400@he.iki.fi> <20040721181410.GA5511@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040721181410.GA5511@scylla.towardex.com> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 18:17:45 -0000 On Wed, Jul 21, 2004 at 02:14:10PM -0400, James wrote: > > > > > Where would the ICMP go anyway because you either don?t have a route to > > where you would point the packet to or the route points to null. > Hmm.. Soemthing tells me that whatever I said below is exactly same to whatever you said.. :) doh Sorry for useless reply :) -J > Under uRPF drop condition, ICMP should not happen b/c the source of the route > is null route. > > Under normal, non-uRPF drop condition, ICMP unreachable will go to the *source* > who is _not_ part of the null route. > > For example: If you are host 10.10.10.2 behind a router 10.10.10.1, and you > run traceroute to 3.3.3.3 and if your router does not have a route for 3.3.3.3 > (not even default route), the router will generate !N/!H icmp message back to > the source, that being 10.10.10.2, and that being you. > > If you are host 10.10.10.2, and you spoof your IP address to 1.1.1.1, and the > router runs loose-check uRPF and has 1.1.1.1 as RTF_REJECT, the router will > obviously cannot generate ICMP back at you, b/c you are claiming to be > 1.1.1.1 which is routed to null. > > -J > > -- > James Jun TowardEX Technologies, Inc. > Technical Lead Network Design, Consulting, IT Outsourcing > james@towardex.com Boston-based Colocation & Bandwidth Services > cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 21:17:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDF4816A4CE for ; Wed, 21 Jul 2004 21:17:01 +0000 (GMT) Received: from mage.trollkarl.net (018.216-123-203-0.interbaun.com [216.123.203.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7216743D5E for ; Wed, 21 Jul 2004 21:17:01 +0000 (GMT) (envelope-from skafte@trollkarl.net) Received: from trollkarl.skafte.org (root@trollkarl [192.168.100.16]) by mage.trollkarl.net (8.12.11/8.12.11) with ESMTP id i6LLGwJ4055438 for ; Wed, 21 Jul 2004 15:16:58 -0600 (MDT) (envelope-from skafte@trollkarl.net) Received: from trollkarl.skafte.org (skafte@localhost [127.0.0.1]) by trollkarl.skafte.org (8.12.11/8.12.11) with ESMTP id i6LLGv8R004791 for ; Wed, 21 Jul 2004 15:16:57 -0600 (MDT) (envelope-from skafte@trollkarl.skafte.org) Received: (from skafte@localhost) by trollkarl.skafte.org (8.12.11/8.12.9/Submit) id i6LLGvHN004790 for freebsd-net@freebsd.org; Wed, 21 Jul 2004 15:16:57 -0600 (MDT) Date: Wed, 21 Jul 2004 15:16:57 -0600 From: Greg Skafte To: freebsd-net@freebsd.org Message-ID: <20040721211657.GA4757@trollkarl.skafte.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Organization: Gregs Hidey Hole Errors-To: skafte@trollkarl.net Subject: a 5.2* bridging mystery. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 21:17:01 -0000 I've got a bit of a mystery when I have the below picture fxp1 10.1.x.x/22 ______|___ 10.1.x.x/22 |device|-------|switch| ---------| bridge | -----------|targ| fxp2 fxp0 arp replies from the target are not being forwarded to fxp2 if I remove the switch (a cisco cat) and go to the picture below fxp1 10.1.x.x/22 ______|___ 10.1.x.x/22 |device|-------------------------| bridge | -----------|targ| x-over cable fxp2 fxp0 the arp replies are recieved just fine. I've tried both 5.2.1-p8 and 5.2-current. Additionally, if targ is a bsd box things are OK, but if targ is a unixware box which it needs to be, bzzzzt. ------------ net.link.ether.bridge_cfg=fxp0,fxp2 net.link.ether.bridge.enable=1 I've tried both net.inet.ip.check_interface=[0|1] ifconfig_fxp0="inet 10.1.X.X netmask 255.255.252.0 media 100basetx mediaopt full-duplex" ifconfig_fxp2="media 100basetx mediaopt full-duplex" ifconfig_fxp1="inet 10.5.Y.Y netmask 255.255.255.0 media 100basetx mediaopt full-duplex" any insights or I ideas? -- Email: skafte@trollkarl.net ICQ: 93234105 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) From owner-freebsd-net@FreeBSD.ORG Thu Jul 22 06:38:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3996F16A4CE for ; Thu, 22 Jul 2004 06:38:23 +0000 (GMT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.245]) by mx1.FreeBSD.org (Postfix) with SMTP id 2290C43D45 for ; Thu, 22 Jul 2004 06:38:23 +0000 (GMT) (envelope-from maksim.yevmenkin@gmail.com) Received: by mproxy.gmail.com with SMTP id w29so968000cwb for ; Wed, 21 Jul 2004 23:38:22 -0700 (PDT) Received: by 10.11.116.69 with SMTP id o69mr29514cwc; Wed, 21 Jul 2004 23:38:22 -0700 (PDT) Message-ID: Date: Wed, 21 Jul 2004 23:38:22 -0700 From: Maksim Yevmenkin To: Anil Madhavapeddy In-Reply-To: <40FEC892.9030801@cw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <40FEC892.9030801@cw.com> cc: freebsd-net@freebsd.org Subject: Re: Set device BD_ADDR via ng_bluetooth X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2004 06:38:23 -0000 > This is a long shot, but is it possible to set a Bluetooth device's > BD_ADDR to a custom value using ng_bluetooth? I couldn't spot anything > in the ng_btsocket(4) man page, or in the Bluez stack on Linux. bluetooth spec v1.1 does not define a way to set device's bd_addr. i guess it *might* be possible via vendor specific command. of course you would need to know the vendor command opcode and the parameters for the specific bluetooth chip. good luck finding them out. vendor commands on some chips do not even return any events back, so it makes it hard to just probe all possible opcodes to see what device does. device's bd_addr is the only way to identify bluetooth device. you are not supposed to change it. everything else is tied to the bd_add, i.e. security etc. why do you want to change it anyway? max From owner-freebsd-net@FreeBSD.ORG Sat Jul 24 02:47:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5748C16A4CE for ; Sat, 24 Jul 2004 02:47:29 +0000 (GMT) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id A925443D46 for ; Sat, 24 Jul 2004 02:47:28 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from dungeon.home (ppp228-230.lns1.bne1.internode.on.net [203.122.228.230])i6O2lQHY042446; Sat, 24 Jul 2004 12:17:26 +0930 (CST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.12.8p2/8.11.6) with ESMTP id i6O2lQfJ007370; Sat, 24 Jul 2004 12:47:26 +1000 (EST) (envelope-from mckay) Message-Id: <200407240247.i6O2lQfJ007370@dungeon.home> To: freebsd-net@freebsd.org Date: Sat, 24 Jul 2004 12:47:26 +1000 From: Stephen McKay cc: Stephen McKay Subject: PPPoE problem: "Too many LQR packets lost" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 02:47:29 -0000 Hi! A few months ago my ADSL line started dropping out, claiming too many LQR packets lost. Seems like my telco changed the hardware at the other end. You get that a lot here. So, I just turned off LQR and left it at that. Unfortunately, when the other end loses its marbles the link just hangs now instead of ppp detecting it and reconnecting. I decided to patch ppp. I found Mike Tancsa's patch but didn't like it. I rolled my own, which seems to be working so far. It works by switching from LQR to simple echo requests when LQR times out. This should be tuned a bit so that people with working LQR (well, at least one correct LQR exchange in a given session) don't have to wait for the echo requests to time out too before a dead connection is detected. I'd have to have a carrier that supported LQR to test that though. :-) Stephen. (This is a patch against ppp in FreeBSD 4.8. I haven't tried the ppp in -current yet as -current is still a wild and woolly place that scares me.) Index: lqr.c =================================================================== RCS file: /cvs/src/usr.sbin/ppp/lqr.c,v retrieving revision 1.40.2.4 diff -u -r1.40.2.4 lqr.c --- lqr.c 1 Sep 2002 02:12:28 -0000 1.40.2.4 +++ lqr.c 24 Jul 2004 02:12:51 -0000 @@ -165,8 +165,16 @@ lcp->fsm.link->name); log_Printf(LogLQM, "%s: Too many LQR packets lost\n", lcp->fsm.link->name); - p->hdlc.lqm.method = 0; - datalink_Down(p->dl, CLOSE_NORMAL); + p->hdlc.lqm.method &= ~LQM_LQR; + if (p->hdlc.lqm.method == 0) + datalink_Down(p->dl, CLOSE_NORMAL); + else { + log_Printf(LogPHASE, "%s: ** Switching to LQR ECHO **\n", + lcp->fsm.link->name); + log_Printf(LogLQM, "%s: Switching to LQR ECHO\n", + lcp->fsm.link->name); + SendEchoReq(lcp); + } } else { SendLqrData(lcp); p->hdlc.lqm.lqr.resent++; From owner-freebsd-net@FreeBSD.ORG Sat Jul 24 11:56:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14F1816A4CE for ; Sat, 24 Jul 2004 11:56:31 +0000 (GMT) Received: from mll.pl (polly.mll.pl [80.53.211.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70C0543D2D for ; Sat, 24 Jul 2004 11:56:30 +0000 (GMT) (envelope-from piotr@mll.pl) Received: from localhost (lca.one.pl [80.53.159.130]) by mll.pl (Qmail) with ESMTP id 8F0CEF805 for ; Sat, 24 Jul 2004 13:57:09 +0200 (CEST) Date: Sat, 24 Jul 2004 13:53:42 +0200 From: -=PeleoS=- To: freebsd-net@freebsd.org Message-Id: <20040724135342.2b5e1ee7.piotr@mll.pl> X-Mailer: Sylpheed version 0.9.9-gtk2-20040229 (GTK+ 2.4.1; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: about skey.access file... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 11:56:31 -0000 Hello. I using S/Key mechanism and i want use skey.access file to deny or permit users or host to password mechanism. Everythink works great but there is one problem. If i have some rules in skey.access file, this rules permit or deny user or host in FTP connections and Telnet connection. Bu in SSH connection rules in skey.access file doesn`t work. SSH totatlly ignored everything in this file. Why? What I must do? regard Piotr Matuszczyk From owner-freebsd-net@FreeBSD.ORG Sat Jul 24 21:29:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9920D16A4CE; Sat, 24 Jul 2004 21:29:21 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D5FD43D54; Sat, 24 Jul 2004 21:29:21 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i6OLTBJU082514; Sat, 24 Jul 2004 17:29:11 -0400 (EDT) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smtp2.sentex.ca (8.12.11/8.12.11) with SMTP id i6OLTCPo047184; Sat, 24 Jul 2004 17:29:16 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Stephen McKay Date: Sat, 24 Jul 2004 17:29:21 -0400 Message-ID: References: <200407240247.i6O2lQfJ007370@dungeon.home> In-Reply-To: <200407240247.i6O2lQfJ007370@dungeon.home> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable cc: freebsd-net@freebsd.org Subject: Re: PPPoE problem: "Too many LQR packets lost" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 21:29:21 -0000 On Sat, 24 Jul 2004 12:47:26 +1000, in sentex.lists.freebsd.net you wrote: > >I found Mike Tancsa's patch but didn't like it. I rolled my own, which >seems to be working so far. It works by switching from LQR to simple >echo requests when LQR times out. I feel so unliked ;-) Seriously though, mine was a very ugly hack to get things working again for me. Most of the DSL aggregators here are Juniper ERXes which do not play nice with FreeBSD's PPPoE. > >(This is a patch against ppp in FreeBSD 4.8. I haven't tried the ppp in >-current yet as -current is still a wild and woolly place that scares = me.) I think Brian re worked the LQR portion at least from looking at the commit messages http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/ppp/ It seems he will be MFC'ing his changes in another week or so. ---Mike