From owner-netdev@oss.sgi.com Mon Apr 1 05:07:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31D7kj30403 for netdev-outgoing; Mon, 1 Apr 2002 05:07:46 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31D7ev30399 for ; Mon, 1 Apr 2002 05:07:41 -0800 Message-Id: <200204011307.g31D7ev30399@oss.sgi.com> Received: from arpabox([211.80.41.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm53ca886af; Mon, 01 Apr 2002 21:07:31 +0800 Date: Mon, 1 Apr 2002 21:9:27 +0800 From: Laudney Ren To: netdev Subject: T/TCP for Linux CVS ready X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g31D7iv30401 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, everyone: CVS has been ready. Everyone now is able to check out a copy of the latest patch source codes. The module name is "2.4.2". More details can be found at http://sourceforge.net/cvs/?group_id=43528 From owner-netdev@oss.sgi.com Mon Apr 1 05:07:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31D7ua30414 for netdev-outgoing; Mon, 1 Apr 2002 05:07:56 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31D7ov30410 for ; Mon, 1 Apr 2002 05:07:51 -0800 Message-Id: <200204011307.g31D7ov30410@oss.sgi.com> Received: from arpabox([211.80.41.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jmc3ca886c2; Mon, 01 Apr 2002 21:07:55 +0800 Date: Mon, 1 Apr 2002 21:9:51 +0800 From: Laudney Ren To: netdev Subject: T/TCP for Linux CVS ready X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g31D7sv30411 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, everyone: CVS has been ready. Everyone now is able to check out a copy of the latest patch source codes. The module name is "2.4.2". More details can be found at http://sourceforge.net/cvs/?group_id=43528 From owner-netdev@oss.sgi.com Mon Apr 1 06:51:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31Epj432407 for netdev-outgoing; Mon, 1 Apr 2002 06:51:45 -0800 Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31EpBv32394 for ; Mon, 1 Apr 2002 06:51:12 -0800 Received: from isg.de (dialin-145-254-208-018.arcor-ip.net [145.254.208.18]) by mail.isg.de (Postfix) with ESMTP id 161E2945B41; Mon, 1 Apr 2002 16:50:25 +0200 (CEST) Message-ID: <3CA87263.6FD1F1AF@isg.de> Date: Mon, 01 Apr 2002 16:44:51 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17test i686) X-Accept-Language: en MIME-Version: 1.0 To: jamal Cc: netdev@oss.sgi.com Subject: Re: Patch: Device operative state notification against 2.5.7 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi Jamal, first thanks for your long reply. I've moved the last part of your mail to the front to answer on it first. > If we were to follow the BSD or CISCOish view of the world, then > removing a cable or death of allocated virtual circuit/tunnel would > mean !IFF_RUNNING. You've caught me, a lot of my networking experience involved cisco stuff ;-) Anyway, I thought the semantic decision has already been made during the development cycle from 2.2 to 2.4. In 2.4, IFF_RUNNING of the in-kernel dev->flags it totally unused except for broken drivers. What you see in fact as IFF_RUNNING when querying an interface from userspace, is the LINK_STATE_NOCARRIER bit. Look at net/core/dev.c::dev_ifsioc(), case SIOCGIFFLAGS or the rtnetlink equivalent. Consequently, dev_change_flags() does not touch the IFF_RUNNING flag (part of IFF_VOLATILE). > NO_CARRIER | IFF_RUNNING | meaning > -----------|-------------|------------------------------------ > !set | !set | There is carrier, but no cable > | | no sense for ethernet; but may be useful > | | for PPP (for example line protocol is not up) If LPCP in a PPP interface is not open and the interface is not waiting for dial on demand, I'd consider it admin down, !IFF_UP. May be the term "carrier" in the flag and functions is simply misnamed and we should have a three states instead. If the interface is admin up, it's operational state can be: -up The driver is sure that it can transmit and receive packets over the line. Depending on the driver, that can be HDLC framing, HDLC keepalives, ethernet carrier, generically said some kind of heartbeat. This state does not include any protocols that might be used over the line, just that layer 1 is up -> IFF_RUNNING -down The driver cannot transmit packets. This may be the inverse of one of the conditions above, but can also something like a stalled ethernet tranceiver (adding a fourth internal state) -> !IFF_RUNNING -unknown Some dial on demand interface that is currently not bound to a physical or logical line, mostly your truth table entry quoted above. May be these interfaces should simply have an IFF_UNBOUND flag that is set in this mode > Think of either a bonding, VLANs For these, operational state should follow the underlying interface(s). > or extreme case where PPP > circuit is up for one protocol but not for another. That's a completely different case. If negotiation for a specific protocol fails, the interface is still admin & operational up, but cannot have a valid address for the protocol in question. In this case, it is the users' decision if it makes sense to keep the interface admin up. > > Is it possible to send (netlink) messages from a softirq? > > Why not? You are right, but my thread actually calls netdev_state_change(), and the event devinet.c::inetdev_event() requires holding the RTNL semaphore. As I want in kernel notification, so that f.e. the VLAN driver can react on state changes of underlying devices, some kind of process context is needed. > In regards to walking the whole dev list: > There is no point in polling when there is no work to be done (and > therefore no need for you to walk all the devices which have not shown > interest). A simple "registration" by devices raising or lowering carrier > would be the best way to do it (via netif_carrier_on/ff). The first > device on the list also wakes up the thread (or as you do right now > always wakes it up). I'll have a look if I can implement such a list. There are three reasons why I haven't done it in the current version: -netif_carrier_on()/_off() seems to be designed to be called from anywhere, interrupts, timers, processes, so I didn't want to add too much locking and memory allocation in this place. Also I have to admit that I'm not yet long enough in kernel programming to know which kind of memory I may safely allocate for list elements from an interrupt ;-) -When the thread goes through this list of events, it has either to check for every element if the device still exists (currently only possible by traversing the device list so that the thread would actually get _less_ efficient) or the event list has to be consulted on interface removal -A runaway driver must be kept from allocating *lots* of kernel memory by calling netif_carrier_on()/_off() in a tight loop And yes, I was lazy and didn't want to overoptimize stuff that lies dormant nearly all the time ;-) > Note, you want to report both transitions and you also want to make > sure its not just simple noise. A better solution should forward an op down immediatly and delay op up by a defined time to check if no other op down arrives, but this would have to be done before allocating list elements. Should be possible with timers and extending the device structure to hold these elements... I'll think about it. Cheers, Stefan From owner-netdev@oss.sgi.com Mon Apr 1 07:56:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31FrPg00833 for netdev-outgoing; Mon, 1 Apr 2002 07:53:25 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31FrGm00820 for ; Mon, 1 Apr 2002 07:53:17 -0800 Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA14608 for ; Mon, 1 Apr 2002 07:47:59 -0800 (PST) mail_from (srompf@isg.de) Received: from isg.de (dialin-145-254-202-016.arcor-ip.net [145.254.202.16]) by mail.isg.de (Postfix) with ESMTP id BDF968F7AB8; Sun, 31 Mar 2002 12:26:41 +0200 (CEST) Message-ID: <3CA6E3BF.8815AA4F@isg.de> Date: Sun, 31 Mar 2002 12:23:59 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17test i686) X-Accept-Language: en MIME-Version: 1.0 To: jamal Cc: netdev@oss.sgi.com Subject: Re: Patch: Device operative state notification against 2.5.7 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi Jamal, > in the future can you please just post to netdev on networking > related issues? I responded to lk, but feel free to remove it > from the list. ok. Do all netdev people already know the patch or shall I repost it to this list? > -I am not sure the idea of using a kernel thread is the best. Maybe > move the checks to both the tx or rx softirqs instead of its own scheduling. > -In particular, it would be a better idea not to just go walking all the > devices; only walk devices that have raised an netif_carrier_. Is it possible to send (netlink) messages from a softirq? Anyway, in the tx/rx softirqs the check would be executed for nearly every packet, so the tradeoff of having a kernel thread that polls the devices on request (so may be never as long as the network is fine) seems better to me, even if it has to walk through the complete list. > -A shared devices bitmask across SMP should be enough (i.e no need for > per-CPU state) Neither dev->flags nor dev->state are per-CPU. Am I missing something? > -Another thing might be to double check that the condition that raised > the state change is still valid example - > in between the moment you say a link is down due to some bad hardware > fault to the moment some device timer recovers it; The patch does that. After the thread wakes up, it iterates over the device list and sends only messages if it sees differences between IFF_RUNNING and LINK_STATE_NO_CARRIER. > -Also IFF_RUNNING seems to have inconsistent semantics in a lot of > drivers. It should really stand for "operational status" whereas > IFF_UP should stand for "admin status" -- anyone wanna shed historical > wisdom here? Ultimately, that's what I want IFF_RUNNING to become in linux. There are 14 files left below linux/drivers that still play with IFF_RUNNING instead of using the netif_carrier_o* functions. I'm willing to supply patches for them as they are broken anyway, but I won't be able to do more than a test if the modifications compile. Cheers, Stefan From owner-netdev@oss.sgi.com Mon Apr 1 08:08:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31FrPg00833 for netdev-outgoing; Mon, 1 Apr 2002 07:53:25 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31FrGm00820 for ; Mon, 1 Apr 2002 07:53:17 -0800 Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA14608 for ; Mon, 1 Apr 2002 07:47:59 -0800 (PST) mail_from (srompf@isg.de) Received: from isg.de (dialin-145-254-202-016.arcor-ip.net [145.254.202.16]) by mail.isg.de (Postfix) with ESMTP id BDF968F7AB8; Sun, 31 Mar 2002 12:26:41 +0200 (CEST) Message-ID: <3CA6E3BF.8815AA4F@isg.de> Date: Sun, 31 Mar 2002 12:23:59 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17test i686) X-Accept-Language: en MIME-Version: 1.0 To: jamal Cc: netdev@oss.sgi.com Subject: Re: Patch: Device operative state notification against 2.5.7 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi Jamal, > in the future can you please just post to netdev on networking > related issues? I responded to lk, but feel free to remove it > from the list. ok. Do all netdev people already know the patch or shall I repost it to this list? > -I am not sure the idea of using a kernel thread is the best. Maybe > move the checks to both the tx or rx softirqs instead of its own scheduling. > -In particular, it would be a better idea not to just go walking all the > devices; only walk devices that have raised an netif_carrier_. Is it possible to send (netlink) messages from a softirq? Anyway, in the tx/rx softirqs the check would be executed for nearly every packet, so the tradeoff of having a kernel thread that polls the devices on request (so may be never as long as the network is fine) seems better to me, even if it has to walk through the complete list. > -A shared devices bitmask across SMP should be enough (i.e no need for > per-CPU state) Neither dev->flags nor dev->state are per-CPU. Am I missing something? > -Another thing might be to double check that the condition that raised > the state change is still valid example - > in between the moment you say a link is down due to some bad hardware > fault to the moment some device timer recovers it; The patch does that. After the thread wakes up, it iterates over the device list and sends only messages if it sees differences between IFF_RUNNING and LINK_STATE_NO_CARRIER. > -Also IFF_RUNNING seems to have inconsistent semantics in a lot of > drivers. It should really stand for "operational status" whereas > IFF_UP should stand for "admin status" -- anyone wanna shed historical > wisdom here? Ultimately, that's what I want IFF_RUNNING to become in linux. There are 14 files left below linux/drivers that still play with IFF_RUNNING instead of using the netif_carrier_o* functions. I'm willing to supply patches for them as they are broken anyway, but I won't be able to do more than a test if the modifications compile. Cheers, Stefan From owner-netdev@oss.sgi.com Mon Apr 1 08:30:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31GUbq01318 for netdev-outgoing; Mon, 1 Apr 2002 08:30:37 -0800 Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31GUH901308 for ; Mon, 1 Apr 2002 08:30:17 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id LAA27549; Mon, 1 Apr 2002 11:30:16 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g31GPHP13286; Mon, 1 Apr 2002 11:25:18 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 1 Apr 2002 11:25:17 -0500 (EST) From: jamal To: Stefan Rompf cc: Subject: Re: Patch: Device operative state notification against 2.5.7 In-Reply-To: <3CA87263.6FD1F1AF@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Stefan, On Mon, 1 Apr 2002, Stefan Rompf wrote: > Hi Jamal, > > first thanks for your long reply. I've moved the last part of your mail > to the front to answer on it first. > > > If we were to follow the BSD or CISCOish view of the world, then > > removing a cable or death of allocated virtual circuit/tunnel would > > mean !IFF_RUNNING. > > You've caught me, a lot of my networking experience involved cisco stuff > ;-) Anyway, I thought the semantic decision has already been made during > the development cycle from 2.2 to 2.4. In 2.4, IFF_RUNNING of the > in-kernel dev->flags it totally unused except for broken drivers. What > you see in fact as IFF_RUNNING when querying an interface from > userspace, is the LINK_STATE_NOCARRIER bit. Look at > net/core/dev.c::dev_ifsioc(), case SIOCGIFFLAGS or the rtnetlink > equivalent. Consequently, dev_change_flags() does not touch the > IFF_RUNNING flag (part of IFF_VOLATILE). Ok, I didnt know of this decision. In that case get rid of any calls directly modifying IFF_RUNNING in the drivers and have them make calls to netcarrier_*. LINK_STATE_NOCARRIER is also good enough to provide synchronization/serialization issue i mentioned earlier > > > NO_CARRIER | IFF_RUNNING | meaning > > -----------|-------------|------------------------------------ > > !set | !set | There is carrier, but no cable > > | | no sense for ethernet; but may be useful > > | | for PPP (for example line protocol is not up) > > If LPCP in a PPP interface is not open and the interface is not waiting > for dial on demand, I'd consider it admin down, !IFF_UP. I agree. Lets forget this now that i know there was a call to use LINK_STATE_NOCARRIER to reflect IFF_RUNNING. > May be the term > "carrier" in the flag and functions is simply misnamed and we should > have a three states instead. If the interface is admin up, it's > operational state can be: > > -up > The driver is sure that it can transmit and receive packets over the > line. Depending on the driver, that can be HDLC framing, HDLC > keepalives, ethernet carrier, generically said some kind of heartbeat. > This state does not include any protocols that might be used over the > line, just that layer 1 is up -> IFF_RUNNING > -down > The driver cannot transmit packets. This may be the inverse of one of > the conditions above, but can also something like a stalled ethernet > tranceiver (adding a fourth internal state) -> !IFF_RUNNING > -unknown > Some dial on demand interface that is currently not bound to a physical > or logical line, mostly your truth table entry quoted above. May be > these interfaces should simply have an IFF_UNBOUND flag that is set in > this mode I think we should use SNMPs view of the world. RFC2863 still hasnt been obsoleted, AFAIK. Look at sections 3.1.12-14. There is a correlation between admin/IFF_UP and oper/IFF_RUNNING. > > Think of either a bonding, VLANs > > For these, operational state should follow the underlying interface(s). > > > or extreme case where PPP > > circuit is up for one protocol but not for another. > > That's a completely different case. If negotiation for a specific > protocol fails, the interface is still admin & operational up, but > cannot have a valid address for the protocol in question. In this case, > it is the users' decision if it makes sense to keep the interface admin > up. > RFC 2863 covers these overlays well actually, look at it and then lets review again. > > > Is it possible to send (netlink) messages from a softirq? > > > > Why not? > > You are right, but my thread actually calls netdev_state_change(), and > the event devinet.c::inetdev_event() requires holding the RTNL > semaphore. As I want in kernel notification, so that f.e. the VLAN > driver can react on state changes of underlying devices, some kind of > process context is needed. Not sure if this is true. But like i said no big deal right now .. > > > In regards to walking the whole dev list: > > There is no point in polling when there is no work to be done (and > > therefore no need for you to walk all the devices which have not shown > > interest). A simple "registration" by devices raising or lowering carrier > > would be the best way to do it (via netif_carrier_on/ff). The first > > device on the list also wakes up the thread (or as you do right now > > always wakes it up). > > I'll have a look if I can implement such a list. There are three reasons > why I haven't done it in the current version: > > -netif_carrier_on()/_off() seems to be designed to be called from > anywhere, interrupts, timers, processes, so I didn't want to add too > much locking and memory allocation in this place. Also I have to admit > that I'm not yet long enough in kernel programming to know which kind of > memory I may safely allocate for list elements from an interrupt ;-) Which is why it is a good thing. You can serialize.. > -When the thread goes through this list of events, it has either to > check for every element if the device still exists (currently only > possible by traversing the device list so that the thread would actually > get _less_ efficient) or the event list has to be consulted on interface > removal Checking device still exists has to be done always. > -A runaway driver must be kept from allocating *lots* of kernel memory > by calling netif_carrier_on()/_off() in a tight loop > > And yes, I was lazy and didn't want to overoptimize stuff that lies > dormant nearly all the time ;-) You might have misunderstood me. Lets defer this to later, first step is semantics A first step could be to get rid of the timer you have. Only wake up the thread when necessary. You can then look at the NAPI code for an example of registration and the concept of not going through the whole list. cheers, jamal From owner-netdev@oss.sgi.com Mon Apr 1 08:49:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31GnKO01643 for netdev-outgoing; Mon, 1 Apr 2002 08:49:20 -0800 Received: from mail.gmx.net (sproxy.gmx.de [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31Gla901612 for ; Mon, 1 Apr 2002 08:47:36 -0800 Received: (qmail 8168 invoked by uid 0); 1 Apr 2002 16:47:14 -0000 Received: from a1as06-p175.stg.tli.de (HELO havana.yon.net) (195.252.187.175) by mail.gmx.net (mp002-rz3) with SMTP; 1 Apr 2002 16:47:14 -0000 Received: from localhost (localhost [127.0.0.1]) by havana.yon.net (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g31HP2O06040; Mon, 1 Apr 2002 19:25:02 +0200 Date: Mon, 1 Apr 2002 19:25:02 +0200 (CEST) From: Yon Uriarte Reply-To: To: K P Muthuvelan cc: , linux netdev Subject: [PATCH] NAT Traversal was: Re: [Design] ipsec_rcv In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="380376598-1361968761-1017681902=:4641" Sender: owner-netdev@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --380376598-1361968761-1017681902=:4641 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, (I'm crossposting this to netdev in the hope to get more answers to my questions. I hope the patch is not considered too big.) GRRRR, I should keep up with the list more often, sheesh, this even came before my 1st announcement. I guess I'm on too many lists. How is your work going? I'll comment a bit on how I've tackled the UDP->FSwan issue: When pluto detects a NATed connection, it will add extra bits (the ports) to the SADB_ADD message. Upon detecting those bits in the function ipsec_sa_put():ipsec_sa.c the matching UDP sock is found (this is always a socket bound to ipsecN_ADDR:500, not *:500) and its data_ready() callback is changed to point to sock_ipsec_natt_readable():ipsec_rcv.c. rationale: * no kernel recompile should be needed * there should be no overhead for UDP socks not owned by pluto and with at least a matching UDP encapsulated tunnel I havent implemented reference counting yet, so once a sock gets changed, it stays that way. sock_ipsec_natt_readable() detects if it is a UDP keepalive (drop) or an UDP-ESP packet (calls ipsec_udp_input). It calls the default sock->data_ready() callback (sock_def_readable) otherwise. In ipsec_udp_input I do basically what you describe further down: * adjust iph->protocol & tot_len * memmove the data 16 bytes forward (overwriting the udp overhead) * [n]h.raw += 16 * skb_pull 16 * ipsec_rcv(skb) I havent implemented error_queue handling yet. There are a series of issues with this delivery scheme: * skb->dev gets sets to NULL in the udp delivery path this; really disturbs ipsec_rcv, so the packets get 'received' on a device stored on the SA (thx mcr for the idea). This means some stats are lost (the ones about errors before we can find the SA) * I'm not sure this is SMP safe. I've tried to hold any lock I could find in struct sock (at least the ones used in the normal data_ready cb). I suspect there is a window in which the packet is enqueued on the sock, the sock is unlocked and we havent yet got the lock on it, so I suspect another CPU might dequeue it for us (the waitqueue on the sock hasnt been 'awakened' (that is what sock_def_readable usually does), but I dont quite expect this to be the only way of initiating sock dequeueing) and deliver it to pluto. This window shold be about 10 simple C statements and a function call. Of course, I cant really pretend to quite understand the code. The udp-encaps receive device is hardcoded to ipsec4 for now. On Sat, 15 Dec 2001, K P Muthuvelan wrote: > This is what I have done in udp_rcv to process UDP encaped IPsec packets > before passing them to netif_rx(). But, how should I adjust > sk_buff->data? > > udp_rcv() > > if the packet is destined for IPsec > determine protocol = ESP/AH AH support is being dropped, from what I've seen in the -01 drafts. > remove UDP header, Non-IKE marker, Non-ESP marker, AH envelop. > skb_trim(skb) Is skb_trim needed? Why care (and waste the cycles)? The skb might expand anyway on decompression? And why should there be space left on the tail? I think moving the ip header'll be cheaper than moving the whole udp payload (wag the payload ;-) > skb->nh.iph->protocol = protocol (ESP/AH) > calculate skb->nh.iph->tot_len > calculate skb->nh.iph->check Is this needed? The csum's been checked already. I cant find a reference to _csum in ipsec_rcv until the packet's already been mangled. > adjust skb->h.raw to point to ESP/AH header? > /* how must I adjust the data pointer? sk_push() */ > > Thanks > Divya Mukundan & KPM > > KPM, > Graduate Student,EECS, > University of Kansas, Lawrence. Some further comments on my patch: It is a slightly linted and only tested for compile snapshot of my working tree. I write comments as I go on, they might or not be actual wrt the code. Specially the comments about the comments might be out of date. It is against 1.96. You will need to apply the small patch to the linux tree (I use 2.4.18 uml if that matters). I've started implementing --ikeport %any to support real anywhere-NATed-RW, but it is not ready yet (it will hit an assert almost always). Support for AH is on the way out. Transport mode is mostly untested, specially I havent used the NAT Original Address yet (it isnt correctly sent to the kernel). Support for the dummy NAT detection is removed. When sending it just insert a bigger 'ESP' header. I tried to keep the changes as unintrusive as possible. Sorry, I've yet to convert all comments to C-Style, // is quicker to type. As always I welcome any comments, suggestions or bug reports. TIA, HAND yon --380376598-1361968761-1017681902=:4641 Content-Type: APPLICATION/x-gunzip; name="diff.natt.2418.apply.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Patch against 2.4.18 Content-Disposition: attachment; filename="diff.natt.2418.apply.gz" H4sICGyWqDwCA2RpZmYubmF0dC4yNDE4LmFwcGx5AM1VbW/bNhD+bP2KA/LF tizbkhXH1bA1qZNuARonqJw1wzAItEjZhGnKICkvBYr99h4lt5XsuOvHGpJo 3stz5PG5I+VZBp7HnlNRUPbr9M+4NiMqXdWm3f9qkz5lWyZpXbI6EnX7mSBL XTdKc5nxZRe8WaFAcFk8e0E/7PuTAZelyUAyM9B5uu6voNiIIHxR5Xie93/u rZgYuGYpBAEMR9H5ODqfQDAc+o7rut/Bbs0LBndEgR+Afx6dh1EYWL/AubwE bzIZ9sbgTiYXPX8Il5cOQHeAHwfYs2FKwi7nFCxSQlmGrzaqSE27GkoFdDu/ OK7jnvEM0IZLRtvT+9nb29+T24f4Zprc3V8/vrvpwKALnz5BNYPXGMZ9MYZi hJKFYM0YPeDSgGDSBjvDg+GZg6tEzFvJDSeCawZprlhpzwzsiOIWRpcbOorE 0SuhxJB6GHTr2rEHjdh6jUHpz8mtgm5PUKvUfJ9ZpUlJrKutgmACw2EUvtoT 5DSxKrcarwI/CsPIr/FqPOldgIvfVyWp9unHI2yhc6LS3de0r5NFgZnFJC8w y4eWPE+NaB+cRsWFdEN7UEjNl8g4ELlcAlHLFzAo15hLyQ5p+wWozDz6eRWH fUuqBoHbFWdfd6BG2gaUDbMLE5Hn62LbLkYBaEKpwvX5Y9DbXBn8i1L6TUor qV0AUqvO6mYAC73hi3LUhhiuDU/137P3yfThMe4G/+CGz6q6g8frh+R2Nk3i +dU8bmecCdppteLZXV3cBOpBZXYCJHnzxwkcqzkB9TPViuUrvvrjRvfTr2xu SI9rpKFuxYWsiD4E34+Ci2g0qoher4+mywdkZOkysi72Cb/Vhj8Obc+1A/LA lsfN08P9+3kS/3X35v5dG0tCFTLJuEAeWD4fqdPVuqbe86Yk74904JdMOrbv g+MehDrsyZamCFKwBVOwxtwvGWS5gtnVHIwiO6Y0ET34l4FkmAKTW34zlbKt rZQNsyyGLbGdVjsu4C+XQEDmakNEqdy3YYInvsKPYGBWbIMw3hqLgiG4zA1C aI0yKDRGRDzWL9Funm1RWQ+7SVKIqj6932yjLzfxsd3Z4ypU2YWmRILCaw2v jkFKhABuHPfp6QnSFcPSxpyaFcdgutwSbgrD2gAyl94mp4WwEJo5ru0NzfQ1 ukKtwl17czVNJePLVWJsjsur6fjY6xapYMQe/WeEzbiE8AgAAA== --380376598-1361968761-1017681902=:4641 Content-Type: APPLICATION/x-gunzip; name="diff.196.rel.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Patch against 1.96 Content-Disposition: attachment; filename="diff.196.rel.gz" H4sICCGWqDwCA2RpZmYuMTk2LnJlbADsXHt32siS/9v+FB3mjFeyBUY8/MDX niE2TtjY4AU8M9lsjo6AxugaJK4knPgm2c++VdUtqYXFw05m7p49y0kMSP2o rq6u+tVDnJ7Ci80m89DbD2bDfmHAzEKJPQTwVmZ483Q7n8/jxX211da157J/ t11WMlmxWjMrtVKJlYrF0vbe3h72Tbf+nQ/Zte2z0iEzD2uVaq1YFa1//ZXl q0dFwzTZHr5Xjtmvv26zrS0GL2fEtFn+bOZ7oecM2atTdtNp99pW8+a8fX0T tfr6lQVh/iwIrZk3cQaPbIfdtK+a5++t3m2r1bjSo4Zftvd+ckZDPmLNm27j 3GrVe1avU/+t0enWr7b3RCNqtrW1NbccNzQPrJBxd2DP2ClbPQv7hbox1mid 12+6t1f1XrPdsq7bF42oRS3zXqfe6t60O70T6r+/ywZjPrhncpbdfbrsjDT2 inn2/YQ/WlNvyJlO17/ISaGb504emT0csnDsBILoYD6xQwc2auT5TLaEl+u5 eTEU05xZwAc6oyFxLtlKvk28O/indc6tq/Ybq9voNNu3XYPlYC8f+xxnc9w7 Nh/OFuZzXHWSbj2nn6QHxp1lGjLUtUNr6Nuj0Jp4A3vCxGYmV30+9UKu6zH5 X9bRVt+UKlb8/PPnnKHN3cC5c0FCYcf1ZxDFdBavC1+RoGjyw+lyWdCluGxl tLi9uEkkZnWrtOwgDd/kJz4JeHxxOase4FwtZVar3Xq6hd48tOww9LWnNAla mSFGMhg2s4Y8GMiPD/aEvgYxYQbbCX3bDaxZP5Djf0sOYvIJV8NSAv/CJaWW w9YsJx9TufLkx+0Y++XFp1+ZbDXbNuIvW8LfNIfhw0+RnAj6122uaLWWIUrT 7+BIasL1spSx3J+4O3RGkfr/Fn2IV9mtW1fNS5jz/U3DYOo3kKjzduuiS5xc NTvaL7N8VDIO2Z5ZKYEhqwoDRgTtgjLmDCyOPZ+EDHrNOfNGrIdEzjw/ZNeo d0Fd20Ewn/JhIZf07KEaH3gurGjoDMJg33vgvu/AtDToRbvJtH/M56CHhqzP J94nvRB33l9t6YBnqII1xp6p7agjIx4E+bP06crUdk+0lNRM7JnjqGNEMvvy /lIqUCAkNV+2TxUgFDpT7qtIqJKJhGSzrR7sKkGhY1Y8qJXKtUpRhUKVheaI nOoznzGTmceInMyDBAuVj40Dtgd/BQ76yXEHkznISM53h4VxTr0ixktf+zS2 B/d4beX+J+1xk0HAQLICeyL6Se5sI6aYei5AL9cZMGyB3AXpxXm1so5SRp+t kCg/qhhHbO/o0DCPiPRIElmE5IIQEVzr9goRmbDk+a0ZSD73Q00qFP7A3RAt JzU7gQbpG4w/nKxeG4vnY+HjjJMV/q3R6pEovms0bupXzd8aIMwgQV9IihZI ALtxbyskYJP0LUEE6tHEOsWMWzLq4sKUUVNLQ6GUykp8uHj9RoP/FqijXqd9 ZQiNAwoHmG0eV41SNeb2EiazrQGMLicDheLyAR6UkxXc5w9ZvMdR13A/HnE1 +8ni7OywRZbDvCzi6tevoJ9ojFfLx8BXMo5KP1MMwB7A6ieUZY+qR6Rl8URn uEPrtOvzJXBBvCSf1whY9uaQUptx7sOlQf4sHNthYexBO8DqPkKegIMQzH0r CO2QwyIRBwmBQ8EqFU3UP6WyaZjlxJAFA9u1wA0bWMF47oaBRugJ7/R9bt/D lzViMbABwGVwoSYtSiKIsfieyFsBLFuwRlC7p84bMwWlPJmj0yCFf93s1SSd oMx6oKtY6DGfE0iYOqHBwC+6cx44m88S40mMqJjHaNIr1QN4SzxS7s6nwAPv k7ZD6lew33LtKQ+M1JaAWXqwcP91XUDNiFMSi+RjD1fbRXE9PU11j0zt8gZb cig84FvQAh0PbEgTu/xziLtCSymXjTIs5bBolEtiLYmS+YZoYNXWAeP++OMP 5kxnEz5FUbvjLvfBIkw9H9g5BrvnuZwRTfskVAQ/YH7uuwzBOOCfCQ95vIf+ fBAy2TLAhX5BORfKSzkHIAdRYyHju7rUa3vSDRSHI91ml7RodA/9Xo1Ys8Mf Jk4QnrATJr6neaXHxwrpIG5GWnQv9jpZpkLGCxb6IjlBAvodQP7PAcpan8vV D8H1DIGeuTvMGRLIR17jBiJFLEmLVERPdBJi9y9baGgEEJrF5SRqMWbISq2V TJwtc/G4I5/z1I4qXRcUXuY+r1ihVIzw9i3WACp+o6CGNfQcwnBlgeEOUhgu ik8pTbe6c5dd8j4rVVipVCse1qqHKo47yOpihxTXKiPiq5WrtZKZYLkKYTn4 a5oLYG46rC4At4H/OAs9uIiayuf/mDs+AP1gbJuFMbPdIaMuhKe+A9tF9/4m Nr0wPlM1KMx8XX/TPK+xGffh6EzZCPwdNpq7BBjwsIeoPee+G6A4OyNnQJgb ECB6LEimuM1GvjclNwWw+FW722y9gT0fkdGZB7IROunx2CCyDpwP25kEhW3C jYSGJRyuVFRUKaWHsK4VeIN7EKHky0mqUeg/wl34m74s1M8p6/bqvYZ1XW+2 rKa5AbIEFiWDJFhK8ZZg0OLnS/lK4bzs5jun7L/jSayLTv2yZ13cXl+/t143 e4g3WPxaM+3iKMWiGCJCVKiWf9Rgkhv7G4w0UL/GuhkYiYYdj7z/GI5RFj5x NgZpjenc3xWhTNCN8wn6uNgjBGsDMgkCmk8mZH07gIYEzGL3BV93CHY8797h Wq9z24jVqSMuGuy83X7XBG+/+Z9wc+cJYNIjG1o+MhEOlI+PDLNCgghWFNXs KwwmBLa24/e94SNchGFkmDawh/0P9jwcR2GSs7MoTtLs1t9d31jdt83L3keA AkiYwQSJ8l6r8UfParVbDQp9qg02iWLHCG/F1vwSB9jUKX9rXrDaEyJY7HYv tse7Cjal8XSdXGqBT0CPpSBnDB2lquj2Lq1mq9fotEDYGp1Ou3MiPWEKqlTM A8OUSYHBBKBG6A0Ag95HpmVmOoEN7LFxeB+YRBtRgPlYPr4qZzRYLrAxDDi1 HdeCnWuauQT/5jc6/knXGgNeBRhNikUWYyqbsF6PTuIX8k3EUbAnExEuwiYU +hk5d3MfoAPCGLwTDeaKtIBICvTnzmRoge4FEOHMcP8CjQlxfCpMCfTYgMwo 4BOBhbiL4m6s2UhsELsxibGmr7CbAbcA5QT2HZcHKNoNcQ9YO4PjNesHcJvP Jo/xeawcg0Uosb1quWiUikI6FARpjwszlDvE0YkkymP49TQ6hvXb3luAOM1z MAJC+bMi7sZ8RsE5jHs9UFqAlWB/xNYR5xNvO5qOQlGFhUjU8pCYTEzBZjwh StxT41TfM5uSAls6k4iEKTPwYBbxT/Wu4aqYmPwnkZBrdEG6RLRhOZ+Brs77 m9662MHCOpP5/hK2Pm+6TflK0ZqKWUYYY1aqh5E3uetbYzsYP9gTAxXApzEH bwoEjcQcPYe/21OGLWTUGIFf1EnotBNSHPgJg3KfEJs5kc+BrUBwo+hb3/Mm eM0aTBwRLSBL5wQF5eLXryyJGMSXJQChbOiRBeLvzk4i6/ocHKYYa5j9RPLl qEJ8qZaOI76s0SeK60p0uZRvi6gDzyHR/iymE/jUciI9HQdnXi0oTtdzB6CG JL2uY0glKkkFy0+kAhQ9lABgQYBmo8C687357EkETuq/FcSeRHBigah3DQ0N f0TVnZOkXqLZBOaQ+j7ZuF9Suj/TqEszTeurmiWM+MACq8dGWYZ+gHHNi4HD NIBmNsmnEzp26Pm6gfbIxbvgYFO4yUFYH8w8d8h9ERsWC+JTBwDSvA+G23KG 2k4keYJK2nFjgdR4jdPHObgpMv2/eNVDYy+tBkAoEN/suUCc5Vx7UbnAK23V XuhKwzUjPqWejGy8R8CYrBXE19U1fC9mUo/GBjgGgzrNQCBsxBa+czcOwX+2 BxyQoYLBQSmBNwqHmkCPekcUKsAue8A1hMtgysFpJRAfzEcjjtgFZk/Bo6vG VeNae+pe6GyHaewZFQERiAJCliSsdvfjYLJK7Xw4s8I4AycrH1iUclaityzT IMZhiSzLuLGlivJRkbDRMkADa+wJhCGYnkz2fLARz5WAF7YYRdulA5GS5Hqv XY/9z6X59teosNB9g/b5dp0Vi0xsGxZXMLkTotAimjtdcMGyNn2hKGNJQhLx 5YLCJKqFzlwGgTN8W/0kjiilHUjYlRFoPTDDA28KWBQXyt7Wu281E3Sg42IU Ba85IVUXEF6NrYyG0U9dnh6UM7LeZklLbD9TLbriuwh/77J+1W3oJzIyf3BA oXmzXI4tEJD3FpY+AfXMrsExEfnktihyGDl+ACca7DEPmRYrZwbIjesUZGFv Lzon3TrL58/kR2DDLgbFxbcTdAaTm/hVxGaUYM628Igct2mihuiYUTBvGtxZ Q+eOAw2706EuF3FUEouoFg3zMLYyAed45Gz2CTZzYPtD2HcFMQxsF1ENRU+F acGMFmzM0CJXPWmq7UyH+TNnBFosf4YqyRAhQQvPeuwFaiAoUl/t6mipDYbd 0AvjPjWNY5VSU6Z0qIGumveJ3LKIYEbKJAKx0xnYB3DhxrZ7xwmUeaBjfSB5 Al+1hF6wgwabOP39wJ5yJKkwiDTCujQTmdfBYpz6ZYxJ4tFwbhJWGAxOBrIg vUrpfP4ps2dszVIaYiQvaElQV2xHodu5z9FjtVnIp9DT9h9VyQolbLbh4uyR sttoED2XF6TAHpvGMQrsYREdzih7ktQN4MJhn33W/xA4/+TeSMuZpllQ/uf0 j1Ec0HcHs0etb8Ai4YumsBq0ieze12Nrv0zpChw2UY689KJB3w64gz4rrO3n oPbzPIeFRTnWB7XkeurKQe3AmQIMhxEqz4e5h9QWtJpCnLJlurpnolgrJ+K8 NNGmU+xtOoUMJhmsn3U6mXo61Vg07iaqYtAh/iuhLBaB05tWu9NI3LOSWSJs XyqZ8R7LGpzAi6OS6FihqSGwg/QITw1j3ggSUUXCYkeYFAP7NRFGoaCUQaxL tKnxpUSbqnjrnBAMBZ1Q9dy73ieX8FUvivIztJmglTF3EHW0BwM+w3xSaD04 w0AjywIK+SQdjdkna4AmLCaa/Y5rcf8tZBNOLBgLBxNM4RTMFtodTYdFD2wA s8io6TwI486g6ya4EyJwheFWeaTMCuZUgd3lilFK2I1nVpoOJ7DvpyAiNpjH ABNEgW3NgOUz+3Hi2cNCYJ9sxk8B/OzJAFESKuQk6JWgCVBYwDnKdyQXA5Tb JGKeyqXIeC5yUmAQmTkEqOaIk37Z7HQVYhaqrGhCOARRMg1hscPOwAvTIwuC 6y4AG2DhBMwWQ7RKKdUGHRD2iB77u1ubtKVTRWo+rhFkW4vdMmZIaWQRGqcd 1XawM9iWeGdlNR1pAAnUqA2V7ukbeDtKzQI45eL8Vg+jYKDcesA2ODaKIR5U NQTQafRuOy0Lx76sN69uOw1tZvsBtxISsau2E8leP0A/fFEQFbJjeEGwDREc pWm/78wjAlMjzHDp/fv3UYhtyAcOlWWpHlaGsDFA2V9UZ4jCTXBiXQ62Ao40 6hJEYHhYYy8/wo5je0h0JMchK1QhA8/Khj5F3sLUZxAoQs3SmmaGmVcGmb89 ge8ZAeaYMl2NDAWo2ZIlg8SgbkWIHyUhS+ZBVcgXVV2heKFoqZnDGupOrCAl tIzmDrZmhgbLFanRm+47ijYb7KJLH2oRrjbYO2BMy8FmhL6Bt2mdLuLOxWKN XKwLwEjyXcdc2u62KBZFeIyoFA0Pxmqw3OARNi8u3ODDmiDlXSOLgg+JW/OR /a154ZhW/+xm3n/HHy2Aa39rOcp3GqiTMVJ6lKjPvRwD2vfP3sERMyRjj6pk CcrFihr/o3O2eMwEFoyyeHqStmHbebGVC6/YXJNPJkUZHZl3jZOWwxabx+fr WcMYsBUX9GcvY0T2g0wrnUpSu5Jvx0cESsvmoVFNLKix6vSdi3DfKpVKuspd pqy+L5S6Ui3kWk5uHXVq/vHPwELxyPYMcR2iPFKy6MeBxPEwyFSs0cgrAcJC rGUuY+kYSo8Varbe3lmWiE/UZVbgRuKDZf7Db6CZgGmg0qXl6ZDlaZZqsbIx KCeJygRIGoqHPxbqEZfOH6ONF8w/d8VWYrQUVdgTKpga/k+J4wrbtFog3Vks gnsrRXAxRvjiPaPM7dPI1YUm5NF4sp/gBSep26zgqb5ZLvZ5E9PhNL9/Ykqs vmjh7frKlVOhzL9o8c+YO66O+LY2zBg58pF6XYFhyBQA+BUFu4eH8pGBRXTS MWvLIIgCPxbgiE9Q5JMDQAbEm8WajS6vGemDEFhhFAuFwkcsNGG7LPO1MK2R 0ZuQ0YtBzgsBjmBupUp2tmIWjWr5r7az/nPtrL/ezvrPsrP/iy1Ws0S+0r/M YiXzP99i+c+3WH6WxfLXW6z/t1l/vc2ihbP/SzZLCRyoEBolXPq5GDJnWWTq cfgNzwQ6MlSbEoiAuEeJs4AipnwoohJobqAZDBqXqyZHZWF2LcHvcZqSbg55 yAdgDeQjIz/a6B5RWXIJi0JkbXdytkV13rIYU7QAOt64f+oRF0d67dM06xmx hA1Jqbckd4iPbmDYCzbnREZBJs4/wTelcnQZuBY8ofwnt4Zj2F2wvWLKqC7F jz+K4tcClaZE/EI+oZ9/aJYkSFEe3FASBrtLHlRTm8uYQJxahHbw5gyt2RA6 41YNxqCiP6RLSj7KQTDxQNUc6OBZ8G4wLMbATyebFIAuFEKlwk1zC/NAIp0Z sv4jgrBOz0LUYd3U31+16xe1VB3X9xZ/UfJFdIY+ohQMm+BJi2JXhwdFEtXj w4MFUf0AqAiQEEyroQd9c9nVNxBcaIZFSarkYlFS7o2Tg7//galukZHC0tqX iLJns8gtZ5E4p4t18AGR+EiK6inkxu2bt6/UtKCUcnoyRya/SQV5LKEyp4YC MdgjFYLYCBHsqeGh/mAIbsE7VkQZovLpIxNxHsHpQxGFPj6uxkh88wqx9ZmM FzFhs6oyf1lVmQI5xAmTdG9aXLa1psa7dHhEIfu9ctE0jUpVYRtJaIrXC2iY aSmSdBEG/KJUVq/g6WKqSTzT4wzZLnGZHlvb1VMMzuavmuvw7U+CJsoWFGRN B3y0fM+bajvJPT3N2xyuE8FcfhNIsAa1LF/yLH8Gy3WAjCcIGDNKoP7w8bBn yRkMuhG/8lm5IYVf+OzYaq7FLTJ4J72aDSDdi5izkNyKws4/tMouq5aOEuhL C+nYMsi+I5KIzymmw992iMhFYwAOTYK51tbObaWq5mgbVhbO/bjKuagI4Gnd P86R/K7JD6idi0rnEodoecnc1g+rl9v6scVyjC0vl1sZOcgumdv6loEpzwVQ lDaUYi4lndKvolxuaaHcM+rkUoomeTYqfjykdFSlOrOyWTQj2PMnAB+E7G/8 BeDTEcBn73uBT8LYZ+AI8RQsFpTNRph1eyhZlNVe9bNuWa3pB9vwN03KRcw8 lqq18kH6592W9kr/zFtF+WmT8iHtSTmKVIon9rv1i9fWHxbKWv3iotPodq2L bs+6vGr/XlvRpgtH67refVdbM45os2IvWPTzBBkD0PGoqT8kFD/FL3/UB6ff umi8vn3zptl6o91cgpC8t+gCgP5Ot2HddNqvrxrXhnxwqUjFL5XisWHK55Y2 606/RJQTHJf2QbC9xnLiXmQ1QAOOnM88ENEo8SwT7MsjDwv/5eZkSYK77oH/ wJty8VwmPoLJQ/LfxdATLn5RTggtoYCtbqN1AXZWa9QvW+3u7Q3pTKrbe0JF Gp9iMZ0oAsVZY0ODzV+dFiM/xiyKAw3vR0ZZHGju+xO7X0vCmXDBw9+4SArg l/38kWBwq21hnLx5jmpze0/w9rMFQIOqzAR74x8ssId9vAUIkdqJHw1AS4B1 PzQ1PvqLWlHt8dkS5YqiE31OnndPtdDjccUPdVFtAnjkj//T3pd3tZFke/4t f4qwqrElkIQ2xGbsowJR1pjtAS6Xj9uTJ1EmoEZbKyUM7XJ/9rlbREYuWrBd 77yZacoFUux73LjL7/KgBKVSyZj9haXBeRAW4uDMvNKKhMlK4I6XETk7hHUG G7d51P7tJM+Yesstw7VwGXZRvSFchBSDdasv4yEsFhxHaNDeChyZ0jP5juuQ S5rTEU4wuy+sgmjWXfvk9+aRvpT4P71A1mILJEQNwPWZdiQQEiKcu7/AIuoO fHXQOmyftGgkznMnzeNWngAsuh3Dlbh2dBdpPMaBg+sPk/7yC37c+4qfC+oX /PNN31OVcmOTlzVJ9HFVR6rSSxKeKOPuvTvxuXS851LTBS5iNyxIhI30/Kvp jUk396aaWUa4R2xdwmcLhmSVq6fDU0d8+rz3TIkhUnmbdEIqleq2Ubh9kXLs YRmF744r6rjEcGA8rJh50YUFitmfrJsEz0G8qz4rBB1JHz4pM5kP7q+n5ovc XHbmlEFYvAkUrVQ6Hm18DeK5uYNJsBgt1kqaxEmrbaZBxtpZ5hIUcBXAHboG f7QJcDYO/5MthKEXTYg4O2rut2KhrT/O2ucYOH9asyl4KNlC7F1I40WQLgTg ohKQLmpPGBUCr8J6TbG2FBL5WAEKy1+L511MaKY0vBAR9CWqD8lPjJ7TGJE3 HwxRLob68+3BBA3e/Ak/rYiBTBu7QYRPZbNhW6+cMTeXgLIClaMXS7HrT66L xJEpMnumWN4uTR5QtMZ84lqpwiT7syKzf0kBX1jBmkGMDf30GTYAXG4LUtnv nfPT00POBUsk/hDihWOHXjSTYWdZjdJWISP1ynZFKzrHikzmPUgG/d7GwGIG xxyWIU36gqWqOQ9Ap7mdSYH5Dx2C0XB7X9xH1Msnjn63x/btRFh8iguy6PzI xkPp6v6UePemJj5tUmrd5vhOmdsLaxfZs4U7iKXTKe/UFPURO6+1cEWreU4l aplKfkdz1fQqijEwxdYD2wPpxQ6EMdBNky9D5XUDBPrsDqZDRMcho6F8uHXq jTK9GRAmm/VPrVYHrtPrXvsExBhreRqgaQzm9N2vHy9bF4VEKWEv5k8S9SvC S6E3MDJZuldTwQITUim5Cf1Bh9/7yFay9yuctfMs/GlNZRexbDCVrLS1yGpK VGstqbn1FhayiQpKmGGJOuwzM0IsLRoba1xUaqfNmPBaIVFbfXtbA9WkXkuR 0u07aVbxhbmoqoVogfHL6nsLjY8ll734vnuRnOHIdUets684Hh9Yy01U3W72 bobj7uS2H13HKkIDsXCodLuIANLpUgDzy2nUj0k/HzJ/o4wAoPinIRLVVfVc /djPcyplrfiD/7GJ6FpUwHLf9eC1rGJoEsjWCtx7x+gVJWKQmzu+9z07nlD5 JR4eijeT21m5odZPZbS+wwkWSEJuF9mfmMaRdg+8ZymUzjykiemYZ6V7TaiQ IlvPfURZFIlfLYpl4E6K8PHOL5bLMXKlSvkI0bkbiA4bwjY/Klfdu+Oue9Xz FXeFTQ9Yz27s33fxRkDZh75kdhLqJrOV6yopYdWUsBoXUYYMVVVTdbWhGmpT bantp4RRIT++etZoJZ9glzV1SCsbnjWt899bB7RSTdN1kiMePLOSf2ZbfnRX YSn/TkbQRA/Z5kbz7pBNTuyg+M+/f2Jbfsq4JHY4aQN9Td2IA2/mDoeo+Vsc Elh73M6NAgGzu9cM5GjK/samydZei2/t0+YP7e2H0sMT9rZM8xN292nzP9v7 L93efxKg3YG6RNBTRH1R0cb8aQ2k3Ub986e0Jfrz5O9hW+infXZfV7m6GnYm /gTeAqh7enbfMOdErtIwccm2/JztnbLBhy7u8PgWHrq8vVPCrb0d39cQazZ2 Ss6uh8+k+aVW04vV0TWMHuAu1cOW3vjuqP6p/nlGM0aNT5UGHTKKIbTXljpv hq45cJCu5GbAYY8gf7LXA9Gu4zgJFDboRoMQwxrVelJhLq6yoj+QwoUliNQy zdgs2rby9pfdtNQMXiwYxnJAJwg7Bf+nxtGVgL9mxcJ6ot+7z0ISHIdt3B2h MSYKmXy3c2sGB5dEhAonO9HFRLgkS6HBa6lOqyT5XBK8IqBu8KfaCEEDnvAT myCBDWUPJqSmoIw+5RKKdDB0V91J3x3hMmOleJwbywouYtPeQ4SpSczifXdG QV98hN/oKVIW7z0qNEqcWRAlEt3zsKyuLmvsd4Y3AwSDINMS0jaZzC6NNBx2 Z0SybkNYl6mkXFbXbr/be5SCCTKUs3qiNGHs9rywGFIQ1YcFVoNLM1a0N+33 H6Ols+Ynx3Dpn+jIiMVwNToqinmt0bATWrp6z9AmJyAxOKSuUd3TcW93F6bx g9HiRN0R8gJ3ZWfd9SDN+sCfMNK14F1PpoOB35sHqD0/H20mQtcuI/e/UjOb SaNrL8g/121KpVJmQRr+FbFRKN3YPz05bP/m8MZpkmG3ks0UiWpdkFM5Vgdo n7GzOQjcWQS5yx7Y2AWbNqlnUTYeYcYTFSm4FyxPbAoa040L6sXlm6hTXR78 6hCXxGlfIK8pN/GuRnkV+kO79V0PNeXU2p6qNHaXkeqQEf6X7qRzS6UVX09Q tg0t7N2gLDh9bE72ndpBiz0iia+FizMK2hGIRJkCRLv8754CzfBO6TBiF/bG MEiPyoPz0DUDtvZWuVfDe5gQPWUe2SPgJJHJWnM0csewO2FS2UwB0/le6SfN 0F81DxtlYhczpGNddEyS9QRu1yvROTC7rh/YD4ygt3Bs4Hwa2R4AgpFazec8 uBjW4Ki6RYUGOB0axs9e6Aluudx5zerXZ/gMJSC9LZYtcZkthmUVX8NvJxh1 EYU+OvYQuBtPOB71IOHtBE6S3NqaNVuoTec+fukOnJ4bTAL/n+JVJJORSa8J lOpGrVBv6EnP8G9o/iccySJBU/CnCrKUoUfiXrMz7El5kTBUcAznPdQUyMyc eULIJ48h10pgQ2Oe+MQOyNB0+HLuk17sFUMdsHosTzI/ffXeLCG5cD0dE5ia N/wyKEkq1EEVN5kLltxXs3hkiqF1t94YSPTb0Ivi+qp8GI3hRXCXU1m6nFgR YMe+mFgj0XnodydaB4YyZlFd15jNFpS3PljvqpXROv0z+i/ckLur4muYI4Qx x4+D29LY/YIoWbeWf0lz6Cj17ghGH/aoc3bePrnMsXoCt0e9UND/yxPnj+P2 pSnC5JzeWoube44a3rBV40vcGgulnfPodiKyethQVJ/FHWq38C8awPWpGcKn jGIB+p0+kio8S/p+H8jLHCQl+z0+c6yBK74OhtNxx5f9GcjmxF6RSkYw7lh1 YHoPDZRmpPbEl1GYmukFVCEjtDtUoCVa2xsCfUg3FDxIaeGzPti0b3cES8CN rauDz0U9mcqeS9qaCY10fom/CcclfveV7MpmHRGw2+wx+/5lyjkXZeO5zzxp aWWi68pyYQtUKF7UML4C4/ZqJcD/XsN6WvfWe7kVb53+5cN1l8Fm/nF4en7s oF4XHzU6bjAZ3ga5cOHkgdAwQbg2IgE4U2ZFRBTUFl1ZP0hH8PWxiYyGtUqj VjPeFtIKxftjXqloc++8PW7uO8cHGxaJ0nyLATtL3B9LHOJwofVHuSzemtmC yuELazWP3wqK7zYhHCLXnSYhMhkhIWwi7KkF6rs3M+lMHkp9bwNPVQN86m04 EAxkQzhupIGVz8MBADG7dqUYEFb6Qhdo4CB1gI0l9oOjpxTMxfuRh8jSVoW5 Dr58nckPDuX3l51PDMwalLPs4JjaD5H/kEPpAPqD1SkEcr5R2STiuLHVsIjj TOZmiE+2nu8OpiMp65tZ4ietS6daWUj0LjH2ck3JvQlrxlhuhIsuT2MsQ2z8 OCeypuQM1Vpo8y6VnGcuPG24r+Zw0fruYYLn8SeCsTXd3iRb01q53ihUZWxJ 84fJQpJzeP59tyMWrZGzGq6TK1+MZ6cjrXy4zKPvg4u4H0gjoqSfb7aXVPb0 5CWr2dBN93L6Mk8opZPhUPXdwSMTmkEoYBn7iPw0EKe92FBUlGIwh74vnNaT qPRLOgR/mCM7LcNos2J4lgLqfy8jOVPgMcAW0k1allEZ+517pD2G40e0eZ8d yfa9kehZ2RI5VKb8oCOv6DG3fmqY4pGs7fP/0gGK/lHodc+9kYSzJ3Rt0YSu fYvoCaPe/DMVyYMW6I6MPBsFseVIudwQc55yodKwWAtiTjj2b7rBhO24IXvu hZmOWh5tZMq2MWqx1T7dXeREjcAfhE+7kBppnxA1ksLinU2b2F0l6iQtt+4X LkEZ6JWAyY+U5NYaLOFCs62IVGihN3uwpmU9WvHiY0Onx16Cy2R0IZ6yylU6 YWuVmjG9ypgaKiVUZN9jWEcrvDojvGaHL7DPz0wHc7uGJ+odeSW0BwrLp6h4 4J52dxvrbGhlElUIYtfLFn+0nupwUJIROxPZoTBE5U1Uho6yQ+ux5HMdDdaq pFuLfyLGbl9VFoG44QYVj4Ke445vpgiUpAEV9w+ct6cXl/D0Oz1V3womX9db kKt9YPIs1MfC8u58fPcsKvRdCzW/uGQumu+z7y9lDcKPW+dtoE3Pf5MiQy1U KBNPsdvhaEGZKI9/e3qWGCd2BLIg8/5Ru3WSHOPpCFkYC/K+Pzs4/XBi8uJ0 b9YrpPi+Wd8oVC0vvaJD6pMkjenucDR28CguFmUE1SuyuRlM+1f++DVZaBt/ SMMR+vQZ9vxXe2X0SWG+q9fo2xDO4HIZTdUzXte9+WcuGy0KMaCRkeMqDoHP ky8oeKqQcktjY6O2AV2GQqGz+aWceSvL/hGGKsd5Cyq7Apc4YyBFfZr2g5sS vWvZk59YXZVDj6LhSNluU4VpSdqBcAy6k+G0l1O6tnKhjL799GCEKDrCU5LR OMPKpOvC2kc9kF7Xk1Cr8/o9Tq504UF6NRS5WibuMG0tk1l6anSpYSS0w5B/ MGRf3Mc3YTXhsP2c+ZQB5SWZPhOmZbuy7KLzkb6OZQfKOpZdq151R0UhZF6H aO/utTMNYD9dofPP3nBw40CVwSf61B14/sNnuiB30+xlyULaNmypz7OXldQp 9rKx4zw111yZVgNBcdcaGhr3F2U8u5ZKcjv0hjfoMpagjIZjRWTGDYHjwdSI X2LRMhBtBdtSPEy/qyW1KCTukYvBG3YpRv6ytceFYiQ39wb6xeSN7LAFSSpa zK9N686O3l+eWrruFXaaC3/+JxkJ/0wbYaUlllWRWG4UNoRjn0JizG2UZbdK XEVaV3GL1dXVjDEtLWhMhGmoNWN+IB4VLOamIdPLJ9u9Psy3fF2Nmb6GY0Ve JuwyuIs7YshsW8NqE9eYLattsBopQlusfrl9xAMy0lAtMBwNu4OJoAYZg+g3 Uvks49PMUj3g6rMy5nsrDzS08FdzF/VssD5oXhsFZ4QZL9HIfE8xNwyxNuCW mJMUFj81m/W9cDCf58LZiE8YLqb84hldNTfjcfPo6HQ/N8eIN//0CZPXLfrg ETUmdBvte8lpOTk9bh0boAoB9BM+v11BIRyusvV5vu2xuZlDMsUuM2mYvfdk w2xs+ewyzbTqCZ6fXOYL/+xSqxebR6MOCg5b2zk4PYGD52375B3+vnA+tI+O nF9bzvuL1uH7I37L5yKmvTRnaNtLSw4X3HHzDzjuPucj/QcCYbWgEosMaOQ9 rWUlx+TWhkFMiFq0Uk2FRcG2JS9FLeAA8MmGTBIniu0tihqhlR0kSeXPd6+1 3R3c2TcIII40SQT94NtuyMiIW9gaD1G3S9jYhokjlMjWTq2xU59lZRvLNNPO tlIl7gv+2RZH9jRwtGcF+86+9WGgx64TEhemjwtofbxvalVbwUvtpoA2st2c OKsQ56UizLpxJz5Qt+Sd0oIK1jQsPLMYsp23t+uwFhfUSNxp/kZqlJrIlQKJ 92XPj+f3pw+LZ0aSJfUOK6lzopPPt3reJsufbRvOb3SFjlZ8t8+oO9QF0jhB qpCBeHSvraQIoJOWlFym5GD4gdpnkVgIkGNrjOJMod4ccyrdYMiwIHgaT8e+ hv2aB3X8C3GtmA5sfjxqH7cvoaOQSQB70+LjxrrRB30qSiSSYvThky7lMx4M qxyIOGPXhahaKeoPjxdbt+t0KYqllVTFUp1+rmZpdbMicJnaK8a4WxrwfTwm d1nBLgXSR/Sni37RHSJOcmNEY5RRGLtfHEoU9XI+Q20F/coIRBPrOFJWwqWU mnrdYBIFSc31XeK3ocPfEEtR7hPTVtZopucM/rEWbt8d33ETkUnqejnd0NF4 2MFT3HQhyJFjufB7PZdfPnGDEnPfoZ9z8YDESG1eoVNvhAWqN+FNqYcFGYzU FZ0pv6tF7x4KUxHiy+0O8Fga9jwFh9e46wcW0Cq+87toRC+zqxGe6EnYqNKb sNHQd6GFQ6gz4yz5WIHGE9Qv/K8Z+ZCZswI08d8+wQeO0zz5uAO9RdrhpWnV S10OS4lw0+e616g3FTZ8V2GI4FPxlz38zUh+xI9Hg1bT6r77cO2pV5zkWhj/ mzUCA9msV83dL9wF02/u4nc1Yc5GQBlPar9FnPLddaqM9nVGDJ3DA6d9cdG6 zEm30Z0UrJ1rj51gZb4uo5OL11CFj6lq5JiqzNepjV40cGwBrRCxSa0+JX/i otrewosKIZIF+wBpg/5kSvfFB+2vnERtAXI/1fHl+zch6ggT7Ovrg9m4XVDO K9xvwRd3ULp9rfltwifxVCUgtDl8uak7f4wiG/bASdqncrFI0e+PnfZhps5W +3z5pCXYwI2MjUY1PPQTiZW+1BYnL42+L1BA13BPRqg9YcGQRnhEFtRxkLaE G/XTZ423skguJuLs6gZTZgZNzCAWkWDq9I/DCxT9lbfK8ajz1u+tfYyrlMsz FXWJwhNjoLlQDbYpTIpIdDcKhUB2xn87Gt7sqOiCKtyrv82kgy3RymaqaCWS OC5gqexUq/ba3pyZaSZDrk6Hb71qqGDNj0PMScLELt1m7XBvEMDTAwJZWup7 BM6mk4oOtE7Mkh4ooLhINqlzRN4lmNMMsqAKECzrdW8a3Doj9krgXD3ablnT ILjzjC09HH9BZ6t8L0XBriLJw+Ez7tpo82/Q5t8sVDctgRQdmTAE95K2oPB4 ZNaw2x3D6WmdnZJuxInCEzRE9xWA/iXdr1KyznLJvKc7c+0/igtT24+rnbJj 3L5CX267/VI0fSee3tPp4REZTerppDNhRkMnvDiuagJkLlIcSG08ir/WV8XX 2kUsX/lZ3Fv/nPrJFCrmthXa3/d18/lLxGNrh0Kxi+zhHj24PvJHuOGgO9qF bESIr10g2+VjRqoH8VzDmpAq4hIRyeuFimTVQ0s12Zl1gzC3boRQMkuUIStO ra/P5hGHL1SxFUBxC0p3hIuHAit2Hq3tPLQ/Rm4Otqxs3EeneF2WtuZUzs6R Z9fxM7qoUEImd1pm3kiY2fhqUZO0Cy3Xyrz7GKqNVc6rG/qZkpFNGt3TeJyg PAKWIGI74q2J9tWDiSgZhUlxm+8aGk8GZ33JNd53gbrOGtfAhgn/zfYVWt8i jz4baCW0EcKj8B8jovpURuX4l38vv9wNaXLk5cDIGTEWjEn7HcO/MBxxMRMM SN35OmdSmS1rQmDHZMUvM/sSipXLzxSRKyrmycaT8DHxlMr0zkxWNl/oYTzM Ll8bC2UTqiffDP8GHeWgJUaXgK0HYmyPpZi3JRVJ2B3JeXguw9H1SnewAnAJ tw8ImYmfSJv8ZCjXxFdnpoOL8otPdm5IbJBH4YvTC8jz6+nBx11O4o+H6N5i +GXgj+PxMFeQgmsjw+BHPiggEB2Is2yTTok3av+dc9k6PjtqXrbUDn47a50f N09aJ5d4ZC9ZDO7nXCQ43Os0HfPrUXEWHXUwypWDJnzpox6y4dIxQVlndisy H6o8gEhFPNNsl4umAyPpXsEj89b3UgkIWBhDB+jhrttzECgBP+SfLXZyoJnA 5Pp1NZiIlSS5BEHoS/RGJuUOhjllTatxF80OI9jJkT60VD7mzIqNmdncMuof Zl51/Cm9Bl0yn8xpsOuz/CvJ/QO7Amc8Fbh7ZlaFXDlBVc8bqb82pP1qucRJ PT61nyp8JOGL5c7Fg5lH/5eVnqdy5YeV3sM6/c5njVSQB6KQCkQ+G3pctwZf SpPI2K+vsw2sE3RgRU17fi4Vr1BWDQU2Gdv/9+YR+YK1J9DYOJBqMp1ZIqS0 nPysxfwEp6ykPennrs2WmQ66QB+1D4K8KBNvVBjTsGws7QoC5RU6mlk1nmYS Mdr1DO2OWT5xPHMhzDZyNCIodiuL0gb1X8ekVwTdCtTwHs1GwkLFMAvplH9O uzBF/sNIpP7wtu2b4nLojSDoavkF1EkkjUcvYDZGoVhkPd4FYiXpQrnjPiz6 sMJQX5FdPgXkMorMT7iJ9DLA79UBCVOa3GRyBBUeNxq35aJZMntO/Tqd2P2x ewKNobK4cPzG+XHcS+piaLXQFKfhB+hF03cfrUH6MhzfKTeQKuAJly+ZbBcs FWIKDz9JlL7RYO5uuve0IhFbjLz8dKZjuv+sVmj3wKimjLtC3QAZg3x4O5+r 6K7yMGNnjPgMyRLW5zKOAvfpTCPM870Mo0TeBLNoi2xWt4x6byY0xEe1Yuca aGbH201G9N3gzglmRXjLeXUKdx4ysrGUVeRMUHmOIFSYlI4zhUbammmRlA6S RXjXx9PZlmJz4z26+zJRbgrMKWsS3+9GWFNRYwNIkk+aIGBomCnNQiGPFxf+ jRq04Y2WCPfQq7ENnwdjT33J0LijsBU1iRzXML4JFBzBT6aTW4hGnhzpGhH9 b2XFeMqbmhO2CgqehuOZ+U3VfqIAf9CJ1RxT/bqvztsSkWTJXRAFMq7OSZ4U rm6T0QT+qWgYESMIFfk9S61FQXD3meWQM5JAcyEJzEYjTc5Z+im6OF+1HJb0 fmIaDLszI0MFhBkJROtgRqxBCVIRGwFCwAj5lkaRIA2GSZVTEsLRn4KaJT7U SUu9WjUPwUjudDUyxNeqzU2plckwZT01JbNUo5hdGzJTcwSl8a6hMkUS/Gsj wbxO0Q2yMzRmp4Su2Ck3U1NGlOAk5VYs5ezmbsUQcqXgg9YRKvYZtWimBZDs ILwGneyieXjU/O3C2T9qNc8pg83WT5scKffvERbzsXvno1RgtsJnNJ0BMlEN BDIpl3c2Kmma+yZ9UnW/bDtFIc39mlHyLJ4iGX7UHUwfgPy48wN100F8WBiH aX+E7v4GgtyMNE5w61ZKHcr3YUrLB2UgeF8gBXH+9mgDOiVAz2gx7weDlwZr BCixZ2qfBhHo3eINlIHwVMUP8K/fDdApZJGsfBmwuPiB1OH8cdFFdFT4fuV6 xevpgAiPYgcFIn+Hp3LxA34skq5FWJDnd3ru2GW6qvjhCxThF+EEgjj8jp86 E7s60yW4Cn9SkaZEPFVCz4nISGJCSdQdGIfxcOz7F+sfmic69Bk6kz5on9No tf+WI7ugg7z6W+7wvNW6gJTtk/2jC3kcVOUhXdXcMVTW7ShS2YVxUhkUA0MA ffQ24BP+xqi1TJSzz2kEGLajDPIshRp5QiciW8C48QBD8Td+p0bV+MFSq2rm CENddZQG0sJ8BPcOYfyXw/6WO2hfXP62f/7xDF6eOM3a3kXkFtDqWEhqT2Iy C5wJLBhGlGs4bl/s5+UznFV5jR5fp31SqWte4+mv/+uCVYf3lC3CGarQfQB+ Ht51ffxA/kzhA8w+RuAsDKlj3PEh+XWGP6KhMZTOw2vFw19ExXrDLnxmQaLk 5i8O7LA+FY76O0M9Q0NrRiCShUFDmhCoaORdUSHFDG3iIU3/ELqOXdMD/bfc UfvXg9bFUfuyZS80CEXWQSRndGifVJLiAf3wtrn/DhlDNIHDZCq6ORsV8nPZ 0GdWZPh37FWYiNMCsUSEWUSx8MRysWZ3x/oSj6FpjgfqjSPWqg1x1yndkMnb 0cveCtGtC0NkmUCDTVCiqXrCY+0Mg3Ujw5CuJ62r1bfI4HFDnx7WCtzhU/82 FkinRyxMlj00MxKcaKpe07GmhsG6qWEIHSvc1g1S2a81NFZhmIgOOzvAjJsV ZuY+DDIztWY3gZTj7KAZ/ZDtmNoZExftkQkOZ2CbZgD9ddX4rOQTwhpU3ndm 5OUbEjSojvBsLbYho+1JxkqLkhFyNqfFmGWYiOKhT4aHQ5vSABnhREy4etJi zQQmYnhkUtrNCzhlhMyCTbbBSw3WuzV1tEMN15T4+Or5z3z93zVf5pqNbfQw WO/xMIRHmSWBJL3cqGr7Krnw9ckWfjf3gQkxA2hCEm2TKzTWNBOqW2YCdJEL uHZzzNJm57EdL6FWy+bORiP6YpmTd+7rZYPH0Kh0GjgJraPyyg366xqvqHT7 2o7i6jBwOX0XyjD1MAdB6noj577u9IDEE3iBUDOG2z/u3KN1HHKBhp07kf7B TCHDwfUIlzstm1ZGopyLNJtizqDDssau1/0H6QNpWQE9BxAiw8COkI3/YIqQ wPyygpUaBKRF/5ytWWzUgpPTg+Zlk0Xa86W26bCExBvMf9U6JprbqVaDO9Ym mdaqKih48sUwakYFb8TWRyGAFExFQ2skBDb4jeafOt3Bah5qZL4hhQT54mt4 t9GXEoft6kI1whiarLAefu8RxZ1NdOPculQaXUwpb8navMW1eYtrC0h9Uxds c2+hJck45txSLJpSqZyJZgSNF6p1fAl1/Hr6/uRA5ZVK2i4LYNq71vmJ86F5 Dk/K39JQJKDho+lkJ2t8HGdhUq6G8LxF6Yg2hRKRhvrfeyoIvwf43ZsTP6IE IysFhQSj2WlYXSNAALPIxoSpyhcEkywY5W3w05xnYjyMKVbyu/YiUy+LlZdw 9ZDbKoEG7F6T+W5J6QkiSeyd1pJWYk32vYOIwzgY8rZAoZHL8Mk9dr/t49gW 0DlzeethfcULP2mbPSmE8Rux42GfI1HYc+w026tZO/xy//TkxNiFS0ToihV5 e8Z0m4fcaGioH+869XtlRF3/ro4Hd98/DOEq0vbriKZ7Tex+vbAD3Xfi9aDQ +c65us29CO6Krztur3cFlyiFRleSxrvDGFHMeoOiUpQZ0tVwO+x5L8nX7UQM 5EvmBLhjVEGHLUL31ItZl8mu1bLpYH7buGhMArOQC2LtHfukGdNBwd6UDVBH KGqF9AXld0nu2h/ClfMYOchzX267nVseylVoCW0cYaLCUhYNaMTfJn4geRW4 8/0RChSjNTK71ZTkUvmryJgkOPYIlHTgErfsi9u7I3R72qY6BkW3sjz1htUn okfanS+iWsIRn+IqI+6/6cg3GTV4KsFV2mFw+spJn4gSnNsVZguj55Xj0wM2 WMlAUYNwKSFam8wSsQnKxHiqNrTtm0abJO8F6g18UDuwdXKkZJCP39nHR+2T d3xlFzPLOe374jPaY8oiIGP8wJ+weZswXg3tIK5kcKr8ScTH8l8/jAhCmIRJ eoDd2y9YkrZQWX++O/IwXcRpaG1nY2untp10RG6lny9sI+dolS3hftoCg4yj eV3OW0atguntTgp4H2h8aAijE+LG7Ypny2LCTCBpoiAeF7UzTK3//sF/ee+r f6Bp4s2QgBZu4f3Axgp44DDLmgv30PmzaqIEZDAYPsJa6D0WKG8aggUauqKU c2mn72GGJ/p9j2WcLd0nDtGW8ej7p6q8emWEQ+2D1sll+/IjGa7Piju4uIzH XbROLtqX7d8hegnnCBH34nQdkEsD/54wTcg2twQ9eLxCXweTW3Xa4ps2rDNu Yp8ag+1MxETEZOHGLIRSL0hBy8Pun5ZzirZtTTxF68fWf/Mg/veMw0HrqHXZ mj8UtS0SrdS2a4VK7T/ryZaXP2VF4fgR1Erl/+sVlTTr7iwSBUsy+7CsVHbq 1Z1aPU0SbCeXI7KKUuOdun011SviPcGYciVMg9jQmui5IMoui9kSaT5jdhGA zBLGROzAiPybkZgchcgIItntaLxk2gUadYg6C7QI3XFQ+rBP5Ctx4IIS37lE WG2QPXAVnXiH9sBGX+6rurhsXrac42b7xGlXCpGvVU4DgceHTvPoiGCHYRXi V8RibMNiOJfv6PL7I7s3Laiz3EUzj39+bx/g38sc6o2T7qw3RMn43WD4RT36 oT+aWJ5ldMmQa4TEoKAQdH2gwkktslZF5SMC0+RgTgGU2dSnhw75S8LHynAI KW9s3pJuzNwWy6jEnaAXSHThdAfnFWc4nbSrBEJn9BKtkT2v7CiILhZfq3Ox RW+wnszmxuJpOo9O03lkms4u3tnTdHBhf4tN0jvo4J/wF7q634rOF0SFE5Oe 7n/AHGErF01Gu4qTcW5PxozRfH9y0Dpsn8ix3SDh/VqjXjcvEjGksd6CSJlB o3zPgW6qVR9RYshwVK3m948vfnOQlZjr9Pm5YnsfHl5fQznoyns6CEZ+pwuj 4GURqC1DCTg+gA3tf0JmWYOO4IvL86PWCZnGJZNpUzrSOWlswI/K5uFtkZJd 6exjcnu8UbaKdIO0CpU2pe704Z3dD27oXfZaUS8hSRx8KD44eW1ozZBrpMi9 Bo00Htv5uUdA6CoH3cKc45Bz+JjXaYw5OyOeMy9xBwcuYwYVGafOYDIcpZVE SXnVvMjleFKSjE6YQZ3XYnFaea2hNzY6VpgwnYRho816FmWyPCYoRF4MxKDN y0Zj5ndQ449/Vw+tzG5gGukG+VjjGFOfDOqJ+Tst3ddLWIqBbgpTm4mx+srw 38Z+LDGljZ8/p41Elxv/z83qzD7+wLw2SlSMPbHLzqiNzZexDz28UAdZsWLe JCWR7W2jJSqzQa0Ysz9yNF9zpje3dJYK5+eweXTRMpgrCy8keU54Fsocg4LC K+J62iuQNh8aIhD7h3hBaJlx57JMUhlyBdnhTGsx5Nieqii2+oS76mqKFndk VIdooYeHBucZOcdoJJQd+x2/e48qlwNfXT1OfGM28/cs5vh7toAMYWIbuj00 aJD4gvLGw9EIWsaSh+g4rMXxTNnuZjp2yPZvT73oozCG1sZuNFLjloUJRJlY 6Wcxe7sqN8r6NShzZCDv82p0FSDKTz9H9cgAQSDQDBhwC6upG2h/pNY82qg5 i+YQh341h2KzRt2ZrOZf2CV3WRON7XuTw474Dl1SbZd0SIvAY7IcoOFwEHSv eo9AXVue5NAxFfcDFuPNYIhKjyV76GcNur7J7NY9dG5vjGG9cXpwevmxdSlv k40Gq99tVw2aR0a8MaL47wjeWMe5wShv3cdl7GwOZV45sYX+UwX9TvE1or9q F6h4wP0p2SOej5GwSwYfIGAgbvMn5lnAeVXGfO+5yqnBiGxKY17W0UAvNea0 qSIHFXL8Oh1/hFxaxPMV9p9NJ3LaKAbOLDO9lUDvQJpm9Cztd1x0wNkly6EJ UJOor5qlgywbcZWqcitBXk0H2mAJzR/Y3RYXmdU+Mco4q2tkz1bbDvfQrDbp BacO2D3sRVNXG9pfI/osNM9zUG05h9/OmucX7ZPfIL/n93ayhBEAe7AEO71A O7TnX0/I+h53Zl645stZ72ipNsFUiNPNf/Fe+rSFRsRfEb7Z+u+bgD3AKcMm j3ukBsxfcilbN3pSjDlQPHMU7PMrmhAIUkJrWdMu8awaQ/vUjD7xlm2L9C10 f7VUAxh+Qw5TGKPu4JO9mOHx9DmKwGHjbsQF1eYDodWEkmGGRdor76queqVq Ffi7tkY75CuvfPKSYkxakUTv5kPaBW1ocQnweirddz3sxr2czfiMAfo8kV+J hxXLDpfOn77f78DyC5OjzALSRxdf6EQMfuJFU9lGdvk1rGXG7nCcw/cn+5ft 0xPHwS/toxZ8yKrfYXLQjfcBkFc7aiXIFroFqzLyH9WNkKfr6zBU4aqAXpkv MNcTC8jFPoHW1/teCe1wIykss1z15x5ywrrKquqb7hZ9+BaKY7U/mR9aOiGi xMITJRylJ50oUP+yJ4rlWWs2BhxLahb1er91frmg2zZ3URRXF6IK6nQk+yJL kw2UfZXrO9XtNFRBk36uDKa+TehFRnwQsv4YRXwG/zCdC4kDE53EEO5xCWaj VmrM2oGizphdDuLomboaDnto7ex4Q6d9hkJtGPzL8/ctRjNHO+jgMZj4fbiP J1PypTfyxyiShObtnx6fvQlhx6sMcVoFYlL7LDlp5eaYguULM5NoG7CUJGT8 lV/gMSOWR3PFya9cShRCOCejiDDJF2xQF/TnA8+hceA76DHomw0/y56foAWa PVsps348wZNXZUgKtnV0QU1Q/Idy4QKpyQ0QwSzIL4NbDrWxDJGQeOE8j2OY i4clus5xngXlHCvERLmpo9XTxPTw2Zq2rw+jGJNIhzN7y+pAPMp0ByNiiMRq NexhDNFYVT4zILqFfGl1LpeAZw9Lgsym+ZmM/daNgX9b9OWScxAFcYbxPoQ3 RgB0P7UBTtqCEgCIgpCrePrC83IE+YnTmVdnh8671kdNLBLvXrWvw0RdMiZj HC+25de58VGHIaJyQoKxK58KIJ9bBCAAz9scSgzQHtcfjwdD4cNSanzsImLv g9tH+Xe+JA+RLZaSbJQ3hPv5zHIOQneee1tyJ/DwL1kuZ4f0FCZtyIv3R026 nI9PD1rO5fuTk9bRM42ULkVAP55exkI69XvLR8gLU4f1kgvLY//tT25y+OTL dIFOGIubYilUoAeH04lDnopZf0KgoLc2jOyVTde16T3q04w7xBUjpa03KoFu o3Y4rBuEYXhUegS+Es1np9H57LKW8B8Tngf6uQAN1FwFrVoWaybFxppJYQbI wgu9mcTKiKTfSSl318IfWbPlMGdtZH+5yH4hDbxR92Y8nI6I2zOGZ5w3pO0K ax2IOtyU4xDWGVFF8OjiWapt4OzANDW2C9WymaYnHWqaD4NnozllINnl6aXz 6/vDz7uLDvllaeRsOCGoV1h/UGqlvOGFQyyhGFjIMmmaXXlYp39ZwevXRRSs T55Bqgo/cWoE2M2nAtikxDCKTWrUNbqaVPmYyToDD/hwFY1U8y2pTsKcITBI FOU3PLDQZs4fTOwNyRp0oy6Ck9/KzjR7I8yJ4DIYuaPix5+4F5fH8CoUgqMA d1HfncwuS+Lt4gilhsMJTWMWejBZF4fGxdBzEktFHE8qcSArmnfCi4o3HROJ Fe024iKUgTIr1yqFmsWDhdMvecuG31+kLW24zVAlHg0iP2u+S0GlRaOaZfE1 g0YgI3U1zT1DWAS6bg9Hl5xjwaMkbJOrmp6n0FfmRTM769I2t/x3ZFXGCxY5 MkUI9t3F6obMvaLzhBh07MSRsK14lQ/dUHrCzH7hVmAi5JUZqkyO/9ws1YyC ehEWat7bpqchfEq0uyZler9V6IXL7jf2DddgEO8bin1ZffZqOLmVNCjURXa3 6f0MBK8ZOFymBXMQvGZmlczMVVnusGSIdlKqoOZnQ91h7RtG5czZicCW+nRl zumfSj0P4/800fnQ6oFmN0pwpzxIrKPW0KdZi9r1llm56fO3VBPg4WOd7KlN CH6kCctNh6wzmhRYZlnjbsa8q2byFwi69Jrococb3Q9urOcB7I5ZzSc0TpRc a2uf5z9UkJyp1gAoIgqBNIdUuRcwynzIwaWCBya6/UVSpes5xOrQutJstVyt VOr/oc5/InUu4kHkvyi3hw4aikXUE794e/r+6AAlNeotdEZdnvLfpjpoHx62 ztHpJFCVcURtbY+4yFWpldRmRVVrOxvlncp2mqqbnWW+JnZjS/xw2+8IVpa5 OHUO2hf7zfODQobcJgSEgjsd8BL3PUEpHF79w++Eik8JTRvMfO5Pxu4g6Hcn Ii6LJYe1jMpHzf0WJb9okg8UeKKiG04GJiTOViRH64+z9nlL0vsPoy6DkITJ 11KSF+alX7Q6UxERWcWRhIIok+VBGfvXCMAAVxyVG1FOj4Enwmwo7RAaqM0h YvJpxzdY6DuxtxGK9s5lgxlsM4ypN+wDOYCqrSRVQm15NENAO4NPNkJjpbSx an3P62dY3A9SCN2jJxJV+eDc3YcpRS3O5sdMptYoU5sr6hYF4MKsqm1sokpU rVHTMIym37aszsKAqhD5Y/myiboEsMWHVq4q5hKZ16z0v7dNjkoN04cc7fkT razZissedXllodqKB7NulVllaHSmSq2iy4CgmVdTajHobcc0pSaOg67RsMEW OmpRJ8kNFhVTX1SKhQ7VeoAXxODG53hiJp0f7lfr5S2VbePSQ0zNC78zJZzE ZhAMO12eW+QyvfMf4TQauDe8s8/QkqUz7CmRFeezolxH/KVGHVbSZmQlpR39 Jxdnrf32Ybt1oGhmkGnV828QpKjIzr5oSwyI92wvmJmHvoYom5sSzzdycKxU dRHGG/FaYd8XW+bi8b3iJfsv1z+NSr1eUzm8Y/bfNk9+Ex3LZDY8SolsNNnq yWxE+46KXX9yXcRn7KQ4QbfDxXKlNHmgGaJJqZcq5DVnbd4Im8vVNHNxejM8 1D4b7JWWURMel6rZu0E4zdu+wmu5ezWVHT3X/h7tyS3hzcZSBviUaZEF/sbc zLZTii2EGyxvhxfpJpnWbBoHILbEhgsho62n6IJbhvYxT4CYN+kg5FnoTBbo O/YGagX5ZERdFg7iJjNwUZ94ezvi9bSyCxQ8TNBwOkFbtuEYdctR8elmOGRH FCRXWGrFk5YDYdai6SUy1DRLGi82OEY8xEPrXovlBqn+onMfjC761pq3FG0w ntK4HlltYWk2Xhja7gu8PZDRxgxSBdMrlkOVTAmh7Uhwd+V0AwceoD1Y0+44 l1domvqSGOaqD+ddT1B5MSlCa4v3GbT4w75xs7UkXldJRtMwAwhZW+IUp5en b3+pcP9Zb59T5d7ksSq+xOEVMUY03rF7Q8ckG8OaOnJ9SKb9F3RH6M1HfXED tbHZwGd0MCzgV9QHmLzJ29WWKkq12+f7bN42GvWIP3Z8/p7O/dFI9QhA2Haz isoD5TIVqKtHRqrqVbGqXk31x9M3at9FagTOdPJNjT3A0sbXHUVupxVqx+8W 8+K4iTzminUqmql3B2R+K2zROwc15FZxoLVERyhvnpvuv8T4ml2EIWmKR114 0nWK4fLRx51QO9WSOmP68xDBkSeBgcSu4tjgURtZdvhWe8vTxBlM+nIapmVK WDUlrGbKqEB8TdWBnG+oTbWltp8SJqWsFX/wPynnT928C6DpOr46MzeMsuMP yIkJ3+iRJH/+Ve2BnyNWO1Ep7aGffcE2icT/he2xf06Gg2L7XQsfWXeoBDrr 5//T9uAWkpPuExCKCijFxud57fm3+rGffy8Yn2V/fuL4SEmXcC7CEaOHg647 fKd7+K6mwdlsbH2W6AIjY0rWYmRXkl/5+D7EVyFdUC6c7a64ub16RPco+vgT d2glU6jZN9CWf/njYcm0NbaKIH6LNJEDJAowKVxA3RtyoEh2lVhz2+jPSiH7 rEaLyNEDaodonGA0n+BysgfuAF8LfBlHYjiIrpyQRhAweQJaCGkFugMH/s0Q GyG85lCpm3SuPN/m+5BvSW+KZny5iSaqcx0Yj+f5dRa85uXConKaIcVB/nWI pGNxOdMeBHPN1cLtVXw9uC11R7fF1yP9zNkDYunsHC5jZN3t6vtLy2qwT823 QBchAwBe8si4vtf6ogzKz93QbYpUMhlqB9eM5iKa+mlp8jD1lYZ40eABegMt U9h1oavesAJAd8KmtOjKgKYCPQ+g4f0be2COEQ+YVoBZ3FA8LxfLhVk4G303 JKimA1qpI3c8MeAJSGMJVsgQCBIPH5zj4TSIlkLqt6Pi6+5tj4D8h/0RviBE R1ETCUCU4DDmzGiN3S8oWm2ogh1UiI4mlvnqVdV4zYhk3oPcuyY0GijBzmja 6+WoI5VGXoOAo6s07ZuqgLxDsjUwFCO+NKTVjKhzha5h7m0dVcZ30eFR4A4L DR4TCkFvSsbWiE5KSJ3TfjIgFgRtQYw3ngd9OFl2JDYOC5DJGlOFmk2mbbOA WXIxtKsCPU5oNWoijwhHps9wE7g9RnuhzeAP/jn1p2QTgVBDkYWgkWWIEodG QwUXx2dwqlwDqag3ZJK8VOxFhn2T0GfHQfStVVie3c6uHkXXIyiSVAwZs4Wx 0/AYCjHNUA5LD4U2TjIe5SX1EYPaAgnTg9c4jP2VP4FHBE0sUtf+Aww/H+sF tG4sqcfhoKRykG0CDwUkpmFP4klngHlMXmwbOh8+z68TjwY/f8izg25pdvAm L8kvGNGJGk7dC+7y2mIeBSkT6MgbrIu3oLQW/0C1HVgXXQ/xFbm08ChYFjkL 1uPOTDw4Ui/IismFb53wSEzIAtE2MgKyFWkEXSl6k+BK+ge7HodlhPvoJZ+p VD0tKmyNAxnMSF6xNxNCHEE71OmYxJXe8MsgsllhYhCoCpYSvsh4aVOJpiQB zkJoowjADzoQGTzSE6ug3BGcfvDQQzgRHATtO5U4EVho6VZPG5uA9324rbCF UrzAECWzyR2pfdm54WKJ4RDRistFEG3wdKD3MAJEcTlkvCVO3oduzxQG5zYN sS5Nn+3QrmnPFxAvNYYrFWNEU1a3pc2LjbozGRJIkgbTITcrOIlyBbLsDJ3G 9Ol0mgRE9vSGwUSvRBUuRQ+92+ElkcUZ2uNj2ffvnInb7eUU7WdZRrwO4LTP Rk8WTI4DYW4g1rHzhp0AjpfHkqLtPRADcNQvETqFekBpzSDJWxg3Gzf7ysfR uEVtOxygAbvyEY/X6CuJ0kP86HqKvEvoMKpS6uI8nxqtx1r2hXbhA/1mszvS rpwiQqZkPaZicVxwQKQUGhO2cCNii+vG82Bg1JxKxEZQ3Zee6RTbtMA8B+by tv3uwvxdMY5OgdiyaCkzHvb4UDNHB91oMj8wH/cOZrgZu/0c3hJluEEL6gUa CWt6JZGQrjGziVgNkjpgFjMOizVgkUs2ilun/Y7/pGMMsSXNESGrjc8IBqtS K7i9jGtQCqJohA8smF7rdq2vCwWw5HrmXCRSZn9Q0Hy0GBw/7kaMHg8Rfb8z HJP2KHkku2gSaBzrTJVseZGVDcGQvtw+0nL+YthXOC2GvQeLCa/lN6YEfl61 A94fuN8H0m/J8sauDD9+4z8kYheSawo0mthWMrm7nQ+dUb14QYaVGLmay8Gl vrWKrnUqa2FuMij5avryzlhSanM+Os8Q0QovAN1rIgYYVW4GpNzPXjvGoJOJ Yu3by1h+lsz9B0c6eb2HdJrSsybKajkRI2+sPhlDRRlnIn9gfakc0UM8dsoe vF3DewvfaEJ2X/nXeIbDG0DuOrKipRJlftDzmIGT1J614NAZIFDnLU7qGjw2 c3CO5PkTPjdZQURpE0+a+leqBo8Y+oxsT2wdfH5jeTmLEWV0niDFuWudPT+f cMHduTJCR7239HfKf3gQVkYqh7CNO/grr3CTM0s5fH0UwpFmVUnKWRC6FP7m uKi1Sl5p2odtwXhwsDfW489sFrSqVa/xnaLnXopcWyOTWMuB4qqsAXJraxZS yJrWzADc9+VC+JQYzGPdJ5wirq8+CW11mQ1DAJpATvRiWwYoB3urhAeZtCI8 Ue0Lccahamde15iby99geq6WP1FUkluOOxybTqB7+tVsNUxef6FXRvgQuwF2 zPtmQQOwW9agJMeEViyn/XnbiEQ5Mo0M+sIODZHA0F0I5zR1s5u9nvpEI2kU 0sro14cJ5g4RewxKEAMdzeVj3IfkYWodpbionq3RtYbK+0sPtVUElvlNJG2L 1NjW5D98zRoZIXOa3jZPDo5a5w7a6B210Frv+JnNFIi8i/FhfsVKv7XqNkOz N7Q6h16JKEjMGfTRW2+sVvPW8bUbprxlhhRk0RwVVTXWToYnMseXtzKaaync EFLYtJkh8FQd0Xjid4Pf2xm7/3oUvF5OaPKkmOevzYLRhMEqKK1sPGNFK9Ff qJNaFZpn1Moar/Qb/SZKDJL2fPeeETEWWleTOPaDvEZxo180kbC+EQRS6Ed4 ADP06HCAzjy/+Gwvu6rICg/ti4JACiDOBEkBaYkG2jiInlIwub47Jgxbyo1D ijw8YubB9YbvruLrLJv6ir5uGtT5xLsaaa1OUoGNzaAVhUlDQFrt6FzsycMZ jiYTjdt1+JU+XRSfciCF1sOz5zFMorE+oMriazyLYPBXgijmsm4j6h33fdEF Ho3vIzsFSofG3MNuyYXpMcRYpucgS95Yd/MDNywB4V8Y+97hKKDMXmCW4uv+ I4VIQd80xq/fiS54Uw+njtYEZ/qDIxBxa2thSTYUMGpmB49BZ9KTg1sMGJzR sNftPDpECuYZhAnT0s4PyG7o+SzE+BzPKkL+CkJ9EjReF8kwwfoMjaEEV8ob DO9f3aoVqg298XiOuiMqfPIwKVihyMd3ROBiBUNaVVRV+B+NIOQWmb9HM/M2 gW3bnr4RrNjUvaAx1TNzNsSuTrC+nroflAAVzNgRmUVHm5XG2hPoigGe/omN kZmzNyjuadsjk4ntEA0B/X2bhHJ/M+WmbxVdp7Vb7FqTG8YuNbJt8PQPL/Hn Ee0dZGoxcGRSs6f5NsV2nd0kLWnALolTUDI3Zlux25miysMboc5TtUwAsPhn 09AHX9nFXi7b6wIZTuw+vDRQ+CcWrAFjCYTxYi4+26RpdQdIPhSQkSUTgXJ0 r124zXJc0hDIKuPvzIGZBCKK4/hqt0dQe9pboHQtyUjpCxWuK1sIFlqpGqWv qMK1Tj5/vBh/Gf9sh8aAsFwNngT7Yhd1fY80XB3STqYI0sJmtVdyby2e4xl7 anklZik3dP4+o1zyRm/YIolajDKfPKEOyIhM87RNKTB+xl24MDwtV+Il42r7 ZDjxdwQWh5n1yFf1NTuBBYWIoC4wHBNy64fNMd7P0INno6o18OgYx8cRNCmX akanF0g8FVoehEZ481JFC1sCJCdSCGJYsllTaTQxT8NkErZf0mls6wZKK4vm m2Ao1BvsMW2zrjGiOO1A2j1073r+Y2hgzN+XMiMdpFlk7am00N3UHGKJFc8i wfE8Q9dKOXSJnteSPu0+wsZzema/ewfoA8YMysYGDcrGZtkAZ7FdLF1hvYkb jgetqeJr/97BJY/skgEe4G9UDlPnc+nJimpAQFI7qijpBhCWmnYhKWFaRlvU ibWPAs0b6I0qq53QHYyVJNqFECco3pFYYuqITpvam2iGvFLWoswYW2WUIH5C NypO++TCmCpzvIX2MBhV0HUoYrV88dFKJ3Dv+mhEjT2UCgN/3HV7gyFPQ3ZX cVo5V7Lo+EGAAnF+cZq3tgoVbflEVV73GYXH6ZJhTMfPdQrUxPzChZ/RLMfI +D+PoUYRKosjhmr7p8fHrZNLJAMKKvvLSm+6o/6eBcoIoR3hH+KB7eKH7kCt oO4Il6m/rQT4X5azx8eAAjtMSnEXOMgfTPsOBuZe0AFJn4MwP4bldZEYj6K2 x092NCoZWcC35c+JkukS4OUcK99a4o8jPx9CgikVAmb0UAxkLWouH5YA/qpC TUPLXZI40LYXVuogqyUHWY+qShtVerRXNtnoYEuuZ1kVREprOL0fsZ8jq8+/ zHru+0tPs52zS/t+yzkLWA8eXw5bMSbQIwrpWBdk4dg+a5/BophnD4Dy0nnE 8LxcKRYBMap4bu75tnV1BumoG581dOQFLqE3NM2RSKFX02sn+HTx/teT1mVq pJeIXAqRz+Qnq+6UMvR8o+oawkgS/CYbnibfkDxB6oWCR+7lCUSd7h9eFGxu Ya1WLVTrFssrfPRE3jUM/aStnOY/rOnwdZ1R1Psb2kxHAxG5hK335aEW+phL y4/v8JQC9DOO+FrwQ/Io9LrGWL6M3qrWUIxUQDvwO58yB3u5FW9nxcvHHr8p NRdS6pVqv+kOhylCm3zzAEU6aNQgiapUxN00nvM4XPcAS4DsuRncl9SqLA6M 7k+5EC4kgw9sQjRk3qLxosR7iLsXZjV9X8zmhnS0subXIl4bKeVoiNyBK/+m O+D4WaeJcadD4Fzjpxwpiawp58rm/HMlWcR8GLnyNvtF3i5UNKOLGMyBS9z5 KNzH6mr+BRqij+GGHsPx6uNfx++7wV0p8IEqGskaVAafef6mJCDuWSATO8Ky Tp4f1MmCJaQKf4QnRRzVCAcqRKbwg8AR5RjNoM1eE+YP2t2eNlXudNy9ISyY JifPR0V+8LNwfCbeVWIzhEQJKrzMSOWQ8u+eImYnH6Jr1mjqc9YGvJ41QKFX 0qUGgtZDlXgxdTh+9WVjpiiGirczMxLO8z8+RqMTmHrVnR9cGhFW8vPcKk/I XR/tmTo5M3oF9dshmlmfIyWR1+zfi9bJQev8PNc6OT1uHedFfsKOhIn1W0d/ 4ZWIQRsJOHaN2dp8ozWypHNOTh2khNv7JE5bs6AsZNhzCQwnTgMfDWidCRm7 iPpLImHyZDtms6aMKJ4Ox2yXt5aZ2pB5GGDX8sBIIathYyymZyRF3tSMZcC/ metsbeYyszu7o/2YMjDLc+wCAis8N3tBbqZ59SxVkQoB77NUC4yNqQTf/oxy dw0j2dONCtdE+wQN2wX4A37LGIX1kCRCj5OjBxnHmRCQcrNSCgwg9zK+vjUO C5966/PGwDrjnjwcKOowpAs5HxwqteKRkhitFx6M2PFkcuyZNWWOpPSe0AHx 39MTJLekJ8t1hKHpkh0xZ+pf2u7pALVbbwZdVJBGsRGuib0Vj1u9J10w6Rcs JruvM1fwj25cFUxJ6Hs97ZmbEE6cnnu1EzoHKGuTgKWUDFTaCalCoKyfdECq r4KhV2F/e1tblUJ109JC+N4fa13hQux6yMvwSnjjiPxPU+4zUmIrEVN2ycoE +8dBs4rHvNpRlaVg8EV14UOXXLnCyUeLXWOBkm7vG0OVCF6UQG7POAJozbyR QUfLCI2DKjdQAiD1Rbz1n1JOvc/6dSCjlgZQFU0xo3n5EER95rDN76PHrLCf 3Ec4Dxf1kRCwFncSKewf6WSc1Fyus5peXKK/EUrN6nRmJppcmAQeh+ursR0T +qot6KdoWtKUvkXSz6bLlxhNTW2y7ZUym+uw/cdxa4eNKb6QBze00ScPbtqx Q5s9waLaukY8Iqp1UjKAN/Ut8p5X29iM4LCGx3+MWi/8cHwxwxEPjtwHHBG+ cFKjC4uYRanLPrphwqJSkuNJsFzy6CJLLFOrwUaqw7BEcRe7i5wXS6LMxXTA L/GyqqJryJ369gxXuovAsqpVxlWDP5W65ZUMyfZa1YkYyzPPtDAvyb0/vhoG Pksg5k9Q/BXCmzl2xa6uZsI7VigE/aKgXURkRyJCkyHheFs3OjpyS1YGoaYy +Fywvd7pxmQs5M/PhYgIXoyAF+ov6HQkhKcprKjyxk6lvoNzmVRdMOnnSuHR ec4WPhSrhfqG+J9Wz3+QqnhOpfy4pTjd5UUeSwcRxpUIxO4JvgqIEA7dU19V VuTqIbLVmfhqKGCuG4cNkw2rTuvZcIE3/sAfdzt53F0a4p0ymGrvpYBP5LhF NLfVNVCwg2m/oLbWf21fAnHaOnd+/XjZKqgs20Rb6FHQkBfyncVF6GQxLKd/ 9a+UYviJR8K1SGriCVQaiVpZrz2blgUGhpSv7SKB1qUO/4QRvp8/wvddj0cX CWouiDHDpBCCU+m5jwi0Q5rICRgTuOU0aFOZUEwCAW2qlaqU+1K0Pq+HAgZz 9ahcde+Ou6TfLBYZqDXB6DNnY/++i2bU9lTtJIDOLCybH0A4Wf0ZACerPwWe Ajf4CXZZhl7Rhte+h2kDm6brJFHIkec/tS0/ethgKf/+HlyMn1X5TxmI9dR9 SCoviS0Y2TlPPuBUfBOeNn/CLnwoPTxhFwqF85SNiK60/7MT/8KdSBAxcKxf opc2DRljNcaGkLHbaEPEYFuiP0/+HraFLSPP7uvoX2vYmfiodopXz9l9Q68g las0TFyyLX/lxhy66Tsz3E5Ppz3WVz9+/MiI/KSHyF5VoM+oNuq7ndsISYEU Eqv6VFija2PDVvh7odtqYYpSkwskkapUYlCkORt8NG9AaXUxoippFVCNoZLm GIc0mTVKTkjuWgKjNGdoi/xSypuf4nc1Emdht/XZWUhPzS8uO7nMaCEOAotI HqwVs4navWublRpQzXqYyZnHFjxnVjtT9r0bFF/Dx10bapoCCVS0iB7T1CuV G03GUMe1M8kH6CcP1gby1IuZ6Q3iFdJDw+u6N7ksPrr9AcJdICxpnzAX0OzN NnJHGbLCcoxW+XcWk1vx1ldG9A/F96ZMeivphhaU6U9BkWezWP+MujFpLpG8 KhwmSrZHw7CmdJG7wovouwhxohhWVW4PuTTYFQ87cDCFwVU1In1A2qIwpqz8 tllt4MNms7ElM5XJJEdkhfCbVui+ClDmpk1v+91Btz/tZ43ssaDQuS6rmVmj LA9a6SXOs/Hw1kUU91ca0aW4qPqeO77RtaN90nV3krU8LafWvvYdhdL0wsQa znxa2ZajOuyGGA5GO8siSJlKveS1ToFOGnnpkr7cPEZFJFnKO7eW9s7Vyec+ c2vlQk2tkVdeXAv4Gh8PaFuLlb1jKfORT3rsryQj7VMyjUmNplJi6un8+ic1 wlVWZ1ngeYxwe/qjHgMBy5XA7pZp9lD5mwpfl1LhdEypX6uxp9TPB9oiKFmc nQrPTjUyO5U5aLDRwd9ANNh6hCdRXTpzgs20wWaXxkOgdDpEcoUydmcqVpF4 hk4MK99Ci63dRRwoe+SXA3hieKcoZylssyOifcdR+u5/9n8AggWswwVXAQA= --380376598-1361968761-1017681902=:4641-- From owner-netdev@oss.sgi.com Mon Apr 1 14:05:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g31M5Cj01026 for netdev-outgoing; Mon, 1 Apr 2002 14:05:12 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g31M52o00986 for ; Mon, 1 Apr 2002 14:05:03 -0800 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07306 for ; Mon, 1 Apr 2002 12:35:58 -0800 (PST) mail_from (david-b@pacbell.net) Received: from krypton ([206.170.6.194]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GTW00NG7P4Q15@mta6.snfc21.pbi.net> for netdev@oss.sgi.com; Mon, 01 Apr 2002 12:34:03 -0800 (PST) Date: Mon, 01 Apr 2002 12:31:43 -0800 From: David Brownell Subject: Re: Patch: Device operative state notification against 2.5.7 To: jamal , Stefan Rompf Cc: netdev@oss.sgi.com Message-id: <080d01c1d9bc$3d4510a0$6800000a@brownell.org> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-netdev@oss.sgi.com Precedence: bulk Two comments on this stuff: (A) I skimmed the 3.1.13 descriptions in RFC 2863. If RUNNING is to correspond to ifAdminStatus, and NO_CARRIER is inverted up/down ifOperStatus, this starts to make sense. For example, it defines the set/set state in Jamal's table as a fault condition. That doesn't quite seem like a complete match though, and not only because one can't map N-ary ifOperStatus (up, down, unknown, testing, dormant, notPresent, and maybe more) to single bits like NO_CARRIER. (B) In Jamal's table I'm thinking about how IP-over-USB stacks would work. Those tend to be point-to-point links with Ethernet framing (easier to bridge :). The devices themselves are all hotplugged, so their interface names won't exist unless there's hardware (maybe it's in the process of being unplugged). But that means there are three meaningful modes: - Only "my" end connected ... nobody on the other end (treated as NO_CARRIER) so IFF_RUNNING can't _ever_ usefully be set - Both ends connected (!NO_CARRIER) so IFF_RUNNING could be set or not. - "Indeterminate" ... some cables might not be able to report whether someone's on the other end. Driver would necessarily treat as if both ends were always connected. So eventually some linkwatch patch could be solving a problem there: no network hotplug events appear for "carrier on" and "carrier off", which are the only events that really matter here (not "register device" and "unregister device") for ifup/ifdown/... calls. - Dave > NO_CARRIER | IFF_RUNNING | meaning > -----------|-------------|------------------------------------ > !set | !set | There is carrier, but no cable > | | no sense for ethernet; but may be useful > | | for PPP (for example line protocol is not up) > -----------|-------------|---------------------------------------- > !set | set | operational up > | | > | | > -----------|-------------|-------------------------------------- > set | !set | operational down > | | > | | > -----------|-------------|-------------------------------------- > set | set | carrier off, cable on; not sure what this > | | means (may make sense for host scope) > | | > -----------|-------------|-------------------------------------- From owner-netdev@oss.sgi.com Mon Apr 1 17:26:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g321Q0B06890 for netdev-outgoing; Mon, 1 Apr 2002 17:26:00 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.6/8.11.3) with ESMTP id g321Pwo06887 for ; Mon, 1 Apr 2002 17:25:58 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g321Pwq19732 for netdev@oss.sgi.com; Mon, 1 Apr 2002 17:25:58 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31D3fv30302 for ; Mon, 1 Apr 2002 05:03:43 -0800 Message-Id: <200204011303.g31D3fv30302@oss.sgi.com> Received: from arpabox([211.80.41.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm153ca885ce; Mon, 01 Apr 2002 21:03:46 +0800 Date: Mon, 1 Apr 2002 21:5:46 +0800 From: Laudney Ren To: netdev Subject: T/TCP for Linux Website Major Update Completed X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g31D3lv30304 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, everyone: "T/TCP for Linux" has seen major updates during the last one month: 1) A new mirror site opened at http://ttcplinux.tripod.com The project home is still at http://ttcplinux.sourceforge.net 2) "Tools" a) Sock Sock is a network program written by W. Richard Stevens. It can be used both as a client and as a server and can send both TCP and UDP packets. b) TCPdump Tcpdump is originally written by Van Jacobson, Craig Leres and Steven McCanne, all of whom come from Lawrence Berkeley Laboratory. Tcpdump sets the network interfaces in "promiscuous" mode to sniff every packet received by the interfaces. Tcpdump-3.3 is able to print out CC, CC_NEW and CC_ECHO options introduced by T/TCP. c) SSH_tunnel SSH_tunnel is a perl script. If you are using ssh behind a firewall or a proxy, you can use this script to direct your ssh traffic through the proxy. 3) "Join us" If you are interested, you can join as an end-user, andience or developer. You will see how to do so on this page. 4) "Documents" This is the part that has seen most drastic updates. There have been about 20 flowgraphs to outline TCP/IP stack in an easy manner or describe methods call sequence in details. You can browse the docs online or download a zipped version at http://prdownloads.sourceforge.net/ttcplinux/Docs_2_4_2.zip. All the documents are divided into six parts: Part one: Linux Kernel TCP/IP Stack Analyses You will see everything, from mostly involved structures to all the methods called during the sending and receiving process and state transition graph, that are both important and foundamental. Anyone that is interested in the understanding of TCP/IP stack of Linux kernel can find useful information here. Part two: Introduction to T/TCP defined in RFC 1644 Here you see detailed introductions to T/TCP, eg. what modifications does T/TCP bring to standard TCP? Part three: Design and Implementation Approach This part is the longest one. It's about implementation approaches. Lies here the answer to "How T/TCP add new functions to TCP with being able to fall back to TCP automatically or manually?" Part four: Known Problems with T/TCP defined in RFC 1644 T/TCP has been around for some time. But it's been rejected for its serious security problems. A detailed breakdown of those problems and "crack methods" are described here. Maybe the biggest mission of "T/TCP for Linux" is to handle the security problems and come up with a new RFC. Of course, with the necessary involvement of each of you around. Part five: Current Patches Performance Testing Information Part six: Current Patches Debugging and Fixing Information These two parts are not started since the debugging process have yet started.Information will be updated lively on these two parts. 5) "Contact" If you have any comment or question, contact us. Email addresses can be found on the contact page. Or, simply post to our mailing lists and forum. We'll try the best to give instant replies. From owner-netdev@oss.sgi.com Mon Apr 1 17:26:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g321QJt06925 for netdev-outgoing; Mon, 1 Apr 2002 17:26:19 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.6/8.11.3) with ESMTP id g321QIo06918 for ; Mon, 1 Apr 2002 17:26:18 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g321QH319744 for netdev@oss.sgi.com; Mon, 1 Apr 2002 17:26:17 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31D42v30307 for ; Mon, 1 Apr 2002 05:04:03 -0800 Message-Id: <200204011304.g31D42v30307@oss.sgi.com> Received: from arpabox([211.80.41.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm163ca885e3; Mon, 01 Apr 2002 21:04:07 +0800 Date: Mon, 1 Apr 2002 21:6:8 +0800 From: Laudney Ren To: netdev Subject: T/TCP for Linux Website Major Update Completed X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g31D46v30308 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, everyone: "T/TCP for Linux" has seen major updates during the last one month: 1) A new mirror site opened at http://ttcplinux.tripod.com The project home is still at http://ttcplinux.sourceforge.net 2) "Tools" a) Sock Sock is a network program written by W. Richard Stevens. It can be used both as a client and as a server and can send both TCP and UDP packets. b) TCPdump Tcpdump is originally written by Van Jacobson, Craig Leres and Steven McCanne, all of whom come from Lawrence Berkeley Laboratory. Tcpdump sets the network interfaces in "promiscuous" mode to sniff every packet received by the interfaces. Tcpdump-3.3 is able to print out CC, CC_NEW and CC_ECHO options introduced by T/TCP. c) SSH_tunnel SSH_tunnel is a perl script. If you are using ssh behind a firewall or a proxy, you can use this script to direct your ssh traffic through the proxy. 3) "Join us" If you are interested, you can join as an end-user, andience or developer. You will see how to do so on this page. 4) "Documents" This is the part that has seen most drastic updates. There have been about 20 flowgraphs to outline TCP/IP stack in an easy manner or describe methods call sequence in details. You can browse the docs online or download a zipped version at http://prdownloads.sourceforge.net/ttcplinux/Docs_2_4_2.zip. All the documents are divided into six parts: Part one: Linux Kernel TCP/IP Stack Analyses You will see everything, from mostly involved structures to all the methods called during the sending and receiving process and state transition graph, that are both important and foundamental. Anyone that is interested in the understanding of TCP/IP stack of Linux kernel can find useful information here. Part two: Introduction to T/TCP defined in RFC 1644 Here you see detailed introductions to T/TCP, eg. what modifications does T/TCP bring to standard TCP? Part three: Design and Implementation Approach This part is the longest one. It's about implementation approaches. Lies here the answer to "How T/TCP add new functions to TCP with being able to fall back to TCP automatically or manually?" Part four: Known Problems with T/TCP defined in RFC 1644 T/TCP has been around for some time. But it's been rejected for its serious security problems. A detailed breakdown of those problems and "crack methods" are described here. Maybe the biggest mission of "T/TCP for Linux" is to handle the security problems and come up with a new RFC. Of course, with the necessary involvement of each of you around. Part five: Current Patches Performance Testing Information Part six: Current Patches Debugging and Fixing Information These two parts are not started since the debugging process have yet started.Information will be updated lively on these two parts. 5) "Contact" If you have any comment or question, contact us. Email addresses can be found on the contact page. Or, simply post to our mailing lists and forum. We'll try the best to give instant replies. From owner-netdev@oss.sgi.com Mon Apr 1 17:26:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g321QT306970 for netdev-outgoing; Mon, 1 Apr 2002 17:26:29 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.6/8.11.3) with ESMTP id g321QSo06967 for ; Mon, 1 Apr 2002 17:26:28 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g321QS119748 for netdev@oss.sgi.com; Mon, 1 Apr 2002 17:26:28 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31DqNv31317 for ; Mon, 1 Apr 2002 05:52:26 -0800 Message-Id: <200204011352.g31DqNv31317@oss.sgi.com> Received: from arpabox([211.80.41.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jmc3ca89137; Mon, 01 Apr 2002 21:52:27 +0800 Date: Mon, 1 Apr 2002 21:54:28 +0800 From: Laudney Ren To: netdev Subject: T/TCP for Linux Website Major Update Completed X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g31DqUv31322 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, everyone: "T/TCP for Linux" has seen major updates during the last one month: 1) A new mirror site opened at http://ttcplinux.tripod.com The project home is still at http://ttcplinux.sourceforge.net 2) "Tools" a) Sock Sock is a network program written by W. Richard Stevens. It can be used both as a client and as a server and can send both TCP and UDP packets. b) TCPdump Tcpdump is originally written by Van Jacobson, Craig Leres and Steven McCanne, all of whom come from Lawrence Berkeley Laboratory. Tcpdump sets the network interfaces in "promiscuous" mode to sniff every packet received by the interfaces. Tcpdump-3.3 is able to print out CC, CC_NEW and CC_ECHO options introduced by T/TCP. c) SSH_tunnel SSH_tunnel is a perl script. If you are using ssh behind a firewall or a proxy, you can use this script to direct your ssh traffic through the proxy. 3) "Join us" If you are interested, you can join as an end-user, andience or developer. You will see how to do so on this page. 4) "Documents" This is the part that has seen most drastic updates. There have been about 20 flowgraphs to outline TCP/IP stack in an easy manner or describe methods call sequence in details. You can browse the docs online or download a zipped version at http://prdownloads.sourceforge.net/ttcplinux/Docs_2_4_2.zip. All the documents are divided into six parts: Part one: Linux Kernel TCP/IP Stack Analyses You will see everything, from mostly involved structures to all the methods called during the sending and receiving process and state transition graph, that are both important and foundamental. Anyone that is interested in the understanding of TCP/IP stack of Linux kernel can find useful information here. Part two: Introduction to T/TCP defined in RFC 1644 Here you see detailed introductions to T/TCP, eg. what modifications does T/TCP bring to standard TCP? Part three: Design and Implementation Approach This part is the longest one. It's about implementation approaches. Lies here the answer to "How T/TCP add new functions to TCP with being able to fall back to TCP automatically or manually?" Part four: Known Problems with T/TCP defined in RFC 1644 T/TCP has been around for some time. But it's been rejected for its serious security problems. A detailed breakdown of those problems and "crack methods" are described here. Maybe the biggest mission of "T/TCP for Linux" is to handle the security problems and come up with a new RFC. Of course, with the necessary involvement of each of you around. Part five: Current Patches Performance Testing Information Part six: Current Patches Debugging and Fixing Information These two parts are not started since the debugging process have yet started.Information will be updated lively on these two parts. 5) "Contact" If you have any comment or question, contact us. Email addresses can be found on the contact page. Or, simply post to our mailing lists and forum. We'll try the best to give instant replies. From owner-netdev@oss.sgi.com Mon Apr 1 17:26:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g321Qb607051 for netdev-outgoing; Mon, 1 Apr 2002 17:26:37 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.6/8.11.3) with ESMTP id g321Qao07036 for ; Mon, 1 Apr 2002 17:26:36 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g321QZv19752 for netdev@oss.sgi.com; Mon, 1 Apr 2002 17:26:35 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31DqUv31324 for ; Mon, 1 Apr 2002 05:52:32 -0800 Message-Id: <200204011352.g31DqUv31324@oss.sgi.com> Received: from arpabox([211.80.41.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm103ca8913e; Mon, 01 Apr 2002 21:52:35 +0800 Date: Mon, 1 Apr 2002 21:54:35 +0800 From: Laudney Ren To: netdev Subject: T/TCP for Linux Website Major Update Completed X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g31Dqav31326 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, everyone: "T/TCP for Linux" has seen major updates during the last one month: 1) A new mirror site opened at http://ttcplinux.tripod.com The project home is still at http://ttcplinux.sourceforge.net 2) "Tools" a) Sock Sock is a network program written by W. Richard Stevens. It can be used both as a client and as a server and can send both TCP and UDP packets. b) TCPdump Tcpdump is originally written by Van Jacobson, Craig Leres and Steven McCanne, all of whom come from Lawrence Berkeley Laboratory. Tcpdump sets the network interfaces in "promiscuous" mode to sniff every packet received by the interfaces. Tcpdump-3.3 is able to print out CC, CC_NEW and CC_ECHO options introduced by T/TCP. c) SSH_tunnel SSH_tunnel is a perl script. If you are using ssh behind a firewall or a proxy, you can use this script to direct your ssh traffic through the proxy. 3) "Join us" If you are interested, you can join as an end-user, andience or developer. You will see how to do so on this page. 4) "Documents" This is the part that has seen most drastic updates. There have been about 20 flowgraphs to outline TCP/IP stack in an easy manner or describe methods call sequence in details. You can browse the docs online or download a zipped version at http://prdownloads.sourceforge.net/ttcplinux/Docs_2_4_2.zip. All the documents are divided into six parts: Part one: Linux Kernel TCP/IP Stack Analyses You will see everything, from mostly involved structures to all the methods called during the sending and receiving process and state transition graph, that are both important and foundamental. Anyone that is interested in the understanding of TCP/IP stack of Linux kernel can find useful information here. Part two: Introduction to T/TCP defined in RFC 1644 Here you see detailed introductions to T/TCP, eg. what modifications does T/TCP bring to standard TCP? Part three: Design and Implementation Approach This part is the longest one. It's about implementation approaches. Lies here the answer to "How T/TCP add new functions to TCP with being able to fall back to TCP automatically or manually?" Part four: Known Problems with T/TCP defined in RFC 1644 T/TCP has been around for some time. But it's been rejected for its serious security problems. A detailed breakdown of those problems and "crack methods" are described here. Maybe the biggest mission of "T/TCP for Linux" is to handle the security problems and come up with a new RFC. Of course, with the necessary involvement of each of you around. Part five: Current Patches Performance Testing Information Part six: Current Patches Debugging and Fixing Information These two parts are not started since the debugging process have yet started.Information will be updated lively on these two parts. 5) "Contact" If you have any comment or question, contact us. Email addresses can be found on the contact page. Or, simply post to our mailing lists and forum. We'll try the best to give instant replies. From owner-netdev@oss.sgi.com Mon Apr 1 17:26:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g321QkB07149 for netdev-outgoing; Mon, 1 Apr 2002 17:26:46 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.6/8.11.3) with ESMTP id g321Qjo07146 for ; Mon, 1 Apr 2002 17:26:45 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g321Qiv19756 for netdev@oss.sgi.com; Mon, 1 Apr 2002 17:26:44 -0800 Received: from web21302.mail.yahoo.com (web21302.mail.yahoo.com [216.136.173.210]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31Ew9v32603 for ; Mon, 1 Apr 2002 06:58:09 -0800 Message-ID: <20020401145730.14109.qmail@web21302.mail.yahoo.com> Received: from [211.92.194.35] by web21302.mail.yahoo.com via HTTP; Mon, 01 Apr 2002 06:57:30 PST Date: Mon, 1 Apr 2002 06:57:30 -0800 (PST) From: Laudney Ren Subject: T/TCP for Linux Website Major Update Completed To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, everyone: "T/TCP for Linux" has seen major updates during the last one month: 1) A new mirror site opened at http://ttcplinux.tripod.com The project home is still at http://ttcplinux.sourceforge.net 2) "Tools" a) Sock Sock is a network program written by W. Richard Stevens. It can be used both as a client and as a server and can send both TCP and UDP packets. b) TCPdump Tcpdump is originally written by Van Jacobson, Craig Leres and Steven McCanne, all of whom come from Lawrence Berkeley Laboratory. Tcpdump sets the network interfaces in "promiscuous" mode to sniff every packet received by the interfaces. Tcpdump-3.3 is able to print out CC, CC_NEW and CC_ECHO options introduced by T/TCP. c) SSH_tunnel SSH_tunnel is a perl script. If you are using ssh behind a firewall or a proxy, you can use this script to direct your ssh traffic through the proxy. 3) "Join us" If you are interested, you can join as an end-user, andience or developer. You will see how to do so on this page. 4) "Documents" This is the part that has seen most drastic updates. There have been about 20 flowgraphs to outline TCP/IP stack in an easy manner or describe methods call sequence in details. You can browse the docs online or download a zipped version at http://prdownloads.sourceforge.net/ttcplinux/Docs_2_4_2.zip. All the documents are divided into six parts: Part one: Linux Kernel TCP/IP Stack Analyses You will see everything, from mostly involved structures to all the methods called during the sending and receiving process and state transition graph, that are both important and foundamental. Anyone that is interested in the understanding of TCP/IP stack of Linux kernel can find useful information here. Part two: Introduction to T/TCP defined in RFC 1644 Here you see detailed introductions to T/TCP, eg. what modifications does T/TCP bring to standard TCP? Part three: Design and Implementation Approach This part is the longest one. It's about implementation approaches. Lies here the answer to "How T/TCP add new functions to TCP with being able to fall back to TCP automatically or manually?" Part four: Known Problems with T/TCP defined in RFC 1644 T/TCP has been around for some time. But it's been rejected for its serious security problems. A detailed breakdown of those problems and "crack methods" are described here. Maybe the biggest mission of "T/TCP for Linux" is to handle the security problems and come up with a new RFC. Of course, with the necessary involvement of each of you around. Part five: Current Patches Performance Testing Information Part six: Current Patches Debugging and Fixing Information These two parts are not started since the debugging process have yet started.Information will be updated lively on these two parts. 5) "Contact" If you have any comment or question, contact us. Email addresses can be found on the contact page. Or, simply post to our mailing lists and forum. We'll try the best to give instant replies. --laudney@21cn.com __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ From owner-netdev@oss.sgi.com Mon Apr 1 17:44:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g321iDB07908 for netdev-outgoing; Mon, 1 Apr 2002 17:44:13 -0800 Received: from grumpy.usu.edu (grumpy.usu.edu [129.123.1.86]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g321i9o07905 for ; Mon, 1 Apr 2002 17:44:09 -0800 Received: from webmail.usu.edu ("port 2032"@webster.usu.edu [129.123.1.90]) by cc.usu.edu (PMDF V5.2-32 #39089) with ESMTP id <01KG25E2AHYA90S2BR@cc.usu.edu> for netdev@oss.sgi.com; Mon, 1 Apr 2002 18:43:54 MST Date: Mon, 01 Apr 2002 18:43:54 -0700 From: "Napanda. C. Pemmaiah" Subject: Confirmation! To: netdev@oss.sgi.com Message-id: <3CABC1F5@webmail.usu.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.62 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 7bit X-WebMail-UserID: pemmaiah X-EXP32-SerialNo: 00002751 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, How are you? I am Anup Pemmaiah doing my masters in computer science at Utah State University -USA. I have a linux box running Red Hat 7.2 (kernel version 2.4). My ethernet driver is 3c59x. I had two questions regarding 3c59x module installation. 1) When the system is booted the module gets installed. I was curious from where does this installation takes place. As far i learnt from the documentation, this is done because of the entry "alias eth0 3c59x" in the /etc/modules.conf file. But even if I delete this entry and reboot the system still the module gets installed. 2) I removed the module by "rmmod 3c59x" and again installed it by "insmod /lib/modules/...../net/3c59x.o". The module got installed but in the /proc/modules it shows "3c59x 0(unused)". And from /etc/rc.d/init.d if I start the network by saying "./network start" the eth0 conncetion does not come up. Is it because of some options setting to be done during insmod. I searched and tried a lot but I could not figure out the above two problems. It will be really great if you can give the solution for the above problems. I will be eagerly waiting for your reply. I am sorry for disturbing you. Have a nice day. Thank you, Anup Pemmaiah ------------------------------------------------- N.C.Pemmaiah (Anup) 620E, 700N, Apt# 2 Logan, UT-84321,USA. email: pemmaiah@cc.usu.edu, anup_pemmaiah@yahoo.com Ph: 435-512-0935(mob.), 435-752-5976 (Res.) ------------------------------------------------- From owner-netdev@oss.sgi.com Mon Apr 1 19:10:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g323AQd09741 for netdev-outgoing; Mon, 1 Apr 2002 19:10:26 -0800 Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g323AGo09737 for ; Mon, 1 Apr 2002 19:10:17 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA17849; Mon, 1 Apr 2002 22:10:15 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3235Fm15040; Mon, 1 Apr 2002 22:05:15 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 1 Apr 2002 22:05:15 -0500 (EST) From: jamal To: David Brownell cc: Stefan Rompf , Subject: Re: Patch: Device operative state notification against 2.5.7 In-Reply-To: <080d01c1d9bc$3d4510a0$6800000a@brownell.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Mon, 1 Apr 2002, David Brownell wrote: > Two comments on this stuff: > > (A) I skimmed the 3.1.13 descriptions in RFC 2863. > If RUNNING is to correspond to ifAdminStatus, > and NO_CARRIER is inverted up/down ifOperStatus, > this starts to make sense. For example, it defines > the set/set state in Jamal's table as a fault condition. Actually ifOperStatus == NO_CARRIER/IFF_RUNNING set NO_CARRIER is used to reflect IFF_RUNNING in serialized way. ifAdminStatus == IFF_UP Someone needs to enumarate a different truth table with IFF_UP etc based on the RFC. > > That doesn't quite seem like a complete match though, > and not only because one can't map N-ary ifOperStatus > (up, down, unknown, testing, dormant, notPresent, and > maybe more) to single bits like NO_CARRIER. > I think we need three bits now to represent IFF_RUNNING (as opposed to the old 1 bit); we also need two bits for IFF_UP; note both are defined as integeers. My only concern is how to map NO_CARRIER now that we have this. > (B) In Jamal's table I'm thinking about how IP-over-USB > stacks would work. Those tend to be point-to-point > links with Ethernet framing (easier to bridge :). That table is now inappropriate; we need a new one to map IFF_UP and the two bits in IFF_RUNNING. > > The devices themselves are all hotplugged, so their > interface names won't exist unless there's hardware > (maybe it's in the process of being unplugged). But > that means there are three meaningful modes: > > - Only "my" end connected ... nobody on the > other end (treated as NO_CARRIER) so > IFF_RUNNING can't _ever_ usefully be set > !IFF_UP and IFF_RUNNING == dormant but once USB negotiation starts IFF_RUNNING should transition to notPresent BTW, i think that IFF_RUNNING == notPresent should also apply for ethernet where theres MII autonegotiation failures (speed mismatch) > - Both ends connected (!NO_CARRIER) > so IFF_RUNNING could be set or not. > !IFF_UP and IFF_RUNNING == up > - "Indeterminate" ... some cables might not be > able to report whether someone's on the other > end. Driver would necessarily treat as if both > ends were always connected. I guess one of those other oper states would represent things Admin status could be up/down. IFF_UP goes to up only if an IP address has been assigned to the USB interface for example via DHCP etc I am kind of brain dead right now, but i am sure we can map hotplug devices easily cheers, jamal From owner-netdev@oss.sgi.com Sun Apr 7 13:22:07 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g37KM7VK008418 for ; Sun, 7 Apr 2002 13:22:07 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g37KM7B8008417 for netdev-outgoing; Sun, 7 Apr 2002 13:22:07 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g37KLrVK008412 for ; Sun, 7 Apr 2002 13:21:53 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA23284; Sun, 7 Apr 2002 16:22:09 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g37KGxN12902; Sun, 7 Apr 2002 16:17:04 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 7 Apr 2002 16:16:59 -0400 (EDT) From: jamal To: Stefan Rompf cc: Subject: Re: Patch: Device operative state notification against 2.5.7 In-Reply-To: <3CACB9BC.4D585C25@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Stefan, On Thu, 4 Apr 2002, Stefan Rompf wrote: > Hi Jamal, > > > I think we should use SNMPs view of the world. RFC2863 still hasnt > > been obsoleted, AFAIK. > > Look at sections 3.1.12-14. There is a correlation between > > admin/IFF_UP and oper/IFF_RUNNING. > > Agreed. If we want to be that specific, I'd prefer to go even further > than the SNMP specification: > > -IFOP_UP > Interface is operational up. > -IFOP_TESTING > Interface is just being tested > -IFOP_UNKNOWN > Driver is not capable of testing the interface status > -IFOP_DORMANT > Interface is sleeping, lower layer status may be unknown. If i understand you correctly, this would still be something along the lines of dial on demand PPP. It stays "dormant" until it receives outgoing packet which initiates connection establishment activity. The type of activity may vary ... Cant remember what diald does, but if i am not mistaken it actually kills the device and creates a new one everytime it detects activity > -IFOP_DOWN_NOTPRESENT > Interface does not exist. This can be f.e. an USB device that has just > been unplugged What do you plan to do with this? eg, the name and stats for example wont change. What do the USB people think? > -IFOP_DOWN_LOWERLAYER > Lower layer is down, f.e. ethernet interfaces below a VLAN > -IFOP_DOWN_NOCARRIER > Interface link beat/framing is missing (current netif_carrier_o* maps > here) Good naming convention for the above two. > -IFOP_DOWN_KEEPALIVE > Another form of keepalive is missing Not clear on this one. > -IFOP_DOWN_TX_TIMEOUT > Transmit timeout signalled by scheduler I take it you want to use this for informational purposes i.e someone has to solicit for this information (Note, it is legal to have transmit path timeout but receive path just fine) > Multiple down reasons can be active for an interface. > this could be tricky mostly because some of the DOWN values are actually different states (in the state machine) eg IFOP_DOWN_NOTPRESENT --> IFOP_DOWN_NOCARRIER when the USB hardware is inserted Also the only time IFOP_DOWN_LOWERLAYER makes sense is when the top stacked device is actually admin up (but none of the lower devices are operationally UP) Maybe you mean there should be something generally refered to as IFOP_DOWN and the reason would be one of IFOP_DOWN_* ? > These states can be represented by atomic data types in the netdevice > structure so that they can safely be set and queried from everywhere > within the kernel. If IFOP_UP, IFOP_UNKNOWN or IFOP_DORMANT is set, > IFF_RUNNING will be visible. If course it must be possible to get the > detailed states from user mode and may be write to IFOP_DORMANT. > The only useful state transitions are to/from IFOP_DOWN_NOCARRIER in my opinion. What do you think? In which case you only set IFF_RUNNING when you transition from IFOP_DOWN_NOCARRIER -> IFOP_UP and you clear it when IFOP_UP -> IFOP_DOWN_NOCARRIER Things like IFOP_DORMANT can probably be set only by the driver and still retrieved via netlink or even ioctl when they are solicited for. By default you only announce via netlink transitions to/from IFOP_DOWN_NOCARRIER. > Userspace notification via netlink should remain optional. Does it make > sense to queue up events or is it enough to report the last state after > a bunch of changes has happened? For me, the second would be ok, > especially as all drivers that can do link beat detection now utilise a > timer for this purpose and will lose too rapid changes anyway. I think the transitions to/from IFOP_DOWN_NOCARRIER would be useful for in kernel FIB or ARP updates as well; so maybe making these two optional would not be a wise decision. And if you send within the kernel then by default user space also gets it. To avoid oscillations you only send the latest request _if it is still valid_, otherwise dont send any. Your code structuring should be built for this. Also (this might be tricky to do), once you start flapping like that, it would also make sense to ratelimit (in exponential manner) the amount of netlink messages you send to announce carrier on/off. One other thing you didnt talk about is the relation ship with IFF_UP; essentially, !IFF_UP would also mean !IFF_RUNNING and generally one of the DOWN states (NOCARRIER?). when someone ifconfigs up, that should also invoke the device operational discovery activity (eg via device open()), so no need to worry there. Apologies for making life difficult Stefan; we need to get it right and we have that opportunity ;-> cheers, jamal From owner-netdev@oss.sgi.com Sun Apr 7 13:31:45 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g37KVjVK008690 for ; Sun, 7 Apr 2002 13:31:45 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g37KVjmS008689 for netdev-outgoing; Sun, 7 Apr 2002 13:31:45 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g37KVgVK008684 for ; Sun, 7 Apr 2002 13:31:42 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA25887; Sun, 7 Apr 2002 16:31:59 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g37KQrg12928; Sun, 7 Apr 2002 16:26:53 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 7 Apr 2002 16:26:53 -0400 (EDT) From: jamal To: Stefan Rompf cc: Subject: Re: Patch: Device operative state notification against 2.5.7 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, 7 Apr 2002, jamal wrote: > The only useful state transitions are to/from IFOP_DOWN_NOCARRIER > in my opinion. What do you think? I meant this view from a "listener" perspective; example from an SNMP NMS perspective or even a dynamic route daemon, this is the only really interesting state transition. So IMO, it only makes sense to send netlink messages for these. cheers, jamal From owner-netdev@oss.sgi.com Sun Apr 7 16:05:55 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g37N5tVK010687 for ; Sun, 7 Apr 2002 16:05:55 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g37N5lsY010684 for netdev-outgoing; Sun, 7 Apr 2002 16:05:47 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-netdev@oss.sgi.com using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g37N5RVK010677 for ; Sun, 7 Apr 2002 16:05:27 -0700 Received: (qmail 25354 invoked by uid 0); 7 Apr 2002 23:05:37 -0000 Received: from a1as10-p197.stg.tli.de (HELO havana.yon.net) (195.252.189.197) by mail.gmx.net (mp014-rz3) with SMTP; 7 Apr 2002 23:05:37 -0000 Received: from localhost (localhost [127.0.0.1]) by havana.yon.net (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g37N0L919556; Mon, 8 Apr 2002 01:00:21 +0200 Date: Mon, 8 Apr 2002 01:00:20 +0200 (CEST) From: Yon Uriarte Reply-To: To: cc: linux netdev Subject: [HELP] kernel_thread Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, I'm developing the IPSEC NAT traversal patch and I've run on a little problem. I'm crossposting this to both list in the hope of getting an answer at all. I'm getting moderately desperate :-E3 The issue: I need to 'steal' skbs from the receive queue of an udp socket. My code only gets called as the data_ready() callback of the struct sock (in softirq context, AFAIK). Apparently this means sometimes there are more than 1 packet on the queue. Those packets can be normal packets(N), keepalive(K) or udp-encapsulated-esp packets(E). Graphically: Sock->receive_queue -> K->N->E->N->E->E->NULL At first, following the data path (udp_queue_rcv_skb), I thought only one packet would be on the queue at any one time, so all I had to do was check the last packet on the queue and handle it (drop, decode, let it stay there and call the normal callback (to wake up the reading process)). But pinging -f led to packet loss, or better put, E-type packet passing to user space. So my first question is: Any good idea on how to resolve this? Would RTFinclude/linux/timer.hIF help (is it appropiate for this)? I decided to implement the following strategy: On callback I would walk the whole queue, removing K's and enqueueing the E packets on another private queue (after removing them off the sock). This queue is worked on by a kernel thread (man kernel_thread(k) (I wish!)), just like ksoftirqd_CPUN, kreiserfsd, etc... This has the nice property of being able to see how much time/cpu% udp/esp packet decoding is taking. All is well (hmm, better put:it doesnt crash, this has induced other funny bugs), until the module is unloaded. The memory isnt being freed. So after a few load/unloads its reboot time (I run my UMLs with mem=16m, so that would be around 3 cycles). I've looked at some of the users of kernel_thread (kreisersfsd, ksoftirqd, apm, some weirdo drivers) and cant quite find the differences between my usage and theirs, I've even suspected some UML bug, but I could load/unload the reiserfs module (mounting/umount something, to trigger the startup of the thread) without problems. I suspected I was starting the kernel thread on the wrong context and changed the code to trigger the startup of the thread only when there are active udp-encaps SAs around, at ipsec_sa_put() time. No luck, same result. I've tried playing with the clone_flags argument to kernel_thread, no luck. I suppose the correct argument to clone_flags for my needs is 0. I'm sleeping on module unload time, waiting for the threads to die. They are all gone by the time I return to the caller of cleanup_module(). I've played with __init/__exit, no luck. Questions: Is this overkill? What I'm doing wrong? Code snippet (I'm only running one thread atm, but it will be easy to add the code to expand this to 1 thread/cpu): ----------------------------------- struct sk_buff_head udp_ipsec_list; DECLARE_WAIT_QUEUE_HEAD(udp_decapsulators); spinlock_t udp_decapsulators_lock; atomic_t udp_threads = ATOMIC_INIT(0); static volatile int udp_stop_threads = 0; /* XXX is volatile needed ? */ /* snip[the callback queueing the packets on udp_ipsec_list] */ static int k_ipsec_udp(void * __bind_cpu) { int bind_cpu = (int) (long) __bind_cpu; int cpu = cpu_logical_map(bind_cpu); DECLARE_WAITQUEUE(wait, current); struct sk_buff *skb; /* MOD_INC_USE_COUNT not needed, we sleep on unload to wait for the threads */ atomic_inc(&udp_threads); daemonize(); reparent_to_init(); current->nice = 19; spin_lock_irq(¤t->sigmask_lock); sigfillset(¤t->blocked); recalc_sigpending(current); spin_unlock_irq(¤t->sigmask_lock); sprintf(current->comm, "kipsec_udp_CPU%d", bind_cpu); /* Migrate to the right CPU */ current->cpus_allowed = 1UL << cpu; while (smp_processor_id() != cpu) schedule(); set_current_state(TASK_INTERRUPTIBLE); mb(); add_wait_queue( &udp_decapsulators, &wait); for (;;) { printk(KERN_CRIT "kipsec_udp_CPU%d main\n", bind_cpu); set_current_state(TASK_INTERRUPTIBLE); schedule(); set_current_state(TASK_RUNNING); if ( udp_stop_threads ) break; while ( skb_queue_len( &udp_ipsec_list) > 0 ) { //int i = 0; printk(KERN_CRIT "kipsec_udp_CPU%d processing\n", bind_cpu); skb = skb_dequeue( &udp_ipsec_list ); if( skb != NULL ) ipsec_udp_input(skb); /* will call ipsec_rcv after mangling the skb a little */ /* if( ++i % 16 && current->need_resched) schedule(); */ } } while ( ( skb = skb_dequeue( &udp_ipsec_list) ) != NULL ) kfree_skb( skb ) ; atomic_dec(&udp_threads); /* MOD_DEC_USE_COUNT not needed, * we sleep on unload to wait for the threads */ printk(KERN_CRIT "Exiting ipsec_udp thread on cpu %d\n", bind_cpu); return 0; } int /*__init*/ start_udp_threads(void) { int cpu; spin_lock( &udp_decapsulators_lock ); printk(KERN_CRIT "start_udp_threads()\n"); skb_queue_head_init( &udp_ipsec_list ); for (cpu = 0; cpu < smp_num_cpus; cpu++) { if (kernel_thread( k_ipsec_udp, (void *) (long) cpu, 0) < 0) printk("start_udp_threads() failed for cpu %d\n", cpu); } spin_unlock( &udp_decapsulators_lock ); return 0; } /*__initcall(start_udp_threads);*/ int /*__exit*/ stop_udp_threads(void) { int n; printk(KERN_CRIT "stop_udp_threads()\n"); spin_lock( &udp_decapsulators_lock ); udp_stop_threads = 1; wake_up( &udp_decapsulators ); while( ( n = atomic_read(&udp_threads)) > 0) { printk(KERN_CRIT "stop_udp_threads waiting 1 sec for threads, %d still running \n", n); set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout(1*HZ); set_current_state(TASK_RUNNING); } spin_unlock( &udp_decapsulators_lock ); return 0; } ----------------------- Any obvious error? TIA, regards yon From owner-netdev@oss.sgi.com Sun Apr 7 19:20:07 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g382K7VK014467 for ; Sun, 7 Apr 2002 19:20:07 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g382K7Ng014466 for netdev-outgoing; Sun, 7 Apr 2002 19:20:07 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-netdev@oss.sgi.com using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g382JvVK014453 for ; Sun, 7 Apr 2002 19:20:00 -0700 Received: from marajade.sandelman.ottawa.on.ca ([2002:d89a:260::20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g382Jhn04841 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 7 Apr 2002 22:20:04 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g37MB3v06124 for ; Sun, 7 Apr 2002 18:11:06 -0400 (EDT) Message-Id: <200204072211.g37MB3v06124@marajade.sandelman.ottawa.on.ca> To: netdev@oss.sgi.com Subject: Re: Patch: Device operative state notification against 2.5.7 In-reply-to: Your message of "Sun, 07 Apr 2002 16:16:59 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 07 Apr 2002 18:11:03 -0400 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "jamal" == jamal writes: >> -IFOP_DOWN_LOWERLAYER >> Lower layer is down, f.e. ethernet interfaces below a VLAN >> -IFOP_DOWN_NOCARRIER >> Interface link beat/framing is missing (current netif_carrier_o* maps >> here) Are there docs on these interfaces somewhere? jamal> Good naming convention for the above two. >> -IFOP_DOWN_KEEPALIVE >> Another form of keepalive is missing jamal> Not clear on this one. PPP, for instance, does keepalives. An IPsec tunnel might also use such a mechanism (we have plans). jamal> Also the only time IFOP_DOWN_LOWERLAYER makes sense is when the top jamal> stacked device is actually admin up (but none of the lower devices are jamal> operationally UP) There are very good operational reasons why this is often done... It would be nice to see this kind of stuff in diagnostics. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPLDD9YqHRg3pndX9AQGvhwP9HYlhJ1BJ5uJUDkRjcbLuaYLkwFrNWX+8 X4hvPb1mOgwQOPs3Fwz40Ng7FEHk4GECwSbRQlccEoSbPU1BLRmUESywN8xmAMyJ uGVqRt9UOzNzTtuvxOdpxk4LkNxZt06Flbs3DAvwv7G4d4W5Ciovu7I/JEjcnbCI qAcy0HuyDqI= =EQ18 -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Mon Apr 8 05:04:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38C4MVK009602 for ; Mon, 8 Apr 2002 05:04:22 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38C4MIp009601 for netdev-outgoing; Mon, 8 Apr 2002 05:04:22 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38C4EVK009597 for ; Mon, 8 Apr 2002 05:04:15 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA25494; Mon, 8 Apr 2002 08:04:34 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g38BxT714899; Mon, 8 Apr 2002 07:59:29 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 8 Apr 2002 07:59:29 -0400 (EDT) From: jamal To: Michael Richardson cc: Subject: Re: Patch: Device operative state notification against 2.5.7 In-Reply-To: <200204072211.g37MB3v06124@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, 7 Apr 2002, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "jamal" == jamal writes: > >> -IFOP_DOWN_LOWERLAYER > >> Lower layer is down, f.e. ethernet interfaces below a VLAN > >> -IFOP_DOWN_NOCARRIER > >> Interface link beat/framing is missing (current netif_carrier_o* maps > >> here) > > Are there docs on these interfaces somewhere? > I guess this discussion will result in some documentation... > jamal> Good naming convention for the above two. > > >> -IFOP_DOWN_KEEPALIVE > >> Another form of keepalive is missing > > jamal> Not clear on this one. > > PPP, for instance, does keepalives. > An IPsec tunnel might also use such a mechanism (we have plans). > Well, in that case the device is actually IFOP_UP. And the keepalives could be looked at as "carrier/link level diagnostics". Should the heartbeats disappear, it would be fair to transition the device to IFOP_DOWN_NOCARRIER. Should the device underneath have its carrier dissapear (eg a cable removed on an ethernet which ipsec0 uses), then the transition is very quickly to IFOP_DOWN_LOWERLAYER.... I guess the device(ipsec0) may also transition to IFOP_DOWN_NOCARRIER since its carrier path is doewn etc. > jamal> Also the only time IFOP_DOWN_LOWERLAYER makes sense is when the top > jamal> stacked device is actually admin up (but none of the lower devices are > jamal> operationally UP) > > There are very good operational reasons why this is often done... > It would be nice to see this kind of stuff in diagnostics. I think they should be accessible; whether you send netlink advertisements everytime there is some state transition is the question. In my opinion the only interesting things are the a transition from a case where a carrier (ethernet cable) is connected to where it is disconnected. The other direction is also important. For example, i think these are the only two route daemons need to know about. cheers, jamal From owner-netdev@oss.sgi.com Mon Apr 8 09:15:18 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38GFI8d026299 for ; Mon, 8 Apr 2002 09:15:18 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38GFI0f026298 for netdev-outgoing; Mon, 8 Apr 2002 09:15:18 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-netdev@oss.sgi.com using -f Received: from rcpt-expgw.biglobe.ne.jp (rcpt-expgw.biglobe.ne.jp [202.225.89.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38GF88d026295 for ; Mon, 8 Apr 2002 09:15:09 -0700 Received: from smtp-gw.biglobe.ne.jp by rcpt-expgw.biglobe.ne.jp (mnmy/3114200202) with ESMTP id g38GFRQ14139; Tue, 9 Apr 2002 01:15:27 +0900 (JST) X-Biglobe-Sender: Received: from monza (210.135.214.150 [210.135.214.150]) by smtp-gw.biglobe.ne.jp id BAEEC0A8261E; Tue, 09 Apr 2002 01:15:27 +0900 (JST) Date: Tue, 9 Apr 2002 01:15:23 +0900 From: Kazunori Miyazawa To: netdev@oss.sgi.com Cc: USAGI Core Subject: USAGI stable release Message-Id: <20020409011523.07e9a540.miyazawa@mrj.biglobe.ne.jp> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, We are glad to announce the USAGI[1] STABLE RELEASE 3.1, dated on April 8th, 2002. Although this is a maintenance release of the STABLE RELEASE 3 dated on January 1st, 2002, it comes with a latest kernel and couple of new features. The new / updated features are: - based on latest kernel linux-2.4.18 (linux-2.2.20 for linux-2.2 systems) - based on radvd-0.7.1, a router advertisement daemon - ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) support - IPv4 and/or IPv6 over IPv4 Tunnel on a single driver support - Privacy Extensions for linux-2.2 systems We also fixed the following bugs of the previous release: - Fixed a bug, which devices, such as PCMCIA devices, could not finish correctly when using Privacy Extensions. - Fixed a bug, which getifaddrs(3) did not report local/remote addresses of point-to-point devices. - Fixed a bug, which tcp_wrapper was not compiled correctly, so that ipv6 support was not enabled. and so on. You can get our complete kit which includes kernel tree, library and applications from the following URL. We also provide separate patches against the main-line kernel and the tools. We have a plan to provide the binary packages for some distributions. They will appear under within several weeks. We announce the latest information on our web pages. Please check our web site . We also manage the mailing list for USAGI users. If you have questions, please join the mailing list. Comments and advises are also welcome on that mailing list. Please visit for further information. Thanks. About USAGI Project: The USAGI Project is managed by volunteers and aims to provide better IPv6 environment on Linux freely. We are tightly collaborating with WIDE Project[2], KAME Project[3] and TAHI Project[4], and trying to improve Linux kernel, IPv6 related libraries and IPv6 applications. Our snapshots are released every two weeks and stable release is released several times a year. Please check our web site for the latest information. References: [1] USAGI Project [2] WIDE Project [3] KAME Project [4] TAHI Project -- USAGI Project From owner-netdev@oss.sgi.com Mon Apr 8 13:23:47 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38KNk8d004095 for ; Mon, 8 Apr 2002 13:23:47 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38KNkuh004094 for netdev-outgoing; Mon, 8 Apr 2002 13:23:46 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-netdev@oss.sgi.com using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38KNh8d004085 for ; Mon, 8 Apr 2002 13:23:43 -0700 Received: from krypton ([206.170.7.98]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GU900IL3NBYJH@mta7.pltn13.pbi.net> for netdev@oss.sgi.com; Mon, 08 Apr 2002 13:24:04 -0700 (PDT) Date: Mon, 08 Apr 2002 10:48:51 -0700 From: David Brownell Subject: Re: Patch: Device operative state notification against 2.5.7 To: jamal , Stefan Rompf Cc: netdev@oss.sgi.com Message-id: <035c01c1df3b$17243d40$6800000a@brownell.org> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-netdev@oss.sgi.com Precedence: bulk > > The only useful state transitions are to/from IFOP_DOWN_NOCARRIER > > in my opinion. What do you think? > > I meant this view from a "listener" perspective; example from an > SNMP NMS perspective or even a dynamic route daemon, this is the only > really interesting state transition. So IMO, it only makes sense to send > netlink messages for these. But ... how about "carrier on"? What else would be able to trigger software to bring the interface up (so it could be routed or bridged) if there were no notification for "carrier on"? Not expecting some administrator to be initating it (or eyeballing some status display); one can ignore alerts, but one can't create them from nothing. This is where my "asymmetry in design" alert triggers. It's usually been a good early warning system for trouble ... :) - Dave From owner-netdev@oss.sgi.com Tue Apr 9 04:43:48 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g39Bhm8d013995 for ; Tue, 9 Apr 2002 04:43:48 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g39BhmYB013994 for netdev-outgoing; Tue, 9 Apr 2002 04:43:48 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-netdev@oss.sgi.com using -f Received: from luxik.cdi.cz (root@inway106.cdi.cz [213.151.81.106]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g39Bhi8d013990 for ; Tue, 9 Apr 2002 04:43:45 -0700 Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16uu2a-0004tu-00; Tue, 09 Apr 2002 13:44:00 +0200 Date: Tue, 9 Apr 2002 13:43:59 +0200 (CEST) From: Martin Devera To: jamal cc: netdev@oss.sgi.com Subject: QoS _put, _get and _delete class ops semantic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 755 Lines: 21 Hi Jamal, please can you help me with this ? During testing of speed improved HTB (as we talked about) I have problem to understand rationale behing Subj and can't find any docs. put and get seem to be simply reference counting on class object. I'd expect thet class creation will call get once to assure that it is locked in active state and "tc class del" would call last put to release this last reference (and class will destroy itself). Unfortunately there is delete class op which seems to do almost the same as put. Do you know rationale behind it ? Why we have both put and delete and what tc framework expect from qdisc ? I know there is some description tcio-current but it doesn't go into great depth on this topic. Thanks in advance, devik From owner-netdev@oss.sgi.com Tue Apr 9 05:09:57 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g39C9u8d014581 for ; Tue, 9 Apr 2002 05:09:57 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g39C9ul2014580 for netdev-outgoing; Tue, 9 Apr 2002 05:09:56 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-netdev@oss.sgi.com using -f Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g39C9h8d014575 for ; Tue, 9 Apr 2002 05:09:44 -0700 Received: from barkeeper.isg.de (barkeeper.is-asp.com [192.168.5.46]) by mail.isg.de (Postfix) with ESMTP id D3761970744; Tue, 9 Apr 2002 13:28:38 +0200 (CEST) Received: from isg.de (localhost.localdomain [127.0.0.1]) by barkeeper.isg.de (8.9.3/8.9.3) with ESMTP id NAA01075; Tue, 9 Apr 2002 13:28:37 +0200 Message-ID: <3CB2D065.A3DA60BB@isg.de> Date: Tue, 09 Apr 2002 13:28:37 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: jamal Cc: Michael Richardson , netdev@oss.sgi.com Subject: Re: Patch: Device operative state notification against 2.5.7 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 570 Lines: 14 Hi Jamal, > [discussion whether IFOP_DOWN_LOWERLAYER should send netlink messages] > > I think they should be accessible; whether you send netlink > advertisements everytime there is some state transition is the question. they should. For a routing daemon it is interesting to be notified when interfaces becomes capable or incapable of handling packets, independant of the reason. As long as we abstract virtual or subinterfaces as normal interfaces to the upper layers (which is IMHO the correct decision), IFOP_DOWN_LOWERLAYER must trigger a notification. Stefan From owner-netdev@oss.sgi.com Tue Apr 9 14:05:15 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g39L5F8d012488 for ; Tue, 9 Apr 2002 14:05:15 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g39L5Fem012487 for netdev-outgoing; Tue, 9 Apr 2002 14:05:15 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-netdev@oss.sgi.com using -f Received: from mail.osdl.org (air-2.osdl.org [65.201.151.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g39L5B8d012470 for ; Tue, 9 Apr 2002 14:05:11 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id g39L5FR27901; Tue, 9 Apr 2002 14:05:15 -0700 Date: Tue, 9 Apr 2002 14:02:30 -0700 (PDT) From: "Randy.Dunlap" X-X-Sender: To: cc: , Subject: remove unused kernel_stat fields Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 611 Lines: 28 Dave, anyone- I can't find any references to these fields in struct kernel_stat. Can they be removed...or is there non-kernel code that needs to have them in the kernel? Patch against 2.5.8-pre2. Please apply. --- linux-258-pre2/include/linux/kernel_stat.h.STAT Tue Apr 9 12:43:14 2002 +++ linux-258-pre2/include/linux/kernel_stat.h Tue Apr 9 13:40:51 2002 @@ -29,9 +29,6 @@ #if !defined(CONFIG_ARCH_S390) unsigned int irqs[NR_CPUS][NR_IRQS]; #endif - unsigned int ipackets, opackets; - unsigned int ierrors, oerrors; - unsigned int collisions; }; extern struct kernel_stat kstat; -- ~Randy From owner-netdev@oss.sgi.com Wed Apr 10 04:20:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ABKE8d008971 for ; Wed, 10 Apr 2002 04:20:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ABKDG9008970 for netdev-outgoing; Wed, 10 Apr 2002 04:20:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from balabit.hu (balabit.bakats.tvnet.hu [195.38.106.66]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ABK08d008959 for ; Wed, 10 Apr 2002 04:20:06 -0700 Date: Wed, 10 Apr 2002 13:20:25 +0200 From: Balazs Scheidler To: netdev@oss.sgi.com Subject: netlink question Message-ID: <20020410132025.A8595@balabit.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 579 Lines: 18 Hi, As I need to communicate between two parts of the kernel (a core TCP part, and a loaded module), Andi suggested to use netlink for this purpose. Since I'm not too familiar with Netlink (and I saw only userspace-kernel communication using netlink), I'd need some introductory material about netlink. Is some information about the subject available? Sample code would be sufficient as well. I've tried google but didn't find too much until now, so some help would be appreciated. TIA, -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 From owner-netdev@oss.sgi.com Wed Apr 10 10:41:21 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AHfL8d013507 for ; Wed, 10 Apr 2002 10:41:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AHfKw3013505 for netdev-outgoing; Wed, 10 Apr 2002 10:41:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AHeM8d013491 for ; Wed, 10 Apr 2002 10:40:22 -0700 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3AHehZ07979 for ; Wed, 10 Apr 2002 13:40:44 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2P90MGM8; Wed, 10 Apr 2002 13:40:43 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQPL0KRX; Wed, 10 Apr 2002 13:40:43 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 85E4B3A6 for ; Wed, 10 Apr 2002 13:51:12 -0400 (EDT) Message-ID: <3CB47B90.B4CF1FAD@nortelnetworks.com> Date: Wed, 10 Apr 2002 13:51:12 -0400 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: suggestion for routing code improvement Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1680 Lines: 42 Well, we're into a new experimental branch, so I figured the time had come to bring back an idea that didn't make it in a year ago. Currently, if you add custom routes and then down the device that the routes are associated with, the routes are then removed. This is entirely understandable. However, when you then up the interface, the routes do not come back up automatically. This is the part that I don't agree with. Addresses, automatic routes, and custom rules either stay in effect or are brought back up by the system when an interface is downed and then upped. The only exception to this is custom routes. I propose that these custom routes be stored in some fashion, and then be brought back up when the device is brought back up. This would make certain types of link management much simpler. Custom routes, once added, would stay in effect until explicitly removed. As it stands now, any time you down/up a link you have to then go back and add all the custom routes again. This can be a pain in the butt. So, what do you guys think? Is this a reasonable thing to do? I think that it makes the system nicely symmetrical, as opposed to the asymmetrical handling of current kernels. I don't have a really good grasp of what data structures are avialable to us in the routing code, so could someone with a better understanding of the code comment as to how hard this would be to implement? Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Wed Apr 10 11:35:01 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AIZ18d017573 for ; Wed, 10 Apr 2002 11:35:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AIZ1dr017572 for netdev-outgoing; Wed, 10 Apr 2002 11:35:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AIYr8d017564 for ; Wed, 10 Apr 2002 11:34:54 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id g3ALbkq01165; Wed, 10 Apr 2002 21:37:46 GMT Date: Wed, 10 Apr 2002 21:37:46 +0000 (GMT) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Chris Friesen cc: netdev@oss.sgi.com Subject: Re: suggestion for routing code improvement In-Reply-To: <3CB47B90.B4CF1FAD@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1380 Lines: 46 Hello, On Wed, 10 Apr 2002, Chris Friesen wrote: > However, when you then up the interface, the routes do not come back up > automatically. This is the part that I don't agree with. > > Addresses, automatic routes, and custom rules either stay in effect or are > brought back up by the system when an interface is downed and then upped. The > only exception to this is custom routes. Check this implementation of static routes (new version is coming soon...): http://www.linuxvirtualserver.org/~julian/#routes The exact patches for static routes: http://www.linuxvirtualserver.org/~julian/00_static_routes-2.4.16-6.diff http://www.linuxvirtualserver.org/~julian/00_static_routes-2.2.20-6.diff > So, what do you guys think? Is this a reasonable thing to do? I think that it > makes the system nicely symmetrical, as opposed to the asymmetrical handling of > current kernels. The patches are not perfect but I hope they can help you: ip route add XXX proto static Such routes survive only device state changes. They are removed when the last IP address is deleted or the device is unregistered. Of course, it is recommended that the multipath routes are recreated when a device used in nexthop is unregistered or all its addresses are deleted. So, it needs some scripting and help from user space. > Thanks, > > > Chris Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Wed Apr 10 11:53:30 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AIrT8d018144 for ; Wed, 10 Apr 2002 11:53:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AIrTi9018143 for netdev-outgoing; Wed, 10 Apr 2002 11:53:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AIrN8d018134 for ; Wed, 10 Apr 2002 11:53:24 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 7EA721EB45; Wed, 10 Apr 2002 20:53:47 +0200 (MEST) Date: Wed, 10 Apr 2002 20:53:47 +0200 From: Andi Kleen To: Chris Friesen Cc: netdev@oss.sgi.com Subject: Re: suggestion for routing code improvement Message-ID: <20020410205347.A29780@wotan.suse.de> References: <3CB47B90.B4CF1FAD@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CB47B90.B4CF1FAD@nortelnetworks.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2014 Lines: 41 On Wed, Apr 10, 2002 at 01:51:12PM -0400, Chris Friesen wrote: > > Well, we're into a new experimental branch, so I figured the time had come to > bring back an idea that didn't make it in a year ago. > > Currently, if you add custom routes and then down the device that the routes are > associated with, the routes are then removed. This is entirely understandable. > > However, when you then up the interface, the routes do not come back up > automatically. This is the part that I don't agree with. > > Addresses, automatic routes, and custom rules either stay in effect or are > brought back up by the system when an interface is downed and then upped. The > only exception to this is custom routes. > > I propose that these custom routes be stored in some fashion, and then be > brought back up when the device is brought back up. This would make certain > types of link management much simpler. Custom routes, once added, would stay in > effect until explicitly removed. As it stands now, any time you down/up a link > you have to then go back and add all the custom routes again. This can be a > pain in the butt. > > So, what do you guys think? Is this a reasonable thing to do? I think that it > makes the system nicely symmetrical, as opposed to the asymmetrical handling of > current kernels. > > I don't have a really good grasp of what data structures are avialable to us in > the routing code, so could someone with a better understanding of the code > comment as to how hard this would be to implement? I don't think it would be very hard. Internally device up/down state and the IP address lists and IP state are separated. The routes and addresses are currently removed triggered by the NETDEV_DOWN event on the netdev_chain. There is no fundamental reason AFAIK that needs to be done, you could not react to the DOWN event in IP in some circumstances. the upper layer should handle down devices already because that can always happen even now due to races at shutdown. -Andi From owner-netdev@oss.sgi.com Wed Apr 10 13:11:12 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AKBC8d020296 for ; Wed, 10 Apr 2002 13:11:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AKBBVl020295 for netdev-outgoing; Wed, 10 Apr 2002 13:11:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AKB28d020290 for ; Wed, 10 Apr 2002 13:11:07 -0700 Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id WAA03134; Wed, 10 Apr 2002 22:15:17 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15540.40277.772027.111512@robur.slu.se> Date: Wed, 10 Apr 2002 22:15:17 +0200 To: Chris Friesen Cc: netdev@oss.sgi.com Subject: suggestion for routing code improvement In-Reply-To: <3CB47B90.B4CF1FAD@nortelnetworks.com> References: <3CB47B90.B4CF1FAD@nortelnetworks.com> X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 850 Lines: 30 Chris Friesen writes: > So, what do you guys think? Is this a reasonable thing to do? I think that it > makes the system nicely symmetrical, as opposed to the asymmetrical handling of > current kernels. Hello! Why not leave the routing policy job to a routing daemon? There is risk of routing havoc if the kernel start acting as one. L-uu1:/# ip route list | wc -l 110441 This Linux box has 110441 bgp routes. Internet routing is very much like a living organism. Routes comes and goes. If some interface goes down for some reason the routing daemon gets it's netlink message "link down" and recalcs the routing topologi. If the interface comes back the router daemon recalcs again and installs appropriate routes for this moment which may very well be different compared to before "link down". Cheers. --ro From owner-netdev@oss.sgi.com Wed Apr 10 13:41:39 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AKfd8d021058 for ; Wed, 10 Apr 2002 13:41:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AKfcpn021057 for netdev-outgoing; Wed, 10 Apr 2002 13:41:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e33.esmtp.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AKfX8d021053 for ; Wed, 10 Apr 2002 13:41:34 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e33.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id g3AKfofH035774; Wed, 10 Apr 2002 16:41:50 -0400 Received: from d03nm035.boulder.ibm.com (d03nm035.boulder.ibm.com [9.17.194.35]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3AKeXJ34396; Wed, 10 Apr 2002 14:40:33 -0600 From: "Nivedita Singhvi" Importance: Normal Sensitivity: Subject: Re: suggestion for routing code improvement To: Robert Olsson Cc: Chris Friesen , netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Wed, 10 Apr 2002 13:41:04 -0700 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.9a |January 7, 2002) at 04/10/2002 02:40:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 840 Lines: 32 > > So, what do you guys think? Is this a reasonable thing > > to do? I think that it > > makes the system nicely symmetrical, as opposed to the > > asymmetrical handling of current kernels. > Hello! > Why not leave the routing policy job to a routing daemon? > There is risk of routing havoc if the kernel start acting > as one. > L-uu1:/# ip route list | wc -l > 110441 > This Linux box has 110441 bgp routes. Internet routing is > very much like a living organism. Routes comes and goes. But is that the norm? Not all linux installations are large internet nodes..I'd say at least a significant minority of hosts typically have just a few static routes, not running a routing daemon, who would be helped by some mechanism to auto reinstall routes..(perhaps a generously configurable one) thanks, Nivedita From owner-netdev@oss.sgi.com Wed Apr 10 13:46:43 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AKkh8d021276 for ; Wed, 10 Apr 2002 13:46:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AKkgBp021275 for netdev-outgoing; Wed, 10 Apr 2002 13:46:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AKji8d021252 for ; Wed, 10 Apr 2002 13:45:44 -0700 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3AKjwZ21465; Wed, 10 Apr 2002 16:45:59 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H63LD9WS; Wed, 10 Apr 2002 16:45:58 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQPL0LLV; Wed, 10 Apr 2002 16:45:59 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 8DEFF3A6; Wed, 10 Apr 2002 16:56:27 -0400 (EDT) Message-ID: <3CB4A6FB.F9146FDB@nortelnetworks.com> Date: Wed, 10 Apr 2002 16:56:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Robert Olsson Cc: netdev@oss.sgi.com Subject: Re: suggestion for routing code improvement References: <3CB47B90.B4CF1FAD@nortelnetworks.com> <15540.40277.772027.111512@robur.slu.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1622 Lines: 41 Robert Olsson wrote: > > Chris Friesen writes: > > So, what do you guys think? Is this a reasonable thing to do? I think that it > > makes the system nicely symmetrical, as opposed to the asymmetrical handling of > > current kernels. > > Hello! > > Why not leave the routing policy job to a routing daemon? Because I've got static routes, and I know exactly what they are. > This Linux box has 110441 bgp routes. Internet routing is very much > like a living organism. Routes comes and goes. The box(es) which inspired this sit on a private network, and once they are brought into service, the routes never change. However, there is a command from our gui to manually drop and raise the ethernet link (just in case something goes wrong and can't be handled automatically) and it would simplify our code greatly if the routes that are automatically deleted would be automatically put back. > If the interface comes back the router daemon recalcs again and installs > appropriate routes for this moment which may very well be different > compared to before "link down". In this case, my software *is* essentially the routing daemon, and I want it to be simpler to maintain. I think the concept is simple: I added some routes, and I think they should stay there until I remove them or the machine reboots. Doesn't this seem like a logical behaviour? Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Wed Apr 10 15:57:56 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AMvu8d025724 for ; Wed, 10 Apr 2002 15:57:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AMvupc025723 for netdev-outgoing; Wed, 10 Apr 2002 15:57:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AMvn8d025718 for ; Wed, 10 Apr 2002 15:57:49 -0700 Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id BAA05500; Thu, 11 Apr 2002 01:02:23 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15540.50303.858294.986710@robur.slu.se> Date: Thu, 11 Apr 2002 01:02:23 +0200 To: Chris Friesen Cc: Robert Olsson , netdev@oss.sgi.com Subject: Re: suggestion for routing code improvement In-Reply-To: <3CB4A6FB.F9146FDB@nortelnetworks.com> References: <3CB47B90.B4CF1FAD@nortelnetworks.com> <15540.40277.772027.111512@robur.slu.se> <3CB4A6FB.F9146FDB@nortelnetworks.com> X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1502 Lines: 45 Chris Friesen writes: > The box(es) which inspired this sit on a private network, and once they are > brought into service, the routes never change. However, there is a command from > our gui to manually drop and raise the ethernet link (just in case something > goes wrong and can't be handled automatically) and it would simplify our code > greatly if the routes that are automatically deleted would be automatically put > back. If we limit us to "static routes" for the other routes we must definitely leave to some with routing/topologi knowledge and we must not break systems with "routing daemons". If we look into the routing world a "route" can come from different origins/routing protocols static/ospf/rip/bgp and there is preferences to decide which one to install. So ip route add x y proto static Is registered by routing daemon and installed if it has the best pref. and the route is hidden otherwise to be restored when appropriate. And the route is invalid but kept by the daemon over "link downs" And I think ip route rep x y proto static or something similar at link up for restoring "static" routes would not break for the daemons either. But I got a feeling it can hurt more than it helps. > In this case, my software *is* essentially the routing daemon, and I want it to > be simpler to maintain. Well router daemons belongs to "user space" and via netlink you should be able to do most of what you want. Cheers. --ro From owner-netdev@oss.sgi.com Wed Apr 10 16:21:42 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ANLg8d026849 for ; Wed, 10 Apr 2002 16:21:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ANLgxW026848 for netdev-outgoing; Wed, 10 Apr 2002 16:21:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ANLY8d026839 for ; Wed, 10 Apr 2002 16:21:35 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id g3B2Oaq15160; Thu, 11 Apr 2002 02:24:36 GMT Date: Thu, 11 Apr 2002 02:24:36 +0000 (GMT) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Robert Olsson cc: Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: <15540.50303.858294.986710@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 670 Lines: 21 Hello, On Thu, 11 Apr 2002, Robert Olsson wrote: > If we limit us to "static routes" for the other routes we must definitely leave to > some with routing/topologi knowledge and we must not break systems with "routing > daemons". include/linux/rtnetlink.h already contains the needed RTPROT_xxx definitions. The most used daemons don't use RTPROT_STATIC. The kernel does not know that the daemon registers static routes, they all have its own RTPROT_value. The static routes are marked as such only in the daemon's config file. May be it is possible value RTPROT_STATIC to be marked in comments as a kernel property. Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Wed Apr 10 20:34:59 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3B3Yx8d003387 for ; Wed, 10 Apr 2002 20:34:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3B3Ywub003386 for netdev-outgoing; Wed, 10 Apr 2002 20:34:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3B3Yu8d003380 for ; Wed, 10 Apr 2002 20:34:56 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id UAA24735; Wed, 10 Apr 2002 20:28:12 -0700 Date: Wed, 10 Apr 2002 20:28:11 -0700 (PDT) Message-Id: <20020410.202811.103858854.davem@redhat.com> To: rddunlap@osdl.org Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: remove unused kernel_stat fields From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 471 Lines: 13 From: "Randy.Dunlap" Date: Tue, 9 Apr 2002 14:02:30 -0700 (PDT) I can't find any references to these fields in struct kernel_stat. Can they be removed...or is there non-kernel code that needs to have them in the kernel? I don't know if I replied to this already, but I will be applying this patch because: 1) Randy is right, the members are not used anywhere 2) This structure is not exported in any way outside of the kernel. From owner-netdev@oss.sgi.com Thu Apr 11 04:25:15 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BBPF8d015776 for ; Thu, 11 Apr 2002 04:25:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BBPEPl015775 for netdev-outgoing; Thu, 11 Apr 2002 04:25:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BBP98d015771 for ; Thu, 11 Apr 2002 04:25:09 -0700 Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id NAA17665; Thu, 11 Apr 2002 13:29:40 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15541.29604.537736.704406@robur.slu.se> Date: Thu, 11 Apr 2002 13:29:40 +0200 To: Julian Anastasov Cc: Robert Olsson , Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: References: <15540.50303.858294.986710@robur.slu.se> X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1443 Lines: 35 Julian Anastasov writes: > > include/linux/rtnetlink.h already contains the needed RTPROT_xxx > definitions. The most used daemons don't use RTPROT_STATIC. The kernel > does not know that the daemon registers static routes, they all > have its own RTPROT_value. The static routes are marked as such only > in the daemon's config file. May be it is possible value RTPROT_STATIC > to be marked in comments as a kernel property. Hello! There is already RTPROT_KERNEL and proto RTPROT_STATIC is way for the administrator to interact with the routing daemon even if is a you say that this is not currently implemented by all daemons. I have used this with gated. IMHO even static routes implements a routing policy from some administrator view and should therefore by configured, debugged etc. This job has to done somewhere and a userland daemon seems most adequate at least in my eyes. And with the current model the "network" comes up in a clean fashion. I think it easier to just add the needed routes rather to check the old history and deal with this. Probably we need to check is address, netmask changes etc so the old routes will be installed in the same context. A very simple daemon for static routes would do the job we are talking about here and should be easy to configure through config files or just via netlink. And just replace it with zebra/gated/bird when the complexity requires it. Cheers. --ro From owner-netdev@oss.sgi.com Thu Apr 11 04:28:52 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BBSq8d015952 for ; Thu, 11 Apr 2002 04:28:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BBSqtj015951 for netdev-outgoing; Thu, 11 Apr 2002 04:28:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BBSm8d015944 for ; Thu, 11 Apr 2002 04:28:49 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id HAA03107; Thu, 11 Apr 2002 07:29:20 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3BBO6T00666; Thu, 11 Apr 2002 07:24:10 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 11 Apr 2002 07:24:06 -0400 (EDT) From: jamal To: Stefan Rompf cc: Michael Richardson , Subject: Re: Patch: Device operative state notification against 2.5.7 In-Reply-To: <3CB2D065.A3DA60BB@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 848 Lines: 25 On Tue, 9 Apr 2002, Stefan Rompf wrote: > Hi Jamal, > > > [discussion whether IFOP_DOWN_LOWERLAYER should send netlink messages] > > > > I think they should be accessible; whether you send netlink > > advertisements everytime there is some state transition is the question. > > they should. For a routing daemon it is interesting to be notified when > interfaces becomes capable or incapable of handling packets, independant > of the reason. As long as we abstract virtual or subinterfaces as normal > interfaces to the upper layers (which is IMHO the correct decision), > IFOP_DOWN_LOWERLAYER must trigger a notification. Well ... ok. Note, the user space program could maintain state and observe when all the interfaces are down to reach the same conclusion. Ok, Stefan, i think you should be ready to roll some code now ;-> cheers, jamal From owner-netdev@oss.sgi.com Thu Apr 11 04:45:50 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BBjo8d016460 for ; Thu, 11 Apr 2002 04:45:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BBjoPm016459 for netdev-outgoing; Thu, 11 Apr 2002 04:45:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BBjh8d016454 for ; Thu, 11 Apr 2002 04:45:43 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id HAA08062; Thu, 11 Apr 2002 07:46:14 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3BBf4600725; Thu, 11 Apr 2002 07:41:08 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 11 Apr 2002 07:41:04 -0400 (EDT) From: jamal To: Balazs Scheidler cc: Subject: Re: netlink question In-Reply-To: <20020410132025.A8595@balabit.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 625 Lines: 22 On Wed, 10 Apr 2002, Balazs Scheidler wrote: > Hi, > > As I need to communicate between two parts of the kernel (a core TCP part, > and a loaded module), Andi suggested to use netlink for this purpose. > > Since I'm not too familiar with Netlink (and I saw only userspace-kernel > communication using netlink), I'd need some introductory material about > netlink. Is some information about the subject available? Sample code would > be sufficient as well. > Look at notifier_chain_un/register(),un/register_netdevice_notifier(), and their usage. You could also look at the usage of netdev_state_change() cheers, jamal From owner-netdev@oss.sgi.com Thu Apr 11 05:07:57 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BC7u8d018255 for ; Thu, 11 Apr 2002 05:07:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BC7ucn018254 for netdev-outgoing; Thu, 11 Apr 2002 05:07:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BC7l8d018247 for ; Thu, 11 Apr 2002 05:07:49 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.9.3/8.9.3) with ESMTP id PAA09630; Thu, 11 Apr 2002 15:08:23 +0300 Date: Thu, 11 Apr 2002 15:08:23 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@l To: Robert Olsson cc: Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: <15541.29604.537736.704406@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1832 Lines: 47 Hello, On Thu, 11 Apr 2002, Robert Olsson wrote: > There is already RTPROT_KERNEL and proto RTPROT_STATIC is way for the > administrator to interact with the routing daemon even if is a you say > that this is not currently implemented by all daemons. I have used this > with gated. Well, I now see, it is used in gated. But only in one route table which is a drawback. > IMHO even static routes implements a routing policy from some administrator > view and should therefore by configured, debugged etc. This job has to done > somewhere and a userland daemon seems most adequate at least in my eyes. Agreed. Add to this that sometimes many such agents play with the routes but in its own area (different tables, etc) and the things become more complex. I still don't know for daemon that can work with multiple routing tables in Linux, some even don't recognize the preferred source IPs and the ip rules. > And with the current model the "network" comes up in a clean fashion. I think > it easier to just add the needed routes rather to check the old history and > deal with this. Probably we need to check is address, netmask changes etc > so the old routes will be installed in the same context. > > A very simple daemon for static routes would do the job we are talking about > here and should be easy to configure through config files or just via netlink. > And just replace it with zebra/gated/bird when the complexity requires it. More correctly, the settings are more complex than the mentioned daemons can handle. Sticking with one route table is not enough in most of the cases. This is the main reason the mentioned patches for static routes to exist. They are more manageable (with scripts) for setups where routing protocols are not used. > Cheers. > > --ro Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Thu Apr 11 05:23:31 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BCNV8d018635 for ; Thu, 11 Apr 2002 05:23:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BCNVtW018634 for netdev-outgoing; Thu, 11 Apr 2002 05:23:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BCNQ8d018629 for ; Thu, 11 Apr 2002 05:23:26 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA22164; Thu, 11 Apr 2002 08:23:57 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3BCIoJ00831; Thu, 11 Apr 2002 08:18:51 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 11 Apr 2002 08:18:50 -0400 (EDT) From: jamal To: Julian Anastasov cc: Robert Olsson , Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1238 Lines: 34 On Thu, 11 Apr 2002, Julian Anastasov wrote: > > Hello, > > On Thu, 11 Apr 2002, Robert Olsson wrote: > > > There is already RTPROT_KERNEL and proto RTPROT_STATIC is way for the > > administrator to interact with the routing daemon even if is a you say > > that this is not currently implemented by all daemons. I have used this > > with gated. > > Well, I now see, it is used in gated. But only in one route table > which is a drawback. I thought gated was capable of using at least main and local. If i am not mistaken zebra is now capable of using more tables as well. It would probably be actually better policy to enter all static routes in one table. Robert, when you enter a static route from gated, is it registered as proto gated or proto static? While i like Julians patch (adding no complexity, IMO) I see that the functionality could be very easily moved outside the kernel where you could also do a lot more fancy things (very complex decision making example: based on which devs go down, what next multihops to use etc). Unfortunately, it does require extra code in user space. The question is: Would people who need this functionality be not very lazy and actually fetch this code and compile it? ;-> cheers, jamal From owner-netdev@oss.sgi.com Thu Apr 11 05:40:04 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BCe48d019187 for ; Thu, 11 Apr 2002 05:40:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BCe4Qw019185 for netdev-outgoing; Thu, 11 Apr 2002 05:40:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BCdw8d019174 for ; Thu, 11 Apr 2002 05:39:59 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA29238; Thu, 11 Apr 2002 08:40:29 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3BCZMs00900; Thu, 11 Apr 2002 08:35:23 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 11 Apr 2002 08:35:22 -0400 (EDT) From: jamal To: Martin Devera cc: Subject: Re: QoS _put, _get and _delete class ops semantic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1181 Lines: 41 Hi Martin, On Tue, 9 Apr 2002, Martin Devera wrote: > Hi Jamal, > > put and get seem to be simply reference counting on > class object. nod > I'd expect thet class creation will call > get once to assure that it is locked in active state and > "tc class del" would call last put to release this last > reference (and class will destroy itself). actually sequence would be get();delete();put() whenever "tc class del" is invoked (theres other activity that may happen here as well instead of delete(), example attaching filters to class etc). I think what you do with the delete+put combo is specific to your needs though. So for example you could return 0 in get() and your put() code will never be invoked. > Unfortunately there is delete class op which seems to do > almost the same as put. > Do you know rationale behind it ? Why we have both put > and delete and what tc framework expect from qdisc ? Alexey can give a better answer. Typically put() is the backup for delete. Should delete fail to destroy because of reference counts being non-zero, put will catch it. CBQ is an easier scheduler to see this. For a fun one look at the ATM scheduler. cheers, jamal From owner-netdev@oss.sgi.com Thu Apr 11 05:56:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BCuM8d019666 for ; Thu, 11 Apr 2002 05:56:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BCuMK3019665 for netdev-outgoing; Thu, 11 Apr 2002 05:56:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BCuH8d019660 for ; Thu, 11 Apr 2002 05:56:18 -0700 Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id PAA20184; Thu, 11 Apr 2002 15:01:03 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15541.35087.61146.809057@robur.slu.se> Date: Thu, 11 Apr 2002 15:01:03 +0200 To: Julian Anastasov Cc: Robert Olsson , Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: References: <15541.29604.537736.704406@robur.slu.se> X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1022 Lines: 30 Hello! Julian Anastasov writes: > > Well, I now see, it is used in gated. But only in one route table > which is a drawback. gated netlink code came from Alexey. I had to adjust the preference for "static" in gated to get the desired effect. > > More correctly, the settings are more complex than the mentioned > daemons can handle. Sticking with one route table is not enough in most > of the cases. This is the main reason the mentioned patches for static > routes to exist. They are more manageable (with scripts) for setups where > routing protocols are not used. Well we can be happy for the well-designed routing/netlink system Linux got and as you say routing software does not yet fully utilize this. But I think we agree that we shouldn't have kernel to compensate for this. I did some benchmarking/profiling on the routing lookup/cache/garbage collection it seems to be well done too. Having listened to all fuzz about routing lookups at GIGE speeds. :-) Cheers. --ro From owner-netdev@oss.sgi.com Thu Apr 11 05:59:51 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BCxp8d019822 for ; Thu, 11 Apr 2002 05:59:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BCxpmZ019821 for netdev-outgoing; Thu, 11 Apr 2002 05:59:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BCxh8d019817 for ; Thu, 11 Apr 2002 05:59:44 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.9.3/8.9.3) with ESMTP id PAA29370; Thu, 11 Apr 2002 15:58:20 +0300 Date: Thu, 11 Apr 2002 15:58:20 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@l To: jamal cc: Robert Olsson , Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1484 Lines: 48 Hello, On Thu, 11 Apr 2002, jamal wrote: > > Well, I now see, it is used in gated. But only in one route table > > which is a drawback. > > I thought gated was capable of using at least main and local. Looking in the sources, main+default and after patching with one table more > If i am not mistaken zebra is now capable of using more tables as well. Last time I checked it 6 months ago and today I don't see much progress on the web site but you can be right :) > It would probably be actually better policy to enter all static routes in > one table. It is not always possible, all we are using Advanced Linux Networking, though :) > Robert, when you enter a static route from gated, is it registered as > proto gated or proto static? I see that gated uses many protos while Zebra uses small number (one?). Actually, gated can use RTPROT_STATIC for its table. > While i like Julians patch (adding no complexity, IMO) I see that the > functionality could be very easily moved outside the kernel where you > could also do a lot more fancy things (very complex decision making > example: based on which devs go down, what next multihops to use etc). > Unfortunately, it does require extra code in user space. Yes, we can ping indirect nexthops, do layer 7 health checks, alter the nexthops' weights. Usually we don't demand such super job from a routing daemon, the things are mostly "do it yourself" :) > cheers, > jamal Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Thu Apr 11 06:06:51 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BD6p8d020047 for ; Thu, 11 Apr 2002 06:06:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BD6pjC020046 for netdev-outgoing; Thu, 11 Apr 2002 06:06:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BD6h8d020042 for ; Thu, 11 Apr 2002 06:06:45 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.9.3/8.9.3) with ESMTP id QAA31561; Thu, 11 Apr 2002 16:06:58 +0300 Date: Thu, 11 Apr 2002 16:06:58 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@l To: Robert Olsson cc: Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: <15541.35087.61146.809057@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 751 Lines: 28 Hello, On Thu, 11 Apr 2002, Robert Olsson wrote: > Well we can be happy for the well-designed routing/netlink system Linux > got and as you say routing software does not yet fully utilize this. > But I think we agree that we shouldn't have kernel to compensate for this. Agreed. We are not trying to insert routing daemon into kernel :) > I did some benchmarking/profiling on the routing lookup/cache/garbage > collection it seems to be well done too. Having listened to all fuzz > about routing lookups at GIGE speeds. :-) If you use another hash function for the route cache you can even get better :) In my tests with many hosts i got 8% increase in performance. > Cheers. > > --ro Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Thu Apr 11 06:10:25 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BDAO8d020234 for ; Thu, 11 Apr 2002 06:10:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BDAO2u020233 for netdev-outgoing; Thu, 11 Apr 2002 06:10:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BDAK8d020225 for ; Thu, 11 Apr 2002 06:10:20 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id JAA14301; Thu, 11 Apr 2002 09:10:52 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3BD5kb01002; Thu, 11 Apr 2002 09:05:46 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 11 Apr 2002 09:05:46 -0400 (EDT) From: jamal To: Julian Anastasov cc: Robert Olsson , Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 963 Lines: 31 On Thu, 11 Apr 2002, Julian Anastasov wrote: > > Hello, > > > If i am not mistaken zebra is now capable of using more tables as well. > > Last time I checked it 6 months ago and today I don't see > much progress on the web site but you can be right :) > hrm. Maybe its in their commercial version ;-< Note how slow they are in updating it these days. Someone approached me a while back with suggestions to join in forking (and liberate) Zebra from the current (lack of) activity. My answer at the time is to put more effort in Bird probably. > Yes, we can ping indirect nexthops, do layer 7 health checks, > alter the nexthops' weights. Usually we don't demand such super > job from a routing daemon, the things are mostly "do it yourself" :) > My sentiments exactly. Any such beast when written should be policy driven. If i dont need layer 7 health checks as stimulus, then dont use them. Other things would be remote SNMP queries etc. cheers, jamal From owner-netdev@oss.sgi.com Thu Apr 11 07:20:45 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BEKj8d024186 for ; Thu, 11 Apr 2002 07:20:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BEKjl3024185 for netdev-outgoing; Thu, 11 Apr 2002 07:20:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from luxik.cdi.cz (root@inway106.cdi.cz [213.151.81.106]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BEKe8d024181 for ; Thu, 11 Apr 2002 07:20:41 -0700 Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16vepO-0003Of-00; Thu, 11 Apr 2002 15:41:30 +0200 Date: Thu, 11 Apr 2002 15:41:30 +0200 (CEST) From: Martin Devera To: jamal cc: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: QoS _put, _get and _delete class ops semantic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 979 Lines: 27 > > Unfortunately there is delete class op which seems to do > > almost the same as put. > > Do you know rationale behind it ? Why we have both put > > and delete and what tc framework expect from qdisc ? > > Alexey can give a better answer. probably he could step in here ;) > Typically put() is the backup for delete. Should delete fail > to destroy because of reference counts being non-zero, put will catch it. So that if I understand it correctly: delete can only assure that class is "invisible" from now to subsequent gets/walks and other uses and leave actual destroy to the last put. Do you think that it is reasonable ? > CBQ is an easier scheduler to see this. For a fun one look at the ATM > scheduler. I looked at them but I hate to blindly copy-n-paste code without in-depth knowledge of interface's expectation. Especially when yesterday (after year of flawless operation) someone made my code oops during class deletion under high load ;-\ thanks, Martin From owner-netdev@oss.sgi.com Thu Apr 11 07:47:52 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BElq8d025276 for ; Thu, 11 Apr 2002 07:47:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BElqwX025275 for netdev-outgoing; Thu, 11 Apr 2002 07:47:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BElm8d025271 for ; Thu, 11 Apr 2002 07:47:48 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id KAA07863; Thu, 11 Apr 2002 10:48:08 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3BEguC01387; Thu, 11 Apr 2002 10:42:57 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 11 Apr 2002 10:42:56 -0400 (EDT) From: jamal To: Martin Devera cc: , Subject: Re: QoS _put, _get and _delete class ops semantic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 745 Lines: 23 On Thu, 11 Apr 2002, Martin Devera wrote: > > Typically put() is the backup for delete. Should delete fail > > to destroy because of reference counts being non-zero, put will catch it. > > So that if I understand it correctly: delete can only assure > that class is "invisible" from now to subsequent gets/walks > and other uses and leave actual destroy to the last put. > Do you think that it is reasonable ? > sort of. If you look at the ATM scheduler, you should see the refcount maybe incremented twice. In this case, delete will fail to destroy the class but put() will catch it. If you only increment/decrement then delete should always catch it. In which case you dont need to destroy in put(). Your mileage may vary. cheers, jamal From owner-netdev@oss.sgi.com Thu Apr 11 07:48:46 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BEmk8d025402 for ; Thu, 11 Apr 2002 07:48:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BEmjDV025401 for netdev-outgoing; Thu, 11 Apr 2002 07:48:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BEmg8d025388 for ; Thu, 11 Apr 2002 07:48:43 -0700 Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id QAA22301; Thu, 11 Apr 2002 16:53:29 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15541.41833.773161.740744@robur.slu.se> Date: Thu, 11 Apr 2002 16:53:29 +0200 To: Julian Anastasov Cc: Robert Olsson , Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: References: <15541.35087.61146.809057@robur.slu.se> X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 269 Lines: 14 Julian Anastasov writes: > If you use another hash function for the route cache you can > even get better :) In my tests with many hosts i got 8% increase in > performance. Interesting. At what rate of new connections/s did you test? Cheers . --ro From owner-netdev@oss.sgi.com Thu Apr 11 08:25:00 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BFP08d027442 for ; Thu, 11 Apr 2002 08:25:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BFP0ZA027441 for netdev-outgoing; Thu, 11 Apr 2002 08:25:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BFOm8d027436 for ; Thu, 11 Apr 2002 08:24:51 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.9.3/8.9.3) with ESMTP id SAA30216; Thu, 11 Apr 2002 18:24:51 +0300 Date: Thu, 11 Apr 2002 18:24:51 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@l To: Robert Olsson cc: Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: <15541.41833.773161.740744@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1314 Lines: 53 Hello, On Thu, 11 Apr 2002, Robert Olsson wrote: > > If you use another hash function for the route cache you can > > even get better :) In my tests with many hosts i got 8% increase in > > performance. > > Interesting. At what rate of new connections/s did you test? It was on 100mbit, I already don't remember the exact tests and number of clients, etc. The patch is archived ..., here it is. You can try it yourself: --- net/ipv4/route.c.orig Wed Jun 6 17:51:49 2001 +++ net/ipv4/route.c Wed Jun 6 18:25:45 2001 @@ -203,11 +203,9 @@ static __inline__ unsigned rt_hash_code(u32 daddr, u32 saddr, u8 tos) { - unsigned hash = ((daddr & 0xF0F0F0F0) >> 4) | - ((daddr & 0x0F0F0F0F) << 4); - hash ^= saddr ^ tos; - hash ^= (hash >> 16); - return (hash ^ (hash >> 8)) & rt_hash_mask; + unsigned hash = (saddr + daddr + tos); + hash = ntohl(hash) * 2654435761UL; + return hash & rt_hash_mask; } static int rt_cache_get_info(char *buffer, char **start, off_t offset, I'm using attacking program with configurable number of client IPs: http://www.linuxvirtualserver.org/~julian/#testlvs Sorry that it does not have flood rate limits, use QoS in the flooding host :) You can try the patch with different tools, of course. > Cheers . > > --ro Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Thu Apr 11 09:00:35 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BG0Z8d030429 for ; Thu, 11 Apr 2002 09:00:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BG0ZiH030428 for netdev-outgoing; Thu, 11 Apr 2002 09:00:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3BG0U8d030424 for ; Thu, 11 Apr 2002 09:00:32 -0700 Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id SAA23432; Thu, 11 Apr 2002 18:05:19 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15541.46143.3860.62384@robur.slu.se> Date: Thu, 11 Apr 2002 18:05:19 +0200 To: Julian Anastasov Cc: Robert Olsson , Chris Friesen , Subject: Re: suggestion for routing code improvement In-Reply-To: References: <15541.41833.773161.740744@robur.slu.se> X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 766 Lines: 24 Julian Anastasov writes: > > Interesting. At what rate of new connections/s did you test? > > It was on 100mbit, I already don't remember the exact tests > and number of clients, etc. The patch is archived ..., here it is. > You can try it yourself: > http://www.linuxvirtualserver.org/~julian/#testlvs > > Sorry that it does not have flood rate limits, use QoS in > the flooding host :) You can try the patch with different tools, > of course. Very intesting. Well seems like I don't get out of the lab until the snow comes.... We're testing GIGE switches now. With one Linux box with five e1000 we can put a background load of almost 5 Gbit/s into the switch. And check latencies through other pair of switch ports. Cheers. --ro From owner-netdev@oss.sgi.com Fri Apr 12 03:11:42 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CABg8d004720 for ; Fri, 12 Apr 2002 03:11:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CABg1w004719 for netdev-outgoing; Fri, 12 Apr 2002 03:11:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CABd8d004716 for ; Fri, 12 Apr 2002 03:11:40 -0700 Received: from barkeeper.isg.de (barkeeper.is-asp.com [192.168.5.46]) by mail.isg.de (Postfix) with ESMTP id C9E0593645D; Fri, 12 Apr 2002 12:12:04 +0200 (CEST) Received: from isg.de (localhost.localdomain [127.0.0.1]) by barkeeper.isg.de (8.9.3/8.9.3) with ESMTP id MAA00978; Fri, 12 Apr 2002 12:12:04 +0200 Message-ID: <3CB6B2F4.ED9875FB@isg.de> Date: Fri, 12 Apr 2002 12:12:04 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: jamal Cc: netdev@oss.sgi.com Subject: Re: Patch: Device operative state notification against 2.5.7 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 219 Lines: 8 Hi Jamal, > Ok, Stefan, i think you should be ready to roll some code now ;-> indeed. It will take a couple of days as I'm not motivated to sit another four hours before the computer every evening ;-) Cheers, Stefan From owner-netdev@oss.sgi.com Sat Apr 13 01:44:00 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3D8i08d009137 for ; Sat, 13 Apr 2002 01:44:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3D8i073009136 for netdev-outgoing; Sat, 13 Apr 2002 01:44:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3D8hr8d009132 for ; Sat, 13 Apr 2002 01:43:55 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id LAA17142 for ; Sat, 13 Apr 2002 11:44:32 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma017136; Sat, 13 Apr 02 11:44:09 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.10.2+Sun/8.11.0) with ESMTP id g3D8i8h14898; Sat, 13 Apr 2002 11:44:08 +0300 (EEST) Received: (from ajtuomin@localhost) by morphine.tml.hut.fi (8.10.2+Sun/8.10.2) id g3D8hr817808; Sat, 13 Apr 2002 11:43:53 +0300 (EEST) From: Antti Tuominen Message-Id: <200204130843.g3D8hr817808@morphine.tml.hut.fi> Subject: ANN: MIPL Mobile IPv6 for Linux 0.9.2 Released To: netdev@oss.sgi.com (Netdev Mailing List), linux-kernel@vger.kernel.org (Linux-kernel Mailing List), usagi-users@linux-ipv6.org (USAGI Users Mailing List) Date: Sat, 13 Apr 2002 11:43:53 +0300 (EEST) X-Mailer: ELM [version 2.4ME+ PL49 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1603 Lines: 39 Hello all! MIPL Mobile IPv6 for Linux is an implementation of the IETF mobile-ip working group draft Mobility Support in IPv6. Project goal is to create a high quality implementation of Mobile IPv6 for inclusion in the mainline Linux kernel tree. Version 0.9.2 is the 7th public release. It complies with the Mobile IPv6 draft revision 15. MIPL implementation includes all three MIPv6 entities Correspondent Node, Mobile Node and Home Agent. Release includes a kernel patch and a set of user tools and scripts. A group of four persons at Helsinki University of Technology's Telecommunications Software and Multimedia Laboratory make up the core development team. MIPL has a solid user base and receives contributions from all over the world. MIPL has been tested in several interoperability and conformance testing events with excellent results. * ETSI IPv6 Bake-off 2000, Sophia Antipolis, France. * Connectathon 2001, San Jose, California, US. * ETSI IPv6 Plugtest 2001, Cannes, France. * Connectathon 2002, San Jose, California, US. Interoperability has been successfully tested with all major Mobile IPv6 vendors. Conformance test suites used include Ericsson Telebit, TAHI, UNH, and ENST/IRISA. MIPL is widely considered the most complete and up-to-date Mobile IPv6 implementation in the world. To download the source code or to read more about MIPL Mobile IPv6 for Linux, see our web site http://www.mipl.mediapoli.com/. You can also just download the latest release at the following URL: http://www.mipl.mediapoli.com/download/mipv6-0.9.2-v2.4.18.tar.gz Best regards, Antti From owner-netdev@oss.sgi.com Sun Apr 14 10:50:54 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EHos8d008481 for ; Sun, 14 Apr 2002 10:50:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EHoso2008480 for netdev-outgoing; Sun, 14 Apr 2002 10:50:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from nyc285ex01.nyc.corp.yr.com (ynrfw28501.yr.com [12.39.241.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EHoX8d008473 for ; Sun, 14 Apr 2002 10:50:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: dst cache overflow 2.2.x; x>=16 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 14 Apr 2002 13:51:16 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dst cache overflow 2.2.x; x>=16 Thread-Index: AcHj3PXkyfkHrNSZQ+eVUFgtMtGwOg== From: "Milam, Chad" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3EHod8d008475 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4219 Lines: 136 First, I apologise for the cross post. I sent this to the lkml, and several people said I should post it here as well..... I have been looking into a problem on a couple of linux routers that I have. All of them are used for routing between the private network and the Internet. Some run Check Point VPN-1 v4.1 SP5, some do not. The problem is that after about 22 hours, they all have "dst cache overflow", which is quite easily traced back to net/ipv4/route.c rt_garbage_collect(). rt_garbage_collect appears to be called or initiated from two places 1) the dst_ops structure 2) rt_intern_hash. Based on my testing here is what I have come up with.... dst_ops.entries is not being set appropriately (or at least not what I would expect it to be). I determined this by changing dst_ops->gc to point to a new function (rt_display_tot) for debugging, as well as had rt_intern_hash() call this function instead of rt_garbage_collect(). The sole purpose of this function was to loop through all hash chains and count up the entries that should be valid, do a printk("%d %d", count, dst_ops.entries), then return(rt_garbage_collect()). The result was, that when rt_garbage_collect() returned 1 (dst cache overflow), the number of entries reported by dst_ops.entries was far different than the number reported by my loop/counter. Upon further investigation in to rt_free(), __dst_free(), and dst_destroy(), I found that only dst_destroy() decrements dst_ops.entries. Furthermore, when dst_ops->gc returns 1, dst_alloc() will not create an entry, appropriately so, the box is at a stand still. So... For the interim, I have create a small patch that purges the dst cache table, and resets dst_ops.entries to 0 anytime rt_garbage_collect() returns 1. The result... The box stays up, and hums along quite happily. I would appreciate any comments with regards to this matter. I have also included a copy of the patch that I created to work around the issue. Thanks, Chad diff -urNp linux-2.2.16cwm/net/ipv4/route.c linux-2.2.16cwm/net/ipv4/route.c -n- linux-2.2.16/net/ipv4/route.c Tue Jan 4 13:12:26 2000 +++ linux-2.2.16cwm/net/ipv4/route.c Tue Apr 9 15:14:12 2002 @@ -96,7 +96,7 @@ #define IP_MAX_MTU 0xFFF0 -#define RT_GC_TIMEOUT (300*HZ) +#define RT_GC_TIMEOUT (120*HZ) int ip_rt_min_delay = 2*HZ; int ip_rt_max_delay = 10*HZ; @@ -134,7 +134,8 @@ static struct dst_entry * ipv4_dst_rerou static struct dst_entry * ipv4_negative_advice(struct dst_entry *); static void ipv4_link_failure(struct sk_buff *skb); static int rt_garbage_collect(void); - +static int rt_delete_now(void); +static int rt_garbage_ctl(void); struct dst_ops ipv4_dst_ops = { @@ -142,7 +143,7 @@ struct dst_ops ipv4_dst_ops = __constant_htons(ETH_P_IP), RT_HASH_DIVISOR, - rt_garbage_collect, + rt_garbage_ctl, ipv4_dst_check, ipv4_dst_reroute, NULL, @@ -508,8 +509,7 @@ static int rt_garbage_collect(void) if (atomic_read(&ipv4_dst_ops.entries) < ip_rt_max_size) return 0; - if (net_ratelimit()) - printk("dst cache overflow\n"); + return 1; work_done: @@ -570,7 +570,7 @@ restart: int saved_int = ip_rt_gc_min_interval; ip_rt_gc_elasticity = 1; ip_rt_gc_min_interval = 0; - rt_garbage_collect(); + rt_garbage_ctl(); ip_rt_gc_min_interval = saved_int; ip_rt_gc_elasticity = saved_elasticity; goto restart; @@ -2045,4 +2045,44 @@ __initfunc(void ip_rt_init(void)) ent->read_proc = ip_rt_acct_read; #endif #endif +} + +static int rt_delete_now(void){ + struct rtable *rth, **rthp; + int i,ent1,ent2,c; + + i=0; + ent1=0; + ent2=0; + c=0; + + ent1=atomic_read(&ipv4_dst_ops.entries); + start_bh_atomic(); + while(iu.rt_next; + rth->u.rt_next=NULL; + c+=1; + rt_free(rth); + } + i++; + } + + atomic_set(&ipv4_dst_ops.entries,0); + end_bh_atomic(); + ent2=atomic_read(&ipv4_dst_ops.entries); + + if(net_ratelimit()){ + printk("dst cache overflow\n"); + printk("rt_delete_now(); s:%d e:%d t:%d\n",ent1,ent2,c); + } + + return 0; +} + +static int rt_garbage_ctl(void){ + if(rt_garbage_collect()) + rt_delete_now(); + return 0; } From owner-netdev@oss.sgi.com Sun Apr 14 12:44:02 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EJi28d011644 for ; Sun, 14 Apr 2002 12:44:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EJi2su011643 for netdev-outgoing; Sun, 14 Apr 2002 12:44:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EJhx8d011637 for ; Sun, 14 Apr 2002 12:43:59 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id PAA11851; Sun, 14 Apr 2002 15:44:45 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3EJdbV13049; Sun, 14 Apr 2002 15:39:37 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 14 Apr 2002 15:39:36 -0400 (EDT) From: jamal To: "Milam, Chad" cc: Subject: Re: dst cache overflow 2.2.x; x>=16 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 232 Lines: 13 Hi, Why couldnt you just modify the parameters in /proc? -Increase the overflow threshold (you actually hardcode this) /proc/sys/net/ipv4/route/gc_thresh -decrease the gc timer /proc/sys/net/ipv4/route/gc_timeout cheers, jamal From owner-netdev@oss.sgi.com Sun Apr 14 12:48:04 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EJm48d011862 for ; Sun, 14 Apr 2002 12:48:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EJm4Ja011861 for netdev-outgoing; Sun, 14 Apr 2002 12:48:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EJm18d011858 for ; Sun, 14 Apr 2002 12:48:01 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id PAA12980; Sun, 14 Apr 2002 15:48:47 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3EJhcb13060; Sun, 14 Apr 2002 15:43:38 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 14 Apr 2002 15:43:38 -0400 (EDT) From: jamal To: "Milam, Chad" cc: Subject: Re: dst cache overflow 2.2.x; x>=16 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 355 Lines: 20 On Sun, 14 Apr 2002, jamal wrote: > > Hi, > > Why couldnt you just modify the parameters in /proc? > > -Increase the overflow threshold (you actually hardcode this) > /proc/sys/net/ipv4/route/gc_thresh > -decrease the gc timer > /proc/sys/net/ipv4/route/gc_timeout Sorry, you hardcoded /proc/sys/net/ipv4/route/gc_timeout to 120 secs. cheers, jamal From owner-netdev@oss.sgi.com Sun Apr 14 12:53:42 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EJrg8d012115 for ; Sun, 14 Apr 2002 12:53:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EJrgqb012114 for netdev-outgoing; Sun, 14 Apr 2002 12:53:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from nyc285ex01.nyc.corp.yr.com (ynrfw28501.yr.com [12.39.241.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EJrb8d012107 for ; Sun, 14 Apr 2002 12:53:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: dst cache overflow 2.2.x; x>=16 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 14 Apr 2002 15:54:21 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: dst cache overflow 2.2.x; x>=16 Thread-Index: AcHj7Z7TGTr2Y+u5R8mKek5CyPSPMAAABiRQ From: "Milam, Chad" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3EJrc8d012108 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 998 Lines: 38 I lowered the timeout to make gc more agressive. Though, it can still be adjusted via a /proc entry. Default was 300. Increasing the other parameters that you specified (which I have done) only delays the inevitable "dst cache overflow". The problem is that gc (rather rt_free) is not decrementing .entries. So it _thinks_ the table has overflown. chad > -----Original Message----- > From: owner-netdev@oss.sgi.com@YRINC On Behalf Of jamal > Sent: Sunday, April 14, 2002 3:44 PM > To: Milam, Chad > Cc: netdev@oss.sgi.com > Subject: Re: dst cache overflow 2.2.x; x>=16 > > > > On Sun, 14 Apr 2002, jamal wrote: > > > > > Hi, > > > > Why couldnt you just modify the parameters in /proc? > > > > -Increase the overflow threshold (you actually hardcode this) > > /proc/sys/net/ipv4/route/gc_thresh > > -decrease the gc timer > > /proc/sys/net/ipv4/route/gc_timeout > > Sorry, you hardcoded /proc/sys/net/ipv4/route/gc_timeout > to 120 secs. > > cheers, > jamal > From owner-netdev@oss.sgi.com Sun Apr 14 13:09:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EK9J8d012668 for ; Sun, 14 Apr 2002 13:09:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EK9J4A012667 for netdev-outgoing; Sun, 14 Apr 2002 13:09:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EK9E8d012663 for ; Sun, 14 Apr 2002 13:09:14 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA18483; Sun, 14 Apr 2002 16:10:00 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3EK4pO13129; Sun, 14 Apr 2002 16:04:51 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 14 Apr 2002 16:04:50 -0400 (EDT) From: jamal To: "Milam, Chad" cc: Subject: RE: dst cache overflow 2.2.x; x>=16 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1025 Lines: 29 On Sun, 14 Apr 2002, Milam, Chad wrote: > I lowered the timeout to make gc more agressive. Though, it can still > be adjusted via a /proc entry. Default was 300. Increasing the other > parameters that you specified (which I have done) only delays the > inevitable "dst cache overflow". The problem is that gc (rather > rt_free) is not decrementing .entries. So it _thinks_ the table > has overflown. > Overflow will only happen if /proc/sys/net/ipv4/route/gc_thresh is exceeded. A default of 512 aint that big. What is the average number of entries you are seeing? What kind of data do you get from running rtstat? Increment the size of /proc/sys/net/ipv4/route/gc_thresh to a higher number matching your avg entries; Garbage collection aint that cheap: so safer to just make the size larger instead of invoking it more frequently -- RAM is cheap. Note also that garbage collection will run every /proc/sys/net/ipv4/route/gc_min_interval time expiry regardless of how you big your max threshold is. cheers, jamal From owner-netdev@oss.sgi.com Sun Apr 14 13:25:14 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EKPE8d013194 for ; Sun, 14 Apr 2002 13:25:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EKPEn0013193 for netdev-outgoing; Sun, 14 Apr 2002 13:25:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from nyc285ex01.nyc.corp.yr.com (ynrfw28501.yr.com [12.39.241.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EKP88d013188 for ; Sun, 14 Apr 2002 13:25:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: dst cache overflow 2.2.x; x>=16 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 14 Apr 2002 16:25:52 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: dst cache overflow 2.2.x; x>=16 Thread-Index: AcHj8GElVQNhF+9YQHiP/B9opsREpQAANc9A From: "Milam, Chad" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3EKP98d013190 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1602 Lines: 47 > On Sun, 14 Apr 2002, Milam, Chad wrote: > > > I lowered the timeout to make gc more agressive. Though, it can still > > be adjusted via a /proc entry. Default was 300. Increasing the other > > parameters that you specified (which I have done) only delays the > > inevitable "dst cache overflow". The problem is that gc (rather > > rt_free) is not decrementing .entries. So it _thinks_ the table > > has overflown. > > > > Overflow will only happen if /proc/sys/net/ipv4/route/gc_thresh > is exceeded. A default of 512 aint that big. What is the average number > of entries you are seeing? > What kind of data do you get from running rtstat? > Increment the size of /proc/sys/net/ipv4/route/gc_thresh to a higher > number matching your avg entries; > > Garbage collection aint that cheap: so safer to just make the size > larger instead of invoking it more frequently -- RAM is cheap. Note also > that garbage collection will run every > /proc/sys/net/ipv4/route/gc_min_interval time expiry regardless of how > you big your max threshold is. > > cheers, > jamal Actually changing the timer to 120*HZ was not supposed to end up in the patch, I pulled it out of there, but managed to leave it in the diff for the email. /proc/sys/net/ipv4/route/gc_min_interval = 1 /proc/sys/net/ipv4/route/max_size=16384 (default 4096) Also, based on the code from route.c: -- if (atomic_read(&ipv4_dst_ops.entries) < ip_rt_max_size) return 0; if (net_ratelimit()) printk("dst cache overflow\n"); return 1; -- Looks to me like gc_thresh has nothing to do with it. Did I read that wrong? chad From owner-netdev@oss.sgi.com Sun Apr 14 13:36:48 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EKal8d013633 for ; Sun, 14 Apr 2002 13:36:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EKalLp013631 for netdev-outgoing; Sun, 14 Apr 2002 13:36:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EKah8d013628 for ; Sun, 14 Apr 2002 13:36:43 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA25680; Sun, 14 Apr 2002 16:37:30 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3EKWKW13173; Sun, 14 Apr 2002 16:32:20 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 14 Apr 2002 16:32:20 -0400 (EDT) From: jamal To: "Milam, Chad" cc: Subject: RE: dst cache overflow 2.2.x; x>=16 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 626 Lines: 31 On Sun, 14 Apr 2002, Milam, Chad wrote: > /proc/sys/net/ipv4/route/max_size=16384 (default 4096) Ok, i meant: /proc/sys/net/ipv4/route/gc_thresh > Also, based on the code from route.c: > -- > if (atomic_read(&ipv4_dst_ops.entries) < ip_rt_max_size) > return 0; > if (net_ratelimit()) > printk("dst cache overflow\n"); > return 1; > -- > 0 typically means the gc was succesful > Looks to me like gc_thresh has nothing to do with it. Did I read that wrong? > I just remembered an old problem that used to cause this; do you have lo configured? make sure it is IP address 127.0.0.1 and it is up. cheers, jamal From owner-netdev@oss.sgi.com Sun Apr 14 13:42:53 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EKgr8d013901 for ; Sun, 14 Apr 2002 13:42:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EKgrBv013900 for netdev-outgoing; Sun, 14 Apr 2002 13:42:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EKgo8d013896 for ; Sun, 14 Apr 2002 13:42:50 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA27266; Sun, 14 Apr 2002 16:43:37 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3EKcRF13186; Sun, 14 Apr 2002 16:38:27 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 14 Apr 2002 16:38:27 -0400 (EDT) From: jamal To: "Milam, Chad" cc: Subject: RE: dst cache overflow 2.2.x; x>=16 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 264 Lines: 16 On Sun, 14 Apr 2002, jamal wrote: > > /proc/sys/net/ipv4/route/max_size=16384 (default 4096) > > Ok, i meant: > /proc/sys/net/ipv4/route/gc_thresh > Sorry, you are right, the correct value is written/read from /proc/sys/net/ipv4/route/max_size cheers, jamal From owner-netdev@oss.sgi.com Sun Apr 14 13:43:28 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EKhS8d013980 for ; Sun, 14 Apr 2002 13:43:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EKhSxZ013979 for netdev-outgoing; Sun, 14 Apr 2002 13:43:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from nyc285ex01.nyc.corp.yr.com (ynrfw28501.yr.com [12.39.241.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EKhM8d013964 for ; Sun, 14 Apr 2002 13:43:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: dst cache overflow 2.2.x; x>=16 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 14 Apr 2002 16:44:06 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: dst cache overflow 2.2.x; x>=16 Thread-Index: AcHj9DibeHYOdMsITH+G5KCUYEjj8QAACd9Q From: "Milam, Chad" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3EKhN8d013965 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 938 Lines: 37 > On Sun, 14 Apr 2002, Milam, Chad wrote: > > > /proc/sys/net/ipv4/route/max_size=16384 (default 4096) > > Ok, i meant: > /proc/sys/net/ipv4/route/gc_thresh it also looks like gc_thresh defaults to RT_HASH_DIVISOR (256). however I have.... /proc/sys/net/ipv4/route/gc_thresh=2048 > > Also, based on the code from route.c: > > -- > > if (atomic_read(&ipv4_dst_ops.entries) < ip_rt_max_size) > > return 0; > > if (net_ratelimit()) > > printk("dst cache overflow\n"); > > return 1; > > -- > > > > 0 typically means the gc was succesful true enough. but the way I read that is that if entries>max_size, you are going to get "dst cache overflow" which returns a 1. there is no test here for entries>gc_thresh. > I just remembered an old problem that used to cause this; do you > have lo configured? > make sure it is IP address 127.0.0.1 and it is up. sure do. read about that issue quite sometime ago. thanks again, chad From owner-netdev@oss.sgi.com Sun Apr 14 13:57:58 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EKvw8d014546 for ; Sun, 14 Apr 2002 13:57:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EKvvav014545 for netdev-outgoing; Sun, 14 Apr 2002 13:57:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EKvs8d014540 for ; Sun, 14 Apr 2002 13:57:54 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA01131; Sun, 14 Apr 2002 16:58:40 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3EKrV013225; Sun, 14 Apr 2002 16:53:31 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 14 Apr 2002 16:53:30 -0400 (EDT) From: jamal To: "Milam, Chad" cc: Subject: RE: dst cache overflow 2.2.x; x>=16 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 577 Lines: 23 If i summarize your problem is that you are building up dst caches faster than they can be garbage collected. Solution 1. Make the max size large enough to catchup with rate 2. Make sure that every time you go into garbage collection you are successful. - reducing the min interval to 1 might be a little aggressive. But you can tune this later - You wanna make sure you get a large positive "goal" every time play with ip_rt_gc_elasticity (/proc/sys/net/ipv4/route/gc_elasticity) also the rt_hash_log All the above are configurable via /proc have to run cheers, jamal From owner-netdev@oss.sgi.com Sun Apr 14 14:33:57 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ELXv8d015546 for ; Sun, 14 Apr 2002 14:33:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ELXv5o015545 for netdev-outgoing; Sun, 14 Apr 2002 14:33:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ELXm8d015539 for ; Sun, 14 Apr 2002 14:33:49 -0700 Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id XAA07235; Sun, 14 Apr 2002 23:38:30 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15545.63190.565448.189570@robur.slu.se> Date: Sun, 14 Apr 2002 23:38:30 +0200 To: "Milam, Chad" Cc: jamal , Subject: RE: dst cache overflow 2.2.x; x>=16 In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2451 Lines: 66 jamal writes: > > > > If i summarize your problem is that you are building up > dst caches faster than they can be garbage collected. > > Solution > 1. Make the max size large enough to catchup with rate > 2. Make sure that every time you go into garbage collection you are > successful. > - reducing the min interval to 1 might be a little aggressive. > But you can tune this later > - You wanna make sure you get a large positive "goal" every time > play with ip_rt_gc_elasticity (/proc/sys/net/ipv4/route/gc_elasticity) > also the rt_hash_log > > All the above are configurable via /proc > > have to run And in in 2.4.X the GC is done more dynamically around an "equilibrium point". Alexey warned about 2.2 code... Snaphot from Linux router. 2.4.10 cat /proc/sys/net/ipv4/route/max_size 65536 rtstat size IN: hit tot mc no_rt bcast madst masrc OUT: hit tot mc 9861 24721 131 0 1 0 0 0 2 1 0 10119 25044 128 0 0 0 0 0 2 0 0 2514 24125 1293 2 0 0 0 0 1 2 0 3654 24315 591 2 1 1 0 0 0 2 1 4441 25170 387 0 2 0 0 0 1 3 0 5060 25000 304 2 1 0 0 0 0 2 0 5532 25627 230 2 0 0 0 0 0 2 0 5947 25754 242 2 0 0 0 0 1 3 0 6379 25602 211 0 1 0 0 0 2 3 0 6371 25523 235 0 0 0 0 0 1 1 0 6752 24251 187 1 0 0 0 0 0 1 0 7077 25310 160 0 0 0 0 0 1 1 0 6851 24608 222 2 1 0 0 0 1 3 0 7256 25313 199 1 0 0 0 0 1 2 0 7086 24656 174 0 0 0 0 0 0 1 0 7459 24070 180 3 1 0 0 0 1 2 0 2434 23844 1340 7 1 0 0 0 1 3 0 1:st ipv4_dst_ops.entries. (You see GC happen) 2:nd: Warm cache hits -> approx aggregated packet/sec. 3:rd: Cache misses -> approx connections/sec. Cheers. --ro From owner-netdev@oss.sgi.com Mon Apr 15 08:20:29 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FFKS8d028493 for ; Mon, 15 Apr 2002 08:20:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FFKSR6028492 for netdev-outgoing; Mon, 15 Apr 2002 08:20:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from nyc285ex01.nyc.corp.yr.com (ynrfw28501.yr.com [12.39.241.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FFKL8d028480 for ; Mon, 15 Apr 2002 08:20:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: dst cache overflow 2.2.x; x>=16 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 15 Apr 2002 11:21:07 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: dst cache overflow 2.2.x; x>=16 Thread-Index: AcHj/G37yVRrA5zoRxKm3tZH7XrHKQAkvxIw From: "Milam, Chad" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3FFKM8d028483 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2121 Lines: 54 Robert Olson writes: > jamal writes: > > > > If i summarize your problem is that you are building up > > dst caches faster than they can be garbage collected. > > > > Solution > > 1. Make the max size large enough to catchup with rate > > 2. Make sure that every time you go into garbage collection you are > > successful. > > - reducing the min interval to 1 might be a little aggressive. > > But you can tune this later > > - You wanna make sure you get a large positive "goal" every time > > play with ip_rt_gc_elasticity (/proc/sys/net/ipv4/route/gc_elasticity) > > also the rt_hash_log > > > > All the above are configurable via /proc > > > > have to run > > And in in 2.4.X the GC is done more dynamically around an "equilibrium point". > Alexey warned about 2.2 code... > > Snaphot from Linux router. 2.4.10 > > cat /proc/sys/net/ipv4/route/max_size > 65536 > > rtstat > size IN: hit tot mc no_rt bcast madst masrc OUT: hit tot mc > > 1:st ipv4_dst_ops.entries. (You see GC happen) > 2:nd: Warm cache hits -> approx aggregated packet/sec. > 3:rd: Cache misses -> approx connections/sec. unfortunately I cannot move my Check Point boxes to 2.4.x yet. Maybe this will come in the future. At the end of the day, my patch was not trying to avoid GC, or eliminate it. It was just there to keep the box from going completely dead... it accomplishes exactly that. I have run it now for about a week, and the box has not had to be restarted, where as with out it, I would have restarted once per day. Even with route/max_size set to 65536, I had to restart about every two weeks. I am also not suggesting that GC does not work, it does (for the most part). What I am trying to say is that there is a condition (still working on that bit) that keeps the .entries counter from decreasing to what it should be. Something, some process, is leaking routes (at least into the counter). This is where my problem is. And the patch works around that, by setting the cache to zero, and starting over. Which, again, is better than restarting. Thanks again, chad From owner-netdev@oss.sgi.com Mon Apr 15 10:57:55 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FHvs8d004939 for ; Mon, 15 Apr 2002 10:57:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FHvs0b004938 for netdev-outgoing; Mon, 15 Apr 2002 10:57:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FHvp8d004933 for ; Mon, 15 Apr 2002 10:57:52 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id NAA29885; Mon, 15 Apr 2002 13:58:39 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3FHrTK16902; Mon, 15 Apr 2002 13:53:29 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 15 Apr 2002 13:53:29 -0400 (EDT) From: jamal To: "Milam, Chad" cc: Subject: RE: dst cache overflow 2.2.x; x>=16 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 597 Lines: 20 On Mon, 15 Apr 2002, Milam, Chad wrote: > At the end of the day, my patch was not trying to avoid GC, or eliminate > it. It was just > there to keep the box from going completely dead... I dont think yourt patch guarantees this (you are nuking routes that may still be actively used) -- i think you may have been lucky so far. Regardless, this seems to be an interesting case of fixing what appears to be a application bug with a kernel patch. Its amazing what you can do when you have source. cheers, jamal PS:- the fact that you are running 2.2 is useful information that you left out. From owner-netdev@oss.sgi.com Mon Apr 15 11:09:24 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FI9O8d005682 for ; Mon, 15 Apr 2002 11:09:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FI9OIC005678 for netdev-outgoing; Mon, 15 Apr 2002 11:09:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from nyc285ex01.nyc.corp.yr.com (ynrfw28501.yr.com [12.39.241.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FI9J8d005674 for ; Mon, 15 Apr 2002 11:09:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: dst cache overflow 2.2.x; x>=16 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 15 Apr 2002 14:10:06 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: dst cache overflow 2.2.x; x>=16 Thread-Index: AcHkp0CJlhwcleGVR7GNuV2QchxxrQAACWNQ From: "Milam, Chad" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3FI9K8d005675 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1214 Lines: 34 jamal writes: > On Mon, 15 Apr 2002, Milam, Chad wrote: > > > At the end of the day, my patch was not trying to avoid GC, or eliminate > > it. It was just > > there to keep the box from going completely dead... > > I dont think yourt patch guarantees this (you are nuking routes that > may still be actively used) -- i think you may have been lucky so far. > Regardless, this seems to be an interesting case of fixing what appears > to be a application bug with a kernel patch. Its amazing what you can do > when you have source. > > cheers, > jamal > > PS:- the fact that you are running 2.2 is useful information that > you left out. > the fact that i am using 2.2 is stated in the subject line. i did neglect to put it explicitly put it in the message (sorry). it is, however, also diff/patch file. I also do not think that nuking valid routes in the cache will produce any major issues, other than slowing things down for a few seconds. the cache is just the cache, not the real route table. and yes, it pretty much guarantees the route cache will be purged, therefore avoiding a reboot and avoiding a quickly repeated overflow... and yes, having the source makes things much easier. :) chad From owner-netdev@oss.sgi.com Mon Apr 15 11:30:36 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FIUa8d007277 for ; Mon, 15 Apr 2002 11:30:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FIUaw3007276 for netdev-outgoing; Mon, 15 Apr 2002 11:30:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FIUS8d007267 for ; Mon, 15 Apr 2002 11:30:30 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.9.3/8.9.3) with ESMTP id VAA22176; Mon, 15 Apr 2002 21:31:21 +0300 Date: Mon, 15 Apr 2002 21:31:21 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@l To: "Milam, Chad" cc: netdev@oss.sgi.com Subject: RE: dst cache overflow 2.2.x; x>=16 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1224 Lines: 37 Hello, On Mon, 15 Apr 2002, Milam, Chad wrote: > I also do not think that nuking valid routes in the cache will produce any > major issues, other than slowing things down for a few seconds. the cache > is just the cache, not the real route table. and yes, it pretty much Of course. You can play only with max_size to achieve the same result. max_size should be appropriate to the rate new hosts appear in the cache. I'm wondering whether your patched kernel does not have some bug, for example, unfreed skbs or struct rtable. Make sure that the unpatched kernels have the same bug. If it appears after 22 hours (I assume the system load for all these 22 hours is same) then this is a bug. Playing with the hash size is final step but it can only give you some CPU cycles. Touching max_size should be enough. > guarantees the route cache will be purged, therefore avoiding a reboot and > avoiding a quickly repeated overflow... Are you sure you have stalled entries? What shows /proc/slabinfo after 22 hours (skbuff_head_cache, etc)? One hint: can this command solve the problem (to flush the cache entries)?: for i in down up ; do ip link set ethXXX $i ; done > chad Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Mon Apr 15 11:31:33 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FIVW8d007332 for ; Mon, 15 Apr 2002 11:31:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FIVRwu007323 for netdev-outgoing; Mon, 15 Apr 2002 11:31:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FIVN8d007317 for ; Mon, 15 Apr 2002 11:31:24 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id OAA16365; Mon, 15 Apr 2002 14:32:14 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3FIR5I17099; Mon, 15 Apr 2002 14:27:05 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 15 Apr 2002 14:27:05 -0400 (EDT) From: jamal To: "Milam, Chad" cc: Subject: RE: dst cache overflow 2.2.x; x>=16 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 906 Lines: 26 On Mon, 15 Apr 2002, Milam, Chad wrote: > the fact that i am using 2.2 is stated in the subject line. i did neglect to > put it explicitly put it in the message (sorry). it is, however, also > diff/patch file. I apologize. I spent all my time rambling to you based on 2.4 code ;-< > > I also do not think that nuking valid routes in the cache will produce any > major issues, other than slowing things down for a few seconds. the cache > is just the cache, not the real route table. and yes, it pretty much > guarantees the route cache will be purged, therefore avoiding a reboot and > avoiding a quickly repeated overflow... > Typically most of the code will check for the dst cache or some dereferencing within it before using it. I am not sure we can swear by this ;-> i suppose we will find out when you get an oops ;-> maybe you should just purge the routes marked as expired. cheers, jamal From owner-netdev@oss.sgi.com Mon Apr 15 12:07:04 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FJ748d009839 for ; Mon, 15 Apr 2002 12:07:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FJ73q4009838 for netdev-outgoing; Mon, 15 Apr 2002 12:07:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from nyc285ex01.nyc.corp.yr.com (ynrfw28501.yr.com [12.39.241.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FJ6u8d009831 for ; Mon, 15 Apr 2002 12:06:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: dst cache overflow 2.2.x; x>=16 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 15 Apr 2002 15:07:44 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: dst cache overflow 2.2.x; x>=16 Thread-Index: AcHkrGIwSo0dfdv7RtK0JYoDZ/fyiQAAqIEw From: "Milam, Chad" To: , "Julian Anastasov " Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3FJ6v8d009832 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1964 Lines: 58 Julian writes: > Hello, > > On Mon, 15 Apr 2002, Milam, Chad wrote: > > > I also do not think that nuking valid routes in the cache will produce any > > major issues, other than slowing things down for a few seconds. the cache > > is just the cache, not the real route table. and yes, it pretty much > > Of course. You can play only with max_size to achieve the same > result. max_size should be appropriate to the rate new hosts appear > in the cache. I'm wondering whether your patched kernel does not have > some bug, for example, unfreed skbs or struct rtable. Make sure that > the unpatched kernels have the same bug. If it appears after 22 > hours (I assume the system load for all these 22 hours is same) > then this is a bug. Playing with the hash size is final step but it > can only give you some CPU cycles. Touching max_size should be > enough. no. Increasing max_size only delays its death. That is my point. The problem existed on an out of the box RH7, RH6.2, RH6.1 install. The whole point of the patch was to fix a problem that existed _prior_ to me patching it. > > guarantees the route cache will be purged, therefore avoiding a reboot and > > avoiding a quickly repeated overflow... > > Are you sure you have stalled entries? What shows /proc/slabinfo > after 22 hours (skbuff_head_cache, etc)? well, what I can tell you is this. If I run a loop like the following, counter will only show say, 50 routes in the cache. ------ start=atomic_read(&ipv4_dst_ops.entries); i=0; counter=0; while(iu.rt_next; rth->u.rt_next=NULL; counter+=1; } i++; } printk("before: %d, after: %d", start, counter); ------ > One hint: can this command solve the problem (to flush the > cache entries)?: > > for i in down up ; do ip link set ethXXX $i ; done downing all interfaces and reupping them does not seem to solve the problem either :S thanks, chad From owner-netdev@oss.sgi.com Mon Apr 15 12:22:15 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FJMF8d010774 for ; Mon, 15 Apr 2002 12:22:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FJMFL8010772 for netdev-outgoing; Mon, 15 Apr 2002 12:22:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FJM68d010746 for ; Mon, 15 Apr 2002 12:22:07 -0700 Received: (qmail 20670 invoked by uid 2001); 15 Apr 2002 19:22:48 -0000 Date: Mon, 15 Apr 2002 21:22:48 +0200 From: Petr Baudis To: Petr Baudis Cc: xs26-dev@xs26.net, Pekka Savola , Jan Oravec , netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: addrconf.c - possible bug Message-ID: <20020415192248.GB3218@pasky.ji.cz> Reply-To: xs26-dev@xs26.net References: <20020323165921.GC1954@pasky.ji.cz> <20020323184451.GD1954@pasky.ji.cz> <20020324195737.GM1954@pasky.ji.cz> <20020331191346.GI1954@pasky.ji.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020331191346.GI1954@pasky.ji.cz> User-Agent: Mutt/1.5.0i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3511 Lines: 58 Dear diary, on Sun, Mar 31, 2002 at 09:13:46PM CEST, I got a letter, where Petr Baudis told me, that... > Dear diary, on Sun, Mar 24, 2002 at 08:57:37PM CET, I got a letter, > where Petr Baudis told me, that... > > Dear diary, on Sat, Mar 23, 2002 at 07:44:51PM CET, I got a letter, > > where Petr Baudis told me, that... > > > I started the tcpdump there, and we'll see. However, by looking into code, we > > > found no possibility how would zebra want to mess with loopback. > > > > > > Also, we discovered that just taking down and back up any ONE interface will > > > fix this for ALL other interfaces as well. > > > > It failed again and tcpdump still runs happily. Again, taking one of the > > interfaces down and back up (maybe it's worth mentioning that the machine acts > > as XS26 PoP, thus it have about 270 interfaces just now up) fixed the problem > > and the machine started to reply to neighbor solicitations again. ..snip.. > And another excellent example of the problem: > > 20:47:58.981124 fe80::2a0:c9ff:fea8:c91c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b > 20:47:58.981175 fe80::3e18:401b > fe80::2a0:c9ff:fea8:c91c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b With 2.4.19-pre5, the problem still persist :(. However, now it looks that the replies for neighbor sol stops to be sent on per-interface basis, not all at once, as it used to be before.. It still looks same.. 20:49:25.562585 fe80::202:55ff:fe21:4756 > ff02::5: OSPFv3-hello 40: rtrid concorde.lido-tech.net backbone [hlim 1] 20:49:27.641160 fe80::3e18:401b > fe80::202:55ff:fe21:4756: OSPFv3-dd 28: rtrid rover.dkm.cz backbone V6/E/R I/M/MS mtu 1480 S 3CBB14BE 20:49:27.991125 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: OSPFv3-dd 28: rtrid concorde.lido-tech.net backbone V6/E/R I/M/MS mtu 1280 S 3CBB243F 20:49:27.991295 fe80::3e18:401b > fe80::202:55ff:fe21:4756: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 20:49:27.991318 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: OSPFv3-dd 28: rtrid concorde.lido-tech.net backbone V6/E/R I/M/MS mtu 1280 S 3CBB243F 20:49:28.432548 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 20:49:28.432621 fe80::3e18:401b > fe80::202:55ff:fe21:4756: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 20:49:28.432641 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 20:49:29.431424 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 20:49:29.431512 fe80::3e18:401b > fe80::202:55ff:fe21:4756: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 20:49:29.431531 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 20:49:30.431762 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 20:49:30.431870 fe80::3e18:401b > fe80::202:55ff:fe21:4756: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 20:49:30.431890 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b If there's any more info needed, please just tell us, we'll try to help you as much as possible. Kind regards, -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI hacker . Object orientation is in the mind, not in the compiler. -- Alan Cox . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From owner-netdev@oss.sgi.com Mon Apr 15 12:34:56 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FJYu8d011730 for ; Mon, 15 Apr 2002 12:34:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FJYtTG011729 for netdev-outgoing; Mon, 15 Apr 2002 12:34:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FJYq8d011722 for ; Mon, 15 Apr 2002 12:34:52 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id XAA22076; Mon, 15 Apr 2002 23:34:33 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200204151934.XAA22076@sex.inr.ac.ru> Subject: Re: addrconf.c - possible bug To: xs26-dev@xs26.net Date: Mon, 15 Apr 2002 23:34:33 +0400 (MSD) Cc: pasky@xs26.net, pekkas@netcore.fi, jan.oravec@xs26.net, netdev@oss.sgi.com In-Reply-To: <20020415192248.GB3218@pasky.ji.cz> from "Petr Baudis" at Apr 15, 2 09:22:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 337 Lines: 20 Hello! > With 2.4.19-pre5, the problem still persist :(. Nothing wonderful, nothing has been changed. :-) > If there's any more info needed, please just tell us, we'll try to help you > as much as possible. Well, when you see this, dump routing tables with ip -6 route ls table all And addresses too with ip addr ls Alexey From owner-netdev@oss.sgi.com Mon Apr 15 12:49:39 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FJnd8d012537 for ; Mon, 15 Apr 2002 12:49:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FJndBx012536 for netdev-outgoing; Mon, 15 Apr 2002 12:49:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FJnT8d012521 for ; Mon, 15 Apr 2002 12:49:32 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id g3FMr6q01301; Mon, 15 Apr 2002 22:53:06 GMT Date: Mon, 15 Apr 2002 22:53:06 +0000 (GMT) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: "Milam, Chad" cc: netdev@oss.sgi.com, "Julian Anastasov " Subject: RE: dst cache overflow 2.2.x; x>=16 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1458 Lines: 44 Hello, On Mon, 15 Apr 2002, Milam, Chad wrote: > > can only give you some CPU cycles. Touching max_size should be > > enough. > > no. Increasing max_size only delays its death. That is my point. The problem > existed on an out of the box RH7, RH6.2, RH6.1 install. The whole point of the > patch was to fix a problem that existed _prior_ to me patching it. I assume you mean a plain kernel (without Check Point?). > > Are you sure you have stalled entries? What shows /proc/slabinfo > > after 22 hours (skbuff_head_cache, etc)? > > well, what I can tell you is this. If I run a loop like the following, counter > will only show say, 50 routes in the cache. It means there are 50 linked cache entries but the ipv4_dst_ops.entries reaches the limit, very strange. > > for i in down up ; do ip link set ethXXX $i ; done > > downing all interfaces and reupping them does not seem to solve the problem either :S I mean when you see the dst cache overflow message can the command help? But ... may be are running a kernel patched with your changes. I'm asking this because I know cases where wrong changes can make problems with dst cache. But the plain kernel should be fine. One question more: can you say that this box is used only as router or what kind of TCP or UDP connections you have (to/from the box)? There can be some corner cases in the dst cache usage from connected sockets. > thanks, > chad Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Mon Apr 15 12:52:39 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FJqd8d012794 for ; Mon, 15 Apr 2002 12:52:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FJqdp4012793 for netdev-outgoing; Mon, 15 Apr 2002 12:52:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FJqZ8d012782 for ; Mon, 15 Apr 2002 12:52:36 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id B07A41E906; Mon, 15 Apr 2002 21:53:21 +0200 (MEST) Date: Mon, 15 Apr 2002 21:53:15 +0200 From: Andi Kleen To: Julian Anastasov Cc: "Milam, Chad" , netdev@oss.sgi.com, "Julian Anastasov " Subject: Re: dst cache overflow 2.2.x; x>=16 Message-ID: <20020415215315.A16910@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 666 Lines: 15 > I mean when you see the dst cache overflow message can the > command help? But ... may be are running a kernel patched with your > changes. I'm asking this because I know cases where wrong changes > can make problems with dst cache. But the plain kernel should be > fine. One question more: can you say that this box is used only as > router or what kind of TCP or UDP connections you have (to/from the > box)? There can be some corner cases in the dst cache usage from > connected sockets. I would suspect CheckPoint (I think it has kernel modules, hasn't it) We had a similar report of such a thing a few months ago and they were using CheckPoint too. -Andi From owner-netdev@oss.sgi.com Mon Apr 15 12:57:31 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FJvV8d013168 for ; Mon, 15 Apr 2002 12:57:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FJvVax013166 for netdev-outgoing; Mon, 15 Apr 2002 12:57:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from nyc285ex01.nyc.corp.yr.com (ynrfw28501.yr.com [12.39.241.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FJvO8d013157 for ; Mon, 15 Apr 2002 12:57:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: dst cache overflow 2.2.x; x>=16 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 15 Apr 2002 15:58:11 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: dst cache overflow 2.2.x; x>=16 Thread-Index: AcHkttOs5RbXq7bUQBG74Lh9ie+HnAAAFZQQ From: "Milam, Chad" To: , "Julian Anastasov " Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3FJvO8d013158 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1935 Lines: 52 Julian wrote: > On Mon, 15 Apr 2002, Milam, Chad wrote: > > > > can only give you some CPU cycles. Touching max_size should be > > > enough. > > > > no. Increasing max_size only delays its death. That is my point. The problem > > existed on an out of the box RH7, RH6.2, RH6.1 install. The whole point of the > > patch was to fix a problem that existed _prior_ to me patching it. > > I assume you mean a plain kernel (without Check Point?). indeed.. out of the box, nothing installed additional, ip params tuned. > > > > Are you sure you have stalled entries? What shows /proc/slabinfo > > > after 22 hours (skbuff_head_cache, etc)? > > > > well, what I can tell you is this. If I run a loop like the following, counter > > will only show say, 50 routes in the cache. > > It means there are 50 linked cache entries but the > ipv4_dst_ops.entries reaches the limit, very strange. this is what I am keep trying to say :) > > > for i in down up ; do ip link set ethXXX $i ; done > > > > downing all interfaces and reupping them does not seem to solve the problem either :S > > I mean when you see the dst cache overflow message can the > command help? But ... may be are running a kernel patched with your > changes. I'm asking this because I know cases where wrong changes > can make problems with dst cache. But the plain kernel should be > fine. One question more: can you say that this box is used only as > router or what kind of TCP or UDP connections you have (to/from the > box)? There can be some corner cases in the dst cache usage from > connected sockets. I originally setup a script to do basically this... grep "dst cache" /var/log/messages; if i get a hit, down and up all interfaces. that didnt work, so then I changed it to reboot the box :(. This was done on a box with _no_ funny stuff... again, bog standard. The box is a router, no ip masq, no ip chains, no ip fw, just a router. Thanks, chad From owner-netdev@oss.sgi.com Mon Apr 15 15:01:26 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FM1P8d019553 for ; Mon, 15 Apr 2002 15:01:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FM1Pc9019552 for netdev-outgoing; Mon, 15 Apr 2002 15:01:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FM188d019534 for ; Mon, 15 Apr 2002 15:01:08 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09474 for ; Mon, 15 Apr 2002 15:02:13 -0700 (PDT) mail_from (Robert.Olsson@data.slu.se) Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id XAA29337; Mon, 15 Apr 2002 23:47:08 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ebTC8EyiCR" Content-Transfer-Encoding: 7bit Message-ID: <15547.19035.479704.356417@robur.slu.se> Date: Mon, 15 Apr 2002 23:47:07 +0200 To: "Milam, Chad" Cc: , "Julian Anastasov " Subject: RE: dst cache overflow 2.2.x; x>=16 In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 8989 Lines: 152 --ebTC8EyiCR Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Milam, Chad writes: > > The box is a router, no ip masq, no ip chains, no ip fw, just a router. Weird. Julian has a useful program testlvs for testing route cache. I just tested this w. linux-2.2.17 many srcnum (80000) but cannot force cache overflow. Ok it was not for hours. And 2.2.X has recent cache code I was wrong here. I have used it for just for routers for pretty demanding jobs. I would look for grows in /proc/slabinfo too... --ebTC8EyiCR Content-Type: application/octet-stream Content-Disposition: attachment; filename="rt_cache_stat-2.2.17.pat" Content-Transfer-Encoding: base64 LS0tIGxpbnV4L2luY2x1ZGUvbmV0L3JvdXRlLmgub3JpZwlTdW4gTm92ICA1IDIyOjE4OjM1 IDIwMDAKKysrIGxpbnV4L2luY2x1ZGUvbmV0L3JvdXRlLmgJTW9uIEFwciAxNSAyMjoxOTox OCAyMDAyCkBAIC0xNCw2ICsxNCw3IEBACiAgKgkJQWxhbiBDb3gJOglTdXBwb3J0IGZvciBU Q1AgcGFyYW1ldGVycy4KICAqCQlBbGV4ZXkgS3V6bmV0c292OglNYWpvciBjaGFuZ2VzIGZv ciBuZXcgcm91dGluZyBjb2RlLgogICoJCU1pa2UgTWNMYWdhbiAgICA6CVJvdXRpbmcgYnkg c291cmNlCisgKgkJUm9iZXJ0IE9sc3NvbiAgIDoJQWRkZWQgcnRfY2FjaGUgc3RhdGlzdGlj cwogICoKICAqCQlUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp c3RyaWJ1dGUgaXQgYW5kL29yCiAgKgkJbW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0 aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKQEAgLTEwMiw2ICsxMDMsMjAgQEAKIAlf X3UzMiAJb19wYWNrZXRzOwogCV9fdTMyIAlpX2J5dGVzOwogCV9fdTMyIAlpX3BhY2tldHM7 Cit9OworCitzdHJ1Y3QgcnRfY2FjaGVfc3RhdCAKK3sKKyAgICAgICAgdW5zaWduZWQgaW5f aGl0OworICAgICAgICB1bnNpZ25lZCBpbl9zbG93X3RvdDsKKyAgICAgICAgdW5zaWduZWQg aW5fc2xvd19tYzsKKyAgICAgICAgdW5zaWduZWQgaW5fbm9fcm91dGU7CisgICAgICAgIHVu c2lnbmVkIGluX2JyZDsKKyAgICAgICAgdW5zaWduZWQgaW5fbWFydGlhbl9kc3Q7CisgICAg ICAgIHVuc2lnbmVkIGluX21hcnRpYW5fc3JjOworICAgICAgICB1bnNpZ25lZCBvdXRfaGl0 OworICAgICAgICB1bnNpZ25lZCBvdXRfc2xvd190b3Q7CisgICAgICAgIHVuc2lnbmVkIG91 dF9zbG93X21jOwogfTsKIAogZXh0ZXJuIHN0cnVjdCBpcF9ydF9hY2N0IGlwX3J0X2FjY3Rb MjU2XTsKLS0tIGxpbnV4L25ldC9pcHY0L3JvdXRlLmMub3JpZwlUdWUgSmFuICA0IDE5OjEy OjI2IDIwMDAKKysrIGxpbnV4L25ldC9pcHY0L3JvdXRlLmMJTW9uIEFwciAxNSAyMzo1NToz NyAyMDAyCkBAIC01Miw2ICs1Miw3IEBACiAgKglUb2JpYXMgUmluZ3N0cm9tCToJVW5pbml0 aWFsaXplZCByZXMudHlwZSBpbiBpcF9yb3V0ZV9vdXRwdXRfc2xvdy4KICAqCVZsYWRpbWly IFYuIEl2YW5vdgk6CUlQIHJ1bGUgaW5mbyAoZmxvd2lkKSBpcyByZWFsbHkgdXNlZnVsLgog ICoJCU1hcmMgQm91Y2hlcgk6CXJvdXRpbmcgYnkgZndtYXJrCisgKglSb2JlcnQgT2xzc29u CQk6CUFkZGVkIHJ0X2NhY2hlIHN0YXRpc3RpY3MKICAqCiAgKgkJVGhpcyBwcm9ncmFtIGlz IGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgogICoJCW1v ZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl bnNlCkBAIC0xNzYsNiArMTc3LDggQEAKIAogc3RydWN0IHJ0YWJsZSAJKnJ0X2hhc2hfdGFi bGVbUlRfSEFTSF9ESVZJU09SXTsKIAorc3RydWN0IHJ0X2NhY2hlX3N0YXQgcnRfY2FjaGVf c3RhdFtOUl9DUFVTXTsKKwogc3RhdGljIGludCBydF9pbnRlcm5faGFzaCh1bnNpZ25lZCBo YXNoLCBzdHJ1Y3QgcnRhYmxlICogcnRoLCBzdHJ1Y3QgcnRhYmxlICoqIHJlcyk7CiAKIHN0 YXRpYyBfX2lubGluZV9fIHVuc2lnbmVkIHJ0X2hhc2hfY29kZSh1MzIgZGFkZHIsIHUzMiBz YWRkciwgdTggdG9zKQpAQCAtMzU3LDYgKzM2MCw0NCBAQAogCX0KIAllbmRfYmhfYXRvbWlj KCk7CiB9CisKKworI2lmZGVmIENPTkZJR19QUk9DX0ZTCitzdGF0aWMgaW50IHJ0X2NhY2hl X3N0YXRfZ2V0X2luZm8oY2hhciAqYnVmZmVyLCBjaGFyICoqc3RhcnQsIG9mZl90IG9mZnNl dCwgaW50IGxlbmd0aCkKK3sKKwlpbnQgaSwgbGNwdTsKKyAgICAgICAgaW50IGxlbj0wOwor CXVuc2lnbmVkIGludCBkc3RfZW50cmllcyA9IGF0b21pY19yZWFkKCZpcHY0X2RzdF9vcHMu ZW50cmllcyk7CisKKyAgICAgICAgZm9yIChsY3B1PTA7IGxjcHU8c21wX251bV9jcHVzOyBs Y3B1KyspIHsKKyAgICAgICAgICAgICAgICBpID0gY3B1X2xvZ2ljYWxfbWFwKGxjcHUpOwor CisJCWxlbiArPSBzcHJpbnRmKGJ1ZmZlcitsZW4sICIlMDh4ICAlMDh4ICUwOHggJTA4eCAl MDh4ICUwOHggJTA4eCAlMDh4ICAlMDh4ICUwOHggJTA4eFxuIiwKKwkJCSAgICAgICBkc3Rf ZW50cmllcywJCSAgICAgICAKKwkJCSAgICAgICBydF9jYWNoZV9zdGF0W2ldLmluX2hpdCwK KwkJCSAgICAgICBydF9jYWNoZV9zdGF0W2ldLmluX3Nsb3dfdG90LAorCQkJICAgICAgIHJ0 X2NhY2hlX3N0YXRbaV0uaW5fc2xvd19tYywKKwkJCSAgICAgICBydF9jYWNoZV9zdGF0W2ld LmluX25vX3JvdXRlLAorCQkJICAgICAgIHJ0X2NhY2hlX3N0YXRbaV0uaW5fYnJkLAorCQkJ ICAgICAgIHJ0X2NhY2hlX3N0YXRbaV0uaW5fbWFydGlhbl9kc3QsCisJCQkgICAgICAgcnRf Y2FjaGVfc3RhdFtpXS5pbl9tYXJ0aWFuX3NyYywKKworCQkJICAgICAgIHJ0X2NhY2hlX3N0 YXRbaV0ub3V0X2hpdCwKKwkJCSAgICAgICBydF9jYWNoZV9zdGF0W2ldLm91dF9zbG93X3Rv dCwKKwkJCSAgICAgICBydF9jYWNoZV9zdGF0W2ldLm91dF9zbG93X21jCisJCQkpOworCX0K KwlsZW4gLT0gb2Zmc2V0OworCisJaWYgKGxlbiA+IGxlbmd0aCkKKwkJbGVuID0gbGVuZ3Ro OworCWlmIChsZW4gPCAwKQorCQlsZW4gPSAwOworCisJKnN0YXJ0ID0gYnVmZmVyICsgb2Zm c2V0OworICAJcmV0dXJuIGxlbjsKK30KKyNlbmRpZgogICAKIHZvaWQgcnRfY2FjaGVfZmx1 c2goaW50IGRlbGF5KQogewpAQCAtMTAyNyw2ICsxMDY4LDcgQEAKIAlzdHJ1Y3QgaW5fZGV2 aWNlICppbl9kZXYgPSBkZXYtPmlwX3B0cjsKIAl1MzIgaXRhZyA9IDA7CiAKKwogCS8qIFBy aW1hcnkgc2FuaXR5IGNoZWNrcy4gKi8KIAogCWlmIChNVUxUSUNBU1Qoc2FkZHIpIHx8IEJB RENMQVNTKHNhZGRyKSB8fCBMT09QQkFDSyhzYWRkcikgfHwKQEAgLTEwNzgsNiArMTEyMCw3 IEBACiAjaWZkZWYgQ09ORklHX0lQX01ST1VURQogCWlmICghTE9DQUxfTUNBU1QoZGFkZHIp ICYmIElOX0RFVl9NRk9SV0FSRChpbl9kZXYpKQogCQlydGgtPnUuZHN0LmlucHV0ID0gaXBf bXJfaW5wdXQ7CisgCXJ0X2NhY2hlX3N0YXRbc21wX3Byb2Nlc3Nvcl9pZCgpXS5pbl9zbG93 X21jKys7CiAjZW5kaWYKIAogCWhhc2ggPSBydF9oYXNoX2NvZGUoZGFkZHIsIHNhZGRyXihk ZXYtPmlmaW5kZXg8PDUpLCB0b3MpOwpAQCAtMTE1NSw2ICsxMTk4LDggQEAKIAkJZ290byBu b19yb3V0ZTsKIAl9CiAKKwlydF9jYWNoZV9zdGF0W3NtcF9wcm9jZXNzb3JfaWQoKV0uaW5f c2xvd190b3QrKzsKKwogI2lmZGVmIENPTkZJR19JUF9ST1VURV9OQVQKIAkvKiBQb2xpY3kg aXMgYXBwbGllZCBiZWZvcmUgbWFwcGluZyBkZXN0aW5hdGlvbiwKIAkgICBidXQgcmVyb3V0 aW5nIGFmdGVyIG1hcCBzaG91bGQgYmUgbWFkZSB3aXRoIG9sZCBzb3VyY2UuCkBAIC0xMjg3 LDYgKzEzMzIsNyBAQAogCX0KIAlmbGFncyB8PSBSVENGX0JST0FEQ0FTVDsKIAlyZXMudHlw ZSA9IFJUTl9CUk9BRENBU1Q7CisJcnRfY2FjaGVfc3RhdFtzbXBfcHJvY2Vzc29yX2lkKCld LmluX2JyZCsrOwogCiBsb2NhbF9pbnB1dDoKIAlydGggPSBkc3RfYWxsb2Moc2l6ZW9mKHN0 cnVjdCBydGFibGUpLCAmaXB2NF9kc3Rfb3BzKTsKQEAgLTEzMjgsNiArMTM3NCw3IEBACiAJ cmV0dXJuIHJ0X2ludGVybl9oYXNoKGhhc2gsIHJ0aCwgKHN0cnVjdCBydGFibGUqKikmc2ti LT5kc3QpOwogCiBub19yb3V0ZToKKwlydF9jYWNoZV9zdGF0W3NtcF9wcm9jZXNzb3JfaWQo KV0uaW5fbm9fcm91dGUrKzsKIAlzcGVjX2RzdCA9IGluZXRfc2VsZWN0X2FkZHIoZGV2LCAw LCBSVF9TQ09QRV9VTklWRVJTRSk7CiAJcmVzLnR5cGUgPSBSVE5fVU5SRUFDSEFCTEU7CiAJ Z290byBsb2NhbF9pbnB1dDsKQEAgLTEzMzYsNiArMTM4Myw3IEBACiAJICoJRG8gbm90IGNh Y2hlIG1hcnRpYW4gYWRkcmVzc2VzOiB0aGV5IHNob3VsZCBiZSBsb2dnZWQgKFJGQzE4MTIp CiAJICovCiBtYXJ0aWFuX2Rlc3RpbmF0aW9uOgorCXJ0X2NhY2hlX3N0YXRbc21wX3Byb2Nl c3Nvcl9pZCgpXS5pbl9tYXJ0aWFuX2RzdCsrOwogI2lmZGVmIENPTkZJR19JUF9ST1VURV9W RVJCT1NFCiAJaWYgKElOX0RFVl9MT0dfTUFSVElBTlMoaW5fZGV2KSAmJiBuZXRfcmF0ZWxp bWl0KCkpCiAJCXByaW50ayhLRVJOX1dBUk5JTkcgIm1hcnRpYW4gZGVzdGluYXRpb24gJTA4 eCBmcm9tICUwOHgsIGRldiAlc1xuIiwgZGFkZHIsIHNhZGRyLCBkZXYtPm5hbWUpOwpAQCAt MTM0Myw2ICsxMzkxLDggQEAKIAlyZXR1cm4gLUVJTlZBTDsKIAogbWFydGlhbl9zb3VyY2U6 CisKKwlydF9jYWNoZV9zdGF0W3NtcF9wcm9jZXNzb3JfaWQoKV0uaW5fbWFydGlhbl9zcmMr KzsKICNpZmRlZiBDT05GSUdfSVBfUk9VVEVfVkVSQk9TRQogCWlmIChJTl9ERVZfTE9HX01B UlRJQU5TKGluX2RldikgJiYgbmV0X3JhdGVsaW1pdCgpKSB7CiAJCS8qCkBAIC0xMzg0LDYg KzE0MzQsNyBAQAogCQkgICAgcnRoLT5rZXkudG9zID09IHRvcykgewogCQkJcnRoLT51LmRz dC5sYXN0dXNlID0gamlmZmllczsKIAkJCWF0b21pY19pbmMoJnJ0aC0+dS5kc3QudXNlKTsK KyAJCQlydF9jYWNoZV9zdGF0W3NtcF9wcm9jZXNzb3JfaWQoKV0uaW5faGl0Kys7CiAJCQlh dG9taWNfaW5jKCZydGgtPnUuZHN0LnJlZmNudCk7CiAJCQlza2ItPmRzdCA9IChzdHJ1Y3Qg ZHN0X2VudHJ5KilydGg7CiAJCQlyZXR1cm4gMDsKQEAgLTE2MzQsMTQgKzE2ODUsMTggQEAK IAogCXJ0aC0+dS5kc3Qub3V0cHV0PWlwX291dHB1dDsKIAorCXJ0X2NhY2hlX3N0YXRbc21w X3Byb2Nlc3Nvcl9pZCgpXS5vdXRfc2xvd190b3QrKzsKKwogCWlmIChmbGFncyZSVENGX0xP Q0FMKSB7CiAJCXJ0aC0+dS5kc3QuaW5wdXQgPSBpcF9sb2NhbF9kZWxpdmVyOwogCQlydGgt PnJ0X3NwZWNfZHN0ID0ga2V5LmRzdDsKIAl9CiAJaWYgKGZsYWdzJihSVENGX0JST0FEQ0FT VHxSVENGX01VTFRJQ0FTVCkpIHsKIAkJcnRoLT5ydF9zcGVjX2RzdCA9IGtleS5zcmM7Ci0J CWlmIChmbGFncyZSVENGX0xPQ0FMICYmICEoZGV2X291dC0+ZmxhZ3MmSUZGX0xPT1BCQUNL KSkKKwkJaWYgKGZsYWdzJlJUQ0ZfTE9DQUwgJiYgIShkZXZfb3V0LT5mbGFncyZJRkZfTE9P UEJBQ0spKSB7CiAJCQlydGgtPnUuZHN0Lm91dHB1dCA9IGlwX21jX291dHB1dDsKKwkJCXJ0 X2NhY2hlX3N0YXRbc21wX3Byb2Nlc3Nvcl9pZCgpXS5vdXRfc2xvd19tYysrOworCQl9CiAj aWZkZWYgQ09ORklHX0lQX01ST1VURQogCQlpZiAocmVzLnR5cGUgPT0gUlROX01VTFRJQ0FT VCAmJiBkZXZfb3V0LT5pcF9wdHIpIHsKIAkJCXN0cnVjdCBpbl9kZXZpY2UgKmluX2RldiA9 IGRldl9vdXQtPmlwX3B0cjsKQEAgLTE2ODMsNiArMTczOCw3IEBACiAJCSkgewogCQkJcnRo LT51LmRzdC5sYXN0dXNlID0gamlmZmllczsKIAkJCWF0b21pY19pbmMoJnJ0aC0+dS5kc3Qu dXNlKTsKKwkJCXJ0X2NhY2hlX3N0YXRbc21wX3Byb2Nlc3Nvcl9pZCgpXS5vdXRfaGl0Kys7 CiAJCQlhdG9taWNfaW5jKCZydGgtPnUuZHN0LnJlZmNudCk7CiAJCQllbmRfYmhfYXRvbWlj KCk7CiAJCQkqcnAgPSBydGg7CkBAIC0yMDQxLDYgKzIwOTcsOCBAQAogCQlydF9jYWNoZV9n ZXRfaW5mbwogCX0pOwogI2lmZGVmIENPTkZJR19ORVRfQ0xTX1JPVVRFCisgCWVudCA9IGNy ZWF0ZV9wcm9jX2VudHJ5ICgibmV0L3J0X2NhY2hlX3N0YXQiLCAwLCAwKTsKKwllbnQtPnJl YWRfcHJvYyA9IHJ0X2NhY2hlX3N0YXRfZ2V0X2luZm87CiAJZW50ID0gY3JlYXRlX3Byb2Nf ZW50cnkoIm5ldC9ydF9hY2N0IiwgMCwgMCk7CiAJZW50LT5yZWFkX3Byb2MgPSBpcF9ydF9h Y2N0X3JlYWQ7CiAjZW5kaWYK --ebTC8EyiCR Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit With the patch you can monitor ipv4_dst_ops.entries wich rtstat and testlvs is good exerciser. Cheers. --ro BTW. I think rtstat can hold have some stats about the GC process too. --ebTC8EyiCR-- From owner-netdev@oss.sgi.com Mon Apr 15 20:06:37 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G36a8d002565 for ; Mon, 15 Apr 2002 20:06:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G36aeP002564 for netdev-outgoing; Mon, 15 Apr 2002 20:06:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from peoplemail.com.cn ([202.99.23.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G36X8d002558 for ; Mon, 15 Apr 2002 20:06:34 -0700 Received: from peoplemail.com.cn([127.0.0.1]) by peoplemail.com.cn(JetMail 2.5.3.0) with SMTP id jm603cbba439; Tue, 16 Apr 2002 03:07:12 -0000 Content-Type: text/plain Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: <3t979583889287.26127@freemail.peopledaily.com.cn> Date: Tue, 16 Apr 2002 11:07:12 +0800 (CST) From: wangxiangyu@peoplemail.com.cn To: netdev@oss.sgi.com Cc: Subject: a question on loopback X-Priority: 3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 390 Lines: 11 Hello, I want to use my usb host-host cable to do a send/receive test on my single pc, but ip layer of net system will only do a loopback on one host condition. How can I do to force it send/receive through device layer? thanks Best Regards Xiang-Yu Wang ------------------------------------------------------------------ ÈËÃñÍø¡¶Õþ²ßÐÅÏ¢¡·ÍøÉÏÊÕ·ÑÔÓÖ¾ »¶Ó­Ôì·Ã£ºhttp://zcxx.people.com.cn From owner-netdev@oss.sgi.com Tue Apr 16 00:18:31 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G7IV8d013284 for ; Tue, 16 Apr 2002 00:18:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G7IVuh013283 for netdev-outgoing; Tue, 16 Apr 2002 00:18:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from peoplemail.com.cn ([202.99.23.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G7IS8d013275 for ; Tue, 16 Apr 2002 00:18:29 -0700 Received: from peoplemail.com.cn([127.0.0.1]) by peoplemail.com.cn(JetMail 2.5.3.0) with SMTP id jm43cbc4141; Tue, 16 Apr 2002 07:19:05 -0000 Content-Type: text/plain Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: <9c979583848095.26152@freemail.peopledaily.com.cn> Date: Tue, 16 Apr 2002 15:19:04 +0800 (CST) From: wangxiangyu@peoplemail.com.cn To: netdev@oss.sgi.com Cc: Subject: 600055 X-Priority: 3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 391 Lines: 11 Hello, I want to use my usb host-host cable to do a send/receive test on my single pc, but ip layer of net system will only do a loopback on one host condition. How can I do to force it send/receive through device layer? thanks Best Regards Xiang-Yu Wang ------------------------------------------------------------------ ÈËÃñÍø¡¶Õþ²ßÐÅÏ¢¡·ÍøÉÏÊÕ·ÑÔÓÖ¾ »¶Ó­Ôì·Ã£ºhttp://zcxx.people.com.cn From owner-netdev@oss.sgi.com Tue Apr 16 03:11:14 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GABE8d029625 for ; Tue, 16 Apr 2002 03:11:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GABAg1029623 for netdev-outgoing; Tue, 16 Apr 2002 03:11:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from luxik.cdi.cz (root@inway106.cdi.cz [213.151.81.106]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GAB38d029615 for ; Tue, 16 Apr 2002 03:11:06 -0700 Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16xPw7-0005J7-00; Tue, 16 Apr 2002 12:11:43 +0200 Date: Tue, 16 Apr 2002 12:11:43 +0200 (CEST) From: Martin Devera To: wangxiangyu@peoplemail.com.cn cc: netdev@oss.sgi.com Subject: Re: a question on loopback In-Reply-To: <3t979583889287.26127@freemail.peopledaily.com.cn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id g3GAB68d029617 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 575 Lines: 21 Try man 7 packet ;) I use it in my QoS measurer which uses loopback ethernet connector .. devik On Tue, 16 Apr 2002 wangxiangyu@peoplemail.com.cn wrote: > Hello, > I want to use my usb host-host cable to do a send/receive test on my single pc, > but ip layer of net system will only do a loopback on one host condition. How > can I do to force it send/receive through device layer? > thanks > Best Regards > Xiang-Yu Wang > ------------------------------------------------------------------ > ÈËÃñÍø¡¶Õþ²ßÐÅÏ¢¡·ÍøÉÏÊÕ·ÑÔÓÖ¾ > »¶Ó­Ôì·Ã£ºhttp://zcxx.people.com.cn > > > From owner-netdev@oss.sgi.com Wed Apr 17 13:40:34 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HKeY8d018030 for ; Wed, 17 Apr 2002 13:40:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HKeXZj018029 for netdev-outgoing; Wed, 17 Apr 2002 13:40:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HKe48d018002 for ; Wed, 17 Apr 2002 13:40:14 -0700 Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g3HKeKi08640 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 17 Apr 2002 16:40:26 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g3HKcHP14697; Wed, 17 Apr 2002 16:38:19 -0400 (EDT) Message-Id: <200204172038.g3HKcHP14697@marajade.sandelman.ottawa.on.ca> To: netdev@oss.sgi.com cc: russell@flora.ca, grupis@atlas.ucpel.tche.br Subject: problems with NAT on 2.4 kernels Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Apr 2002 16:38:17 -0400 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1620 Lines: 36 -----BEGIN PGP SIGNED MESSAGE----- When FreeSWAN is configured to do Opportunistic Encryption, it arranges for all outgoing packets to travel through ipsec0. If the destination is not OE capable, the packet goes out in the clear on ppp0/eth0. When OE is configured on a box that also does NAT (IP masquerading) we run into a problem. One can talk to any box that has OE enabled. This is because the NAT code seems to believe it proper for packets to arrive on the same interface that they went out. This just doesn't happen when there is IPsec OE (as it exists now) and often won't happen at all when there are multiple internet connections. Jamal Hadi diagnosed this as the problem in the bar at IETF, but wasn't sure what piece of code we could hack. He seemed to think that this code has been changed in 2.5. If someone could point at the change, I would appreciate it, as we have many people who want to do precisely this: NAT followed by OE. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPL3c9oqHRg3pndX9AQEPwgQAp2jfyRuBdu9QxIzo9CcrjHmcmsipCR9v wb1fsI1WD8BYe9n3bMMnSbqvS13XuEvBOh3sWjx/cW1SqcPDJY+kxD/hS5UbvaHv n2ioN4G33txAJuUFLI12OIohwiHZD0HYKBikFCkUBxoDiwIYjFZEvOLvkUAu/Gc1 DtwskGpERfM= =KAHF -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Thu Apr 18 19:09:31 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J29U8d017901 for ; Thu, 18 Apr 2002 19:09:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J29UOZ017900 for netdev-outgoing; Thu, 18 Apr 2002 19:09:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from web13003.mail.yahoo.com (web13003.mail.yahoo.com [216.136.174.13]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3J29Q8d017897 for ; Thu, 18 Apr 2002 19:09:26 -0700 Message-ID: <20020419021031.24839.qmail@web13003.mail.yahoo.com> Received: from [65.209.235.11] by web13003.mail.yahoo.com via HTTP; Thu, 18 Apr 2002 19:10:31 PDT Date: Thu, 18 Apr 2002 19:10:31 -0700 (PDT) From: Yan-Fa Li Subject: SMP Re-ordering ? To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1015 Lines: 33 So I've read the excellent "Beyond Softnet" paper about how SMP is inherently likely to re-order packet flows, and I'm trying to use the work around where I assign IRQs to CPUs, in this case for a gigabit network card. I have dual PIIIs 1GHz on serverworks chipsets. I'm using the DGE550 66MHz/64bit GigE cards over copper. Each system has 1.5Gbytes of RAM. Each kernel is 2.4.19-pre5aa1 and /dev/epoll. To force IRQ affinity to CPU 2 or 2, I type the following: echo 2 > /proc/irq/23/smp_affinity when I send traffic to this interface I only see IRQs on the second CPU on /proc/interrupts. All is good so far. However, a network device I'm testing between my hosts keeps seeing re-ordered TCP sessions. When I reboot and specify maxcpus=1 and re-run the test I get none. Am I doing something really wrong here or does this workaround no longer work ? Thanks Yan __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-netdev@oss.sgi.com Fri Apr 19 04:02:45 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JB2j8d000501 for ; Fri, 19 Apr 2002 04:02:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JB2dac000500 for netdev-outgoing; Fri, 19 Apr 2002 04:02:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JB2Z8d000497 for ; Fri, 19 Apr 2002 04:02:35 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id HAA23473; Fri, 19 Apr 2002 07:03:37 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g3JAwPq01360; Fri, 19 Apr 2002 06:58:25 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 19 Apr 2002 06:58:24 -0400 (EDT) From: jamal To: Yan-Fa Li cc: Subject: Re: SMP Re-ordering ? In-Reply-To: <20020419021031.24839.qmail@web13003.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 457 Lines: 23 Yan, On Thu, 18 Apr 2002, Yan-Fa Li wrote: > However, a network device I'm testing between my hosts > keeps seeing re-ordered TCP sessions. When I reboot and > specify maxcpus=1 and re-run the test I get none. > Strange indeed. > Am I doing something really wrong here or does this > workaround no longer work ? > IRQ affinity should work and so should NAPI. How are you proving packets are re-ordered? Could it be the device driver? cheers, jamal From owner-netdev@oss.sgi.com Fri Apr 19 11:28:59 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JISx8d008786 for ; Fri, 19 Apr 2002 11:28:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JISxiU008785 for netdev-outgoing; Fri, 19 Apr 2002 11:28:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from hotmail.com (f241.law14.hotmail.com [64.4.21.241]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JISp8d008779 for ; Fri, 19 Apr 2002 11:28:51 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 11:29:54 -0700 Received: from 198.242.58.71 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 18:29:53 GMT X-Originating-IP: [198.242.58.71] From: "Md Arif" To: netdev@oss.sgi.com Subject: Linux IPv6 Bind failure with Invalid Argument Date: Fri, 19 Apr 2002 18:29:53 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 18:29:54.0243 (UTC) FILETIME=[33449130:01C1E7D0] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2040 Lines: 69 Hello, Would you pls help me out in this regard. I am getting Bind failure with error inValid argument Linux IPv6 machine(Kernel 2.4.7) Same code works in Solaris IPv6. Where is is bug????? Pls let me know if you need more info on this. Thanks in advance for your support. Arif /*-------------- code segment ------------------*/ struct sockaddr_in6 addr6; int size, sd; sd = socket(AF_INET6, SOCK_DGRAM, 0); if(sd == -1) { perror("socket()"); exit(1); } if(setsockopt(sd, SOL_SOCKET, SO_BSDCOMPAT, &enable, sizeof(enable)) == -1) { perror("setsockopt()"); exit(1); } if(setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &enable, sizeof(enable)) == -1) { perror("setsockopt()"); exit(1); } memset(&addr6, 0, sizeof(addr6)); size = sizeof(struct sockaddr_in6); addr6.sin6_family = AF_INET6; addr6.sin6_port = htons(0); /* use this to bind to real address */ if(inet_pton(AF_INET6, "FE80::250:DAFF:FECD:2DE2", &addr6.sin6_addr)==0) perror("inet_pton call failed inside cmInetBind"); /* when binding to loopback interface. THIS PORTION WORKS!!!! */ /* memcpy(&addr6.sin6_addr, &in6addr_loopback, sizeof(in6addr_loopback)); */  if(bind(sd, (struct sockaddr *)&addr6, size) == -1) { perror("bind()"); exit(1); } ------------log of the Interface on linux IPv6 machine------------ eth0 Link encap:Ethernet HWaddr 00:50:DA:CD:2D:E2 inet addr:10.242.101.18 Bcast:10.242.101.255 Mask:255.255.255.0 inet6 addr: fe80::250:daff:fecd:2de2/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3109744 errors:0 dropped:0 overruns:136 frame:0 TX packets:2470093 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:650222683 (620.1 Mb) TX bytes:541913530 (516.8 Mb) _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-netdev@oss.sgi.com Fri Apr 19 11:30:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JIUJ8d008888 for ; Fri, 19 Apr 2002 11:30:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JIUJCm008887 for netdev-outgoing; Fri, 19 Apr 2002 11:30:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from amilo (unet2-87.univie.ac.at [131.130.232.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JITW8d008807 for ; Fri, 19 Apr 2002 11:29:54 -0700 Received: from amilo ([127.0.0.1] ident=till) by amilo with esmtp (Exim 3.35 #1 (Debian)) id 16yd8u-0000OS-00; Fri, 19 Apr 2002 20:29:56 +0200 Content-Type: text/plain; charset="us-ascii" From: till busch Reply-To: buti@gmx.at To: netdev@oss.sgi.com Subject: 3CXFE575BT full-duplex problem Date: Fri, 19 Apr 2002 20:29:45 +0200 X-Mailer: KMail [version 1.4] Cc: andrewm@uow.edu.au MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204192029.45577.buti@gmx.at> Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 7756 Lines: 183 hi. having read Documentation/networking/vortex.txt i'm trying to make a bug report: My "3Com Megahertz 10/100 LAN CardBus PC Card", a 3CXFE575BT has problems switching to full-duplex mode. (is there any difference between 3CC and 3CX?) Is it really a driver problem? yes, i've seen reports about this on many sites in the internet. also, i tested it with windows, where things work fine. i'm running linux 2.4.18. the card is connected to a switch. and there is another machine with a 100baseT-FD card, connected to the switch, also. as the switch-leds indicate, these work fine, (and it's also advertising FD). banner message: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 05:00.0: 3Com PCI 3CCFE575BT Cyclone CardBus at 0x4800. Vers LK1.1.16 00:00:86:51:43:95, IRQ 10 product code 4e56 rev 07.1 date 03-10-98 05:00.0: CardBus functions mapped 11000080->c8bf9080 Internal config register is 1000000, transceivers 0x40. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT interface. Enabling bus-master transmits and whole-frame receives. scatter/gather enabled. h/w checksums enabled lspci -vx: 05:00.0 Ethernet controller: 3Com Corporation 3c575 [Megahertz] 10/100 LAN CardBus (rev 01) Subsystem: 3Com Corporation 3C575 Megahertz 10/100 LAN Cardbus PC Card Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at 4800 [size=128] Memory at 11000000 (32-bit, non-prefetchable) [size=128] Memory at 11000080 (32-bit, non-prefetchable) [size=128] Expansion ROM at 10c00000 [size=128K] Capabilities: [50] Power Management version 1 00: b7 10 57 51 07 00 10 02 01 00 00 02 00 40 00 00 10: 01 48 00 00 00 00 00 11 80 00 00 11 00 00 00 00 20: 00 00 00 00 00 00 00 00 90 00 00 00 b7 10 57 5b 30: 01 00 c0 10 50 00 00 00 00 00 00 00 0a 01 0a 05 eth0: Filling in the Rx ring. eth0: using NWAY device table, not 0 eth0: Initial media type Autonegotiate. vortex_up(): writing 0x1800000 to InternalConfig eth0: vortex_up() InternalConfig 01800000. eth0: MII #0 status 282d, link partner capability 45e1, info1 2010, setting full-duplex. outw(0x20, 0x4806) /* i've added this myself, just to see what happens */ eth0: vortex_up() InternalConfig 01800000. eth0: vortex_up() irq 10 media status a000. mii-diag -v: mii-diag.c:v2.02 5/21/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. The autonegotiated capability is 00a0. The autonegotiated media type is 100baseTx. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. This transceiver is capable of 100baseTx 10baseT. Able to perform Auto-negotiation, negotiation complete. Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. End of basic transceiver informaion. MII PHY #0 transceiver registers: 3000 282d 0300 e54b 00a1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0140 0000 0700 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x282d ... 282d. Link status: established. Capable of 100baseTx 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:c0:39:--:--:--, model 20 rev. 11. Vendor/Part: TDK transceiver (unknown type). I'm advertising 00a1: 100baseTx 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. TDK format vendor-specific registers 16..18 are 0x0140 0x0000 0x0700 Link polarity is detected as normal. Auto-negotiation complete, 100Mbps half duplex. Rx link in pass state, PLL slipped since last read. No new link status events. vortex-diag -aaee: vortex-diag.c:v2.05 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3CCFE575BT CardBus adapter at 0x4800. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 4, registers values by window: Window 0: 0000 0000 0000 0000 0000 06ff ffff 0000. Window 1: FIFO FIFO 0000 0000 0000 0000 0000 2000. Window 2: 0000 5186 9543 0000 0000 0000 0112 4000. Window 3: 0000 0180 05ea 0020 0040 1000 0800 6000. Window 4: 0000 0000 0000 0042 0003 a000 0000 8000. Window 5: 1ffc 0000 0000 0600 0807 0000 06c6 a000. Window 6: 0000 0000 0000 0000 0000 0000 0000 c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000. Vortex chip registers at 0x4800 0x4810: **FIFO** 00000000 0000000a *STATUS* 0x4820: 00000020 00000000 00080000 00000004 0x4830: 00000000 513faec1 00000000 00080004 Indication enable is 06c6, interrupt enable is 0000. No interrupt sources are pending. Transceiver/media interfaces available: MII. Transceiver type in use: Autonegotiate. MAC settings: full-duplex. Station address set to 00:00:86:51:43:95. Configuration options 0112. EEPROM contents (256 words, offset 0x30): 0x000: 10b7 5157 0007 0000 0001 0200 4000 0000 0x008: 0000 0000 0000 0000 0000 0000 0000 0000 0x010: 0000 0000 0000 0000 0090 0000 10b7 5b57 0x018: 0000 0000 0000 0000 0000 0000 0109 0a0a 0x020: 0000 0060 0000 0000 0000 0000 0000 0000 0x028: 0000 0000 0000 0000 0000 0000 0000 0000 0x030: 0000 8651 4395 5157 c46a 0036 564e 6d50 0x038: 3000 0009 0000 8651 4395 2010 0000 0006 0x040: 32a6 1570 0000 0060 0007 0000 0000 0022 0x048: 0313 4943 2053 0104 5701 0451 0306 0001 0x050: 0000 0500 410c 019a 1eb5 5501 3002 ffff 0x058: 0701 1106 4000 0000 1500 0534 3300 6f43 0x060: 206d 6f43 7072 726f 7461 6f69 006e 4333 0x068: 4643 3545 3537 5442 4c00 4e41 4320 7261 0x070: 6264 7375 4320 7261 0064 3030 0031 21ff 0x078: 0602 0501 0006 8080 8080 ff19 ffff ffff 0x080: ffff ffff ffff ffff ffff ffff ffff ffff 0x088: ffff ffff ffff ffff ffff ffff ffff ffff 0x090: ffff ffff ffff ffff ffff ffff ffff ffff 0x098: ffff ffff ffff ffff ffff ffff ffff ffff 0x0a0: ffff ffff ffff ffff ffff ffff ffff ffff 0x0a8: ffff ffff ffff ffff ffff ffff ffff ffff 0x0b0: ffff ffff ffff ffff ffff ffff ffff ffff 0x0b8: ffff ffff ffff ffff ffff ffff ffff ffff 0x0c0: ffff ffff ffff ffff ffff ffff ffff ffff 0x0c8: ffff ffff ffff ffff ffff ffff ffff ffff 0x0d0: ffff ffff ffff ffff ffff ffff ffff ffff 0x0d8: ffff ffff ffff ffff ffff ffff ffff ffff 0x0e0: ffff ffff ffff ffff ffff ffff ffff ffff 0x0e8: ffff ffff ffff ffff ffff ffff ffff ffff 0x0f0: ffff ffff ffff ffff ffff ffff ffff ffff 0x0f8: ffff ffff ffff ffff ffff ffff ffff ffff The word-wide EEPROM checksum is 0xc5a4. Saved EEPROM settings of a 3Com Vortex/Boomerang: The CardBus product ID is 10b7 5157. 3Com Node Address 00:00:86:51:43:95 (used as a unique ID only). OEM Station address 00:00:86:51:43:95 (used as the ethernet address). Manufacture date (MM/DD/YYYY) 3/10/1998, division 6, product NV. Options: negotiated duplex, link beat required. Vortex format checksum is correct (0022 vs. 0022). Cyclone format checksum is incorrect (0x1a vs. 00). Hurricane format checksum is incorrect (0x6b vs. 00). mii-tool -v: eth0: negotiated 100baseTx-HD, link ok product info: TDK 78Q2120 rev 11 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-HD 10baseT-HD advertising: 100baseTx-HD 10baseT-HD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control i'll be happily providing any information you need, and so on, and so forth.. thanks for your help, - till From owner-netdev@oss.sgi.com Fri Apr 19 11:53:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JIrM8d009331 for ; Fri, 19 Apr 2002 11:53:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JIrMju009330 for netdev-outgoing; Fri, 19 Apr 2002 11:53:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from yue.hongo.wide.ad.jp (root@yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JIrJ8d009327 for ; Fri, 19 Apr 2002 11:53:20 -0700 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id DAA13231; Sat, 20 Apr 2002 03:52:04 +0900 To: arif7290@hotmail.com Cc: netdev@oss.sgi.com Subject: Re: Linux IPv6 Bind failure with Invalid Argument In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020420035204V.yoshfuji@wide.ad.jp> Date: Sat, 20 Apr 2002 03:52:04 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 505 Lines: 12 In article (at Fri, 19 Apr 2002 18:29:53 +0000), "Md Arif" says: > Would you pls help me out in this regard. I am getting Bind failure with > error inValid argument Linux IPv6 machine(Kernel 2.4.7) > Same code works in Solaris IPv6. > Where is is bug????? please set sin6_scope_id in the sockaddr_in6{}. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From owner-netdev@oss.sgi.com Fri Apr 19 12:04:21 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JJ4L8d012193 for ; Fri, 19 Apr 2002 12:04:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JJ4Kgp012192 for netdev-outgoing; Fri, 19 Apr 2002 12:04:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JJ4C8d011593 for ; Fri, 19 Apr 2002 12:04:12 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.39 2002/04/15 17:47:23 root Exp $) with ESMTP id g3JJ3ao03675 for ; Fri, 19 Apr 2002 19:04:11 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3JJ6Do05295 for ; Fri, 19 Apr 2002 19:06:13 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041912082414646 ; Fri, 19 Apr 2002 12:08:24 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2HL0LCB7>; Fri, 19 Apr 2002 12:04:18 -0700 Message-ID: From: "Hossain, Mohammad" To: "'YOSHIFUJI Hideaki / ????'" , arif7290@hotmail.com Cc: netdev@oss.sgi.com Subject: RE: Linux IPv6 Bind failure with Invalid Argument Date: Fri, 19 Apr 2002 12:04:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 929 Lines: 30 Hello Hideaki, It seems my IPv6 address has link scope only. What value should be put in the scope id to pass the bind call? Is it because of the address has scope link??? Thanks Arif -----Original Message----- From: yoshfuji@wide.ad.jp [mailto:yoshfuji@wide.ad.jp] Sent: Friday, April 19, 2002 11:52 AM To: arif7290@hotmail.com Cc: netdev@oss.sgi.com Subject: Re: Linux IPv6 Bind failure with Invalid Argument In article (at Fri, 19 Apr 2002 18:29:53 +0000), "Md Arif" says: > Would you pls help me out in this regard. I am getting Bind failure with > error inValid argument Linux IPv6 machine(Kernel 2.4.7) > Same code works in Solaris IPv6. > Where is is bug????? please set sin6_scope_id in the sockaddr_in6{}. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From owner-netdev@oss.sgi.com Fri Apr 19 12:47:13 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JJlD8d012680 for ; Fri, 19 Apr 2002 12:47:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JJlDxb012679 for netdev-outgoing; Fri, 19 Apr 2002 12:47:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from yue.hongo.wide.ad.jp (root@yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JJl98d012676 for ; Fri, 19 Apr 2002 12:47:10 -0700 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id EAA13425; Sat, 20 Apr 2002 04:46:08 +0900 To: m_hossain@trillium.com Cc: arif7290@hotmail.com, netdev@oss.sgi.com Subject: RE: Linux IPv6 Bind failure with Invalid Argument In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020420044608I.yoshfuji@wide.ad.jp> Date: Sat, 20 Apr 2002 04:46:08 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 481 Lines: 14 In article (at Fri, 19 Apr 2002 12:04:09 -0700), "Hossain, Mohammad" says: > Hello Hideaki, > It seems my IPv6 address has link scope only. > What value should be put in the scope id to pass the bind call? > Is it because of the address has scope link??? ifindex at this moment. getaddrinfo() will help you. give fe80::xxx%ethX as host where ethX is eth0 or whatever. --yoshfuji From owner-netdev@oss.sgi.com Sun Apr 21 23:47:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3M6lIqf024242 for ; Sun, 21 Apr 2002 23:47:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3M6lItO024241 for netdev-outgoing; Sun, 21 Apr 2002 23:47:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3M6lBqf024215 for ; Sun, 21 Apr 2002 23:47:11 -0700 Received: (qmail 11013 invoked from network); 22 Apr 2002 06:47:14 -0000 Received: from pd950f0f5.dip.t-dialin.net (HELO ?192.168.1.2?) (217.80.240.245) by mail.bieringer.de with SMTP; 22 Apr 2002 06:47:14 -0000 Date: Mon, 22 Apr 2002 08:47:13 +0200 From: Peter Bieringer To: Maillist netdev Subject: Debug kernel network hook chain or why has Check Point Firewall module problems with IPv6 Message-ID: <22830000.1019458033@localhost> X-Mailer: Mulberry/2.2.0b4 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1450 Lines: 54 Hi, I found a for me strange issue and need help to dig a little bit into because I'm running out of knowledge. Pls. don't comment the use of commercial firewalls on Linux ;-) Running a Check Point Firewall (NG FP-2) on Linux (RHL kernel 2.4.9-31, OpenSSH 2.9 and 3.1) this loads its big firewall module into the kernel. First question: how can I check, which kernel network hooks it use? Are there any tools available? Now further on... "No problem" scenario: Linux is IPv4-only, openssh bound to 0.0.0.0, incoming SSH traffic is accepted and CP state table is updated "Problematic" scenario: Linux has ipv6 module loaded, openssh bound to ::, now following happen: incoming SSH traffic (still IPv4) is accepted, CP updates the initial connection timer but never update its state table to state "established". The initial timer is still updated after each keystroke, but if timeout occurs (default 60s), the connection will break. Looks like CP never sees (or recognizes) packets leaving the firewalled host from a dual-stack application. Second question: Can I trace such issues? Is there a toolset available which shows me which way a packet run in network kernel? BTW: incoming SSH traffic via IPv6 is completly unrecognized and therefore quietly accepted. Looks like CP never sees or recognize incoming IPv6 packets at all - same issue, if on a IPv4-netfiltererd box the IPv6-netfilter was forgotten... TIA, Peter From owner-netdev@oss.sgi.com Mon Apr 22 00:25:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3M7PDqf024682 for ; Mon, 22 Apr 2002 00:25:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3M7PDPF024681 for netdev-outgoing; Mon, 22 Apr 2002 00:25:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3M7P9qf024675 for ; Mon, 22 Apr 2002 00:25:09 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 7F0631E2DB; Mon, 22 Apr 2002 09:22:52 +0200 (MEST) Date: Mon, 22 Apr 2002 09:22:52 +0200 From: Andi Kleen To: Peter Bieringer Cc: Maillist netdev Subject: Re: Debug kernel network hook chain or why has Check Point Firewall module problems with IPv6 Message-ID: <20020422092252.A17861@wotan.suse.de> References: <22830000.1019458033@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22830000.1019458033@localhost> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 933 Lines: 25 On Mon, Apr 22, 2002 at 08:47:13AM +0200, Peter Bieringer wrote: > Looks like CP never sees (or recognizes) packets leaving the > firewalled host from a dual-stack application. Linux has no "generic" firewall hooks, only protocol specific ones. Checkpoint is probably using the v4 specific ones only. Other protocols can be received (by registering a protocol to ETH_P_ALL via SOCK_PACKET or in the kernel), but not stolen from protocol handlers. 2.2 had no working firewall chains for IPv6, 2.4 has a v6 netfilter interface. BTW the CheckPoint module seems to leak routes too at least on 2.2, there are regular reports of that. > BTW: incoming SSH traffic via IPv6 is completly unrecognized and > therefore quietly accepted. Looks like CP never sees or recognize > incoming IPv6 packets at all - same issue, if on a IPv4-netfiltererd > box the IPv6-netfilter was forgotten... Sounds like a serious CheckPoint bug. -Andi From owner-netdev@oss.sgi.com Mon Apr 22 01:53:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3M8rQqf025552 for ; Mon, 22 Apr 2002 01:53:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3M8rQIg025551 for netdev-outgoing; Mon, 22 Apr 2002 01:53:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3M8rMqf025545 for ; Mon, 22 Apr 2002 01:53:23 -0700 Received: (qmail 12823 invoked by uid 89); 22 Apr 2002 08:53:46 -0000 Message-ID: <20020422085346.12822.qmail@titan.bieringer.de> References: <22830000.1019458033@localhost> <20020422092252.A17861@wotan.suse.de> In-Reply-To: <20020422092252.A17861@wotan.suse.de> From: "Peter Bieringer" To: Andi Kleen Cc: Peter Bieringer , Maillist netdev Subject: Re: Debug kernel network hook chain or why has Check Point Firewall module problems with IPv6 Date: Mon, 22 Apr 2002 08:53:45 GMT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 736 Lines: 22 Hi Andi, thanks for fast answering, need only a short explanation now: Andi Kleen writes: > On Mon, Apr 22, 2002 at 08:47:13AM +0200, Peter Bieringer wrote: > > Looks like CP never sees (or recognizes) packets leaving the > > firewalled host from a dual-stack application. > > Linux has no "generic" firewall hooks, only protocol specific ones. > Checkpoint is probably using the v4 specific ones only. > Other protocols can be received (by registering a protocol to ETH_P_ALL via > SOCK_PACKET or in the kernel), but not stolen from protocol handlers. Is such IPv4 hook not seeing packets leaving a dual-stack application like openssh? Is there any scheme (the way such packet takes) available for visualisation. TIA, Peter From owner-netdev@oss.sgi.com Mon Apr 22 03:47:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MAlIqf027174 for ; Mon, 22 Apr 2002 03:47:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MAlIsl027173 for netdev-outgoing; Mon, 22 Apr 2002 03:47:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MAlFqf027169 for ; Mon, 22 Apr 2002 03:47:16 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id ABF5E1F07F; Mon, 22 Apr 2002 12:06:29 +0200 (MEST) Date: Mon, 22 Apr 2002 12:06:18 +0200 From: Andi Kleen To: Peter Bieringer Cc: Andi Kleen , Maillist netdev Subject: Re: Debug kernel network hook chain or why has Check Point Firewall module problems with IPv6 Message-ID: <20020422120618.A29547@wotan.suse.de> References: <22830000.1019458033@localhost> <20020422092252.A17861@wotan.suse.de> <20020422085346.12822.qmail@titan.bieringer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020422085346.12822.qmail@titan.bieringer.de> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 393 Lines: 10 On Mon, Apr 22, 2002 at 08:53:45AM +0000, Peter Bieringer wrote: > Is such IPv4 hook not seeing packets leaving a dual-stack application like > openssh? Is there any scheme (the way such packet takes) available for > visualisation. The v4 hook only sees packets that are sent as v4. The v6 hook only v6. It has nothing to do with the application using v4-mapped-on-v6 sockets or not. -Andi From owner-netdev@oss.sgi.com Mon Apr 22 05:47:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MClGqf029120 for ; Mon, 22 Apr 2002 05:47:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MClGA3029119 for netdev-outgoing; Mon, 22 Apr 2002 05:47:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MClCqf029112 for ; Mon, 22 Apr 2002 05:47:13 -0700 Received: (qmail 16886 invoked by uid 89); 22 Apr 2002 12:47:37 -0000 Message-ID: <20020422124737.16885.qmail@titan.bieringer.de> References: <22830000.1019458033@localhost> <20020422092252.A17861@wotan.suse.de> <20020422085346.12822.qmail@titan.bieringer.de> <20020422120618.A29547@wotan.suse.de> In-Reply-To: <20020422120618.A29547@wotan.suse.de> From: "Peter Bieringer" To: Andi Kleen Cc: Peter Bieringer , Maillist netdev Subject: Re: Debug kernel network hook chain or why has Check Point Firewall module problems with IPv6 Date: Mon, 22 Apr 2002 12:47:37 GMT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 555 Lines: 17 Andi Kleen writes: > On Mon, Apr 22, 2002 at 08:53:45AM +0000, Peter Bieringer wrote: > > Is such IPv4 hook not seeing packets leaving a dual-stack application like > > openssh? Is there any scheme (the way such packet takes) available for > > visualisation. > > The v4 hook only sees packets that are sent as v4. The v6 hook only v6. > It has nothing to do with the application using v4-mapped-on-v6 sockets > or not. Thanks for reply. Is there any tool available which can display which application has registered which network hooks? TIA, Peter From owner-netdev@oss.sgi.com Mon Apr 22 05:53:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MCrrqf029444 for ; Mon, 22 Apr 2002 05:53:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MCrrPo029443 for netdev-outgoing; Mon, 22 Apr 2002 05:53:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MCrmqf029438 for ; Mon, 22 Apr 2002 05:53:49 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 84F6B1E3E8; Mon, 22 Apr 2002 14:54:14 +0200 (MEST) Date: Mon, 22 Apr 2002 14:54:12 +0200 From: Andi Kleen To: Peter Bieringer Cc: Andi Kleen , Maillist netdev Subject: Re: Debug kernel network hook chain or why has Check Point Firewall module problems with IPv6 Message-ID: <20020422145412.A10284@wotan.suse.de> References: <22830000.1019458033@localhost> <20020422092252.A17861@wotan.suse.de> <20020422085346.12822.qmail@titan.bieringer.de> <20020422120618.A29547@wotan.suse.de> <20020422124737.16885.qmail@titan.bieringer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020422124737.16885.qmail@titan.bieringer.de> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 693 Lines: 19 On Mon, Apr 22, 2002 at 12:47:37PM +0000, Peter Bieringer wrote: > > Andi Kleen writes: > > > On Mon, Apr 22, 2002 at 08:53:45AM +0000, Peter Bieringer wrote: > > > Is such IPv4 hook not seeing packets leaving a dual-stack application like > > > openssh? Is there any scheme (the way such packet takes) available for > > > visualisation. > > > > The v4 hook only sees packets that are sent as v4. The v6 hook only v6. > > It has nothing to do with the application using v4-mapped-on-v6 sockets > > or not. > > Thanks for reply. Is there any tool available which can display which > application has registered which network hooks? Only a kernel debugger (gdb vmlinux /proc/kcore) -Andi From owner-netdev@oss.sgi.com Mon Apr 22 06:05:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MD5Oqf029762 for ; Mon, 22 Apr 2002 06:05:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MD5NwE029760 for netdev-outgoing; Mon, 22 Apr 2002 06:05:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MD5Lqf029756 for ; Mon, 22 Apr 2002 06:05:21 -0700 Received: (qmail 17248 invoked by uid 89); 22 Apr 2002 13:05:46 -0000 Message-ID: <20020422130546.17247.qmail@titan.bieringer.de> References: <22830000.1019458033@localhost> <20020422092252.A17861@wotan.suse.de> In-Reply-To: <20020422092252.A17861@wotan.suse.de> From: "Peter Bieringer" To: Andi Kleen Cc: Peter Bieringer , Maillist netdev Subject: Re: Debug kernel network hook chain or why has Check Point Firewall module problems with IPv6 Date: Mon, 22 Apr 2002 13:05:46 GMT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 216 Lines: 10 Andi Kleen writes: > BTW the CheckPoint module seems to leak routes too at least on 2.2, > there are regular reports of that. Can you explain what's happen? Perhaps caused by their implementation of NAT. Peter From owner-netdev@oss.sgi.com Mon Apr 22 06:08:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MD8Oqf029904 for ; Mon, 22 Apr 2002 06:08:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MD8OpJ029903 for netdev-outgoing; Mon, 22 Apr 2002 06:08:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MD8Iqf029900 for ; Mon, 22 Apr 2002 06:08:19 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id C243E1E41B; Mon, 22 Apr 2002 15:08:40 +0200 (MEST) Date: Mon, 22 Apr 2002 15:08:34 +0200 From: Andi Kleen To: Peter Bieringer Cc: Andi Kleen , Maillist netdev Subject: Re: Debug kernel network hook chain or why has Check Point Firewall module problems with IPv6 Message-ID: <20020422150834.A17495@wotan.suse.de> References: <22830000.1019458033@localhost> <20020422092252.A17861@wotan.suse.de> <20020422130546.17247.qmail@titan.bieringer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020422130546.17247.qmail@titan.bieringer.de> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 624 Lines: 17 On Mon, Apr 22, 2002 at 01:05:46PM +0000, Peter Bieringer wrote: > > Andi Kleen writes: > > > BTW the CheckPoint module seems to leak routes too at least on 2.2, > > there are regular reports of that. > > Can you explain what's happen? Perhaps caused by their implementation of > NAT. I have no idea what happens exactly, except that there were several reports to this list of users who ran into problems with an overflowing routing cache. All they had in common was that they run CheckPoint on 2.2. There were no other such reports from non BreakPoint users. I may be fixed in the 2.4 version of their module. -Andi From owner-netdev@oss.sgi.com Tue Apr 23 11:15:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NIFqwJ029507 for ; Tue, 23 Apr 2002 11:15:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NIFqbf029506 for netdev-outgoing; Tue, 23 Apr 2002 11:15:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NIFkwJ029503 for ; Tue, 23 Apr 2002 11:15:47 -0700 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.1/8.11.1) with ESMTP id g3NIG6X20940; Tue, 23 Apr 2002 20:16:07 +0200 (MET DST) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id g3NIG6X03192; Tue, 23 Apr 2002 20:16:06 +0200 Date: Tue, 23 Apr 2002 20:16:06 +0200 (CEST) From: Bogdan Costescu To: Trond Myklebust cc: nfs@lists.sourceforge.net, Subject: Re: [NFS] nfs performance: read only/gigE/nolock/1Tb per day In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1558 Lines: 40 [ cc-ed to netdev; the discussion was about receiving bursts of ICMP Time Exceeded messages after some large NFS datagrams could not be reassembled; sometimes down/up the interface on the receiver/reassembly side cures it ] On 23 Apr 2002, Trond Myklebust wrote: > > How big are the datagrams compared with the MTU ? With 32K > > datagrams over Ethernet, you're talking about roughly a full Rx > > ring worth of packets (32 is common for the Rx ring size)... > > It has been a while ago (I've since mothballed the machine) but I saw > it on a Pentium 90 with only 8k write sizes. 4k was fine, 8k gave > avalanches. IMHO you can't comletely eliminate hardware related problems: apart from having a slow CPU, some early PCI implementations were buggy (although you don't say if it's PCI or ISA and what's the link speed). > > Does the other side sees these messages ? > > IIRC, yes, and the server was resending the datagrams. From the code, > it looks as if there is no attempt to stop loopback situations > occurring when this goes on: > i.e. resending an ICMP when the server resends a datagram which times > out again appears to be possible. This might be what was happening... That's why I cc-ed netdev. My knowledge above the driver level is close to non-existant... -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-netdev@oss.sgi.com Wed Apr 24 08:14:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OFEnwJ024066 for ; Wed, 24 Apr 2002 08:14:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OFEn02024065 for netdev-outgoing; Wed, 24 Apr 2002 08:14:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OFEjwJ024062 for ; Wed, 24 Apr 2002 08:14:46 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id BAA11203 for ; Thu, 25 Apr 2002 01:15:06 +1000 Date: Thu, 25 Apr 2002 01:15:06 +1000 (EST) From: James Morris To: netdev@oss.sgi.com Subject: Tigon 3 driver & Netgear GA302T Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 155 Lines: 10 Does the tg3 driver support the Netgear GA302T card (which I think uses the Altima AC1000 chip) ? - James -- James Morris From owner-netdev@oss.sgi.com Wed Apr 24 08:21:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OFLkwJ024364 for ; Wed, 24 Apr 2002 08:21:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OFLkMO024363 for netdev-outgoing; Wed, 24 Apr 2002 08:21:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from trained-monkey.org (IDENT:root@trained-monkey.org [209.217.122.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OFLewJ024355 for ; Wed, 24 Apr 2002 08:21:40 -0700 Received: (from jes@localhost) by trained-monkey.org (8.11.6/8.9.3) id g3OFM0801059; Wed, 24 Apr 2002 11:22:00 -0400 To: James Morris Cc: netdev@oss.sgi.com Subject: Re: Tigon 3 driver & Netgear GA302T References: From: Jes Sorensen Date: 24 Apr 2002 11:21:59 -0400 In-Reply-To: James Morris's message of "Thu, 25 Apr 2002 01:15:06 +1000 (EST)" Message-ID: X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 422 Lines: 16 >>>>> "James" == James Morris writes: James> Does the tg3 driver support the Netgear GA302T card (which I James> think uses the Altima AC1000 chip) ? If it's the Altima then I guess so, otherwise I'd expect the 83820 driver to run it. >From the list of devices for tg3: #ifndef PCI_VENDOR_ID_ALTIMA #define PCI_VENDOR_ID_ALTIMA 0x173b #define PCI_DEVICE_ID_ALTIMA_AC1000 0x03e8 #endif Jes From owner-netdev@oss.sgi.com Wed Apr 24 08:53:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OFrhwJ025752 for ; Wed, 24 Apr 2002 08:53:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OFrhu2025751 for netdev-outgoing; Wed, 24 Apr 2002 08:53:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OFrcwJ025748 for ; Wed, 24 Apr 2002 08:53:39 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id BAA11353; Thu, 25 Apr 2002 01:53:58 +1000 Date: Thu, 25 Apr 2002 01:53:58 +1000 (EST) From: James Morris To: Jes Sorensen cc: netdev@oss.sgi.com Subject: Re: Tigon 3 driver & Netgear GA302T In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 579 Lines: 24 On 24 Apr 2002, Jes Sorensen wrote: > >>>>> "James" == James Morris writes: > > James> Does the tg3 driver support the Netgear GA302T card (which I > James> think uses the Altima AC1000 chip) ? > > If it's the Altima then I guess so, otherwise I'd expect the 83820 > driver to run it. > It appears to be the Altima, from the Freebsd cvs log comments & associated changes for their bge driver. I'll be getting a couple of the cards on Friday and should find out pretty quickly after that. - James -- James Morris From owner-netdev@oss.sgi.com Fri Apr 26 03:14:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QAETwJ004739 for ; Fri, 26 Apr 2002 03:14:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QAETTs004738 for netdev-outgoing; Fri, 26 Apr 2002 03:14:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QAEMwJ004735 for ; Fri, 26 Apr 2002 03:14:24 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id UAA17969; Fri, 26 Apr 2002 20:14:47 +1000 Date: Fri, 26 Apr 2002 20:14:47 +1000 (EST) From: James Morris To: Jes Sorensen cc: netdev@oss.sgi.com Subject: Re: Tigon 3 driver & Netgear GA302T In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 852 Lines: 33 On Thu, 25 Apr 2002, James Morris wrote: > On 24 Apr 2002, Jes Sorensen wrote: > > > >>>>> "James" == James Morris writes: > > > > James> Does the tg3 driver support the Netgear GA302T card (which I > > James> think uses the Altima AC1000 chip) ? > > > > If it's the Altima then I guess so, otherwise I'd expect the 83820 > > driver to run it. > > > > It appears to be the Altima, from the Freebsd cvs log comments & > associated changes for their bge driver. > Confirmed: eth2: Tigon3 [partno(BAC91000A1) rev 7104 PHY(5411)] (PCI:33MHz:32-bit) 10/100/1000BaseT Ethernet 00:40:f4:35:f1:77 eth2: Link is up at 100 Mbps, full duplex. eth2: Flow control is off for TX and off for RX. Unfortunately, it's not successfully transmitting or receiving any packets. - James -- James Morris From owner-netdev@oss.sgi.com Fri Apr 26 06:09:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QD9mwJ008513 for ; Fri, 26 Apr 2002 06:09:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QD9mRa008512 for netdev-outgoing; Fri, 26 Apr 2002 06:09:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QD9LwJ008507 for ; Fri, 26 Apr 2002 06:09:21 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA06658 for ; Fri, 26 Apr 2002 06:09:33 -0700 (PDT) mail_from (Robert.Olsson@data.slu.se) Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id OAA30600; Fri, 26 Apr 2002 14:55:03 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="lNLPauBgfS" Content-Transfer-Encoding: 7bit Message-ID: <15561.20004.964497.762468@robur.slu.se> Date: Fri, 26 Apr 2002 14:55:00 +0200 To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, hadi@cyberus.ca, netdev@oss.sgi.com, jensl@robur.slu.se Subject: route cache GC monitoring X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 14751 Lines: 240 --lNLPauBgfS Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Hello! We like to propose four new stats. counters to monitor the garbage process of route cache. This should be useful for tuning and debugging installations which have a large number of flows. Tuning is another business but we have played with max_size and gc_thresh there are more tuning knobs. The number of buckets in the hash table is something to tune as well be but we have not experimented with this here. Anyway for most installations the "default" setting does a very good job but when we see high numbers in the new GC counters one should be warned. Kernel patch. --lNLPauBgfS Content-Type: application/octet-stream Content-Disposition: attachment; filename="GC.pat" Content-Transfer-Encoding: base64 LS0tIGxpbnV4L2luY2x1ZGUvbmV0L3JvdXRlLmgub3JpZwlNb24gRmViIDI1IDIwOjM4OjEz IDIwMDIKKysrIGxpbnV4L2luY2x1ZGUvbmV0L3JvdXRlLmgJRnJpIEFwciAxOSAxNTo1MDoy MCAyMDAyCkBAIC0xMTAsNiArMTEwLDEwIEBACiAgICAgICAgIHVuc2lnbmVkIGludCBvdXRf aGl0OwogICAgICAgICB1bnNpZ25lZCBpbnQgb3V0X3Nsb3dfdG90OwogICAgICAgICB1bnNp Z25lZCBpbnQgb3V0X3Nsb3dfbWM7CisgICAgICAgIHVuc2lnbmVkIGludCBnY190b3RhbDsK KyAgICAgICAgdW5zaWduZWQgaW50IGdjX2lnbm9yZWQ7CisgICAgICAgIHVuc2lnbmVkIGlu dCBnY19nb2FsX21pc3M7CisgICAgICAgIHVuc2lnbmVkIGludCBnY19kc3Rfb3ZlcmZsb3c7 CiB9IF9fX19jYWNoZWxpbmVfYWxpZ25lZF9pbl9zbXA7CiAKIGV4dGVybiBzdHJ1Y3QgaXBf cnRfYWNjdCAqaXBfcnRfYWNjdDsKLS0tIGxpbnV4L25ldC9pcHY0L3JvdXRlLmMub3JpZwlU aHUgQXByIDE4IDA3OjQzOjQ0IDIwMDIKKysrIGxpbnV4L25ldC9pcHY0L3JvdXRlLmMJRnJp IEFwciAyNiAxMToyNzoxNiAyMDAyCkBAIC0yODYsNyArMjg2LDcgQEAKICAgICAgICAgZm9y IChsY3B1ID0gMDsgbGNwdSA8IHNtcF9udW1fY3B1czsgbGNwdSsrKSB7CiAgICAgICAgICAg ICAgICAgaSA9IGNwdV9sb2dpY2FsX21hcChsY3B1KTsKIAotCQlsZW4gKz0gc3ByaW50Zihi dWZmZXIrbGVuLCAiJTA4eCAgJTA4eCAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHggJTA4eCAg JTA4eCAlMDh4ICUwOHhcbiIsCisJCWxlbiArPSBzcHJpbnRmKGJ1ZmZlcitsZW4sICIlMDh4 ICAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHggJTA4eCAlMDh4ICAlMDh4ICUwOHggJTA4eCAl MDh4ICUwOHggJTA4eCAlMDh4IFxuIiwKIAkJCSAgICAgICBkc3RfZW50cmllcywJCSAgICAg ICAKIAkJCSAgICAgICBydF9jYWNoZV9zdGF0W2ldLmluX2hpdCwKIAkJCSAgICAgICBydF9j YWNoZV9zdGF0W2ldLmluX3Nsb3dfdG90LApAQCAtMjk4LDcgKzI5OCwxMyBAQAogCiAJCQkg ICAgICAgcnRfY2FjaGVfc3RhdFtpXS5vdXRfaGl0LAogCQkJICAgICAgIHJ0X2NhY2hlX3N0 YXRbaV0ub3V0X3Nsb3dfdG90LAotCQkJICAgICAgIHJ0X2NhY2hlX3N0YXRbaV0ub3V0X3Ns b3dfbWMKKwkJCSAgICAgICBydF9jYWNoZV9zdGF0W2ldLm91dF9zbG93X21jLCAKKworCQkJ ICAgICAgIHJ0X2NhY2hlX3N0YXRbaV0uZ2NfdG90YWwsCisJCQkgICAgICAgcnRfY2FjaGVf c3RhdFtpXS5nY19pZ25vcmVkLAorCQkJICAgICAgIHJ0X2NhY2hlX3N0YXRbaV0uZ2NfZ29h bF9taXNzLAorCQkJICAgICAgIHJ0X2NhY2hlX3N0YXRbaV0uZ2NfZHN0X292ZXJmbG93CisK IAkJCSk7CiAJfQogCWxlbiAtPSBvZmZzZXQ7CkBAIC00OTksOSArNTA1LDE0IEBACiAJICog R2FyYmFnZSBjb2xsZWN0aW9uIGlzIHByZXR0eSBleHBlbnNpdmUsCiAJICogZG8gbm90IG1h a2UgaXQgdG9vIGZyZXF1ZW50bHkuCiAJICovCisKKwlydF9jYWNoZV9zdGF0W3NtcF9wcm9j ZXNzb3JfaWQoKV0uZ2NfdG90YWwrKzsKKwogCWlmIChub3cgLSBsYXN0X2djIDwgaXBfcnRf Z2NfbWluX2ludGVydmFsICYmCi0JICAgIGF0b21pY19yZWFkKCZpcHY0X2RzdF9vcHMuZW50 cmllcykgPCBpcF9ydF9tYXhfc2l6ZSkKKwkgICAgYXRvbWljX3JlYWQoJmlwdjRfZHN0X29w cy5lbnRyaWVzKSA8IGlwX3J0X21heF9zaXplKSB7CisJCXJ0X2NhY2hlX3N0YXRbc21wX3By b2Nlc3Nvcl9pZCgpXS5nY19pZ25vcmVkKys7CiAJCWdvdG8gb3V0OworCX0KIAogCS8qIENh bGN1bGF0ZSBudW1iZXIgb2YgZW50cmllcywgd2hpY2ggd2Ugd2FudCB0byBleHBpcmUgbm93 LiAqLwogCWdvYWwgPSBhdG9taWNfcmVhZCgmaXB2NF9kc3Rfb3BzLmVudHJpZXMpIC0KQEAg LTU2Nyw2ICs1NzgsOCBAQAogCQkgICAgIFdlIHdpbGwgbm90IHNwaW4gaGVyZSBmb3IgbG9u ZyB0aW1lIGluIGFueSBjYXNlLgogCQkgKi8KIAorCQlydF9jYWNoZV9zdGF0W3NtcF9wcm9j ZXNzb3JfaWQoKV0uZ2NfZ29hbF9taXNzKys7CisKIAkJaWYgKGV4cGlyZSA9PSAwKQogCQkJ YnJlYWs7CiAKQEAgLTU4NCw2ICs1OTcsNyBAQAogCQlnb3RvIG91dDsKIAlpZiAobmV0X3Jh dGVsaW1pdCgpKQogCQlwcmludGsoS0VSTl9XQVJOSU5HICJkc3QgY2FjaGUgb3ZlcmZsb3dc biIpOworCXJ0X2NhY2hlX3N0YXRbc21wX3Byb2Nlc3Nvcl9pZCgpXS5nY19kc3Rfb3ZlcmZs b3crKzsKIAlyZXR1cm4gMTsKIAogd29ya19kb25lOgo= --lNLPauBgfS Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Use/Experiment. --lNLPauBgfS Content-Type: application/octet-stream Content-Disposition: attachment; filename="usage" Content-Transfer-Encoding: base64 Ckp1bGlhbiBBbmF0YXNvdnMgdGVzdCBwcm9ncmFtLiBVc2luZyA4MDAwMCBkaWZmZXJlbnQg c291cmNlcy4KdGVzdGx2cyB4Lnkuejo4MCAtdWRwIC1zcmNudW0gODAwMDAgLXBhY2tldHMg MAoKCnRvdCAgICAgPT0gR0M6IHRvdGFsIGNhbGxzIHBlciBzZWMKaWdub3JlZCA9PSBHQzog Y2FsbHMgaWdub3JlZCBwZXIgc2VjCmdvYWxfbWlzcyAgPT0gR0M6IGdvYWwgbWlzcyBwZXIg c2VjCm92cmZsdyAgPT0gR0M6IGRzdF9vdmVyZmxvdyBwZXIgc2VjCgpOb3QgbG9hZGVkOgot LS0tLS0tLS0tCm1heF9zaXplIDY1NTM2CmdjX3RocmVzaCA0MDk2CiBzaXplICAgSU46IGhp dCAgICAgdG90ICAgIG1jIG5vX3J0IGJjYXN0IG1hZHN0IG1hc3JjICBPVVQ6IGhpdCAgICAg dG90ICAgICBtYyBHQzogdG90IGlnbm9yZWQgZ29hbF9taXNzIG92cmYKICAgMTEgICAgICAg MTM0ICAgIDExNTkgICAgIDQgICAgIDAgICAgMTUgICAgIDAgICAgIDAgICAgICAgMTQ2ICAg ICA4NTQgICAgICAwICAgICAgIDAgICAgICAgMCAgICAgICAgIDAgICAgMAogICAxMSAgICAg ICAgIDAgICAgICAgMSAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgICAgIDAg ICAgICAgMCAgICAgIDAgICAgICAgMCAgICAgICAwICAgICAgICAgMCAgICAwCiAgIDExICAg ICAgICAgMCAgICAgICAxICAgICAwICAgICAwICAgICAwICAgICAwICAgICAwICAgICAgICAg MCAgICAgICAwICAgICAgMCAgICAgICAwICAgICAgIDAgICAgICAgICAwICAgIDAKICAgMTEg ICAgICAgICAwICAgICAgIDMgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgICAg ICAwICAgICAgIDAgICAgICAwICAgICAgIDAgICAgICAgMCAgICAgICAgIDAgICAgMAoKQ2Fj aGUgdG9vIHNtYWxsOgotLS0tLS0tLS0tLS0tLS0KbWF4X3NpemUgMjAwMApnY190aHJlc2gg MTAwMAogc2l6ZSAgIElOOiBoaXQgICAgIHRvdCAgICBtYyBub19ydCBiY2FzdCBtYWRzdCBt YXNyYyAgT1VUOiBoaXQgICAgIHRvdCAgICAgbWMgR0M6IHRvdCBpZ25vcmVkIGdvYWxfbWlz cyBvdnJmCiAyMDAwICAgICAgIDU0MSAxMzI2NzM3ICAgICA0ICAgICAwICAgIDM5ICAgICAw ICAgICAwICAgICAgIDU0MiAxMzIxNjYyICAgICAgMCAxMjg2NTYzIDEwMDk2NzMgICAgICAz OTQ2IDM5NDYKIDIwMDAgICAgICAgICAwICAgICA4NzYgICAgIDAgICAgIDAgICAgIDAgICAg IDAgICAgIDAgICAgICAgICAwICAgICA4MDggICAgICAwICAgIDE3MjQgICAgICAxOCAgICAg ICAgNjcgICA2NwogMjAwMCAgICAgICAgIDAgICAgIDg3NyAgICAgMCAgICAgMCAgICAgMCAg ICAgMCAgICAgMCAgICAgICAgIDAgICAgIDgxMCAgICAgIDAgICAgMTcxOSAgICAgIDEwICAg ICAgICA2NSAgIDY1CiAyMDAwICAgICAgICAgMCAgICAgODc2ICAgICAwICAgICAwICAgICAw ICAgICAwICAgICAwICAgICAgICAgMCAgICAgODA5ICAgICAgMCAgICAxNzIzICAgICAgMTcg ICAgICAgIDY2ICAgNjYKIDIwMDAgICAgICAgICAwICAgICA4NzYgICAgIDAgICAgIDAgICAg IDAgICAgIDAgICAgIDAgICAgICAgICAwICAgICA4MDggICAgICAwICAgIDE3MjMgICAgICAg NyAgICAgICAgNjcgICA2NwogMjAwMCAgICAgICAgIDAgICAgIDg3NSAgICAgMCAgICAgMCAg ICAgMCAgICAgMCAgICAgMCAgICAgICAgIDAgICAgIDgwNyAgICAgIDAgICAgMTcyMiAgICAg IDExICAgICAgICA2NyAgIDY3CiAyMDAwICAgICAgICAgMCAgICAgODc1ICAgICAwICAgICAw ICAgICAwICAgICAwICAgICAwICAgICAgICAgMCAgICAgODA2ICAgICAgMCAgICAxNzEzICAg ICAgIDYgICAgICAgIDY5ICAgNjkKIDIwMDAgICAgICAgICAwICAgICA4NzUgICAgIDAgICAg IDAgICAgIDAgICAgIDAgICAgIDAgICAgICAgICAwICAgICA4MDcgICAgICAwICAgIDE3MjAg ICAgICAxMyAgICAgICAgNjggICA2OAogMjAwMCAgICAgICAgIDAgICAgIDg3NSAgICAgMCAg ICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgICAgIDAgICAgIDgxMCAgICAgIDAgICAgMTcy NyAgICAgIDEwICAgICAgICA2NSAgIDY1CgpDYWNoZSBzdGlsbCAidG9vIiBzbWFsbCBidXQg bm8gZHN0IG92ZXJmbG93OgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQptYXhfc2l6ZSA4MDAwCmdjX3RocmVzaCA0MDAwCiBzaXplICAgSU46IGhpdCAg ICAgdG90ICAgIG1jIG5vX3J0IGJjYXN0IG1hZHN0IG1hc3JjICBPVVQ6IGhpdCAgICAgdG90 ICAgICBtYyBHQzogdG90IGlnbm9yZWQgZ29hbF9taXNzIG92cmYKIDM0MDggICAgICAgNTUx IDEzNzQ1MzAgICAgIDQgICAgIDAgICAgMzkgICAgIDAgICAgIDAgICAgICAgNTU4IDEzNjYw NTggICAgICAwIDEzNzcwNzQgMTAxMDMxNCAgICAgIDczMTMgNzMxMwogNDc0MyAgICAgICAg IDAgICAgIDY3MyAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgICAgIDAgICAg IDY3MSAgICAgIDAgICAgIDc0MyAgICAgNzQyICAgICAgICAgMCAgICAwCiA1ODgwICAgICAg ICAgMCAgICAgNTY5ICAgICAwICAgICAwICAgICAwICAgICAwICAgICAwICAgICAgICAgMCAg ICAgNTY4ICAgICAgMCAgICAxMTM3ICAgIDExMzcgICAgICAgICAwICAgIDAKIDc2MTAgICAg ICAgICAwICAgICA4NjEgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgICAgICAw ICAgICA4NjEgICAgICAwICAgIDE3MjIgICAgMTcyMiAgICAgICAgIDAgICAgMAogNzM0OCAg ICAgICAgIDAgICAgIDg3MiAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgICAg IDAgICAgIDg3MSAgICAgIDAgICAgMTc0MiAgICAxNzQxICAgICAgICAgMCAgICAwCiA3NTYz ICAgICAgICAgMCAgICAgODcyICAgICAwICAgICAwICAgICAwICAgICAwICAgICAwICAgICAg ICAgMCAgICAgODcwICAgICAgMCAgICAxNzQwICAgIDE3MzggICAgICAgICAwICAgIDAKIDc5 NjMgICAgICAgICAwICAgICA4NzIgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAg ICAgICAwICAgICA4NzEgICAgICAwICAgIDE3NDIgICAgMTcxOCAgICAgICAgIDAgICAgMAog Nzk3NiAgICAgICAgIDAgICAgIDg3MyAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAg ICAgICAgIDAgICAgIDg3MSAgICAgIDAgICAgMTc0MiAgICAxNzA0ICAgICAgICAgMCAgICAw CiA3OTU2ICAgICAgICAgMCAgICAgODcyICAgICAwICAgICAwICAgICAwICAgICAwICAgICAw ICAgICAgICAgMCAgICAgODcxICAgICAgMCAgICAxNzQyICAgIDE3MDggICAgICAgICAwICAg IDAKIDc5NzAgICAgICAgICAwICAgICA4NzYgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAg IDAgICAgICAgICAwICAgICA4NzUgICAgICAwICAgIDE3NTAgICAgMTcxMiAgICAgICAgIDAg ICAgMAoKTW9yZSBkZWNlbnQgc2V0dGluZ3M6IChvc2NpbGxhdGluZyBhcm91bmQgZ2NfdGhy ZXNoKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCm1heF9zaXplIDk0MDAwCmdjX3RocmVzaCA0NzAwMAogc2l6ZSAgIElOOiBoaXQgICAg IHRvdCAgICBtYyBub19ydCBiY2FzdCBtYWRzdCBtYXNyYyAgT1VUOiBoaXQgICAgIHRvdCAg ICAgbWMgR0M6IHRvdCBpZ25vcmVkIGdvYWxfbWlzcyBvdnJmCjQyNDkwICAgICAgIDU1OSAx NDQyNjc3ICAgICA2ICAgICAwICAgIDQ2ICAgICAwICAgICAwICAgICAgIDU3NCAxNDM0MTM4 ICAgICAgMCAxNDQ1Nzk1IDEwNzc3NzcgICAgICA3MzEzIDczMTMKNDM4NjQgICAgICAgICAw ICAgICA2ODYgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgICAgICAwICAgICA2 ODUgICAgICAwICAgICAgIDAgICAgICAgMCAgICAgICAgIDAgICAgMAo0NTIyNCAgICAgICAg IDAgICAgIDY3NiAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgICAgIDAgICAg IDY3NSAgICAgIDAgICAgICAgMCAgICAgICAwICAgICAgICAgMCAgICAwCjQ2NjE2ICAgICAg ICAgMCAgICAgNjkxICAgICAwICAgICAwICAgICAwICAgICAwICAgICAwICAgICAgICAgMCAg ICAgNjkxICAgICAgMCAgICAgICAwICAgICAgIDAgICAgICAgICAwICAgIDAKNDA1MTggICAg ICAgICAwICAgICA2ODQgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgICAgICAw ICAgICA2ODQgICAgICAwICAgICA2NjAgICAgIDY1OSAgICAgICAgIDAgICAgMAo0MTk0OCAg ICAgICAgIDAgICAgIDcxMSAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgICAg IDAgICAgIDcxMSAgICAgIDAgICAgICAgMCAgICAgICAwICAgICAgICAgMCAgICAwCjQzNjk4 ICAgICAgICAgMyAgICAgODcxICAgICAwICAgICAwICAgICAwICAgICAwICAgICAwICAgICAg ICAgNyAgICAgODcxICAgICAgMCAgICAgICAwICAgICAgIDAgICAgICAgICAwICAgIDAKNDU0 NDggICAgICAgICAyICAgICA4NzIgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAg ICAgICAzICAgICA4NzIgICAgICAwICAgICAgIDAgICAgICAgMCAgICAgICAgIDAgICAgMAo0 NzE5OCAgICAgICAgIDAgICAgIDg3MSAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAg ICAgICAgIDAgICAgIDg3MSAgICAgIDAgICAgIDE5NyAgICAgMTk3ICAgICAgICAgMCAgICAw CjQwOTgwICAgICAgICAgMCAgICAgODcyICAgICAwICAgICAwICAgICAwICAgICAwICAgICAw ICAgICAgICAgMCAgICAgODcyICAgICAgMCAgICAxMjA3ICAgIDEyMDYgICAgICAgICAwICAg IDAKNDI1MzQgICAgICAgICAwICAgICA3NzQgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAg IDAgICAgICAgICAwICAgICA3NzMgICAgICAwICAgICAgIDAgICAgICAgMCAgICAgICAgIDAg ICAgMAo0NDA2MiAgICAgICAgIDAgICAgIDc2NCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAg ICAgMCAgICAgICAgIDAgICAgIDc2NCAgICAgIDAgICAgICAgMCAgICAgICAwICAgICAgICAg MCAgICAwCjQ1MjYwICAgICAgICAgMCAgICAgNTk2ICAgICAwICAgICAwICAgICAwICAgICAw ICAgICAwICAgICAgICAgMCAgICAgNTk1ICAgICAgMCAgICAgICAwICAgICAgIDAgICAgICAg ICAwICAgIDAKNDY1MDggICAgICAgICAwICAgICA2MjEgICAgIDAgICAgIDAgICAgIDAgICAg IDAgICAgIDAgICAgICAgICAwICAgICA2MjAgICAgICAwICAgICAgIDAgICAgICAgMCAgICAg ICAgIDAgICAgMAo0MDA4MSAgICAgICAgIDAgICAgIDU2MSAgICAgMCAgICAgMCAgICAgMCAg ICAgMCAgICAgMCAgICAgICAgIDAgICAgIDU2MCAgICAgIDAgICAgIDIyNyAgICAgMjI2ICAg ICAgICAgMCAgICAwCjQxODM1ICAgICAgICAgMCAgICAgODc0ICAgICAwICAgICAwICAgICAw ICAgICAwICAgICAwICAgICAgICAgMCAgICAgODczICAgICAgMCAgICAgICAwICAgICAgIDAg ICAgICAgICAwICAgIDAKNDM1ODEgICAgICAgICAwICAgICA4NzAgICAgIDAgICAgIDAgICAg IDAgICAgIDAgICAgIDAgICAgICAgICAwICAgICA4NjkgICAgICAwICAgICAgIDAgICAgICAg MCAgICAgICAgIDAgICAgMAo0NTMzMCAgICAgICAgIDAgICAgIDg3MiAgICAgMCAgICAgMCAg ICAgMSAgICAgMCAgICAgMCAgICAgICAgIDAgICAgIDg3MCAgICAgIDAgICAgICAgMCAgICAg ICAwICAgICAgICAgMCAgICAwCjQ3MDgyICAgICAgICAgMCAgICAgODcyICAgICAwICAgICAw ICAgICAwICAgICAwICAgICAwICAgICAgICAgMCAgICAgODcyICAgICAgMCAgICAgIDgxICAg ICAgODEgICAgICAgICAwICAgIDAKNDA5MTAgICAgICAgICAwICAgICA4NzEgICAgIDAgICAg IDAgICAgIDAgICAgIDAgICAgIDAgICAgICAgICAwICAgICA4NzEgICAgICAwICAgIDEwMzEg ICAgMTAzMCAgICAgICAgIDAgICAgMAoKT3B0aW11bSAoPykgc2V0dGluZyBmb3IgdGhpcyBs b2FkOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm1heF9zaXplIDEwMDAw MApnY190aHJlc2ggNTAwMDAKIHNpemUgICBJTjogaGl0ICAgICB0b3QgICAgbWMgbm9fcnQg YmNhc3QgbWFkc3QgbWFzcmMgIE9VVDogaGl0ICAgICB0b3QgICAgIG1jIEdDOiB0b3QgaWdu b3JlZCBnb2FsX21pc3Mgb3ZyZgo0MjI3MSAgICAgICA1ODkgMTUyOTk2MyAgICAgNiAgICAg MCAgICA1MiAgICAgMCAgICAgMCAgICAgICA2MTAgMTUyMTM0MSAgICAgIDAgMTQ1NjM5NCAx MDg4MzYyICAgICAgNzMxMyA3MzEzCjQ0MDAxICAgICAgICAgMCAgICAgODY2ICAgICAwICAg ICAwICAgICAwICAgICAwICAgICAwICAgICAgICAgMCAgICAgODY1ICAgICAgMCAgICAgICAw ICAgICAgIDAgICAgICAgICAwICAgIDAKNDU3NDMgICAgICAgICAwICAgICA4NzIgICAgIDAg ICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgICAgICAwICAgICA4NzEgICAgICAwICAgICAg IDAgICAgICAgMCAgICAgICAgIDAgICAgMAo0NzQ5MSAgICAgICAgIDAgICAgIDg3NSAgICAg MCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgICAgIDAgICAgIDg3NCAgICAgIDAgICAg ICAgMCAgICAgICAwICAgICAgICAgMCAgICAwCjQ5MjQxICAgICAgICAgMCAgICAgODc1ICAg ICAwICAgICAwICAgICAwICAgICAwICAgICAwICAgICAgICAgMCAgICAgODc1ICAgICAgMCAg ICAgICAwICAgICAgIDAgICAgICAgICAwICAgIDAKNDIzMjYgICAgICAgICAwICAgICA4NjAg ICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgICAgICAwICAgICA4NjAgICAgICAw ICAgICAgIDEgICAgICAgMCAgICAgICAgIDAgICAgMAo0NDA3NSAgICAgICAgIDAgICAgIDg3 NiAgICAgMCAgICAgMCAgICAgMSAgICAgMCAgICAgMCAgICAgICAgIDAgICAgIDg3NCAgICAg IDAgICAgICAgMCAgICAgICAwICAgICAgICAgMCAgICAwCjQ1ODI1ICAgICAgICAgMCAgICAg ODc2ICAgICAwICAgICAwICAgICAwICAgICAwICAgICAwICAgICAgICAgMCAgICAgODc1ICAg ICAgMCAgICAgICAwICAgICAgIDAgICAgICAgICAwICAgIDAKNDc1NzQgICAgICAgICAwICAg ICA4NzYgICAgIDEgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgICAgICAwICAgICA4NzQg ICAgICAwICAgICAgIDAgICAgICAgMCAgICAgICAgIDAgICAgMAo0OTMxNiAgICAgICAgIDAg ICAgIDg3MiAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgICAgIDAgICAgIDg3 MSAgICAgIDAgICAgICAgMCAgICAgICAwICAgICAgICAgMCAgICAwCjQyMzczICAgICAgICAg MCAgICAgODc2ICAgICAwICAgICAwICAgICAwICAgICAwICAgICAwICAgICAgICAgMCAgICAg ODc1ICAgICAgMCAgICAgICA4ICAgICAgIDcgICAgICAgICAwICAgIDAKNDQxMjEgICAgICAg ICAwICAgICA4NzUgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgICAgICAwICAg ICA4NzQgICAgICAwICAgICAgIDAgICAgICAgMCAgICAgICAgIDAgICAgMAo0NTg3MyAgICAg ICAgIDAgICAgIDg3NSAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgMCAgICAgICAgIDAg ICAgIDg3NSAgICAgIDAgICAgICAgMCAgICAgICAwICAgICAgICAgMCAgICAwCjQ3NjIzICAg ICAgICAgMCAgICAgODc1ICAgICAwICAgICAwICAgICAwICAgICAwICAgICAwICAgICAgICAg MCAgICAgODc1ICAgICAgMCAgICAgICAwICAgICAgIDAgICAgICAgICAwICAgIDAKNDkzNzEg ICAgICAgICAwICAgICA4NzUgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgIDAgICAgICAg ICAwICAgICA4NzQgICAgICAwICAgICAgIDAgICAgICAgMCAgICAgICAgIDAgICAgMAoK --lNLPauBgfS Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Cheers. Robert Olsson, Jens Laas --lNLPauBgfS-- From owner-netdev@oss.sgi.com Fri Apr 26 08:26:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QFQewJ011853 for ; Fri, 26 Apr 2002 08:26:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QFQdp8011852 for netdev-outgoing; Fri, 26 Apr 2002 08:26:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QFQZwJ011848 for ; Fri, 26 Apr 2002 08:26:36 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id TAA21824; Fri, 26 Apr 2002 19:25:50 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200204261525.TAA21824@sex.inr.ac.ru> Subject: Re: route cache GC monitoring To: Robert.Olsson@data.slu.se (Robert Olsson) Date: Fri, 26 Apr 2002 19:25:50 +0400 (MSD) Cc: davem@redhat.com, hadi@cyberus.ca, netdev@oss.sgi.com, jensl@robur.slu.se In-Reply-To: <15561.20004.964497.762468@robur.slu.se> from "Robert Olsson" at Apr 26, 2 02:55:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 437 Lines: 15 Hello! > We like to propose four new stats. counters to monitor the garbage process > of route cache. This should be useful for tuning and debugging installations > which have a large number of flows. OK. > Tuning is another business but we have played with max_size and gc_thresh > there are more tuning knobs. There exist one more interesting parameter: gc_elasticity, which is supposed to control length of hash bucket. Alexey From owner-netdev@oss.sgi.com Fri Apr 26 11:11:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QIBGwJ019742 for ; Fri, 26 Apr 2002 11:11:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QIBFSH019741 for netdev-outgoing; Fri, 26 Apr 2002 11:11:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QIBAwJ019735 for ; Fri, 26 Apr 2002 11:11:11 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id UAA24730 for ; Fri, 26 Apr 2002 20:11:45 +0200 (MET DST) Date: Fri, 26 Apr 2002 20:11:45 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: netdev@oss.sgi.com Subject: no_arp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 795 Lines: 27 hi list, is there a way to disable dynamic ARP on a specific interface during runtime. (i looked around the kernel sources, but must have missed it) 'ifconfig eth? noarp' disables dynamic ARPing, but it also seems to prevent writing to the ARP table itself (and don't consult the ARP table at all) - which is fine and the behaviour i would expect. why i would like to have this feature nevertheless? well, i would consider having a static ARP table better for certain networks (networks which are heavily frequented by people who want to "experiment") - this makes our host resistent to ARP poisoning (ok, we won't be standard conform, that's why i'd like to be able to control the behaviour on runtime :) thanks for your help, ++dent -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Mon Apr 29 03:14:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TAEBwJ025173 for ; Mon, 29 Apr 2002 03:14:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TAEBTM025172 for netdev-outgoing; Mon, 29 Apr 2002 03:14:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from color.sics.se (color.sics.se [193.10.66.199]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TAE4wJ025169 for ; Mon, 29 Apr 2002 03:14:05 -0700 Received: from sics.se (pets.sics.se [193.10.65.97]) by color.sics.se (8.9.3/8.9.3) with ESMTP id MAA05174 for ; Mon, 29 Apr 2002 12:14:49 +0200 (MET DST) env-to () env-from (gabriel@sics.se) Message-ID: <3CCD1D18.F33EAEE8@sics.se> Date: Mon, 29 Apr 2002 12:14:48 +0200 From: Gabriel Paues Reply-To: gabriel@sics.se Organization: SICS X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: dst_entry and friends References: <15561.20004.964497.762468@robur.slu.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1700 Lines: 38 Hi! I'm working on my Masters Thesis which aims at making a label switched environment. I know there are protocols for doing that but I am supposed to do it at IPv6-level (by altering the IPv6-stack) thus making Linux route on different criteria than the usual routing table. This is what i want to do: If the flowlabel in the IPv6 header is set to some value except zero then skip the whole routing behaviour and check for the flowlabel in an internal table, and get the out-device and new flowlabel from that table and send the packet. otherwise: Just do as usual My idea is to use netfilter and in the PRE_ROUTING-hook check the flowlabel for values other than zero, and set the dst_entry in the skbuff to something with its input-function to ip6_output. I dont know if I should allocate this fabricated dst_entry myself or if I should scan the list of already existing ones. By setting the input-function-pointer to ip6_output i will skip the whole routing behaviour in a snap. The same goes for the hook LOCAL_OUT where i want to skip ip6_maybe_reroute function and go directly to ip6_output. This might sound like a quite destructive concept, but the whole thing is that my teacher thought those "small hacks" could be done in notime, whle I have discovered that thats not the case. Do you know of any easier way of doing this? And if not, how do I get hold of a dst_entry when I know what netdevice that should be the output? I have had a look in rt6_device_match function in route.c and think that it does more or less what I want to do. I would be grateful if some Linux Ipv6-implementation guru would read this and try to understand what I'm trying to do... :-) Sincerily Gabriel From owner-netdev@oss.sgi.com Mon Apr 29 07:54:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TEsRwJ015515 for ; Mon, 29 Apr 2002 07:54:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TEsRBG015514 for netdev-outgoing; Mon, 29 Apr 2002 07:54:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TEsNwJ015511 for ; Mon, 29 Apr 2002 07:54:23 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 8BAFE1E63C; Mon, 29 Apr 2002 16:55:05 +0200 (MEST) Date: Mon, 29 Apr 2002 16:55:03 +0200 From: Andi Kleen To: Gabriel Paues Cc: netdev@oss.sgi.com Subject: Re: dst_entry and friends Message-ID: <20020429165503.A14300@wotan.suse.de> References: <15561.20004.964497.762468@robur.slu.se> <3CCD1D18.F33EAEE8@sics.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CCD1D18.F33EAEE8@sics.se> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1348 Lines: 25 On Mon, Apr 29, 2002 at 12:14:48PM +0200, Gabriel Paues wrote: > My idea is to use netfilter and in the PRE_ROUTING-hook check the flowlabel for > values other than zero, and set the dst_entry in the skbuff to something with > its input-function to ip6_output. I dont know if I should allocate this > fabricated dst_entry myself or if I should scan the list of already existing > ones. By setting the input-function-pointer to ip6_output i will skip the whole That won't work for most networking protocols, which always route themselves. All you can do is to drop the route later in netfilter and reroute/resubmit Still your concept will fail for path mtu discovery for example, which assumes that an incoming ICMP can be matched to an dst_entry in the routing cache to communicate the new pmtu. It may be easier to just change ip_route_output(). Routes are often cached however, so you would need to make sure that the caches are invalidated when the flow label changes (e.g. by setting dst->obsolete) Overall the concept does not look very promising however. I guess to make the labels unique you'll have to add srcip/dstip to your private tables too, and that means that the label lookup is exactly equivalent in cost to a normal routing cache lookup - even if you didn't need the src/dst it probably wouldn't be much cheaper. -Andi