From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 06:11: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 3DDCC16A4CF; Sun, 25 Apr 2004 06:11:10 -0700 (PDT) Received: from mail023.syd.optusnet.com.au (mail023.syd.optusnet.com.au [211.29.132.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id E76F743D54; Sun, 25 Apr 2004 06:11:08 -0700 (PDT) (envelope-from david.burns@dugeem.net) Received: from dugeem.net (c211-30-248-50.carlnfd2.nsw.optusnet.com.au [211.30.248.50])i3PDB6j17615; Sun, 25 Apr 2004 23:11:07 +1000 Message-ID: <408BB8DF.5090509@dugeem.net> Date: Sun, 25 Apr 2004 23:10:55 +1000 From: David Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Andre Oppermann References: <408A160F.4090703@dugeem.net> <408A91BC.46A0D95F@freebsd.org> In-Reply-To: <408A91BC.46A0D95F@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: fast ethernet driver MII phy serial clock rates 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, 25 Apr 2004 13:11:10 -0000 Andre Oppermann wrote: > > This is a very interesting observation. I've just worked my way through > the MII code to add link state notification to the routing socket and had > to remove a couple of return(0) when the link is up to break so the later > status function can read the MII and announce the state change if neccessary. > Based on your explanation this seems to be a regression and I will look at > how to work around this. > > Do you have any idea how to make the MII access faster or to get some sort > of async notification from the hardware when the link state changes so we > don't have to poll every second? > Apart from cautiously removing the DELAY(1) and retesting each driver on a few different hardware platforms there are a couple of other small improvements that could be considered: 1. Not all PHYs need resyncing on every operation - which would obviously eliminate half the access time 2. Only do autoneg operations every 10 seconds (although I think 17 is the current period for MII autoneg timeout?) - at least this will help minimise per second operations. A handful of PHYs appear to support a form of link state interrupt but given it hasn't already been implemented I'm suspecting broken hardware - not to mention the additional driver complexity necessary for a small gain. David From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 06:23:49 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 1CF1D16A4CE for ; Sun, 25 Apr 2004 06:23:49 -0700 (PDT) Received: from mail022.syd.optusnet.com.au (mail022.syd.optusnet.com.au [211.29.132.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03A1B43D5A for ; Sun, 25 Apr 2004 06:23:48 -0700 (PDT) (envelope-from david.burns@dugeem.net) Received: from dugeem.net (c211-30-248-50.carlnfd2.nsw.optusnet.com.au [211.30.248.50])i3PDNgj01139; Sun, 25 Apr 2004 23:23:43 +1000 Message-ID: <408BBBD3.4090200@dugeem.net> Date: Sun, 25 Apr 2004 23:23:31 +1000 From: David Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Mike Silbersack References: <408A160F.4090703@dugeem.net> <20040424140143.S5713@odysseus.silby.com> In-Reply-To: <20040424140143.S5713@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: fast ethernet driver MII phy serial clock rates 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, 25 Apr 2004 13:23:49 -0000 Mike Silbersack wrote: > > On Sat, 24 Apr 2004, David Burns wrote: > > >>Hello all, >> >>It appears that quite a few of the "el cheapo" hardware Fast Ethernet >>drivers (at least rl, sis, ste, vr, wb - these are just the ones I found >>in /usr/src/sys/pci) have added DELAY(1) statements around MII serial >>clock ops which will result in a max Management Data Clock (MDC) >>frequency of 500kHz for the serial management interface. Which means >>that a mii_readreg (or writereg) operation will take a minimum of 128?s >>(64?s for mii_sync + 64?s for data read/write). During which time the >>driver is locked. > > > This is an old problem, most of us leave it alone because hardware can > break in strange ways. :) > I was afraid someone would say that... :-) We should still implement this where testing succeeds on at least a few hardware platforms. Alternatively implement a driver.mii_phy_fast tunable which allows the DELAY to be disabled. > >>NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't >>think it is ... :-( > > > Correct, DELAY takes far longer than it should. > > If you're really interested in fixing the problem and not inadvertantly > breaking older cards, what you should do is implement a nanodelay function > that actually delays for the time it's supposed to and then delay the > rated amount. Removing all delays will probably break something > somewhere. > We could probably build a driver specific nanodelay function based on dummy PCI operations. Some will say this sucks but then I'd argue it's better than the current DELAY implementation. Of course just sending one bit of data on the MDIO will take us about 600 nanoseconds - resulting in a 1.6MHz clock. Probably need input from the guys who originally cut these drivers years ago (eg wpaul) to help identify the pathological PHYs out there... David From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 09:49:41 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 5E71216A4CE; Sun, 25 Apr 2004 09:49:41 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3892643D49; Sun, 25 Apr 2004 09:49:41 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3PGnfgd051047; Sun, 25 Apr 2004 09:49:41 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3PGnf5J051046; Sun, 25 Apr 2004 09:49:41 -0700 (PDT) (envelope-from rizzo) Date: Sun, 25 Apr 2004 09:49:40 -0700 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20040425094940.A50968@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i cc: net@freebsd.org Subject: new arp code snapshot for review... 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, 25 Apr 2004 16:49:41 -0000 Here is a snapshot of the new arp code that i have been working on lately, based a on Andre's ideas. (I say 'ARP' for brevity, what i mean is the layer3-to-layer2 address translation code -- arp, aarp, nd6 all fit in the category). The basic idea is to have per-ifp, per-af tables linked to the ifnet itself. Each table is address-family specific, and as such is managed by the protocol itself. It can be structured as a list, an array with direct access, or a hash table depending on the requirements. The search key is always the layer3 address. The advantage is a reduction in size of the routing table, because it does not have to store ARP entries anymore, and a likely speedup of the arp lookups because now the table lends itself nicely to quick lookup and easy management. Also, when the approach is used for INET6 as well (which is the only other AF using the routing table to store arp entries) rtentry's will not need to support cloning anymore, nor store 'rt_gwroute', 'rt_llinfo', 'rt_genmask' and 'rt_parent' fields, which means another large chunk of code simply goes away. Entries in the table are tagged with some flags so the code knows which ones refer to dynamic entries, local interface addresses, or statically configured entries. Compatibility with userland tools is preserved usign some stub routines which trap requests on the routing sockets and manipulate the arp tables accordingly. I have tried to keep the changes to a minimum (see below) Basically all the existing functionality should be preserved, with a few minor differences: + routing entries associated to interfaces are now non-clonable + the 'useloopback' flag is not yet implemented, because i have some doubts on its semantic. At the moment, and despite what you might think, 'useloopback' means "when you create (by cloning) a routing entry to the local host, use the loopback interface if useloopback is set at the time of cloning". Because there is no cloning anymore, the above semantics (which is not a design decision, just an accident) has to change slightly, to one of these two forms: - use the loopback interface for any local traffic if useloopback=1 - create a routing entry that uses the loopback interface if useloopback is set when you assign an address to an interface The former is a lot simpler, so i would vote for that. I also have patches for nd6, but these are a bit more extensive and i am trying to see if i can write them in a way to minimize differences with the existing code. In any case, ipv6 should work unmodified. --- Code changes: --- src/usr.sbin/arp/arp.c one small change to make 'arp' requests clearly identifiable; src/sys/net/route.c rtinit calls the new arp code, arp_ifscrub(), to remove an interface address when the address goes away. It also creates a route-to-interface, non clonable, entry when a new interface address is configured. src/sys/net/rtsock.c route_output() calls the new arp code, arp_rt_output(), to implement routing socket requests that relate to the arp table. Another method, sysctl_dumparp(), is used for the sysctl interface to the arp table. In both cases, the input and output data format is the same as before src/sys/netinet/if_ether.c this is the core of the new arp code for ipv4. At the moment this file also contains a number of generic routines which are not specific for ipv4 and so could be well moved to a different file. Note that arpresolve now completely ignores the 'rtentry' parameter passed by the upper layer. src/sys/netinet/if_ether.h contains the definition of the 'struct lltable' and various flags that control the behaviour of the each entry. All this should probably go elsewhere as it is not INET specific. ---------------------- comments welcome. The questions i have is mainly: Have i forgotten anything ? (the routing API is quite hard to follow...) Please keep in mind that some things such as malloc vs uma, field and variable names, location of code are going to change, so if you have preferences please state them. Also, as you see, there is no locking in place yet, i am leaving that task to the locking gurus cheers luigi ========================================= Index: src/usr.sbin/arp/arp.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/arp/arp.c,v retrieving revision 1.50 diff -u -p -r1.50 arp.c --- src/usr.sbin/arp/arp.c 13 Apr 2004 14:16:37 -0000 1.50 +++ src/usr.sbin/arp/arp.c 25 Apr 2004 15:42:21 -0000 @@ -439,6 +439,17 @@ delete(char *host, int do_proxy) !(rtm->rtm_flags & RTF_GATEWAY) && valid_type(sdl->sdl_type) ) break; /* found it */ + /* check the new arp interface */ + if (sdl->sdl_family == AF_LINK && + !(rtm->rtm_flags & RTF_GATEWAY) && + valid_type(sdl->sdl_type) ) { + /* + * found it. But overwrite the address to make + * sure that we really get it. + */ + addr->sin_addr.s_addr = dst->sin_addr.s_addr; + break; + } if (dst->sin_other & SIN_PROXY) { fprintf(stderr, "delete: cannot locate %s\n",host); return (1); Index: src/sys/net/route.c =================================================================== RCS file: /home/ncvs/src/sys/net/route.c,v retrieving revision 1.104 diff -u -p -r1.104 route.c --- src/sys/net/route.c 25 Apr 2004 01:39:00 -0000 1.104 +++ src/sys/net/route.c 25 Apr 2004 16:13:39 -0000 @@ -42,6 +42,7 @@ #include #include +#include /* for sockaddr_dl */ #include #include @@ -1105,9 +1106,13 @@ rt_maskedcopy(struct sockaddr *src, stru bzero((caddr_t)cp2, (unsigned)(cplim2 - cp2)); } +void arp_ifscrub(struct ifnet *ifp, uint32_t addr); + /* * Set up a routing table entry, normally * for an interface. + * Instead of the destination address, use a sockaddr_dl for the + * gateway, using the index and type of the interface. */ int rtinit(struct ifaddr *ifa, int cmd, int flags) @@ -1118,6 +1123,7 @@ rtinit(struct ifaddr *ifa, int cmd, int struct rtentry *rt = NULL; struct rt_addrinfo info; int error; + static struct sockaddr_dl null_sdl = {sizeof(null_sdl), AF_LINK}; if (flags & RTF_HOST) { dst = ifa->ifa_dstaddr; @@ -1126,6 +1132,13 @@ rtinit(struct ifaddr *ifa, int cmd, int dst = ifa->ifa_addr; netmask = ifa->ifa_netmask; } + printf("rtinit cmd %d flags 0x%x, ifa_ifp %p dst %d:0x%x gw %d:0x%x\n", + cmd, flags, ifa->ifa_ifp, + dst->sa_family, + ntohl(((struct sockaddr_in *)dst)->sin_addr.s_addr), + ifa->ifa_addr->sa_family, + ntohl(((struct sockaddr_in *)ifa->ifa_addr)->sin_addr.s_addr)); + /* * If it's a delete, check that if it exists, it's on the correct * interface or we might scrub a route to another ifa which would @@ -1136,6 +1149,9 @@ rtinit(struct ifaddr *ifa, int cmd, int struct radix_node_head *rnh; struct radix_node *rn; + if (dst->sa_family == AF_INET) + arp_ifscrub(ifa->ifa_ifp, + ((struct sockaddr_in *)dst)->sin_addr.s_addr); /* * It's a delete, so it should already exist.. * If it's a net, mask off the host bits @@ -1175,10 +1191,14 @@ bad: info.rti_ifa = ifa; info.rti_flags = flags | ifa->ifa_flags; info.rti_info[RTAX_DST] = dst; - info.rti_info[RTAX_GATEWAY] = ifa->ifa_addr; + info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)&null_sdl; info.rti_info[RTAX_NETMASK] = netmask; error = rtrequest1(cmd, &info, &rt); if (error == 0 && rt != NULL) { + ((struct sockaddr_dl *)rt->rt_gateway)->sdl_type = + rt->rt_ifp->if_type; + ((struct sockaddr_dl *)rt->rt_gateway)->sdl_index = + rt->rt_ifp->if_index; /* * notify any listening routing agents of the change */ Index: src/sys/net/rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.107 diff -u -p -r1.107 rtsock.c --- src/sys/net/rtsock.c 19 Apr 2004 07:20:32 -0000 1.107 +++ src/sys/net/rtsock.c 25 Apr 2004 15:39:49 -0000 @@ -91,6 +91,10 @@ static void rt_getmetrics(const struct r struct rt_metrics *out); static void rt_dispatch(struct mbuf *, const struct sockaddr *); +/* support new arp code */ +int arp_rt_output(struct rt_msghdr *rtm, struct rt_addrinfo *info); +int sysctl_dumparp(int af, struct sysctl_req *wr); + /* * It really doesn't make any sense at all for this code to share much * with raw_usrreq.c, since its functionality is so restricted. XXX @@ -275,6 +279,8 @@ static struct pr_usrreqs route_usrreqs = sosend, soreceive, sopoll, pru_sosetlabel_null }; + + /*ARGSUSED*/ static int route_output(struct mbuf *m, struct socket *so) @@ -350,6 +356,11 @@ route_output(struct mbuf *m, struct sock if (info.rti_info[RTAX_GATEWAY] == NULL) senderr(EINVAL); saved_nrt = NULL; + if (info.rti_info[RTAX_GATEWAY]->sa_family == AF_LINK) { + /* support for new ARP code */ + arp_rt_output(rtm, &info); + break; + } error = rtrequest1(RTM_ADD, &info, &saved_nrt); if (error == 0 && saved_nrt) { RT_LOCK(saved_nrt); @@ -363,6 +374,11 @@ route_output(struct mbuf *m, struct sock case RTM_DELETE: saved_nrt = NULL; + if (info.rti_info[RTAX_GATEWAY]->sa_family == AF_LINK) { + /* support for new ARP code */ + arp_rt_output(rtm, &info); + break; + } error = rtrequest1(RTM_DELETE, &info, &saved_nrt); if (error == 0) { RT_LOCK(saved_nrt); @@ -1069,6 +1085,7 @@ sysctl_rtsock(SYSCTL_HANDLER_ARGS) int i, lim, s, error = EINVAL; u_char af; struct walkarg w; + int found = 0; name ++; namelen--; @@ -1100,8 +1117,17 @@ sysctl_rtsock(SYSCTL_HANDLER_ARGS) error = rnh->rnh_walktree(rnh, sysctl_dumpentry, &w);/* could sleep XXX */ /* RADIX_NODE_HEAD_UNLOCK(rnh); */ - } else if (af != 0) - error = EAFNOSUPPORT; + if (error) + break; + found = 1; + } + /* + * take care of llinfo entries. XXX check AF_INET ? + */ + if (w.w_op == NET_RT_FLAGS && (RTF_LLINFO & w.w_arg)) + error = sysctl_dumparp(af, w.w_req); + else if (af != 0 && found == 0) + error = EAFNOSUPPORT; break; case NET_RT_IFLIST: Index: src/sys/netinet/if_ether.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/if_ether.c,v retrieving revision 1.127 diff -u -p -r1.127 if_ether.c --- src/sys/netinet/if_ether.c 25 Apr 2004 15:00:17 -0000 1.127 +++ src/sys/netinet/if_ether.c 25 Apr 2004 16:14:03 -0000 @@ -27,7 +27,7 @@ * SUCH DAMAGE. * * @(#)if_ether.c 8.1 (Berkeley) 6/10/93 - * $FreeBSD: src/sys/netinet/if_ether.c,v 1.127 2004/04/25 15:00:17 luigi Exp $ + * $FreeBSD$ */ /* @@ -101,7 +101,6 @@ struct llinfo_arp { static LIST_HEAD(, llinfo_arp) llinfo_arp; static struct ifqueue arpintrq; -static int arp_allocated; static int arp_maxtries = 5; static int useloopback = 1; /* use loopback interface for local traffic */ @@ -116,18 +115,303 @@ SYSCTL_INT(_net_link_ether_inet, OID_AUT &arp_proxyall, 0, ""); static void arp_init(void); -static void arp_rtrequest(int, struct rtentry *, struct rt_addrinfo *); static void arprequest(struct ifnet *, struct in_addr *, struct in_addr *, u_char *); static void arpintr(struct mbuf *); static void arptfree(struct llinfo_arp *); static void arptimer(void *); -static struct llinfo_arp - *arplookup(u_long, int, int); +struct llentry *arplookup(struct ifnet *ifp, uint32_t addr, uint32_t flags); #ifdef INET static void in_arpinput(struct mbuf *); #endif +/*** + *** + *** Start of new arp support routines which should go to a separate file. + *** + ***/ +#define DEB(x) +#define DDB(x) x + +struct llentry { + struct llentry *lle_next; + struct mbuf *la_hold; + uint16_t flags; /* see values in if_ether.h */ + uint8_t la_preempt; + uint8_t la_asked; + time_t expire; + struct in_addr l3_addr; + union { + uint64_t mac_aligned; + uint16_t mac16[3]; + } ll_addr; +}; + +MALLOC_DEFINE(M_ARP, "arp", "arp entries"); /* XXX will move to UMA */ + +int arp_rt_output(struct rt_msghdr *rtm, struct rt_addrinfo *info); +int sysctl_dumparp(int af, struct sysctl_req *wr); +void arp_ifscrub(struct ifnet *ifp, uint32_t addr); + +/* + * called by in_ifscrub to remove entry from the table when + * the interface goes away + */ +void +arp_ifscrub(struct ifnet *ifp, uint32_t addr) +{ + arplookup(ifp, addr, LLE_DELETE | LLE_IFADDR); +} + +/* + * Find an interface address matching the ifp-addr pair. + * This may replicate some of the functions of ifa_ifwithnet() + */ +static struct ifaddr * +find_ifa(struct ifnet *ifp, uint32_t addr) +{ + struct ifaddr *ifa; + + if (ifp == NULL) + return NULL; + TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { + if (ifa->ifa_addr->sa_family != AF_INET) + continue; + if (ifp->if_flags & IFF_POINTOPOINT) + break; + if (((addr ^ SIN(ifa->ifa_addr)->sin_addr.s_addr) & + SIN(ifa->ifa_netmask)->sin_addr.s_addr ) == 0) + break; /* found! */ + } + return ifa; +} + +static void +llentry_free(struct llentry **e) +{ + struct llentry *x; + + if (e == 0) + panic("llentry_free: null ptr"); + x = *e; + *e = x->lle_next; + if (x->la_hold) + m_freem(x->la_hold); + free(x, M_ARP); +} + +/* + * Add a new table at the head of the list for interface ifp + */ +struct lltable * +lltable_new(struct ifnet *ifp, int af) +{ + struct lltable *t; + + t = malloc(sizeof (struct lltable), M_ARP, M_DONTWAIT | M_ZERO); + if (t != NULL) { + t->llt_next = ifp->lltables; + t->llt_af = af; + ifp->lltables = t; + } + return t; +} + +struct lltable ** +lltable_free(struct lltable **t) +{ + struct lltable *x; + + if (t == NULL) + panic("lltable_free: null ptr"); + x = *t; + *t = x->llt_next; + free(x, M_ARP); + return t; +} + +static void +newarptimer(__unused void *ignored_arg) +{ + struct lltable *t; + struct llentry **e; + struct ifnet *ifp; + + IFNET_RLOCK(); + printf("arptimer!\n"); + TAILQ_FOREACH(ifp, &ifnet, if_link) { + for (t = ifp->lltables; t ; t = t->llt_next) { + if (t->llt_af != AF_INET) + continue; + for (e = (struct llentry **)&t->lle_head; *e; ) { + int kill; + + if ((*e)->flags & LLE_DELETED) + kill = 1; + else if ((*e)->flags & LLE_STATIC) + kill = 0; + else + kill = time_second >= (*e)->expire; + if (kill) + llentry_free(e); + else + e = &((*e)->lle_next); + } + } + } + IFNET_RUNLOCK(); + callout_reset(&arp_callout, arpt_prune * hz, newarptimer, NULL); +} + +static int +inet_dumparp(struct ifnet *ifp, void *head, struct sysctl_req *wr) +{ + struct llentry *e; + int error = 0; + + for (e = head; e; e = e->lle_next) { + struct { + struct rt_msghdr rtm; + struct sockaddr_inarp sin2; + struct sockaddr_dl sdl; + //struct sockaddr_inarp addr2; + } d; + + DEB(printf("ifp %p index %d flags 0x%x ip %x %s\n", + ifp, ifp->if_index, + e->flags, + ntohl(e->l3_addr.s_addr), + (e->flags & LLA_VALID) ? "valid" : "incomplete");) + if (e->flags & LLE_DELETED) /* skip deleted entries */ + continue; + /* + * produce a msg made of: + * struct rt_msghdr; + * struct sockaddr_inarp; + * struct sockaddr_dl; + */ + bzero(&d, sizeof (d)); + d.rtm.rtm_msglen = sizeof(d); + d.sin2.sin_family = AF_INET; + d.sin2.sin_len = sizeof(d.sin2); + d.sin2.sin_addr.s_addr = e->l3_addr.s_addr; + + if (e->flags & LLA_VALID) { /* valid MAC */ + d.sdl.sdl_family = AF_LINK; + d.sdl.sdl_len = sizeof(d.sdl); + d.sdl.sdl_alen = ifp->if_addrlen; + d.sdl.sdl_index = ifp->if_index; + d.sdl.sdl_type = ifp->if_type; + bcopy(&e->ll_addr, LLADDR(&d.sdl), ifp->if_addrlen); + } + d.rtm.rtm_rmx.rmx_expire = + e->flags & LLE_STATIC ? 0 : e->expire; + d.rtm.rtm_flags = RTF_LLINFO; + if (e->flags & LLE_STATIC) + d.rtm.rtm_flags |= RTF_STATIC; + d.rtm.rtm_index = ifp->if_index; + error = SYSCTL_OUT(wr, &d, sizeof(d)); + if (error) + break; + } + return error; +} + +/* + * glue to dump arp tables + */ +int +sysctl_dumparp(int af, struct sysctl_req *wr) +{ + struct lltable *t; + struct ifnet *ifp; + int error = 0; + + IFNET_RLOCK(); + TAILQ_FOREACH(ifp, &ifnet, if_link) { + for (t = ifp->lltables; t ; t = t->llt_next) { + if (af != 0 && t->llt_af != af) + continue; + switch (af) { + case AF_INET: + error = inet_dumparp(ifp, t->lle_head, wr); + break; + /* other handlers, if any */ + } + if (error) + goto done; + } + } +done: + IFNET_RUNLOCK(); + return (error); +} + +/* + * Called in route_output when adding/deleting a route to an interface. + */ +int +arp_rt_output(struct rt_msghdr *rtm, struct rt_addrinfo *info) +{ + struct sockaddr_dl *dl = + (struct sockaddr_dl *)info->rti_info[RTAX_GATEWAY]; + struct sockaddr_in *dst = + (struct sockaddr_in *)info->rti_info[RTAX_DST]; + struct ifnet *ifp; + struct llentry *la; + u_int flags; + + printf("arp_rt_output type %d af: gw %d dst %d:%x if_index %d\n", + rtm->rtm_type, + dl ? dl->sdl_family : 0, + dst ? dst->sin_family : 0, + dst && dst->sin_family == AF_INET ? + ntohl(dst->sin_addr.s_addr) : 0, + dl ? dl->sdl_index : 0); + if (dl == NULL || dl->sdl_family != AF_LINK) { + /* XXX should also check (dl->sdl_index < if_indexlim) */ + printf("invalid gateway/index\n"); + return EINVAL; + } + ifp = ifnet_byindex(dl->sdl_index); + if (ifp == NULL) { + printf("invalid ifp\n"); + return EINVAL; + } + + switch (rtm->rtm_type) { + case RTM_ADD: + flags = LLE_CREATE; + break; + + case RTM_CHANGE: + default: + return EINVAL; /* XXX not implemented yet */ + + case RTM_DELETE: + flags = LLE_DELETE; + break; + } + la = arplookup(ifp, dst->sin_addr.s_addr, flags); + if (la == NULL) { + bcopy(LLADDR(dl), &la->ll_addr, ifp->if_addrlen); + la->flags |= LLA_VALID; + if (rtm->rtm_flags & RTF_STATIC) + la->flags |= LLE_STATIC; + else + la->expire = time_second + arpt_keep; + } + return 0; +} + + + +/*** + *** + *** End of new arp support routines which should go to a separate file. + *** + ***/ + /* * Timeout routine. Age arp_tab entries periodically. */ @@ -152,6 +436,9 @@ arptimer(ignored_arg) callout_reset(&arp_callout, arpt_prune * hz, arptimer, NULL); } +#if 0 /* this is unused */ +static int arp_allocated; + /* * Parallel to llc_rtrequest. */ @@ -284,6 +571,7 @@ arp_rtrequest(req, rt, info) Free((caddr_t)la); } } +#endif /* arp_rtrequest unused */ /* * Broadcast an ARP request. Caller specifies: @@ -301,6 +589,28 @@ arprequest(ifp, sip, tip, enaddr) struct arphdr *ah; struct sockaddr sa; + if (sip == NULL) { + /* + * The caller did not supply a source address, try to find + * a compatible one among those assigned to this interface. + */ + struct ifaddr *ifa; + + TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { + if (!ifa->ifa_addr || + ifa->ifa_addr->sa_family != AF_INET) + continue; + sip = &SIN(ifa->ifa_addr)->sin_addr; + if (0 == ((sip->s_addr ^ tip->s_addr) & + SIN(ifa->ifa_netmask)->sin_addr.s_addr) ) + break; /* found it. */ + } + } + if (sip == NULL) { + printf(" cannot find matching address, no arprequest\n"); + return; + } + if ((m = m_gethdr(M_DONTWAIT, MT_DATA)) == NULL) return; m->m_len = sizeof(*ah) + 2*sizeof(struct in_addr) + @@ -344,16 +654,11 @@ int arpresolve(struct ifnet *ifp, struct rtentry *rt0, struct mbuf *m, struct sockaddr *dst, u_char *desten) { - struct llinfo_arp *la = 0; + struct llentry *la = 0; struct sockaddr_dl *sdl; - int error; struct rtentry *rt; - - error = rt_check(&rt, &rt0, dst); - if (error) { - m_freem(m); - return error; - } + u_int flags = (ifp->if_flags & (IFF_NOARP | IFF_STATICARP)) ? + 0 : LLE_CREATE; if (m->m_flags & M_BCAST) { /* broadcast */ (void)memcpy(desten, ifp->if_broadcastaddr, ifp->if_addrlen); @@ -363,51 +668,39 @@ arpresolve(struct ifnet *ifp, struct rte ETHER_MAP_IP_MULTICAST(&SIN(dst)->sin_addr, desten); return (0); } - if (rt) - la = (struct llinfo_arp *)rt->rt_llinfo; - if (la == 0) { - la = arplookup(SIN(dst)->sin_addr.s_addr, 1, 0); - if (la) - rt = la->la_rt; - } - if (la == 0 || rt == 0) { - log(LOG_DEBUG, "arpresolve: can't allocate llinfo for %s%s%s\n", - inet_ntoa(SIN(dst)->sin_addr), la ? "la" : "", - rt ? "rt" : ""); + la = arplookup(ifp, SIN(dst)->sin_addr.s_addr, flags); + if (la == NULL) { + if (flags & LLE_CREATE) + log(LOG_DEBUG, + "arpresolve: can't allocate llinfo for %s\n", + inet_ntoa(SIN(dst)->sin_addr)); m_freem(m); return (EINVAL); /* XXX */ } sdl = SDL(rt->rt_gateway); /* - * Check the address family and length is valid, the address - * is resolved; otherwise, try to resolve. + * If the entry is valid and not expired, use it. */ - if ((rt->rt_expire == 0 || rt->rt_expire > time_second) && - sdl->sdl_family == AF_LINK && sdl->sdl_alen != 0) { + if (la->flags & LLA_VALID && + (la->flags & LLE_STATIC || la->expire > time_second)) { + bcopy(&la->ll_addr, desten, ifp->if_addrlen); /* * If entry has an expiry time and it is approaching, * see if we need to send an ARP request within this * arpt_down interval. */ - if ((rt->rt_expire != 0) && - (time_second + la->la_preempt > rt->rt_expire)) { - arprequest(ifp, - &SIN(rt->rt_ifa->ifa_addr)->sin_addr, - &SIN(dst)->sin_addr, - IF_LLADDR(ifp)); + if (!(la->flags & LLE_STATIC) && + time_second + la->la_preempt > la->expire) { + arprequest(ifp, NULL, + &SIN(dst)->sin_addr, IF_LLADDR(ifp)); + la->la_preempt--; } - - bcopy(LLADDR(sdl), desten, sdl->sdl_alen); return (0); } - /* - * If ARP is disabled or static on this interface, stop. - * XXX - * Probably should not allocate empty llinfo struct if we are - * not going to be sending out an arp request. - */ - if (ifp->if_flags & (IFF_NOARP | IFF_STATICARP)) { + if (la->flags & LLE_STATIC) { /* should not happen! */ + log(LOG_DEBUG, "arpresolve: ouch, empty static llinfo for %s\n", + inet_ntoa(SIN(dst)->sin_addr)); m_freem(m); return (EINVAL); } @@ -419,26 +712,26 @@ arpresolve(struct ifnet *ifp, struct rte if (la->la_hold) m_freem(la->la_hold); la->la_hold = m; - if (rt->rt_expire) { - RT_LOCK(rt); - rt->rt_flags &= ~RTF_REJECT; - if (la->la_asked == 0 || rt->rt_expire != time_second) { - rt->rt_expire = time_second; - if (la->la_asked++ < arp_maxtries) { - arprequest(ifp, - &SIN(rt->rt_ifa->ifa_addr)->sin_addr, - &SIN(dst)->sin_addr, - IF_LLADDR(ifp)); - } else { - rt->rt_flags |= RTF_REJECT; - rt->rt_expire += arpt_down; - la->la_asked = 0; - la->la_preempt = arp_maxtries; - } - + /* + * Now implement the logic to issue requests -- we can send up + * to arp_maxtries with a 1-sec spacing, followed by a pause + * of arpt_down seconds if no replies are coming back. + * Take the chance to enforce limits on arp_maxtries and arpt_down + */ + if (la->expire <= time_second) { /* ok, expired */ + if (arp_maxtries > 100) /* enforce a sane limit */ + arp_maxtries = 100; + else if (arp_maxtries < 3) + arp_maxtries = 3; + if (la->la_asked++ < arp_maxtries) + la->expire = time_second + 1; + else { + la->la_asked = 0; + la->expire = time_second + arpt_down; + la->la_preempt = arp_maxtries; } - RT_UNLOCK(rt); - } + arprequest(ifp, NULL, &SIN(dst)->sin_addr, IF_LLADDR(ifp)); + } return (EWOULDBLOCK); } @@ -518,16 +811,12 @@ in_arpinput(m) { struct arphdr *ah; struct ifnet *ifp = m->m_pkthdr.rcvif; - struct iso88025_header *th = (struct iso88025_header *)0; - struct iso88025_sockaddr_dl_data *trld; - struct llinfo_arp *la = 0; - struct rtentry *rt; + struct llentry *la = 0; struct ifaddr *ifa; struct in_ifaddr *ia; - struct sockaddr_dl *sdl; struct sockaddr sa; struct in_addr isaddr, itaddr, myaddr; - int op, rif_len; + int op; int req_len; req_len = arphdr_len2(ifp->if_addrlen, sizeof(struct in_addr)); @@ -540,6 +829,19 @@ in_arpinput(m) op = ntohs(ah->ar_op); (void)memcpy(&isaddr, ar_spa(ah), sizeof (isaddr)); (void)memcpy(&itaddr, ar_tpa(ah), sizeof (itaddr)); + /* + * sanity check for the address length. + * XXX this does not work for protocols with variable address + * length. -is + */ + if (ifp->if_addrlen != ah->ar_hln) { + log(LOG_WARNING, + "arp from %*D: addr len: new %d, i/f %d (ignored)", + ifp->if_addrlen, (u_char *) ar_sha(ah), ":", + ah->ar_hln, ifp->if_addrlen); + goto drop; + } + #ifdef BRIDGE #define BRIDGE_TEST (do_bridge) #else @@ -592,62 +894,41 @@ match: } if (ifp->if_flags & IFF_STATICARP) goto reply; - la = arplookup(isaddr.s_addr, itaddr.s_addr == myaddr.s_addr, 0); - if (la && (rt = la->la_rt) && (sdl = SDL(rt->rt_gateway))) { - /* the following is not an error when doing bridging */ - if (!BRIDGE_TEST && rt->rt_ifp != ifp) { - if (log_arp_wrong_iface) - log(LOG_ERR, "arp: %s is on %s but got reply from %*D on %s\n", - inet_ntoa(isaddr), - rt->rt_ifp->if_xname, - ifp->if_addrlen, (u_char *)ar_sha(ah), ":", - ifp->if_xname); - goto reply; - } - if (sdl->sdl_alen && - bcmp(ar_sha(ah), LLADDR(sdl), sdl->sdl_alen)) { - if (rt->rt_expire) { - if (log_arp_movements) - log(LOG_INFO, "arp: %s moved from %*D to %*D on %s\n", - inet_ntoa(isaddr), - ifp->if_addrlen, (u_char *)LLADDR(sdl), ":", - ifp->if_addrlen, (u_char *)ar_sha(ah), ":", - ifp->if_xname); - } else { + /* Look up the source. If I am the target, create an entry for it. */ + la = arplookup(ifp, isaddr.s_addr, + (itaddr.s_addr == myaddr.s_addr) ? LLE_CREATE : 0); + if (la != NULL) { + /* We have a valid entry. Check and store the MAC. */ + if (la->flags & LLA_VALID && + bcmp(ar_sha(ah), &la->ll_addr, ifp->if_addrlen)) { + if (la->flags & LLE_STATIC) { log(LOG_ERR, "arp: %*D attempts to modify permanent entry for %s on %s\n", ifp->if_addrlen, (u_char *)ar_sha(ah), ":", inet_ntoa(isaddr), ifp->if_xname); goto reply; } + if (log_arp_movements) + log(LOG_INFO, "arp: %s moved from %*D to %*D on %s\n", + inet_ntoa(isaddr), + ifp->if_addrlen, (u_char *)&la->ll_addr, ":", + ifp->if_addrlen, (u_char *)ar_sha(ah), ":", + ifp->if_xname); } - /* - * sanity check for the address length. - * XXX this does not work for protocols with variable address - * length. -is - */ - if (sdl->sdl_alen && - sdl->sdl_alen != ah->ar_hln) { - log(LOG_WARNING, - "arp from %*D: new addr len %d, was %d", - ifp->if_addrlen, (u_char *) ar_sha(ah), ":", - ah->ar_hln, sdl->sdl_alen); - } - if (ifp->if_addrlen != ah->ar_hln) { - log(LOG_WARNING, - "arp from %*D: addr len: new %d, i/f %d (ignored)", - ifp->if_addrlen, (u_char *) ar_sha(ah), ":", - ah->ar_hln, ifp->if_addrlen); - goto reply; - } - (void)memcpy(LLADDR(sdl), ar_sha(ah), - sdl->sdl_alen = ah->ar_hln); + bcopy(ar_sha(ah), &la->ll_addr, ifp->if_addrlen); + la->flags |= LLA_VALID; +#if 0 /* XXX this needs to be fixed */ /* * If we receive an arp from a token-ring station over * a token-ring nic then try to save the source * routing info. */ if (ifp->if_type == IFT_ISO88025) { + struct iso88025_header *th; + struct iso88025_sockaddr_dl_data *trld; + struct sockaddr_dl *sdl; + int rif_len; + th = (struct iso88025_header *)m->m_pkthdr.header; trld = SDL_ISO88025(sdl); rif_len = TR_RCF_RIFLEN(th->rcf); @@ -673,15 +954,20 @@ match: m->m_pkthdr.len += 8; th->rcf = trld->trld_rcf; } - RT_LOCK(rt); - if (rt->rt_expire) - rt->rt_expire = time_second + arpt_keep; - rt->rt_flags &= ~RTF_REJECT; - RT_UNLOCK(rt); +#endif + if (!(la->flags & LLE_STATIC)) + la->expire = time_second + arpt_keep; la->la_asked = 0; la->la_preempt = arp_maxtries; if (la->la_hold) { - (*ifp->if_output)(ifp, la->la_hold, rt_key(rt), rt); + struct sockaddr_in sin; + + bzero(&sin, sizeof(sin)); + sin.sin_len = sizeof(struct sockaddr_in); + sin.sin_family = AF_INET; + sin.sin_addr.s_addr = la->l3_addr.s_addr; + ifp->if_output(ifp, la->la_hold, + (struct sockaddr *)&sin, NULL); la->la_hold = 0; } } @@ -693,9 +979,10 @@ reply: (void)memcpy(ar_tha(ah), ar_sha(ah), ah->ar_hln); (void)memcpy(ar_sha(ah), IF_LLADDR(ifp), ah->ar_hln); } else { - la = arplookup(itaddr.s_addr, 0, SIN_PROXY); + la = arplookup(ifp, itaddr.s_addr, LLE_PROXY); if (la == NULL) { struct sockaddr_in sin; + struct rtentry *rt; if (!arp_proxyall) goto drop; @@ -747,10 +1034,8 @@ reply: inet_ntoa(itaddr)); #endif } else { - rt = la->la_rt; (void)memcpy(ar_tha(ah), ar_sha(ah), ah->ar_hln); - sdl = SDL(rt->rt_gateway); - (void)memcpy(ar_sha(ah), LLADDR(sdl), ah->ar_hln); + (void)memcpy(ar_sha(ah), &la->ll_addr, ah->ar_hln); } } @@ -798,66 +1083,77 @@ arptfree(la) /* * Lookup or enter a new address in arptab. */ -static struct llinfo_arp * -arplookup(addr, create, proxy) - u_long addr; - int create, proxy; +struct llentry * +arplookup(struct ifnet *ifp, uint32_t l3addr, u_int flags) { - struct rtentry *rt; - struct sockaddr_inarp sin; - const char *why = 0; - - bzero(&sin, sizeof(sin)); - sin.sin_len = sizeof(sin); - sin.sin_family = AF_INET; - sin.sin_addr.s_addr = addr; - if (proxy) - sin.sin_other = SIN_PROXY; - rt = rtalloc1((struct sockaddr *)&sin, create, 0UL); - if (rt == 0) - return (0); - - if (rt->rt_flags & RTF_GATEWAY) - why = "host is not on local network"; - else if ((rt->rt_flags & RTF_LLINFO) == 0) - why = "could not allocate llinfo"; - else if (rt->rt_gateway->sa_family != AF_LINK) - why = "gateway route is not ours"; - - if (why) { -#define ISDYNCLONE(_rt) \ - (((_rt)->rt_flags & (RTF_STATIC | RTF_WASCLONED)) == RTF_WASCLONED) - if (create) - log(LOG_DEBUG, "arplookup %s failed: %s\n", - inet_ntoa(sin.sin_addr), why); - /* - * If there are no references to this Layer 2 route, - * and it is a cloned route, and not static, and - * arplookup() is creating the route, then purge - * it from the routing table as it is probably bogus. - */ - if (rt->rt_refcnt == 1 && ISDYNCLONE(rt)) - rtexpunge(rt); - RTFREE_LOCKED(rt); - return (0); -#undef ISDYNCLONE - } else { - RT_REMREF(rt); - RT_UNLOCK(rt); - return ((struct llinfo_arp *)rt->rt_llinfo); - } + struct llentry *e; + struct lltable *t; + // uint proxy = flags & LLE_PROXY; + + if (ifp == NULL) + return NULL; + /* LOCK_IFNET */ + for (t = ifp->lltables; t && t->llt_af != AF_INET; t = t->llt_next) + ; + if (t == NULL && flags & LLE_CREATE) + t = lltable_new(ifp, AF_INET); + if (t == NULL) { + /* UNLOCK_ALL_TABLES */ + return NULL; /* failed! */ + } + /* LOCK_TABLE(t) */ + /* UNLOCK_ALL_TABLES */ + for (e = (struct llentry *)t->lle_head; e ; e = e->lle_next) { + if (e->flags & LLE_DELETED) + continue; + if (l3addr == e->l3_addr.s_addr) + break; + } + if (e == NULL) { /* entry not found */ + if (!(flags & LLE_CREATE)) + goto done; + if (find_ifa(ifp, l3addr) == NULL) { + printf("host is not on local network\n"); + goto done; + } + e = malloc(sizeof (struct llentry), M_ARP, M_DONTWAIT | M_ZERO); + if (e == NULL) { + printf("arp malloc failed\n"); + goto done; + } + e->expire = time_second; /* mark expired */ + e->l3_addr.s_addr = l3addr; + e->lle_next = t->lle_head; + t->lle_head = e; + } + if (flags & LLE_DELETE && + (e->flags & LLE_IFADDR) == (flags & LLE_IFADDR)) + e->flags = LLE_DELETED; +done: + /* UNLOCK(t) */ + return e; } + void arp_ifinit(ifp, ifa) struct ifnet *ifp; struct ifaddr *ifa; { + struct llentry *la; + + printf("arp_ifinit ifp %p addr 0x%x\n", + ifp, ntohl(IA_SIN(ifa)->sin_addr.s_addr)); + if (ntohl(IA_SIN(ifa)->sin_addr.s_addr) != INADDR_ANY) arprequest(ifp, &IA_SIN(ifa)->sin_addr, &IA_SIN(ifa)->sin_addr, IF_LLADDR(ifp)); - ifa->ifa_rtrequest = arp_rtrequest; - ifa->ifa_flags |= RTF_CLONING; + la = arplookup(ifp, IA_SIN(ifa)->sin_addr.s_addr, LLE_CREATE); + if (la) { /* store our address */ + bcopy(IF_LLADDR(ifp), &la->ll_addr, ifp->if_addrlen); + la->flags |= LLA_VALID | LLE_STATIC | LLE_IFADDR; + } + ifa->ifa_rtrequest = NULL; } static void @@ -866,9 +1162,8 @@ arp_init(void) arpintrq.ifq_maxlen = 50; mtx_init(&arpintrq.ifq_mtx, "arp_inq", NULL, MTX_DEF); - LIST_INIT(&llinfo_arp); callout_init(&arp_callout, CALLOUT_MPSAFE); netisr_register(NETISR_ARP, arpintr, &arpintrq, NETISR_MPSAFE); - callout_reset(&arp_callout, hz, arptimer, NULL); + callout_reset(&arp_callout, hz, newarptimer, NULL); } SYSINIT(arp, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, arp_init, 0); Index: src/sys/netinet/if_ether.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/if_ether.h,v retrieving revision 1.30 diff -u -p -r1.30 if_ether.h --- src/sys/netinet/if_ether.h 7 Apr 2004 20:46:13 -0000 1.30 +++ src/sys/netinet/if_ether.h 25 Apr 2004 15:09:46 -0000 @@ -112,6 +112,33 @@ extern u_char ether_ipmulticast_max[ETHE int arpresolve(struct ifnet *ifp, struct rtentry *rt, struct mbuf *m, struct sockaddr *dst, u_char *desten); void arp_ifinit(struct ifnet *, struct ifaddr *); + +/* + * Support routines for the new arp table + */ +struct lltable *lltable_new(struct ifnet *ifp, int af); +struct lltable **lltable_free(struct lltable **t); #endif +struct lltable { + struct lltable *llt_next; + void *lle_head; /* pointer to the list of address entries */ + int llt_af; /* address family */ +}; + +/* + * flags to be passed to arplookup. + */ +#define LLE_DELETED 0x0001 /* entry must be deleted */ +#define LLE_STATIC 0x0002 /* entry is static */ +#define LLE_IFADDR 0x0004 /* entry is interface addr */ +#define LLA_VALID 0x0008 /* ll_addr is valid */ +#define LLE_PROXY 0x0010 /* proxy entry ??? */ +#define LLE_PUB 0x0020 /* publish entry ??? */ +#define LLE_CREATE 0x8000 /* create on a lookup miss */ +#define LLE_DELETE 0x4000 /* delete on a lookup - match LLE_IFADDR */ + +/* + * End of support code for the new arp table + */ #endif From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 19:39:57 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 47C0D16A4CF for ; Sun, 25 Apr 2004 19:39:57 -0700 (PDT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8646043D46 for ; Sun, 25 Apr 2004 19:39:56 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i3Q2dp5v009055; Mon, 26 Apr 2004 12:39:51 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i3Q2dmI2003761; Mon, 26 Apr 2004 12:39:49 +1000 Date: Mon, 26 Apr 2004 12:39:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Burns In-Reply-To: <408BBBD3.4090200@dugeem.net> Message-ID: <20040426115156.X3272@gamplex.bde.org> References: <408A160F.4090703@dugeem.net> <20040424140143.S5713@odysseus.silby.com> <408BBBD3.4090200@dugeem.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: fast ethernet driver MII phy serial clock rates 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, 26 Apr 2004 02:39:57 -0000 On Sun, 25 Apr 2004, David Burns wrote: > Mike Silbersack wrote: > > > > On Sat, 24 Apr 2004, David Burns wrote: > >>NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't > >>think it is ... :-( > > > > Correct, DELAY takes far longer than it should. Actually, it takes at least as long as it should (normally a few microseconds longer than the specified delay, but hundreds or thousands of microseconds longer if it is interrupted). The bus ISA accesses in it can also be delayed by (PCI) bus activity (I've measured 170 usec for the 3 accesses in getit() which normally take 3-4 usec). > > If you're really interested in fixing the problem and not inadvertantly > > breaking older cards, what you should do is implement a nanodelay function > > that actually delays for the time it's supposed to and then delay the > > rated amount. Removing all delays will probably break something > > somewhere. > > We could probably build a driver specific nanodelay function based on > dummy PCI operations. Some will say this sucks but then I'd argue it's > better than the current DELAY implementation. No, it would be considerably worse. DELAY() has a poor resolution because non-dummy ISA operations that it uses to read the time are slow. Dummy PCI operations aren't much faster, depending on which address they are at. They would be at least 3 times faster in practice since the current implementation of DELAY() needs 3 ISA operations. DELAY() could probably use only the low byte of an unlatched counter if its efficiency were important. I think it is unimportant, since only broken code uses busy-wait. Anyway, you won't get near nansoseconds reasolution or PCI clock resolution (30 nsec) using PCI i/o instructions. rdtsc on i386's and delay loops on all machines can easily do better provided the CPU doesn't get throttled. > Of course just sending one bit of data on the MDIO will take us about > 600 nanoseconds - resulting in a 1.6MHz clock. Except some machines add lots of wait states. I have a PCI card which can usually be accessed in 467 nsec (write) and 150 nsec (read) on one machine, but on a newer machine which is otherwise 6 times faster but appears to have a slow PCI bugs (ASUS A7N8X-E), the access times increase to 943 nsec (write) and 290 nsec (read). Bruce From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 21:26: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 9B04316A4CE for ; Sun, 25 Apr 2004 21:26:19 -0700 (PDT) Received: from mail022.syd.optusnet.com.au (mail022.syd.optusnet.com.au [211.29.132.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 729C643D2F for ; Sun, 25 Apr 2004 21:26:18 -0700 (PDT) (envelope-from david.burns@dugeem.net) Received: from dugeem.net (c211-30-248-50.carlnfd2.nsw.optusnet.com.au [211.30.248.50])i3Q4QBj31220; Mon, 26 Apr 2004 14:26:11 +1000 Message-ID: <408C8F55.1080001@dugeem.net> Date: Mon, 26 Apr 2004 14:25:57 +1000 From: David Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Bruce Evans References: <408A160F.4090703@dugeem.net> <20040424140143.S5713@odysseus.silby.com> <408BBBD3.4090200@dugeem.net> <20040426115156.X3272@gamplex.bde.org> In-Reply-To: <20040426115156.X3272@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: fast ethernet driver MII phy serial clock rates 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, 26 Apr 2004 04:26:19 -0000 Bruce Evans wrote: > On Sun, 25 Apr 2004, David Burns wrote: > >>Mike Silbersack wrote: >> >>>On Sat, 24 Apr 2004, David Burns wrote: >>> >>>>NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't >>>>think it is ... :-( >>> >>>Correct, DELAY takes far longer than it should. > > Actually, it takes at least as long as it should (normally a few > microseconds longer than the specified delay, but hundreds or thousands > of microseconds longer if it is interrupted). The bus ISA accesses in > it can also be delayed by (PCI) bus activity (I've measured 170 usec for > the 3 accesses in getit() which normally take 3-4 usec). > No argument that a DELAY(x) delays for a minimum of x microseconds - this is what we're seeing. The fact that we're using a DELAY() which can be interrupted inside locked code seems problematic - although I guess it just slows driver operation down. > >>>If you're really interested in fixing the problem and not inadvertantly >>>breaking older cards, what you should do is implement a nanodelay function >>>that actually delays for the time it's supposed to and then delay the >>>rated amount. Removing all delays will probably break something >>>somewhere. >> >>We could probably build a driver specific nanodelay function based on >>dummy PCI operations. Some will say this sucks but then I'd argue it's >>better than the current DELAY implementation. > > > No, it would be considerably worse. DELAY() has a poor resolution > because non-dummy ISA operations that it uses to read the time are > slow. Dummy PCI operations aren't much faster, depending on which > address they are at. They would be at least 3 times faster in practice > since the current implementation of DELAY() needs 3 ISA operations. > DELAY() could probably use only the low byte of an unlatched counter > if its efficiency were important. I think it is unimportant, since > only broken code uses busy-wait. Sorry I should have made myself clearer. Given the evidence that a DELAY(1) delays for far more than 1 microsecond we just need some other kind of known delay which will allow us to wait a few hundred nanoseconds (the MDIO clock period of most 100Mb/s PHYs) instead of a DELAY which is an order of magnitude higher (and is subject to interrupts). A dummy PCI operation would achieve this. > > Anyway, you won't get near nansoseconds reasolution or PCI clock > resolution (30 nsec) using PCI i/o instructions. rdtsc on i386's and > delay loops on all machines can easily do better provided the CPU > doesn't get throttled. > Yes the term nanosecond delay is inappropriate - when it is only a submicrosecond delay we need. > >>Of course just sending one bit of data on the MDIO will take us about >>600 nanoseconds - resulting in a 1.6MHz clock. > > > Except some machines add lots of wait states. I have a PCI card which > can usually be accessed in 467 nsec (write) and 150 nsec (read) on one > machine, but on a newer machine which is otherwise 6 times faster but > appears to have a slow PCI bugs (ASUS A7N8X-E), the access times > increase to 943 nsec (write) and 290 nsec (read). > A PCI implementation built from ISA components perhaps ... :-) It still comes back to slowing down PHY accesses without using DELAY(). The fact that ste DELAY() removal provided a small but non-trivial improvement in network performance (including other network cards on the same PCI bus) underlines how horrible the use of DELAY() is. I'm only after a simple fix - experiment with removal of MII code DELAY() on the affected drivers and commit the change only where testing results are good. David From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 22:37:54 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 9DDDD16A4CE; Sun, 25 Apr 2004 22:37:54 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96F7843D1F; Sun, 25 Apr 2004 22:37:52 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i3Q5blaB098866; Mon, 26 Apr 2004 13:37:48 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <408CA012.AF5018B@kuzbass.ru> Date: Mon, 26 Apr 2004 13:37:22 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20040422130659.GG722@empiric.dek.spc.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org Subject: BGP MD5: compatibility for STABLE? 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, 26 Apr 2004 05:37:54 -0000 Hi! What is the current status of BGP MD5 support for STABLE branch? I know that STABLE has TCP_SIGNATURE kernel option for basic compatibility with Cisco BGP neighbors but wonder if zebra/quagga/something have RFC 2385 support for FreeBSD? Are there corresponding patches for routing daemons available to public? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 22:39:06 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 4976716A4CE; Sun, 25 Apr 2004 22:39:06 -0700 (PDT) Received: from xraided.net (xraided.net [66.88.26.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A0BE43D3F; Sun, 25 Apr 2004 22:39:06 -0700 (PDT) (envelope-from owner-freebsd-stable@freebsd.org) Received: by xraided.net (CommuniGate Pro PIPE 4.1.8) with PIPE id 1710863; Sun, 25 Apr 2004 22:39:06 -0700 X-PolluStop-Diagnostic: ########## X-PolluStop-Score: 1.00 X-PolluStop: Scanned with Niversoft PolluStop 2.0 public beta 7, http://www.niversoft.com/pollustop Received: from mx2.freebsd.org ([216.136.204.119] verified) by xraided.net (CommuniGate Pro SMTP 4.1.8) with SMTP id 1710862 for kyle@xraided.net; Sun, 25 Apr 2004 22:38:56 -0700 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 9A2C255FCD; Sun, 25 Apr 2004 22:38:20 -0700 (PDT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0EA2416A4E4; Sun, 25 Apr 2004 22:38:20 -0700 (PDT) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DDDD16A4CE; Sun, 25 Apr 2004 22:37:54 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96F7843D1F; Sun, 25 Apr 2004 22:37:52 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i3Q5blaB098866; Mon, 26 Apr 2004 13:37:48 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <408CA012.AF5018B@kuzbass.ru> Date: Mon, 26 Apr 2004 13:37:22 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20040422130659.GG722@empiric.dek.spc.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org cc: freebsd-stable@freebsd.org Subject: [SPAM] BGP MD5: compatibility for STABLE? X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2004 05:39:06 -0000 Hi! What is the current status of BGP MD5 support for STABLE branch? I know that STABLE has TCP_SIGNATURE kernel option for basic compatibility with Cisco BGP neighbors but wonder if zebra/quagga/something have RFC 2385 support for FreeBSD? Are there corresponding patches for routing daemons available to public? Eugene Grosbein _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 02:59:02 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 5350916A4CE; Mon, 26 Apr 2004 02:59:02 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68D6843D58; Mon, 26 Apr 2004 02:59:00 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i3Q9wuYH029082; Mon, 26 Apr 2004 17:58:56 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <408CDD45.4EFA2085@kuzbass.ru> Date: Mon, 26 Apr 2004 17:58:29 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: tackerman@freebsd.org Subject: em(4) link flapping 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, 26 Apr 2004 09:59:02 -0000 Hi! My Intel motherboard contains on-boad NIC: em0: port 0xac00-0xac1f mem 0xfe9e0000-0xfe9fffff irq 10 at device 1.0 on pci2 It it connected to Allied Telesyn AT FS724i unmanaged switch, media is autodetected correctly - 100baseTX full-duplex. It worked nice for 3 months. Today morning switch and em0 start to loose/establish link every 5-10 seconds. They do it with autosensed media and with manually set 100baseTX (both half-duplex or full-duplex variants) now. I've forced it to 10mbit/half duplex, it seems to be much stable. This box has two more PCI ethernet cards, each of which is two-port em(4), so I have em0 (that has problems) and em1, em2, em3 and em4 (that keep working OK). I tried to replace a cable, to reset the switch, to reboot this 4.9-STABLE box - nothing helps. What should I try next? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 05:14:17 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 DE6A116A4CE for ; Mon, 26 Apr 2004 05:14:17 -0700 (PDT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A7A943D67 for ; Mon, 26 Apr 2004 05:14:17 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i3QCBFg7037435 for net@freebsd.org.checked; (8.12.8/vak/2.1) Mon, 26 Apr 2004 16:11:15 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i3QCAOOx037374; (8.12.8/vak/2.1) Mon, 26 Apr 2004 16:10:24 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <408CFC60.4040708@cronyx.ru> Date: Mon, 26 Apr 2004 16:11:12 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eugene Grosbein References: <408CDD45.4EFA2085@kuzbass.ru> In-Reply-To: <408CDD45.4EFA2085@kuzbass.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: tackerman@freebsd.org cc: net@freebsd.org Subject: Re: em(4) link flapping 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, 26 Apr 2004 12:14:18 -0000 Eugene Grosbein wrote: >Hi! > >My Intel motherboard contains on-boad NIC: > >em0: port >0xac00-0xac1f mem 0xfe9e0000-0xfe9fffff irq 10 at device 1.0 on pci2 > >It it connected to Allied Telesyn AT FS724i unmanaged switch, >media is autodetected correctly - 100baseTX full-duplex. > >It worked nice for 3 months. Today morning switch and em0 >start to loose/establish link every 5-10 seconds. They do it >with autosensed media and with manually set 100baseTX (both half-duplex >or full-duplex variants) now. I've forced it to 10mbit/half duplex, >it seems to be much stable. > >This box has two more PCI ethernet cards, each of which is two-port em(4), >so I have em0 (that has problems) and em1, em2, em3 and em4 >(that keep working OK). > >I tried to replace a cable, to reset the switch, to reboot this 4.9-STABLE >box - nothing helps. What should I try next? > > Did you tried another port on a switch? Best regards, rik >Eugene Grosbein >_______________________________________________ >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 Mon Apr 26 05:47:17 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 7D8F916A4CE; Mon, 26 Apr 2004 05:47:17 -0700 (PDT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id C912E43D58; Mon, 26 Apr 2004 05:47:13 -0700 (PDT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.11/8.12.11) with ESMTP id i3QCkW0E000719; Mon, 26 Apr 2004 20:46:32 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i3QCkWvZ000718; Mon, 26 Apr 2004 20:46:32 +0800 (KRAST) (envelope-from eugen) Date: Mon, 26 Apr 2004 20:46:32 +0800 From: Eugene Grosbein To: Roman Kurakin Message-ID: <20040426124632.GA685@grosbein.pp.ru> References: <408CDD45.4EFA2085@kuzbass.ru> <408CFC60.4040708@cronyx.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <408CFC60.4040708@cronyx.ru> User-Agent: Mutt/1.4.1i cc: tackerman@freebsd.org cc: net@freebsd.org Subject: Re: em(4) link flapping 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, 26 Apr 2004 12:47:17 -0000 On Mon, Apr 26, 2004 at 04:11:12PM +0400, Roman Kurakin wrote: > >I tried to replace a cable, to reset the switch, to reboot this 4.9-STABLE > >box - nothing helps. What should I try next? > Did you tried another port on a switch? Yes, I tried several. No change. All other ports of switch carry 100Mbit links fine. Eugene From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 06:23: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 AC80616A4CE for ; Mon, 26 Apr 2004 06:23:03 -0700 (PDT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03B2843D39 for ; Mon, 26 Apr 2004 06:23:03 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i3QDKCsq040596 for net@freebsd.org.checked; (8.12.8/vak/2.1) Mon, 26 Apr 2004 17:20:12 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i3QDHTo9040365; (8.12.8/vak/2.1) Mon, 26 Apr 2004 17:17:29 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <408D0C19.2040409@cronyx.ru> Date: Mon, 26 Apr 2004 17:18:17 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eugene Grosbein References: <408CDD45.4EFA2085@kuzbass.ru> <408CFC60.4040708@cronyx.ru> <20040426124632.GA685@grosbein.pp.ru> In-Reply-To: <20040426124632.GA685@grosbein.pp.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: tackerman@freebsd.org cc: net@freebsd.org Subject: Re: em(4) link flapping 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, 26 Apr 2004 13:23:03 -0000 Eugene Grosbein wrote: >On Mon, Apr 26, 2004 at 04:11:12PM +0400, Roman Kurakin wrote: > > >>>I tried to replace a cable, to reset the switch, to reboot this 4.9-STABLE >>>box - nothing helps. What should I try next? >>> >>> >>Did you tried another port on a switch? >> >> >Yes, I tried several. No change. All other ports of switch >carry 100Mbit links fine. > > Try to plug it to another hardware, other switch or other computer to be sure. I think this hardware problem, not software one. And I hope you have a warranty. rik >Eugene >_______________________________________________ >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 Mon Apr 26 07:43:55 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 DB00116A4CE for ; Mon, 26 Apr 2004 07:43:55 -0700 (PDT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 894C143D39 for ; Mon, 26 Apr 2004 07:43:55 -0700 (PDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i3QEhtdD060293; Mon, 26 Apr 2004 10:43:55 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.10/8.12.10) with ESMTP id i3QEhr3x008238; Mon, 26 Apr 2004 10:43:54 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i3QEhlqZ062650; Mon, 26 Apr 2004 10:43:47 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.0.3.0.0.20040426104224.09809978@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 26 Apr 2004 10:45:21 -0400 To: Eugene Grosbein , freebsd-net@freebsd.org From: Mike Tancsa In-Reply-To: <408CA012.AF5018B@kuzbass.ru> References: <20040422130659.GG722@empiric.dek.spc.org> <408CA012.AF5018B@kuzbass.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new Subject: Re: BGP MD5: compatibility for STABLE? 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, 26 Apr 2004 14:43:56 -0000 At 01:37 AM 26/04/2004, Eugene Grosbein wrote: >Are there corresponding patches for routing daemons available to public? The links were posted a few times. The keywords "bgp md5 quagga freebsd patches" in google first link points to http://lists.quagga.net/pipermail/quagga-users/2004-February/001469.html which has the links to what you are after. The above link even has instructions on what to do. ---Mike From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 07:56:41 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 D1DC316A4CE for ; Mon, 26 Apr 2004 07:56:41 -0700 (PDT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9627443D58 for ; Mon, 26 Apr 2004 07:56:40 -0700 (PDT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.11/8.12.11) with ESMTP id i3QEubpb000628; Mon, 26 Apr 2004 22:56:37 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i3QEubpG000627; Mon, 26 Apr 2004 22:56:37 +0800 (KRAST) (envelope-from eugen) Date: Mon, 26 Apr 2004 22:56:37 +0800 From: Eugene Grosbein To: Mike Tancsa Message-ID: <20040426145637.GB398@grosbein.pp.ru> References: <20040422130659.GG722@empiric.dek.spc.org> <408CA012.AF5018B@kuzbass.ru> <6.0.3.0.0.20040426104224.09809978@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.3.0.0.20040426104224.09809978@64.7.153.2> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: BGP MD5: compatibility for STABLE? 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, 26 Apr 2004 14:56:42 -0000 On Mon, Apr 26, 2004 at 10:45:21AM -0400, Mike Tancsa wrote: > >Are there corresponding patches for routing daemons available to public? > > The links were posted a few times. The keywords "bgp md5 quagga freebsd > patches" in google first link points to > http://lists.quagga.net/pipermail/quagga-users/2004-February/001469.html > which has the links to what you are after. Thank you very much, I'll go for it. It would be nice if patches where in the ports tree until they included in the vendor distribution. That is what ports are for, aren't they? Eugene From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 11:01:30 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 260F316A4CE for ; Mon, 26 Apr 2004 11:01:30 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08B7D43D49 for ; Mon, 26 Apr 2004 11:01:30 -0700 (PDT) (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 i3QI1TWJ045417 for ; Mon, 26 Apr 2004 11:01:29 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i3QI1T0D045411 for freebsd-net@freebsd.org; Mon, 26 Apr 2004 11:01:29 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 26 Apr 2004 11:01:29 -0700 (PDT) Message-Id: <200404261801.i3QI1T0D045411@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, 26 Apr 2004 18:01:30 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 11:22:44 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 1231116A4CE for ; Mon, 26 Apr 2004 11:22:44 -0700 (PDT) Received: from web13506.mail.yahoo.com (web13506.mail.yahoo.com [216.136.175.85]) by mx1.FreeBSD.org (Postfix) with SMTP id E086143D4C for ; Mon, 26 Apr 2004 11:22:43 -0700 (PDT) (envelope-from dyeske@yahoo.com) Message-ID: <20040426182243.59597.qmail@web13506.mail.yahoo.com> Received: from [216.162.35.42] by web13506.mail.yahoo.com via HTTP; Mon, 26 Apr 2004 11:22:43 PDT Date: Mon, 26 Apr 2004 11:22:43 -0700 (PDT) From: David Yeske To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: netgraph arp issues vs linux veth 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, 26 Apr 2004 18:22:44 -0000 I made another attempt with netgraph and I think I'm almost there, but I'm still having some issues. I found a linux solution called veth http://www.geocities.com/nestorjpg/veth/ which might do the job, but I would prefer to use netgraph if possible. Here is some more detailed config information. I ran this on the spoof machine # ngctl mkpeer . eiface hook ether # ifconfig ngeth0 link 00:bd:03:12:12:12 # ifconfig ngeth0 192.168.10.3 netmask 255.255.255.0 # ngctl mkpeer ngeth0: bridge lower link0 # ngctl name ngeth0:lower broken # ngctl connect fxp0: broken: lower link1 # ngctl connect fxp0: broken: upper link2 # ngctl connect ngeth0: broken: upper link3 # ngctl msg ngeth0: setpromisc 1 # ngctl msg ngeth0: setautosrc 0 # ngctl msg fxp0: setpromisc 1 # ngctl msg fxp0: setautosrc 0 # ngctl show broken: Name: broken Type: bridge ID: 00000046 Num hooks: 4 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- link3 ngeth0 ether 00000005 upper link2 fxp0 ether 00000004 upper link1 fxp0 ether 00000004 lower link0 ngeth0 ether 00000005 lower on the remote machine an arp -a lists this ? (192.168.10.3) at 00:bd:03:12:12:12 on rl0 [ethernet] ? (192.168.10.1) at 00:00:e8:5b:13:44 on rl0 permanent [ethernet] on the spoof machine an arp -a lists this ? (192.168.10.1) at (incomplete) on ngeth0 [ethernet] ? (192.168.10.3) at 00:bd:03:12:12:12 on ngeth0 permanent [ethernet] a sniff on the spoof machine listed this while pinging the remote machine # tcpdump -i ngeth0 'ether host 00:00:e8:5b:13:44' tcpdump: listening on ngeth0 14:03:30.519263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:03:33.416568 192.168.10.1 > 192.168.10.3: icmp: echo request 14:03:40.530562 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:03:43.427175 192.168.10.1 > 192.168.10.3: icmp: echo request 14:03:50.540805 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:03:53.437845 192.168.10.1 > 192.168.10.3: icmp: echo request 14:04:00.550960 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:04:03.448383 192.168.10.1 > 192.168.10.3: icmp: echo request a sniff on the remote machine listed this while pinging the spoof machine # tcpdump -i rl0 'ether host 00:bd:03:12:12:12' tcpdump: listening on rl0 14:02:24.918804 192.168.10.1 > 192.168.10.3: icmp: echo request 14:02:29.179263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:02:34.929051 192.168.10.1 > 192.168.10.3: icmp: echo request 14:02:44.939136 192.168.10.1 > 192.168.10.3: icmp: echo request 14:02:52.052260 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:02:54.949402 192.168.10.1 > 192.168.10.3: icmp: echo request 14:03:02.063079 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:03:04.959534 192.168.10.1 > 192.168.10.3: icmp: echo request 14:03:12.072830 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 Any clues or pointers are greatly appreciated and will mean I get to deploy FreeBSD with netgraph rather than linux with veth. Regards, David Yeske From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 11:43: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 36ABD16A4CF for ; Mon, 26 Apr 2004 11:43:23 -0700 (PDT) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6ECA43D48 for ; Mon, 26 Apr 2004 11:43:22 -0700 (PDT) (envelope-from ghelmer@palisadesys.com) Received: from mira (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0)i3QIgKMt089970 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 26 Apr 2004 13:42:20 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) From: "Guy Helmer" To: "David Yeske" , Date: Mon, 26 Apr 2004 13:42:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040426182243.59597.qmail@web13506.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Subject: RE: netgraph arp issues vs linux veth 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, 26 Apr 2004 18:43:23 -0000 David Yeske wrote on April 26, 2004 1:23 PM > I made another attempt with netgraph and I think I'm almost there, but I'm > still having some issues. I found a linux solution called veth > http://www.geocities.com/nestorjpg/veth/ which might do the job, > but I would > prefer to use netgraph if possible. Here is some more detailed config > information. > > I ran this on the spoof machine > > # ngctl mkpeer . eiface hook ether > # ifconfig ngeth0 link 00:bd:03:12:12:12 > # ifconfig ngeth0 192.168.10.3 netmask 255.255.255.0 > ... Yes, I initially thought this would be a great solution until I remembered how the machine would route 192.168.10.3, as you found below: > on the remote machine an arp -a lists this > ? (192.168.10.3) at 00:bd:03:12:12:12 on rl0 [ethernet] > ? (192.168.10.1) at 00:00:e8:5b:13:44 on rl0 permanent [ethernet] > ... > a sniff on the spoof machine listed this while pinging the remote machine > > # tcpdump -i ngeth0 'ether host 00:00:e8:5b:13:44' > tcpdump: listening on ngeth0 > 14:03:30.519263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > ... > > a sniff on the remote machine listed this while pinging the spoof machine > > # tcpdump -i rl0 'ether host 00:bd:03:12:12:12' > tcpdump: listening on rl0 > 14:02:24.918804 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:02:29.179263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 Doug Ambrisko and I discussed this routing issue a couple of years ago. Doug wrote a layer-2 network address translator to work around the fact that multiple IP addresses in a single subnet on a computer will route all traffic for that subnet through one interface, resulting in the same Ethernet MAC address irrespective of the IP address. I didn't have the time or hard requirement to implement Doug's solution, though. Perhaps Doug would be willing to help; I've Cc:ed him. Guy Helmer, Ph.D. Principal System Architect Palisade Systems, Inc. From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 13:02: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 3737916A4CE for ; Mon, 26 Apr 2004 13:02:52 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id E309C43D64 for ; Mon, 26 Apr 2004 13:02:51 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <20040426200250012002so51e>; Mon, 26 Apr 2004 20:02:51 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA46684; Mon, 26 Apr 2004 13:02:50 -0700 (PDT) Date: Mon, 26 Apr 2004 13:02:48 -0700 (PDT) From: Julian Elischer To: David Yeske In-Reply-To: <20040426182243.59597.qmail@web13506.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: netgraph arp issues vs linux veth 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, 26 Apr 2004 20:02:52 -0000 On Mon, 26 Apr 2004, David Yeske wrote: > I made another attempt with netgraph and I think I'm almost there, but I'm > still having some issues. I found a linux solution called veth > http://www.geocities.com/nestorjpg/veth/ which might do the job, but I would > prefer to use netgraph if possible. Here is some more detailed config > information. > > I ran this on the spoof machine > > # ngctl mkpeer . eiface hook ether > # ifconfig ngeth0 link 00:bd:03:12:12:12 > # ifconfig ngeth0 192.168.10.3 netmask 255.255.255.0 > > # ngctl mkpeer ngeth0: bridge lower link0 the lower hook of an ngether node does what exactly? [goes off to read code...] ok the hook really should be called "ether" are you SURE you didn't get an error? > # ngctl name ngeth0:lower broken > # ngctl connect fxp0: broken: lower link1 > # ngctl connect fxp0: broken: upper link2 > # ngctl connect ngeth0: broken: upper link3 > # ngctl msg ngeth0: setpromisc 1 > # ngctl msg ngeth0: setautosrc 0 > # ngctl msg fxp0: setpromisc 1 > # ngctl msg fxp0: setautosrc 0 > > # ngctl show broken: > Name: broken Type: bridge ID: 00000046 Num hooks: 4 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > link3 ngeth0 ether 00000005 upper > link2 fxp0 ether 00000004 upper > link1 fxp0 ether 00000004 lower > link0 ngeth0 ether 00000005 lower try this instead: ngctl mkpeer fxp0: bridge lower link1 ngctl name fxp0:lower bridge ngctl connect fxp0: bridge: upper link2 ngctl msg fxp0: setpromisc 1 ngctl msg fxp0: setautosrc 0 if ngeth0 already exists.. ngctl connect bridge: ngeth0: link2 ether if not then.. ngctl mkpeer bridge: eiface link2 ether ifconfig ngeth0 link 00:bd:03:12:12:12 ifconfig ngeth0 192.168.10.3 netmask 255.255.255.0 > > on the remote machine an arp -a lists this > ? (192.168.10.3) at 00:bd:03:12:12:12 on rl0 [ethernet] > ? (192.168.10.1) at 00:00:e8:5b:13:44 on rl0 permanent [ethernet] > > on the spoof machine an arp -a lists this > ? (192.168.10.1) at (incomplete) on ngeth0 [ethernet] > ? (192.168.10.3) at 00:bd:03:12:12:12 on ngeth0 permanent [ethernet] > > a sniff on the spoof machine listed this while pinging the remote machine > > # tcpdump -i ngeth0 'ether host 00:00:e8:5b:13:44' > tcpdump: listening on ngeth0 > 14:03:30.519263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:33.416568 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:40.530562 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:43.427175 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:50.540805 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:53.437845 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:04:00.550960 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:04:03.448383 192.168.10.1 > 192.168.10.3: icmp: echo request > > a sniff on the remote machine listed this while pinging the spoof machine > > # tcpdump -i rl0 'ether host 00:bd:03:12:12:12' > tcpdump: listening on rl0 > 14:02:24.918804 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:02:29.179263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:02:34.929051 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:02:44.939136 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:02:52.052260 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:02:54.949402 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:02.063079 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:04.959534 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:12.072830 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > > Any clues or pointers are greatly appreciated and will mean I get to deploy > FreeBSD with netgraph rather than linux with veth. > > Regards, > David Yeske > > _______________________________________________ > 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 Mon Apr 26 13:13: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 ECA4516A4CE for ; Mon, 26 Apr 2004 13:13:03 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C619343D46 for ; Mon, 26 Apr 2004 13:13:03 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004042620130301400icc9pe>; Mon, 26 Apr 2004 20:13:03 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA46817; Mon, 26 Apr 2004 13:13:02 -0700 (PDT) Date: Mon, 26 Apr 2004 13:13:00 -0700 (PDT) From: Julian Elischer To: David Yeske In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: netgraph arp issues vs linux veth 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, 26 Apr 2004 20:13:04 -0000 On Mon, 26 Apr 2004, Julian Elischer wrote: > > > On Mon, 26 Apr 2004, David Yeske wrote: > > > I made another attempt with netgraph and I think I'm almost there, but I'm > > still having some issues. I found a linux solution called veth > > http://www.geocities.com/nestorjpg/veth/ which might do the job, but I would > > prefer to use netgraph if possible. Here is some more detailed config > > information. > > > > I ran this on the spoof machine > > > > # ngctl mkpeer . eiface hook ether > > # ifconfig ngeth0 link 00:bd:03:12:12:12 > > # ifconfig ngeth0 192.168.10.3 netmask 255.255.255.0 > > > > # ngctl mkpeer ngeth0: bridge lower link0 > > > the lower hook of an ngether node does what exactly? > [goes off to read code...] > > ok the hook really should be called "ether" > are you SURE you didn't get an error? aaahhhh I see it gets an 'ether' node attached to it.. how "humourous".. > > > > > # ngctl name ngeth0:lower broken > > # ngctl connect fxp0: broken: lower link1 > > # ngctl connect fxp0: broken: upper link2 > > # ngctl connect ngeth0: broken: upper link3 > > # ngctl msg ngeth0: setpromisc 1 > > # ngctl msg ngeth0: setautosrc 0 > > # ngctl msg fxp0: setpromisc 1 > > # ngctl msg fxp0: setautosrc 0 > > > > # ngctl show broken: > > Name: broken Type: bridge ID: 00000046 Num hooks: 4 > > Local hook Peer name Peer type Peer ID Peer hook > > ---------- --------- --------- ------- --------- > > link3 ngeth0 ether 00000005 upper > > link2 fxp0 ether 00000004 upper > > link1 fxp0 ether 00000004 lower > > link0 ngeth0 ether 00000005 lower > > > > > try this instead: > > > ngctl mkpeer fxp0: bridge lower link1 > ngctl name fxp0:lower bridge > ngctl connect fxp0: bridge: upper link2 > ngctl msg fxp0: setpromisc 1 > ngctl msg fxp0: setautosrc 0 > > > if ngeth0 already exists.. > > ngctl connect bridge: ngeth0: link2 ether > > if not then.. > > ngctl mkpeer bridge: eiface link2 ether > > ifconfig ngeth0 link 00:bd:03:12:12:12 > ifconfig ngeth0 192.168.10.3 netmask 255.255.255.0 > don't worry.. I wasn't realising about the 'ether' node attaching itself to the 'eiface' node... (a node on a node.. funny..) > > > > > > on the remote machine an arp -a lists this > > ? (192.168.10.3) at 00:bd:03:12:12:12 on rl0 [ethernet] > > ? (192.168.10.1) at 00:00:e8:5b:13:44 on rl0 permanent [ethernet] > > > > on the spoof machine an arp -a lists this > > ? (192.168.10.1) at (incomplete) on ngeth0 [ethernet] > > ? (192.168.10.3) at 00:bd:03:12:12:12 on ngeth0 permanent [ethernet] > > > > a sniff on the spoof machine listed this while pinging the remote machine > > > > # tcpdump -i ngeth0 'ether host 00:00:e8:5b:13:44' > > tcpdump: listening on ngeth0 > > 14:03:30.519263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > > 14:03:33.416568 192.168.10.1 > 192.168.10.3: icmp: echo request > > 14:03:40.530562 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > > 14:03:43.427175 192.168.10.1 > 192.168.10.3: icmp: echo request > > 14:03:50.540805 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > > 14:03:53.437845 192.168.10.1 > 192.168.10.3: icmp: echo request > > 14:04:00.550960 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > > 14:04:03.448383 192.168.10.1 > 192.168.10.3: icmp: echo request > > > > a sniff on the remote machine listed this while pinging the spoof machine > > > > # tcpdump -i rl0 'ether host 00:bd:03:12:12:12' > > tcpdump: listening on rl0 > > 14:02:24.918804 192.168.10.1 > 192.168.10.3: icmp: echo request > > 14:02:29.179263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > > 14:02:34.929051 192.168.10.1 > 192.168.10.3: icmp: echo request > > 14:02:44.939136 192.168.10.1 > 192.168.10.3: icmp: echo request > > 14:02:52.052260 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > > 14:02:54.949402 192.168.10.1 > 192.168.10.3: icmp: echo request > > 14:03:02.063079 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > > 14:03:04.959534 192.168.10.1 > 192.168.10.3: icmp: echo request > > 14:03:12.072830 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > > > > Any clues or pointers are greatly appreciated and will mean I get to deploy > > FreeBSD with netgraph rather than linux with veth. > > > > Regards, > > David Yeske > > > > _______________________________________________ > > 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" > > > > _______________________________________________ > 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 Mon Apr 26 14:27:24 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 50B7116A4CE for ; Mon, 26 Apr 2004 14:27:24 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 126B243D49 for ; Mon, 26 Apr 2004 14:27:24 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 34A00651EE; Mon, 26 Apr 2004 22:27:22 +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 98676-01-4; Mon, 26 Apr 2004 22:27:21 +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 06B5A651EB; Mon, 26 Apr 2004 22:27:21 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 5C2EE60EE; Mon, 26 Apr 2004 22:27:20 +0100 (BST) Date: Mon, 26 Apr 2004 22:27:20 +0100 From: Bruce M Simpson To: Eugene Grosbein Message-ID: <20040426212720.GB33708@empiric.dek.spc.org> Mail-Followup-To: Eugene Grosbein , Mike Tancsa , freebsd-net@freebsd.org References: <20040422130659.GG722@empiric.dek.spc.org> <408CA012.AF5018B@kuzbass.ru> <6.0.3.0.0.20040426104224.09809978@64.7.153.2> <20040426145637.GB398@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040426145637.GB398@grosbein.pp.ru> cc: freebsd-net@freebsd.org cc: Mike Tancsa Subject: Re: BGP MD5: compatibility for STABLE? 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, 26 Apr 2004 21:27:24 -0000 On Mon, Apr 26, 2004 at 10:56:37PM +0800, Eugene Grosbein wrote: > It would be nice if patches where in the ports tree until they included > in the vendor distribution. That is what ports are for, aren't they? I haven't gotten round to this, my bad, and we're currently in freeze. Regards BMS From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 19:44:32 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 8951B16A4CE for ; Mon, 26 Apr 2004 19:44:32 -0700 (PDT) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CDCD43D45 for ; Mon, 26 Apr 2004 19:44:25 -0700 (PDT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 65833 invoked from network); 27 Apr 2004 03:04:41 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 27 Apr 2004 03:04:41 -0000 Received: (nullmailer pid 1421 invoked by uid 136); Tue, 27 Apr 2004 02:44:20 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <8765bt18md.wl@jchurch.neville-neil.com.neville-neil.com> To: "George V. Neville-Neil" Date: Tue, 27 Apr 2004 06:44:20 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1083033860.265497.1420.nullmailer@cicuta.babolo.ru> cc: Chance Whaley cc: net@freebsd.org Subject: Re: Opinions on "best" NIC for high-touch applications 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, 27 Apr 2004 02:44:32 -0000 > At Wed, 21 Apr 2004 09:36:45 -0700 (PDT), > Chance Whaley wrote: > > I have an application where I am doing quite a bit of high-touch packet > > fiddling and I am looking for opinions on which "standard" Gb NIC > > has the best driver support in 5.2 or CURRENT. > > > > In my dream world I am looking for something that supports: > > - IRQ mitigation / polling (absolute must) > > - PCI-X (absolute must) > > - HW checksumming > > - Scatter / Gather > > - IPsec > > - Jumbo frames > > - VLANs > > > > Thoughts?? > > > > I think you want the Netear Copper Gigiabit Adapter (GA302T) which is > well supported in 5.x. > > I don't know if it supports all that you want, but you should check it > out at least. The driver is if_bge.c. PR kern/61109 From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 01:15:02 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 6F19616A4CE for ; Tue, 27 Apr 2004 01:15:02 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1357A43D67 for ; Tue, 27 Apr 2004 01:15:01 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3R8K8Gu094674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2004 11:20:10 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3R8EqCb043472; Tue, 27 Apr 2004 11:14:52 +0300 (EEST) (envelope-from ru) Date: Tue, 27 Apr 2004 11:14:52 +0300 From: Ruslan Ermilov To: David Yeske Message-ID: <20040427081452.GA43360@ip.net.ua> References: <20040426182243.59597.qmail@web13506.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20040426182243.59597.qmail@web13506.mail.yahoo.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: netgraph arp issues vs linux veth 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, 27 Apr 2004 08:15:02 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2004 at 11:22:43AM -0700, David Yeske wrote: > I made another attempt with netgraph and I think I'm almost there, but I'm > still having some issues. I found a linux solution called veth > http://www.geocities.com/nestorjpg/veth/ which might do the job, but I wo= uld > prefer to use netgraph if possible. Here is some more detailed config > information. >=20 > I ran this on the spoof machine >=20 > # ngctl mkpeer . eiface hook ether > # ifconfig ngeth0 link 00:bd:03:12:12:12 > # ifconfig ngeth0 192.168.10.3 netmask 255.255.255.0 >=20 > # ngctl mkpeer ngeth0: bridge lower link0 > # ngctl name ngeth0:lower broken > # ngctl connect fxp0: broken: lower link1 > # ngctl connect fxp0: broken: upper link2 > # ngctl connect ngeth0: broken: upper link3 > # ngctl msg ngeth0: setpromisc 1 > # ngctl msg ngeth0: setautosrc 0 > # ngctl msg fxp0: setpromisc 1 > # ngctl msg fxp0: setautosrc 0 >=20 > # ngctl show broken: > Name: broken Type: bridge ID: 00000046 Num hooks: 4 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > link3 ngeth0 ether 00000005 upper > link2 fxp0 ether 00000004 upper > link1 fxp0 ether 00000004 lower > link0 ngeth0 ether 00000005 lower >=20 I experminted a bit more here, and it turns out that this can be further simplified. Instead of attaching both "lower" and "upper' of ngeth0: ("ether" node type) to the bridge, you can only attach "eiface" node's "ether" hook to the bridge (i.e., the corresponding "ether" node type will be left unconnected). So bridge will be with three links: fxp0:lower, fxp0:upper, and [eiface]:ether. > on the remote machine an arp -a lists this > ? (192.168.10.3) at 00:bd:03:12:12:12 on rl0 [ethernet]=20 > ? (192.168.10.1) at 00:00:e8:5b:13:44 on rl0 permanent [ethernet] >=20 > on the spoof machine an arp -a lists this > ? (192.168.10.1) at (incomplete) on ngeth0 [ethernet] > ? (192.168.10.3) at 00:bd:03:12:12:12 on ngeth0 permanent [ethernet] >=20 > a sniff on the spoof machine listed this while pinging the remote machine >=20 > # tcpdump -i ngeth0 'ether host 00:00:e8:5b:13:44' > tcpdump: listening on ngeth0 > 14:03:30.519263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:33.416568 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:40.530562 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:43.427175 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:50.540805 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:53.437845 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:04:00.550960 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:04:03.448383 192.168.10.1 > 192.168.10.3: icmp: echo request >=20 > a sniff on the remote machine listed this while pinging the spoof machine >=20 > # tcpdump -i rl0 'ether host 00:bd:03:12:12:12' > tcpdump: listening on rl0 > 14:02:24.918804 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:02:29.179263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:02:34.929051 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:02:44.939136 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:02:52.052260 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:02:54.949402 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:02.063079 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:04.959534 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:12.072830 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 >=20 > Any clues or pointers are greatly appreciated and will mean I get to depl= oy > FreeBSD with netgraph rather than linux with veth. >=20 It seems that you use the same 192.168.10/24 network on both fxp0 and ngeth0 interfaces -- this is troublesome, as ARP in FreeBSD (this is about to change soon) is the global, non per-interface property, and is stored in a single routing table. So when you ping 192.168.10.3 from the remote box, it sends ARP request, the bridge correctly forwards it to ngeth0, that correctly replies with ARP reply, and ICMP ECHO REQUEST gets delivered to ngeth0. Then FreeBSD box with ngeth0 tries to send ICMP ECHO REPLY. For this, it looks up its routing table, and finds out that 192.168.10.1 is on fxp0 (not on ngeth0!), so the reply will be from the fxp0's MAC and with 192.168.10.3 source IP address -- I've verified this locally. Generally, it's not possible to have two broadcast type interfaces in the same subnetwork on one (FreeBSD) box. Put it in other way: suppose it works somehow. So when you ping 192.168.10.1 from the box with fxp0 and ngeth0, and both have addresses from the same IP subnetwork, which interface (i.e., which MAC) should get used? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAjhZ8Ukv4P6juNwoRAv7OAJ9qWItzheLQT4DdULr8ArucwuVbhACeMf0G 1ALCFj5OSU0grmZdwWrglw8= =UOA7 -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 01:16:30 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 99B1316A4CE for ; Tue, 27 Apr 2004 01:16:30 -0700 (PDT) Received: from kogut3.o2.pl (kogut3.go2.pl [212.126.20.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8386E43D64 for ; Tue, 27 Apr 2004 01:16:28 -0700 (PDT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (rekin7.go2.pl [212.126.20.19]) by kogut3.o2.pl (Postfix) with ESMTP id 9C220780C2 for ; Tue, 27 Apr 2004 10:16:23 +0200 (CEST) Message-ID: <00b701c42c2f$f3985bb0$df5561d9@ALFA> From: "Heinz Knocke" To: References: <1083033860.265497.1420.nullmailer@cicuta.babolo.ru> Date: Tue, 27 Apr 2004 10:16:25 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Modern TCP stats 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, 27 Apr 2004 08:16:30 -0000 Hi! Thanks in advance for all the support for me you priveded. Now I'm looking for some modern statistics on whats is going now in the global Internet (some main backbones), specially TCP. Special subjects of interests are: - how many packets are being sent per ... - how many of them contain interactive data (short TCP segments) and bulk (long) - maybe some stats divided into transmissions with higher level protocols - how much data sent is for HTTP, SMTP, FTP etc - ??? :) Thanks! hk From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 01:36: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 4B4EF16A4CE for ; Tue, 27 Apr 2004 01:36:10 -0700 (PDT) Received: from guldan.demon.nl (cust.13.38.adsl.cistron.nl [62.216.13.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8B9943D49 for ; Tue, 27 Apr 2004 01:36:09 -0700 (PDT) (envelope-from robert@guldan.demon.nl) Received: from bombur.guldan.demon.nl ([192.168.201.3] helo=localhost) by guldan.demon.nl with esmtp (Exim 4.24; FreeBSD) id 1BIO08-0007OW-8U; Tue, 27 Apr 2004 10:31:36 +0200 Date: Tue, 27 Apr 2004 10:34:37 +0200 From: Robert Blacquiere To: freebsd-net@freebsd.org Message-ID: <20040427083437.GA65151@bombur.guldan.demon.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Disclaimer: running FreeBSD X-Spam-Score: 0.0 (/) Subject: ppp and radius authentication 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, 27 Apr 2004 08:36:10 -0000 Hi, I'm working on a system giving access with pptp to our network. I'd like to move the users from the /etc/ppp/ppp.sercet and have them in a radius server. I have build a test setup but it fails the authentication using radius. If i debug it seems ppp sends a radius paket without a username and passwd (with pap). The radius server will reject this. Is there something missing? or have i overlooked some thing. With /etc/ppp/ppp.secret it works normaly as expected. I use the ppp option set radius /etc/radius.conf and have there 2 lines in. auth my_radius.server my_big_secret acct my_radius.server my_big_secret Also i did some tcpdumps to see if the radius server is missing the usernames. but when analysing the dump it is a empty username. Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: Hey guys you left some holes out there! From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 14:16:58 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 A013F16A4CE for ; Mon, 26 Apr 2004 14:16:58 -0700 (PDT) Received: from web13507.mail.yahoo.com (web13507.mail.yahoo.com [216.136.175.86]) by mx1.FreeBSD.org (Postfix) with SMTP id 8ED0943D1F for ; Mon, 26 Apr 2004 14:16:57 -0700 (PDT) (envelope-from dyeske@yahoo.com) Message-ID: <20040426192845.4719.qmail@web13507.mail.yahoo.com> Received: from [216.162.35.42] by web13507.mail.yahoo.com via HTTP; Mon, 26 Apr 2004 12:28:45 PDT Date: Mon, 26 Apr 2004 12:28:45 -0700 (PDT) From: David Yeske To: Nick Sayer In-Reply-To: <408D55DF.2070902@kfu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 27 Apr 2004 04:59:30 -0700 Subject: Re: netgraph arp issues vs linux veth 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, 26 Apr 2004 21:16:58 -0000 I looks like removing the promisc and autosrc messages to ngeth0 fixed part of it. That is the only modification I made from what I have pasted so far. I still had to add the upper hooks up of the ngeth0 device to the bridge for it to work. When I set this up with more than one virtual interface it appeared to favor one of the interfaces. I could keep one virtual interface working for a bit, but when I wanted to use the other one, I had to stop passing traffic through the first one. One interface would start dropping all packets, and then the other interface would start working. I did not see anything useful in dmesg, although I don't know netgraph that well or what sysctl's I should turn on for debugging. I'm not sure if this is a bug or a feature. I'm going to look at some of the vmware scripts and see how they are different, but what I have going now is good enough for a temporary solution. I will need to simulate thousands of mac addresses when I'm done with this. Thanks for the help everyone :) --- Nick Sayer wrote: > Don't send promisc and autosrc messages to ngeth0. You only need to do > that for the physical interface. > > Hook the lower and upper hooks of the physical interface up to the bridge. > > Hook the lower hook of the virtual interface up to the bridge. Do not > mess with its upper hook. > > David Yeske wrote: > > >I made another attempt with netgraph and I think I'm almost there, but I'm > >still having some issues. I found a linux solution called veth > >http://www.geocities.com/nestorjpg/veth/ which might do the job, but I would > >prefer to use netgraph if possible. Here is some more detailed config > >information. > > > >I ran this on the spoof machine > > > ># ngctl mkpeer . eiface hook ether > ># ifconfig ngeth0 link 00:bd:03:12:12:12 > ># ifconfig ngeth0 192.168.10.3 netmask 255.255.255.0 > > > ># ngctl mkpeer ngeth0: bridge lower link0 > ># ngctl name ngeth0:lower broken > ># ngctl connect fxp0: broken: lower link1 > ># ngctl connect fxp0: broken: upper link2 > ># ngctl connect ngeth0: broken: upper link3 > ># ngctl msg ngeth0: setpromisc 1 > ># ngctl msg ngeth0: setautosrc 0 > ># ngctl msg fxp0: setpromisc 1 > ># ngctl msg fxp0: setautosrc 0 > > > ># ngctl show broken: > > Name: broken Type: bridge ID: 00000046 Num hooks: 4 > > Local hook Peer name Peer type Peer ID Peer hook > > ---------- --------- --------- ------- --------- > > link3 ngeth0 ether 00000005 upper > > link2 fxp0 ether 00000004 upper > > link1 fxp0 ether 00000004 lower > > link0 ngeth0 ether 00000005 lower > > > >on the remote machine an arp -a lists this > >? (192.168.10.3) at 00:bd:03:12:12:12 on rl0 [ethernet] > >? (192.168.10.1) at 00:00:e8:5b:13:44 on rl0 permanent [ethernet] > > > >on the spoof machine an arp -a lists this > >? (192.168.10.1) at (incomplete) on ngeth0 [ethernet] > >? (192.168.10.3) at 00:bd:03:12:12:12 on ngeth0 permanent [ethernet] > > > >a sniff on the spoof machine listed this while pinging the remote machine > > > ># tcpdump -i ngeth0 'ether host 00:00:e8:5b:13:44' > >tcpdump: listening on ngeth0 > >14:03:30.519263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > >14:03:33.416568 192.168.10.1 > 192.168.10.3: icmp: echo request > >14:03:40.530562 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > >14:03:43.427175 192.168.10.1 > 192.168.10.3: icmp: echo request > >14:03:50.540805 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > >14:03:53.437845 192.168.10.1 > 192.168.10.3: icmp: echo request > >14:04:00.550960 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > >14:04:03.448383 192.168.10.1 > 192.168.10.3: icmp: echo request > > > >a sniff on the remote machine listed this while pinging the spoof machine > > > ># tcpdump -i rl0 'ether host 00:bd:03:12:12:12' > >tcpdump: listening on rl0 > >14:02:24.918804 192.168.10.1 > 192.168.10.3: icmp: echo request > >14:02:29.179263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > >14:02:34.929051 192.168.10.1 > 192.168.10.3: icmp: echo request > >14:02:44.939136 192.168.10.1 > 192.168.10.3: icmp: echo request > >14:02:52.052260 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > >14:02:54.949402 192.168.10.1 > 192.168.10.3: icmp: echo request > >14:03:02.063079 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > >14:03:04.959534 192.168.10.1 > 192.168.10.3: icmp: echo request > >14:03:12.072830 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > > > >Any clues or pointers are greatly appreciated and will mean I get to deploy > >FreeBSD with netgraph rather than linux with veth. > > > >Regards, > >David Yeske > > > > > > > From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 09:25: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 1664216A4CE for ; Tue, 27 Apr 2004 09:25:52 -0700 (PDT) Received: from shell-ng.nominum.com (shell-ng.nominum.com [81.200.64.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8A5343D53 for ; Tue, 27 Apr 2004 09:25:51 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from waits.engr.nominum.com (waits.engr.nominum.com [128.177.194.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id A29DD56840 for ; Tue, 27 Apr 2004 09:25:51 -0700 (PDT) Received: from waits.engr.nominum.com.neville-neil.com (localhost.engr.nominum.com [127.0.0.1])i3RGQTDV092983; Tue, 27 Apr 2004 09:26:31 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Tue, 27 Apr 2004 09:26:29 -0700 Message-ID: From: "George V. Neville-Neil" To: "Heinz Knocke" In-Reply-To: <00b701c42c2f$f3985bb0$df5561d9@ALFA> References: <1083033860.265497.1420.nullmailer@cicuta.babolo.ru> <00b701c42c2f$f3985bb0$df5561d9@ALFA> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: Modern TCP stats 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, 27 Apr 2004 16:25:52 -0000 At Tue, 27 Apr 2004 10:16:25 +0200, Heinz Knocke wrote: > > Hi! > > Thanks in advance for all the support for me you priveded. Now I'm looking > for some modern statistics on whats is going now in the global Internet > (some main backbones), specially TCP. Special subjects of interests are: > - how many packets are being sent per ... > - how many of them contain interactive data (short TCP segments) and bulk > (long) > - maybe some stats divided into transmissions with higher level protocols - > how much data sent is for HTTP, SMTP, FTP etc > - ??? :) I think you want to look at the work done by CAIDA as a jumping off point: http://www.caida.org/ There are others doing similar work as well. Look at recent SIGCOMM publications (http://www.acm.org) as well. Later, George From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 11:23:51 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 D4D0816A4CE for ; Tue, 27 Apr 2004 11:23:51 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C34243D39 for ; Tue, 27 Apr 2004 11:23:51 -0700 (PDT) (envelope-from marks@dell-laptop.6bone.nl) Received: by postman.ripe.net (Postfix, from userid 8) id 6CDA15DEBD; Tue, 27 Apr 2004 20:23:50 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 26A075DEAF for ; Tue, 27 Apr 2004 20:23:50 +0200 (CEST) Received: from dell-laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i3RINoVt004467 for ; Tue, 27 Apr 2004 20:23:50 +0200 Received: (nullmailer pid 4263 invoked by uid 1001); Tue, 27 Apr 2004 16:09:01 -0000 Date: Tue, 27 Apr 2004 18:09:01 +0200 From: Mark Santcroos To: net@freebsd.org Message-ID: <20040427160901.GA2552@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000007 / 0.0 / 0.0 / disabled X-RIPE-Signature: b69d628ebbf8dc7a28e98470f4da24d2 Subject: udp checksum on raw sockets 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, 27 Apr 2004 18:23:51 -0000 * I'm sending UDP packets on a raw socket. * iphdr->ip_src.s_addr = INADDR_ANY; So I don't know the IP address that will be used as src address. So as far as I can see, I have a problem generating the checksum in userspace. Suggestion: Would it make sense that if: sysctl net.udp.checksum=1 and udphdr->uh_sum = 0; in a UDP packet created on a raw socket, to do the checksum in the kernel instead of leaving it zero? If it does, I can create a patch. Any other hints as how to do the checksum in userland are welcome too. As that is the "ultimate" problem I try to fix. Thanks Mark From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 11:48:32 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 E1C2B16A4CE for ; Tue, 27 Apr 2004 11:48:32 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id C65E543D31 for ; Tue, 27 Apr 2004 11:48:32 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i3RImWog014213; Tue, 27 Apr 2004 11:48:32 -0700 (PDT) Received: from [10.1.1.193] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)i3RImVgQ023177; Tue, 27 Apr 2004 11:48:31 -0700 (PDT) In-Reply-To: <20040427160901.GA2552@laptop.6bone.nl> References: <20040427160901.GA2552@laptop.6bone.nl> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <773BE796-987B-11D8-ABA7-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 27 Apr 2004 14:48:25 -0400 To: Mark Santcroos X-Mailer: Apple Mail (2.613) cc: net@freebsd.org Subject: Re: udp checksum on raw sockets 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, 27 Apr 2004 18:48:33 -0000 On Apr 27, 2004, at 12:09 PM, Mark Santcroos wrote: > * I'm sending UDP packets on a raw socket. > > * iphdr->ip_src.s_addr = INADDR_ANY; > So I don't know the IP address that will be used as src address. The kernel ought to pick the src address of the interface the packet will be sent from according to the routing table. At least if you were using SOCK_DGRAM, I'm not sure how much the kernel fills in when using SOCK_RAW. > So as far as I can see, I have a problem generating the checksum in > userspace. > > Suggestion: > > Would it make sense that if: > sysctl net.udp.checksum=1 > and > udphdr->uh_sum = 0; > in a UDP packet created on a raw socket, to do the checksum in the > kernel > instead of leaving it zero? If it does, I can create a patch. And likewise with computing the checksum, I would expect the kernel to compute the packet checksums-- there's ip_sum as well as uh_sum. > Any other hints as how to do the checksum in userland are welcome too. > As > that is the "ultimate" problem I try to fix. Consider using libnet to build your packets: http://www.packetfactory.net/projects/libnet/ ...between libnet and libpcap, you've got userland code to handle both sending and receiving packets in an OS-independent fashion. Amoung other things, libnet has an implementation of "how to compute packet checksums" available for you to consider or use. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 12:05: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 5915F16A4CE for ; Tue, 27 Apr 2004 12:05:50 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF21643D1F for ; Tue, 27 Apr 2004 12:05:48 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3RJB1o7064773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2004 22:11:02 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3RJ5hJS076084; Tue, 27 Apr 2004 22:05:43 +0300 (EEST) (envelope-from ru) Date: Tue, 27 Apr 2004 22:05:43 +0300 From: Ruslan Ermilov To: Mark Santcroos Message-ID: <20040427190543.GA75827@ip.net.ua> References: <20040427160901.GA2552@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20040427160901.GA2552@laptop.6bone.nl> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: udp checksum on raw sockets 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, 27 Apr 2004 19:05:50 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 27, 2004 at 06:09:01PM +0200, Mark Santcroos wrote: > * I'm sending UDP packets on a raw socket. >=20 > * iphdr->ip_src.s_addr =3D INADDR_ANY; > So I don't know the IP address that will be used as src address. > So as far as I can see, I have a problem generating the checksum in > userspace. >=20 Yes, that problem is real. > Suggestion: >=20 > Would it make sense that if: > sysctl net.udp.checksum=3D1 > and > udphdr->uh_sum =3D 0; > in a UDP packet created on a raw socket, to do the checksum in the kernel > instead of leaving it zero? If it does, I can create a patch. >=20 > Any other hints as how to do the checksum in userland are welcome too. As > that is the "ultimate" problem I try to fix. >=20 Have the raw IP code set csum_flags |=3D CSUM_UDP (and set csum_data correctly) in m->m_pkthdr, if ip_p =3D=3D IPPROTO_UDP && uh_csum =3D=3D 0. Do the same thing for IPPROTO_TCP. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAjq8GUkv4P6juNwoRAvxJAJ4tHLdBZ1hzYCUBGQut4HBgVwHmXwCfT0rR ebFdz10AGKUUZpT4CXK4tn8= =mvLQ -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 14:16:41 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 A056916A4CF; Tue, 27 Apr 2004 14:16:41 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B3F443D53; Tue, 27 Apr 2004 14:16:41 -0700 (PDT) (envelope-from marks@dell-laptop.6bone.nl) Received: by postman.ripe.net (Postfix, from userid 8) id 5896C4E68A; Tue, 27 Apr 2004 23:16:40 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D30E04E6DB; Tue, 27 Apr 2004 23:16:39 +0200 (CEST) Received: from dell-laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i3RLGdVt023128; Tue, 27 Apr 2004 23:16:39 +0200 Received: (nullmailer pid 5170 invoked by uid 1001); Tue, 27 Apr 2004 21:16:39 -0000 Date: Tue, 27 Apr 2004 23:16:39 +0200 From: Mark Santcroos To: Ruslan Ermilov Message-ID: <20040427211639.GA1455@laptop.6bone.nl> References: <20040427160901.GA2552@laptop.6bone.nl> <20040427190543.GA75827@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040427190543.GA75827@ip.net.ua> User-Agent: Mutt/1.4.2.1i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000023 / 0.0 / 0.0 / disabled X-RIPE-Signature: 850013f1fdfc77f9d07e7e4b80059357 cc: net@freebsd.org Subject: Re: udp checksum on raw sockets 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, 27 Apr 2004 21:16:41 -0000 Hi, On Tue, Apr 27, 2004 at 10:05:43PM +0300, Ruslan Ermilov wrote: > Have the raw IP code set csum_flags |= CSUM_UDP (and set csum_data > correctly) in m->m_pkthdr, if ip_p == IPPROTO_UDP && uh_csum == 0. > Do the same thing for IPPROTO_TCP. Like I said, I'm willing to tackle this in the kernel, but for now I also need a userland-only solution. I guess I can fetch the IP address from the first ethernet iface and use that as the src address for the IP packet. Then I have enough information to calculate the UDP checksum in userland, don't I? Thanks Mark From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 20:20:17 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 D550416A4CE for ; Tue, 27 Apr 2004 20:20:17 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 40F6843D4C for ; Tue, 27 Apr 2004 20:20:17 -0700 (PDT) (envelope-from freebsd@stevenfettig.com) Received: (qmail 53940 invoked from network); 28 Apr 2004 03:20:16 -0000 Received: from 66-168-50-57.jvl.wi.charter.com (HELO stevenfettig.com) (66.168.50.57) by relay.pair.com with SMTP; 28 Apr 2004 03:20:16 -0000 X-pair-Authenticated: 66.168.50.57 Message-ID: <408F22DF.9090102@stevenfettig.com> Date: Tue, 27 Apr 2004 22:19:59 -0500 From: "Steven N. Fettig" User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Load Balanced Dual T1's - Same default gateway for both CSU/DSU's? 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, 28 Apr 2004 03:20:18 -0000 I know this is possible using a Cisco router with two or dual CSU/DSU's for data T1's, but I am struggling to figure out how to get this to work with FreeBSD: I have a Sangoma Dual T1 (CSU/DSU) card in a FreeBSD box I want to use as the router and firewall for. Global Crossing has provided me with two T1's that they are "load balancing" on their end (they will not employ multilink ppp) - traffic will be distributed "evenly" across both T1's - one is not a main vs. backup - they are both mains and if one goes down, both go down. I need to somehow tell the gateway/router to use two different pipes as the default gateway. I.e. the far side of the wan is 123.1.1.161 for T1-1 and 123.1.2.166 for T1-2. I can only add a default route for one and not set it to both. Is there a way to either use ipfw or simple routing to make this work? otherwise, I guess Cisco is it... Thanks in advance, Steve From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 23:28:32 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 2E69E16A4CE; Tue, 27 Apr 2004 23:28:32 -0700 (PDT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65BF343D1F; Tue, 27 Apr 2004 23:28:31 -0700 (PDT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i3S6SQQE015947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2004 10:28:27 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i3S6SPQc015946; Wed, 28 Apr 2004 10:28:25 +0400 (MSD) Date: Wed, 28 Apr 2004 10:28:25 +0400 From: Gleb Smirnoff To: "Steven N. Fettig" Message-ID: <20040428062825.GD15740@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , "Steven N. Fettig" , freebsd-questions@freebsd.org, freebsd-net@freebsd.org References: <408F22DF.9090102@stevenfettig.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <408F22DF.9090102@stevenfettig.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: Load Balanced Dual T1's - Same default gateway for both CSU/DSU's? 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, 28 Apr 2004 06:28:32 -0000 On Tue, Apr 27, 2004 at 10:19:59PM -0500, Steven N. Fettig wrote: S> I know this is possible using a Cisco router with two or dual CSU/DSU's S> for data T1's, but I am struggling to figure out how to get this to work S> with FreeBSD: S> I have a Sangoma Dual T1 (CSU/DSU) card in a FreeBSD box I want to use S> as the router and firewall for. Global Crossing has provided me with S> two T1's that they are "load balancing" on their end (they will not S> employ multilink ppp) - traffic will be distributed "evenly" across both S> T1's - one is not a main vs. backup - they are both mains and if one S> goes down, both go down. I need to somehow tell the gateway/router to S> use two different pipes as the default gateway. I.e. the far side of S> the wan is 123.1.1.161 for T1-1 and 123.1.2.166 for T1-2. I can only S> add a default route for one and not set it to both. Is there a way to S> either use ipfw or simple routing to make this work? otherwise, I guess S> Cisco is it... Surely, the best way ever is multilink PPP. You can also try this hack: route delete default route add 0.0.0.0/1 123.1.1.161 route add 128.0.0.0/1 123.1.2.166 Does Sangoma has a netgraph driver? If it does you can try to use ng_one2many. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 00:05: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 5C31816A4CE for ; Wed, 28 Apr 2004 00:05:59 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CF4E43D5A for ; Wed, 28 Apr 2004 00:05:58 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3S7BFKn007757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2004 10:11:17 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3S75twU025217; Wed, 28 Apr 2004 10:05:55 +0300 (EEST) (envelope-from ru) Date: Wed, 28 Apr 2004 10:05:54 +0300 From: Ruslan Ermilov To: Mark Santcroos Message-ID: <20040428070554.GB25064@ip.net.ua> References: <20040427160901.GA2552@laptop.6bone.nl> <20040427190543.GA75827@ip.net.ua> <20040427211639.GA1455@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OwLcNYc0lM97+oe1" Content-Disposition: inline In-Reply-To: <20040427211639.GA1455@laptop.6bone.nl> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: udp checksum on raw sockets 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, 28 Apr 2004 07:05:59 -0000 --OwLcNYc0lM97+oe1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 27, 2004 at 11:16:39PM +0200, Mark Santcroos wrote: > Hi, >=20 > On Tue, Apr 27, 2004 at 10:05:43PM +0300, Ruslan Ermilov wrote: > > Have the raw IP code set csum_flags |=3D CSUM_UDP (and set csum_data > > correctly) in m->m_pkthdr, if ip_p =3D=3D IPPROTO_UDP && uh_csum =3D=3D= 0. > > Do the same thing for IPPROTO_TCP. >=20 > Like I said, I'm willing to tackle this in the kernel, but for now I also= =20 > need a userland-only solution. >=20 OK. > I guess I can fetch the IP address from the first ethernet iface and use > that as the src address for the IP packet. >=20 getifaddrs(3). > Then I have enough information to calculate the UDP checksum in userland, > don't I? >=20 Yes, you do. Another possibility would be to emit UDP datagrams unchecksummed, by leaving the checksum field as zero. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --OwLcNYc0lM97+oe1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAj1fSUkv4P6juNwoRAog+AJoDFRw8mza7E0TbcxiRdVsosWUrywCfZcha hn1LOV/PxiEmQ6jT4Mthe2s= =IfO1 -----END PGP SIGNATURE----- --OwLcNYc0lM97+oe1-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 08:40:54 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 CB38716A4CE; Tue, 27 Apr 2004 08:40:54 -0700 (PDT) Received: from lmfilto02.st1.spray.net (lmfilto02.st1.spray.net [212.78.202.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D366C43D3F; Tue, 27 Apr 2004 08:40:53 -0700 (PDT) (envelope-from wijayakusuma@lycos.co.uk) Received: from localhost (localhost [127.0.0.1]) by lmfilto02.st1.spray.net (Postfix) with ESMTP id DA405AD663; Tue, 27 Apr 2004 15:40:51 +0000 (GMT) Received: from lmcodec04.st1.spray.net ([212.78.202.209])port 10024) with ESMTP id 30124-05; Tue, 27 Apr 2004 15:40:51 +0000 (GMT) Received: from lmcodec04.st1.spray.net (localhost [127.0.0.1]) by lmcodec04.st1.spray.net (Postfix) with SMTP id 26D5DCF903; Tue, 27 Apr 2004 15:40:51 +0000 (GMT) From: "Teguh Kurniawan " To: freebsd-isp@freebsd.org, freebsd-net@freebsd.org, freebsd-www@freebsd.org Message-ID: <1083080450009450@lycos-europe.com> X-Mailer: LycosMail X-Originating-IP: [202.152.9.132] Mime-Version: 1.0 Date: Tue, 27 Apr 2004 15:40:50 GMT Content-Type: multipart/mixed; boundary="=_NextPart_Lycos_0094501083080450_ID" X-Virus-Scanned: by amavisd-new at spray.net X-Mailman-Approved-At: Wed, 28 Apr 2004 05:12:50 -0700 Subject: Inserting html/frame/banner to requested webpage by proxy/gateway 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, 27 Apr 2004 15:40:54 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Lycos_0094501083080450_ID Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, anybody here can told me, how to insert html code to any requested page by proxy/gateway. Thank's. Teguh Lycos Email has 10 MB of FREE storage space. http://mail.lycos.co.uk --=_NextPart_Lycos_0094501083080450_ID-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 09:06: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 3607016A4CE for ; Wed, 28 Apr 2004 09:06:23 -0700 (PDT) Received: from hotmail.com (bay14-f38.bay14.hotmail.com [64.4.49.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22D4D43D45 for ; Wed, 28 Apr 2004 09:06:23 -0700 (PDT) (envelope-from monicadomingues@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Apr 2004 08:56:04 -0700 Received: from 193.137.232.15 by by14fd.bay14.hotmail.msn.com with HTTP; Wed, 28 Apr 2004 15:56:03 GMT X-Originating-IP: [193.137.232.15] X-Originating-Email: [monicadomingues@hotmail.com] X-Sender: monicadomingues@hotmail.com From: "Mónica Domingues" To: suz@crl.hitachi.co.jp Date: Wed, 28 Apr 2004 15:56:03 +0000 Message-ID: X-OriginalArrivalTime: 28 Apr 2004 15:56:04.0180 (UTC) FILETIME=[4F67B940:01C42D39] MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org Subject: pim6sd 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, 28 Apr 2004 16:06:23 -0000 Hi, Last week you respond to a message that I put in freebsd.org. I hope you can help me. At this moment i have two computers. My router with FreeBSD 4.9 and kame snap kit. At this pc I have pim6sd runing. And a host with FreeBSD4.9 and kame snap kit. What I trying to do is to buid a SSM plataform. I'am I doing this the right way? Thansk's for the attention. Mónica Domingues _________________________________________________________________ Help STOP spam with [1]the new MSN 8 and get 2 months FREE* References 1. http://g.msn.com/8HMBEN/2731??PS= From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 10:25: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 DBA8716A4CE for ; Wed, 28 Apr 2004 10:25:43 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 568FE43D5E for ; Wed, 28 Apr 2004 10:25:43 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id E6E1165216; Wed, 28 Apr 2004 18:25:40 +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 22974-04; Wed, 28 Apr 2004 18:25:40 +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 040856520E; Wed, 28 Apr 2004 18:25:32 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id BC66E60EE; Wed, 28 Apr 2004 18:25:29 +0100 (BST) Date: Wed, 28 Apr 2004 18:25:29 +0100 From: Bruce M Simpson To: =?iso-8859-1?Q?M=F3nica?= Domingues Message-ID: <20040428172529.GC38871@empiric.dek.spc.org> Mail-Followup-To: =?iso-8859-1?Q?M=F3nica?= Domingues , suz@crl.hitachi.co.jp, freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: cc: freebsd-net@freebsd.org cc: suz@crl.hitachi.co.jp Subject: Re: pim6sd 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, 28 Apr 2004 17:25:44 -0000 On Wed, Apr 28, 2004 at 03:56:03PM +0000, Mónica Domingues wrote: > What I trying to do is to buid a SSM plataform. I'am I doing this the > right way? FreeBSD doesn't implement Source-Specific Multicast yet, to the best of my knowledge. Someone at Berkeley was working on an IGMPv3 stack a while back, though, but it was for FreeBSD 4.x. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 12:25:12 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 9DBA516A4CE for ; Wed, 28 Apr 2004 12:25:12 -0700 (PDT) Received: from host130.ipowerweb.com (host130.ipowerweb.com [66.235.192.160]) by mx1.FreeBSD.org (Postfix) with SMTP id 54D0D43D31 for ; Wed, 28 Apr 2004 12:25:12 -0700 (PDT) (envelope-from jetman@mycbc.com) Received: (qmail 82711 invoked from network); 28 Apr 2004 19:28:25 -0000 Received: from unknown (HELO eagle) (141.155.145.91) by 0 with SMTP; 28 Apr 2004 19:28:25 -0000 Message-ID: <002a01c42d57$3803e300$3200a8c0@cbcoffice> From: "The Jetman" To: "FreeBSD Net" Date: Wed, 28 Apr 2004 15:29:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [4.9-R]Can I Make My DSL Connect Go Faster ? 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, 28 Apr 2004 19:25:12 -0000 Folks: I just installed an eval ADSL connection (1.5M/128K) yesterday. I installed it on a dual-boot XP/FBSD box. When the DSL connection is directly used by the XP box, I can routinely get 1.5Mb download speed, as determined by ADSLGuide, etc. I took an essentially, unmodified FBSD partition (I added IPFW2, DIVERT, and DUMMYNET to the kernel config) and turned it into a NATting gateway. It worked immediately, but running the same speed tests I got significantly and consistently lower incoming speed results (avg 400 Kb/s). FWIW, my DSL provider is Verizon and I operate this in Long Island w/ a Westell 2200 DSL router. I also use a modified version of the rc.firewall script, but I took it out of the loop by using the open config. The box I'm using uses a 1.1GHz Celeron w/ 128MB of SDRAM. I'm just confused as to why I lose SO much going thru my FBSD box and that's essence of my question. I can live w/ *some* overhead for the sake of using FBSD, but this is ridiculous. TIA....Jet =============== From the desk of Jethro Wright, III ================ + If it's there, and you can see it, it's real. + + If it's not there, and you can see it, it's virtual. + + If it's there, and you can't see it, it's transparent. + + If it's not there, and you can't see it, you erased it. + === jetman516 'at' hotmail.com ========================== Anon === From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 12:42: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 B00A216A4CE for ; Wed, 28 Apr 2004 12:42:05 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F0D443D53 for ; Wed, 28 Apr 2004 12:42:05 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 4AEB565444; Wed, 28 Apr 2004 20:42:03 +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 24598-01-6; Wed, 28 Apr 2004 20:42:02 +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 3865D65434; Wed, 28 Apr 2004 20:42:02 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id DE7C860FF; Wed, 28 Apr 2004 20:41:57 +0100 (BST) Date: Wed, 28 Apr 2004 20:41:57 +0100 From: Bruce M Simpson To: The Jetman Message-ID: <20040428194157.GL38871@empiric.dek.spc.org> Mail-Followup-To: The Jetman , FreeBSD Net References: <002a01c42d57$3803e300$3200a8c0@cbcoffice> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002a01c42d57$3803e300$3200a8c0@cbcoffice> cc: FreeBSD Net Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? 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, 28 Apr 2004 19:42:05 -0000 On Wed, Apr 28, 2004 at 03:29:58PM -0400, The Jetman wrote: > I'm just confused as to why I lose SO much going thru my FBSD box and > that's essence of my question. I can live w/ *some* overhead for the sake > of using FBSD, but this is ridiculous. TIA....Jet Are you using user space NAT? If so, this might account for some of the poor performance. Try reconfiguring your system to use IPFILTER, or consider updating to 5-CURRENT and trying pf(4). Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 13:49:55 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 0F1FD16A4CE for ; Wed, 28 Apr 2004 13:49:55 -0700 (PDT) Received: from relay2.EECS.Berkeley.EDU (relay2.EECS.Berkeley.EDU [169.229.60.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEEE243D1D for ; Wed, 28 Apr 2004 13:49:54 -0700 (PDT) (envelope-from aswan@garfield.bmrc.berkeley.edu) Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) i3SKnrBE012047 for ; Wed, 28 Apr 2004 13:49:54 -0700 (PDT) Received: from garfield.bmrc.berkeley.edu (garfield.BMRC.Berkeley.EDU [169.229.12.80])i3SKnrtj006050; Wed, 28 Apr 2004 13:49:53 -0700 (PDT) Received: (from aswan@localhost)i3SKnqMV005792; Wed, 28 Apr 2004 13:49:52 -0700 (PDT) (envelope-from aswan) Date: Wed, 28 Apr 2004 13:49:52 -0700 From: Andrew Swan To: M?nica Domingues , suz@crl.hitachi.co.jp, freebsd-net@freebsd.org Message-ID: <20040428204952.GA5701@cs.berkeley.edu> Mail-Followup-To: M?nica Domingues , suz@crl.hitachi.co.jp, freebsd-net@freebsd.org References: <20040428172529.GC38871@empiric.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040428172529.GC38871@empiric.dek.spc.org> User-Agent: Mutt/1.4.1i Subject: IGMPv3 (was Re: pim6sd) 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, 28 Apr 2004 20:49:55 -0000 Bruce M Simpson wrote: > FreeBSD doesn't implement Source-Specific Multicast yet, to the best of > my knowledge. > > Someone at Berkeley was working on an IGMPv3 stack a while back, though, > but it was for FreeBSD 4.x. i was able to apply those patches to 5.1-RELEASE without too much trouble but there is a more complete and current implementation in kame. just the igmpv3 portion of kame was split out as a separate patch for netbsd available here: http://www-sop.inria.fr/planete/Hitoshi.Asaeda/igmpv3/ as of last fall, kame was waiting for the igmpv3 sockets api to be published as an rfc (it was an internet-draft at the time) to merge igmpv3 into the core bsd distributions. (see http://www.kame.net/roadmap-2003.html). in january, the api draft was published as rfc 3678. what is the process by which code is merged from kame to freebsd? is it just a matter of somebody extracting the appropriate patches and submitting them? -Andrew From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 14:20: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 C8FA716A4CE for ; Wed, 28 Apr 2004 14:20:13 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E73E743D46 for ; Wed, 28 Apr 2004 14:20:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004042821201101400deu5me>; Wed, 28 Apr 2004 21:20:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA75497; Wed, 28 Apr 2004 14:20:10 -0700 (PDT) Date: Wed, 28 Apr 2004 14:20:09 -0700 (PDT) From: Julian Elischer To: Bruce M Simpson In-Reply-To: <20040428194157.GL38871@empiric.dek.spc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD Net cc: The Jetman Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? 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, 28 Apr 2004 21:20:13 -0000 On Wed, 28 Apr 2004, Bruce M Simpson wrote: > On Wed, Apr 28, 2004 at 03:29:58PM -0400, The Jetman wrote: > > I'm just confused as to why I lose SO much going thru my FBSD box and > > that's essence of my question. I can live w/ *some* overhead for the sake > > of using FBSD, but this is ridiculous. TIA....Jet > > Are you using user space NAT? If so, this might account for some of the > poor performance. Try reconfiguring your system to use IPFILTER, or > consider updating to 5-CURRENT and trying pf(4). > I would be surprised if that were the problem.. I've saturated ethernets using natd.. Howver I agree that more info on the setup being used would be beneficial.. > Regards, > BMS > _______________________________________________ > 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 Wed Apr 28 16:46:09 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 7F79516A4CE for ; Wed, 28 Apr 2004 16:46:09 -0700 (PDT) Received: from host130.ipowerweb.com (host130.ipowerweb.com [66.235.192.160]) by mx1.FreeBSD.org (Postfix) with SMTP id 4B1F043D3F for ; Wed, 28 Apr 2004 16:46:09 -0700 (PDT) (envelope-from jetman@mycbc.com) Received: (qmail 11820 invoked from network); 28 Apr 2004 23:49:22 -0000 Received: from unknown (HELO eagle) (141.155.145.91) by 0 with SMTP; 28 Apr 2004 23:49:22 -0000 Message-ID: <004a01c42d7b$abf676a0$3200a8c0@cbcoffice> From: "The Jetman" To: "FreeBSD Net" References: <002a01c42d57$3803e300$3200a8c0@cbcoffice> <20040428194157.GL38871@empiric.dek.spc.org> Date: Wed, 28 Apr 2004 19:50:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? 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, 28 Apr 2004 23:46:09 -0000 ----- Original Message ----- From: "Bruce M Simpson" To: "The Jetman" Cc: "FreeBSD Net" Sent: Wednesday, April 28, 2004 15:41 PM Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? > On Wed, Apr 28, 2004 at 03:29:58PM -0400, The Jetman wrote: > > I'm just confused as to why I lose SO much going thru my FBSD box and > > that's essence of my question. I can live w/ *some* overhead for the sake > > of using FBSD, but this is ridiculous. TIA....Jet > > Are you using user space NAT? If so, this might account for some of the > poor performance. Try reconfiguring your system to use IPFILTER, or > consider updating to 5-CURRENT and trying pf(4). Bruce: I'd heard about this issue on the mail lists/ngroups, but never dreamed it was as much of a big deal. BTW, yes, I *do* use the stock NATD. And IPFILTER *is* an option. Thanx again....Jet =============== From the desk of Jethro Wright, III ================ + If it's there, and you can see it, it's real. + + If it's not there, and you can see it, it's virtual. + + If it's there, and you can't see it, it's transparent. + + If it's not there, and you can't see it, you erased it. + === jetman516 'at' hotmail.com ========================== Anon === From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 17:07: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 E7B1116A4CF for ; Wed, 28 Apr 2004 17:07:50 -0700 (PDT) Received: from jchurch.neville-neil.com (jchurch.neville-neil.com [209.157.133.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8AF243D53 for ; Wed, 28 Apr 2004 17:07:48 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from jchurch.neville-neil.com.neville-neil.com (localhost.neville-neil.com [127.0.0.1])i3T09URb031952 for ; Wed, 28 Apr 2004 17:09:30 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Wed, 28 Apr 2004 17:09:30 -0700 Message-ID: <87r7u7wsp1.wl@jchurch.neville-neil.com.neville-neil.com> From: "George V. Neville-Neil" To: net@freebsd.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Subject: RFC 2292 CMSG_FIRSTHDR macro... 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, 29 Apr 2004 00:07:51 -0000 Howdy, This should be a minor nit but, is there any reason we implement this this way: #define CMSG_FIRSTHDR(mhdr) ((struct cmsghdr *)(mhdr)->msg_control) instead of this way: #define CMSG_FIRSTHDR(mhdr) \ ( (mhdr)->msg_controllen >= sizeof(struct cmsghdr) ? \ (struct cmsghdr *)(mhdr)->msg_control : \ (struct cmsghdr *)NULL ) as suggested in RFC 2292? A coworker of mine asked about this and then I got to wondering myself. The RFC says: (Note: Most existing implementations do not test the value of msg_controllen, and just return the value of msg_control. The value of msg_controllen must be tested, because if the application asks recvmsg() to return ancillary data, by setting msg_control to point to the application's buffer and setting msg_controllen to the length of this buffer, the kernel indicates that no ancillary data is available by setting msg_controllen to 0 on return. It is also easier to put this test into this macro, than making the application perform the test.) Later, George From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 22:12:17 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 0389416A4D0 for ; Wed, 28 Apr 2004 22:12:17 -0700 (PDT) Received: from v6.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DEDB43D2F for ; Wed, 28 Apr 2004 22:12:15 -0700 (PDT) (envelope-from suz@crl.hitachi.co.jp) Received: from s30.uki-uki.net (galilei.v6.hitachi.co.jp [133.145.167.4]) by v6.hitachi.co.jp (8.12.11/8.11.6) with ESMTP id i3T5C9W8085460; Thu, 29 Apr 2004 14:12:10 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Date: Thu, 29 Apr 2004 14:12:02 +0900 Message-ID: From: SUZUKI Shinsuke To: aswan@cs.berkeley.edu X-cite: xcite 1.33 In-Reply-To: <20040428204952.GA5701@cs.berkeley.edu> References: <20040428172529.GC38871@empiric.dek.spc.org> <20040428204952.GA5701@cs.berkeley.edu> User-Agent: User-Agent: Wanderlust/2.11.26 (Wonderwall) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Network Systems Research Dept., Central Research Laboratory, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: monicadomingues@hotmail.com cc: suz@crl.hitachi.co.jp Subject: Re: IGMPv3 (was Re: pim6sd) 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, 29 Apr 2004 05:12:17 -0000 >>>>> On Wed, 28 Apr 2004 13:49:52 -0700 >>>>> aswan@cs.berkeley.edu(Andrew Swan) said: > as of last fall, kame was waiting for the igmpv3 sockets api to > be published as an rfc (it was an internet-draft at the time) to > merge igmpv3 into the core bsd distributions. > (see http://www.kame.net/roadmap-2003.html). > > in january, the api draft was published as rfc 3678. what is > the process by which code is merged from kame to freebsd? is > it just a matter of somebody extracting the appropriate patches > and submitting them? I know MSF API has been published as an RFC, but I have to wait until the IPR issue raised by Apple has been closed, because Apple requires some fee for SSM-related implementations, which is against BSD-license. http://www.ietf.org/ietf/IPR/APPLE-SSM.txt I'm not sure if this IPR is really valid or this IPR is applicable to IGMPv3/MLDv2, but I think it's dangerous to MFC IGMPv3/MLDv2 without any clarification. As far as I know some Apple engineers have been aware of the issue, but I don't know if Apple's legal staffs know it. I really hope that this issue has been peacefully solved... From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 22:18:54 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 75F0D16A4CE for ; Wed, 28 Apr 2004 22:18:54 -0700 (PDT) Received: from v6.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C47D443D49 for ; Wed, 28 Apr 2004 22:18:53 -0700 (PDT) (envelope-from suz@crl.hitachi.co.jp) Received: from s30.uki-uki.net (galilei.v6.hitachi.co.jp [133.145.167.4]) by v6.hitachi.co.jp (8.12.11/8.11.6) with ESMTP id i3T5Iqq8085541; Thu, 29 Apr 2004 14:18:52 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Date: Thu, 29 Apr 2004 14:18:45 +0900 Message-ID: From: SUZUKI Shinsuke To: monicadomingues@hotmail.com X-cite: xcite 1.33 In-Reply-To: References: User-Agent: User-Agent: Wanderlust/2.11.26 (Wonderwall) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Network Systems Research Dept., Central Research Laboratory, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-net@freebsd.org Subject: Re: pim6sd 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, 29 Apr 2004 05:18:54 -0000 >>>>> On Wed, 28 Apr 2004 15:56:03 +0000 >>>>> monicadomingues@hotmail.com("M=F3nica Domingues") said: > My router with FreeBSD 4.9 and kame snap kit. At this pc I have > pim6sd runing. And a host with FreeBSD4.9 and kame snap kit. It's a KAME-SNAP specific question. You have to do the following three things to make use of MLDv2 features in KAME-SNAP. - build a kernel with "option MLDv2" configuration. - configure pim6sd with MLDv2 on, using "mld-version " option in your pim6sd.conf. - use MSF-API in some multicast application to generate MLDv2 report P.S.) I recommend you to ask such a KAME-specific question in snap-users@kame.net. From owner-freebsd-net@FreeBSD.ORG Thu Apr 29 03:12: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 085AF16A4CE for ; Thu, 29 Apr 2004 03:12:22 -0700 (PDT) Received: from artis.latnet.lv (artis.latnet.lv [159.148.107.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7751D43D2D for ; Thu, 29 Apr 2004 03:12:21 -0700 (PDT) (envelope-from artis@fbsd.lv) Received: from artis.latnet.lv (localhost [127.0.0.1]) by artis.latnet.lv (Postfix) with ESMTP id D5B5CC109 for ; Thu, 29 Apr 2004 13:12:17 +0300 (EEST) To: net@freebsd.org From: Artis Caune Content-Type: text/plain; format=flowed; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Thu, 29 Apr 2004 13:12:17 +0300 Message-ID: User-Agent: Opera7.23/FreeBSD M2 build 518 Subject: 'struct ifnet' question! 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, 29 Apr 2004 10:12:22 -0000 I'm writing kld module for traffic shaping (5.x only). It use PFIL hooks. There will be seperate decision trees for every interface + IN/OUT pair. Let's say we have rules: shape in on fxp0 ... shape out on fxp0 ... shape in on vlan0 ... in this example we have 3 decision trees: - rules with 'fxp0 in' - rules with 'fxp0 out' - rules with 'vlan0 in' When PFIL pass packet, I need find pointer to right decision tree: tree = find_decision_tree(ifp->if_xname, direction); Yeh, this works as expected, but I wonder if I can use ifp->index instead of ifp->if_xname. Using 'index + array pointer feature' I can find decision tree in just one? memory access step, compared to if_xname where I should make expensive strcmp() calls. ;) I'm worried about 'dynamic' interfaces. e.x: # ifconfig vlan0 create; ... # load rules with 'shape in on vlan0' # ifconfig vlan0 destroy # ifconfig vlan0 create; ... I belive at this point if_index is not the same when rules was loaded. How safe is to use if_index instead of if_xname? How safe is to use if_xname with interface renaming feature (-current)? Is there some way to track interface changes events? thanks, -- Artis From owner-freebsd-net@FreeBSD.ORG Thu Apr 29 03:15: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 7E63316A4CE for ; Thu, 29 Apr 2004 03:15:19 -0700 (PDT) Received: from artis.latnet.lv (artis.latnet.lv [159.148.107.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id F155943D54 for ; Thu, 29 Apr 2004 03:15:18 -0700 (PDT) (envelope-from ac-lists@latnet.lv) Received: from artis.latnet.lv (localhost [127.0.0.1]) by artis.latnet.lv (Postfix) with ESMTP id 25BEBC109 for ; Thu, 29 Apr 2004 13:15:18 +0300 (EEST) Organization: Latnet To: net@freebsd.org Message-ID: From: Artis Caune Content-Type: text/plain; format=flowed; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Thu, 29 Apr 2004 13:15:17 +0300 User-Agent: Opera7.23/FreeBSD M2 build 518 Subject: 'struct ifnet' question! 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, 29 Apr 2004 10:15:19 -0000 I'm writing kld module for traffic shaping (5.x only). It use PFIL hooks. There will be seperate decision trees for every interface + IN/OUT pair. Let's say we have rules: shape in on fxp0 ... shape out on fxp0 ... shape in on vlan0 ... in this example we have 3 decision trees: - rules with 'fxp0 in' - rules with 'fxp0 out' - rules with 'vlan0 in' When PFIL pass packet, I need find pointer to right decision tree: tree = find_decision_tree(ifp->if_xname, direction); Yeh, this works as expected, but I wonder if I can use ifp->index instead of ifp->if_xname. Using 'index + array pointer feature' I can find decision tree in just one? memory access step, compared to if_xname where I should make expensive strcmp() calls. ;) I'm worried about 'dynamic' interfaces. e.x: # ifconfig vlan0 create; ... # load rules with 'shape in on vlan0' # ifconfig vlan0 destroy # ifconfig vlan0 create; ... I belive at this point if_index is not the same when rules was loaded. How safe is to use if_index instead of if_xname? How safe is to use if_xname with interface renaming feature (-current)? Is there some way to track interface changes events? thanks, -- Artis From owner-freebsd-net@FreeBSD.ORG Thu Apr 29 05:23:04 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 AC00C16A4CF for ; Thu, 29 Apr 2004 05:23:04 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id C454B43D58 for ; Thu, 29 Apr 2004 05:23:03 -0700 (PDT) (envelope-from max@love2party.net) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BJAZD-0003wV-00; Thu, 29 Apr 2004 14:23:03 +0200 Received: from [80.131.159.221] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BJAZ9-00064j-00; Thu, 29 Apr 2004 14:23:01 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Thu, 29 Apr 2004 14:22:47 +0200 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-03=_gOPkAMMSZWkUB4J"; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200404291422.56670.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e28873fbe4dbe612ce62ab869898ff08 X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: Artis Caune Subject: Re: 'struct ifnet' question! 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, 29 Apr 2004 12:23:04 -0000 --Boundary-03=_gOPkAMMSZWkUB4J Content-Type: multipart/mixed; boundary="Boundary-01=_XOPkAY1L7EC/vgS" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_XOPkAY1L7EC/vgS Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 29 April 2004 12:15, Artis Caune wrote: <...> > Yeh, this works as expected, but I wonder if I can > use ifp->index instead of ifp->if_xname. > Using 'index + array pointer feature' I can find decision > tree in just one? memory access step, compared to > if_xname where I should make expensive strcmp() calls. ;) > > I'm worried about 'dynamic' interfaces. e.x: > # ifconfig vlan0 create; ... > # load rules with 'shape in on vlan0' > # ifconfig vlan0 destroy > # ifconfig vlan0 create; ... > > I belive at this point if_index is not the same > when rules was loaded. How safe is to use if_index > instead of if_xname? How safe is to use if_xname > with interface renaming feature (-current)? > > Is there some way to track interface changes events? Yes there is, in -current you will find some eventhandlers (in if_var.h and= =20 if_clone.h) which allow you to get a notification when an interface arrives= =20 or leaves. Pf (from OpenBSD 3.5) will use them to do exactly what you are=20 planning, to have O(1) interface look-ups. The other (big) problem in this field is, how to handle yet unknown interfa= ces=20 (e.g. USB/Cardbus/ppp/tun/...). Attached is my WIP version of the pf interface handling, which might be a b= it=20 too complex for your purpose, but should give you the idea. =2D-=20 Best regards, | mlaier@freebsd.org Max Laier | ICQ #67774661 http://pf4freebsd.love2party.net/ | mlaier@EFnet --Boundary-01=_XOPkAY1L7EC/vgS-- --Boundary-03=_gOPkAMMSZWkUB4J Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAkPOgXyyEoT62BG0RAo4RAJ42m8ilLZMm3Vn8CViL4Bhid0XisgCeMA2g K23VgL7OtBwNpk/g/Pt5C18= =JAqU -----END PGP SIGNATURE----- --Boundary-03=_gOPkAMMSZWkUB4J-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 29 05:50: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 ACA3F16A4CE for ; Thu, 29 Apr 2004 05:50:39 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BAF443D2D for ; Thu, 29 Apr 2004 05:50:38 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i3TCoZ1N065106 for ; Thu, 29 Apr 2004 20:50:35 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <4090FA08.FF856C0A@kuzbass.ru> Date: Thu, 29 Apr 2004 20:50:16 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Subject: ripd, multicast and route to 224.0.0.0/4 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, 29 Apr 2004 12:50:39 -0000 Hi! Who is guilty: ripd or FreeBSD kernel? Or I am? My router has default route via its em4 interface (and there is eBGP session) and has to announce default route using RIPv2 to the network reachable through em3. So T configure ripd: router rip version 2 network em3 ! Just to be sure: em3 is configured as 172.20.2.75/24 network 172.20.2.0/24 default-information originate redistribute kernel redistribute static redistribute connected ! It seems that ripd (I tried zebra and quagga from fresh ports) will send its multicast announces using the interface that a route to 224.0.0.0/4 points to. So, ripd sends its RIPv2 multicast packets to my uplink network via em3 if the router does not have a specific route to 224.0.0.0/4 pointing to em3. Why? And what should I do if I will need to send RIPv2 to em0, em1, em2 and em3? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Apr 29 07:41: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 46C9816A4CE for ; Thu, 29 Apr 2004 07:41:21 -0700 (PDT) Received: from mx03.ca.mci.com (mx03.ca.mci.com [142.77.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0790943D31 for ; Thu, 29 Apr 2004 07:41:19 -0700 (PDT) (envelope-from kfl@xiphos.ca) Received: from xiphos.ca (unknown [216.95.199.150]) by mx03.ca.mci.com (Postfix) with ESMTP id 48C923C81D; Thu, 29 Apr 2004 10:41:17 -0400 (EDT) Message-ID: <4091167D.5040401@xiphos.ca> Date: Thu, 29 Apr 2004 10:51:41 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Berizzi References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: ipsec ipcomp between FreeS/WAN 2.04 and FreeBSD 5.2 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, 29 Apr 2004 14:41:21 -0000 Hi, I have fixed IPComp for tunnel mode in FreeBSD 4.8 (I still need to cleanup the code). I beleive it should be easy for you to apply the diffs to FreeBSD 5.2. I will contact the Kame group and try to see how I can deleiver the patch. Since the R&D was done on the company's time I would like to have myself and Xiphos mentionned in realsing the patch. Regards, Karim Fodil-Lemelin Xiphos Technologies Inc Marco Berizzi wrote: >Hello everybody. > >I'm running an interop issue with IPSec tunnels >between FreeS/WAN and FreeBSD 5.2 >Without IPComp tunnel are successfully established. >With IPComp enabled tunnel are again successfully >established but there is no traffic flow. > >This is my setkey init (FreeBSD box side): > >/usr/local/sbin/setkey -c <flush; >spdflush; >spdadd 10.1.2.0/24 10.1.1.0/24 any -P in ipsec > ipcomp/tunnel/172.16.1.247-172.16.1.226/use > esp/tunnel/172.16.1.247-172.16.1.226/require; > >spdadd 10.1.1.0/24 10.1.2.0/24 any -P out ipsec > ipcomp/tunnel/172.16.1.226-172.16.1.247/use > esp/tunnel/172.16.1.226-172.16.1.247/require; >EOF > >However with this kind of init file FreeS/WAN is dropping packet coming from the FreeBSD box. >Michael Richardson (fsw mantainer) reply me telling: > >"... The packets that racoon is telling the system to build >would appear to have been constructed like: > >orig IPsrc = 10.1.1.1,IPdst = 10.1.2.1 > IPcomp >* IPsrc = 172.16.1.247,IPdst=172.16.1.226 > ESP >outer IPsrc = 172.16.1.247,IPdst=172.16.1.226 > >[...] This packet format is in error. It defeats most of the point of using >IPcomp, which is to compress the inner-IP header out. It appears that a new >IP header has been added. >If the 2.6.0 kernel accepts this, then I wonder what other things it >might accept! The IPIP header marked "*" is completely superfluous and >a waste of 20 bytes. ..." > >The full thread available at https://lists.freeswan.org/archives/design/2003-December/msg00032.html > >The thread is about FreeS/WAN and kernel 2.6 (2.6 IPSec stack is a KAME based). However Linux 2.6 and FreeBSD have the same behaviour. > >Comments? > >TIA > >PS: Please CC me. I'm not subscribed to the list. >_______________________________________________ >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 Thu Apr 29 08:22:08 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 2A9DB16A4CE for ; Thu, 29 Apr 2004 08:22:08 -0700 (PDT) Received: from mail.a-quadrat.at (mail.a-quadrat.at [81.223.141.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B35C243D49 for ; Thu, 29 Apr 2004 08:22:07 -0700 (PDT) (envelope-from mbretter@a-quadrat.at) Received: from localhost (localhost.a-quadrat.at [127.0.0.1]) by mail.a-quadrat.at (Postfix) with ESMTP id BE2045D016; Thu, 29 Apr 2004 17:22:06 +0200 (CEST) Received: from mail.a-quadrat.at ([127.0.0.1]) by localhost (files.a-quadrat.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37379-03; Thu, 29 Apr 2004 17:22:05 +0200 (CEST) Received: from a-quadrat.at (files.a-quadrat.at [192.168.90.9]) by mail.a-quadrat.at (Postfix) with ESMTP id 152915C4FE; Thu, 29 Apr 2004 17:22:05 +0200 (CEST) Message-ID: <40911D99.6030305@a-quadrat.at> Date: Thu, 29 Apr 2004 17:22:01 +0200 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.6) Gecko/20040113 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: mpd-users@lists.sourceforge.net, net@freebsd.org, bugat-chat@bugat.at Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at a-quadrat.at Subject: Mpd-4 beta1 - call for testers 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, 29 Apr 2004 15:22:08 -0000 Hi, We are pleased to announce the availability of Mpd-4 (Beta 1). What's new? - Completely overhauled event system based on pthreads - Multi-threaded authentication and accounting requests - EAP support - OPIE support - take a look at the changelog for more http://www.bretterklieber.com/mpd/doc4/mpd5.html It would be great if people are willing to test it and help ensure Mpd-4 is stable. Mpd-4 can be downloaded from here: http://prdownloads.sourceforge.net/mpd/mpd-4.0b1.tar.gz?download Important: Mpd-4 depends on libpdel (ports/devel). Mpd-4 needs an enhanced libradius, you can get the patches from here: FreeBSD-5 < 2004-04-27: http://www.bretterklieber.com/freebsd/libradius5.diff or get the latest 5-current. FreeBSD-4: http://www.bretterklieber.com/freebsd/libradius.diff thanx, bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 From owner-freebsd-net@FreeBSD.ORG Thu Apr 29 08:27:08 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 5FEC816A4CE for ; Thu, 29 Apr 2004 08:27:08 -0700 (PDT) Received: from host130.ipowerweb.com (host130.ipowerweb.com [66.235.192.160]) by mx1.FreeBSD.org (Postfix) with SMTP id 7162E43D4C for ; Thu, 29 Apr 2004 08:27:07 -0700 (PDT) (envelope-from jetman@mycbc.com) Received: (qmail 20922 invoked from network); 29 Apr 2004 15:30:20 -0000 Received: from unknown (HELO eagle) (141.155.145.91) by 0 with SMTP; 29 Apr 2004 15:30:20 -0000 Message-ID: <00c301c42dff$1fc2ff80$3200a8c0@cbcoffice> From: "The Jetman" To: "FreeBSD Net" References: Date: Thu, 29 Apr 2004 11:18:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? 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, 29 Apr 2004 15:27:08 -0000 ----- Original Message ----- From: "Julian Elischer" To: "Bruce M Simpson" Cc: "FreeBSD Net" ; "The Jetman" Sent: Wednesday, April 28, 2004 17:20 PM Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? > > > On Wed, 28 Apr 2004, Bruce M Simpson wrote: > > > On Wed, Apr 28, 2004 at 03:29:58PM -0400, The Jetman wrote: > > > I'm just confused as to why I lose SO much going thru my FBSD box and > > > that's essence of my question. I can live w/ *some* overhead for the sake > > > of using FBSD, but this is ridiculous. TIA....Jet > > > > Are you using user space NAT? If so, this might account for some of the > > poor performance. Try reconfiguring your system to use IPFILTER, or > > consider updating to 5-CURRENT and trying pf(4). > > > > I would be surprised if that were the problem.. I've saturated ethernets > using natd.. > > Howver I agree that more info on the setup being used would be > beneficial.. > Julian: There isn't much that I can *think* to add. If knowing which LAN cards I use will help, they're the usu stuf, a dc (forget which chip) and a Realtek. I admit these aren't superstars, but I just slapped NAT box together from what was a simple workstation. The IPFW firewall script is the unmodified 'open' config, that is: 00050 99654 49243070 divert 8668 ip from any to any via dc0 00100 112 26392 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 65000 195218 98282299 allow ip from any to any 65535 0 0 allow ip from any to any Again, I can even live w/ some overhead due to sub-optimal hware. I only write bec the FBSD NAT speed is less than 30% of XP standalone speed ! Later....Jet =============== From the desk of Jethro Wright, III ================ + If it's there, and you can see it, it's real. + + If it's not there, and you can see it, it's virtual. + + If it's there, and you can't see it, it's transparent. + + If it's not there, and you can't see it, you erased it. + === jetman516 'at' hotmail.com ========================== Anon === From owner-freebsd-net@FreeBSD.ORG Thu Apr 29 08:53: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 1A4A416A4CE for ; Thu, 29 Apr 2004 08:53:38 -0700 (PDT) Received: from hotmail.com (sea2-dav72.sea2.hotmail.com [207.68.164.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7E4643D1F for ; Thu, 29 Apr 2004 08:53:37 -0700 (PDT) (envelope-from pupilla@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 29 Apr 2004 08:53:37 -0700 Received: from 80.204.235.254 by sea2-dav72.sea2.hotmail.com with DAV; Thu, 29 Apr 2004 15:53:37 +0000 X-Originating-IP: [80.204.235.254] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "Karim Fodil-Lemelin" References: <4091167D.5040401@xiphos.ca> Date: Thu, 29 Apr 2004 17:53:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 Message-ID: X-OriginalArrivalTime: 29 Apr 2004 15:53:37.0887 (UTC) FILETIME=[229EEEF0:01C42E02] cc: freebsd-net@freebsd.org Subject: Re: ipsec ipcomp between FreeS/WAN 2.04 and FreeBSD 5.2 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, 29 Apr 2004 15:53:38 -0000 Wow! Great. I will wait your news. Karim Fodil-Lemelin wrote: > Hi, >=20 > I have fixed IPComp for tunnel mode in FreeBSD 4.8 (I still need = to=20 > cleanup the code). I beleive it should be easy for you to apply the=20 > diffs to FreeBSD 5.2. I will contact the Kame group and try to see how = I=20 > can deleiver the patch. Since the R&D was done on the company's time I = > would like to have myself and Xiphos mentionned in realsing the patch. >=20 > Regards, >=20 > Karim Fodil-Lemelin > Xiphos Technologies Inc >=20 > Marco Berizzi wrote: >=20 > >Hello everybody. > > > >I'm running an interop issue with IPSec tunnels > >between FreeS/WAN and FreeBSD 5.2 > >Without IPComp tunnel are successfully established. > >With IPComp enabled tunnel are again successfully > >established but there is no traffic flow. > > > >This is my setkey init (FreeBSD box side): > > > >/usr/local/sbin/setkey -c < >flush; > >spdflush; > >spdadd 10.1.2.0/24 10.1.1.0/24 any -P in ipsec > > ipcomp/tunnel/172.16.1.247-172.16.1.226/use > > esp/tunnel/172.16.1.247-172.16.1.226/require;=20 > > > >spdadd 10.1.1.0/24 10.1.2.0/24 any -P out ipsec > > ipcomp/tunnel/172.16.1.226-172.16.1.247/use > > esp/tunnel/172.16.1.226-172.16.1.247/require; > >EOF > > > >However with this kind of init file FreeS/WAN is dropping packet = coming from the FreeBSD box.=20 > >Michael Richardson (fsw mantainer) reply me telling: > > > >"... The packets that racoon is telling the system to build > >would appear to have been constructed like: > > > >orig IPsrc =3D 10.1.1.1,IPdst =3D 10.1.2.1 > > IPcomp > >* IPsrc =3D 172.16.1.247,IPdst=3D172.16.1.226 > > ESP > >outer IPsrc =3D 172.16.1.247,IPdst=3D172.16.1.226 > > > >[...] This packet format is in error. It defeats most of the point = of using > >IPcomp, which is to compress the inner-IP header out. It appears that = a new > >IP header has been added. > >If the 2.6.0 kernel accepts this, then I wonder what other things it > >might accept! The IPIP header marked "*" is completely superfluous = and > >a waste of 20 bytes. ..." > > > >The full thread available at = https://lists.freeswan.org/archives/design/2003-December/msg00032.html > > > >The thread is about FreeS/WAN and kernel 2.6 (2.6 IPSec stack is a = KAME based). However Linux 2.6 and FreeBSD have the same behaviour. > > > >Comments? > > > >TIA From owner-freebsd-net@FreeBSD.ORG Thu Apr 29 21:19:26 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 C395916A4CE for ; Thu, 29 Apr 2004 21:19:26 -0700 (PDT) Received: from jchurch.neville-neil.com (jchurch.neville-neil.com [209.157.133.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B33543D46 for ; Thu, 29 Apr 2004 21:19:24 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from jchurch.neville-neil.com.neville-neil.com (localhost.neville-neil.com [127.0.0.1])i3U4L7Rb068216 for ; Thu, 29 Apr 2004 21:21:07 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Thu, 29 Apr 2004 21:21:07 -0700 Message-ID: <877jvyw0y4.wl@jchurch.neville-neil.com.neville-neil.com> From: "George V. Neville-Neil" To: net@freebsd.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Subject: Up to date web link for NetGraph? 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: Fri, 30 Apr 2004 04:19:26 -0000 Hi, I'm referencing Net Graph in a document and would like an up to date web page or some such to reference. I looked at Julian's page (that's what Google pointed me to) but it's out of date, as is the Daemon News article. Thanks, George From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 06:19:46 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 E000116A4CE for ; Fri, 30 Apr 2004 06:19:46 -0700 (PDT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0599643D53 for ; Fri, 30 Apr 2004 06:19:46 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i3UDH2DE036392 for net@freebsd.org.checked; (8.12.8/vak/2.1) Fri, 30 Apr 2004 17:17:02 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i3UDFY85036331; (8.12.8/vak/2.1) Fri, 30 Apr 2004 17:15:34 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <409251A4.3050909@cronyx.ru> Date: Fri, 30 Apr 2004 17:16:20 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "George V. Neville-Neil" References: <877jvyw0y4.wl@jchurch.neville-neil.com.neville-neil.com> In-Reply-To: <877jvyw0y4.wl@jchurch.neville-neil.com.neville-neil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: Up to date web link for NetGraph? 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: Fri, 30 Apr 2004 13:19:47 -0000 George V. Neville-Neil wrote: >Hi, > > I'm referencing Net Graph in a document and would like an up > to date web page or some such to reference. I looked at > Julian's page (that's what Google pointed me to) but it's out > of date, as is the Daemon News article. > > Why not http://www.freebsd.org/cgi/man.cgi?query=netgraph&apropos=0&sektion=0&manpath=FreeBSD+5.2-current&format=html Best regards, Roman Kurakin rik >Thanks, >George >_______________________________________________ >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 Fri Apr 30 15:16:48 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 6847016A4CE for ; Fri, 30 Apr 2004 15:16:48 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FD5443D4C for ; Fri, 30 Apr 2004 15:16:48 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004043022164601400d72cse>; Fri, 30 Apr 2004 22:16:47 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA04514; Fri, 30 Apr 2004 15:16:46 -0700 (PDT) Date: Fri, 30 Apr 2004 15:16:45 -0700 (PDT) From: Julian Elischer To: "George V. Neville-Neil" In-Reply-To: <877jvyw0y4.wl@jchurch.neville-neil.com.neville-neil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: Up to date web link for NetGraph? 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: Fri, 30 Apr 2004 22:16:48 -0000 There is no up-to-date 'article'.. I guess we need to update them.. The man pages should be up to date... On Thu, 29 Apr 2004, George V. Neville-Neil wrote: > Hi, > > I'm referencing Net Graph in a document and would like an up > to date web page or some such to reference. I looked at > Julian's page (that's what Google pointed me to) but it's out > of date, as is the Daemon News article. > > Thanks, > George > _______________________________________________ > 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 Fri Apr 30 15:24:58 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 3777216A4D2 for ; Fri, 30 Apr 2004 15:24:58 -0700 (PDT) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBFE143D39 for ; Fri, 30 Apr 2004 15:24:57 -0700 (PDT) (envelope-from mitch@bitblock.com) Received: from a1200 ([24.83.187.201]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Fri, 30 Apr 2004 22:24:54 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 4092D236.0001161C.bigass1.bitblock.com,dns; a1200 ([24.83.187.201]),AUTH: LOGIN mitch@bitblock.com From: "Mitch (bitblock)" To: freebsd-net@freebsd.org Date: Fri, 30 Apr 2004 15:24:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Routing and VPN troubles... 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: Fri, 30 Apr 2004 22:24:58 -0000 There are about a 1000 different lists - hope this is the right one - if not, any suggestions welcome! The crux of my problem, is that I need to configure a VPN network in a star - one central node, many outside nodes... easy right? The problem is that I need the individual "rays" or "spokes" to be able to communicate with each other SELECTIVELY. I've tried to get this config working with BSD boxes - I have about 50 spokes to deal with right now and that number will hopefully grow.... I've been looking at the two problems separately, but I'll describe the whole mess, and then hope you are more inspired than I am. PC1 (192.168.1.10)<--\ PC2 (192.168.1.11)<-->(192.168.1.1)FBSD 1(10.1.1.2)<-->ADSL<------\ | PC3 (192.168.2.10)<--\ | PC4 (192.168.2.11)<-->(192.168.2.1)FBSD 2(10.1.1.3)<-->ADSL<----\ | | | PC5 (192.168.3.10)<--\ | | PC6 (192.168.3.11)<-->(192.168.3.1)FBSD 3(10.1.1.4)<-->ADSL<--\ | | | | | <--/ / / INTERNET <---> (SOME PUBLIC IP) FBSD 4 (10.1.1.1) <---/ / <----/ In actual fact, the 10.1.1.X addresses are all public addresses on a subnet. PC1 and PC2 need full access to PC3 - 6. PC3 needs access to certain ports on PC 5. Consider FBSD 4 to be on dedicated vlans with each of FBSD 1 - 3. That is the essence of the firewalling / port filtering of the VPN - like can I trest the virtual VPN interfaces as normal interfaces for purposes of writing firewall rules? Second problem. To do this, 10.1.1.2 and 10.1.1.3 need to communciate with 10.1.1.4 to set up these vpn's. The problem is that we have ADSL over ATM. ATM manages data flow by configured path. All remote nodes have a "path" to the router, not each other... so FBSD 4 needs to be able to establish VPN's with FBSD 1 - 3 and route between the VPN's. If I can use FBSD 4 for this, and if I can treat the virtual interfaces as normal ones in ipfw, then I can do what I want - right? I can probably alter my layout and use of IP addresses and so on somewhat, but the key is that routing has to be performed on a single interface in order to redirect traffic from the hosts that can't see each other. Does that make the problem clear? For starters, there are really FBSD 1 - 50 (not just 1 - 3) ;-) At present, I've got a variety of hardware and software (Linksys SX41 / Netgear / etc.) deployed in place of FBSD 1 - 3 and FreeBSD in place of FBSD 4... I have a couple of test machines to work with though and figure if I can get 3 working I can get the rest working too. I've heard something about /32 subnetting, not sure how that works, or what has to be done to enable it... I've been looking for any information on that I can find on that subject - might solve the problem another way if I can make my endpoint routers (1 - 3) communicate through regular IP by forcing them to bounce through the router - but I've been told the router has to support this function as a router woudl normally ignore traffic bound for the same subnet as it comes from - right? If you know it's impossible, that's ok... I tried ;-) Any alternatives? PPPOE instead of VPN between the gateway's? Thanks in advance. Hope I'm not asking to much, or that the challenge is worthy ;-) m/ From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 15:30:46 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 796A316A4CE; Fri, 30 Apr 2004 15:30:46 -0700 (PDT) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44EB043D1D; Fri, 30 Apr 2004 15:30:46 -0700 (PDT) (envelope-from mitch@bitblock.com) Received: from a1200 ([24.83.187.201]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Fri, 30 Apr 2004 22:30:43 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 4092D393.00011760.bigass1.bitblock.com,dns; a1200 ([24.83.187.201]),AUTH: LOGIN mitch@bitblock.com From: "Mitch (bitblock)" To: freebsd-net@freebsd.org, freebsd-isp@freebsd.org Date: Fri, 30 Apr 2004 15:30:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Routing and VPN troubles... 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: Fri, 30 Apr 2004 22:30:46 -0000 There are about a 1000 different lists - hope this is the right two - if not, any suggestions welcome! The crux of my problem, is that I need to configure a VPN network in a star - one central node, many outside nodes... easy right? The problem is that I need the individual "rays" or "spokes" to be able to communicate with each other SELECTIVELY. I've tried to get this config working with BSD boxes - I have about 50 spokes to deal with right now and that number will hopefully grow.... I've been looking at the two problems separately, but I'll describe the whole mess, and then hope you are more inspired than I am. PC1 (192.168.1.10)<--\ PC2 (192.168.1.11)<-->(192.168.1.1)FBSD 1(10.1.1.2)<-->ADSL<------\ | PC3 (192.168.2.10)<--\ | PC4 (192.168.2.11)<-->(192.168.2.1)FBSD 2(10.1.1.3)<-->ADSL<----\ | | | PC5 (192.168.3.10)<--\ | | PC6 (192.168.3.11)<-->(192.168.3.1)FBSD 3(10.1.1.4)<-->ADSL<--\ | | | | | <--/ / / INTERNET <---> (SOME PUBLIC IP) FBSD 4 (10.1.1.1) <---/ / <----/ In actual fact, the 10.1.1.X addresses are all public addresses on a subnet. PC1 and PC2 need full access to PC3 - 6. PC3 needs access to certain ports on PC 5. That is the essence of the firewalling / port filtering of the VPN - like can I trest the virtual VPN interfaces as normal interfaces for purposes of writing firewall rules? Second problem. To do this, 10.1.1.2 and 10.1.1.3 need to communciate with 10.1.1.4 to set up these vpn's. The problem is that we have ADSL over ATM. ATM manages data flow by configured path. Consider FBSD 4 to be on dedicated vlans with each of FBSD 1 - 3. All remote nodes have a "path" to the router, not each other... so FBSD 4 needs to be able to establish VPN's with FBSD 1 - 3 and route between the VPN's. If I can use FBSD 4 for this, and if I can treat the virtual interfaces as normal ones in ipfw, then I can do what I want - right? I can probably alter my layout and use of IP addresses and so on somewhat, but the key is that routing has to be performed on a single interface in order to redirect traffic from the hosts that can't see each other. Does that make the problem clear? For starters, there are really FBSD 1 - 50 (not just 1 - 3) ;-) At present, I've got a variety of hardware and software (Linksys SX41 / Netgear / etc.) deployed in place of FBSD 1 - 3 and FreeBSD in place of FBSD 4... I have a couple of test machines to work with though and figure if I can get 3 working I can get the rest working too. I've heard something about /32 subnetting, not sure how that works, or what has to be done to enable it... I've been looking for any information on that I can find on that subject - might solve the problem another way if I can make my endpoint routers (1 - 3) communicate through regular IP by forcing them to bounce through the router - but I've been told the router has to support this function as a router woudl normally ignore traffic bound for the same subnet as it comes from - right? If you know it's impossible, that's ok... I tried ;-) Any alternatives? PPPOE instead of VPN between the gateway's? Thanks in advance. Hope I'm not asking to much, or that the challenge is worthy ;-) m/ From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 15:43:53 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 A1C5B16A4CF for ; Fri, 30 Apr 2004 15:43:53 -0700 (PDT) Received: from jchurch.neville-neil.com (jchurch.neville-neil.com [209.157.133.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C2A743D5A for ; Fri, 30 Apr 2004 15:43:53 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from jchurch.neville-neil.com.neville-neil.com (localhost.neville-neil.com [127.0.0.1])i3UMjWRb005962; Fri, 30 Apr 2004 15:45:32 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 30 Apr 2004 15:45:32 -0700 Message-ID: <87smelultf.wl@jchurch.neville-neil.com.neville-neil.com> From: gnn@neville-neil.com To: Julian Elischer In-Reply-To: References: <877jvyw0y4.wl@jchurch.neville-neil.com.neville-neil.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: Up to date web link for NetGraph? 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: Fri, 30 Apr 2004 22:43:53 -0000 At Fri, 30 Apr 2004 15:16:45 -0700 (PDT), julian wrote: > > There is no up-to-date 'article'.. I guess we need to update them.. > > The man pages should be up to date... > > That's what I wound up referencing, the thing hURLed earlier. Later, George From owner-freebsd-net@FreeBSD.ORG Sat May 1 00:30: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 4509116A4CE; Sat, 1 May 2004 00:30:52 -0700 (PDT) Received: from flash.mipk.kharkiv.edu (flash.mipk.kharkiv.edu [194.44.157.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7078D43D2F; Sat, 1 May 2004 00:30:49 -0700 (PDT) (envelope-from artem@mipk.kharkiv.edu) Received: from mipk.kharkiv.edu (aws.aws-net.org.ua [192.168.32.1]) i417TLT1036266; Sat, 1 May 2004 10:29:23 +0300 (EEST) (envelope-from artem@mipk.kharkiv.edu) Message-ID: <409351D8.8060603@mipk.kharkiv.edu> Date: Sat, 01 May 2004 10:29:28 +0300 From: "Artyom V. Viklenko" Organization: IIAT NTU "KhPI" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: ru, uk, en MIME-Version: 1.0 To: "Mitch (bitblock)" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Routing and VPN troubles... 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, 01 May 2004 07:30:52 -0000 Mitch (bitblock) wrote: > The crux of my problem, is that I need to configure a VPN network in a > star - one central node, many outside nodes... easy right? First of all, is it really a VPN network? How you connect your ADSL links to FBSD 4? And second, if FBSD4 is only point which handle ALL traffic between FBSD1-3 and their clients, you can use ipfw to block unwanted traffic. For example, if your ADSL links connected to VLAN-avare switch, and each ADSL link paired to FBSD4 in the separate VLAN, you can set up different interfaces vlan0-vlanx for each one and use these interfaces in ipfw rules. -- Sincerely yours, Artyom V. Viklenko. ====================================================== System Administrator artem@mipk.kharkiv.edu ------------------------------------------------------ IIAT NTU "KhPI" 21, Frunze Str., Kharkov Ukraine 61002 Phone: +38 (0572) 400026 Fax: +38 (057) 7062749 ====================================================== From owner-freebsd-net@FreeBSD.ORG Sat May 1 02:03: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 25DF416A4CE; Sat, 1 May 2004 02:03:22 -0700 (PDT) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C48EB43D41; Sat, 1 May 2004 02:03:21 -0700 (PDT) (envelope-from mitch@bitblock.com) Received: from a1200 ([24.83.187.201]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Sat, 01 May 2004 09:03:17 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 409367D5.0000020F.bigass1.bitblock.com,dns; a1200 ([24.83.187.201]),AUTH: LOGIN mitch@bitblock.com From: "Mitch (bitblock)" To: "Artyom V. Viklenko" Date: Sat, 1 May 2004 02:03:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <409351D8.8060603@mipk.kharkiv.edu> cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org Subject: RE: Routing and VPN troubles... 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, 01 May 2004 09:03:22 -0000 > -----Original Message----- > From: Artyom V. Viklenko [mailto:artem@mipk.kharkiv.edu] > Sent: Saturday, May 01, 2004 12:29 AM > To: Mitch (bitblock) > Cc: freebsd-net@freebsd.org; freebsd-isp@freebsd.org > Subject: Re: Routing and VPN troubles... > > > Mitch (bitblock) wrote: > > The crux of my problem, is that I need to configure a VPN network in a > > star - one central node, many outside nodes... easy right? > > First of all, is it really a VPN network? > How you connect your ADSL links to FBSD 4? > > And second, if FBSD4 is only point which handle > ALL traffic between FBSD1-3 and their clients, you can > use ipfw to block unwanted traffic. > For example, if your ADSL links connected to VLAN-avare > switch, and each ADSL link paired to FBSD4 in the separate VLAN, > you can set up different interfaces vlan0-vlanx > for each one and use these interfaces in ipfw rules. Thanks Artyom... The PC's behind FBSD1-3 are on private network addresses. The ADSL infrastructure and ATM paths will only route the assigned public address to the router FBSD4. There is no VLAN-aware switch, it's just the way that the ATM paths are configured that made it a close analogy (so I thought). The VPN stuff might be easy if I could figure out how to make FBSD1-3 route through FBSD4 (regardless of the fact that they are all on the same subnet... the traffic from FBSD1 needs to "bounce" off FBSD4 on it's way to FBSD3 for example... either that, or maybe the gif interfaces count as distinct interfaces for routing? m/ From owner-freebsd-net@FreeBSD.ORG Sat May 1 02:13: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 64D3D16A4CE; Sat, 1 May 2004 02:13:59 -0700 (PDT) Received: from guldan.demon.nl (cust.13.38.adsl.cistron.nl [62.216.13.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA0FA43D31; Sat, 1 May 2004 02:13:58 -0700 (PDT) (envelope-from robert@guldan.demon.nl) Received: from bombur.guldan.demon.nl ([192.168.201.3] helo=localhost) by guldan.demon.nl with esmtp (Exim 4.24; FreeBSD) id 1BJqUd-000CCz-2M; Sat, 01 May 2004 11:09:07 +0200 Date: Sat, 1 May 2004 11:12:20 +0200 From: Robert Blacquiere To: "Mitch (bitblock)" Message-ID: <20040501091220.GT67426@bombur.guldan.demon.nl> References: <409351D8.8060603@mipk.kharkiv.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Disclaimer: running FreeBSD X-Spam-Score: 0.0 (/) cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Routing and VPN troubles... 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, 01 May 2004 09:13:59 -0000 On Sat, May 01, 2004 at 02:03:17AM -0700, Mitch (bitblock) wrote: > > Thanks Artyom... > > The PC's behind FBSD1-3 are on private network addresses. The ADSL > infrastructure and ATM paths will only route the assigned public address to > the router FBSD4. There is no VLAN-aware switch, it's just the way that the > ATM paths are configured that made it a close analogy (so I thought). May be it is possible to use proxy arp on de "gateway" FBSD4 machine. So all machines can talk to each thru FBSD4 box. We use some similair setup to prevent people to talk to each without us knowning (bigboss is watching). All traffic will then be handled by the proxy arp box. > > The VPN stuff might be easy if I could figure out how to make FBSD1-3 route > through FBSD4 (regardless of the fact that they are all on the same > subnet... the traffic from FBSD1 needs to "bounce" off FBSD4 on it's way to > FBSD3 for example... either that, or maybe the gif interfaces count as > distinct interfaces for routing? > > m/ > > _______________________________________________ > freebsd-isp@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-isp > To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: Hey guys you left some holes out there! From owner-freebsd-net@FreeBSD.ORG Sat May 1 13:16:04 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 96AB916A4CE; Sat, 1 May 2004 13:16:04 -0700 (PDT) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49AE943D62; Sat, 1 May 2004 13:16:04 -0700 (PDT) (envelope-from mitch@bitblock.com) Received: from a1200 ([24.83.187.201]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Sat, 01 May 2004 20:15:59 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 4094057F.00006381.bigass1.bitblock.com,dns; a1200 ([24.83.187.201]),AUTH: LOGIN mitch@bitblock.com From: "Mitch (bitblock)" To: "Robert Blacquiere" Date: Sat, 1 May 2004 13:15:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040501091220.GT67426@bombur.guldan.demon.nl> cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org Subject: RE: Routing and VPN troubles... 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, 01 May 2004 20:16:04 -0000 > May be it is possible to use proxy arp on de "gateway" FBSD4 > machine. So all > machines can talk to each thru FBSD4 box. We use some similair setup to > prevent people to talk to each without us knowning (bigboss is watching). > > All traffic will then be handled by the proxy arp box. > I'll look and see what info I can find on this idea - had a few people suggest I switch to OpenVPN instead of IPSec which creates virtual devices allowing full firewalling etc. Thanks Robert m/ From owner-freebsd-net@FreeBSD.ORG Sat May 1 15:57:40 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 95C2616A4CE for ; Sat, 1 May 2004 15:57:40 -0700 (PDT) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51CF643D39 for ; Sat, 1 May 2004 15:57:40 -0700 (PDT) (envelope-from mbsd@pacbell.net) Received: from sotec.home (adsl-64-168-26-76.dsl.snfc21.pacbell.net [64.168.26.76])i41Mvc4b008648; Sat, 1 May 2004 17:57:39 -0500 (CDT) Date: Sat, 1 May 2004 15:57:38 -0700 (PDT) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= X-X-Sender: mikko@sotec.home To: The Jetman In-Reply-To: <002a01c42d57$3803e300$3200a8c0@cbcoffice> Message-ID: <20040501154922.T39972@sotec.home> References: <002a01c42d57$3803e300$3200a8c0@cbcoffice> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD Net Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? 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, 01 May 2004 22:57:40 -0000 On Wed, 28 Apr 2004, The Jetman wrote: > Folks: I just installed an eval ADSL connection (1.5M/128K) yesterday. > I installed it on a dual-boot XP/FBSD box. When the DSL connection is directly > used by the XP box, I can routinely get 1.5Mb download speed, as determined > by ADSLGuide, etc. I took an essentially, unmodified FBSD partition (I added > IPFW2, DIVERT, and DUMMYNET to the kernel config) and turned it into a > NATting gateway. It worked immediately, but running the same speed tests > I got significantly and consistently lower incoming speed results (avg 400 > Kb/s). > > FWIW, my DSL provider is Verizon and I operate this in Long Island > w/ a Westell 2200 DSL router. I also use a modified version of the > rc.firewall script, but I took it out of the loop by using the open config. > The box I'm using uses a 1.1GHz Celeron w/ 128MB of SDRAM. > > I'm just confused as to why I lose SO much going thru my FBSD box and > that's essence of my question. I can live w/ *some* overhead for the sake > of using FBSD, but this is ridiculous. TIA....Jet I'm getting 1.5 Mb over PPPoE with user space ppp on a 400 MHz Celeron with a crappy RealTek card, so you should certainly not be limited by your hardware. Do you have lots of packet collisions (check with netstat -i)? Perhaps you can try fiddling with the media/mediaopt flags to ifconfig on the interface connected to the DSL box - just in case it autonegotiation is not working at is should. $.02, /Mikko From owner-freebsd-net@FreeBSD.ORG Sat May 1 18:35: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 925B616A4CE for ; Sat, 1 May 2004 18:35:50 -0700 (PDT) Received: from office.suresupport.com (office.suresupport.com [213.145.98.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 5292943D2F for ; Sat, 1 May 2004 18:35:49 -0700 (PDT) (envelope-from tie@ankh.morp.org) Received: (qmail 77578 invoked by uid 1026); 2 May 2004 01:32:36 -0000 Received: from tie@ankh.morp.org by office.suresupport.com by uid 1004 with qmail-scanner-1.20 (f-prot: 4.4.1/3.14.11. Clear:RC:1(213.145.98.44):. Processed in 0.021303 secs); 02 May 2004 01:32:36 -0000 Received: from unknown (HELO ankh.morp.org) (213.145.98.44) by office.suresupport.com with SMTP; 2 May 2004 01:32:36 -0000 Message-ID: <40945070.1040909@ankh.morp.org> Date: Sun, 02 May 2004 04:35:44 +0300 From: Emil Filipov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: mpd and external authentication 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, 02 May 2004 01:35:50 -0000 Hi list:) Has anyone used mpd with external authentication like this one (mpd manual here): ---- # mpd.secrets configuration file # An external password access program gregory "!/usr/local/etc/mpd/get_passwd.sh" ---- It is a very convinient way of authenticating users I admit . However there is a major disadvantage - you cannot (according the documentation; will be glad if I'm wrong) assign ip address/range to the authenticated user. You will need to use RADIUS authentication, in order to do so. However, I don't feel like deploying RADIUS just to have a simple and convinient way of authenticating my VPN users against a database. So my question is: has someone of you , guys, patched mpd, so that it can understand ip address/range ardument upon successful authentication? Don't want to re-discover the wheel you know. Also, Archie :), if you read this, could you share your thoughts about it? TIA, Emil Filipov