From owner-netdev@oss.sgi.com Sat Sep 1 03:22:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81AMCn08947 for netdev-outgoing; Sat, 1 Sep 2001 03:22:12 -0700 Received: from colin.muc.de (root@colin.muc.de [193.149.48.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81AMAd08942 for ; Sat, 1 Sep 2001 03:22:10 -0700 Received: by colin.muc.de id <140549-3>; Sat, 1 Sep 2001 12:22:41 +0200 Message-ID: <20010901122229.64064@colin.muc.de> Date: Sat, 1 Sep 2001 12:22:29 +0200 From: Andi Kleen To: David Stevens Cc: netdev@oss.sgi.com Subject: Re: source routing honored by hosts? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from David Stevens on Sat, Sep 01, 2001 at 01:14:11AM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sat, Sep 01, 2001 at 01:14:11AM +0200, David Stevens wrote: > ip6_forward() has the following two lines: > > if (ipv6_devconf.forwarding == 0 && opt->srcrt == 0) > goto error; > > Aside from the other issue of per-interface forwarding :-), this appears to allow > forwarding of source-routed packets even when the node is a host, only. That > seems to be a security hole to me. Suppose you have a multihomed host, or Yes. Looks like one. > > if (ipv6_devconf.forwarding == 0) > goto error; Definitely. -Andi From owner-netdev@oss.sgi.com Sat Sep 1 03:54:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81AsJe09386 for netdev-outgoing; Sat, 1 Sep 2001 03:54:19 -0700 Received: from yue.hongo.wide.ad.jp ([203.178.139.94]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81AsFd09383 for ; Sat, 1 Sep 2001 03:54:15 -0700 Received: from localhost (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 TAA06575; Sat, 1 Sep 2001 19:57:08 +0900 To: ak@muc.de Cc: dlstevens@us.ibm.com, netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: source routing honored by hosts? In-Reply-To: <20010901122229.64064@colin.muc.de> References: <20010901122229.64064@colin.muc.de> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.hongo.wide.ad.jp/%7Eyoshfuji/ 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://cerberus.hongo.wide.ad.jp/%7Eyoshfuji/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010901195708V.yoshfuji@linux-ipv6.org> Date: Sat, 01 Sep 2001 19:57:08 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 49 Sender: owner-netdev@oss.sgi.com Precedence: bulk In article <20010901122229.64064@colin.muc.de> (at Sat, 1 Sep 2001 12:22:29 +0200), Andi Kleen says: > On Sat, Sep 01, 2001 at 01:14:11AM +0200, David Stevens wrote: > > ip6_forward() has the following two lines: > > > > if (ipv6_devconf.forwarding == 0 && opt->srcrt == 0) > > goto error; > > > > Aside from the other issue of per-interface forwarding :-), this appears to allow > > forwarding of source-routed packets even when the node is a host, only. That > > seems to be a security hole to me. Suppose you have a multihomed host, or > > if (ipv6_devconf.forwarding == 0) > > goto error; > > Definitely. NO. In IPv6, even a node is not a router (i.e. it is a host), it MUST forward source routed packet. So, > > if (ipv6_devconf.forwarding == 0 && opt->srcrt == 0) > > goto error; is OK. RFC 2460 says: 4.4 Routing Header : If, while processing a received packet, a *node* encounters a Routing ~~~~~~ header with an unrecognized Routing Type value, the required behavior of the node depends on the value of the Segments Left field, as follows: : While, 2. Terminology node - a device that implements IPv6. router - a node that forwards IPv6 packets not explicitly addressed to itself. [See Note below]. host - any node that is not a router. [See Note below]. --yoshfuji From owner-netdev@oss.sgi.com Sat Sep 1 05:10:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81CAGe10786 for netdev-outgoing; Sat, 1 Sep 2001 05:10:16 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81CABd10783 for ; Sat, 1 Sep 2001 05:10:11 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f81C95719585; Sat, 1 Sep 2001 15:09:13 +0300 Date: Sat, 1 Sep 2001 15:09:04 +0300 (EEST) From: Pekka Savola To: cc: , , Subject: Re: (usagi-users 00750) Re: source routing honored by hosts? In-Reply-To: <20010901195708V.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sat, 1 Sep 2001, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article <20010901122229.64064@colin.muc.de> (at Sat, 1 Sep 2001 12:22:29 +0200), Andi Kleen says: > > > On Sat, Sep 01, 2001 at 01:14:11AM +0200, David Stevens wrote: > > > ip6_forward() has the following two lines: > > > > > > if (ipv6_devconf.forwarding == 0 && opt->srcrt == 0) > > > goto error; > > > > > > Aside from the other issue of per-interface forwarding :-), this appears to allow > > > forwarding of source-routed packets even when the node is a host, only. That > > > seems to be a security hole to me. Suppose you have a multihomed host, or > > > > if (ipv6_devconf.forwarding == 0) > > > goto error; > > > > Definitely. > > NO. In IPv6, even a node is not a router (i.e. it is a host), > it MUST forward source routed packet. So, This is by the spec, yeah. > 4.4 Routing Header > : > If, while processing a received packet, a *node* encounters a Routing > ~~~~~~ > header with an unrecognized Routing Type value, the required behavior > of the node depends on the value of the Segments Left field, as > follows: Problem with source routing is that with scenarios like: host1 --- rtr1 --- rtr2 --- host2 | / rtr3 -/ | host3 you may want to route the packet first from host1 to host2, and from host2 through rtr3 to host3. host2 might not have a route to host3 pointing towards rtr3. I guess this is what the forwarding exception is for? If it was only for routers, you couldn't source route through host2. IPv4 source routing should be work in the same way though, AFAIR, so I don't know how IPv4 implementation deals with this? One could argue, though, that obeying source routing should be togglable, as it's impossible to authenticate, and may allow the packets traverse where they normally should never be able to go. (Rather challenging to firewall, too, as real destination can be hidden in the routing header options.. urghh..) And don't you just love....: Security Considerations The security features of IPv6 are described in the Security Architecture for the Internet Protocol [RFC-2401]. sigh. the ipsec security pixie dust at it again. Writing to ipng mailing list.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Sat Sep 1 05:30:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81CUPI11073 for netdev-outgoing; Sat, 1 Sep 2001 05:30:25 -0700 Received: from zero.aec.at (qmailr@zero.aec.at [195.3.98.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81CUMd11070 for ; Sat, 1 Sep 2001 05:30:23 -0700 Received: (qmail 24686 invoked by uid 99); 1 Sep 2001 12:30:19 -0000 Received: from unknown (HELO fred.muc.de) (unknown) by unknown with SMTP; 1 Sep 2001 12:30:19 -0000 Received: by fred.muc.de (Postfix, from userid 500) id E7962E2D4D; Sat, 1 Sep 2001 14:29:23 +0200 (CEST) Date: Sat, 1 Sep 2001 14:29:23 +0200 From: Andi Kleen To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B" Cc: ak@muc.de, dlstevens@us.ibm.com, netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: source routing honored by hosts? Message-ID: <20010901142923.A5433@fred.local> References: <20010901122229.64064@colin.muc.de> <20010901195708V.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010901195708V.yoshfuji@linux-ipv6.org>; from yoshfuji@linux-ipv6.org on Sat, Sep 01, 2001 at 12:57:08PM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sat, Sep 01, 2001 at 12:57:08PM +0200, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > In article <20010901122229.64064@colin.muc.de> (at Sat, 1 Sep 2001 12:22:29 +0200), Andi Kleen says: > > > On Sat, Sep 01, 2001 at 01:14:11AM +0200, David Stevens wrote: > > > ip6_forward() has the following two lines: > > > > > > if (ipv6_devconf.forwarding == 0 && opt->srcrt == 0) > > > goto error; > > > > > > Aside from the other issue of per-interface forwarding :-), this appears to allow > > > forwarding of source-routed packets even when the node is a host, only. That > > > seems to be a security hole to me. Suppose you have a multihomed host, or > > > > if (ipv6_devconf.forwarding == 0) > > > goto error; > > > > Definitely. > > NO. In IPv6, even a node is not a router (i.e. it is a host), > it MUST forward source routed packet. So, I would still agree with David that it is a security hole (at least without a working ipsec infrastructure) Even if the Spec says otherwise this hole should be closed. -Andi From owner-netdev@oss.sgi.com Sat Sep 1 10:36:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81Ha4u16188 for netdev-outgoing; Sat, 1 Sep 2001 10:36:04 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81HZjd16185 for ; Sat, 1 Sep 2001 10:35:45 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) 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 SMTP id KAA09686 for ; Sat, 1 Sep 2001 10:35:20 -0700 (PDT) mail_from (kuznet@mops.inr.ac.ru) Received: from mops.inr.ac.ru (mops.inr.ac.ru [193.233.7.60]) by ms2.inr.ac.ru (8.6.13/ANK) with ESMTP id VAA19611; Sat, 1 Sep 2001 21:13:33 +0400 Received: (from kuznet@localhost) by mops.inr.ac.ru (8.9.3/8.9.3) id DAA00392; Fri, 31 Aug 2001 03:28:53 +0400 Message-Id: <200108302328.DAA00392@mops.inr.ac.ru> Subject: Re: [patch] 2.4.9 new socket option TCP_DELACK (RFC) To: nivedita@sequent.COM (Nivedita Singhvi) Date: Fri, 31 Aug 2001 03:28:53 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: <200108280207.f7S275J18467@eng4.beaverton.ibm.com> from "Nivedita Singhvi" at Aug 28, 1 06:15:02 am From: Alexey Kuznetsov X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > - possibly better performance in certain environments What exactly? Well, actually, I have one question: how is application supposed to determine, when it is in this "certain environment"? I see no way, but already implemented in tcp. In any case, if you can propose another way to guess, when delayed acks harm performance, it should be added to set of heuristics. Actually, opposite option would make sense, 2.4 really generates too much of acks in some curcumstances. :-) > - _very_ convenient for academic, benchmarking, and certain > other environments to use Benchmarking thing which happen only in academic environment is not very cool idea. > - portability: its available on some other OS's, and > so some apps that make use of it might want to continue > to use it on Linux when ported here.. Enlighten me, what OSes exactly? I would rather expect that applications using this funny option are to be repaired not to use it. > - makes the tcp engine more configurable based on what the > user wants to do, and the easier it is to fiddle with things, > the more learning, innovation that happens on the OS, and > I'd like to encourage that happening on Linux ;) Sigh, the word "innovation" would make sense if you proposed a way to generate ACKs more cleverly, rather than more silly. :-) :-) One comment to improve your patch: > @@ -3015,7 +3015,8 @@ > struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); > > /* More than one full frame received... */ > - if (((tp->rcv_nxt - tp->rcv_wup) > tp->ack.rcv_mss > + if (tp->ack.no_delack || > + ((tp->rcv_nxt - tp->rcv_wup) > tp->ack.rcv_mss > /* ... and right edge of window advances far enough. > * (tcp_recvmsg() will send ACK otherwise). Or... > */ The place is wrong. If done at all, this should be done in tcp_recvmsg() to wait for reopening window at least. Otherwise each segment will generate double ACK: one of them is totally useless, because it does not move right edge of window. Also, you can improve it removing checks from data path. You can obtain required effect blocking setting tp->ack.pingpong. tp->ack.pingpong frozen at zero gives maximal reasonable ack frequency. Alexey From owner-netdev@oss.sgi.com Sat Sep 1 19:06:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8226rY23932 for netdev-outgoing; Sat, 1 Sep 2001 19:06:53 -0700 Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8226nd23922 for ; Sat, 1 Sep 2001 19:06:49 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA71844; Sat, 1 Sep 2001 22:04:28 -0400 Received: from d03nm104.boulder.ibm.com (d03nm104.boulder.ibm.com [9.99.140.96]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8225JR79092; Sat, 1 Sep 2001 20:05:25 -0600 From: "David Stevens" Importance: Normal Subject: Re: source routing honored by hosts? To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: ak@muc.de, netdev@oss.sgi.com, usagi-users@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: Date: Sat, 1 Sep 2001 20:09:52 -0600 X-MIMETrack: Serialize by Router on D03NM104/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/01/2001 08:10:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk >RFC 2460 says: > >4.4 Routing Header >: > If, while processing a received packet, a *node* encounters a Routing > ~~~~~~ > header with an unrecognized Routing Type value, the required behavior > of the node depends on the value of the Segments Left field, as > follows: Routers are nodes too. The wording is unfortunately ambiguous, because they haven't explicitly said hosts must route source-routed packets. But: > router - a node that forwards IPv6 packets not explicitly > addressed to itself. [See Note below]. In the case in question, the IP destination is not the host. So, you could make the argument that the packet isn't explicitly addressed to it and therefore should be dropped if it's a host, routed if it's a router. You could also make the argument that the source-route itself is the explicit addressing. Whether they intended for hosts to forward source-routed packets or not is a good question (esp. if it's a requirement, or if they're allowing for the possibility). If that's their intent, then I'd say it's a misfeature. Consider the scenario where you have, say, a cable modem connected to the Internet and an IPsec tunnel to your company's intranet. If your company's firewall only filters packets coming in from the Internet, and not any from the "trusted" intranet hosts, then a bad guy can source-route through you (even though your machine is configured as a host) to get packets in, and the target host will gladly send TCP ACK's, confidential data, etc. directly to the waiting cracker. Your host will encrypt, encapsulate and forward to your company's intranet and the target machine. Personally, I wouldn't want any machine not explicitly configured as a router to forward packets, but for security reasons, I think if you support it at all, it at least should be a configuration option defaulting to "off". +-DLS From owner-netdev@oss.sgi.com Mon Sep 3 04:34:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83BYYY23491 for netdev-outgoing; Mon, 3 Sep 2001 04:34:34 -0700 Received: from blackhole.kfki.hu (blackhole.kfki.hu [148.6.0.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83BYUd23488 for ; Mon, 3 Sep 2001 04:34:30 -0700 Received: by blackhole.kfki.hu (Postfix, from userid 311) id C7CAE10583; Mon, 3 Sep 2001 13:34:28 +0200 (CEST) Date: Mon, 3 Sep 2001 13:34:28 +0200 (CEST) From: Jozsef Kadlecsik To: Cc: Subject: Re: icmp bug in 2.4.5? 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 Fri, 31 Aug 2001, Jozsef Kadlecsik wrote: > After upgrading a firewall which is configured with connection tracking > from 2.4.2 to 2.4.5, the following strange thing happens on it: > > traceroute targeted to the firewall completes successfully: > icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0) in > udp.c generates proper (large enough) response packets, which > then can be handled by the connection tracking code. > > traceroute going through the firewall doesn't generate "proper" > ICMP packets from the firewall: > icmp_send(skb, ICMP_TIME_EXCEEDED, ICMP_EXC_TTL, 0) in > ip_forward.c seems to generate too short packets, which cannot > therefore be tracked: > > Aug 31 12:16:12 zzz kernel: denied: IN= OUT=eth1 SRC=zzz.zzz.zzz.zzz > DST=a.b.c.d LEN=66 TOS=0x00 PREC=0xC0 TTL=255 ID=10383 PROTO=ICMP > TYPE=11 CODE=0 [SRC=a.b.c.d DST=x.y.z.w LEN=38 TOS=0x00 > PREC=0x00 TTL=1 ID=42915 PROTO=UDP INCOMPLETE [6 bytes] ] > > Nothing else's changed, only an upgrade happened. > > Is it a known bug? If yes, is it fixed in later releases? Sorry, the quick (rush) explanation above is completely wrong. Still, the problem stands, so a better analysys follows: in ip_forward.c all error trackings (too many hops, strict route failed, fragmentation needed) simply jump over calling the netfilter hooks for the original packet. Thus if a *connection-initiating* packet would generate an ICMP error message, the conntrack entry won't be created. In consequence the generated reply packet will not be detected by the connection tracking as RELATED, as it should be and as it is expected. [As far as I see, the function ip_forward hasn't changed at least from 2.4.0, up to 2.4.9. So I dunno how we didn't notice the problem at running 2.4.2.] Regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From owner-netdev@oss.sgi.com Mon Sep 3 14:27:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83LRKA02920 for netdev-outgoing; Mon, 3 Sep 2001 14:27:20 -0700 Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83LRGd02916 for ; Mon, 3 Sep 2001 14:27:16 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id AAA15433 for ; Tue, 4 Sep 2001 00:26:25 +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 xma015431; Tue, 4 Sep 01 00:26:22 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id f83LPT904127 for ; Tue, 4 Sep 2001 00:25:29 +0300 (EEST) Received: (from ajtuomin@localhost) by morphine.tml.hut.fi (8.9.3+Sun/8.9.3) id AAA20245 for netdev@oss.sgi.com; Tue, 4 Sep 2001 00:27:06 +0300 (EEST) From: Antti Tuominen Message-Id: <200109032127.AAA20245@morphine.tml.hut.fi> Subject: IPv6 routes and RTPROT_* To: netdev@oss.sgi.com Date: Tue, 4 Sep 2001 00:27:06 +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 Hello all, I'm writing a routing protocol daemon and need to know which routes are inserted by this daemon. I use rtnetlink rtm_protocol with some RTPROT_* value to mark the routes. It seems that IPv6 stack returns a type but it's implicitly determined from some flag values and is one of only RTPROT_BOOT, RTPROT_REDIRECT, RTPROT_RA or RTPROT_KERNEL (linux/net/ipv6/route.c: rt6_fill_node()). As far as I can tell linux does not store routing protocol value (RTPROT_*) for IPv6 routes. If I'm correct, why is it so? Regards, Antti -- Antti J. Tuominen, JMT 3A 133, FIN-02150 Espoo, Finland. Research assistant, TSE Institute at Helsinki University of Technology work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi From owner-netdev@oss.sgi.com Tue Sep 4 11:03:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84I3A729031 for netdev-outgoing; Tue, 4 Sep 2001 11:03:10 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84I34d29024 for ; Tue, 4 Sep 2001 11:03:05 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA08105; Tue, 4 Sep 2001 22:02:40 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200109041802.WAA08105@ms2.inr.ac.ru> Subject: Re: IPv6 routes and RTPROT_* To: ajtuomin@tml.HUt.FI (Antti Tuominen) Date: Tue, 4 Sep 2001 22:02:40 +0400 (MSK DST) Cc: netdev@oss.sgi.com In-Reply-To: <200109032127.AAA20245@morphine.tml.hut.fi> from "Antti Tuominen" at Sep 4, 1 01:45:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > As far as I can tell linux does not store routing protocol value > (RTPROT_*) for IPv6 routes. If I'm correct, why is it so? Because this is not implemented like lots of other things. And unlike other really important things, this is not so useful. Just use any protocol different from reserved values, it is local configuration option in any case. Alexey From owner-netdev@oss.sgi.com Tue Sep 4 13:57:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84KvIt32519 for netdev-outgoing; Tue, 4 Sep 2001 13:57:18 -0700 Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84KvFd32513 for ; Tue, 4 Sep 2001 13:57:16 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id XAA24216 for ; Tue, 4 Sep 2001 23:56:22 +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 xma024212; Tue, 4 Sep 01 23:56:16 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id f84KtP911244; Tue, 4 Sep 2001 23:55:25 +0300 (EEST) Received: (from ajtuomin@localhost) by morphine.tml.hut.fi (8.9.3+Sun/8.9.3) id XAA23356; Tue, 4 Sep 2001 23:57:07 +0300 (EEST) From: Antti Tuominen Message-Id: <200109042057.XAA23356@morphine.tml.hut.fi> Subject: Re: IPv6 routes and RTPROT_* In-Reply-To: <200109041802.WAA08105@ms2.inr.ac.ru> from "kuznet@ms2.inr.ac.ru" at "Sep 4, 2001 10:02:40 pm" To: kuznet@ms2.inr.ac.ru Date: Tue, 4 Sep 2001 23:57:07 +0300 (EEST) Cc: netdev@oss.sgi.com 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 kuznet@ms2.inr.ac.ru previously wrote: > Hello! Hello, > Because this is not implemented like lots of other things. > > And unlike other really important things, this is not so useful. Yes, I understand that. Thanks for clearing that out. I was just wondering if there was a reason to do it differently in IPv6. IPv4 routing table entry has a field for the protocol value but IPv6 doesn't. But if it's just not implemented, that's okay. > Just use any protocol different from reserved values, it is local > configuration option in any case. What do you mean? I missed your point, I mean if the value is not stored, what protocol I use doesn't really change anything. Right? Regards, Antti -- Antti J. Tuominen, JMT 3A 133, FIN-02150 Espoo, Finland. Research assistant, TSE Institute at Helsinki University of Technology work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi From owner-netdev@oss.sgi.com Wed Sep 5 08:40:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85FeiS24558 for netdev-outgoing; Wed, 5 Sep 2001 08:40:44 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85Fefd24555 for ; Wed, 5 Sep 2001 08:40:41 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA25216; Wed, 5 Sep 2001 19:39:42 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200109051539.TAA25216@ms2.inr.ac.ru> Subject: Re: IPv6 routes and RTPROT_* To: ajtuomin@tml.hut.fi (Antti Tuominen) Date: Wed, 5 Sep 2001 19:39:42 +0400 (MSK DST) Cc: netdev@oss.sgi.com In-Reply-To: <200109042057.XAA23356@morphine.tml.hut.fi> from "Antti Tuominen" at Sep 4, 1 11:57:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > What do you mean? I missed your point, I mean if the value is not > stored, what protocol I use doesn't really change anything. Right? Think what will happen if it will be implemented. IPv6 routing requests should fill all the fields with something sensible not to fail in this case. F.e. another example: RTM_NEWROUTE for IPv6 _always_ force implicit NLM_F_CREATE|NLM_F_APPEND now, because no other way is implemented. However, careful application must set these flags. So that the day, when kernel will start to understand flags, application will not fail, because flagless RTM_NEWROUTE does not create anything and adds route to head. :-) Alexey From owner-netdev@oss.sgi.com Wed Sep 5 15:10:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85MAsB00308 for netdev-outgoing; Wed, 5 Sep 2001 15:10:54 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85MApd00305 for ; Wed, 5 Sep 2001 15:10:51 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id SAA11702; Wed, 5 Sep 2001 18:08:18 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 5 Sep 2001 18:08:18 -0400 (EDT) From: jamal To: cc: , Andi Kleen , Subject: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Andi, Alexey, Whats wrong with this patch (just a thought, not tested or even compiled)? --------------------------------------- --- devinet.c 2001/09/04 19:18:51 1.1 +++ devinet.c 2001/09/04 19:31:13 @@ -530,7 +530,7 @@ if ((in_dev=__in_dev_get(dev)) != NULL) { for (ifap=&in_dev->ifa_list; (ifa=*ifap) != NULL; ifap=&ifa->ifa_next) - if (strcmp(ifr.ifr_name, ifa->ifa_label) == 0) + if ((strcmp(ifr.ifr_name, ifa->ifa_label) == 0) || (sin->sin_addr.s_addr == ifa->ifa_address)) break; } -------------------------------- cheers, jamal From owner-netdev@oss.sgi.com Wed Sep 5 15:23:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85MN1300773 for netdev-outgoing; Wed, 5 Sep 2001 15:23:01 -0700 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85MMxd00770 for ; Wed, 5 Sep 2001 15:22:59 -0700 Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA116234 for ; Wed, 5 Sep 2001 18:20:38 -0400 Received: from localhost.localdomain (dyn9-47-18-112.des.beaverton.ibm.com [9.47.18.112]) by northrelay03.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f85MGxR141512 for ; Wed, 5 Sep 2001 18:16:59 -0400 Received: from us.ibm.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f85MMt401184 for ; Wed, 5 Sep 2001 15:22:55 -0700 Message-ID: <3B96A5BF.7BA6BAEB@us.ibm.com> Date: Wed, 05 Sep 2001 15:22:55 -0700 From: "David C. Hansen" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [PATCH] to make netdev_fc_lock static Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Here is a little patch to make netdev_fc_lock static instead of global. It is against 2.4.7, but applies cleanly to 2.4.9. The motivation for doing this came from this: http://lse.sourceforge.net/lockhier/global-spin-lock --- linux-2.4.7/net/core/sock.c Fri Jun 29 19:38:26 2001 +++ linux/net/core/sock.c Fri Jul 27 11:23:19 2001 @@ -861,7 +861,7 @@ * It is broken by design. All the protocols using it must be fixed. --ANK */ -rwlock_t net_big_sklist_lock = RW_LOCK_UNLOCKED; +static rwlock_t net_big_sklist_lock = RW_LOCK_UNLOCKED; void sklist_remove_socket(struct sock **list, struct sock *sk) { -- David C. Hansen haveblue@us.ibm.com IBM LTC Base/OS Group (503)578-4080 From owner-netdev@oss.sgi.com Wed Sep 5 15:34:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85MYHw00978 for netdev-outgoing; Wed, 5 Sep 2001 15:34:17 -0700 Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85MYCd00970 for ; Wed, 5 Sep 2001 15:34:13 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.99.140.24]) by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA38940 for ; Wed, 5 Sep 2001 18:29:29 -0400 Received: from localhost.localdomain (dyn9-47-18-112.des.beaverton.ibm.com [9.47.18.112]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f85MVgb143496 for ; Wed, 5 Sep 2001 16:31:42 -0600 Received: from us.ibm.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f85MVk401209 for ; Wed, 5 Sep 2001 15:31:46 -0700 Message-ID: <3B96A7D2.8D5F3EB4@us.ibm.com> Date: Wed, 05 Sep 2001 15:31:46 -0700 From: "David C. Hansen" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [PATCH] to make net_big_sklist_lock static Content-Type: multipart/mixed; boundary="------------0D0B99CFB66CFCC9E0B40FD4" Sender: owner-netdev@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------0D0B99CFB66CFCC9E0B40FD4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just like the last one: Here is a little patch to make net_big_sklist_lock static instead of global. It is against 2.4.7, but applies cleanly to 2.4.9. The motivation for doing this came from this: http://lse.sourceforge.net/lockhier/global-spin-lock --- linux-2.4.7/net/core/dev.c Sun Jul 15 16:29:40 2001 +++ linux/net/core/dev.c Fri Jul 27 11:20:01 2001 @@ -1068,7 +1068,7 @@ atomic_t netdev_dropping = ATOMIC_INIT(0); static unsigned long netdev_fc_mask = 1; unsigned long netdev_fc_xoff = 0; -spinlock_t netdev_fc_lock = SPIN_LOCK_UNLOCKED; +static spinlock_t netdev_fc_lock = SPIN_LOCK_UNLOCKED; static struct { -- David C. Hansen haveblue@us.ibm.com IBM LTC Base/OS Group (503)578-4080 --------------0D0B99CFB66CFCC9E0B40FD4 Content-Type: text/plain; charset=us-ascii; name="hgafb.static.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hgafb.static.patch" --- linux-2.4.5/drivers/video/hgafb.c Fri Feb 9 11:30:23 2001 +++ linux/drivers/video/hgafb.c Tue Jun 26 11:17:14 2001 @@ -106,7 +106,7 @@ /* Global locks */ -spinlock_t hga_reg_lock = SPIN_LOCK_UNLOCKED; +static spinlock_t hga_reg_lock = SPIN_LOCK_UNLOCKED; /* Framebuffer driver structures */ --------------0D0B99CFB66CFCC9E0B40FD4-- From owner-netdev@oss.sgi.com Wed Sep 5 19:08:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8628i105305 for netdev-outgoing; Wed, 5 Sep 2001 19:08:44 -0700 Received: from ns1.panamanow.com ([209.127.124.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8628Vd05298 for ; Wed, 5 Sep 2001 19:08:40 -0700 Received: from pananix.com (adsl28.187-pool-30.cwpanama.net [206.28.187.30] (may be forged)) by ns1.panamanow.com (8.10.0/8.10.0) with ESMTP id f8625kO24177 for ; Wed, 5 Sep 2001 21:05:46 -0500 Message-ID: <3B96D9F4.16E0D826@pananix.com> Date: Wed, 05 Sep 2001 21:05:40 -0500 From: "David A. Bandel" Organization: Pananix, SA X-Mailer: Mozilla 4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: if_ether.h changes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Folks, Sometime between 2.4.2 and 2.4.9, if_ether.h has changed (/usr/include/linux/if_ether.h): --- if_ether.h Fri Oct 27 13:03:14 2000 +++ if_ether.h.249 Wed Sep 5 13:06:17 2001 @@ -37,12 +37,14 @@ */ #define ETH_P_LOOP 0x0060 /* Ethernet Loopback packet */ -#define ETH_P_ECHO 0x0200 /* Ethernet Echo packet */ -#define ETH_P_PUP 0x0400 /* Xerox PUP packet */ +#define ETH_P_PUP 0x0200 /* Xerox PUP packet */ +#define ETH_P_PUPAT 0x0201 /* Xerox PUP Addr Trans packet */ #define ETH_P_IP 0x0800 /* Internet Protocol packet */ #define ETH_P_X25 0x0805 /* CCITT X.25 */ #define ETH_P_ARP 0x0806 /* Address Resolution packet */ #define ETH_P_BPQ 0x08FF /* G8BPQ AX.25 Ethernet Packet [ NOT AN OFFICIALLY REGISTERED ID ] */ +#define ETH_P_IEEEPUP 0x0a00 /* Xerox IEEE802.3 PUP packet */ +#define ETH_P_IEEEPUPAT 0x0a01 /* Xerox IEEE802.3 PUP Addr Trans packet */ #define ETH_P_DEC 0x6000 /* DEC Assigned proto */ #define ETH_P_DNA_DL 0x6001 /* DEC DNA Dump/Load */ #define ETH_P_DNA_RC 0x6002 /* DEC DNA Remote Console */ The removal of ETH_P_ECHO causes iproute2 compile to blow up. Note: ETH_P_PUP was 0x400, ETH_P_ECHO was 0x200. Now, ETH_P_ECHO is gone, and ETH_P_PUP is 0x200. Did I miss something? I cannot find ETH_P_ECHO anywhere. Note: Pls cc: me, as I'm not subbed to the list. Ciao, David A. Bandel -- Focus on the dream, not the competition. -- Nemesis Racing Team motto From owner-netdev@oss.sgi.com Thu Sep 6 02:32:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f869Ww012582 for netdev-outgoing; Thu, 6 Sep 2001 02:32:58 -0700 Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f869Wud12579 for ; Thu, 6 Sep 2001 02:32:56 -0700 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (8.11.6/8.11.6/ALCANET/MAIL2 2001) with ESMTP id f869Wsn17149 for ; Thu, 6 Sep 2001 11:32:54 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id LAA16690 for ; Thu, 6 Sep 2001 11:31:58 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.244.53]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id LAA07090; Thu, 6 Sep 2001 11:32:19 +0200 (MET DST) Message-ID: <3B9740B5.61A51BA3@ms.alcatel.fr> Date: Thu, 06 Sep 2001 11:24:05 +0200 From: Philippe Bereski Organization: Alcatel R&I - Marcoussis X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: IPv6 over ATM ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 561 Lines: 16 Hello, I'm looking for IPv6/ATM/Linux. Is is under development/test somewhere ? It's quoted in IETF minute of august, on USAGI IPv6 status, but only as "Hacking items/coming soon". I've not found any potential deadline for IPv6 over ATM. There is no trace of that topic in the release notes of the last kernel snapshots nor on the ATM site at lrcwww.epfl.ch/linux-atm/. Can someone make me a status on that item ? Best regards, Philippe Bereski. -- Philippe Bereski | Voice : (33) 1 6963 4436 Alcatel Telecom | Fax : (33) 1 6963 1790 From owner-netdev@oss.sgi.com Thu Sep 6 07:30:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86EUwg18020 for netdev-outgoing; Thu, 6 Sep 2001 07:30:58 -0700 Received: from krusty.e-technik.uni-dortmund.de (postfix@krusty.E-Technik.Uni-Dortmund.DE [129.217.163.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86EUld18017 for ; Thu, 6 Sep 2001 07:30:47 -0700 Received: from maggie.e-technik.uni-dortmund.de (maggie.dt.e-technik.uni-dortmund.de [129.217.163.9]) by krusty.e-technik.uni-dortmund.de (Postfix) with ESMTP id E9740A3828 for ; Thu, 6 Sep 2001 16:30:44 +0200 (CEST) Received: by maggie.e-technik.uni-dortmund.de (Postfix, from userid 537) id 2A97E9068; Thu, 6 Sep 2001 16:30:44 +0200 (CEST) Date: Thu, 6 Sep 2001 16:30:43 +0200 From: Matthias Andree To: netdev@oss.sgi.com Subject: (fwd) ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010906163043.F29583@maggie.dt.e-technik.uni-dortmund.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 6488 Lines: 169 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I sent the attached mail to Linux-Kernel and Linux-Net yesterday, it has got some attention recently, however, since Alan Cox mentioned it, I'm forwarding this to netdev@oss.sgi.com, even if it's just for completeness's sake. -- Matthias Andree --XsQoSWH+UP9D9v3l Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: ma+lxnt@dt.e-technik.uni-dortmund.de Received: from nx5.HRZ.Uni-Dortmund.DE (nx5.HRZ.Uni-Dortmund.DE [129.217.131.21]) by krusty.e-technik.uni-dortmund.de (Postfix) with ESMTP id 0E440A3828 for ; Wed, 5 Sep 2001 18:25:49 +0200 (CEST) Received: from vger.kernel.org by nx5.HRZ.Uni-Dortmund.DE via smtp-def with ESMTP; Wed, 5 Sep 2001 18:25:40 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 5 Sep 2001 12:20:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 5 Sep 2001 12:20:35 -0400 Received: from krusty.E-Technik.Uni-Dortmund.DE ([129.217.163.1]:55305 "HELO krusty.e-technik.uni-dortmund.de") by vger.kernel.org with SMTP id ; Wed, 5 Sep 2001 12:20:18 -0400 Received: from emma1.emma.line.org (krusty.dt.e-technik.uni-dortmund.de [129.217.163.1]) by krusty.e-technik.uni-dortmund.de (Postfix) with ESMTP id 340D0A3828; Wed, 5 Sep 2001 18:20:36 +0200 (CEST) Received: by emma1.emma.line.org (Postfix, from userid 500) id 2AE13A201F; Wed, 5 Sep 2001 18:20:34 +0200 (CEST) Date: Wed, 5 Sep 2001 18:20:33 +0200 From: Matthias Andree To: Wietse Venema , Linux-Kernel mailing list , linux-net@vger.kernel.org Subject: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010905182033.D3926@emma1.emma.line.org> Mail-Followup-To: Wietse Venema , Linux-Kernel mailing list , linux-net@vger.kernel.org References: <20010905170037.A6473@emma1.emma.line.org> <20010905152738.C5912BC06D@spike.porcupine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20010905152738.C5912BC06D@spike.porcupine.org> User-Agent: Mutt/1.3.22.1i Sender: linux-net-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-net@vger.kernel.org -----BEGIN PGP SIGNED MESSAGE----- Dear network experts, dear lurkers, Wietse Venema and I are wondering about different Linux 2.2/2.4 and FreeBSD 4.4-RC behaviour when using ioctls to figure interface netmasks, FreeBSD gets it right, Linux 2.4.9 and 2.4.9-ac7 get it wrong, and from looking at the source, I think, Linux 2.2.19 gets it wrong as well. Please Cc: replies back, I'm not on the -net list, and I'm not sure if Wietse is on either list. In either case, inet_addr_local, which Postfix uses to figure local address/netmask pairs, does this: 1. obtain SIOCGIFCONF list 2. for each AF_INET entry in the list from (1.), do: 2.1 pull out the address from ifr and store it away 2.2 copy the whole request to an ifr_mask structure 2.3 ioctl(somesocket, SIOCGIFNETMASK, ifr_mask) 2.4 pull out the mask and store it away Example: FreeBSD 4.4-RC: # ifconfig xl0 alias 192.168.1.1/28 # add alias # ifconfig xl0 # display, only relevant part quoted xl0: flags=8843 mtu 1500 inet 192.168.0.4 netmask 0xffffff00 broadcast 192.168.0.255 inet 192.168.1.1 netmask 0xfffffff0 broadcast 192.168.1.15 # ./inet_addr_local # what Postfix figures 192.168.0.4/255.255.255.0 192.168.1.1/255.255.255.240 127.0.0.1/255.0.0.0 - -> works. Linux: # ip addr add 192.168.1.1/28 dev eth0 # add alias without label eth0:0 # ip addr show dev eth0 # 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:60:08:6f:8a:5e brd ff:ff:ff:ff:ff:ff inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0 inet 192.168.1.1/28 scope global eth0 # ./inet_addr_local 127.0.0.1/255.0.0.0 192.168.0.1/255.255.255.0 192.168.1.1/255.255.255.0 - -> oops, 192.168.1.1 got wrong netmask. Digging with gdb on either platform, the interface name is xl0 for all addresses on FreeBSD (no :0 or something) and eth0 on Linux (no :0 or something). There is no platform-dependent code in inet_addr_local. Looking at FreeBSD's Kernel source, FreeBSD iterates over the addresses: /usr/src/sys/netinet/in.c, function in_control, ll. 189ff in my version, comparing against ifr_addr. Looking at Linux' Kernel source, Linux 2.4.9 compares just the ifr_name, /usr/src/linux/net/ipv4/devinet.c, function devinet_ioctl, ll. 463 ff. in 2.4.9, so Linux always returns the mask for the first address, not the mask for the requested address. This doesn't matter as long as eth0:0-style aliases are configured with ifconfig, but it does matter as soon as ip comes into play and both addresses are assigned to eth0 rather than eth0 and eth0:0. I believe this would require fixing for compatibility reasons, in the sense that the address is also compared to figure the interface, but I'm out of time now and cannot try anything before tomorrow, I'd happily test patches sent by then. Would net/ipv4/devinet.c be the only place to fix or are there other places that do also need fixing? Non-Postfix guys: Here's how to build inet_addr_local: 1. fetch /mirrors/postfix-release/official/postfix-20010228-pl04.tar.gz from ftp.porcupine.org 2. unpack the sources, then do: make Makefiles ; cd src/util ; make inet_addr_local 3. add an IP alias to any network (eth in my case), but let it have a different netmask than the primary address of the net. Thanks a lot in advance! Cheers, - -- Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iQCVAwUBO5ZQgydEoB0mv1ypAQEzvAP+IMWRaKR+Bvzxbhd/fJCNR8oq//U06kP3 mg1KIoOKX3PBfNkxIZW4l+oTt9wxHAXHJUJ1W6w3T43xlBlcHi4Y70XNKqbyCFiB n6l+q0JFHv+qV4pWxJCG1sz20nrwK/nUwf+5nxcGAdetPnPBXpndGtiX66nzNtka NGO38uOvIuA= =587q -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --XsQoSWH+UP9D9v3l-- From owner-netdev@oss.sgi.com Thu Sep 6 08:12:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86FC1F18995 for netdev-outgoing; Thu, 6 Sep 2001 08:12:01 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86FBwd18991 for ; Thu, 6 Sep 2001 08:11:59 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA10532; Thu, 6 Sep 2001 19:11:40 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200109061511.TAA10532@ms2.inr.ac.ru> Subject: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 To: hadi@cyberus.ca (jamal) Date: Thu, 6 Sep 2001 19:11:40 +0400 (MSK DST) Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, ak@muc.de In-Reply-To: from "jamal" at Sep 5, 1 06:08:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 203 Lines: 8 Hello! > Whats wrong with this patch (just a thought, not tested or even compiled)? Wrong is that it stops to work if you do not fill ifr_data. This field in write only in 4.3BSD and in Linux. Alexey From owner-netdev@oss.sgi.com Thu Sep 6 10:49:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86Hn1Y21143 for netdev-outgoing; Thu, 6 Sep 2001 10:49:01 -0700 Received: from krusty.e-technik.uni-dortmund.de (postfix@krusty.E-Technik.Uni-Dortmund.DE [129.217.163.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86Hmnd21140 for ; Thu, 6 Sep 2001 10:48:49 -0700 Received: from maggie.e-technik.uni-dortmund.de (maggie.dt.e-technik.uni-dortmund.de [129.217.163.9]) by krusty.e-technik.uni-dortmund.de (Postfix) with ESMTP id F30F3A3828; Thu, 6 Sep 2001 19:48:47 +0200 (CEST) Received: by maggie.e-technik.uni-dortmund.de (Postfix, from userid 537) id 4D5749067; Thu, 6 Sep 2001 19:48:47 +0200 (CEST) Date: Thu, 6 Sep 2001 19:48:46 +0200 From: Matthias Andree To: kuznet@ms2.inr.ac.ru Cc: Matthias Andree , Linux-Kernel mailing list , linux-net@vger.kernel.org, netdev@oss.sgi.com, Wietse Venema , Alan Cox Subject: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010906194846.A743@maggie.dt.e-technik.uni-dortmund.de> Mail-Followup-To: kuznet@ms2.inr.ac.ru, Linux-Kernel mailing list , linux-net@vger.kernel.org, netdev@oss.sgi.com, Wietse Venema , Alan Cox References: <20010906155920.B29583@maggie.dt.e-technik.uni-dortmund.de> <200109061554.TAA11031@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109061554.TAA11031@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Thu, Sep 06, 2001 at 19:54:43 +0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 5882 Lines: 160 On Thu, 06 Sep 2001, kuznet@ms2.inr.ac.ru wrote: > > What 4.3BSD do you refer to? > > The most wide spread example is Linux. Is this not enough? :-) Nah, if you argue with BSD, show real BSD. :-) > > I "must"? Who says so? The ip reference says to use label for 2.0 > > compatibility, but other systems > > You read manual and however did this. Cool. Do you not flout on me > occasionally? :-) No, the issue is being serious. I can do what I did, and I (personally) don't get the idea that SIOCGIFNETMASK compatibility is properly described with "2.0 compatibility". 2.0 compatibility can mean anything from "choke on SMP" to "does not compile with 2.95.2", "runs on Windows 2.0" but does not state anything about the ioctl SIOCGIFNETMASK API whatsoever. > > I don't get the compatibility reasons. An eth0 interface that has two > > If you are going to continue to use legacy interface, > each interface/alias must have ONE address. Period. No. See below. > The easiest way to prevent such problems is not to use "ip", > but use ifconfig. ...or use the "label" option of ip. Linux has no "home" as SysV or BSD, it pulls its behaviour from anywhere the maintainers like it, and turns arbitrarily incompatible (from a portability point of view) this way. > > How can one seriously expect a portable software to use SIOCGIFNETMASK > > Using "ip" you have prepared configuration which is not portable by definition. > Each portable application will fail on it. Sure, because the interface is broken. > > names for the subsequent addresses)? "Not at all"? > > Not "at all". F.e. if you fill ifr_data with random bits > and run the test on Solaris (which is also <4.4BSD, something grown > of 4.2BSD) and SIOCGIFNETMASK _fails_ there, I can agree > that adding this 4.4BSDism will not be disasterous. Solaris 8 does not fail, and it does not care for passing in 85.85.85.85 as address (patch to inet_addr_local.c that I used to test below). Solaris has "logical interfaces" with distinct (hme0:1) names. Linux has not -> 4.4BSD behaviour. We can have both worlds in the same API: 1. if the address family given in ifa_address is AF_INET, assume we have a 4.4BSD (FreeBSD 4.x) application and search for name AND address. 2. if (1.) does not turn up an address, or the address family was not AF_INET, fall back to 4.2BSD/Solaris behaviour and search for just the name. That way, applications that expect the 4.4BSD API can send in the alias they want the netmask for, and if an application uses a 4.2BSD API and passes junk in, it will get the proper information from the fallback. To stop all that nonsense discussion and give a proof of concept (as best evidence): this is my patch against 2.4.9, it fixes the issue while retaining 4.3BSD compatibility, if you pass it junk, it will happily return the netmask of the first address of that interface as it did until now. I did not invent a pointer to store in the inside loop so as to keep the loop bodies quick and keep loop invariant code (AF_INET comparison) out, before someone asks. Constructive comments are welcome. Flames are not. --- net/ipv4/devinet.c.orig Thu Sep 6 18:57:25 2001 +++ net/ipv4/devinet.c Thu Sep 6 19:33:38 2001 @@ -20,6 +20,10 @@ * Changes: * Alexey Kuznetsov: pa_* fields are replaced with ifaddr lists. * Cyrus Durgin: updated for kmod + * Matthias Andree: in devinet_ioctl, compare label and + * address (4.4BSD alias style support), + * fall back to comparing just the label + * if no match found. */ #include @@ -463,6 +467,7 @@ int devinet_ioctl(unsigned int cmd, void *arg) { struct ifreq ifr; + struct sockaddr_in sin_orig; struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr; struct in_device *in_dev; struct in_ifaddr **ifap = NULL; @@ -479,6 +484,9 @@ return -EFAULT; ifr.ifr_name[IFNAMSIZ-1] = 0; + /* save original address for comparison */ + memcpy(&sin_orig, sin, sizeof(*sin)); + colon = strchr(ifr.ifr_name, ':'); if (colon) *colon = 0; @@ -529,9 +537,24 @@ *colon = ':'; if ((in_dev=__in_dev_get(dev)) != NULL) { - for (ifap=&in_dev->ifa_list; (ifa=*ifap) != NULL; ifap=&ifa->ifa_next) - if (strcmp(ifr.ifr_name, ifa->ifa_label) == 0) - break; + /* compare label and address (4.4BSD style) first if we + have an AF_INET address family in the request */ + if (sin_orig.sin_family == AF_INET) { + for (ifap=&in_dev->ifa_list; (ifa=*ifap) != NULL; ifap=&ifa->ifa_next) + if ((strcmp(ifr.ifr_name, ifa->ifa_label) == 0) + && sin_orig.sin_addr.s_addr == ifa->ifa_address) + break; + } else { + ifa = NULL; + } + /* we didn't get a match, maybe the application is + 4.3BSD-style and passed in junk so we fall back to + comparing just the label */ + if (ifa == NULL) { + for (ifap=&in_dev->ifa_list; (ifa=*ifap) != NULL; ifap=&ifa->ifa_next) + if (strcmp(ifr.ifr_name, ifa->ifa_label) == 0) + break; + } } if (ifa == NULL && cmd != SIOCSIFADDR && cmd != SIOCSIFFLAGS) { This patch to Postfix' inet_addr_local.c showed that Solaris doesn't care about junk passed, and to verify Linux still returns a mask if you pass it junk. *** inet_addr_local.c.orig Thu Sep 6 18:06:20 2001 --- inet_addr_local.c Thu Sep 6 18:12:26 2001 *************** *** 133,138 **** --- 133,139 ---- if (mask_list) { ifr_mask = (struct ifreq *) mymalloc(IFREQ_SIZE(ifr)); memcpy((char *) ifr_mask, (char *) ifr, IFREQ_SIZE(ifr)); + memset((char *)&(((struct sockaddr_in *)&ifr_mask->ifr_addr)->sin_addr), 0x55, 4); if (ioctl(sock, SIOCGIFNETMASK, ifr_mask) < 0) msg_fatal("%s: ioctl SIOCGIFNETMASK: %m", myname); addr = ((struct sockaddr_in *) & ifr_mask->ifr_addr)->sin_addr; -- Matthias Andree From owner-netdev@oss.sgi.com Thu Sep 6 11:06:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86I6cQ21473 for netdev-outgoing; Thu, 6 Sep 2001 11:06:38 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86I6Zd21470 for ; Thu, 6 Sep 2001 11:06:35 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA12629; Thu, 6 Sep 2001 22:06:24 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200109061806.WAA12629@ms2.inr.ac.ru> Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 To: matthias.andree@gmx.de (Matthias Andree) Date: Thu, 6 Sep 2001 22:06:24 +0400 (MSK DST) Cc: matthias.andree@gmx.de, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, wietse@porcupine.org, alan@lxorguk.ukuu.org.uk In-Reply-To: <20010906194846.A743@maggie.dt.e-technik.uni-dortmund.de> from "Matthias Andree" at Sep 6, 1 07:48:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 150 Lines: 12 Hello! > Sure, because the interface is broken. It is __legacy__ interface. > Solaris 8 does not fail, That's all, the issue is closed. Alexey From owner-netdev@oss.sgi.com Thu Sep 6 11:18:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86IIVJ21688 for netdev-outgoing; Thu, 6 Sep 2001 11:18:31 -0700 Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86IISd21684 for ; Thu, 6 Sep 2001 11:18:29 -0700 Received: by spike.porcupine.org (Postfix, from userid 1001) id 9CCECBC06C; Thu, 6 Sep 2001 14:18:26 -0400 (EDT) Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-Reply-To: <200109061806.WAA12629@ms2.inr.ac.ru> "from kuznet@ms2.inr.ac.ru at Sep 6, 2001 10:06:24 pm" To: kuznet@ms2.inr.ac.ru Date: Thu, 6 Sep 2001 14:18:26 -0400 (EDT) Cc: Matthias Andree , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, wietse@porcupine.org, alan@lxorguk.ukuu.org.uk X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010906181826.9CCECBC06C@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 517 Lines: 21 kuznet@ms2.inr.ac.ru: > Hello! > > > Sure, because the interface is broken. > > It is __legacy__ interface. > > > Solaris 8 does not fail, > > That's all, the issue is closed. Soldiers are marching down the street. The mother of one of those soldiers is ever so proud. All the other guys are marching out of step. Her son is the only one who does it right. That's what it looks like for a person who writes Internet software that aims to work on a wide variety of platforms. Ah. That feels better. Wietse From owner-netdev@oss.sgi.com Thu Sep 6 11:39:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86Id7B22156 for netdev-outgoing; Thu, 6 Sep 2001 11:39:07 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86Id5d22153 for ; Thu, 6 Sep 2001 11:39:05 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA13334; Thu, 6 Sep 2001 22:38:49 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200109061838.WAA13334@ms2.inr.ac.ru> Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 To: wietse@porcupine.org (Wietse Venema) Date: Thu, 6 Sep 2001 22:38:49 +0400 (MSK DST) Cc: matthias.andree@gmx.de, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, wietse@porcupine.org, alan@lxorguk.ukuu.org.uk In-Reply-To: <20010906181826.9CCECBC06C@spike.porcupine.org> from "Wietse Venema" at Sep 6, 1 02:18:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 146 Lines: 8 Hello! > That's what it looks like I am sorry, apparently, I have problems with sense of humour. I was not able to find any connection. Alexey From owner-netdev@oss.sgi.com Thu Sep 6 12:42:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86JgH324274 for netdev-outgoing; Thu, 6 Sep 2001 12:42:17 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86JgEd24271 for ; Thu, 6 Sep 2001 12:42:15 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15f55T-0000Kc-00; Thu, 06 Sep 2001 20:45:19 +0100 Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 To: wietse@porcupine.org (Wietse Venema) Date: Thu, 6 Sep 2001 20:45:19 +0100 (BST) Cc: kuznet@ms2.inr.ac.ru, matthias.andree@gmx.de (Matthias Andree), linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, wietse@porcupine.org, alan@lxorguk.ukuu.org.uk In-Reply-To: <20010906181826.9CCECBC06C@spike.porcupine.org> from "Wietse Venema" at Sep 06, 2001 02:18:26 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 615 Lines: 13 > Soldiers are marching down the street. The mother of one of those > soldiers is ever so proud. All the other guys are marching out of > step. Her son is the only one who does it right. > > That's what it looks like for a person who writes Internet software > that aims to work on a wide variety of platforms. I think you have the metaphor wrong. The older API is a bit like the cavalry charging into battle at the start of world war one. It may have been how everyone did it but they guys with the "newfangled, really not how it should be done, definitely not cricket" machine guns got the last laugh Alan From owner-netdev@oss.sgi.com Thu Sep 6 13:00:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86K03h24910 for netdev-outgoing; Thu, 6 Sep 2001 13:00:03 -0700 Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86Jxxd24873 for ; Thu, 6 Sep 2001 13:00:00 -0700 Received: by spike.porcupine.org (Postfix, from userid 1001) id 222DFBC06C; Thu, 6 Sep 2001 15:59:58 -0400 (EDT) Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-Reply-To: "from Alan Cox at Sep 6, 2001 08:45:19 pm" To: Alan Cox Date: Thu, 6 Sep 2001 15:59:58 -0400 (EDT) Cc: Wietse Venema , kuznet@ms2.inr.ac.ru, Matthias Andree , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010906195958.222DFBC06C@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 711 Lines: 16 Alan Cox: > > Soldiers are marching down the street. The mother of one of those > > soldiers is ever so proud. All the other guys are marching out of > > step. Her son is the only one who does it right. > > > > That's what it looks like for a person who writes Internet software > > that aims to work on a wide variety of platforms. > > I think you have the metaphor wrong. The older API is a bit like the > cavalry charging into battle at the start of world war one. It may have been > how everyone did it but they guys with the "newfangled, really not how it > should be done, definitely not cricket" machine guns got the last laugh Keep your superiority complex out of my mailbox, thank you. Wietse From owner-netdev@oss.sgi.com Thu Sep 6 13:14:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86KE7f25228 for netdev-outgoing; Thu, 6 Sep 2001 13:14:07 -0700 Received: from emma1.emma.line.org (postfix@pD951FD2B.dip.t-dialin.net [217.81.253.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86KE4d25225 for ; Thu, 6 Sep 2001 13:14:04 -0700 Received: by emma1.emma.line.org (Postfix, from userid 500) id 991CBA2023; Thu, 6 Sep 2001 22:13:59 +0200 (CEST) Date: Thu, 6 Sep 2001 22:13:59 +0200 From: Matthias Andree To: Alan Cox Cc: Wietse Venema , kuznet@ms2.inr.ac.ru, Matthias Andree , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010906221359.G13547@emma1.emma.line.org> Mail-Followup-To: Alan Cox , Wietse Venema , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20010906181826.9CCECBC06C@spike.porcupine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 809 Lines: 18 On Thu, 06 Sep 2001, Alan Cox wrote: > I think you have the metaphor wrong. The older API is a bit like the > cavalry charging into battle at the start of world war one. It may have been > how everyone did it but they guys with the "newfangled, really not how it > should be done, definitely not cricket" machine guns got the last laugh Alan, portability is an issue or Linux will lose. Admittedly, legacy interfaces do not support all of those new features, but a rather trivial patch of mine brings SIOCGIFNETMASK compatibility with both the old and the new stuff, please name precisely the objections against portability and compatibility with FreeBSD 4.x aliasing. -- Matthias Andree Outlook (Express) users: press Ctrl+F3 for the full source code of this post. begin dont_click_this_virus.exe end From owner-netdev@oss.sgi.com Thu Sep 6 13:19:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86KJTZ25406 for netdev-outgoing; Thu, 6 Sep 2001 13:19:29 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86KJQd25403 for ; Thu, 6 Sep 2001 13:19:27 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15f5fV-0000Pd-00; Thu, 06 Sep 2001 21:22:33 +0100 Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 To: wietse@porcupine.org (Wietse Venema) Date: Thu, 6 Sep 2001 21:22:33 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), wietse@porcupine.org (Wietse Venema), kuznet@ms2.inr.ac.ru, matthias.andree@gmx.de (Matthias Andree), linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20010906195958.222DFBC06C@spike.porcupine.org> from "Wietse Venema" at Sep 06, 2001 03:59:58 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 303 Lines: 9 > > how everyone did it but they guys with the "newfangled, really not how it > > should be done, definitely not cricket" machine guns got the last laugh > > Keep your superiority complex out of my mailbox, thank you. What is it about so many mail system authors and lacking sense of humour. Alan From owner-netdev@oss.sgi.com Thu Sep 6 13:22:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86KMYe25537 for netdev-outgoing; Thu, 6 Sep 2001 13:22:34 -0700 Received: from emma1.emma.line.org (postfix@pD951FD2B.dip.t-dialin.net [217.81.253.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86KMUd25534 for ; Thu, 6 Sep 2001 13:22:31 -0700 Received: by emma1.emma.line.org (Postfix, from userid 500) id A1DE1A2029; Thu, 6 Sep 2001 22:22:28 +0200 (CEST) Date: Thu, 6 Sep 2001 22:22:28 +0200 From: Matthias Andree To: jamal Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, Andi Kleen , kuznet@ms2.inr.ac.ru Subject: Re: ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010906222228.I13547@emma1.emma.line.org> Mail-Followup-To: jamal , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, Andi Kleen , kuznet@ms2.inr.ac.ru References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 966 Lines: 28 On Wed, 05 Sep 2001, jamal wrote: > --- devinet.c 2001/09/04 19:18:51 1.1 > +++ devinet.c 2001/09/04 19:31:13 > @@ -530,7 +530,7 @@ > > if ((in_dev=__in_dev_get(dev)) != NULL) { > for (ifap=&in_dev->ifa_list; (ifa=*ifap) != NULL; > ifap=&ifa->ifa_next) > - if (strcmp(ifr.ifr_name, ifa->ifa_label) == 0) > + if ((strcmp(ifr.ifr_name, ifa->ifa_label) == 0) || > (sin->sin_addr.s_addr == ifa->ifa_address)) > break; > } Thanks for trying to help, however, that's not going to work this way, sorry. 1. "sin" is cleared a few lines above, so you end up comparing 0.0.0.0 against "ifa->ifa_address". 2. two interfaces can have the same configured address, your patch might end up returning the wrong address. You'd need to write && where you wrote ||, and you'd need to save the old address. See the patch that I sent. -- Matthias Andree From owner-netdev@oss.sgi.com Thu Sep 6 13:23:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86KNeX25645 for netdev-outgoing; Thu, 6 Sep 2001 13:23:40 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86KNad25636 for ; Thu, 6 Sep 2001 13:23:37 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id QAA14788; Thu, 6 Sep 2001 16:20:39 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 6 Sep 2001 16:20:39 -0400 (EDT) From: jamal To: Wietse Venema cc: Alan Cox , , Matthias Andree , , , Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-Reply-To: <20010906195958.222DFBC06C@spike.porcupine.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1506 Lines: 38 On Thu, 6 Sep 2001, Wietse Venema wrote: > Alan Cox: > > > Soldiers are marching down the street. The mother of one of those > > > soldiers is ever so proud. All the other guys are marching out of > > > step. Her son is the only one who does it right. > > > > > > That's what it looks like for a person who writes Internet software > > > that aims to work on a wide variety of platforms. > > > > I think you have the metaphor wrong. The older API is a bit like the > > cavalry charging into battle at the start of world war one. It may have been > > how everyone did it but they guys with the "newfangled, really not how it > > should be done, definitely not cricket" machine guns got the last laugh > > Keep your superiority complex out of my mailbox, thank you. > Wietse, netlink, as a few people have pointed to you is the 'proper' way to do things. Sure, the BSDs did it the way you love it, but linux is a different operating system (cut the "if its not Scottish its crap mentality"). Netlink does improve on "the way its always been done for the last 80 years". Infact netlink has already been approved to be (at least informational) RFC. Look at a slightly dated draft at: http://search.ietf.org/internet-drafts/draft-salim-netlink-jhshk-00.txt Maybe you should preach to the BSDs about netlink? cheers, jamal PS:- If you want help on writting netlink based code to achieve what you are trying to do, just yell. Look at the source for the ip utility which is within the iproute2 package. From owner-netdev@oss.sgi.com Thu Sep 6 13:38:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86KcYm26187 for netdev-outgoing; Thu, 6 Sep 2001 13:38:34 -0700 Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86KcWd26184 for ; Thu, 6 Sep 2001 13:38:32 -0700 Received: by spike.porcupine.org (Postfix, from userid 1001) id 4BCE2BC06C; Thu, 6 Sep 2001 16:38:31 -0400 (EDT) Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-Reply-To: "from Alan Cox at Sep 6, 2001 09:22:33 pm" To: Alan Cox Date: Thu, 6 Sep 2001 16:38:31 -0400 (EDT) Cc: Wietse Venema , kuznet@ms2.inr.ac.ru, Matthias Andree , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010906203831.4BCE2BC06C@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 460 Lines: 15 Alan Cox: > > > how everyone did it but they guys with the "newfangled, really not how it > > > should be done, definitely not cricket" machine guns got the last laugh > > > > Keep your superiority complex out of my mailbox, thank you. > > What is it about so many mail system authors and lacking sense of humour. I pointed jokingly at a difference. You had to talk about superiority. The reference to email authors is completely uncalled for. Wietse From owner-netdev@oss.sgi.com Thu Sep 6 13:41:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86KfAU26305 for netdev-outgoing; Thu, 6 Sep 2001 13:41:10 -0700 Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86Kf5d26301 for ; Thu, 6 Sep 2001 13:41:06 -0700 Received: by spike.porcupine.org (Postfix, from userid 1001) id A3FBDBC06C; Thu, 6 Sep 2001 16:41:04 -0400 (EDT) Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-Reply-To: "from jamal at Sep 6, 2001 04:20:39 pm" To: jamal Date: Thu, 6 Sep 2001 16:41:04 -0400 (EDT) Cc: Wietse Venema , Alan Cox , kuznet@ms2.inr.ac.ru, Matthias Andree , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010906204104.A3FBDBC06C@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1797 Lines: 49 Please stop that BSD versus Linux drivel. Either make a constructive contribution or be silent. I don't care what API is "superior", as long as it provides me with the information that I want. Wietse jamal: > > > On Thu, 6 Sep 2001, Wietse Venema wrote: > > > Alan Cox: > > > > Soldiers are marching down the street. The mother of one of those > > > > soldiers is ever so proud. All the other guys are marching out of > > > > step. Her son is the only one who does it right. > > > > > > > > That's what it looks like for a person who writes Internet software > > > > that aims to work on a wide variety of platforms. > > > > > > I think you have the metaphor wrong. The older API is a bit like the > > > cavalry charging into battle at the start of world war one. It may have been > > > how everyone did it but they guys with the "newfangled, really not how it > > > should be done, definitely not cricket" machine guns got the last laugh > > > > Keep your superiority complex out of my mailbox, thank you. > > > > Wietse, > > netlink, as a few people have pointed to you is the 'proper' way to do > things. Sure, the BSDs did it the way you love it, but linux is a > different operating system (cut the "if its not Scottish its crap > mentality"). Netlink does improve on "the way its always been done for > the last 80 years". Infact netlink has already been approved to be (at > least informational) RFC. Look at a slightly dated draft at: > http://search.ietf.org/internet-drafts/draft-salim-netlink-jhshk-00.txt > Maybe you should preach to the BSDs about netlink? > > cheers, > jamal > > PS:- If you want help on writting netlink based code to achieve what you > are trying to do, just yell. Look at the source for the ip utility which > is within the iproute2 package. > > From owner-netdev@oss.sgi.com Thu Sep 6 13:47:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86KlY126495 for netdev-outgoing; Thu, 6 Sep 2001 13:47:34 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86KlTd26489 for ; Thu, 6 Sep 2001 13:47:29 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id QAA14885; Thu, 6 Sep 2001 16:44:40 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 6 Sep 2001 16:44:40 -0400 (EDT) From: jamal To: Wietse Venema cc: Alan Cox , , Matthias Andree , , , Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-Reply-To: <20010906204104.A3FBDBC06C@spike.porcupine.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2102 Lines: 66 Sigh. Which part dont you understand? Youve been told about 1000 times already, but let me shout: YOU CAN GET THE INFORAMTION YOU WANT IF YOU USE NETLINK. Cheers, jamal On Thu, 6 Sep 2001, Wietse Venema wrote: > Please stop that BSD versus Linux drivel. Either make a constructive > contribution or be silent. > > I don't care what API is "superior", as long as it provides me with > the information that I want. > > Wietse > > jamal: > > > > > > On Thu, 6 Sep 2001, Wietse Venema wrote: > > > > > Alan Cox: > > > > > Soldiers are marching down the street. The mother of one of those > > > > > soldiers is ever so proud. All the other guys are marching out of > > > > > step. Her son is the only one who does it right. > > > > > > > > > > That's what it looks like for a person who writes Internet software > > > > > that aims to work on a wide variety of platforms. > > > > > > > > I think you have the metaphor wrong. The older API is a bit like the > > > > cavalry charging into battle at the start of world war one. It may have been > > > > how everyone did it but they guys with the "newfangled, really not how it > > > > should be done, definitely not cricket" machine guns got the last laugh > > > > > > Keep your superiority complex out of my mailbox, thank you. > > > > > > > Wietse, > > > > netlink, as a few people have pointed to you is the 'proper' way to do > > things. Sure, the BSDs did it the way you love it, but linux is a > > different operating system (cut the "if its not Scottish its crap > > mentality"). Netlink does improve on "the way its always been done for > > the last 80 years". Infact netlink has already been approved to be (at > > least informational) RFC. Look at a slightly dated draft at: > > http://search.ietf.org/internet-drafts/draft-salim-netlink-jhshk-00.txt > > Maybe you should preach to the BSDs about netlink? > > > > cheers, > > jamal > > > > PS:- If you want help on writting netlink based code to achieve what you > > are trying to do, just yell. Look at the source for the ip utility which > > is within the iproute2 package. > > > > > From owner-netdev@oss.sgi.com Thu Sep 6 14:20:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86LKhB27229 for netdev-outgoing; Thu, 6 Sep 2001 14:20:43 -0700 Received: from emma1.emma.line.org (postfix@pD951FD2B.dip.t-dialin.net [217.81.253.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86LKcd27223 for ; Thu, 6 Sep 2001 14:20:39 -0700 Received: by emma1.emma.line.org (Postfix, from userid 500) id A73A6A201F; Thu, 6 Sep 2001 23:20:33 +0200 (CEST) Date: Thu, 6 Sep 2001 23:20:33 +0200 From: Matthias Andree To: jamal Cc: Wietse Venema , Alan Cox , kuznet@ms2.inr.ac.ru, Matthias Andree , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010906232033.L13547@emma1.emma.line.org> Mail-Followup-To: jamal , Wietse Venema , Alan Cox , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20010906204104.A3FBDBC06C@spike.porcupine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1653 Lines: 38 On Thu, 06 Sep 2001, jamal wrote: > Which part dont you understand? > > Youve been told about 1000 times already, but let me shout: > > YOU CAN GET THE INFORAMTION YOU WANT IF YOU USE NETLINK. Calm down. Please. This discussion is about portability. I'm not striving to turn Linux into FreeBSD, and neither is Wietse. Not personally addressed to anyone, but for all Linux hackers to consider are the following parts: See it from the user-space programmer's point of view. Imagine you're developing your software on FreeBSD or Solaris, or whatever. Now imagine a client/user asks you about Linux support. You figure Linux does an ioctl differently than BSD - that's all you see in the first place. You start wondering, tracking, debugging, end up reading kernel sources, and you see the difference. You go for support, and all you hear is "well, we want to keep this non-portable for egoistic compatibility reasons, use netlink instead". As to netlink, "go get ip of iproute2 and see how it does things". The programmer of a portable application is annoyed and frustrated because it's just another fucking subtle API difference, and it coincides with a boggled and outdated netdevice(7) man page. It's not a sign of quality if Linux man pages are updated months after the code either. Does anyone think these issues help Linux or get Linux anywhere except to bad reputation? There are a lot of competent people with their hands on Linux, and generally, Linux works well, and people are helpful, but sometimes, developers seem to lose the more global view. Linux is not longer an end in itself. Please don't let portability slip from your view. From owner-netdev@oss.sgi.com Thu Sep 6 16:37:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86NbjP29768 for netdev-outgoing; Thu, 6 Sep 2001 16:37:45 -0700 Received: from attila.bofh.it (postfix@attila.bofh.it [213.92.8.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86Nbfd29763 for ; Thu, 6 Sep 2001 16:37:42 -0700 Received: by attila.bofh.it (Postfix, from userid 10) id C4F7A60899; Fri, 7 Sep 2001 01:37:38 +0200 (CEST) Received: by wonderland.linux.it (Postfix/Md, from userid 1001) id B58B117EBD; Fri, 7 Sep 2001 01:37:14 +0200 (CEST) Date: Fri, 7 Sep 2001 01:37:14 +0200 From: "Marco d'Itri" To: netdev@oss.sgi.com Subject: automatic default route Message-ID: <20010907013714.A8122@wonderland.linux.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 948 Lines: 30 When I set up the ethernet card in my boot scripts: ip link set up dev eth0 ip addr add 10.0.0.1/24 brd + dev eth0 label eth0 ip addr add 10.0.0.9/24 brd + dev eth0 label eth0 I get this message: Sep 7 01:27:59 wonderland kernel: eth0: no IPv6 routers present and an extra default route for ipv6 is added by the kernel: root@wonderland:vc/2:~#ip -6 ro fe80::/10 dev eth0 proto kernel metric 256 mtu 1500 ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 default dev eth0 proto kernel metric 256 mtu 1500 unreachable default dev lo metric -1 error -101 root@wonderland:vc/2:~# This is very annoying because IPv6 enabled programs then will try connectiong to IPv6 addresses and will have to wait the timeout to try with the IPv4 address, and this means I can't use a kernel with IPv6 support on my IPv4 only hosts (or on IPv6 hosts without a configured tunnel). How can I stop the kernel adding this route? -- ciao, Marco From owner-netdev@oss.sgi.com Thu Sep 6 17:01:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8701jX30385 for netdev-outgoing; Thu, 6 Sep 2001 17:01:45 -0700 Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8701gd30382 for ; Thu, 6 Sep 2001 17:01:43 -0700 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA14312 for ; Thu, 6 Sep 2001 18:59:27 -0500 Received: from w-sridhar2.des.beaverton.ibm.com (w-sridhar2.des.beaverton.ibm.com [9.47.18.20]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8701fu261842 for ; Thu, 6 Sep 2001 20:01:41 -0400 Date: Thu, 6 Sep 2001 17:01:43 -0700 (PDT) From: Sridhar Samudrala X-Sender: sridhar@w-sridhar2.des.sequent.com To: netdev@oss.sgi.com Subject: [PATCH] fixes the type of 'index' in struct open_request Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1281 Lines: 36 The 'index' field in struct open_request is declared as __u8. This field is used to cache the syn table hash bucket index of a openreq and is set in tcp_v4_synq_add(). unsigned h = tcp_v4_synq_hash(req->af.v4_req.rmt_addr, req->rmt_port); .... req->index = h; The value that is set to this field can be any number between 0 and TCP_SYNQ_HASH_SIZE(512). The assignment causes an incorrect type conversion when the the openreq hashes to a value more than 255. Looks like this field is only set, but not being read anywhere within TCP currently, probably the reason why it was not noticed till now. I came across this while working on a patch where i would like to use the index field to get the syntable hash bucket index of the openreq instead of recalculating the hash. A simple patch to fix this is to change the type of index to __u16. --- tcp.h.orig Thu Sep 6 16:46:57 2001 +++ tcp.h Thu Sep 6 16:47:32 2001 @@ -498,7 +498,7 @@ __u16 rmt_port; __u16 mss; __u8 retrans; - __u8 index; + __u16 index; __u16 snd_wscale : 4, rcv_wscale : 4, tstamp_ok : 1, Thanks Sridhar From owner-netdev@oss.sgi.com Thu Sep 6 23:06:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8766N103558 for netdev-outgoing; Thu, 6 Sep 2001 23:06:23 -0700 Received: from oknodo.bof.de (bof.de [195.4.223.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8766Kd03555 for ; Thu, 6 Sep 2001 23:06:20 -0700 Received: (qmail 14314 invoked by uid 500); 7 Sep 2001 06:11:21 -0000 Date: Fri, 7 Sep 2001 08:11:21 +0200 From: Patrick Schaaf To: jamal , Wietse Venema , Alan Cox , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010907081121.A13586@oknodo.bof.de> References: <20010906204104.A3FBDBC06C@spike.porcupine.org> <20010906232033.L13547@emma1.emma.line.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010906232033.L13547@emma1.emma.line.org>; from matthias.andree@stud.uni-dortmund.de on Thu, Sep 06, 2001 at 11:20:33PM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 733 Lines: 20 > > YOU CAN GET THE INFORAMTION YOU WANT IF YOU USE NETLINK. > > Calm down. Please. > Not personally addressed to anyone, but for all Linux hackers to > consider are the following parts: Calm down please, and get on with your job. The way you and Wietse are trying to advocate Linux to change, is obviously just not working out. Your politics only inflame, there is no progress in this thread. Please stop it, and either ignore Linux in your software, or learn how to use netlink for your task. There have been offers of help, and you could probably have working code by now, if you took those offers, instead of writing nice political speeches. Please, EVERYBODY calm down. There is only pain. Deal with it. regards Patrick From owner-netdev@oss.sgi.com Fri Sep 7 02:41:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f879fnj08188 for netdev-outgoing; Fri, 7 Sep 2001 02:41:49 -0700 Received: from castle.nmd.msu.ru (castle.nmd.msu.ru [193.232.112.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f879fid08182 for ; Fri, 7 Sep 2001 02:41:45 -0700 Received: (qmail 28314 invoked by uid 577); 7 Sep 2001 09:48:29 -0000 Message-ID: <20010907134829.A28196@castle.nmd.msu.ru> Date: Fri, 7 Sep 2001 13:48:29 +0400 From: Andrey Savochkin To: Julian Anastasov Cc: netdev@oss.sgi.com Subject: Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip aliasbug 2.4.9 and 2.2.19] References: <20010907124220.A27338@castle.nmd.msu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from "Julian Anastasov" on Fri, Sep 07, 2001 at 12:08:05PM Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1464 Lines: 51 On Fri, Sep 07, 2001 at 12:08:05PM +0000, Julian Anastasov wrote: > > Hello, > > On Fri, 7 Sep 2001, Andrey Savochkin wrote: > > > In my opinion, the priorities in address selection should be the following: > > 1. always use prefsrc if it is specified > > 2. then for local routes, use destination > > 3. as a last resort, call that function guessing the address... > > So, you mean such change: > > if (!key.src) > key.src = key.dst; > with > if (!key.src) > key.src = res.fi->fib_prefsrc ?: key.dst; > > key.dst is != 0, so, we don't need to call FIB_RES_PREFSRC > and inet_select_addr, we prefer key.dst as source. Yes, something like this. I only wonder why there is a check `if (res.fi)' several lines below and whether !res.fi can really happen in this place. After that FIB_RES_PREFSRC is used without any precautions. Dave, could you consider the patch, please? "We used to ignore preferred source in local route, and this patch fixes it." Andrey --- net/ipv4/route.c.x Fri Sep 7 02:30:54 2001 +++ net/ipv4/route.c Fri Sep 7 02:30:54 2001 @@ -1795,14 +1795,13 @@ if (res.type == RTN_LOCAL) { if (!key.src) - key.src = key.dst; + key.src = res.fi->fib_prefsrc ? : key.dst; if (dev_out) dev_put(dev_out); dev_out = &loopback_dev; dev_hold(dev_out); key.oif = dev_out->ifindex; - if (res.fi) - fib_info_put(res.fi); + fib_info_put(res.fi); res.fi = NULL; flags |= RTCF_LOCAL; goto make_route; From owner-netdev@oss.sgi.com Fri Sep 7 03:01:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87A1Ds08618 for netdev-outgoing; Fri, 7 Sep 2001 03:01:13 -0700 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87A1Ad08615 for ; Fri, 7 Sep 2001 03:01:10 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id f87D2CF03244; Fri, 7 Sep 2001 13:02:12 GMT Date: Fri, 7 Sep 2001 13:02:12 +0000 (GMT) From: Julian Anastasov X-X-Sender: To: Andrey Savochkin cc: Subject: Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip aliasbug 2.4.9 and 2.2.19] In-Reply-To: <20010907134829.A28196@castle.nmd.msu.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 689 Lines: 26 Hello, On Fri, 7 Sep 2001, Andrey Savochkin wrote: > > key.src = res.fi->fib_prefsrc ?: key.dst; > > > > key.dst is != 0, so, we don't need to call FIB_RES_PREFSRC > > and inet_select_addr, we prefer key.dst as source. > > Yes, something like this. > I only wonder why there is a check `if (res.fi)' several lines below and > whether !res.fi can really happen in this place. > After that FIB_RES_PREFSRC is used without any precautions. It seems fib_lookup returns valid fi, 0 is not possible. I'm wondering what else we break except autofs, for local routes with prefixlen!=32, I don't know who uses the current "feature" :) > Andrey Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Fri Sep 7 09:42:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87Gglt15308 for netdev-outgoing; Fri, 7 Sep 2001 09:42:47 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87Gghd15305 for ; Fri, 7 Sep 2001 09:42:44 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA30949; Fri, 7 Sep 2001 20:39:01 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200109071639.UAA30949@ms2.inr.ac.ru> Subject: Re: notion of a local address [was: Re: ioctl SIOCGIFNETMASK: ip To: ja@ssi.bg (Julian Anastasov) Date: Fri, 7 Sep 2001 20:39:01 +0400 (MSK DST) Cc: netdev@oss.sgi.com In-Reply-To: from "Julian Anastasov" at Sep 7, 1 02:15:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 155 Lines: 9 Hello! > prefixlen!=32, I don't know who uses the current "feature" :) It is bug, not a feature. I think the patch proposed by Andrey is right. Alexey From owner-netdev@oss.sgi.com Fri Sep 7 10:49:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87HnoO16004 for netdev-outgoing; Fri, 7 Sep 2001 10:49:50 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87Hnmd16001 for ; Fri, 7 Sep 2001 10:49:48 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA01322; Fri, 7 Sep 2001 21:49:34 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200109071749.VAA01322@ms2.inr.ac.ru> Subject: Re: [PATCH] fixes the type of 'index' in struct open_request To: samudrala@us.ibm.COM (Sridhar Samudrala) Date: Fri, 7 Sep 2001 21:49:34 +0400 (MSK DST) Cc: netdev@oss.sgi.com In-Reply-To: from "Sridhar Samudrala" at Sep 7, 1 04:15:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 634 Lines: 23 Hello! > Looks like this field is only set, but not being read anywhere within TCP > currently, Yes, it was used only in some tests with timing out by calendar rather then scanning hash table. > probably the reason why it was not noticed till now. No, I remember this. It is an explicit padding now, though initialization should be deleted yet. > field to get the syntable hash bucket index of the openreq instead of > recalculating the hash. Is this really necessary? Not a big deal, of course, but it adds another 4 bytes and it is really useless. To _find_ an open request you need to calculate hash function... Alexey From owner-netdev@oss.sgi.com Fri Sep 7 16:35:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87NZHH22336 for netdev-outgoing; Fri, 7 Sep 2001 16:35:17 -0700 Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87NZEd22332 for ; Fri, 7 Sep 2001 16:35:14 -0700 Received: from southrelay03.raleigh.ibm.com (southrelay03.raleigh.ibm.com [9.37.3.210]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA15664; Fri, 7 Sep 2001 18:32:57 -0500 Received: from w-sridhar2.des.beaverton.ibm.com (w-sridhar2.des.beaverton.ibm.com [9.47.18.20]) by southrelay03.raleigh.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87NZA9136526; Fri, 7 Sep 2001 19:35:11 -0400 Date: Fri, 7 Sep 2001 16:35:12 -0700 (PDT) From: Sridhar Samudrala X-Sender: sridhar@w-sridhar2.des.sequent.com To: kuznet@ms2.inr.ac.ru, davem@redhat.com cc: Sridhar Samudrala , netdev@oss.sgi.com Subject: Re: [PATCH] fixes the type of 'index' in struct open_request In-Reply-To: <200109071749.VAA01322@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 689 Lines: 24 On Fri, 7 Sep 2001 kuznet@ms2.inr.ac.ru wrote: > > probably the reason why it was not noticed till now. > > No, I remember this. It is an explicit padding now, though > initialization should be deleted yet. If index is not used and there is no need for it and only used as padding, then the initialization needs to be removed in tcp_v4_synq_add(). --- tcp_ipv4.c.orig Fri Sep 7 16:22:26 2001 +++ tcp_ipv4.c Fri Sep 7 16:22:59 2001 @@ -781,7 +781,6 @@ req->expires = jiffies + TCP_TIMEOUT_INIT; req->retrans = 0; req->sk = NULL; - req->index = h; req->dl_next = lopt->syn_table[h]; write_lock(&tp->syn_wait_lock); Thanks Sridhar From owner-netdev@oss.sgi.com Fri Sep 7 22:13:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f885DVY27481 for netdev-outgoing; Fri, 7 Sep 2001 22:13:31 -0700 Received: from brads.dnsalias.net (IDENT:qmailr@CPE-61-9-178-125.vic.bigpond.net.au [61.9.178.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f885DQd27477 for ; Fri, 7 Sep 2001 22:13:27 -0700 Received: (qmail 11652 invoked by uid 8); 8 Sep 2001 21:12:21 -0000 Received: from pc-00245.e-smith.brads.dnsalias.net (192.168.0.245, claiming to be "bigpond.net.au") by e-smith.e-smith.brads.dnsalias.net with SMTP id smtpdK9iXDr; Sat, 08 Sep 2001 17:12:19 EDT Message-ID: <3B99A91E.5A460D1F@bigpond.net.au> Date: Sat, 08 Sep 2001 15:14:06 +1000 From: Brad Hards X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.10-pre2 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Promiscuous and Multicast semantics Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1696 Lines: 41 G'day all, I am working on adding multicast / promiscuous mode support to the CDCEther driver (USB Communication Device Class, Ethernet control model - and don't blame me for the name...) The question I have relates to how multicast and promiscuous stuff gets enabled. Sorry about the newbie type nature, but I am mainly a USB coder. Promiscuous mode first: I take it that, to enable promiscuous mode, ifconfig (or equivalant) sets the net_device.flags with IFF_PROMISC, and then calls net_device.set_multicast_list. To disable, we clear IFF_PROMISC and then call net_device.set_multicast_list. Multicast mode: If we want all the multicast addresses, ifconfig sets net->flags with IFF_ALLMULTI and then calls net_device.set_multicast_list. Same to disable receiving every multicast address. If we just want some of the multicast addresses, we set IFF_MULTICAST, and get the number of addresses as net_device.mc_count and the addresses as a linked list as net_device.mc_list, and then a call to net_device.set_multicast_list. No problems so far, I hope. What is the interaction between promiscuous mode and multicast mode? If I set promiscuous mode, is there any required changes to multicast mode (enabled or disabled)? What is the interaction between IFF_ALLMULTI and IFF_MULTICAST? If I set specific addresses, should ALL_MULTI be disabled? If I set ALL_MULTI, should the list of addresses be cleared? If I have previously set a multicast list, and the user changes it with ifconfig, will I get the whole list again, or just the changes? If just changes, how do I know that I have to delete some? If multicast is disabled (IFF_MULTICAST == 0), should I clear the multicast list? Brad From owner-netdev@oss.sgi.com Sat Sep 8 01:25:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f888Pqc30673 for netdev-outgoing; Sat, 8 Sep 2001 01:25:52 -0700 Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f888Pmd30670 for ; Sat, 8 Sep 2001 01:25:49 -0700 Received: from hsdlgw92.sdl.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id RAA14399; Sat, 8 Sep 2001 17:25:37 +0900 (JST) From: serizawa@sdl.hitachi.co.jp Received: from mailc.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.9.3/3.7W98102618) id RAA27111; Sat, 8 Sep 2001 17:25:37 +0900 (JST) Received: from localhost (seri3.sdl.hitachi.co.jp [192.168.3.31]) by mailc.sdl.hitachi.co.jp (8.9.3/3.7W98100211) with ESMTP id RAA26372; Sat, 8 Sep 2001 17:25:36 +0900 (JST) Reply-to: usagi-core@linux-ipv6.org To: Philippe.Bereski@ms.alcatel.fr Cc: netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: IPv6 over ATM ? In-Reply-To: <3B9740B5.61A51BA3@ms.alcatel.fr> References: <3B9740B5.61A51BA3@ms.alcatel.fr> X-Mailer: Mew version 1.94b37 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010908172610J.serizawa@sdl.hitachi.co.jp> Date: Sat, 08 Sep 2001 17:26:10 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 424 Lines: 14 Hello Philippe, I'm Kazuyoshi Serizawa, developing an ATM stack in USAGI Project. I wrote an PVC driver for IPv6 and testing connectivity between a KAME ATM box. Just to connect and to communicate, my stack works well, but I didn't test for performance, QoS, etc. I used separated repository for some reason, so my source isn't on USAGI CVS for now. Soon I'll commit it and inform you. Thanks, Kazuyoshi Serizawa From owner-netdev@oss.sgi.com Sat Sep 8 08:32:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f88FWfZ04260 for netdev-outgoing; Sat, 8 Sep 2001 08:32:41 -0700 Received: from vaio.greennet (pool-151-196-233-140.balt.east.verizon.net [151.196.233.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f88FWYd04256 for ; Sat, 8 Sep 2001 08:32:34 -0700 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id LAA23656; Sat, 8 Sep 2001 11:32:01 -0400 Date: Sat, 8 Sep 2001 11:32:01 -0400 (EDT) From: Donald Becker X-Sender: becker@vaio.greennet To: Brad Hards cc: netdev@oss.sgi.com Subject: Re: Promiscuous and Multicast semantics In-Reply-To: <3B99A91E.5A460D1F@bigpond.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3804 Lines: 87 On Sat, 8 Sep 2001, Brad Hards wrote: > The question I have relates to how multicast and promiscuous stuff gets > enabled. ... > Promiscuous mode first: > I take it that, to enable promiscuous mode, ifconfig (or equivalant) sets the > net_device.flags with IFF_PROMISC, and then calls > net_device.set_multicast_list. To disable, we clear IFF_PROMISC and then call > net_device.set_multicast_list. Correct. Every change to the Rx filter is communicated by a call to net_device.set_multicast_list(dev) [[ This name is slightly misleading: at one point this call had three parameters, including the list to set. Someone made the bogus change of dropping two parameters without changing the function name. Doing this made backwards-compatible code very ugly. ]] > Multicast mode: > If we want all the multicast addresses, ifconfig sets net->flags with > IFF_ALLMULTI and then calls net_device.set_multicast_list. Same to disable > receiving every multicast address. > If we just want some of the multicast addresses, we set IFF_MULTICAST, and get > the number of addresses as net_device.mc_count and the addresses as a linked > list as net_device.mc_list, and then a call to net_device.set_multicast_list. Correct. > What is the interaction between promiscuous mode and multicast mode? If I set > promiscuous mode, is there any required changes to multicast mode (enabled or > disabled)? You should refer to the code in pci-skeleton.c or the older (ISA-oriented) skeleton.c to confirm your understanding. IFF_PROMISC overrides all else. It implies ALLMULTI. Most hardware has separate bits to enable HW_ALLPHYS and HW_ALLMULTI. The netdriver interface does not match this: set both HW_ALLPHYS and HW_ALLMULTI when IFF_PROMISC is set. > What is the interaction between IFF_ALLMULTI and IFF_MULTICAST? If I set > specific addresses, should ALL_MULTI be disabled? If I set ALL_MULTI, should > the list of addresses be cleared? IFF_ALLMULTI overrides the multicast list. You need not check the multicast list when IFF_ALLMULTI is set. Most of my drivers use the module parameter 'multicast_filter_limit' to treat too many multicast addresses as the equivalent of ALLMULTI. The default value is set based on the multicast filter size and how painful it is to set the multicast list. For instance, on Intel chips it is very time consuming to change a long multicast list, and the receiver is shut off (!) while the chip is loading the new list. Other chips have register-loaded multicast hash filters based on the CRC of the address. The cost of loading the filter to the chip is constant, independent of the multicast filter list length. There the controlling factor is when the hash filter becomes ineffective and the (trivial) effort of computing the CRC is wasted. Keep in mind that a single write the Ethernet chip (even on PCI) might cost the same as executing thousands of cached instructions. Doing an unconditional write might look simpler, but keeping the old state around to avoid a duplicate write is now well worth the complexity. > If I have previously set a multicast list, and the user changes it with > ifconfig, will I get the whole list again, or just the changes? If just > changes, how do I know that I have to delete some? The whole list. You have to recalculate your filter. While it might seem wasteful, this is the most efficient method with the common case of a short multicast list. If you have a long multicast list (very rare) you should effectively do ALLMULTI as above. > If multicast is disabled (IFF_MULTICAST == 0), should I clear the multicast > list? Yes. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Sun Sep 9 02:45:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f899jpF17994 for netdev-outgoing; Sun, 9 Sep 2001 02:45:51 -0700 Received: from mail.SerNet.DE (exim@mail.SerNet.DE [193.159.217.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f899jmd17990 for ; Sun, 9 Sep 2001 02:45:48 -0700 Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 2.12 #1) for netdev@oss.sgi.com id 15g19t-00087P-00; Sun, 9 Sep 2001 11:45:45 +0200 Received: by intern.SerNet.DE id 15g19t-0005cF-00; Sun, 9 Sep 2001 11:45:45 +0200 Date: Sun, 9 Sep 2001 11:45:45 +0200 (MEST) From: Lutz Pressler To: netdev@oss.sgi.com Subject: "ip": listing of proxy ARP entries? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: Organization: Service Network GmbH, Goettingen, Germany Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1133 Lines: 35 Hello, I am not able to get information about manually set proxy ARP entries with the "ip" tool (iproute2-ss010824), tested on both 2.2.19 and 2.4.8-ac7 kernels. # ip neigh add proxy 172.20.1.1 dev eth0 The "arp" tool then yields (normal entries trimmed) # arp -n Address HWtype HWaddress Flags Mask Iface 192.168.1.254 ether 00:80:C8:F6:47:6F C eth0 172.20.1.1 * * MP eth0 but "ip" only shows # ip neigh show 192.168.1.254 dev eth0 lladdr 00:80:c8:f6:47:6f nud reachable Is this expected behaviour or a (kernel) bug? Trying different "nud" options does not help. Inserting debugging code at the beginning of print_neigh in iproute2/ip/ipneigh.c shows that no data is sent through the netlink socket for proxy ARP entries. Greetings, Lutz -- _ | Lutz Pressler | Tel: ++49-551-3700002 |_ |\ | | Service Network GmbH | FAX: ++49-551-3700009 ._|ER | \|ET | Bahnhofsallee 1b | mailto:lp@SerNet.DE Service Network | D-37081 Goettingen | http://www.SerNet.DE/ From owner-netdev@oss.sgi.com Sun Sep 9 02:51:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f899pSl18154 for netdev-outgoing; Sun, 9 Sep 2001 02:51:28 -0700 Received: from brads.dnsalias.net (IDENT:qmailr@CPE-61-9-178-125.vic.bigpond.net.au [61.9.178.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f899pMd18146 for ; Sun, 9 Sep 2001 02:51:23 -0700 Received: (qmail 16080 invoked by uid 8); 10 Sep 2001 01:50:25 -0000 Received: from pc-00245.e-smith.brads.dnsalias.net (192.168.0.245, claiming to be "bigpond.net.au") by e-smith.e-smith.brads.dnsalias.net with SMTP id smtpdMjhwRh; Sun, 09 Sep 2001 21:50:21 EDT Message-ID: <3B9B3BBA.28918EB9@bigpond.net.au> Date: Sun, 09 Sep 2001 19:51:54 +1000 From: Brad Hards X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.10-pre2 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: Donald Becker Subject: Re: Promiscuous and Multicast semantics References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2300 Lines: 47 Donald Becker wrote: > Correct. Every change to the Rx filter is communicated by a call to > net_device.set_multicast_list(dev) Is this a "necessary", in that if that call is made, something has definately changed? > > What is the interaction between promiscuous mode and multicast mode? If I set > > promiscuous mode, is there any required changes to multicast mode (enabled or > > disabled)? > > You should refer to the code in pci-skeleton.c or the older > (ISA-oriented) skeleton.c to confirm your understanding. OK, that did help, although having your explaination to read with the code certainly made it a lot easier. Thanks very much for the assistance. > Most of my drivers use the module parameter 'multicast_filter_limit' to > treat too many multicast addresses as the equivalent of ALLMULTI. The > default value is set based on the multicast filter size and how painful > it is to set the multicast list. The CDC Ethernet descriptor actually specifies how many filters are available (if any) for this device, and I was planning to use that, rather than a module parameter, since the driver can conceivably support a number of different devices on the same host. Does this seem reasonable? > Keep in mind that a single write the Ethernet chip (even on PCI) might > cost the same as executing thousands of cached instructions. Doing an > unconditional write might look simpler, but keeping the old state around > to avoid a duplicate write is now well worth the complexity. Going back to my first question, does this mean that the higher level net code will shield the driver from calls to .set_multicast_list() where no change would have occurred (such as changing the multicast list while promiscuous mode is enabled)? Or does the driver have to do this, if required? After all that, I have two more questions: 1. Do the higher level networking functions "know" or care whether perfect multicast filtering or hashing is being used? Or does some upper level networking function always apply filtering, on the assumption that some form of hashed multicast is (or may be) in use? 2. In pci-skeleton, AcceptMyPhys seems to be asserted in any case. Can the "do not receive directed packets" (essentially !AcceptMyPhys) case be communicated to a driver? Brad From owner-netdev@oss.sgi.com Sun Sep 9 05:56:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f89CuUx25879 for netdev-outgoing; Sun, 9 Sep 2001 05:56:30 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f89CuPd25876 for ; Sun, 9 Sep 2001 05:56:25 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f89CtLU25526; Sun, 9 Sep 2001 15:55:25 +0300 Date: Sun, 9 Sep 2001 15:55:21 +0300 (EEST) From: Pekka Savola To: cc: , , , Subject: Re: source routing honored by hosts? 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: 1979 Lines: 54 On Sat, 1 Sep 2001, Pekka Savola wrote: > One could argue, though, that obeying source routing should be togglable, > as it's impossible to authenticate, and may allow the packets traverse > where they normally should never be able to go. > > (Rather challenging to firewall, too, as real destination can be hidden > in the routing header options.. urghh..) > > And don't you just love....: > > Security Considerations > > The security features of IPv6 are described in the Security > Architecture for the Internet Protocol [RFC-2401]. > > sigh. the ipsec security pixie dust at it again. > > Writing to ipng mailing list.. There has not been an "official" statement on ipng IETF list on this, but the general consensus seems to be that hosts should not forward source-routed frames, at least by default. Perhaps it would be time to introduce 'accept_source_route' sysctl toggle for IPv6 too; some want to turn off doing source routing e.g. in access-routers and the like. So, as an intermediate approach, I think what David proposed is a good way (device-specific forwarding toggle might be a good thing too, but separate issue to be discussed): --- linux-2.4/net/ipv6/ip6_output.c Thu Apr 19 18:38:50 2001 +++ linux-2.4.new/net/ipv6/ip6_output.c Sun Sep 9 14:56:32 2001 @@ -724,7 +724,9 @@ struct ipv6hdr *hdr = skb->nh.ipv6h; struct inet6_skb_parm *opt =(struct inet6_skb_parm*)skb->cb; - if (ipv6_devconf.forwarding == 0 && opt->srcrt == 0) + /* Note: RFC2460 implies all nodes should do source routing, but it + doesn't make sense for hosts and there would be no way to toggle it off */ + if (ipv6_devconf.forwarding == 0) goto error; skb->ip_summed = CHECKSUM_NONE; (this practically reverts one of many changes in r1.14 from 3 years ago). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Sun Sep 9 07:08:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f89E8av26733 for netdev-outgoing; Sun, 9 Sep 2001 07:08:36 -0700 Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f89E8Wd26730 for ; Sun, 9 Sep 2001 07:08:32 -0700 Received: from localhost (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 XAA27191; Sun, 9 Sep 2001 23:09:56 +0900 To: ipng@sunroof.eng.sun.com, usagi-users@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.hongo.wide.ad.jp/%7Eyoshfuji/ 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://cerberus.hongo.wide.ad.jp/%7Eyoshfuji/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010909230956M.yoshfuji@linux-ipv6.org> Date: Sun, 09 Sep 2001 23:09:56 +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: 573 Lines: 16 In article (at Sun, 9 Sep 2001 15:55:21 +0300 (EEST)), Pekka Savola says: > There has not been an "official" statement on ipng IETF list on this, but > the general consensus seems to be that hosts should not forward > source-routed frames, at least by default. Who did say that it should be disabled by default? Consensus seems to be "hosts are expected to forward source-routed frames by default." ...or, do I misunderstand something? We need the conclusion of this discussion... -- yoshfuji From owner-netdev@oss.sgi.com Sun Sep 9 07:15:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f89EFHN26885 for netdev-outgoing; Sun, 9 Sep 2001 07:15:17 -0700 Received: from vaio.greennet (pool-151-196-236-37.balt.east.verizon.net [151.196.236.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f89EFAd26882 for ; Sun, 9 Sep 2001 07:15:10 -0700 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id KAA02019; Sun, 9 Sep 2001 10:15:23 -0400 Date: Sun, 9 Sep 2001 10:15:22 -0400 (EDT) From: Donald Becker X-Sender: becker@vaio.greennet To: Brad Hards cc: netdev@oss.sgi.com Subject: Re: Promiscuous and Multicast semantics In-Reply-To: <3B9B3BBA.28918EB9@bigpond.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4781 Lines: 94 On Sun, 9 Sep 2001, Brad Hards wrote: > Donald Becker wrote: > > > Correct. Every change to the Rx filter is communicated by a call to > > net_device.set_multicast_list(dev) > Is this a "necessary", in that if that call is made, something has definately > changed? No, there are cases where set_multicast_list() is called without a change in the Rx filter. It's usually called three times when the interface is started, when you would expect that just once would do. (Cf. the ioctl() calls from 'ifconfig'.) > > Most of my drivers use the module parameter 'multicast_filter_limit' to > > treat too many multicast addresses as the equivalent of ALLMULTI. The > > default value is set based on the multicast filter size and how painful > > it is to set the multicast list. > The CDC Ethernet descriptor actually specifies how many filters are available > (if any) for this device, and I was planning to use that, rather than a module > parameter, since the driver can conceivably support a number of different > devices on the same host. Does this seem reasonable? No. Imagine the case where you have a 512 bin statistical filter. That doesn't mean you can effectively filter 511 Ethernet addresses. And if you have over a few dozen multicast addresses, you are likely changing the list very frequently. I once investigated adding a time component to the code for loading the multicast filter. If the multicast list changed frequently, it would remain in Rx-all-multicast mode. Once the list stopped being changed, the driver would load the filter. I never found a real environment where this extra complexity made a significant difference. It's very easy to put in "optimizations" like this without taking into account how expensive complexity is for long-term maintenance. > Going back to my first question, does this mean that the higher level net code > will shield the driver from calls to .set_multicast_list() where no change > would have occurred (such as changing the multicast list while promiscuous > mode is enabled)? Or does the driver have to do this, if required? The generic interface control levels don't filter out all non-changes. The driver should keep track if anything has changed. Even if the upper levels did perfectly minimize the changes, the driver has additional knowledge. For instance adding to the multicast list might still result in the same hash filter setting. > After all that, I have two more questions: > 2. In pci-skeleton, AcceptMyPhys seems to be asserted in any case. Can > the "do not receive directed packets" (essentially !AcceptMyPhys) case > be communicated to a driver? No. Note that not all Ethernet chips support turning off reception of directed unicast packets. > 1. Do the higher level networking functions "know" or care whether perfect > multicast filtering or hashing is being used? Or does some upper level > networking function always apply filtering, on the assumption that some form > of hashed multicast is (or may be) in use? There is always additional software filtering for multicast addresses. With IPv4 multicast this needs to be done anyway, since in a foolish economy they under-mapped the IP multicast Here is a snip from something I wrote a while back: http://www.scyld.com/expert/multicast.html ________________________________________________________________ Mapping of Multicast IP Addresses to Ethernet Addresses. As explained above, Ethernet has a 48 bit destination address field, with 47 bits in multicast address range. IP has a 32 bit address, with 28 bits in the multicast address range. The obvious solution is to set a fixed value for the 20 leading Ethernet address bits, and directly map the 28 IP multicast address bits in the remaining Ethernet address bits. Even better, use a fixed assigned value for the 16 leading address bits and directly substitute the IP multicast address for the remaining 32 bits. In this case, the Internet designers failed to select the obvious method in favor of an approach that is less good. The prefix 01:00:5e identifies the frame as multicast, the next bit is always 0 and only 23 bits are left to the multicast address. The 23 least significant bits of the IP multicast group are placed in the frame. With the ignored five high-order bits, the mapping is obviously not one-to-one. 32 different IP multicast groups being mapped to the same Ethernet multicast address. This means that the Ethernet layer acts as an imperfect filter, and the IP layer must do further filtering on the datagrams from the data-link layer. ________________ Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Sun Sep 9 07:26:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f89EQFp27054 for netdev-outgoing; Sun, 9 Sep 2001 07:26:15 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f89EQCd27051 for ; Sun, 9 Sep 2001 07:26:12 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f89EQ0Y26052; Sun, 9 Sep 2001 17:26:00 +0300 Date: Sun, 9 Sep 2001 17:26:00 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: , , Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? In-Reply-To: <20010909230956M.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1271 Lines: 31 On Sun, 9 Sep 2001, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article (at Sun, 9 Sep 2001 15:55:21 +0300 (EEST)), Pekka Savola says: > > > There has not been an "official" statement on ipng IETF list on this, but > > the general consensus seems to be that hosts should not forward > > source-routed frames, at least by default. > > Who did say that it should be disabled by default? > Consensus seems to be "hosts are expected to forward source-routed > frames by default." > > ...or, do I misunderstand something? > > We need the conclusion of this discussion... I think it was quite widely accepted (at least nobody objected, thus I said "consensus") that _hosts_, at least by default, should not forward source-routed packets. "local source-routing" from IPv4 context (same incoming/outgoing interface) was also mentioned w.r.t. host behaviour. There were ... arguments back and forth whether forwarding source-routed packets by default is safe (enough) for routers. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Mon Sep 10 01:06:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A86I108132 for netdev-outgoing; Mon, 10 Sep 2001 01:06:18 -0700 Received: from khan.acc.umu.se (daemon@khan.acc.umu.se [130.239.18.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A86Ed08128 for ; Mon, 10 Sep 2001 01:06:15 -0700 Received: (from tao@localhost) by khan.acc.umu.se (8.11.6/8.11.6) id f8A85cH19752; Mon, 10 Sep 2001 10:05:38 +0200 (MEST) Date: Mon, 10 Sep 2001 10:05:37 +0200 From: David Weinehall To: Alan Cox , Wietse Venema , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010910100537.W26627@khan.acc.umu.se> References: <20010906181826.9CCECBC06C@spike.porcupine.org> <20010906221359.G13547@emma1.emma.line.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20010906221359.G13547@emma1.emma.line.org>; from matthias.andree@stud.uni-dortmund.de on Thu, Sep 06, 2001 at 10:13:59PM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1707 Lines: 32 On Thu, Sep 06, 2001 at 10:13:59PM +0200, Matthias Andree wrote: > On Thu, 06 Sep 2001, Alan Cox wrote: > > > I think you have the metaphor wrong. The older API is a bit like the > > cavalry charging into battle at the start of world war one. It may have been > > how everyone did it but they guys with the "newfangled, really not how it > > should be done, definitely not cricket" machine guns got the last laugh > > Alan, portability is an issue or Linux will lose. Admittedly, legacy > interfaces do not support all of those new features, but a rather > trivial patch of mine brings SIOCGIFNETMASK compatibility with both the > old and the new stuff, please name precisely the objections against > portability and compatibility with FreeBSD 4.x aliasing. Are you saying that Linux should implement compability with _new_ features in FreeBSD 4.x, while at the same time frowning at the fact that Linux introduces a new API?! The mind boggles at the thought. Please accept, that sometimes, just sometimes, there is a superior way to do something, and implementing support for that might not be such a bad idea after all. Whining about this causing "bloat and maintainance nightmares" (no, not a direct quote, sorry for that) doesn't cut it, because there are probably more Linux-machines running the software than any BSD-machines, thus the netlink-code will get _more_ testing than the legacy API. /David Weinehall _ _ // David Weinehall /> Northern lights wander \\ // Project MCA Linux hacker // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ ; Mon, 10 Sep 2001 05:26:05 -0700 Received: by spike.porcupine.org (Postfix, from userid 1001) id 80CA4BC06C; Mon, 10 Sep 2001 08:26:03 -0400 (EDT) Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-Reply-To: <20010910100537.W26627@khan.acc.umu.se> "from David Weinehall at Sep 10, 2001 10:05:37 am" To: David Weinehall Date: Mon, 10 Sep 2001 08:26:03 -0400 (EDT) Cc: Alan Cox , Wietse Venema , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010910122603.80CA4BC06C@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 487 Lines: 14 David Weinehall: > Are you saying that Linux should implement compability with _new_ > features in FreeBSD 4.x, while at the same time frowning at the fact > that Linux introduces a new API?! The mind boggles at the thought. SIOCGIFNETMASK is not "new". It exists in systems as ancient as SunOS 4.x, which pre dates FreeBSD 4.x by about 10 years. Evidence: RTFM the Postfix source code :-) In other words, SIOCGIFNETMASK existed long before Linux could plug into a network. Wietse From owner-netdev@oss.sgi.com Mon Sep 10 05:54:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ACsel14602 for netdev-outgoing; Mon, 10 Sep 2001 05:54:40 -0700 Received: from khan.acc.umu.se (daemon@khan.acc.umu.se [130.239.18.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ACsbd14598 for ; Mon, 10 Sep 2001 05:54:37 -0700 Received: (from tao@localhost) by khan.acc.umu.se (8.11.6/8.11.6) id f8ACrQl13845; Mon, 10 Sep 2001 14:53:26 +0200 (MEST) Date: Mon, 10 Sep 2001 14:53:25 +0200 From: David Weinehall To: Wietse Venema Cc: Alan Cox , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010910145325.X26627@khan.acc.umu.se> References: <20010910100537.W26627@khan.acc.umu.se> <20010910122603.80CA4BC06C@spike.porcupine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20010910122603.80CA4BC06C@spike.porcupine.org>; from wietse@porcupine.org on Mon, Sep 10, 2001 at 08:26:03AM -0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1219 Lines: 27 On Mon, Sep 10, 2001 at 08:26:03AM -0400, Wietse Venema wrote: > David Weinehall: > > Are you saying that Linux should implement compability with _new_ > > features in FreeBSD 4.x, while at the same time frowning at the fact > > that Linux introduces a new API?! The mind boggles at the thought. > > SIOCGIFNETMASK is not "new". It exists in systems as ancient as > SunOS 4.x, which pre dates FreeBSD 4.x by about 10 years. > > Evidence: RTFM the Postfix source code :-) > > In other words, SIOCGIFNETMASK existed long before Linux could plug > into a network. "[snip] old and the new stuff, please name precisely the objections against portability and compatibility with FreeBSD 4.x aliasing." ^^^^^^^^^^^^^^^^^^^^ This is what lead me to my conclusion. Care to clarify? If you simply meant SIOCGIFNETMASK, why not write that instead instead of involving FreeBSD 4.x?! /David Weinehall _ _ // David Weinehall /> Northern lights wander \\ // Project MCA Linux hacker // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ ; Mon, 10 Sep 2001 06:02:22 -0700 Received: from mail pickup service by yucntsys2.yucom.be with Microsoft SMTPSVC; Mon, 10 Sep 2001 15:01:50 +0200 Received: from vger.kernel.org ([199.183.24.194]) by yucntsys2.yucom.be with Microsoft SMTPSVC(5.5.1877.687.68); Mon, 10 Sep 2001 10:14:47 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Sep 2001 04:06:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Sep 2001 04:06:07 -0400 Received: from khan.acc.umu.se ([130.239.18.139]:63116 "EHLO khan.acc.umu.se") by vger.kernel.org with ESMTP id ; Mon, 10 Sep 2001 04:05:50 -0400 Received: (from tao@localhost) by khan.acc.umu.se (8.11.6/8.11.6) id f8A85cH19752; Mon, 10 Sep 2001 10:05:38 +0200 (MEST) Date: Mon, 10 Sep 2001 10:05:37 +0200 From: David Weinehall To: Alan Cox , Wietse Venema , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010910100537.W26627@khan.acc.umu.se> References: <20010906181826.9CCECBC06C@spike.porcupine.org> <20010906221359.G13547@emma1.emma.line.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20010906221359.G13547@emma1.emma.line.org>; from matthias.andree@stud.uni-dortmund.de on Thu, Sep 06, 2001 at 10:13:59PM +0200 X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1951 Lines: 37 On Thu, Sep 06, 2001 at 10:13:59PM +0200, Matthias Andree wrote: > On Thu, 06 Sep 2001, Alan Cox wrote: > > > I think you have the metaphor wrong. The older API is a bit like the > > cavalry charging into battle at the start of world war one. It may have been > > how everyone did it but they guys with the "newfangled, really not how it > > should be done, definitely not cricket" machine guns got the last laugh > > Alan, portability is an issue or Linux will lose. Admittedly, legacy > interfaces do not support all of those new features, but a rather > trivial patch of mine brings SIOCGIFNETMASK compatibility with both the > old and the new stuff, please name precisely the objections against > portability and compatibility with FreeBSD 4.x aliasing. Are you saying that Linux should implement compability with _new_ features in FreeBSD 4.x, while at the same time frowning at the fact that Linux introduces a new API?! The mind boggles at the thought. Please accept, that sometimes, just sometimes, there is a superior way to do something, and implementing support for that might not be such a bad idea after all. Whining about this causing "bloat and maintainance nightmares" (no, not a direct quote, sorry for that) doesn't cut it, because there are probably more Linux-machines running the software than any BSD-machines, thus the netlink-code will get _more_ testing than the legacy API. /David Weinehall _ _ // David Weinehall /> Northern lights wander \\ // Project MCA Linux hacker // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ ; Mon, 10 Sep 2001 06:22:15 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f8ADM9n01329 for ; Mon, 10 Sep 2001 16:22:09 +0300 Date: Mon, 10 Sep 2001 16:22:08 +0300 (EEST) From: Pekka Savola To: Subject: IPv6 Addressing Architecture (RFC2373) updates Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4154 Lines: 116 Hello all, As IPv6 Addressing Architectures draft is being revised, I took the time to go through the new spec and check (not very thoroughly, though) what appears to be changed/missing (and some left over from the original spec). (http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-06.txt): --8<-- 2.5.2 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It must never be assigned to any node. ==> should adding this to interfaces be forbidden in addrconf.c:ipv6_add_addr? The unspecified address must not be used as the destination address of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a source address of unspecified must never be forwarded by an IPv6 router. ==> the unspecified source address must not be forwarded, check it in route.c:ipv6_route_input? ==> also check that unspecified is not destination address? (one could argue that it's not router's business to police this, though) 2.5.3 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It may be used by a node to send an IPv6 packet to itself. It may never be assigned to any physical interface. ==> should adding this to interfaces other than loopback be forbidden in addrconf.c:ipv6_add_addr or the like? (probably not worth the pain) The loopback address must not be used as the source address in IPv6 packets that are sent outside of a single node. An IPv6 packet with a destination address of loopback must never be sent outside of a single node and must never be forwarded by an IPv6 router. A packet received on an interface with destination address of loopback must be dropped. ==> dst and source loopback address should be checked in route.c:ipv6_route_input ? 2.5.6 Routers must not forward any packets with link-local source or destination addresses to other links. ==> destination already apparently checked in route.c:ipv6_route_input, source too? Routers must not forward any packets with site-local source or destination addresses outside of the site. ==> not checked, but semantics of site site-scoped routing are quite fuzzy.. 2.6 o An anycast address must not be used as the source address of an IPv6 packet. ==> check in source address selection (can't check otherwise) for IPV6_ADDR_ANYCAST; addrconf.c:ipv6_get_saddr ? Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets to which they have interfaces. ==> Anycast listening not supported yet (shouldn't be a big problem, but userland tools lack the mechanism), but could add a comment. 2.7 Multicast addresses must not be used as source addresses in IPv6 packets or appear in any Routing header. ==> Multicast src checked in ipv6_route_input, need to check otherwise?; routing header? ==> Check that multicast address can't be assigned to an interface, like USAGI: addrconf.c.diff r1.69 Routers must not forward any multicast packets beyond of the scope indicated by the scop field in the destination multicast address. ==> Multicast routing not supported yet, could add a comment so this won't be forgotten. 2.8 A router is required to recognize all addresses that a host is required to recognize, plus the following addresses as identifying. itself: o The Subnet-Router Anycast Addresses for all interfaces for which it is configured to act as a router. o The All-Routers Multicast Addresses defined in section 2.7.1. ==> Subnet-Router Anycast, when anycast support is added. ==> All-Routers Multicast Address added by the kernel (as discussed on netdev); this is good because that way e.g. daemons requiring these need not monitor interface state and rejoin if interfaces are brough up and down -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Mon Sep 10 06:52:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ADqZo16725 for netdev-outgoing; Mon, 10 Sep 2001 06:52:35 -0700 Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ADqVd16722 for ; Mon, 10 Sep 2001 06:52:32 -0700 Received: by spike.porcupine.org (Postfix, from userid 1001) id EA1BFBC06C; Mon, 10 Sep 2001 09:52:30 -0400 (EDT) Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-Reply-To: <20010910145325.X26627@khan.acc.umu.se> "from David Weinehall at Sep 10, 2001 02:53:25 pm" To: David Weinehall Date: Mon, 10 Sep 2001 09:52:30 -0400 (EDT) Cc: Wietse Venema , Alan Cox , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010910135230.EA1BFBC06C@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1170 Lines: 28 David Weinehall: > On Mon, Sep 10, 2001 at 08:26:03AM -0400, Wietse Venema wrote: > > David Weinehall: > > > Are you saying that Linux should implement compability with _new_ > > > features in FreeBSD 4.x, while at the same time frowning at the fact > > > that Linux introduces a new API?! The mind boggles at the thought. > > > > SIOCGIFNETMASK is not "new". It exists in systems as ancient as > > SunOS 4.x, which pre dates FreeBSD 4.x by about 10 years. > > > > Evidence: RTFM the Postfix source code :-) > > > > In other words, SIOCGIFNETMASK existed long before Linux could plug > > into a network. Other vendors with SIOCGIFNETMASK in 10-year old releases: DEC, HP, IBM. > "[snip] old and the new stuff, please name precisely the objections > against portability and compatibility with FreeBSD 4.x aliasing." > ^^^^^^^^^^^^^^^^^^^^ > This is what lead me to my conclusion. Care to clarify? If you simply > meant SIOCGIFNETMASK, why not write that instead instead of involving > FreeBSD 4.x?! The poster was referring to systems that he has personal experience with. Not everyone is a dinosaur like I am. Wietse From owner-netdev@oss.sgi.com Mon Sep 10 07:03:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AE35Y17015 for netdev-outgoing; Mon, 10 Sep 2001 07:03:05 -0700 Received: from zmailer.org (mail.zmailer.org [194.252.70.162]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AE34d17012 for ; Mon, 10 Sep 2001 07:03:04 -0700 Received: (mea@zmailer.org) by mail.zmailer.org id ; Mon, 10 Sep 2001 17:02:41 +0300 Date: Mon, 10 Sep 2001 17:02:41 +0300 From: Matti Aarnio To: Wietse Venema Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010910170241.Q11046@mea-ext.zmailer.org> References: <20010910145325.X26627@khan.acc.umu.se> <20010910135230.EA1BFBC06C@spike.porcupine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010910135230.EA1BFBC06C@spike.porcupine.org>; from wietse@porcupine.org on Mon, Sep 10, 2001 at 09:52:30AM -0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 512 Lines: 15 On Mon, Sep 10, 2001 at 09:52:30AM -0400, Wietse Venema wrote: > Other vendors with SIOCGIFNETMASK in 10-year old releases: DEC, HP, IBM. ... > The poster was referring to systems that he has personal experience > with. Not everyone is a dinosaur like I am. Just in between us MTA writing dinosaurs, could you care to explain why Postfix needs to know the netmask associated with each IP address ? Knowledge about IP addresses I do - sort of - understand, but why netmask ? > Wietse /Matti Aarnio From owner-netdev@oss.sgi.com Mon Sep 10 07:37:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AEbLL18105 for netdev-outgoing; Mon, 10 Sep 2001 07:37:21 -0700 Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AEbId18102 for ; Mon, 10 Sep 2001 07:37:18 -0700 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8AEajp03562 for ; Mon, 10 Sep 2001 10:36:45 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 10 Sep 2001 10:36:57 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S334RWH9; Mon, 10 Sep 2001 10:36:53 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RAA7K90B; Mon, 10 Sep 2001 10:37:01 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id D0BEA4EE for ; Mon, 10 Sep 2001 10:37:46 -0400 (EDT) Message-ID: <3B9CD03A.EBD40915@nortelnetworks.com> Date: Mon, 10 Sep 2001 10:37:46 -0400 From: "Christopher Friesen" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-custom i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: "ip": listing of proxy ARP entries? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1050 Lines: 33 Lutz Pressler wrote: > > Hello, > > I am not able to get information about manually set proxy ARP entries > with the "ip" tool (iproute2-ss010824), tested on both 2.2.19 and > 2.4.8-ac7 kernels. > > # ip neigh add proxy 172.20.1.1 dev eth0 > > The "arp" tool then yields (normal entries trimmed) > # arp -n > Address HWtype HWaddress Flags Mask Iface > 192.168.1.254 ether 00:80:C8:F6:47:6F C eth0 > 172.20.1.1 * * MP eth0 > > but "ip" only shows > # ip neigh show > 192.168.1.254 dev eth0 lladdr 00:80:c8:f6:47:6f nud reachable > > Is this expected behaviour or a (kernel) bug? I'd like to know about this as well, since this is the only reason why I keep the "arp" command around. 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 Mon Sep 10 09:15:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AGFfp21049 for netdev-outgoing; Mon, 10 Sep 2001 09:15:41 -0700 Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AGFdd21045 for ; Mon, 10 Sep 2001 09:15:40 -0700 Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id MAA31326; Mon, 10 Sep 2001 12:12:24 -0400 (EDT) (envelope-from dennis@etinc.com) Message-Id: <5.0.2.1.0.20010910121002.01712b40@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 10 Sep 2001 12:11:12 -0400 To: jamal , Wietse Venema From: Dennis Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Cc: Alan Cox , , Matthias Andree , , , In-Reply-To: References: <20010906195958.222DFBC06C@spike.porcupine.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 147 Lines: 6 At 04:20 PM 09/06/2001, jamal wrote: >Infact netlink has already been approved to be (at >least informational) RFC. Wow! It MUST be good then!!! From owner-netdev@oss.sgi.com Mon Sep 10 12:27:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AJRQB25175 for netdev-outgoing; Mon, 10 Sep 2001 12:27:26 -0700 Received: from eventhorizon.antefacto.net (eventhorizon.antefacto.net [193.120.245.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AJRNd25170 for ; Mon, 10 Sep 2001 12:27:24 -0700 Received: from antefacto.com (pixelbeat.internal.antefacto.com [172.24.1.107]) by eventhorizon.antefacto.net (8.11.0/8.11.0) with ESMTP id f8AJRMu22681 for ; Mon, 10 Sep 2001 20:27:22 +0100 Message-ID: <3B9D1325.8030304@antefacto.com> Date: Mon, 10 Sep 2001 20:23:17 +0100 From: Padraig Brady User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.os.linux.networking To: netdev@oss.sgi.com Subject: How to determine source ip address Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 666 Lines: 24 Hi, I'm writing a network app (currently on linux 2.2.18, but soon moving to 2.4) that needs to build up ip & tcp packets manually. So my question is how do I determine the source ip address to use for a given destination ip address. I.E. take account of multiple interfaces/routes/ aliases/... Could I create a temporary UDP socket and connect() it. If indeed the kernel fills in the appropriate info when "connecting" a UDP socket (source ip/port), how do I read this info? If a port number is not allocated with the above connect(), how do I manually allocate a source port, bind()? Or do I have to resort to ioctl()? thanks, Padraig. (I'm not on netdev). From owner-netdev@oss.sgi.com Mon Sep 10 12:37:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AJbHY25388 for netdev-outgoing; Mon, 10 Sep 2001 12:37:17 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AJbEd25384 for ; Mon, 10 Sep 2001 12:37:14 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA00707; Mon, 10 Sep 2001 23:36:20 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200109101936.XAA00707@ms2.inr.ac.ru> Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 To: tao@acc.umu.se, matthias.andree@gmx.de Date: Mon, 10 Sep 2001 23:36:20 +0400 (MSK DST) Cc: alan@lxorguk.ukuu.org.uk, wietse@porcupine.org, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20010910100537.W26627@khan.acc.umu.se> from "David Weinehall" at Sep 10, 1 10:05:37 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 715 Lines: 21 Hello! > a bad idea after all. Whining about this causing "bloat and maintainance Listen, let's close this thread. :-) The patch sent by Matthias is enough small not to speak about some bloat. And I see no reasons to refuse this: it evidently improves the things almost without efforts. No matter that this imporvement is not so useful, as it would happen if I guessed this way from the very beginning. So that applications will have to worry about compatibility with older kernels in any case. (BTW Matthias, while applying it to my tree, I noticed that it does not check for SIOGGIFNETMASK. It would be better to do this only when it is meaningful: I see only SIOGGIFNETMASK and SIOGGIFBROADCAST). Alexey From owner-netdev@oss.sgi.com Mon Sep 10 13:39:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AKdlY26964 for netdev-outgoing; Mon, 10 Sep 2001 13:39:47 -0700 Received: from colin.muc.de (root@colin.muc.de [193.149.48.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AKdjd26960 for ; Mon, 10 Sep 2001 13:39:45 -0700 Received: by colin.muc.de id <140562-1>; Mon, 10 Sep 2001 22:40:09 +0200 Message-ID: <20010910224002.31693@colin.muc.de> Date: Mon, 10 Sep 2001 22:40:02 +0200 From: Andi Kleen To: kuznet@ms2.inr.ac.ru Cc: tao@acc.umu.se, matthias.andree@gmx.de, alan@lxorguk.ukuu.org.uk, wietse@porcupine.org, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 References: <20010910100537.W26627@khan.acc.umu.se> <200109101936.XAA00707@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <200109101936.XAA00707@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Mon, Sep 10, 2001 at 09:36:20PM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 532 Lines: 18 On Mon, Sep 10, 2001 at 09:36:20PM +0200, kuznet@ms2.inr.ac.ru wrote: > And I see no reasons to refuse this: it evidently improves the things > almost without efforts. Doubtful. > No matter that this imporvement is not so useful, > as it would happen if I guessed this way from the very beginning. That's a polite way to express it. > So that applications will have to worry about compatibility with older > kernels in any case. Just hope then that no ifconfig or other binary has a two on the stack when calling this. -Andi From owner-netdev@oss.sgi.com Mon Sep 10 13:44:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AKiN427245 for netdev-outgoing; Mon, 10 Sep 2001 13:44:23 -0700 Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AKiLd27242 for ; Mon, 10 Sep 2001 13:44:21 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8AKhDp17483 for ; Mon, 10 Sep 2001 16:43:13 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Mon, 10 Sep 2001 16:43:05 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S334TSNS; Mon, 10 Sep 2001 16:43:00 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RAA7LAHY; Mon, 10 Sep 2001 16:43:09 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 57FF83B9; Mon, 10 Sep 2001 16:42:44 -0400 (EDT) Message-ID: <3B9D25C4.A599D9E4@nortelnetworks.com> Date: Mon, 10 Sep 2001 16:42:44 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Christopher Friesen" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-custom i686) X-Accept-Language: en MIME-Version: 1.0 To: Padraig Brady Cc: netdev@oss.sgi.com Subject: Re: How to determine source ip address References: <3B9D1325.8030304@antefacto.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1291 Lines: 32 Padraig Brady wrote: > I'm writing a network app (currently on linux 2.2.18, > but soon moving to 2.4) that needs to build up ip & > tcp packets manually. So my question is how do I determine > the source ip address to use for a given destination > ip address. I.E. take account of multiple interfaces/routes/ > aliases/... How low in the protocol stack are you going? If you use an IP raw socket with IP_HDRINCL and just leave the sending address filled with zeros, then it will be filled in with the default address for the link used to send to the destination address. See the man page on raw(4) for more details. > If a port number is not allocated with the above connect(), > how do I manually allocate a source port, bind()? Yes, bind() works. Why do you care about source address? I would suspect that most of the time you want to either a) use the default, in which case you let the IP stack fill it in, or b) use some wierd source address, in which case you're usually better off using a config file or commandline parm. 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 Mon Sep 10 13:46:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AKkpk27375 for netdev-outgoing; Mon, 10 Sep 2001 13:46:51 -0700 Received: from emma1.emma.line.org (postfix@pD9E1EFE3.dip.t-dialin.net [217.225.239.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AKkkd27372 for ; Mon, 10 Sep 2001 13:46:46 -0700 Received: by emma1.emma.line.org (Postfix, from userid 500) id 708A5A2082; Mon, 10 Sep 2001 22:14:48 +0200 (CEST) Date: Mon, 10 Sep 2001 22:14:48 +0200 From: Matthias Andree To: kuznet@ms2.inr.ac.ru Cc: matthias.andree@gmx.de, alan@lxorguk.ukuu.org.uk, wietse@porcupine.org, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010910221448.E30149@emma1.emma.line.org> Mail-Followup-To: kuznet@ms2.inr.ac.ru, alan@lxorguk.ukuu.org.uk, wietse@porcupine.org, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20010910100537.W26627@khan.acc.umu.se> <200109101936.XAA00707@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200109101936.XAA00707@ms2.inr.ac.ru> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1824 Lines: 45 On Mon, 10 Sep 2001, kuznet@ms2.inr.ac.ru wrote: > (BTW Matthias, while applying it to my tree, I noticed that > it does not check for SIOGGIFNETMASK. It would be better to do this only > when it is meaningful: I see only SIOGGIFNETMASK and SIOGGIFBROADCAST). Thanks for reviewing it again. However, I think it should not be complicated. It's clear, simple and can easily be understood. Further reasons: 1/ It's not worth it. a/ If someone configures two IP addresses for a P2P-interface, something is wrong in a different part of the kernel, so SIOCGIFDSTADDR need not be exempt. b/ Treating SIOCGIFADDR the same way as SIOCGIFNETMASK has the advantage that kernels with 4.3BSD ioctl interface (Linux up to 2.2.19 and 2.4.9) will return the first address of the interface rather than the alias address passed in. This way, an application can check if the kernel's ioctl interface is really IP alias aware, by just matching the ifr it passed in against the one it got back after SIOCGIFADDR. I have actually sent a patch to Wietse Venema which lets Postfix warn about alias interface addresses that it cannot obtain the netmasks for and just skip them, so it does not treat something it does not know how to handle. 2/ The search-for-ifa code is unconditionally called upon entry to that function. If it depends on the ioctl, it will confuse all people that expect all SIOCGIF* ioctls to have the same search properties and hinder debugging of applications. Let's keep this as simple as possible. Performance is not an issue, ioctl is not read, you don't call it from tight inner loops. Let's not make it more error prone than it needs to be. -- Matthias Andree Outlook (Express) users: press Ctrl+F3 for the full source code of this post. begin dont_click_this_virus.exe end From owner-netdev@oss.sgi.com Mon Sep 10 14:41:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ALfnZ29053 for netdev-outgoing; Mon, 10 Sep 2001 14:41:49 -0700 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ALfkd29050 for ; Mon, 10 Sep 2001 14:41:46 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id RAA27057 for ; Mon, 10 Sep 2001 17:41:45 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f8ALgUG11468 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 10 Sep 2001 17:42:30 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f8ALfSx10110 for ; Mon, 10 Sep 2001 17:41:29 -0400 (EDT) Message-Id: <200109102141.f8ALfSx10110@marajade.sandelman.ottawa.on.ca> To: netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-reply-to: Your message of "Mon, 10 Sep 2001 10:05:37 +0200." <20010910100537.W26627@khan.acc.umu.se> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Sep 2001 17:41:28 -0400 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1114 Lines: 20 >>>>> "David" == David Weinehall writes: David> Are you saying that Linux should implement compability with _new_ David> features in FreeBSD 4.x, while at the same time frowning at the fact David> that Linux introduces a new API?! The mind boggles at the thought. I think that this ioctl is in all 4.4 derived systems, including Solaris. David> because there are probably more Linux-machines running the software than David> any BSD-machines, thus the netlink-code will get _more_ testing than David> the legacy API. Put a proper userspace API around netlink that abstracts the operations, write man pages so that we (application developers) know how to use it, and then *BSD can implement it to the ioctl interface and everyone will be happy. ] 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"); [ From owner-netdev@oss.sgi.com Mon Sep 10 14:45:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ALjG329287 for netdev-outgoing; Mon, 10 Sep 2001 14:45:16 -0700 Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ALjDd29283 for ; Mon, 10 Sep 2001 14:45:13 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA72534; Mon, 10 Sep 2001 17:42:54 -0400 Received: from d03nm035.boulder.ibm.com (d03nm035.boulder.ibm.com [9.99.140.35]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8ALj4868040; Mon, 10 Sep 2001 15:45:05 -0600 From: "David Stevens" Importance: Normal Subject: Re: source routing honored by hosts? [really: per-interface forwarding] To: Pekka Savola Cc: , , , X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: Date: Mon, 10 Sep 2001 14:45:04 -0700 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 03:45:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1758 Lines: 34 > (device-specific forwarding toggle might be a good thing too, but >separate issue to be discussed): BTW, I came across this bit from RFC2460: Note: it is possible, though unusual, for a device with multiple interfaces to be configured to forward non-self-destined packets arriving from some set (fewer than all) of its interfaces, and to discard non-self-destined packets arriving from its other interfaces. Such a device must obey the protocol requirements for routers when receiving packets from, and interacting with neighbors over, the former (forwarding) interfaces. It must obey the protocol requirements for hosts when receiving packets from, and interacting with neighbors over, the latter (non-forwarding) interfaces. I don't see any place for a global "forwarding" flag in this interpretation, except as a convenience for turning all interfaces on or off. The code (other than sysctl) I think ought to use per-interface flags. Whether a router is eligible to be a defaut router should be determined by a separate flag, "AdvSendAdvertisements" in RFC2461, if the concern was that a backwater router would become a default router for some hosts. I haven't looked at radvd to see if it supports that, but by my reading, having IsRouter true shouldn't by itself add a router to the default-router list for a host. I thought that was your concern, Alexy-- did I misunderstand your comments? It does say that IsRouter being cleared is reason to remove a router from the default-router list, but I think they should be added only based on router advertisements. So, having forwarding enabled alone wouldn't mean hosts would use the router as a default router. +-DLS From owner-netdev@oss.sgi.com Mon Sep 10 15:07:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AM7lZ29897 for netdev-outgoing; Mon, 10 Sep 2001 15:07:47 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AM7gd29893 for ; Mon, 10 Sep 2001 15:07:42 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f8AM7UK04774; Tue, 11 Sep 2001 01:07:30 +0300 Date: Tue, 11 Sep 2001 01:07:30 +0300 (EEST) From: Pekka Savola To: David Stevens cc: , Subject: Re: source routing honored by hosts? [really: per-interface forwarding] 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: 2828 Lines: 56 On Mon, 10 Sep 2001, David Stevens wrote: [snip Cc: list a bit] > > (device-specific forwarding toggle might be a good thing too, but > >separate issue to be discussed): > > BTW, I came across this bit from RFC2460: > > Note: it is possible, though unusual, for a device with multiple > interfaces to be configured to forward non-self-destined packets > arriving from some set (fewer than all) of its interfaces, and to > discard non-self-destined packets arriving from its other interfaces. > Such a device must obey the protocol requirements for routers when > receiving packets from, and interacting with neighbors over, the > former (forwarding) interfaces. It must obey the protocol > requirements for hosts when receiving packets from, and interacting > with neighbors over, the latter (non-forwarding) interfaces. > > I don't see any place for a global "forwarding" flag in this interpretation, > except as a convenience for turning all interfaces on or off. The code (other > than sysctl) I think ought to use per-interface flags. True; for simplicity, there are a few implementations who haven't done it this way though. (not that per-interface flags shouldn't be a goal). > Whether a router is eligible to be a defaut router should be determined by > a separate flag, "AdvSendAdvertisements" in RFC2461, if the concern was that > a backwater router would become a default router for some hosts. I haven't > looked at radvd to see if it supports that, but by my reading, having IsRouter > true shouldn't by itself add a router to the default-router list for a host. I > thought that was your concern, Alexy-- did I misunderstand your comments? > It does say that IsRouter being cleared is reason to remove a router > from the default-router list, but I think they should be added only based > on router advertisements. So, having forwarding enabled alone wouldn't mean > hosts would use the router as a default router. As noted in the draft (I'm sure you read it, but to summarize), IsRouter flag is basically used for Neighbour Unreachability Detection, for detecting when 1) a router goes down or 2) changes from router to host. The flag is also set in neighbour advertisements, which, even though radvd or similar would be run, would still be sent by the kernel (IIRC). As far as I can see, adding IsRouter flag isn't, in and of itself, currently harmful if you don't have "AdvSendAdvertisements" set (by radvd) -- so the scenario you describe shouldn't happen. The countrary, AdvSendAdvertisements without IsRouter, seems like a potentially very bad scenario though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Mon Sep 10 15:09:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AM9xm30003 for netdev-outgoing; Mon, 10 Sep 2001 15:09:59 -0700 Received: from colin.muc.de (root@colin.muc.de [193.149.48.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AM9vd30000 for ; Mon, 10 Sep 2001 15:09:57 -0700 Received: by colin.muc.de id <140570-1>; Tue, 11 Sep 2001 00:10:24 +0200 Message-ID: <20010911001022.12845@colin.muc.de> Date: Tue, 11 Sep 2001 00:10:22 +0200 From: Andi Kleen To: Michael Richardson Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 References: <20010910100537.W26627@khan.acc.umu.se> <200109102141.f8ALfSx10110@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <200109102141.f8ALfSx10110@marajade.sandelman.ottawa.on.ca>; from Michael Richardson on Mon, Sep 10, 2001 at 11:41:28PM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 721 Lines: 16 On Mon, Sep 10, 2001 at 11:41:28PM +0200, Michael Richardson wrote: > Put a proper userspace API around netlink that abstracts the operations, > write man pages so that we (application developers) know how to use it, and > then *BSD can implement it to the ioctl interface and everyone will be happy. There is libnetlink which helps a lot. It is part of iproute2. I actually wrote man pages for it some time ago and submitted them, but they never appeared for some reason with iproute2. You can get them from the SuSE libnetlink.rpm though. There are also man pages for netlink/rtnetlink in the standard linux manpages (which are admittedly not very good, but they at least exist and they are not that bad) -Andi From owner-netdev@oss.sgi.com Mon Sep 10 15:29:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AMTYZ30552 for netdev-outgoing; Mon, 10 Sep 2001 15:29:34 -0700 Received: from comunit.de (comunit.de [195.21.213.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AMTUd30546 for ; Mon, 10 Sep 2001 15:29:30 -0700 Received: (qmail 21664 invoked by uid 517); 10 Sep 2001 22:22:47 -0000 Date: Tue, 11 Sep 2001 00:22:47 +0200 (CEST) From: Sven Koch X-X-Sender: To: Andi Kleen cc: Michael Richardson , Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-Reply-To: <20010911001022.12845@colin.muc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1534 Lines: 36 On Tue, 11 Sep 2001, Andi Kleen wrote: > On Mon, Sep 10, 2001 at 11:41:28PM +0200, Michael Richardson wrote: > > Put a proper userspace API around netlink that abstracts the operations, > > write man pages so that we (application developers) know how to use it, and > > then *BSD can implement it to the ioctl interface and everyone will be happy. > > There is libnetlink which helps a lot. It is part of iproute2. > I actually wrote man pages for it some time ago and submitted them, > but they never appeared for some reason with > iproute2. You can get them from the SuSE libnetlink.rpm though. > There are also man pages for netlink/rtnetlink in the standard linux > manpages (which are admittedly not very good, but they at least exist and > they are not that bad) One thing raises a question in this thread: There is the (somewhat broken) SIOCGIFNETMASK, and then there is the netlink interface. Netlink is only available if I compile advanced-router into my kernel (/sbin/ip does only work when I do that). SIOCGIFNETMASK works for the normal (ifconfig) alias interfaces, but not for the one's added via ip. So do I get it right that application-developer, who want to know the netmask for the interfaces (for whatever reason), need to implement two different interfaces in their programs to work with every current kernel? (Use netlink if its available, SIOCGIFNETMASK otherwise?) c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) From owner-netdev@oss.sgi.com Tue Sep 11 03:41:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BAfi013728 for netdev-outgoing; Tue, 11 Sep 2001 03:41:44 -0700 Received: from emma1.emma.line.org (postfix@pD9E1E6FC.dip.t-dialin.net [217.225.230.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BAfed13724 for ; Tue, 11 Sep 2001 03:41:40 -0700 Received: by emma1.emma.line.org (Postfix, from userid 500) id AE74DA2021; Mon, 10 Sep 2001 23:19:11 +0200 (CEST) Date: Mon, 10 Sep 2001 23:19:11 +0200 From: Matthias Andree To: Andi Kleen Cc: kuznet@ms2.inr.ac.ru, tao@acc.umu.se, matthias.andree@gmx.de, alan@lxorguk.ukuu.org.uk, wietse@porcupine.org, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010910231911.I30149@emma1.emma.line.org> Mail-Followup-To: Andi Kleen , kuznet@ms2.inr.ac.ru, tao@acc.umu.se, alan@lxorguk.ukuu.org.uk, wietse@porcupine.org, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20010910100537.W26627@khan.acc.umu.se> <200109101936.XAA00707@ms2.inr.ac.ru> <20010910224002.31693@colin.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20010910224002.31693@colin.muc.de> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1061 Lines: 26 Andi Kleen schrieb am Montag, den 10. September 2001: > > So that applications will have to worry about compatibility with older > > kernels in any case. > > Just hope then that no ifconfig or other binary has a two on the stack > when calling this. Thanks for asking, however, nothing bad will happen if there are no 4.4BSD-style aliases. If there are, you have no business using ifconfig anyways, and ifconfig certainly has not configured the aliases (it overwrites the primary address unless you use a separate name such as eth0:0). Actually, in net-tools-1.56, ifconfig does write AF_INET onto its ifr (it gets shot otherwise), without clearing the address field (which contains the txqueuelen result). However, the worst thing that can happen is that ifconfig displays one of the aliases - but the alias would match the txqueuelen then. How many people have 0.0.0.* or *.0.0.0 addresses configured as alias? Not too many. None, to be precise. It will not bite portable applications either since those init their address properly. -- Matthias Andree From owner-netdev@oss.sgi.com Tue Sep 11 06:34:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BDYTG16854 for netdev-outgoing; Tue, 11 Sep 2001 06:34:29 -0700 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BDYNd16851 for ; Tue, 11 Sep 2001 06:34:23 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id f8B1hEb02577; Tue, 11 Sep 2001 01:43:34 GMT Date: Tue, 11 Sep 2001 01:43:14 +0000 (GMT) From: Julian Anastasov X-X-Sender: To: Christopher Friesen cc: Padraig Brady , Subject: Re: How to determine source ip address In-Reply-To: <3B9D25C4.A599D9E4@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: 2340 Lines: 51 Hello, On Mon, 10 Sep 2001, Christopher Friesen wrote: > Padraig Brady wrote: > > > I'm writing a network app (currently on linux 2.2.18, > > but soon moving to 2.4) that needs to build up ip & > > tcp packets manually. So my question is how do I determine > > the source ip address to use for a given destination > > ip address. I.E. take account of multiple interfaces/routes/ > > aliases/... > > How low in the protocol stack are you going? If you use an IP raw socket with > IP_HDRINCL and just leave the sending address filled with zeros, then it will be > filled in with the default address for the link used to send to the destination > address. See the man page on raw(4) for more details. Looking in udp_sendmsg and raw_sendmsg() I don't see the saddr argument in the route lookup call to depend on the IP_HDRINCL option (which is an raw socket option only). The same mistake (as your assumption) you can see in the (latest?) traceroute-1.4a12 where bind() is surrounded in #ifndef IP_HDRINCL. As result bind() is not called and the packets go to wrong route. As for the question from Padraig: you have to create SOCK_DGRAM socket, then to connect() it to the target address (any port), then to get the generated source address from the kernel by calling getsockname(). Now you have the source that the kernel usually uses to talk with the specified target. Then you have to create the actual data socket and to call bind() for the source address from the previous step and then to connect()/sendto() to the newly created socket. Without bind() your data will not be routed considering the source address in the IP header. Such routing problem is usually noticed when you have two or more routes to the universe. If you send with different source addresses from one socket then the handling will be more complex. May be then you have to play with IP_PKTINFO. My man page is incorrect here, it claims that ipi_spec_dst contains the destination address but raw_sendmsg uses it as source address. The oif value is correctly used. The only problem may be is that IP_PKTINFO should be called before sending each packet. So, may be there is no way to specify different source address (for the routing call) in sendmsg(). You have to change it with IP_PKTINFO call each time. > Chris Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Tue Sep 11 08:23:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BFNKp18767 for netdev-outgoing; Tue, 11 Sep 2001 08:23:20 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BFNId18764 for ; Tue, 11 Sep 2001 08:23:18 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA16406; Tue, 11 Sep 2001 19:22:58 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200109111522.TAA16406@ms2.inr.ac.ru> Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 To: matthias.andree@stud.uni-dortmund.de (Matthias Andree) Date: Tue, 11 Sep 2001 19:22:57 +0400 (MSK DST) Cc: matthias.andree@gmx.de, alan@lxorguk.ukuu.org.uk, wietse@porcupine.org, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20010910221448.E30149@emma1.emma.line.org> from "Matthias Andree" at Sep 10, 1 10:14:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 382 Lines: 12 Hello! > Let's keep this as simple as possible. A. No way to do the trick with SIOCSIF*. B. The things does not become simpler when code does something random. The things become simpler when code checks something explicitly, otherwise you have to add comment: "Well, here we do this against plain logic, but this does not matter because of this, this and this." Alexey From owner-netdev@oss.sgi.com Tue Sep 11 08:34:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BFYms18948 for netdev-outgoing; Tue, 11 Sep 2001 08:34:48 -0700 Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BFYkd18945 for ; Tue, 11 Sep 2001 08:34:46 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8BFYCp11939 for ; Tue, 11 Sep 2001 11:34:12 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 11 Sep 2001 11:34:31 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S334V9TR; Tue, 11 Sep 2001 11:27:46 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RAA7LBF8; Tue, 11 Sep 2001 11:27:52 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 4E20E4EE; Tue, 11 Sep 2001 11:27:47 -0400 (EDT) Message-ID: <3B9E2D73.DF3EF58E@nortelnetworks.com> Date: Tue, 11 Sep 2001 11:27:47 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Christopher Friesen" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-custom i686) X-Accept-Language: en MIME-Version: 1.0 To: Sven Koch Cc: Michael Richardson , netdev Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 967 Lines: 22 Sven Koch wrote: > So do I get it right that application-developer, who want to know the > netmask for the interfaces (for whatever reason), need to implement two > different interfaces in their programs to work with every current kernel? > (Use netlink if its available, SIOCGIFNETMASK otherwise?) Essentially, yes. If the addresses are configured using ifconfig, then the ioctl stuff will work. If the addresses are configured using ip (ie netlink) then the ioctl stuff is not sufficient and the netlink stuff must be used. Basically netlink offers a superset of the functionality of the ioctl interface, so if you set it up with netlink and then read it with ioctl it may not work (but the other way around will). -- 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 Tue Sep 11 09:39:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BGdWZ20085 for netdev-outgoing; Tue, 11 Sep 2001 09:39:32 -0700 Received: from emma1.emma.line.org (postfix@pD9E1E6FC.dip.t-dialin.net [217.225.230.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BGdUd20082 for ; Tue, 11 Sep 2001 09:39:30 -0700 Received: by emma1.emma.line.org (Postfix, from userid 500) id 33D5CA201F; Tue, 11 Sep 2001 18:39:28 +0200 (CEST) Date: Tue, 11 Sep 2001 18:39:28 +0200 From: Matthias Andree To: kuznet@ms2.inr.ac.ru Cc: matthias.andree@gmx.de, alan@lxorguk.ukuu.org.uk, wietse@porcupine.org, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 Message-ID: <20010911183928.A7711@emma1.emma.line.org> Mail-Followup-To: kuznet@ms2.inr.ac.ru, alan@lxorguk.ukuu.org.uk, wietse@porcupine.org, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20010910221448.E30149@emma1.emma.line.org> <200109111522.TAA16406@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200109111522.TAA16406@ms2.inr.ac.ru> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 974 Lines: 25 On Tue, 11 Sep 2001, kuznet@ms2.inr.ac.ru wrote: > A. No way to do the trick with SIOCSIF*. Well, ioctl cannot configure IP aliases, however. Indeed, it may be useful to change the patch to not touch the SIOCS* functions and document that it only accesses the first one. > B. The things does not become simpler when code does something random. > The things become simpler when code checks something explicitly, > otherwise you have to add comment: "Well, here we do this against > plain logic, but this does not matter because of this, this and this." That's true, but I would not want to make SIOCGIFADDR behave differently than SIOCGIFNETMASK, in that case, I'd rather have SIOCGIFCONF just return the first address per interface name. I will prepare a new patch as my time permits (unless, of course, someone is faster). -- Matthias Andree Outlook (Express) users: press Ctrl+F3 for the full source code of this post. begin dont_click_this_virus.exe end From owner-netdev@oss.sgi.com Tue Sep 11 10:51:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BHpgh21362 for netdev-outgoing; Tue, 11 Sep 2001 10:51:42 -0700 Received: from eventhorizon.antefacto.net (eventhorizon.antefacto.net [193.120.245.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BHpad21359 for ; Tue, 11 Sep 2001 10:51:36 -0700 Received: from antefacto.com (pixelbeat.internal.antefacto.com [172.24.1.107]) by eventhorizon.antefacto.net (8.11.0/8.11.0) with ESMTP id f8BHpEu25393; Tue, 11 Sep 2001 18:51:16 +0100 Message-ID: <3B9E4E1B.9060006@antefacto.com> Date: Tue, 11 Sep 2001 18:47:07 +0100 From: Padraig Brady User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en-us MIME-Version: 1.0 To: Julian Anastasov CC: Christopher Friesen , netdev@oss.sgi.com Subject: Re: How to determine source ip address References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3201 Lines: 77 Julian Anastasov wrote: > Hello, > >On Mon, 10 Sep 2001, Christopher Friesen wrote: > >>Padraig Brady wrote: >> >>>I'm writing a network app (currently on linux 2.2.18, >>>but soon moving to 2.4) that needs to build up ip & >>>tcp packets manually. So my question is how do I determine >>>the source ip address to use for a given destination >>>ip address. I.E. take account of multiple interfaces/routes/ >>>aliases/... >>> >>How low in the protocol stack are you going? If you use an IP raw socket with >>IP_HDRINCL and just leave the sending address filled with zeros, then it will be >>filled in with the default address for the link used to send to the destination >>address. See the man page on raw(4) for more details. >> Chris, I'm only filling in the TCP header, and I realise the IP header will be filled appropriately when sent. However I need to calculate the checksum for the TCP header which is actually calculated for the pseudo header: struct pseudo_header { unsigned int src_address; /* <==-- */ unsigned int dest_address; unsigned char placeholder; unsigned char protocol; unsigned short tcp_length; struct tcphdr tcp; } pseudo_header; So I need to determine the source address before sending... > > Looking in udp_sendmsg and raw_sendmsg() I don't see the >saddr argument in the route lookup call to depend on the IP_HDRINCL >option (which is an raw socket option only). The same mistake (as your >assumption) you can see in the (latest?) traceroute-1.4a12 where bind() >is surrounded in #ifndef IP_HDRINCL. As result bind() is not called and >the packets go to wrong route. > > As for the question from Padraig: you have to create SOCK_DGRAM >socket, then to connect() it to the target address (any port), then to >get the generated source address from the kernel by calling getsockname(). >Now you have the source that the kernel usually uses to talk with the >specified target. > Cool. I was unsure that would work, and forgot about getsockname(). Thanks! > Then you have to create the actual data socket and to >call bind() for the source address from the previous step and then to >connect()/sendto() to the newly created socket. Without bind() your >data will not be routed considering the source address in the IP >header. Such routing problem is usually noticed when you have two or more >routes to the universe. If you send with different source addresses >from one socket then the handling will be more complex. May be then you >have to play with IP_PKTINFO. My man page is incorrect here, it claims that >ipi_spec_dst contains the destination address but raw_sendmsg uses it as >source address. The oif value is correctly used. The only problem may be >is that IP_PKTINFO should be called before sending each packet. So, may be >there is no way to specify different source address (for the routing call) >in sendmsg(). You have to change it with IP_PKTINFO call each time. > I don't have to worry about source routing, but thanks for the info. I don't think I have to call connect() so, do I? I'm still unsure how to get a source port that will never clash with existing connections, but that's not a major problem. Thanks, Padraig. From owner-netdev@oss.sgi.com Tue Sep 11 12:32:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BJWJn22926 for netdev-outgoing; Tue, 11 Sep 2001 12:32:19 -0700 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BJW9d22923 for ; Tue, 11 Sep 2001 12:32:11 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id f8BMWjR17795; Tue, 11 Sep 2001 22:32:45 GMT Date: Tue, 11 Sep 2001 22:32:45 +0000 (GMT) From: Julian Anastasov X-X-Sender: To: Padraig Brady cc: Christopher Friesen , Subject: Re: How to determine source ip address In-Reply-To: <3B9E4E1B.9060006@antefacto.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 999 Lines: 38 Hello, On Tue, 11 Sep 2001, Padraig Brady wrote: > Chris, I'm only filling in the TCP header, and I realise the IP header > will be > filled appropriately when sent. However I need to calculate the checksum for > the TCP header which is actually calculated for the pseudo header: The checksum is calculated for you in raw_getrawfrag() > So I need to determine the source address before sending... getsockname() gives it to you after connect() to the DGRAM socket. > I don't have to worry about source routing, but thanks for the info. I > don't think > I have to call connect() so, do I? You have to, if you need the source address > I'm still unsure how to get a source port that will never clash with > existing connections, but that's not a major problem. Hm, then you have to create a normal TCP socket and to receive port with bind(). I don't know your goals, so you have to take into account everything you know. > Thanks, > Padraig. Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Tue Sep 11 13:44:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BKilu24422 for netdev-outgoing; Tue, 11 Sep 2001 13:44:47 -0700 Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BKiid24419 for ; Tue, 11 Sep 2001 13:44:44 -0700 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8BKiAp16562 for ; Tue, 11 Sep 2001 16:44:10 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 11 Sep 2001 16:44:13 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S334XFZT; Tue, 11 Sep 2001 16:44:09 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RAA7LB0M; Tue, 11 Sep 2001 16:44:19 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 22F804EE; Tue, 11 Sep 2001 16:44:18 -0400 (EDT) Message-ID: <3B9E77A1.B4F75F11@nortelnetworks.com> Date: Tue, 11 Sep 2001 16:44:17 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Christopher Friesen" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-custom i686) X-Accept-Language: en MIME-Version: 1.0 To: Gigi Sullivan Cc: Padraig Brady , Julian Anastasov , netdev@oss.sgi.com Subject: Re: How to determine source ip address References: <3B9E4E1B.9060006@antefacto.com> <20010911215036.B205@armageddon.tin.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 956 Lines: 25 Gigi Sullivan wrote: > So, what you have to do is just this; > look at destination IP address, use the kernel routing table to > get the outgoing interface, retrieve the IP address associated with > it. Minor problem with this: what if you're routing based on source addresses? If the outgoing address that you pick influences which route/interface you use, this won't work. By far the simplest method is to either a) use the default outgoing route to that destination and let the kernel fill it in, or b) have the admin specify a source address via a config file or commandline parm. Anything else is guesswork and likely a pathological case can be invented for which it will be wrong. 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 Sep 12 02:45:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8C9jMd04012 for netdev-outgoing; Wed, 12 Sep 2001 02:45:22 -0700 Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8C9jGe04009 for ; Wed, 12 Sep 2001 02:45:16 -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 MAA03287; Wed, 12 Sep 2001 12:46:57 +0300 Date: Wed, 12 Sep 2001 12:46:57 +0300 (EEST) From: Julian Anastasov X-X-Sender: To: cc: "David S. Miller" Subject: Incorrect sch_ingress registration to NF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1159 Lines: 52 Hello, The diffserv guys know about this bug for already more than 2 months. What is going on, guys? I'm appending a modified version of the patch posted to diffserv list on June 24, from Doron Oz. It is against 2.4. In short, the ingress support should not register itself twice to netfilter. Regards -- Julian Anastasov --- linux/net/sched/sch_ingress.c.orig Fri Aug 18 20:26:25 2000 +++ linux/net/sched/sch_ingress.c Tue Sep 11 19:39:47 2001 @@ -42,7 +42,9 @@ #define PRIV(sch) ((struct ingress_qdisc_data *) (sch)->data) - +#ifndef MODULE +static int nf_registered = 0; +#endif struct ingress_qdisc_data { struct Qdisc *q; @@ -241,10 +243,11 @@ p->filter_list = NULL; p->q = &noop_qdisc; #ifndef MODULE - if (nf_register_hook(&ing_ops) < 0) { + if (!nf_registered && nf_register_hook(&ing_ops) < 0) { printk("Unable to register ingress \n"); goto error; } + nf_registered ++; #endif DPRINTK("ingress_init: qdisc %p\n", sch); MOD_INC_USE_COUNT; @@ -297,7 +300,8 @@ #endif #ifndef MODULE - nf_unregister_hook(&ing_ops); + if (!--nf_registered) + nf_unregister_hook(&ing_ops); #endif MOD_DEC_USE_COUNT; From owner-netdev@oss.sgi.com Wed Sep 12 02:47:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8C9lPh04112 for netdev-outgoing; Wed, 12 Sep 2001 02:47:25 -0700 Received: from fep29-svc.tin.it (mta29-acc.tin.it [212.216.176.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8C9lKe04109 for ; Wed, 12 Sep 2001 02:47:20 -0700 Received: from armageddon.allanon.org ([212.216.28.43]) by fep19-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with ESMTP id <20010911203015.YOON14026.fep19-svc.tin.it@armageddon.allanon.org>; Tue, 11 Sep 2001 22:30:15 +0200 Received: by armageddon.allanon.org (Postfix, from userid 0) id 0E5D26050; Tue, 11 Sep 2001 21:50:36 +0200 (CEST) Date: Tue, 11 Sep 2001 21:50:36 +0200 From: Gigi Sullivan To: Padraig Brady Cc: Julian Anastasov , Christopher Friesen , netdev@oss.sgi.com Subject: Re: How to determine source ip address Message-ID: <20010911215036.B205@armageddon.tin.it> References: <3B9E4E1B.9060006@antefacto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B9E4E1B.9060006@antefacto.com>; from padraig@antefacto.com on Tue, Sep 11, 2001 at 06:47:07PM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1896 Lines: 58 Aiee :) Hello! On Tue, Sep 11, 2001 at 06:47:07PM +0100, Padraig Brady wrote: > >>Padraig Brady wrote: > >> > >>>I'm writing a network app (currently on linux 2.2.18, > >>>but soon moving to 2.4) that needs to build up ip & > >>>tcp packets manually. So my question is how do I determine > >>>the source ip address to use for a given destination > >>>ip address. I.E. take account of multiple interfaces/routes/ > >>>aliases/... > >>> > Chris, I'm only filling in the TCP header, and I realise the IP header > will be > filled appropriately when sent. However I need to calculate the checksum for > the TCP header which is actually calculated for the pseudo header: > > struct pseudo_header { > unsigned int src_address; /* <==-- */ > unsigned int dest_address; > unsigned char placeholder; > unsigned char protocol; > unsigned short tcp_length; > struct tcphdr tcp; > } pseudo_header; > > So I need to determine the source address before sending... When sending IP datagram, source IP address is choosen by the kernel just picking up the one bound to the outgoing interface (actually I never thought about this could work when multiple addresses are assigned to one interface). So, what you have to do is just this; look at destination IP address, use the kernel routing table to get the outgoing interface, retrieve the IP address associated with it. You can achieve all this just using AF_NETLINK socket(2) or by playing with /proc/net/route and doing a few ioctl(2) calls (SIOCGIFADDR)) If I misenderstood something, I apologize; point me out to the beginning thread then, thanks! :) > Thanks, > Padraig. bye bye -- gg sullivan -- Lorenzo Cavallaro `Gigi Sullivan' Until I loved, life had no beauty; I did not know I lived until I had loved. (Theodor Korner) From owner-netdev@oss.sgi.com Wed Sep 12 04:10:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CBAob06010 for netdev-outgoing; Wed, 12 Sep 2001 04:10:50 -0700 Received: from eventhorizon.antefacto.net (eventhorizon.antefacto.net [193.120.245.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CBAke06007 for ; Wed, 12 Sep 2001 04:10:46 -0700 Received: from antefacto.com (pixelbeat.internal.antefacto.com [172.24.1.107]) by eventhorizon.antefacto.net (8.11.0/8.11.0) with ESMTP id f8CBAMu26619; Wed, 12 Sep 2001 12:10:22 +0100 Message-ID: <3B9F41A4.5070706@antefacto.com> Date: Wed, 12 Sep 2001 12:06:12 +0100 From: Padraig Brady User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en-us MIME-Version: 1.0 To: Julian Anastasov CC: Christopher Friesen , netdev@oss.sgi.com Subject: Re: How to determine source ip address References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1303 Lines: 50 Julian Anastasov wrote: > Hello, > >On Tue, 11 Sep 2001, Padraig Brady wrote: > >>Chris, I'm only filling in the TCP header, and I realise the IP header >>will be >>filled appropriately when sent. However I need to calculate the checksum for >>the TCP header which is actually calculated for the pseudo header: >> > > The checksum is calculated for you in raw_getrawfrag() > For IP not *TCP*. I must do this myself I think, but it's fine, I can do this easily. > >>So I need to determine the source address before sending... >> > > getsockname() gives it to you after connect() to the >DGRAM socket. > >>I don't have to worry about source routing, but thanks for the info. I >>don't think >>I have to call connect() so, do I? >> > > You have to, if you need the source address > Great I don't have to do it so. > >>I'm still unsure how to get a source port that will never clash with >>existing connections, but that's not a major problem. >> > > Hm, then you have to create a normal TCP socket and to >receive port with bind(). I don't know your goals, so you have to >take into account everything you know. > Basically I'm building a TCP header and need to use a local port number that wont clash with anything. I'll just use rand() for the moment, if there is nothing better? thanks, Padraig. From owner-netdev@oss.sgi.com Sun Sep 16 16:07:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8GN7Dq20742 for netdev-outgoing; Sun, 16 Sep 2001 16:07:13 -0700 Received: from emma1.emma.line.org (postfix@pD9E1E5CF.dip.t-dialin.net [217.225.229.207]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8GN5Ae20725 for ; Sun, 16 Sep 2001 16:05:11 -0700 Received: by emma1.emma.line.org (Postfix, from userid 500) id C0E5EA201F; Mon, 17 Sep 2001 01:05:07 +0200 (CEST) Date: Mon, 17 Sep 2001 01:05:07 +0200 From: Matthias Andree To: Linux-Kernel mailing list Cc: Alan Cox , Linus Torvalds , Alexey Kuznetsov , Wietse Venema , netdev@oss.sgi.com, "David S. Miller" Subject: 2.4.9 SIOCGIF* BSD4.4 compatibility patch, take #2 (restricted impact) Message-ID: <20010917010507.A17850@emma1.emma.line.org> Mail-Followup-To: Linux-Kernel mailing list , Alan Cox , Linus Torvalds , Alexey Kuznetsov , Wietse Venema , netdev@oss.sgi.com, "David S. Miller" Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3974 Lines: 120 This is the second edition of my SIOCGIF* compatibility patch, against Linux 2.4.9. In contrast to the first edition, it only does the "search passed-in address" logic for SIOCGIFADDR, DSTADDR, BRDADDR and NETMASK ioctls as suggested by Alexey Kuznetsov. It keeps the "only do this if we got AF_INET" property. This patch allows the aforementioned ioctls to return the proper values for an interface that has multiple addresses with the same label, as configured by: ip addr 192.168.0.1/24 dev eth0 ip addr 172.16.15.14/16 dev eth0 Note that SIOCGIFCONF returns all these IP aliases, which confuses applications that feed the data obtained from SIOCGIFCONF back into SIOCGIFNETMASK, but do not validate the address via SIOCGIFADDR. 4.4BSD applications pass in the interface address alongside the interface name to select the alias. Remember, this patch falls back to interface-only match (return the "primary" address) if at least one of these conditions is true: - the address family is not AF_INET - no interface alias has the address passed in Linus, Alan, please apply. Alexey, David, Netdev list subscribers, this is for your reference. Feel free to comment. Wietse, this supersedes the first patch I sent which you may want to put in the contrib section somewhere. --- linux-2.4.9-f/net/ipv4/devinet.c.orig Wed May 16 19:21:45 2001 +++ linux-2.4.9-f/net/ipv4/devinet.c Mon Sep 17 00:39:41 2001 @@ -20,6 +20,10 @@ * Changes: * Alexey Kuznetsov: pa_* fields are replaced with ifaddr lists. * Cyrus Durgin: updated for kmod + * Matthias Andree: in devinet_ioctl, compare label and + * address (4.4BSD alias style support), + * fall back to comparing just the label + * if no match found. */ #include @@ -463,6 +467,7 @@ int devinet_ioctl(unsigned int cmd, void *arg) { struct ifreq ifr; + struct sockaddr_in sin_orig; struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr; struct in_device *in_dev; struct in_ifaddr **ifap = NULL; @@ -470,6 +475,7 @@ struct net_device *dev; char *colon; int ret = 0; + int tryaddrmatch = 0; /* * Fetch the caller's info block into kernel space @@ -479,6 +485,9 @@ return -EFAULT; ifr.ifr_name[IFNAMSIZ-1] = 0; + /* save original address for comparison */ + memcpy(&sin_orig, sin, sizeof(*sin)); + colon = strchr(ifr.ifr_name, ':'); if (colon) *colon = 0; @@ -496,6 +505,7 @@ so that we do not impose a lock. One day we will be forced to put shlock here (I mean SMP) */ + tryaddrmatch = (sin_orig.sin_family == AF_INET); memset(sin, 0, sizeof(*sin)); sin->sin_family = AF_INET; break; @@ -529,9 +539,29 @@ *colon = ':'; if ((in_dev=__in_dev_get(dev)) != NULL) { - for (ifap=&in_dev->ifa_list; (ifa=*ifap) != NULL; ifap=&ifa->ifa_next) - if (strcmp(ifr.ifr_name, ifa->ifa_label) == 0) - break; + if (tryaddrmatch) { + /* Matthias Andree */ + /* compare label and address (4.4BSD style) */ + /* note: we only do this for a limited set of ioctls + and only if the original address family was AF_INET. + This is checked above. */ + for (ifap=&in_dev->ifa_list; (ifa=*ifap) != NULL; ifap=&ifa->ifa_next) { + if ((strcmp(ifr.ifr_name, ifa->ifa_label) == 0) + && (sin_orig.sin_addr.s_addr == ifa->ifa_address)) { + break; /* found */ + } /* if */ + } /* for */ + } else { /* tryaddrmatch */ + ifa = NULL; + } /* if (tryaddrmatch) */ + /* we didn't get a match, maybe the application is + 4.3BSD-style and passed in junk so we fall back to + comparing just the label */ + if (ifa == NULL) { + for (ifap=&in_dev->ifa_list; (ifa=*ifap) != NULL; ifap=&ifa->ifa_next) + if (strcmp(ifr.ifr_name, ifa->ifa_label) == 0) + break; + } } if (ifa == NULL && cmd != SIOCSIFADDR && cmd != SIOCSIFFLAGS) { -- Matthias Andree "Those who give up essential liberties for temporary safety deserve neither liberty nor safety." - Benjamin Franklin From owner-netdev@oss.sgi.com Sun Sep 16 21:39:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8H4dXT25754 for netdev-outgoing; Sun, 16 Sep 2001 21:39:33 -0700 Received: from squeaker.ratbox.org (postfix@squeaker.ratbox.org [63.216.218.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8H4dUe25751 for ; Sun, 16 Sep 2001 21:39:30 -0700 Received: by squeaker.ratbox.org (Postfix, from userid 500) id D435312CAA; Mon, 17 Sep 2001 00:39:28 -0400 (EDT) Date: Mon, 17 Sep 2001 00:39:28 -0400 (EDT) From: Aaron Sethman To: Matti Aarnio Cc: Wietse Venema , , Subject: Re: [PATCH] ioctl SIOCGIFNETMASK: ip alias bug 2.4.9 and 2.2.19 In-Reply-To: <20010910170241.Q11046@mea-ext.zmailer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 538 Lines: 21 On Mon, 10 Sep 2001, Matti Aarnio wrote: > Knowledge about IP addresses I do - sort of - understand, but why > netmask ? I think it has to do with Postfix defaulting the mynetwork setting. Without a netmask for what the user allows relaying from it goes with the netmask of the interface. Aaron > > > Wietse > > /Matti Aarnio > - > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > From owner-netdev@oss.sgi.com Sun Sep 16 22:30:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8H5U6Q26641 for netdev-outgoing; Sun, 16 Sep 2001 22:30:06 -0700 Received: from weta.f00f.org (weta.f00f.org [203.167.249.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8H5U4e26636 for ; Sun, 16 Sep 2001 22:30:04 -0700 Received: by weta.f00f.org (Postfix, from userid 1000) id 702731681C; Mon, 17 Sep 2001 17:30:13 +1200 (NZST) Date: Mon, 17 Sep 2001 17:30:13 +1200 From: Chris Wedgwood To: netdev@oss.sgi.com Subject: [slightly OT] tcp resets in response to ICMP messages --- required behavior? Message-ID: <20010917173013.A3031@weta.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i X-No-Archive: Yes Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 478 Lines: 12 Somewhat off topic.. but can anyone tell me definitively what a TCP implementation should do when it receives and ICMP unreachable (net or host) during a TCP session (i.e. in response to an ACK or PSH)? rfc1122 seems to indicate all such message are to be treated as transient errors and hence should be ignored --- but it seems some stacks, (e.g. Windows98) reset the connection as if a TCP packet with RST was received. Needless to say, this sucks rocks terribly. --cw From owner-netdev@oss.sgi.com Mon Sep 17 15:33:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8HMX2A14877 for netdev-outgoing; Mon, 17 Sep 2001 15:33:02 -0700 Received: from web11501.mail.yahoo.com (web11501.mail.yahoo.com [216.136.172.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8HMX0e14874 for ; Mon, 17 Sep 2001 15:33:00 -0700 Message-ID: <20010917223259.71870.qmail@web11501.mail.yahoo.com> Received: from [134.22.47.55] by web11501.mail.yahoo.com via HTTP; Mon, 17 Sep 2001 15:32:59 PDT Date: Mon, 17 Sep 2001 15:32:59 -0700 (PDT) From: Guilhem Tardy Subject: skbuff variables set already in ethernet drivers 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: 828 Lines: 22 Hello, I tried to modify the 3c59x.c driver some time ago, unsuccessfully. I now want to get around those difficulties, could you help? My goal is to add an unsigned long value in all UDP packets received on a particular port. This value represents the current time from a custom rtc timer (8192Hz). I also modified ip_input.c and udp.c for the same purpose. Obviously, I had to turn off the checksum in 3c59x.c and udp.c. The problem is that I don't know where skbuff.{data, mac.ethernet} point to in 3c59x.c (or any driver, for what it matters)? As a result, the value is probably copied in the wrong place. Thanks, Guilhem. __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From owner-netdev@oss.sgi.com Mon Sep 17 15:41:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8HMfaO15084 for netdev-outgoing; Mon, 17 Sep 2001 15:41:36 -0700 Received: from ezri.xs4all.nl (ezri.xs4all.nl [194.109.253.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8HMfUe15066 for ; Mon, 17 Sep 2001 15:41:30 -0700 Received: (qmail 8778 invoked from network); 17 Sep 2001 22:41:19 -0000 Received: from ally.lammerts.org (10.90.0.1) by ally.lammerts.org with SMTP; 17 Sep 2001 22:41:19 -0000 Date: Tue, 18 Sep 2001 00:41:19 +0200 (CEST) From: Eric Lammerts To: David Acklam cc: , Subject: Re: compiled-in (non-modular) USB initialization bug 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: 2240 Lines: 68 On Mon, 17 Sep 2001, David Acklam wrote: > A few months ago I posted a bug report about the Pegasus driver not > initializing (or not initializing fast enough to work with NFS-Root) when > compiled-in. I've found that this is not specific to the > pegasus, as I have recently noticed that the kernel 'driver-initialized' > messages for my USB mouse and keyboard (i.e. HID devices) come up AFTER > init has been started. These drivers are also 'compiled-in' > > The problem this poses is that some applications (like NFSRoot) need > access to USB devices BEFORE the kernel mounts filesystems/starts init. I had the same problem a while ago. I haven't really looked into the usb code, but it appears USB devices are detected from a kernel thread, i.e., asynchronously. When the USB thread has discovered the device, the dhcp/bootp code has already failed. The following patch adds the "ip=wait" option. It makes ipconfig.c retry forever until is has found a suitable device to do dhcp/bootp/rarp. This is untested! (I don't have a USB netdevice at home). But at least it boots ok with a PCI network card (and waits forever if I remove support for that card from the kernel). Of course, in the long run, a better solution is an initrd with dhcp/bootp/rarp client in userspace. But AFAIK there is no Debian package that does that yet ;-). Eric --- linux-2.4.9-ac7/net/ipv4/ipconfig.c.orig Wed May 2 05:59:24 2001 +++ linux-2.4.9-ac7/net/ipv4/ipconfig.c Tue Sep 18 00:19:03 2001 @@ -102,6 +102,8 @@ int ic_enable __initdata = 0; /* IP config enabled? */ +int ic_wait __initdata = 0; /* wait until a device appears? */ + /* Protocol choice */ int ic_proto_enabled __initdata = 0 #ifdef IPCONFIG_BOOTP @@ -1105,8 +1107,12 @@ ; /* Setup all network devices */ - if (ic_open_devs() < 0) - return -1; + if (ic_open_devs() < 0) { + if(!ic_wait) return -1; + + printk("IP-Config: Retrying forever...\n"); + goto try_try_again; // wait a while and try again + } /* Give drivers a chance to settle */ jiff = jiffies + CONF_POST_OPEN; @@ -1281,6 +1287,8 @@ (strcmp(addrs, "none") != 0)); if (!ic_enable) return 1; + + ic_wait = *addrs && (strcmp(addrs, "wait") == 0); if (ic_proto_name(addrs)) return 1; From owner-netdev@oss.sgi.com Mon Sep 17 19:07:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8I27s318868 for netdev-outgoing; Mon, 17 Sep 2001 19:07:54 -0700 Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8I27Ge18862 for ; Mon, 17 Sep 2001 19:07:16 -0700 Received: from southrelay03.raleigh.ibm.com (southrelay03.raleigh.ibm.com [9.37.3.210]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA62796; Mon, 17 Sep 2001 21:03:55 -0500 Received: from w-sridhar2.des.beaverton.ibm.com (w-sridhar2.des.beaverton.ibm.com [9.47.18.20]) by southrelay03.raleigh.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8I26BD131390; Mon, 17 Sep 2001 22:06:11 -0400 Date: Mon, 17 Sep 2001 19:06:12 -0700 (PDT) From: Sridhar Samudrala X-Sender: sridhar@w-sridhar2.des.sequent.com To: netdev@oss.sgi.com, linux-net@vger.kernel.org, kuznet@ms2.inr.ac.ru cc: dmfreim@us.ibm.com Subject: [PATCH] Prioritized Accept Queues with Preemption Capability Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 12811 Lines: 409 The following patch is an enhancement to a mechanism called Prioritized Accept Queues(PAQ) that can be used to prioritize incoming connection requests on a socket based on the source/dest ip addreses and ports. We have posted the original patch in July. This enhancement introduces a way to preempt low priority connections from the accept queue in order to avoid starvation of higher priority connections when the accept queue is filled with lower priority connections. This idea is based on the comments and suggestions made by Alexey. The documentation on HOWTO use this patch and the test results which show an improvement in connection rate for higher priority classes can be found at our project website. http://oss.software.ibm.com/qos We would appreciate any comments or suggestions. Thanks Sridhar --------------------------- Sridhar Samudrala IBM Linux Technology Centre samudrala@us.ibm.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ diff -urN -X dontdiff linux-2.4.9/Documentation/Configure.help linux-2.4.9-ppaq/Documentation/Configure.help --- linux-2.4.9/Documentation/Configure.help Sun Aug 12 10:51:41 2001 +++ linux-2.4.9-ppaq/Documentation/Configure.help Thu Sep 13 18:15:37 2001 @@ -1955,6 +1955,14 @@ If you want to compile it as a module, say M here and read Documentation/modules.txt. If unsure, say `N'. +Prioritized Accept Queue (EXPERIMENTAL) +CONFIG_PRIO_ACCEPTQ + When enabled, this option allows you to set priorities to incoming + connection requests using the rules created by the iptables MARK target + option. The nfmark field set by the rules is used as a priority value + when the connection is added to accept queue. The priority value can + range between 0-7 with 0 being the highest priority and 7 the lowest. + Packet filtering CONFIG_IP_NF_FILTER Packet filtering defines a table `filter', which has a series of diff -urN -X dontdiff linux-2.4.9/include/net/sock.h linux-2.4.9-ppaq/include/net/sock.h --- linux-2.4.9/include/net/sock.h Wed Aug 15 14:21:32 2001 +++ linux-2.4.9-ppaq/include/net/sock.h Thu Sep 13 18:32:38 2001 @@ -239,6 +239,11 @@ #define pppoe_relay proto.pppoe.relay #endif +#ifdef CONFIG_PRIO_ACCEPTQ +/* Priorities range from 0-7 */ +#define MAX_ACCEPTQ_PRIO 7 +#endif + /* This defines a selective acknowledgement block. */ struct tcp_sack_block { __u32 start_seq; @@ -409,7 +414,11 @@ /* FIFO of established children */ struct open_request *accept_queue; +#ifdef CONFIG_PRIO_ACCEPTQ + struct open_request *accept_queue_tail[MAX_ACCEPTQ_PRIO]; +#else struct open_request *accept_queue_tail; +#endif int write_pending; /* A write to socket waits to start. */ diff -urN -X dontdiff linux-2.4.9/include/net/tcp.h linux-2.4.9-ppaq/include/net/tcp.h --- linux-2.4.9/include/net/tcp.h Wed Aug 15 14:26:33 2001 +++ linux-2.4.9-ppaq/include/net/tcp.h Thu Sep 13 18:42:25 2001 @@ -519,6 +519,9 @@ struct tcp_v6_open_req v6_req; #endif } af; +#ifdef CONFIG_PRIO_ACCEPTQ + int acceptq_prio; +#endif }; /* SLAB cache for open requests. */ @@ -1572,10 +1575,33 @@ struct sock *child) { struct tcp_opt *tp = &sk->tp_pinfo.af_tcp; +#ifdef CONFIG_PRIO_ACCEPTQ + int prio = req->acceptq_prio; + int prev_prio; +#endif req->sk = child; tcp_acceptq_added(sk); +#ifdef CONFIG_PRIO_ACCEPTQ + if (!tp->accept_queue_tail[prio]) { + for (prev_prio = prio - 1; prev_prio >= 0; prev_prio--) + if (tp->accept_queue_tail[prev_prio]) + break; + tp->accept_queue_tail[prio] = req; + if (prev_prio >= 0) { + req->dl_next = tp->accept_queue_tail[prev_prio]->dl_next; + tp->accept_queue_tail[prev_prio]->dl_next = req; + } else { + req->dl_next = tp->accept_queue; + tp->accept_queue = req; + } + } else { + req->dl_next = tp->accept_queue_tail[prio]->dl_next; + tp->accept_queue_tail[prio]->dl_next = req; + tp->accept_queue_tail[prio] = req; + } +#else if (!tp->accept_queue_tail) { tp->accept_queue = req; } else { @@ -1583,6 +1609,7 @@ } tp->accept_queue_tail = req; req->dl_next = NULL; +#endif } struct tcp_listen_opt @@ -1649,6 +1676,10 @@ struct tcp_opt *tp, struct sk_buff *skb) { +#ifdef CONFIG_PRIO_ACCEPTQ + int nfmark = (int)skb->nfmark; +#endif + req->rcv_wnd = 0; /* So that tcp_send_synack() knows! */ req->rcv_isn = TCP_SKB_CB(skb)->seq; req->mss = tp->mss_clamp; @@ -1660,6 +1691,9 @@ req->acked = 0; req->ecn_ok = 0; req->rmt_port = skb->h.th->source; +#ifdef CONFIG_PRIO_ACCEPTQ + req->acceptq_prio = (nfmark < 0) ? 0 : ((nfmark > MAX_ACCEPTQ_PRIO) ? MAX_ACCEPTQ_PRIO : nfmark); +#endif } #define TCP_MEM_QUANTUM ((int)PAGE_SIZE) diff -urN -X dontdiff linux-2.4.9/net/ipv4/netfilter/Config.in linux-2.4.9-ppaq/net/ipv4/netfilter/Config.in --- linux-2.4.9/net/ipv4/netfilter/Config.in Tue Mar 6 22:44:16 2001 +++ linux-2.4.9-ppaq/net/ipv4/netfilter/Config.in Thu Sep 13 18:15:38 2001 @@ -27,6 +27,7 @@ if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then dep_tristate ' Unclean match support (EXPERIMENTAL)' CONFIG_IP_NF_MATCH_UNCLEAN $CONFIG_IP_NF_IPTABLES dep_tristate ' Owner match support (EXPERIMENTAL)' CONFIG_IP_NF_MATCH_OWNER $CONFIG_IP_NF_IPTABLES + bool ' Prioritized Accept Queues (EXPERIMENTAL)' CONFIG_PRIO_ACCEPTQ fi # The targets dep_tristate ' Packet filtering' CONFIG_IP_NF_FILTER $CONFIG_IP_NF_IPTABLES diff -urN -X dontdiff linux-2.4.9/net/ipv4/tcp.c linux-2.4.9-ppaq/net/ipv4/tcp.c --- linux-2.4.9/net/ipv4/tcp.c Wed Aug 15 01:22:17 2001 +++ linux-2.4.9-ppaq/net/ipv4/tcp.c Thu Sep 13 18:15:38 2001 @@ -529,7 +529,12 @@ sk->max_ack_backlog = 0; sk->ack_backlog = 0; +#ifdef CONFIG_PRIO_ACCEPTQ + tp->accept_queue = NULL; + memset(tp->accept_queue_tail, 0, (sizeof(struct open_request *) * (MAX_ACCEPTQ_PRIO + 1))); +#else tp->accept_queue = tp->accept_queue_tail = NULL; +#endif tp->syn_wait_lock = RW_LOCK_UNLOCKED; tcp_delack_init(tp); @@ -588,7 +593,12 @@ write_lock_bh(&tp->syn_wait_lock); tp->listen_opt =NULL; write_unlock_bh(&tp->syn_wait_lock); +#ifdef CONFIG_PRIO_ACCEPTQ + tp->accept_queue = NULL; + memset(tp->accept_queue_tail, 0, (sizeof(struct open_request *) * (MAX_ACCEPTQ_PRIO + 1))); +#else tp->accept_queue = tp->accept_queue_tail = NULL; +#endif if (lopt->qlen) { for (i=0; iaccept_queue; +#ifdef CONFIG_PRIO_ACCEPTQ + tp->accept_queue = req->dl_next; + for (prio = 0; prio <= MAX_ACCEPTQ_PRIO; prio++) + if (req == tp->accept_queue_tail[prio]) { + tp->accept_queue_tail[prio] = NULL; + break; + } +#else if ((tp->accept_queue = req->dl_next) == NULL) tp->accept_queue_tail = NULL; +#endif newsk = req->sk; tcp_acceptq_removed(sk); diff -urN -X dontdiff linux-2.4.9/net/ipv4/tcp_ipv4.c linux-2.4.9-ppaq/net/ipv4/tcp_ipv4.c --- linux-2.4.9/net/ipv4/tcp_ipv4.c Wed Apr 25 14:57:39 2001 +++ linux-2.4.9-ppaq/net/ipv4/tcp_ipv4.c Mon Sep 17 18:49:01 2001 @@ -1262,6 +1262,21 @@ tcp_v4_send_reset }; +#ifdef CONFIG_PRIO_ACCEPTQ +static struct open_request *low_prio_req_in_acceptq(struct sock *sk, int prio) +{ + struct tcp_opt *tp = &sk->tp_pinfo.af_tcp; + struct open_request *low_prio_req = NULL; + int tmp_prio; + + for (tmp_prio = MAX_ACCEPTQ_PRIO; tmp_prio > prio; tmp_prio--) + if ((low_prio_req = tp->accept_queue_tail[tmp_prio])) + break; + + return (low_prio_req); +} +#endif + int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb) { struct tcp_opt tp; @@ -1299,7 +1314,19 @@ * clogging syn queue with openreqs with exponentially increasing * timeout. */ +#ifdef CONFIG_PRIO_ACCEPTQ + /* With Prioritized Accept Queue, a new condition is added so that an + * incoming SYN is dropped only if there are no lower priority + * connection requests in the acceptq. This is to avoid starvation of + * higher priority connection requests in the presence of persistent low + * priority connections filling up the acceptq. + */ + if (tcp_acceptq_is_full(sk) && + !(low_prio_req_in_acceptq(sk, (int)skb->nfmark)) && + tcp_synq_young(sk) > 1) +#else if (tcp_acceptq_is_full(sk) && tcp_synq_young(sk) > 1) +#endif goto drop; req = tcp_openreq_alloc(); @@ -1407,6 +1434,62 @@ return 0; } +#ifdef CONFIG_PRIO_ACCEPTQ +/* removes the req(last one) from sk's accept queue. */ +static void remove_openreq_from_acceptq(struct sock *sk, struct open_request *req) +{ + struct tcp_opt *tp = &sk->tp_pinfo.af_tcp; + struct open_request *tmp_req = NULL; + struct open_request *prev_req; + int req_prio = req->acceptq_prio; + int prio; + + /* find the last req in the next higher priority class */ + for (prio = req_prio-1; prio >= 0; prio--) + if ((tmp_req = tp->accept_queue_tail[prio])) + break; + + /* no higher priority class, start scanning from the start of acceptq */ + if (!tmp_req) + tmp_req = tp->accept_queue; + + prev_req = tmp_req; + + /* find the prev req */ + for (; tmp_req ; tmp_req = tmp_req->dl_next) { + if (tmp_req == req) + break; + prev_req = tmp_req; + } + + if (prev_req) { + prev_req->dl_next = NULL; + if (prev_req->acceptq_prio == req_prio) + tp->accept_queue_tail[req_prio] = prev_req; + else + tp->accept_queue_tail[req_prio] = NULL; + } else { + BUG_TRAP(prev_req != NULL); + } +} + +/* remove lreq from accept queue and add it to syn table */ +static void preempt_low_prio_req(struct sock *sk, struct open_request *lreq) +{ + struct sock *lsk; + + lsk = lreq->sk; + lreq->sk = NULL; + remove_openreq_from_acceptq(sk, lreq); + tcp_acceptq_removed(sk); + tcp_v4_synq_add(sk, lreq); + tcp_unhash(lsk); + tcp_set_state(lsk, TCP_CLOSE); + sock_orphan(lsk); + atomic_inc(&tcp_orphan_count); + tcp_destroy_sock(lsk); +} +#endif /* CONFIG_PRIO_ACCEPTQ */ /* * The three way handshake has completed - we got a valid synack - @@ -1419,8 +1502,35 @@ struct tcp_opt *newtp; struct sock *newsk; +#ifdef CONFIG_PRIO_ACCEPTQ + if (tcp_acceptq_is_full(sk)) { + struct open_request *low_prio_req; + + /* if there is a lower priority req in acceptq and we haven't + * acked any received data on the associated socket, move it to + * syn table so that the incoming higher priority req can be + * accepted. + */ + if ((low_prio_req = low_prio_req_in_acceptq(sk, req->acceptq_prio))) { + struct sock *lsk = low_prio_req->sk; + struct tcp_opt *tp = &lsk->tp_pinfo.af_tcp; + + bh_lock_sock(lsk); + /* we haven't acked any data received */ + if (tp->rcv_wup == (low_prio_req->rcv_isn + 1)) { + preempt_low_prio_req(sk, low_prio_req); + bh_unlock_sock(lsk); + } else { + bh_unlock_sock(lsk); + goto exit_overflow; + } + } else + goto exit_overflow; + } +#else if (tcp_acceptq_is_full(sk)) goto exit_overflow; +#endif if (dst == NULL && (dst = tcp_v4_route_req(sk, req)) == NULL) diff -urN -X dontdiff linux-2.4.9/net/ipv4/tcp_minisocks.c linux-2.4.9-ppaq/net/ipv4/tcp_minisocks.c --- linux-2.4.9/net/ipv4/tcp_minisocks.c Wed Aug 15 01:22:17 2001 +++ linux-2.4.9-ppaq/net/ipv4/tcp_minisocks.c Mon Sep 17 18:49:18 2001 @@ -734,7 +734,12 @@ newtp->num_sacks = 0; newtp->urg_data = 0; newtp->listen_opt = NULL; +#ifdef CONFIG_PRIO_ACCEPTQ + newtp->accept_queue = NULL; + memset(newtp->accept_queue_tail, 0, (sizeof(struct open_request *) * (MAX_ACCEPTQ_PRIO + 1))); +#else newtp->accept_queue = newtp->accept_queue_tail = NULL; +#endif /* Deinitialize syn_wait_lock to trap illegal accesses. */ memset(&newtp->syn_wait_lock, 0, sizeof(newtp->syn_wait_lock)); @@ -802,6 +807,9 @@ int paws_reject = 0; struct tcp_opt ttp; struct sock *child; +#ifdef CONFIG_PRIO_ACCEPTQ + struct open_request *r1, *r2; +#endif ttp.saw_tstamp = 0; if (th->doff > (sizeof(struct tcphdr)>>2)) { @@ -913,10 +921,24 @@ * ESTABLISHED STATE. If it will be dropped after * socket is created, wait for troubles. */ +#ifdef CONFIG_PRIO_ACCEPTQ + r1 = *prev; +#endif child = tp->af_specific->syn_recv_sock(sk, skb, req, NULL); if (child == NULL) goto listen_overflow; +#ifdef CONFIG_PRIO_ACCEPTQ + r2 = *prev; + /* With Prioritized Accept Queues, it is possible that prev pointer can + * change in the above call to syn_recv_sock(). This can happen if an + * openreq is preempted and moved from acceptq to syn table and it + * hashes to the same bucket as 'req' and 'req' is the first entry in + * the hash bucket. If so, prev needs to be updated. + */ + if ((req == r1) && (r1 != r2)) + prev = &r2->dl_next; +#endif tcp_synq_unlink(tp, req, prev); tcp_synq_removed(sk, req); ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From owner-netdev@oss.sgi.com Mon Sep 17 19:19:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8I2JtM19089 for netdev-outgoing; Mon, 17 Sep 2001 19:19:55 -0700 Received: from dea.linux-mips.net (u-210-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.210]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8I2Jce19083 for ; Mon, 17 Sep 2001 19:19:39 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f8I2JY530047 for netdev@oss.sgi.com; Tue, 18 Sep 2001 04:19:34 +0200 Received: from grok.yi.org (IDENT:root@cx97923-a.phnx3.az.home.com [24.9.112.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8HNuxe16982 for ; Mon, 17 Sep 2001 16:56:59 -0700 Received: from candelatech.com (IDENT:greear@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.2/8.11.2) with ESMTP id f8HNuwT02640; Mon, 17 Sep 2001 16:56:58 -0700 Message-ID: <3BA68DCA.F0A2A7D@candelatech.com> Date: Mon, 17 Sep 2001 16:56:58 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686) X-Accept-Language: en MIME-Version: 1.0 To: Guilhem Tardy CC: netdev@oss.sgi.com Subject: Re: skbuff variables set already in ethernet drivers References: <20010917223259.71870.qmail@web11501.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1274 Lines: 30 Guilhem Tardy wrote: > > Hello, > > I tried to modify the 3c59x.c driver some time ago, unsuccessfully. I now want > to get around those difficulties, could you help? > > My goal is to add an unsigned long value in all UDP packets received on a > particular port. This value represents the current time from a custom rtc timer > (8192Hz). I also modified ip_input.c and udp.c for the same purpose. Obviously, > I had to turn off the checksum in 3c59x.c and udp.c. > > The problem is that I don't know where skbuff.{data, mac.ethernet} point to in > 3c59x.c (or any driver, for what it matters)? As a result, the value is > probably copied in the wrong place. Well, the driver is given whole ethernet frames to ship, right? In other words, data points to the beginning of the ethernet header by the time the driver sees the skb. I wouldn't trust mac.ethernet on transmitted skb, btw: I don't think it is (uniformly??) set. So, you know the first 12 bytes are MAC addresses, the next 2 are length/proto, and the IP header will start after that.... Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Tue Sep 18 02:00:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8I90TI25725 for netdev-outgoing; Tue, 18 Sep 2001 02:00:29 -0700 Received: from hrtades9.atea.be (viap090.atea.be [194.78.143.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8I90Me25721 for ; Tue, 18 Sep 2001 02:00:25 -0700 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SF8JZP1H; Tue, 18 Sep 2001 11:00:30 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Sep 2001 11:00:00 +0200 Message-ID: <6B546A602AD2D211BFF00008C7A42889041D6BF8@hrtades2.atea.be> From: Goddeeris Frederic To: "'netdev@oss.sgi.com'" Subject: Non Ethernet network driver Date: Tue, 18 Sep 2001 10:59:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 973 Lines: 24 Hi, I need to exchange data between an MPC860 processor and other components over an HDLC bus. No protocol is needed on top of that; from an application I need to be able to send and receive HDLC packets. I have some working code. On another mailing-list I asked whether I should pack it as a char or a network driver. Somebody who advised me to write a network driver told me to pick a type from linux/if_ether.h (like ETH_P_WAN_PPP) and use raw sockets. He also told me that this question would better fit on the netdev mailing list... I am still confused about what parameters I exactly need to use when opening a socket and how the OS will know what network driver to use. As far as I know for Ethernet adapters ifconfig is used to map reachable IP-addresses to adapters. Until now I am unsuccessful in finding some sample-code or document that gives me enough information. Every example/document is so Ethernet/IP oriented. Who can help me? Regards, Frederic From owner-netdev@oss.sgi.com Tue Sep 18 05:24:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ICO0K29637 for netdev-outgoing; Tue, 18 Sep 2001 05:24:00 -0700 Received: from smtp102.urscorp.com (smtp102.urscorp.com [64.17.27.233]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ICNxe29634 for ; Tue, 18 Sep 2001 05:23:59 -0700 To: Goddeeris Frederic Cc: netdev@oss.sgi.com Subject: Re: Non Ethernet network driver X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: mike_phillips@urscorp.com Message-ID: Date: Tue, 18 Sep 2001 08:22:47 -0400 X-MIMETrack: Serialize by Router on SMTP102/URSCorp(Release 5.0.5 |September 22, 2000) at 09/18/2001 08:22:59 AM, Serialize complete at 09/18/2001 08:22:59 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 156 Lines: 5 You may want to take a look at the work done for sna. (www.linux-sna.org). They've built the protocol stack directly on top of the network drivers. Mike From owner-netdev@oss.sgi.com Tue Sep 18 12:19:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8IJJgn05066 for netdev-outgoing; Tue, 18 Sep 2001 12:19:42 -0700 Received: from ezri.xs4all.nl (ezri.xs4all.nl [194.109.253.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8IJJae05063 for ; Tue, 18 Sep 2001 12:19:37 -0700 Received: (qmail 10786 invoked from network); 18 Sep 2001 19:19:30 -0000 Received: from ally.lammerts.org (10.90.0.1) by ally.lammerts.org with SMTP; 18 Sep 2001 19:19:30 -0000 Date: Tue, 18 Sep 2001 21:19:30 +0200 (CEST) From: Eric Lammerts To: David Acklam cc: , , Subject: Re: compiled-in (non-modular) USB initialization bug 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: 1686 Lines: 55 On Tue, 18 Sep 2001, Eric Lammerts wrote: > > The following patch adds the "ip=wait" option. It makes ipconfig.c > retry forever until is has found a suitable device to do > dhcp/bootp/rarp. This was a dumb patch. It didn't schedule so the USB kernel thread could not do anything. This is fixed in the patch below. The ip=wait parameter is gone now: it'll always wait for a net device if you're doing nfsroot. I've tested it with a Pegasus USB ethernet adapter and it works ok. You can even boot the kernel without any adapter plugged in. It will patiently wait for you to plug one in. Then it'll start the dhcp/bootp/rarp stuff. Eric --- linux-2.4.9-ac7/net/ipv4/ipconfig.c.orig Wed May 2 05:59:24 2001 +++ linux-2.4.9-ac7/net/ipv4/ipconfig.c Tue Sep 18 17:16:07 2001 @@ -80,6 +80,8 @@ #define CONF_PRE_OPEN (HZ/2) /* Before opening: 1/2 second */ #define CONF_POST_OPEN (1*HZ) /* After opening: 1 second */ +#define CONF_DEV_WAIT (1*HZ) + /* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */ #define CONF_OPEN_RETRIES 2 /* (Re)open devices twice */ #define CONF_SEND_RETRIES 6 /* Send six requests per open */ @@ -1105,8 +1107,20 @@ ; /* Setup all network devices */ - if (ic_open_devs() < 0) + while (ic_open_devs() < 0) { +#ifdef CONFIG_ROOT_NFS + if (ROOT_DEV == MKDEV(UNNAMED_MAJOR, 255)) { + printk(KERN_ERR + "IP-Config: Retrying forever (NFS root)...\n"); + + // wait a while and try again + current->state = TASK_INTERRUPTIBLE; + schedule_timeout(CONF_DEV_WAIT); + continue; + } +#endif return -1; + } /* Give drivers a chance to settle */ jiff = jiffies + CONF_POST_OPEN; From owner-netdev@oss.sgi.com Wed Sep 19 06:22:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8JDMAE27035 for netdev-outgoing; Wed, 19 Sep 2001 06:22:10 -0700 Received: from web11501.mail.yahoo.com (web11501.mail.yahoo.com [216.136.172.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8JDM6e27032 for ; Wed, 19 Sep 2001 06:22:06 -0700 Message-ID: <20010919132205.52080.qmail@web11501.mail.yahoo.com> Received: from [24.112.158.226] by web11501.mail.yahoo.com via HTTP; Wed, 19 Sep 2001 06:22:05 PDT Date: Wed, 19 Sep 2001 06:22:05 -0700 (PDT) From: Guilhem Tardy Subject: 3c59x.c modified for time measurement / code included To: netdev@oss.sgi.com, andrewm@uow.edu.au Cc: greearb@candelatech.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1847 Lines: 53 Hi all, I should be able to access skb->mac.{ethernet, raw} ahter eth_type_trans(skb, dev), but nevertheless I used skb->data in the code below. At this point, only a series of consecutive numbers are written for test purpose, but the result is nil: I get all but what is expected when I tcpdump packets received on this port. I thought that the error could reside in the filter on UDP & port, but it seems right. Any idea? Guilhem. --- parts of the function boomerang_rx(struct net_device *dev) in 3c59x.c --- (...) if (rx_status & RxDError) { /* Error, update stats. */ (...) } else { /* The packet length: up to 4.5K!. */ (...) skb->protocol = eth_type_trans(skb, dev); { /* Use hardware checksum info. */ /* ### avoid checksum on all packets ! */ // int csum_bits = rx_status & 0xee000000; // if (csum_bits && // (csum_bits == (IPChksumValid | TCPChksumValid) || // csum_bits == (IPChksumValid | UDPChksumValid))) { skb->ip_summed = CHECKSUM_UNNECESSARY; vp->rx_csumhits++; // } } /* ### add time */ if (*(skb->data + 9) == 17 && *(((unsigned int *) (skb->data+20)) + 1) == htons(6969)) { // *((unsigned long *) (skb->data + 28)) = rsm_jiffies; *((unsigned long *) (skb->data + 28)) = 0x00000000; *(((unsigned long *) (skb->data + 28)) + 1) = 0x00000001; *(((unsigned long *) (skb->data + 28)) + 2) = 0x00000002; *(((unsigned long *) (skb->data + 28)) + 3) = 0x00000003; *(((unsigned long *) (skb->data + 28)) + 4) = 0x00000004; *(((unsigned long *) (skb->data + 28)) + 5) = 0x00000005; } netif_rx(skb); dev->last_rx = jiffies; vp->stats.rx_packets++; } __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From owner-netdev@oss.sgi.com Wed Sep 19 09:08:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8JG8JB31103 for netdev-outgoing; Wed, 19 Sep 2001 09:08:19 -0700 Received: from web11508.mail.yahoo.com (web11508.mail.yahoo.com [216.136.172.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8JG8Ge31097 for ; Wed, 19 Sep 2001 09:08:16 -0700 Message-ID: <20010919151227.4370.qmail@web11508.mail.yahoo.com> Received: from [134.22.47.55] by web11508.mail.yahoo.com via HTTP; Wed, 19 Sep 2001 08:12:27 PDT Date: Wed, 19 Sep 2001 08:12:27 -0700 (PDT) From: Guilhem Tardy Subject: Re: 3c59x.c modified for time measurement / code included To: Rene Pilz Cc: netdev@oss.sgi.com In-Reply-To: <200109191436.QAA20886@mx0.int.fh-sbg.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1031 Lines: 25 > After eth_type_trans the skb->data pointer is at the first position > of the data part of the frame. So you only have to look 14 octets > before skb->data. I assume that after eth_type_trans the skb->data pointer is at the first position of the IP header. Then *(skb->data+9) should be the IP protocol (i.e. 17 for UDP), and *(skb->data+20) should be the start of the UDP header. What is your remark concerning "int = 32Bit @ linux"? I thought that short/int was platform dependant, and unsigned short/int on x86 should be only 16 bits. It would have been probably safer to use u8, u16 or u32. if ((*(skb->data + 9 ) == 17 ) && ( *((unsigned short *) (skb->data+20)+1) == 0x391b )) I will make changes accordingly (with +1 for the UDP destination port, as above). Thanks, I hope this was all what caused my problems. Guilhem. __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From owner-netdev@oss.sgi.com Wed Sep 19 09:36:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8JGam331783 for netdev-outgoing; Wed, 19 Sep 2001 09:36:48 -0700 Received: from castor.erda.se ([195.163.32.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8JGaie31780 for ; Wed, 19 Sep 2001 09:36:44 -0700 Received: by castor.erda.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 18:38:17 +0200 Message-ID: <499AC99D205FD51197CD0002A574C4F80523EE@castor.erda.se> From: =?iso-8859-1?Q?=22Wikstr=F6m=2C_M=E5rten=22?= To: "'netdev@oss.sgi.com'" Subject: Is IP Header Compression (RFC2507) implemented? Date: Wed, 19 Sep 2001 18:38:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14129.7B7D7A50" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1360 Lines: 49 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C14129.7B7D7A50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know if there is an implementation of IP header compression according to RFC 2507 available anywhere. I have searched the net but = have found nothing so far. I am thinking about implementing it if its not = already done. Thanks M=E5rten ------_=_NextPart_001_01C14129.7B7D7A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is IP Header Compression (RFC2507) implemented?

Does anyone know if there is an implementation of IP = header compression according to RFC 2507 available anywhere. I have = searched the net but have found nothing so far. I am thinking about = implementing it if its not already done.

Thanks

M=E5rten

------_=_NextPart_001_01C14129.7B7D7A50-- From owner-netdev@oss.sgi.com Wed Sep 19 12:25:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8JJP6O02706 for netdev-outgoing; Wed, 19 Sep 2001 12:25:06 -0700 Received: from vaio.greennet (battlejitney.wdhq.scyld.com [216.254.93.178]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8JJP1e02698 for ; Wed, 19 Sep 2001 12:25:01 -0700 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id PAA02083; Wed, 19 Sep 2001 15:27:22 -0400 Date: Wed, 19 Sep 2001 15:27:22 -0400 (EDT) From: Donald Becker X-Sender: becker@vaio.greennet To: Guilhem Tardy cc: netdev@oss.sgi.com, andrewm@uow.edu.au, greearb@candelatech.com Subject: Re: 3c59x.c modified for time measurement / code included In-Reply-To: <20010919132205.52080.qmail@web11501.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: 2151 Lines: 52 On Wed, 19 Sep 2001, Guilhem Tardy wrote: > Subject: 3c59x.c modified for time measurement / code included I had previously guessed that you had selected the 3c905C for its various features, including checksum and real-time support. But you don't seem to be using the special hardware at all. > parts of the function boomerang_rx(struct net_device *dev) in 3c59x.c .... > skb->protocol = eth_type_trans(skb, dev); > { /* Use hardware checksum info. */ > /* ### avoid checksum on all packets ! */ > // int csum_bits = rx_status & 0xee000000; > // if (csum_bits && Why did you comment this out? I had previously guessed that you wanted to limit changes to just the driver, and don't want to duplicate the software checksum code. The 3c905B /3c905C has the easiest to use hardware TCP/IP checksum assist -- the hardware does all of the work for you. Presumably you only want to accept uncorrupted packets, and you don't want to protocol layers to subsequently reject the packets because of an invalid checksum. (Ignoring the issue of fragmented packets...) The best approach is to retain the checksum support, only annotate packets that pass the chip's checksum, and continue to set CHECKSUM_UNNECESSARY as before. > /* ### add time */ > if (*(skb->data + 9) == 17 && *(((unsigned int *) (skb->data+20)) + 1) == > htons(6969)) { Acckkk!! Don't you really want u16 ( u8/u16/u32) as the type? And probably htons(0x6969) not htons(6969). And that unaligned access indicates that you probably have the wrong offset. Look at the receive debugging code in the pci-skeleton.c example driver for an example of how to use skb->data ftp://www.scyld.com/pub/network/pci-skeleton.c Also, if you are using the 3c905C (or later) you have the "RealTimeCnt" register. This is a counter at offset 0x40 intended to support real-time transmit scheduling and time stamps. It is a wrapping 32 bit counter that increments every 800ns. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Wed Sep 19 12:44:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8JJi1I03151 for netdev-outgoing; Wed, 19 Sep 2001 12:44:01 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8JJhse03146 for ; Wed, 19 Sep 2001 12:43:55 -0700 Received: from vaio.greennet (battlejitney.wdhq.scyld.com [216.254.93.178]) 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 MAB06106 for ; Wed, 19 Sep 2001 12:43:37 -0700 (PDT) mail_from (becker@scyld.com) Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id PAA02083; Wed, 19 Sep 2001 15:27:22 -0400 Date: Wed, 19 Sep 2001 15:27:22 -0400 (EDT) From: Donald Becker X-Sender: becker@vaio.greennet To: Guilhem Tardy cc: netdev@oss.sgi.com, andrewm@uow.edu.au, greearb@candelatech.com Subject: Re: 3c59x.c modified for time measurement / code included In-Reply-To: <20010919132205.52080.qmail@web11501.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: 2151 Lines: 52 On Wed, 19 Sep 2001, Guilhem Tardy wrote: > Subject: 3c59x.c modified for time measurement / code included I had previously guessed that you had selected the 3c905C for its various features, including checksum and real-time support. But you don't seem to be using the special hardware at all. > parts of the function boomerang_rx(struct net_device *dev) in 3c59x.c .... > skb->protocol = eth_type_trans(skb, dev); > { /* Use hardware checksum info. */ > /* ### avoid checksum on all packets ! */ > // int csum_bits = rx_status & 0xee000000; > // if (csum_bits && Why did you comment this out? I had previously guessed that you wanted to limit changes to just the driver, and don't want to duplicate the software checksum code. The 3c905B /3c905C has the easiest to use hardware TCP/IP checksum assist -- the hardware does all of the work for you. Presumably you only want to accept uncorrupted packets, and you don't want to protocol layers to subsequently reject the packets because of an invalid checksum. (Ignoring the issue of fragmented packets...) The best approach is to retain the checksum support, only annotate packets that pass the chip's checksum, and continue to set CHECKSUM_UNNECESSARY as before. > /* ### add time */ > if (*(skb->data + 9) == 17 && *(((unsigned int *) (skb->data+20)) + 1) == > htons(6969)) { Acckkk!! Don't you really want u16 ( u8/u16/u32) as the type? And probably htons(0x6969) not htons(6969). And that unaligned access indicates that you probably have the wrong offset. Look at the receive debugging code in the pci-skeleton.c example driver for an example of how to use skb->data ftp://www.scyld.com/pub/network/pci-skeleton.c Also, if you are using the 3c905C (or later) you have the "RealTimeCnt" register. This is a counter at offset 0x40 intended to support real-time transmit scheduling and time stamps. It is a wrapping 32 bit counter that increments every 800ns. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Wed Sep 19 15:51:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8JMpo107099 for netdev-outgoing; Wed, 19 Sep 2001 15:51:50 -0700 Received: from web11501.mail.yahoo.com (web11501.mail.yahoo.com [216.136.172.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8JMpje07096 for ; Wed, 19 Sep 2001 15:51:45 -0700 Message-ID: <20010919213413.21563.qmail@web11501.mail.yahoo.com> Received: from [134.22.47.55] by web11501.mail.yahoo.com via HTTP; Wed, 19 Sep 2001 14:34:13 PDT Date: Wed, 19 Sep 2001 14:34:13 -0700 (PDT) From: Guilhem Tardy Subject: Re: 3c59x.c modified for time measurement / code included To: Donald Becker Cc: netdev@oss.sgi.com, andrewm@uow.edu.au, greearb@candelatech.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2436 Lines: 61 > Presumably you only want to accept uncorrupted packets, and you don't > want to protocol layers to subsequently reject the packets because of an > invalid checksum. (Ignoring the issue of fragmented packets...) The > best approach is to retain the checksum support, only annotate packets > that pass the chip's checksum, and continue to set CHECKSUM_UNNECESSARY > as before. As a matter of fact, I did retain some of the hardware checksum as in "if (rx_status & RxDError)", but you are right in saying that I should keep the hardware TCP & UDP checksum as well, thanks. > > /* ### add time */ > > if (*(skb->data + 9) == 17 && *(((unsigned int *) (skb->data+20)) + 1) == > > htons(6969)) { > > Acckkk!! Don't you really want u16 ( u8/u16/u32) as the type? That was pointed out in a previous email, and I agree (see below). > And probably htons(0x6969) not htons(6969). OK. /* ### add time */ if (*(((u8 *) skb->data) + 9) == 17 && ((u16 *) (((u8 *) skb->data) + 20))[1] == htons(0x6969)) { *((u32 *) (skb->data + 28)) = 0x00000000; ((u32 *) (skb->data + 28))[1] = 0x00000001; (((u32 *) (skb->data + 28))[2] = 0x00000002; } > And that unaligned access indicates that you probably have the wrong offset. > > Look at the receive debugging code in the pci-skeleton.c example driver > for an example of how to use skb->data > ftp://www.scyld.com/pub/network/pci-skeleton.c Thanks for the link, I looked at it but remain puzzled at this problem with "unaligned access". Could you please tell me more about it? > Also, if you are using the 3c905C (or later) you have the "RealTimeCnt" > register. This is a counter at offset 0x40 intended to support > real-time transmit scheduling and time stamps. It is a wrapping 32 bit > counter that increments every 800ns. Is this supported by recent NICs from other vendors as well? As for my current test, I actually don't need such a thing, since I already got a 8192Hz counter (by interrupt) working and an accuracy of a few milliseconds is enough. But if I can access this RealTimeCnt from other parts of the kernel AND from the application space, this could come handy. Do you have sample code for that? Regards, Guilhem. __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From owner-netdev@oss.sgi.com Wed Sep 19 18:53:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8K1r9O10172 for netdev-outgoing; Wed, 19 Sep 2001 18:53:09 -0700 Received: from vaio.greennet (battlejitney.wdhq.scyld.com [216.254.93.178]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8K1r4e10163 for ; Wed, 19 Sep 2001 18:53:06 -0700 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id VAA02805; Wed, 19 Sep 2001 21:55:23 -0400 Date: Wed, 19 Sep 2001 21:55:23 -0400 (EDT) From: Donald Becker X-Sender: becker@vaio.greennet To: Guilhem Tardy cc: netdev@oss.sgi.com, andrewm@uow.edu.au, greearb@candelatech.com Subject: Re: 3c59x.c modified for time measurement / code included In-Reply-To: <20010919213413.21563.qmail@web11501.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: 1708 Lines: 40 On Wed, 19 Sep 2001, Guilhem Tardy wrote: > > And that unaligned access indicates that you probably have the wrong offset. ... > Thanks for the link, I looked at it but remain puzzled at this problem with > "unaligned access". Could you please tell me more about it? If you are accessing a 32 bit number, you should use a "naturally aligned" address. In your previous example you were using (int *)(base + 21) If "base" is aligned, base+21 will be misaligned for all but byte accesses. This is only a minor performance problem with the x86, but it may cause a trap (and associated major performance problem) on other architectures. > > Also, if you are using the 3c905C (or later) you have the "RealTimeCnt" > > register. This is a counter at offset 0x40 intended to support > > real-time transmit scheduling and time stamps. It is a wrapping 32 bit > > counter that increments every 800ns. > > Is this supported by recent NICs from other vendors as well? No. The 3c905C is the only low-cost board that has real time packet scheduling. > As for my current test, I actually don't need such a thing, since I > already got a 8192Hz counter (by interrupt) working and an accuracy of > a few milliseconds is enough. But if I can access this RealTimeCnt > from other parts of the kernel AND from the application space, this > could come handy. Do you have sample code for that? It's trival to access in the device driver -- just read offset 0x40. It's very difficult to use elsewhere, at least for general purpose code. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Wed Sep 19 20:20:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8K3KjI11622 for netdev-outgoing; Wed, 19 Sep 2001 20:20:45 -0700 Received: from web11507.mail.yahoo.com (web11507.mail.yahoo.com [216.136.172.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8K3Khe11619 for ; Wed, 19 Sep 2001 20:20:43 -0700 Message-ID: <20010920032040.14252.qmail@web11507.mail.yahoo.com> Received: from [24.112.158.226] by web11507.mail.yahoo.com via HTTP; Wed, 19 Sep 2001 20:20:40 PDT Date: Wed, 19 Sep 2001 20:20:40 -0700 (PDT) From: Guilhem Tardy Subject: Re: 3c59x.c modified for time measurement / code included To: Donald Becker Cc: netdev@oss.sgi.com, andrewm@uow.edu.au, greearb@candelatech.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 992 Lines: 24 > If you are accessing a 32 bit number, you should use a "naturally > aligned" address. In your previous example you were using > (int *)(base + 21) > If "base" is aligned, base+21 will be misaligned for all but byte accesses. Then I should be fine, as my original code read: *(((unsigned int *) (skb->data+20)) + 1) I was under the assumption that int was 16 bits on x86, but Rene corrected me ("int = 32Bit @ linux"). I will test the code modified with u16 first thing in the morning tomorrow. In all cases, the "+1" above refers to a pointer of unsigned int, then alignment should be OK, right? Thanks for the input. I hope not to bother anyone with that after tomorrow. :) As a last resort, I will add some heuristic to find the port number in the packet and start from there. Guilhem. __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From owner-netdev@oss.sgi.com Wed Sep 19 21:16:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8K4GtR12498 for netdev-outgoing; Wed, 19 Sep 2001 21:16:55 -0700 Received: from mandrakesoft.mandrakesoft.com (nsd.netnomics.com [216.71.84.35] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8K4Gre12495 for ; Wed, 19 Sep 2001 21:16:53 -0700 Received: from localhost (jgarzik@localhost) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP id XAA09280; Wed, 19 Sep 2001 23:16:50 -0500 Date: Wed, 19 Sep 2001 23:16:49 -0500 (CDT) From: Jeff Garzik To: linux-net@vger.kernel.org, netdev@oss.sgi.com cc: Linux-Kernel Subject: ethtool 1.3 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 861 Lines: 23 (this is directed to linux-kernel just this once; future announcements will be limited to the linux-net and netdev mailing lists.) A new version of ethtool was just posted on its homepage, at http://sf.net/projects/gkernel/ This version adds Wake-on-LAN support courtesy of Tim Hockin. You need kernel 2.4.9 or later, hardware which supports Wake-on-LAN, and a driver which supports Wake-on-LAN to take advantage of this. Since it takes a little while for SourceForge's database to post the new file locations, you can optionally use this direct (and permanent) link: http://prdownloads.sourceforge.net/gkernel/ethtool-1.3.tar.gz What is ethtool? ethtool is a general diagnostic utility for your network adapter. It allows for general media selection, interrupt-based coalescing and mitigation control, NIC diagnostics, and Wake-on-LAN manipulation. From owner-netdev@oss.sgi.com Thu Sep 20 03:41:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KAfQ519485 for netdev-outgoing; Thu, 20 Sep 2001 03:41:26 -0700 Received: from samrat.cisco.com (samrat.cisco.com [192.135.241.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KAfOe19481 for ; Thu, 20 Sep 2001 03:41:24 -0700 Received: from vjacob-pc.cisco.com (root@[192.135.240.108]) by samrat.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA11319; Thu, 20 Sep 2001 16:11:32 +0530 (IST) Received: from localhost (jvt@localhost) by vjacob-pc.cisco.com (8.9.3/8.9.3) with ESMTP id QAA01753; Thu, 20 Sep 2001 16:10:59 GMT X-Authentication-Warning: vjacob-pc.cisco.com: jvt owned process doing -bs Date: Thu, 20 Sep 2001 16:10:59 +0000 (/etc/localtime) From: Vino Thomas X-Sender: jvt@vjacob-pc.cisco.com To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: IPV6 over MPLS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 68 Lines: 8 Hello, Does Linux has support for IPV6 over MPLS? Regards, Vino From owner-netdev@oss.sgi.com Thu Sep 20 04:35:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KBZvp20709 for netdev-outgoing; Thu, 20 Sep 2001 04:35:57 -0700 Received: from nero.doit.wisc.edu (nero.doit.wisc.edu [128.104.17.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KBZte20706 for ; Thu, 20 Sep 2001 04:35:55 -0700 Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id HAA28648; Thu, 20 Sep 2001 07:30:56 -0500 Date: Thu, 20 Sep 2001 07:30:56 -0500 From: "James R. Leu" To: Vino Thomas Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: IPV6 over MPLS Message-ID: <20010920073056.A28643@nero.doit.wisc.edu> Reply-To: jleu@mindspring.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jvt@technologist.com on Thu, Sep 20, 2001 at 04:10:59PM +0000 Organization: none Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 434 Lines: 18 On Thu, Sep 20, 2001 at 04:10:59PM +0000, Vino Thomas wrote: > Hello, > > Does Linux has support for IPV6 over MPLS? Right now there are only minimal hooks from the IPv6 stack to the MPLS stack. No testing has been done on it. If you are interested in working on it I could point you in the right direction. If you interesting in MPLS for Linux check out: http://sf.net/projects/mpls-linux > Regards, > Vino -- James R. Leu From owner-netdev@oss.sgi.com Thu Sep 20 10:56:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KHuOs29565 for netdev-outgoing; Thu, 20 Sep 2001 10:56:24 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KHu5e29561 for ; Thu, 20 Sep 2001 10:56:06 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15k88D-0005ld-00 for netdev@oss.sgi.com; Thu, 20 Sep 2001 19:01:01 +0100 Received: from vger.kernel.org ([199.183.24.194]) by the-village.bc.nu with esmtp (Exim 3.22 #1) id 15k6at-0005aV-00 for alan@lxorguk.ukuu.org.uk; Thu, 20 Sep 2001 17:22:32 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 20 Sep 2001 12:14:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 20 Sep 2001 12:14:39 -0400 Received: from e21.nc.us.ibm.com ([32.97.136.227]:17317 "EHLO e21.nc.us.ibm.com") by vger.kernel.org with ESMTP id ; Thu, 20 Sep 2001 12:14:23 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA158142 for ; Thu, 20 Sep 2001 11:12:15 -0500 Received: from d04nms38.raleigh.ibm.com (d04nms38.raleigh.ibm.com [9.67.228.5]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8KGEIq121540 for ; Thu, 20 Sep 2001 12:14:18 -0400 Importance: Normal Subject: [PATCH] strict interface arp patch for Linux 2.4.2 To: linux-kernel@vger.kernel.org X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: "Allen Lau" Date: Thu, 20 Sep 2001 12:12:53 -0400 X-MIMETrack: Serialize by Router on D04NMS38/04/M/IBM(Release 5.0.8 |June 18, 2001) at 09/20/2001 12:14:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 9245 Lines: 228 I want to bring your attention to a Linux ARP patch we plan to use for load balancing and server clustering. The available arp filter and hidden patch are not completely satisfactory. The following post by Julian Anastasov and Bernd Eckenfels described the virtual server clustering problem. http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.3/0188.html To generalize, each real server may have multiple nic's of different types. The task becomes one of maintaining strict identity of each of the real and virtual ip addresses. The Linux ARP has the following behaviors which are problematic for maintaining strict interface identify. 1) box responds to arp on all interfaces on the same wire for an IP address (arp race) 2) interface responds to arp requests for any of its IP addresses (loopback not hidden) 3) box responds to arp request for downed interface IP address 4) interface uses as source (in arp request) IP address from any other interface (arp flux) The proposed strict interface arp patch tackles the strict interface identify problem by explicitly binding arp request and response to the interface (i.e. an interface uses as source and responds to ARPs for an IP address only if the address is configured on the interface). The strict_interface_arp patch can be enabled for individual or all interfaces. 1) to enable for eth0 dynamically [/root]# echo 1 > /proc/sys/net/ipv4/conf/eth0/strict_interface_arp 2) to enable for all interfaces on boot using /etc/sysctl.conf [/root]# cat /etc/sysctl.conf # Enable strict_interface_arp : net.ipv4.conf.all.strict_interface_arp = 1 Your comments are sincerely appreciated. Allen Lau IBM Storage Network Division Research Triangle Park, NC 27709 email : pflau@us.ibm.com diff -Naur linux-2.4.2-2/Documentation/filesystems/proc.txt linux-2.4.2-2-strict_interface_arp/Documentation/filesystems/proc.txt --- linux-2.4.2-2/Documentation/filesystems/proc.txt Sat Sep 8 22:08:40 2001 +++ linux-2.4.2-2-strict_interface_arp/Documentation/filesystems/proc.txt Mon Sep 10 12:33:30 2001 @@ -1578,6 +1578,14 @@ Determines whether to send ICMP redirects to other hosts. +strict_interface_arp +-------------------- + +Bind arp request and response to the interface (i.e. an interface uses as source +and responds to ARPs for an IP address only if the address is configured on the +interface). + + Routing settings ---------------- diff -Naur linux-2.4.2-2/include/linux/inetdevice.h linux-2.4.2-2-strict_interface_arp/include/linux/inetdevice.h --- linux-2.4.2-2/include/linux/inetdevice.h Sat Sep 8 22:08:40 2001 +++ linux-2.4.2-2-strict_interface_arp/include/linux/inetdevice.h Mon Sep 10 12:33:30 2001 @@ -17,6 +17,7 @@ int forwarding; int mc_forwarding; int tag; + int strict_interface_arp; void *sysctl; }; @@ -47,6 +48,7 @@ #define IN_DEV_TX_REDIRECTS(in_dev) (ipv4_devconf.send_redirects || (in_dev)->cnf.send_redirects) #define IN_DEV_SEC_REDIRECTS(in_dev) (ipv4_devconf.secure_redirects || (in_dev)->cnf.secure_redirects) #define IN_DEV_IDTAG(in_dev) ((in_dev)->cnf.tag) +#define IN_DEV_STRICT_INTF_ARP(in_dev) (ipv4_devconf.strict_interface_arp || (in_dev)->cnf.strict_interface_arp) #define IN_DEV_RX_REDIRECTS(in_dev) \ ((IN_DEV_FORWARD(in_dev) && \ diff -Naur linux-2.4.2-2/include/linux/sysctl.h linux-2.4.2-2-strict_interface_arp/include/linux/sysctl.h --- linux-2.4.2-2/include/linux/sysctl.h Sat Sep 8 22:08:40 2001 +++ linux-2.4.2-2-strict_interface_arp/include/linux/sysctl.h Mon Sep 10 12:33:30 2001 @@ -327,7 +327,8 @@ NET_IPV4_CONF_ACCEPT_SOURCE_ROUTE=9, NET_IPV4_CONF_BOOTP_RELAY=10, NET_IPV4_CONF_LOG_MARTIANS=11, - NET_IPV4_CONF_TAG=12 + NET_IPV4_CONF_TAG=12, + NET_IPV4_CONF_STRICT_INTERFACE_ARP=13 }; /* /proc/sys/net/ipv6 */ diff -Naur linux-2.4.2-2/net/ipv4/arp.c linux-2.4.2-2-strict_interface_arp/net/ipv4/arp.c --- linux-2.4.2-2/net/ipv4/arp.c Sat Sep 8 22:08:40 2001 +++ linux-2.4.2-2-strict_interface_arp/net/ipv4/arp.c Mon Sep 10 12:33:30 2001 @@ -314,16 +314,43 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb) { + u32 sip; + int onlink = 0; + struct in_device *in_dev = NULL; + u32 saddr; u8 *dst_ha = NULL; struct net_device *dev = neigh->dev; u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) - saddr = skb->nh.iph->saddr; - else + /* if strict_interface_arp then bind arp request saddr to the interface. i.e. saddr must + * be on dev where arp request is sent - pflau 06-29-2001 */ + if (skb) { + sip = skb->nh.iph->saddr; + in_dev = in_dev_get(dev); + + if (IN_DEV_STRICT_INTF_ARP(in_dev)) { + read_lock(&in_dev->lock); + for_ifa(in_dev) { + if ((onlink = !(sip ^ ifa->ifa_local)) != 0) + break; + } endfor_ifa(in_dev); + read_unlock(&in_dev->lock); + } else if (inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) + onlink = 1; + + if (in_dev) + in_dev_put(in_dev); + } + + + if (onlink) { + saddr = skb->nh.iph->saddr; + } else { saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); + } + if ((probes -= neigh->parms->ucast_probes) < 0) { if (!(neigh->nud_state&NUD_VALID)) @@ -571,6 +598,7 @@ int addr_type; struct in_device *in_dev = in_dev_get(dev); struct neighbour *n; + int onlink; /* * The hardware length of the packet should match the hardware length @@ -725,8 +753,21 @@ /* Special case: IPv4 duplicate address detection packet (RFC2131) */ if (sip == 0) { if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && - inet_addr_type(tip) == RTN_LOCAL) - arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr); + inet_addr_type(tip) == RTN_LOCAL) { + onlink = 0; + if (IN_DEV_STRICT_INTF_ARP(in_dev)) { + read_lock(&in_dev->lock); + for_ifa(in_dev) { + if ((onlink = !(tip ^ ifa->ifa_local)) != 0) + break; + } endfor_ifa(in_dev); + read_unlock(&in_dev->lock); + } else + onlink = 1; + + if (onlink) + arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr); + } goto out; } @@ -739,7 +780,22 @@ if (addr_type == RTN_LOCAL) { n = neigh_event_ns(&arp_tbl, sha, &sip, dev); if (n) { - arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha); + /* if strict_interface_arp then bind arp response to the interface. */ + /* reply only if tip is on dev where arp request is received - 2/5/2001 pflau */ + onlink = 0; + if (IN_DEV_STRICT_INTF_ARP(in_dev)) { + read_lock(&in_dev->lock); + for_ifa(in_dev) { + if ((onlink = !(tip ^ ifa->ifa_local)) != 0) + break; + } endfor_ifa(in_dev); + read_unlock(&in_dev->lock); + } else + onlink = 1; + + if (onlink) { + arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha); + } neigh_release(n); } goto out; diff -Naur linux-2.4.2-2/net/ipv4/devinet.c linux-2.4.2-2-strict_interface_arp/net/ipv4/devinet.c --- linux-2.4.2-2/net/ipv4/devinet.c Sat Sep 8 22:08:40 2001 +++ linux-2.4.2-2-strict_interface_arp/net/ipv4/devinet.c Mon Sep 10 12:33:30 2001 @@ -737,6 +737,7 @@ read_lock(&in_dev->lock); for_primary_ifa(in_dev) { if (ifa->ifa_scope != RT_SCOPE_LINK && + !IN_DEV_STRICT_INTF_ARP(in_dev) && ifa->ifa_scope <= scope) { read_unlock(&in_dev->lock); read_unlock(&inetdev_lock); @@ -1016,7 +1017,7 @@ static struct devinet_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table devinet_vars[13]; + ctl_table devinet_vars[14]; ctl_table devinet_dev[2]; ctl_table devinet_conf_dir[2]; ctl_table devinet_proto_dir[2]; @@ -1058,6 +1059,9 @@ &proc_dointvec}, {NET_IPV4_CONF_TAG, "tag", &ipv4_devconf.tag, sizeof(int), 0644, NULL, + &proc_dointvec}, + {NET_IPV4_CONF_TAG, "strict_interface_arp", + &ipv4_devconf.strict_interface_arp, sizeof(int), 0644, NULL, &proc_dointvec}, {0}}, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-netdev@oss.sgi.com Thu Sep 20 16:14:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KNETS06005 for netdev-outgoing; Thu, 20 Sep 2001 16:14:29 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KNERe06001 for ; Thu, 20 Sep 2001 16:14:27 -0700 Received: from localhost (IDENT:davem@pizda.ninka.net [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA26646; Thu, 20 Sep 2001 16:14:13 -0700 Date: Thu, 20 Sep 2001 16:14:12 -0700 (PDT) Message-Id: <20010920.161412.88343865.davem@redhat.com> To: ja@ssi.bg Cc: netdev@oss.sgi.com Subject: Re: Incorrect sch_ingress registration to NF From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 2.0 on Emacs 21.0 / 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: 707 Lines: 18 From: Julian Anastasov Date: Wed, 12 Sep 2001 12:46:57 +0300 (EEST) The diffserv guys know about this bug for already more than 2 months. What is going on, guys? I'm appending a modified version of the patch posted to diffserv list on June 24, from Doron Oz. It is against 2.4. In short, the ingress support should not register itself twice to netfilter. What is going on is that these fixes add more MODULE ifdefs, there shouldn't be any new MODULE ifdefs added to the kernel these days. I told Jamal (who first sent me this fix) to fixup the patch so that the MODULE ifdefs were all removed, but it slipped through the cracks. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu Sep 20 20:49:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8L3nxM10892 for netdev-outgoing; Thu, 20 Sep 2001 20:49:59 -0700 Received: from web11508.mail.yahoo.com (web11508.mail.yahoo.com [216.136.172.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8L3nve10889 for ; Thu, 20 Sep 2001 20:49:57 -0700 Message-ID: <20010921034957.80659.qmail@web11508.mail.yahoo.com> Received: from [24.112.158.2] by web11508.mail.yahoo.com via HTTP; Thu, 20 Sep 2001 20:49:57 PDT Date: Thu, 20 Sep 2001 20:49:57 -0700 (PDT) From: Guilhem Tardy Subject: linking network.o (ip_input.c, udp.c) with rtc_custom.o To: netdev@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1085 Lines: 30 Hi all, For those who followed my tribulations with the 3c59x.c driver, I can now get RTC timings of received packets directly in the payload (I must "insmod rtc_custom" before starting the 3c59x driver, though). Therefore, I am now able to measure time spent from the driver to the application (which uses an ioctl call to the same 'rtc_custom' module). I tried to use the same procedure inside the IP stack (in ip_input.c and udp.c): #include "/usr/src/linux/rtc_custom.h" (...) rtc_get_time(ptr); As you would expect, rtc_custom.h defines "extern void rtc_get_time(void *ptr);" and the function is found in rtc_custom.c This works well from the 3c59x driver, but strangely doesn't from the IP stack (the corresponding fields in the payload are set to 0x00000000). I sense that the 'rtc_custom' module should be loaded before the networking stack, any other idea? Thanks, Guilhem. __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From owner-netdev@oss.sgi.com Sat Sep 22 08:06:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8MF6YD13275 for netdev-outgoing; Sat, 22 Sep 2001 08:06:34 -0700 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8MF6Se13272 for ; Sat, 22 Sep 2001 08:06:28 -0700 Received: from brinquedo.distro.conectiva (1-241.ctame701-2.telepar.net.br [200.181.138.241]) by netbank.com.br (Postfix) with ESMTP id D8BED4683A; Sat, 22 Sep 2001 12:03:06 -0300 (BRST) Received: by brinquedo.distro.conectiva (Postfix, from userid 501) id 874D7C44B; Sat, 22 Sep 2001 12:06:23 -0300 (BRT) Date: Sat, 22 Sep 2001 12:06:23 -0300 From: Arnaldo Carvalho de Melo To: "J.Schulist" Cc: netdev@oss.sgi.com Subject: [acme@conectiva.com.br: some questions about struct sock] Message-ID: <20010922120623.B25990@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2307 Lines: 51 Jay/Andi, (humm, better send to netdev as well 8) ) I'm thinking about moving p8022_connection to sk->protinfo and make llc_connection_alloc become llc_sock_alloc, so that we can move some of the functionality to the struct sock and pass struct socks to the upper layers, in NetBEUI we have llc_handler in struct nb_link, humm, so a link in NetBEUI would be associated with a struct sock in 802.2, humm, then it demultiplexes into several struct socks for the NetBEUI sessions... care to think about this one with me? The idea is to make the two protocols use more of the infrastructure in Linux (tp_pinfo for NetBEUI, like spx does) so that maintainance of both become more possible for other net stacks hackers that will see more things in common with other net stacks, what do you think? It may well make the PF_LLC code you're working on more simpler... another goal for doing this is to use lock_sock/release_socks and friends the locking mechanism for most of the two stacks. If anybody is interested in how NetBEUI and 802.2 stacks development is going on and are willing to help, the patches are here: http://bazar.conectiva.com.br/~acme/patches/wip/netbeui+8022.patch.CURRENT for 2.4.9, based on the stacks PROCOM has released over a year ago as GPL. and http://bazar.conectiva.com.br/~acme/patches/wip/samba_netbeui.patch.CURRENT samba 2.0.6 based - Arnaldo ----- Forwarded message from Arnaldo Carvalho de Melo ----- > Date: Fri, 21 Sep 2001 14:07:13 -0300 > From: Arnaldo Carvalho de Melo > Subject: some questions about struct sock > To: Andi Kleen > X-Url: http://advogato.org/person/acme > > Hi Andi, > > Some questions about struct sock handling, have I got it right that > in TCP/IP a struct sock is shared by both the IP and TCP layers with IP > using sk->protinfo and TCP using sk->tp_pinfo? I want to know if this is > the right way to go as I want to do the same thing for 802.2 and NetBEUI, > so that I use the same locking techniques in net/ipv4. To do that I'll move > the p8022_connection in 802.2 to sk->protinfo and the struct nb_session and > struct netbeui_sock (that now is in sk->protinfo) to sk->tp_pinfo), is this > something that makes sense? > > Best Regards, > > - Arnaldo From owner-netdev@oss.sgi.com Sat Sep 22 16:18:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8MNIA319794 for netdev-outgoing; Sat, 22 Sep 2001 16:18:10 -0700 Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8MNI6e19791 for ; Sat, 22 Sep 2001 16:18:07 -0700 Received: from brinquedo.distro.conectiva (dhcp047.distro.conectiva [10.0.20.47]) by perninha.conectiva.com.br (Postfix) with ESMTP id 1960A38CDF for ; Sat, 22 Sep 2001 20:18:03 -0300 (EST) Received: by brinquedo.distro.conectiva (Postfix, from userid 501) id 34CE2C44B; Sat, 22 Sep 2001 20:18:00 -0300 (BRT) Date: Sat, 22 Sep 2001 20:18:00 -0300 From: Arnaldo Carvalho de Melo To: netdev@oss.sgi.com Subject: struct sock restructuring Message-ID: <20010922201759.B26166@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 629 Lines: 17 Is there any plan to do the restructuring of struct sock that is commented in include/net/sock.h? I'm now studying the net stacks to see what is the best way to have NetBEUI and 802.2 (or even IPX, SPX, etc) structured and the way struct sock is today is, humm, confusing :) I'm just curious if somebody is thinking about doing what the comment (who wrote it? 8) ) says. BTW, the comment starts with this and is located at line 433 of include/net/sock.h: /* * The idea is to start moving to a newer struct gradualy * * IMHO the newer struct should have the following format: - Arnaldo From owner-netdev@oss.sgi.com Mon Sep 24 09:33:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8OGX2503492 for netdev-outgoing; Mon, 24 Sep 2001 09:33:02 -0700 Received: from artos.cymry.org (IDENT:qmailr@artos.cymry.org [64.90.44.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8OGWte03487 for ; Mon, 24 Sep 2001 09:32:55 -0700 Received: (qmail 13461 invoked by uid 501); 24 Sep 2001 16:28:54 -0000 Date: Mon, 24 Sep 2001 11:28:52 -0500 From: Mark Bainter To: netdev@oss.sgi.com Subject: dri/card0 permissions / devfs + devfsd Message-ID: <20010924112852.D2634@firinn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-Operating-System: Linux 2.0.35 on a i586 X-PGP-Fingerprint: 55 B3 6F F7 61 30 BC 86 0B A2 C2 16 5D C9 77 4A Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1550 Lines: 40 I am using devfs (fully) and I'm running into a problem trying to get DRI working. I have tried everything I can think of, and no matter what when I start X the permissions look like this: crw-rw---- 1 root root 226, 0 Sep 24 10:25 card0 What's odd is I've had no trouble before this getting devfs perms working right. The sound card/etc all work fine. And when I run devfsd in trace mode I see this: Looking for "dri/card0" (0) update permissions for "dri/card0" from 20660 to 20666, user.group from 0.0 to -1.-1 Set permission 20666 on "dri/card0" Set user.group -1.-1 on "dri/card0" With a devfsd.conf that looks like: LOOKUP mixer MODLOAD LOOKUP audio MODLOAD LOOKUP dsp MODLOAD REGISTER mixer PERMISSIONS -1.-1 666 REGISTER dsp PERMISSIONS -1.-1 666 REGISTER agpgart PERMISSIONS -1.-1 666 REGISTER dri/.* PERMISSIONS -1.-1 666 agpgart works fine. As does mixer and dsp. And if I restart devfsd after starting X the permissions get set right on dri/card0 too. But of course, at that time it's too late. In case I was missing an event somewhere, I've gone through and tried each of the other events I thought relevent (lookup, create, and change) The first two had no effect, the third (obv) created a lot of load on my system but didn't help really. I also tried combinations of them together, which also didn't work. Any suggestions would be greatly appreciated. Oh yeah, and I'm running devfsd 1.3.18 and the 2.4.10 kernel. I've actually been working on this with 2.4.9 as well, with the same problem. From owner-netdev@oss.sgi.com Tue Sep 25 10:47:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8PHlWH30397 for netdev-outgoing; Tue, 25 Sep 2001 10:47:32 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8PHlTD30394 for ; Tue, 25 Sep 2001 10:47:30 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA05804; Tue, 25 Sep 2001 21:46:53 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200109251746.VAA05804@ms2.inr.ac.ru> Subject: Re: struct sock restructuring To: acme@conectiva.COM.BR (Arnaldo Carvalho de Melo) Date: Tue, 25 Sep 2001 21:46:53 +0400 (MSK DST) Cc: netdev@oss.sgi.com In-Reply-To: <20010922201759.B26166@conectiva.com.br> from "Arnaldo Carvalho de Melo" at Sep 23, 1 03:45:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 362 Lines: 14 Hello! > Is there any plan to do the restructuring of struct sock that is commented > in include/net/sock.h? Why "plan"? It is complete. > * IMHO the newer struct should have the following format: It does have. Only the thing called "net_pinfo" in the comment preserved its traditional name "protinfo" and "ll_pinfo" did not find any applications. Alexey From owner-netdev@oss.sgi.com Wed Sep 26 06:47:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QDlJg21050 for netdev-outgoing; Wed, 26 Sep 2001 06:47:19 -0700 Received: from web11501.mail.yahoo.com (web11501.mail.yahoo.com [216.136.172.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QDlGD21047 for ; Wed, 26 Sep 2001 06:47:16 -0700 Message-ID: <20010926134716.68101.qmail@web11501.mail.yahoo.com> Received: from [134.22.47.55] by web11501.mail.yahoo.com via HTTP; Wed, 26 Sep 2001 06:47:16 PDT Date: Wed, 26 Sep 2001 06:47:16 -0700 (PDT) From: Guilhem Tardy Subject: timing results To: netdev@oss.sgi.com In-Reply-To: <3BA68DCA.F0A2A7D@candelatech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1495 Lines: 34 Hi all, I am done with those measurements, and the results are (average of 50 UDP packets of 500 bytes, in bunch of 3 every 50 ms, the PC running X but no other particularly demanding application): from stage 0 to 1: 5.97 msec [eth driver to IP_input] from stage 1 to 2: 1.26 msec [IP_input] from stage 2 to 3: 1.75 msec [IP_input to UDP] from stage 3 to 4: 12.83 msec [UDP to application] --- Total: 21.75 ms I have seen variations in those numbers, for example stage 3 to 4 taking over 50 ms in another instance of the test. I may rerun another quick test for capturing maximum values (and variance?) at a later stage when I compare it to a real-time patched kernel, probably for next week. Technical detail of my implementation are: * storing the 32 lower bits of the CPU clock register found in timex.h (this is x586 specific and provides less than a usec precision without any particular performance hit) in each UDP packets received on a particular port (hard coded in the 3c59x.c, ip_input.c and udp.c) * 'sleep(1)' and a custom rtc interrupt handler (from Rene) used by the application to calibrate the number of CPU clock register ticks per second I will package and release the whole code to anyone interested. Thanks to all for your help and suggestions. I learnt quite a lot in doing that. Guilhem. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com From owner-netdev@oss.sgi.com Wed Sep 26 10:13:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QHDS825422 for netdev-outgoing; Wed, 26 Sep 2001 10:13:28 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QHCkD25418 for ; Wed, 26 Sep 2001 10:12:46 -0700 Received: from dea.linux-mips.net (u-210-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.210]) 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 KAA05044 for ; Wed, 26 Sep 2001 10:12:18 -0700 (PDT) mail_from (ralf@linux-mips.net) Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f8QGp5M28266 for netdev@oss.sgi.com; Wed, 26 Sep 2001 18:51:05 +0200 Received: from grok.yi.org (IDENT:root@cx97923-a.phnx3.az.home.com [24.9.112.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QFkaD23874 for ; Wed, 26 Sep 2001 08:46:37 -0700 Received: from candelatech.com (IDENT:greear@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.2/8.11.2) with ESMTP id f8QFkWT07041; Wed, 26 Sep 2001 08:46:32 -0700 Message-ID: <3BB1F858.51748064@candelatech.com> Date: Wed, 26 Sep 2001 08:46:32 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686) X-Accept-Language: en MIME-Version: 1.0 To: Guilhem Tardy CC: netdev@oss.sgi.com Subject: Re: timing results References: <20010926134716.68101.qmail@web11501.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2229 Lines: 54 Hrm, my tests, where I use mili-second timers in data sent from userspace shows that I can run 100Mbps of TCP, UDP, and custom Ethernet traffic with less than 1 milisecond of latency. And that is end-to-end (user-space to user-space). This is 100Mbps tx and 100Mbps rx at the same time, too... Maybe you don't mean miliseconds?? ping also shows about .3ms for round-trip on normal fast-ethernet and modern computers.... Ben Guilhem Tardy wrote: > > Hi all, > > I am done with those measurements, and the results are (average of 50 UDP > packets of 500 bytes, in bunch of 3 every 50 ms, the PC running X but no other > particularly demanding application): > from stage 0 to 1: 5.97 msec [eth driver to IP_input] > from stage 1 to 2: 1.26 msec [IP_input] > from stage 2 to 3: 1.75 msec [IP_input to UDP] > from stage 3 to 4: 12.83 msec [UDP to application] > --- > Total: 21.75 ms > > I have seen variations in those numbers, for example stage 3 to 4 taking over > 50 ms in another instance of the test. I may rerun another quick test for > capturing maximum values (and variance?) at a later stage when I compare it to > a real-time patched kernel, probably for next week. > > Technical detail of my implementation are: > * storing the 32 lower bits of the CPU clock register found in timex.h (this > is x586 specific and provides less than a usec precision without any particular > performance hit) in each UDP packets received on a particular port (hard coded > in the 3c59x.c, ip_input.c and udp.c) > * 'sleep(1)' and a custom rtc interrupt handler (from Rene) used by the > application to calibrate the number of CPU clock register ticks per second > > I will package and release the whole code to anyone interested. Thanks to all > for your help and suggestions. I learnt quite a lot in doing that. > > Guilhem. > > __________________________________________________ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Wed Sep 26 13:07:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QK7Ci29041 for netdev-outgoing; Wed, 26 Sep 2001 13:07:12 -0700 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QK73D29038 for ; Wed, 26 Sep 2001 13:07:05 -0700 Received: by chiara.elte.hu (Postfix, from userid 17806) id D5BCB1FCE; Wed, 26 Sep 2001 22:06:55 +0200 (CEST) Date: Wed, 26 Sep 2001 22:04:33 +0200 (CEST) From: Ingo Molnar Reply-To: To: Cc: , Subject: [patch] netconsole - log kernel messages over the network. 2.4.10. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2484 Lines: 64 this is the first public release of the 'netconsole patch', a debugging patch that implements kernel-level network logging via UDP packets. the special thing about this approach is the ability to send 'emergency' network packets even from IRQ handlers. This enables the netconsole to send enough info even if we crash in init or in an interrupt handler. another property of netconsole is that it's able to share the networking device with other kernel subsystems, like the TCP/IP stack. So the networking device is not dedicated for netconsole use, it's transparently shared. netconsole is also designed to be robust, it goes straight to the network driver, so it does not depend on the networking stack to log messages. kernel-level netlogging is useful in a number of scenarios: - if remotely managed systems with no serial cable logging keep crashing without any trace of an oops message in the userspace log. (the patch was written to debug such a crash. Original idea of sending an emergency packet from IRQ handlers comes from Daniel Veillard who's system produced the crash - thanks Daniel!) - if for whatever reason the amount of logging is so high that a serial console cannot hold it and disks can not keep up - or in cases where logged messages disturb the debugged subsystem. I'm sure fellow VM hackers will find this useful :-) - the netconsole can be used to emit crashdumps over the network, without any delay between the point of crash and start of netlogging. the kernel patch (against 2.4.10 or 2.4.9-ac), and a simple user-space tool to display netconsole messages can be found at: http://redhat.com/~mingo/netconsole-patches/ sample startup of the netconsole on the server: insmod netconsole dev=eth1 target_ip=0x0a000701 \ source_port=6666 \ target_port=6666 \ target_eth_byte0=0x00 \ target_eth_byte1=0x90\ target_eth_byte2=0x27 \ target_eth_byte3=0x8C \ target_eth_byte4=0xA0 \ target_eth_byte5=0xA8 and on the client: # ./netconsole-client -server 10.0.7.5 -client 10.0.7.1 -port 6666 [...network console startup...] netconsole: network logging started up successfully! SysRq : Loglevel set to 9 more about features and limitations can be found under: Documentation/networking/netlogging.txt reports, comments, suggestions welcome. Ingo From owner-netdev@oss.sgi.com Wed Sep 26 13:47:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QKlVt30180 for netdev-outgoing; Wed, 26 Sep 2001 13:47:31 -0700 Received: from mail.SerNet.DE (exim@mail.SerNet.DE [193.159.217.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QKlRD30177 for ; Wed, 26 Sep 2001 13:47:27 -0700 Received: from news by mail.SerNet.DE with local (Exim 2.12 #1) for netdev@oss.sgi.com id 15mLaX-0003od-00; Wed, 26 Sep 2001 22:47:25 +0200 To: netdev@oss.sgi.com Path: not-for-mail From: Lutz Pressler Newsgroups: lists.linux.netdev Subject: Re: "ip": listing of proxy ARP entries? Date: 26 Sep 2001 20:47:25 GMT Organization: Service Network GmbH, Goettingen, Germany Message-ID: <9otest$cjo$1@server1.GoeNet.DE> References: <3B9CD03A.EBD40915@nortelnetworks.com> NNTP-Posting-Host: gabi.sernet.de X-Trace: server1.GoeNet.DE 1001537245 12920 193.159.216.39 (26 Sep 2001 20:47:25 GMT) X-Complaints-To: news@news.SerNet.DE NNTP-Posting-Date: 26 Sep 2001 20:47:25 GMT Cc: kuznet@ms2.inr.ac.ru User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.19 (i686)) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1248 Lines: 38 Some time ago I wrote, "Christopher Friesen" wrote: > Lutz Pressler wrote: >> >> I am not able to get information about manually set proxy ARP entries >> with the "ip" tool (iproute2-ss010824), tested on both 2.2.19 and >> 2.4.8-ac7 kernels. >> >> # ip neigh add proxy 172.20.1.1 dev eth0 >> >> The "arp" tool then yields (normal entries trimmed) >> # arp -n >> Address HWtype HWaddress Flags Mask Iface >> 192.168.1.254 ether 00:80:C8:F6:47:6F C eth0 >> 172.20.1.1 * * MP eth0 >> >> but "ip" only shows >> # ip neigh show >> 192.168.1.254 dev eth0 lladdr 00:80:c8:f6:47:6f nud reachable >> >> Is this expected behaviour or a (kernel) bug? > I'd like to know about this as well, since this is the only reason why I keep > the "arp" command around. Nobody having any opinion about this? :) Thanks, Lutz Cc: Alexey Kuznetsov -- _ | Lutz Pressler | Tel: ++49-551-3700002 |_ |\ | | Service Network GmbH | FAX: ++49-551-3700009 ._|ER | \|ET | Bahnhofsallee 1b | mailto:lp@SerNet.DE Service Network | D-37081 Goettingen | http://www.SerNet.DE/ From owner-netdev@oss.sgi.com Wed Sep 26 14:00:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QL05m30482 for netdev-outgoing; Wed, 26 Sep 2001 14:00:05 -0700 Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QKxsD30443 for ; Wed, 26 Sep 2001 13:59:55 -0700 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (Postfix) with ESMTP id B371138D12; Wed, 26 Sep 2001 17:59:25 -0300 (EST) Date: Wed, 26 Sep 2001 16:36:20 -0300 (BRT) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Ingo Molnar Cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [patch] netconsole - log kernel messages over the network. 2.4.10. 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: 3123 Lines: 82 Ingo, Don't you think it would be useful to have some reserved memory for the netconsole use ? It would be nice to have a guarantee that messages are sent over network even if the system is under real OOM. On Wed, 26 Sep 2001, Ingo Molnar wrote: > > this is the first public release of the 'netconsole patch', a debugging > patch that implements kernel-level network logging via UDP packets. > > the special thing about this approach is the ability to send 'emergency' > network packets even from IRQ handlers. This enables the netconsole to > send enough info even if we crash in init or in an interrupt handler. > > another property of netconsole is that it's able to share the networking > device with other kernel subsystems, like the TCP/IP stack. So the > networking device is not dedicated for netconsole use, it's transparently > shared. > > netconsole is also designed to be robust, it goes straight to the network > driver, so it does not depend on the networking stack to log messages. > > kernel-level netlogging is useful in a number of scenarios: > > - if remotely managed systems with no serial cable logging keep crashing > without any trace of an oops message in the userspace log. (the patch > was written to debug such a crash. Original idea of sending an > emergency packet from IRQ handlers comes from Daniel Veillard who's > system produced the crash - thanks Daniel!) > > - if for whatever reason the amount of logging is so high that a serial > console cannot hold it and disks can not keep up - or in cases where > logged messages disturb the debugged subsystem. I'm sure fellow VM > hackers will find this useful :-) > > - the netconsole can be used to emit crashdumps over the network, without > any delay between the point of crash and start of netlogging. > > the kernel patch (against 2.4.10 or 2.4.9-ac), and a simple user-space > tool to display netconsole messages can be found at: > > http://redhat.com/~mingo/netconsole-patches/ > > sample startup of the netconsole on the server: > > insmod netconsole dev=eth1 target_ip=0x0a000701 \ > source_port=6666 \ > target_port=6666 \ > target_eth_byte0=0x00 \ > target_eth_byte1=0x90\ > target_eth_byte2=0x27 \ > target_eth_byte3=0x8C \ > target_eth_byte4=0xA0 \ > target_eth_byte5=0xA8 > > and on the client: > > # ./netconsole-client -server 10.0.7.5 -client 10.0.7.1 -port 6666 > [...network console startup...] > netconsole: network logging started up successfully! > SysRq : Loglevel set to 9 > > more about features and limitations can be found under: > > Documentation/networking/netlogging.txt > > reports, comments, suggestions welcome. > > Ingo > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From owner-netdev@oss.sgi.com Wed Sep 26 14:18:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QLIf231080 for netdev-outgoing; Wed, 26 Sep 2001 14:18:41 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QLIdD31077 for ; Wed, 26 Sep 2001 14:18:40 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id RAA06830; Wed, 26 Sep 2001 17:15:40 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 26 Sep 2001 17:15:40 -0400 (EDT) From: jamal To: Ingo Molnar cc: , , Subject: Re: [patch] netconsole - log kernel messages over the network. 2.4.10. 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: 149 Lines: 8 Is there any reason you are not using dev_queue_xmit()? (side benefits, you could hack this into using scatter gather schemes etc) cheers, jamal From owner-netdev@oss.sgi.com Wed Sep 26 14:29:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QLTcF31385 for netdev-outgoing; Wed, 26 Sep 2001 14:29:38 -0700 Received: from webber.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QLTYD31381 for ; Wed, 26 Sep 2001 14:29:34 -0700 Received: from webber.adilger.int (adilger@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id f8QLT9mK001836; Wed, 26 Sep 2001 15:29:09 -0600 Received: (from adilger@localhost) by webber.adilger.int (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) id f8QLT947001834; Wed, 26 Sep 2001 15:29:09 -0600 From: Andreas Dilger Date: Wed, 26 Sep 2001 15:29:09 -0600 To: Ingo Molnar Cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [patch] netconsole - log kernel messages over the network. 2.4.10. Message-ID: <20010926152909.D1140@turbolinux.com> Mail-Followup-To: Ingo Molnar , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1695 Lines: 42 On Wed, 26 Sep 2001, Ingo Molnar wrote: > sample startup of the netconsole on the server: > > insmod netconsole dev=eth1 target_ip=0x0a000701 \ > source_port=6666 \ > target_port=6666 \ > target_eth_byte0=0x00 \ > target_eth_byte1=0x90\ > target_eth_byte2=0x27 \ > target_eth_byte3=0x8C \ > target_eth_byte4=0xA0 \ > target_eth_byte5=0xA8 Ugh. Maybe a wrapper script (netconsole-server) which automates this is in order? I imagine the eth_byteX is a MAC address (or at least that this is in the documentation)? > > and on the client: > > > > # ./netconsole-client -server 10.0.7.5 -client 10.0.7.1 -port 6666 > > [...network console startup...] > > netconsole: network logging started up successfully! > > SysRq : Loglevel set to 9 Any chance the netconsole-client can be set up to listen for multiple hosts and log to the local syslog? This would allow you to run netconsole-client on your normal syslog host and add timestamps, clean up old logs, etc. I take it that this is only a one-way interface (i.e. logs sent from the server to the client), and not a real serial-console replacement? In any case, this will be EXTREMELY useful for me, as a lot of new machines do not have serial ports and are a PITA to debug in case of a crash. Thanks. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert From owner-netdev@oss.sgi.com Wed Sep 26 14:49:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QLna631898 for netdev-outgoing; Wed, 26 Sep 2001 14:49:36 -0700 Received: from web11502.mail.yahoo.com (web11502.mail.yahoo.com [216.136.172.47]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QLnPD31892 for ; Wed, 26 Sep 2001 14:49:25 -0700 Message-ID: <20010926214925.7742.qmail@web11502.mail.yahoo.com> Received: from [134.22.47.55] by web11502.mail.yahoo.com via HTTP; Wed, 26 Sep 2001 14:49:25 PDT Date: Wed, 26 Sep 2001 14:49:25 -0700 (PDT) From: Guilhem Tardy Subject: Re: timing results To: Ben Greear Cc: netdev@oss.sgi.com In-Reply-To: <3BB1F858.51748064@candelatech.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-729451506-1001540965=:5122" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 8668 Lines: 158 --0-729451506-1001540965=:5122 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Hrm, my tests, where I use mili-second timers in data sent > from userspace shows that I can run 100Mbps of TCP, UDP, > and custom Ethernet traffic with less than 1 milisecond of > latency. And that is end-to-end (user-space to user-space). > This is 100Mbps tx and 100Mbps rx at the same time, too... > > Maybe you don't mean miliseconds?? > > ping also shows about .3ms for round-trip on normal fast-ethernet > and modern computers.... > > Ben I run over a 100Mbps ethernet card from 3COM (hence the 3c59x.c driver), and stand by my measurements in microseconds. Yeah, you're right this was microseconds (sorry for the heart attack ;). Really, this can go as low as 19 usec and as high as 1300+ usec for the total. I included the application that receives and sinks the UDP traffic for your consideration. One thing puzzles me: my calibration results in either 350 or 800 megaticks per second, changing from time to time on the same setup. Would you think of an explanation for that? Guilhem. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com --0-729451506-1001540965=:5122 Content-Type: application/x-unknown; name="measure_udp_traffic.c" Content-Transfer-Encoding: base64 Content-Description: measure_udp_traffic.c Content-Disposition: attachment; filename="measure_udp_traffic.c" I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3NvY2tldC5o PgojaW5jbHVkZSA8c3lzL3N0YXQuaD4KI2luY2x1ZGUgPGZjbnRsLmg+CiNp bmNsdWRlIDxzeXMvaW9jdGwuaD4KI2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5j bHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgojaW5jbHVkZSA8 dmFsdWVzLmg+CiNpbmNsdWRlIDxlcnJuby5oPgojaW5jbHVkZSA8bmV0aW5l dC9pbi5oPgojaW5jbHVkZSA8bmV0aW5ldC9pcC5oPgojaW5jbHVkZSA8bmV0 aW5ldC91ZHAuaD4KCiNpbmNsdWRlIDxsaW51eC9ydGNfY3VzdG9tLmg+CiNp bmNsdWRlIDxsaW51eC9pNTg2X3RpY2tzLmg+CgojZGVmaW5lIEJVRlNJWkUg MTUwMAojZGVmaW5lIHRpY2tzX3RvX21zZWMoc3RhcnQsZW5kLHJhdGlvKQko KDEwMDAqKChmbG9hdCkgKChlbmQpPihzdGFydCk/KGVuZCktKHN0YXJ0KToo c3RhcnQpLShlbmQpKSkpL3JhdGlvKQoKaW50IG1haW4oaW50IGFyZ19jLCBj aGFyICoqYXJnX3YpIHsKICBpbnQgcnRjZmQsIHNvY2tmZCwgcGNrbGVuLCBw b3J0ID0gNjk2OTsKICB1bnNpZ25lZCBpbnQgbnBjayA9IDAsIG1heHBjayA9 IDU7CiAgX191aW50MzJfdCBzdGFydF90aWNrcywgZW5kX3RpY2tzLCBudGlj a3MsIHN0YXJ0X3J0YywgZW5kX3J0YywgKnZwdHI7CiAgZmxvYXQgbnRpY2tz X3Blcl9zZWM7CiAgZmxvYXQgbXNlYzAxLCBtc2VjMTIsIG1zZWMyMywgbXNl YzM0OwogIGZsb2F0IG1pbl9tc2VjMDEgPSBNQVhGTE9BVCwgbWluX21zZWMx MiA9IE1BWEZMT0FULCBtaW5fbXNlYzIzID0gTUFYRkxPQVQsIG1pbl9tc2Vj MzQgPSBNQVhGTE9BVDsKICBmbG9hdCBtYXhfbXNlYzAxID0gTUlORkxPQVQs IG1heF9tc2VjMTIgPSBNSU5GTE9BVCwgbWF4X21zZWMyMyA9IE1JTkZMT0FU LCBtYXhfbXNlYzM0ID0gTUlORkxPQVQ7CiAgZmxvYXQgc3VtX21zZWMwMSA9 IDAsIHN1bV9tc2VjMTIgPSAwLCBzdW1fbXNlYzIzID0gMCwgc3VtX21zZWMz NCA9IDA7CiAgc3RydWN0IHNvY2thZGRyX2luIGJpbmRQb3J0LCBzaW47CiAg aW50IHNpbmxlbiA9IHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfaW4pOwogIHVu c2lnbmVkIGNoYXIgcGFja2V0W0JVRlNJWkVdOwogIHN0cnVjdCBpcGhkciAq aGRyOwogIHN0cnVjdCB1ZHBoZHIgKnVoZHI7CgogIGlmIChhcmdfYz4xKSB7 CiAgICBpZiAoMSAhPSBzc2NhbmYoYXJnX3ZbMV0sICIlZCIsICZwb3J0KSkg ewogICAgICBwcmludGYoImVycm9yIHNzY2FuZihhcmdfdlsxXSkiKTsKICAg ICAgZXhpdCgtMSk7CiAgICB9CiAgfQoKICBpZiAoYXJnX2M+MikgewogICAg aWYgKDEgIT0gc3NjYW5mKGFyZ192WzJdLCAiJXUiLCAmbWF4cGNrKSkgewog ICAgICBwcmludGYoImVycm9yIHNzY2FuZihhcmdfdlsyXSkiKTsKICAgICAg ZXhpdCgtMSk7CiAgICB9CiAgfQoKICBwcmludGYoInVzYWdlOiBtZWFzdXJl X3VkcF90cmFmZmljIFtwb3J0XSBbI3BhY2tldHNdXG4iKTsKICBwcmludGYo ImJ1ZzogY2FsY3VsYXRpb25zIGluIDMyIGJpdHMsIHBvc3NpYmxlIG92ZXJm bG93ISEhXG5cbiIpOwogIHByaW50ZigicmVjb3JkaW5nIHBhY2tldHMgb24g cG9ydCAlZCB1bnRpbCAldSByZWNlaXZlZC4uLlxuIixwb3J0LG1heHBjayk7 CgogIGlmICgocnRjZmQgPSBvcGVuKCIvZGV2L3J0Y19jdXN0b20iLCBPX1JE V1IsIDApKSA9PSAtMSkgewogICAgcHJpbnRmKCJlcnJvciBvcGVuKHJ0Yyki KTsKICAgIGV4aXQoLTEpOwogIH0KCiAgcHJpbnRmKCJDb25maWd1cmluZyB0 aGUgY2xvY2suLi5cbiIpOwogIGlmICgtMSA9PSBpb2N0bChydGNmZCwgMSwg JnN0YXJ0X3J0YykpIHsKICAgIHByaW50ZigiZXJyb3IgaW9jdGwoKTogJWQg KG9mIEVCQURGICVkLCBFRkFVTFQgJWQsIEVOT1RUWSAlZCwgRUlOVkFMICVk KSIsIGVycm5vLCBFQkFERiwgRUZBVUxULCBFTk9UVFksIEVJTlZBTCk7CiAg ICBleGl0KC0xKTsKICB9CiAgc3RhcnRfdGlja3MgPSBnZXRfaTU4Nl90aWNr cygpOwogIHNsZWVwKDEpOwogIGlmICgtMSA9PSBpb2N0bChydGNmZCwgMSwg JmVuZF9ydGMpKSB7CiAgICBwcmludGYoImVycm9yIGlvY3RsKCk6ICVkIChv ZiBFQkFERiAlZCwgRUZBVUxUICVkLCBFTk9UVFkgJWQsIEVJTlZBTCAlZCki LCBlcnJubywgRUJBREYsIEVGQVVMVCwgRU5PVFRZLCBFSU5WQUwpOwogICAg ZXhpdCgtMSk7CiAgfQogIGVuZF90aWNrcyA9IGdldF9pNTg2X3RpY2tzKCk7 CiAgbnRpY2tzID0gKGVuZF90aWNrcyA+IHN0YXJ0X3RpY2tzP2VuZF90aWNr cyAtIHN0YXJ0X3RpY2tzOnN0YXJ0X3RpY2tzIC0gZW5kX3RpY2tzKTsKICBu dGlja3NfcGVyX3NlYyA9ICgoKGZsb2F0KSBudGlja3MpLyhlbmRfcnRjIC0g c3RhcnRfcnRjKSkgKiBSVENfSFo7CiAgcHJpbnRmKCJudGlja3MgcGVyIHNl Y29uZDogKCV1IC8gJXUpICogJXUgPSAlLjJmXG4iLCBudGlja3MsIGVuZF9y dGMgLSBzdGFydF9ydGMsIFJUQ19IWiwgbnRpY2tzX3Blcl9zZWMpOwoKICBp ZiAoKHNvY2tmZCA9IHNvY2tldChBRl9JTkVULCBTT0NLX1JBVywgSVBQUk9U T19VRFApKSA9PSAtMSkgewogICAgcHJpbnRmKCJlcnJvciBzb2NrZXQoKSIp OwogICAgZXhpdCgtMSk7CiAgfQoKICBiaW5kUG9ydC5zaW5fZmFtaWx5PUFG X0lORVQ7CiAgYmluZFBvcnQuc2luX3BvcnQ9aHRvbnMocG9ydCk7CiAgYmlu ZFBvcnQuc2luX2FkZHIuc19hZGRyPTA7CgogIGlmICgtMSA9PSBiaW5kKHNv Y2tmZCwgJmJpbmRQb3J0LCBzaXplb2Yoc3RydWN0IHNvY2thZGRyX2luKSkp IHsKICAgIHByaW50ZigiZXJyb3IgYmluZCgpIik7CiAgICBleGl0KC0xKTsK ICB9CgogIHdoaWxlIChucGNrPG1heHBjaykgewogICAgaWYgKChwY2tsZW4g PSByZWN2ZnJvbShzb2NrZmQsIHBhY2tldCwgQlVGU0laRSwgMCwgJnNpbiwg JnNpbmxlbikpID09IC0xKSB7CiAgICAgIHByaW50ZigiZXJyb3IgcmVjdmZy b20oKSIpOwogICAgICBleGl0KC0xKTsKICAgIH0KCiAgICBlbmRfdGlja3Mg PSBnZXRfaTU4Nl90aWNrcygpOwoKICAgIGhkciA9IChzdHJ1Y3QgaXBoZHIq KSBwYWNrZXQ7CiAgICB1aGRyID0gKHN0cnVjdCB1ZHBoZHIqKSAocGFja2V0 ICsgKGhkci0+aWhsKjQpKTsKCiAgICBpZiAobnRvaHModWhkci0+ZGVzdCkg IT0gcG9ydCkKICAgICAgY29udGludWU7CgogICAgLy8gcHJpbnRmKCJwcm90 OiAldSwgaGRybGVuOiAldSwgZHBvcnQ6ICV1LCB1ZHBsZW46ICV1XG4iLCBo ZHItPnByb3RvY29sLCBoZHItPmlobCo0LCBudG9ocyh1aGRyLT5kZXN0KSwg bnRvaHModWhkci0+bGVuKSk7CgovKiBDdXJyZW50IGZpZWxkcyBpbiB0aGUg VURQIHBheWxvYWQ6CgkJCTNjNTl4CWlwX2lucHV0CXVkcAoJcnRjX2dldF90 aW1lCVswXQoJaTU4Nl90aWNrcwlbMV0JWzJdIFszXQkJWzRdCiovCgogICAg dnB0ciA9IChfX3VpbnQzMl90ICopICh1aGRyICsgMSk7CgogICAgbXNlYzAx PXRpY2tzX3RvX21zZWMoKih2cHRyKzEpLCoodnB0cisyKSxudGlja3NfcGVy X3NlYyk7CiAgICBtc2VjMTI9dGlja3NfdG9fbXNlYygqKHZwdHIrMiksKih2 cHRyKzMpLG50aWNrc19wZXJfc2VjKTsKICAgIG1zZWMyMz10aWNrc190b19t c2VjKCoodnB0ciszKSwqKHZwdHIrNCksbnRpY2tzX3Blcl9zZWMpOwogICAg bXNlYzM0PXRpY2tzX3RvX21zZWMoKih2cHRyKzQpLGVuZF90aWNrcyxudGlj a3NfcGVyX3NlYyk7CgovKgogICAgcHJpbnRmKCIwOiAldSAtLT4gMTogJXUg KCUuMmYgbXNlYykiLCAqKHZwdHIrMSksICoodnB0cisyKSwgbXNlYzAxKTsK ICAgIHByaW50ZigiIC0tPiAyOiAldSAoJS4yZiBtc2VjKSIsICoodnB0cisz KSwgbXNlYzEyKTsKICAgIHByaW50ZigiIC0tPiAzOiAldSAoJS4yZiBtc2Vj KSIsICoodnB0cis0KSwgbXNlYzIzKTsKICAgIHByaW50ZigiIC0tPiA0OiAl dSAoJS4yZiBtc2VjKVxuIiwgKF9fdWludDMyX3QpIGVuZF90aWNrcywgbXNl YzM0KTsKKi8KCiAgICBpZiAobXNlYzAxIDwgbWluX21zZWMwMSkgbWluX21z ZWMwMSA9IG1zZWMwMTsKICAgIGlmIChtc2VjMDEgPiBtYXhfbXNlYzAxKSBt YXhfbXNlYzAxID0gbXNlYzAxOwogICAgc3VtX21zZWMwMSArPSBtc2VjMDE7 CiAgICBpZiAobXNlYzEyIDwgbWluX21zZWMxMikgbWluX21zZWMxMiA9IG1z ZWMxMjsKICAgIGlmIChtc2VjMTIgPiBtYXhfbXNlYzEyKSBtYXhfbXNlYzEy ID0gbXNlYzEyOwogICAgc3VtX21zZWMxMiArPSBtc2VjMTI7CiAgICBpZiAo bXNlYzIzIDwgbWluX21zZWMyMykgbWluX21zZWMyMyA9IG1zZWMyMzsKICAg IGlmIChtc2VjMjMgPiBtYXhfbXNlYzIzKSBtYXhfbXNlYzIzID0gbXNlYzIz OwogICAgc3VtX21zZWMyMyArPSBtc2VjMjM7CiAgICBpZiAobXNlYzM0IDwg bWluX21zZWMzNCkgbWluX21zZWMzNCA9IG1zZWMzNDsKICAgIGlmIChtc2Vj MzQgPiBtYXhfbXNlYzM0KSBtYXhfbXNlYzM0ID0gbXNlYzM0OwogICAgc3Vt X21zZWMzNCArPSBtc2VjMzQ7CgogICAgbnBjaysrOwogIH0KCiAgcHJpbnRm KCJcbnJlc3VsdHMgYXZlcmFnZWQgb24gJXUgcGFja2V0OlxuIiwgbnBjayk7 CiAgcHJpbnRmKCIgIGZyb20gc3RhZ2UgMCB0byAxOiAlLjNmIG1zZWMgeyUu M2YsICUuM2Z9XG4iLCBzdW1fbXNlYzAxL25wY2ssIG1pbl9tc2VjMDEsIG1h eF9tc2VjMDEpOwogIHByaW50ZigiICBmcm9tIHN0YWdlIDEgdG8gMjogJS4z ZiBtc2VjIHslLjNmLCAlLjNmfVxuIiwgc3VtX21zZWMxMi9ucGNrLCBtaW5f bXNlYzEyLCBtYXhfbXNlYzEyKTsKICBwcmludGYoIiAgZnJvbSBzdGFnZSAy IHRvIDM6ICUuM2YgbXNlYyB7JS4zZiwgJS4zZn1cbiIsIHN1bV9tc2VjMjMv bnBjaywgbWluX21zZWMyMywgbWF4X21zZWMyMyk7CiAgcHJpbnRmKCIgIGZy b20gc3RhZ2UgMyB0byA0OiAlLjNmIG1zZWMgeyUuM2YsICUuM2Z9XG4iLCBz dW1fbXNlYzM0L25wY2ssIG1pbl9tc2VjMzQsIG1heF9tc2VjMzQpOwoKICBw cmludGYoIlxuICBUT1RBTDogJS4zZiBtc2VjIHslLjNmLCAlLjNmfVxuIiwg KHN1bV9tc2VjMDErc3VtX21zZWMxMitzdW1fbXNlYzIzK3N1bV9tc2VjMzQp L25wY2ssIG1pbl9tc2VjMDErbWluX21zZWMxMittaW5fbXNlYzIzK21pbl9t c2VjMzQsIG1heF9tc2VjMDErbWF4X21zZWMxMittYXhfbXNlYzIzK21heF9t c2VjMzQpOwoKICBjbG9zZShzb2NrZmQpOwogIGNsb3NlKHJ0Y2ZkKTsKICBy ZXR1cm4gMDsKfQoKLyogZ2NjIC1JIC91c3Ivc3JjL2xpbnV4L2luY2x1ZGUg LVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtTzYgbWVhc3VyZV91ZHBfdHJh ZmZpYy5jIC1vIG1lYXN1cmVfdWRwX3RyYWZmaWMgKi8K --0-729451506-1001540965=:5122-- From owner-netdev@oss.sgi.com Wed Sep 26 15:01:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QM19b32171 for netdev-outgoing; Wed, 26 Sep 2001 15:01:09 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QM16D32168 for ; Wed, 26 Sep 2001 15:01:06 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id RAA06943; Wed, 26 Sep 2001 17:58:08 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 26 Sep 2001 17:58:08 -0400 (EDT) From: jamal To: "David S. Miller" cc: , Subject: Re: Incorrect sch_ingress registration to NF In-Reply-To: <20010920.161412.88343865.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1474 Lines: 40 Dave, That email got lost in the shuffle. Apologies. I cant think of any clever way that wont have a cost to it. One way could be just to get rid of the new define in the patch (means modules will have this extra static variable they dont use). OTOH, we could fix this from netfilter. I remember discussing this with Harald and sending him a small patchlet. I hope he's on the list. The check if (nf_register_hook(&ing_ops) < 0) is basically useless. The return is always succesful. Adding the same hook twice does not make any semantic sense in netfilter and as can be seen creates a oops. If nf_register_hook() returns something like -EREGISTERED life would be good. cheers, jamal On Thu, 20 Sep 2001, David S. Miller wrote: > From: Julian Anastasov > Date: Wed, 12 Sep 2001 12:46:57 +0300 (EEST) > > The diffserv guys know about this bug for already more than > 2 months. What is going on, guys? I'm appending a modified version of > the patch posted to diffserv list on June 24, from Doron Oz. It is against > 2.4. In short, the ingress support should not register itself twice to > netfilter. > > What is going on is that these fixes add more MODULE ifdefs, there > shouldn't be any new MODULE ifdefs added to the kernel these days. > > I told Jamal (who first sent me this fix) to fixup the patch so that > the MODULE ifdefs were all removed, but it slipped through the cracks. > > Later, > David S. Miller > davem@redhat.com > From owner-netdev@oss.sgi.com Wed Sep 26 15:27:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QMR4Q32560 for netdev-outgoing; Wed, 26 Sep 2001 15:27:04 -0700 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QMR0D32556 for ; Wed, 26 Sep 2001 15:27:00 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id f8R1R4n05693; Thu, 27 Sep 2001 01:27:04 GMT Date: Thu, 27 Sep 2001 01:27:04 +0000 (GMT) From: Julian Anastasov X-X-Sender: To: jamal cc: "David S. Miller" , Subject: Re: Incorrect sch_ingress registration to NF 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: 1183 Lines: 35 Hello, On Wed, 26 Sep 2001, jamal wrote: > I cant think of any clever way that wont have a cost to it. One way could > be just to get rid of the new define in the patch (means modules will have > this extra static variable they dont use). I vote for the above variant. The counter will allow the change from 1 to 0 to unregister the hook. When the counter is 0 the packet processing will not be delayed. IMO, init_module and cleanup_module better not to play with netfilter. The hook will be managed only from ingress_init and ingress_destroy without depending on the MODULE define. > OTOH, we could fix this from netfilter. I remember discussing this with > Harald and sending him a small patchlet. I hope he's on the list. > The check if (nf_register_hook(&ing_ops) < 0) is basically useless. > The return is always succesful. Adding the same hook twice does not make > any semantic sense in netfilter and as can be seen creates a oops. > If nf_register_hook() returns something like -EREGISTERED life would be > good. But may be this variant is not good if we want to unregister the hook when it is not used. > cheers, > jamal Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Wed Sep 26 15:49:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QMnGq00484 for netdev-outgoing; Wed, 26 Sep 2001 15:49:16 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QMnDD00481 for ; Wed, 26 Sep 2001 15:49:13 -0700 Received: from localhost (IDENT:davem@pizda.ninka.net [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id PAA10689; Wed, 26 Sep 2001 15:49:05 -0700 Date: Wed, 26 Sep 2001 15:49:04 -0700 (PDT) Message-Id: <20010926.154904.85546891.davem@redhat.com> To: hadi@cyberus.ca Cc: ja@ssi.bg, netdev@oss.sgi.com Subject: Re: Incorrect sch_ingress registration to NF From: "David S. Miller" In-Reply-To: References: <20010920.161412.88343865.davem@redhat.com> X-Mailer: Mew version 2.0 on Emacs 21.0 / 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: 475 Lines: 16 From: jamal Date: Wed, 26 Sep 2001 17:58:08 -0400 (EDT) If nf_register_hook() returns something like -EREGISTERED life would be good. I would like to ask people to work on this solution. To me it seems obvious that this would be highly desirable behavior for other reasons. NF should be checking to ensure it's own data structure integrity in cases like this one where it certainly can do so. Franks a lot, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed Sep 26 16:46:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8QNkQk01516 for netdev-outgoing; Wed, 26 Sep 2001 16:46:26 -0700 Received: from webber.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8QNkID01513 for ; Wed, 26 Sep 2001 16:46:18 -0700 Received: from webber.adilger.int (adilger@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id f8QNk7mK002551; Wed, 26 Sep 2001 17:46:08 -0600 Received: (from adilger@localhost) by webber.adilger.int (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) id f8QNk6iL002549; Wed, 26 Sep 2001 17:46:06 -0600 From: Andreas Dilger Date: Wed, 26 Sep 2001 17:46:05 -0600 To: Ingo Molnar , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [patch] netconsole - log kernel messages over the network. 2.4.10. Message-ID: <20010926174605.E1140@turbolinux.com> Mail-Followup-To: Ingo Molnar , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20010926152909.D1140@turbolinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010926152909.D1140@turbolinux.com> User-Agent: Mutt/1.3.20i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3745 Lines: 109 On Sep 26, 2001 15:29 -0600, adilger wrote: > On Wed, 26 Sep 2001, Ingo Molnar wrote: > > sample startup of the netconsole on the server: > > > > insmod netconsole dev=eth1 target_ip=0x0a000701 \ > > source_port=6666 \ > > target_port=6666 \ > > target_eth_byte0=0x00 \ > > target_eth_byte1=0x90\ > > target_eth_byte2=0x27 \ > > target_eth_byte3=0x8C \ > > target_eth_byte4=0xA0 \ > > target_eth_byte5=0xA8 > > Ugh. Maybe a wrapper script (netconsole-server) which automates this is > in order? I imagine the eth_byteX is a MAC address (or at least that this > is in the documentation)? Ok, I read the docs, and this is indeed a target MAC address. It may still be easier to accept a regular MAC address like target_mac=XX:XX:XX:XX:XX:XX as the module parameter (and a target_ip=A.B.C.D). In any case, here is a script to automate this (ugly because of the conversions needed). ========================================================================= #!/bin/sh prog=netconsole-server # # initialize the netconsole using reasonable defaults (normally just the # client IP address, and possibly the port. We can determine the MAC # address of the client system, IP address, the correct device, and verify # that we are using an ethernet interface (required for netconsole to work). # # Andreas Dilger Sep 26, 2001 usage() { cat - <<- EOF 1>&2 Initialize a network message console over UDP. usage: $prog [-b] [-d dev] [-m mac] [-p port] target[:port] -b - use broadcast ethernet MAC address -m - specify remote system MAC address (default: detect) -p - local port to use for message traffic (default: 6666) -d - ethernet device to use for messages (default: detect) target - hostname/IP address of remote netconsole-client :port - port on target netconsole-client (default: like -p) EOF exit 1 } PATH=$PATH:/sbin:/usr/sbin PORT=6666 while [ $# -ge 1 ]; do case $1 in -b) NOMAC=1 ;; -d) DEV=$2; shift ;; -m) MAC=$2; shift ;; -p) PORT=$2; shift ;; *:*) TGT=`echo $1 | sed "s/:.*//"`; TPORT=`echo $1 | sed "s/.*://"` ;; *) TGT=$1 ;; esac shift done [ -z "$TGT" ] && usage [ -z "$TPORT" ] && TPORT=$PORT ping -c 1 $TGT > /dev/null 2>&1 [ $? -ne 0 ] && echo "$prog: can't ping $TGT" 1>&2 && usage dquad_to_hex() { echo $1 | sed -e "s/[()]//g" -e "s/\./ /g" | while read I0 I1 I2 I3 ; do printf "0x%02X%02X%02X%02X" $I0 $I1 $I2 $I3 done } # output from arp -a of the form: # good: host.domain (A.B.C.D) at 00:50:BF:06:48:C1 [ether] on eth0 # bad: ? (A.B.C.D) at on eth0 arp -a | grep $TGT | { read HOSTNAME IPADDR AT MACADDR TYPE ON IFACE; [ "$HOSTNAME" = "?" -a -z "$MAC" -a -z "$NOMAC" ] && \ echo "$prog: can't resolve $TGT MAC" 1>&2 && usage [ -z "$MAC" ] && MAC=$MACADDR [ -z "$DEV" ] && DEV=$IFACE [ "$DEV" = "$IFACE" -a "$TYPE" != "[ether]" ] && \ echo "$prog: $DEV must be an ethernet interface" 1>&2 && usage IPHEX=`dquad_to_hex $IPADDR` echo $MAC | sed "s/:/ /g" | { read M0 M1 M2 M3 M4 M5; if [ -z "$NOMAC" ]; then TGTMAC="target_eth_byte0=0x$M0 target_eth_byte1=0x$M1 \ target_eth_byte2=0x$M2 target_eth_byte3=0x$M3 \ target_eth_byte4=0x$M4 target_eth_byte5=0x$M5" fi #insmod netconsole dev=$DEV target_ip=$IPHEX \ echo dev=$DEV target_ip=$IPHEX \ source_port=$PORT target_port=$TPORT $TGTMAC } } Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert From owner-netdev@oss.sgi.com Wed Sep 26 22:30:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8R5UZ005422 for netdev-outgoing; Wed, 26 Sep 2001 22:30:35 -0700 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8R5UVD05419 for ; Wed, 26 Sep 2001 22:30:33 -0700 Received: by chiara.elte.hu (Postfix, from userid 17806) id 378801FCE; Thu, 27 Sep 2001 07:30:27 +0200 (CEST) Date: Thu, 27 Sep 2001 07:28:06 +0200 (CEST) From: Ingo Molnar Reply-To: To: Andreas Dilger Cc: , , Subject: Re: [patch] netconsole - log kernel messages over the network. 2.4.10. In-Reply-To: <20010926174605.E1140@turbolinux.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 415 Lines: 13 On Wed, 26 Sep 2001, Andreas Dilger wrote: > Ok, I read the docs, and this is indeed a target MAC address. It may > still be easier to accept a regular MAC address like > target_mac=XX:XX:XX:XX:XX:XX as the module parameter (and a > target_ip=A.B.C.D). In any case, here is a script to automate this > (ugly because of the conversions needed). thanks - i've put this script into the userspace tarball. Ingo From owner-netdev@oss.sgi.com Wed Sep 26 22:48:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8R5mJV05621 for netdev-outgoing; Wed, 26 Sep 2001 22:48:19 -0700 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8R5mGD05617 for ; Wed, 26 Sep 2001 22:48:16 -0700 Received: by chiara.elte.hu (Postfix, from userid 17806) id 6F24D1FD2; Thu, 27 Sep 2001 07:48:13 +0200 (CEST) Date: Thu, 27 Sep 2001 07:45:51 +0200 (CEST) From: Ingo Molnar Reply-To: To: jamal Cc: , , Subject: Re: [patch] netconsole - log kernel messages over the network. 2.4.10. 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: 1134 Lines: 26 On Wed, 26 Sep 2001, jamal wrote: > Is there any reason you are not using dev_queue_xmit()? (side > benefits, you could hack this into using scatter gather schemes etc) the reason is latency of messages, and reliability of sends. If we are in the middle of a *nasty* crash that takes down the system down 10 microseconds later, then i wanted to make 100% sure the message gets out and the bug can be debugged. The VGA console and the serial logging console have such properties - messages are instantaneous. Networking is very asynchron in nature, so a new network driver extension was needed to achieve this goal. There are crashes where there are no new IRQs processed after the crash, so there is no chance for dev_queue_xmit to do any useful send. We must be able to send packets even if the output interface's hardware queues are full - and dev_queue_xmit relies on future device interrupts to send queued packets. this is not just theory - about 10% of the crashes i experience (during development...) are such, and the majority of the 'hard to fix' crashes have such properties, especially on busy remote servers. Ingo From owner-netdev@oss.sgi.com Wed Sep 26 23:41:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8R6fKB06324 for netdev-outgoing; Wed, 26 Sep 2001 23:41:20 -0700 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8R6fGD06321 for ; Wed, 26 Sep 2001 23:41:16 -0700 Received: by chiara.elte.hu (Postfix, from userid 17806) id 45CBF1FCE; Thu, 27 Sep 2001 08:41:13 +0200 (CEST) Date: Thu, 27 Sep 2001 08:38:51 +0200 (CEST) From: Ingo Molnar Reply-To: To: Marcelo Tosatti Cc: , , , Andreas Dilger Subject: [patch] netconsole-2.4.10-B1 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: 1399 Lines: 38 On Wed, 26 Sep 2001, Marcelo Tosatti wrote: > Don't you think it would be useful to have some reserved memory for > the netconsole use ? > It would be nice to have a guarantee that messages are sent over > network even if the system is under real OOM. yep, that is very useful indeed. i've implemented a private emergency pool of 32 packets that we try to keep filled as much as possible, and which one we use only if GFP_ATOMIC fails. The new patch can downloaded from: http://redhat.com/~mingo/netconsole-patches/netconsole-2.4.10-B1 the patch also includes Andrew Morton's suggestion to add the HAVE_POLL_CONTROLLER define for easier network-driver integration. The eepro100.c changes now use this define. the new utilities-tarball is at: http://redhat.com/~mingo/netconsole-patches/netconsole-client-20010927.tar.gz this includes Andreas Dilger's netconsole-server script. (i've done a minor modification to the script, it insmods the netconsole module with the parameters.) there is one more thing we could do: we could also allocate the skb on stack in extreme cases. This adds noticeable latency though, since the skb xmit has to be polled for completion as well [this can be done with the current ->poll_controller() method], but this way the netconsole could be self-sufficient and would be completely independent of the VM. reports, suggestions, comments welcome, Ingo From owner-netdev@oss.sgi.com Thu Sep 27 08:52:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8RFqq617091 for netdev-outgoing; Thu, 27 Sep 2001 08:52:52 -0700 Received: from mail.zrz.tu-berlin.de (smtp.zrz.TU-Berlin.DE [130.149.4.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8RFqoD17088 for ; Thu, 27 Sep 2001 08:52:51 -0700 Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with smtp (exim-3.33) for id 15mdSu-0004wJ-00; Thu, 27 Sep 2001 17:52:44 +0200 Received: from cs.tu-berlin.de (turino.ee.TU-Berlin.DE [130.149.49.160]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f8RFqhD11397 for ; Thu, 27 Sep 2001 17:52:44 +0200 Message-ID: <3BB34EC7.16DAF07@cs.tu-berlin.de> Date: Thu, 27 Sep 2001 18:07:35 +0200 From: root X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.7-me9 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: documentation for linux ipv6-code Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 295 Lines: 8 Hello, I' am trying hard to find some kind of documentation for the linux ipv6 stack. If anybody knows some docs, howtos or interesting links regarding this please let me know. Even just something discribing the meaning of the different data-structures would be great. thanx in advance... axel From owner-netdev@oss.sgi.com Thu Sep 27 08:58:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8RFwkQ17246 for netdev-outgoing; Thu, 27 Sep 2001 08:58:46 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8RFwiD17242 for ; Thu, 27 Sep 2001 08:58:44 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f8RFw2u02223; Thu, 27 Sep 2001 18:58:02 +0300 Date: Thu, 27 Sep 2001 18:58:02 +0300 (EEST) From: Pekka Savola To: root cc: Subject: Re: documentation for linux ipv6-code In-Reply-To: <3BB34EC7.16DAF07@cs.tu-berlin.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 540 Lines: 15 On Thu, 27 Sep 2001, root wrote: > I' am trying hard to find some kind of documentation for the linux ipv6 > stack. > If anybody knows some docs, howtos or interesting links regarding this > please let me know. > Even just something discribing the meaning of the different > data-structures would be great. Source be with you, always. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Thu Sep 27 09:42:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8RGgZ818436 for netdev-outgoing; Thu, 27 Sep 2001 09:42:35 -0700 Received: from dibbler.ne.mediaone.net (dibbler.ne.mediaone.net [24.218.56.247]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8RGgWD18430 for ; Thu, 27 Sep 2001 09:42:33 -0700 Received: (from rodrigc@localhost) by dibbler.ne.mediaone.net (8.11.0/8.11.0) id f8RGgPD25719; Thu, 27 Sep 2001 12:42:25 -0400 Date: Thu, 27 Sep 2001 12:42:25 -0400 From: Craig Rodrigues To: root Cc: netdev@oss.sgi.com Subject: Re: documentation for linux ipv6-code Message-ID: <20010927124225.A25714@mediaone.net> References: <3BB34EC7.16DAF07@cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BB34EC7.16DAF07@cs.tu-berlin.de>; from insel@cs.tu-berlin.de on Thu, Sep 27, 2001 at 06:07:35PM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 662 Lines: 18 On Thu, Sep 27, 2001 at 06:07:35PM +0200, root wrote: > Hello, > I' am trying hard to find some kind of documentation for the linux ipv6 > stack. > If anybody knows some docs, howtos or interesting links regarding this > please let me know. > Even just something discribing the meaning of the different > data-structures would be great. > thanx in advance... axel For docs, the source code is probably the best. For interesting links, try: http://www.linux-ipv6.org. The USAGI mailing list which you can find out about on that web site may also have useful information. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From owner-netdev@oss.sgi.com Thu Sep 27 13:01:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8RK1K022904 for netdev-outgoing; Thu, 27 Sep 2001 13:01:20 -0700 Received: from nero.doit.wisc.edu (nero.doit.wisc.edu [128.104.17.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8RK1HD22895 for ; Thu, 27 Sep 2001 13:01:17 -0700 Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id PAA11200 for netdev@oss.sgi.com; Thu, 27 Sep 2001 15:55:44 -0500 Date: Thu, 27 Sep 2001 15:55:44 -0500 From: "James R. Leu" To: netdev@oss.sgi.com Subject: Virtual routing tables .... Message-ID: <20010927155544.B11135@nero.doit.wisc.edu> Reply-To: jleu@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Organization: none Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 721 Lines: 22 Hello all, I know Linux already has the notion of multiple routing tables, but has anyone extended this to be "Virtual Routing/Forwarding" (ala Cisco and RFC 2547bis). Is there any standard yet for an application to request which routing table it want to bind to? Is there any standard yet for binding an interface to a routing table? I know these are vague question, and I'm expecting vague answers. Just want to know if anyone has done or is doing this type of work. Thanks, Jim BTW my posting to netdev was triggered by a post to the mpls for linux mailing list "" by "Nick Eggleston " .. just making sure to give credit where credit is due ... -- James R. Leu From owner-netdev@oss.sgi.com Fri Sep 28 00:09:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8S79bU01804 for netdev-outgoing; Fri, 28 Sep 2001 00:09:37 -0700 Received: from webber.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8S79AD01800 for ; Fri, 28 Sep 2001 00:09:10 -0700 Received: from webber.adilger.int (adilger@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id f8S78TZs000468; Fri, 28 Sep 2001 01:08:29 -0600 Received: (from adilger@localhost) by webber.adilger.int (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) id f8S78KpK000466; Fri, 28 Sep 2001 01:08:20 -0600 From: Andreas Dilger Date: Fri, 28 Sep 2001 01:08:19 -0600 To: Ingo Molnar Cc: Marcelo Tosatti , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, jgarzik@mandrakesoft.com Subject: Re: [patch] netconsole-2.4.10-B1 Message-ID: <20010928010819.A434@turbolinux.com> Mail-Followup-To: Ingo Molnar , Marcelo Tosatti , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, jgarzik@mandrakesoft.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 12397 Lines: 362 On Sep 27, 2001 08:38 +0200, Ingo Molnar wrote: > the patch also includes Andrew Morton's suggestion to add the > HAVE_POLL_CONTROLLER define for easier network-driver integration. The > eepro100.c changes now use this define. > > the new utilities-tarball is at: > > http://redhat.com/~mingo/netconsole-patches/netconsole-client-20010927.tar.gz A few minor changes to the code, after testing it a bit locally (note that I am using kernel patch C1): First, a patch to change the MAC address kernel parameter to be in the standard XX:XX:XX:XX:XX:XX form, instead of separate bytes. It also fixes the output of the IP addresses to be unsigned ints. Isn't there a function in the kernel to format IP addresses for output already? Next, a patch to netconsole-server to use the target_mac parameter instead of the target_eth_byteX parameters. I thought about keeping these around for compatibility, but since this is a relatively new tool there is no point in keeping the extra baggage. TODO: figure out what "offset" is really supposed to be useful for. Maybe it should be aligned properly, and we add the message priority into one of the free bytes? Finally, a patch to netconsole-client.c which does a few things: - remove "offset" from output, it appears meaningless and screws formatting. - allow the client to receive messages from multiple servers, unless a single server is specified. - log to syslog (this is a bit complex because of the desire to write full lines into the syslog as opposed to chunks of the size sent by printk(). - (minor) change parameters to use "--" long option names in preparation for using getopt-long to do CLI parsing. - (minor) don't require the --port option (use 6666 as default) - (minor) don't require the --server option (accept all messages by default) TODO: don't require the --client option (get ipaddress from interface and/or listen on all interfaces by default) TODO: add getopt_long parsing of options to avoid ordered option requirement TODO: make syslog and stdout logging optional (need one or the other obviously) TODO: print server IP/hostname in syslog/stdout output in case we are getting messages from multiple servers TODO: figure out why LOG_KERN does not show up in kernel log, while klogd does TODO: add timeout for messages in syslog output buffer. TODO: allow client/server to be specified by both hostname/IP TODO: allow different client/server port numbers? Do we care? As an added bonus, a patch for 8139too.c which adds poll support (Jeff CC'd). Cheers, Andreas ======================= netconsole-2.4.8-mac.diff ===================== --- linux/drivers/net/netconsole.c.orig Thu Sep 27 10:11:27 2001 +++ linux/drivers/net/netconsole.c Thu Sep 27 17:13:24 2001 @@ -219,20 +219,10 @@ } static char *dev; -static int target_eth_byte0 = 255; -static int target_eth_byte1 = 255; -static int target_eth_byte2 = 255; -static int target_eth_byte3 = 255; -static int target_eth_byte4 = 255; -static int target_eth_byte5 = 255; +static char *target_mac; MODULE_PARM(target_ip, "i"); -MODULE_PARM(target_eth_byte0, "i"); -MODULE_PARM(target_eth_byte1, "i"); -MODULE_PARM(target_eth_byte2, "i"); -MODULE_PARM(target_eth_byte3, "i"); -MODULE_PARM(target_eth_byte4, "i"); -MODULE_PARM(target_eth_byte5, "i"); +MODULE_PARM(target_mac, "s"); MODULE_PARM(source_port, "h"); MODULE_PARM(target_port, "h"); MODULE_PARM(dev, "s"); @@ -267,8 +257,8 @@ printk(KERN_ERR "netconsole: network device %s has no local address, aborting.\n", dev); return -1; } -#define IP(x) ((char *)&source_ip)[x] - printk(KERN_INFO "netconsole: using source IP %i.%i.%i.%i\n", +#define IP(x) ((unsigned char *)&source_ip)[x] + printk(KERN_INFO "netconsole: using source IP %u.%u.%u.%u\n", IP(3), IP(2), IP(1), IP(0)); #undef IP source_ip = htonl(source_ip); @@ -276,8 +266,8 @@ printk(KERN_ERR "netconsole: target_ip parameter not specified, aborting.\n"); return -1; } -#define IP(x) ((char *)&target_ip)[x] - printk(KERN_INFO "netconsole: using target IP %i.%i.%i.%i\n", +#define IP(x) ((unsigned char *)&target_ip)[x] + printk(KERN_INFO "netconsole: using target IP %u.%u.%u.%u\n", IP(3), IP(2), IP(1), IP(0)); #undef IP target_ip = htonl(target_ip); @@ -294,18 +284,26 @@ printk(KERN_INFO "netconsole: using target UDP port: %i\n", target_port); target_port = htons(target_port); - daddr[0] = target_eth_byte0; - daddr[1] = target_eth_byte1; - daddr[2] = target_eth_byte2; - daddr[3] = target_eth_byte3; - daddr[4] = target_eth_byte4; - daddr[5] = target_eth_byte5; - - if ((daddr[0] & daddr[1] & daddr[2] & daddr[3] & daddr[4] & daddr[5]) == 255) - printk(KERN_INFO "netconsole: using broadcast ethernet frames to send packets.\n"); - else - printk(KERN_INFO "netconsole: using target ethernet address %02x:%02x:%02x:%02x:%02x:%02x.\n", daddr[0], daddr[1], daddr[2], daddr[3], daddr[4], daddr[5]); - + if (target_mac) { + char *ptr = target_mac; + int i; + + printk(KERN_INFO "netconsole: using target ethernet MAC: %s\n", + target_mac); + for (i = 0; i < 6 && ptr; i++) { + int val; + char *sep; + val = simple_strtoul(ptr, &sep, 16); + if (sep != ptr) { + daddr[i] = val; + ptr = *sep ? sep + 1 : NULL; + } + } + } else + printk(KERN_INFO "netconsole: using broadcast ethernet MAC.\n"); + netconsole_dev = ndev; #define STARTUP_MSG "[...network console startup...]\n" write_netconsole_msg(NULL, STARTUP_MSG, strlen(STARTUP_MSG)); ===================== netconsole-server.diff ============================= --- netconsole-client/netconsole-server.orig Thu Sep 27 00:32:50 2001 +++ netconsole-client/netconsole-server Thu Sep 27 17:22:55 2001 @@ -30,9 +30,11 @@ while [ $# -ge 1 ]; do case $1 in -b) NOMAC=1 ;; - -d) DEV=$2; shift ;; - -m) MAC=$2; shift ;; - -p) PORT=$2; shift ;; + -d|--device) DEV=$2; shift ;; + -m|--mac) MAC=$2; shift ;; + -p|--port) PORT=$2; shift ;; + --client) TGT=`echo $2| sed "s/:.*//"`; + TPORT=`echo $2 | sed "s/.*://"`; shift ;; *:*) TGT=`echo $1 | sed "s/:.*//"`; TPORT=`echo $1 | sed "s/.*://"` ;; *) TGT=$1 ;; esac @@ -65,16 +67,9 @@ echo "$prog: $DEV must be an ethernet interface" 1>&2 && usage IPHEX=`dquad_to_hex $IPADDR` - echo $MAC | sed "s/:/ /g" | { read M0 M1 M2 M3 M4 M5; - if [ -z "$NOMAC" ]; then - TGTMAC="target_eth_byte0=0x$M0 target_eth_byte1=0x$M1 \ - target_eth_byte2=0x$M2 target_eth_byte3=0x$M3 \ - target_eth_byte4=0x$M4 target_eth_byte5=0x$M5" - fi - echo dev=$DEV target_ip=$IPHEX \ - source_port=$PORT target_port=$TPORT $TGTMAC - /sbin/insmod netconsole dev=$DEV target_ip=$IPHEX \ - source_port=$PORT target_port=$TPORT $TGTMAC - } + [ -z "$NOMAC" ] && TGTMAC="target_mac=$MAC" + echo dev=$DEV target_ip=$IPHEX \ + source_port=$PORT target_port=$TPORT $TGTMAC + insmod netconsole dev=$DEV target_ip=$IPHEX \ + source_port=$PORT target_port=$TPORT $TGTMAC } - ===================== netconsole-client.diff ============================= --- netconsole-client/netconsole-client.c.orig Thu Sep 27 08:32:31 2001 +++ netconsole-client/netconsole-client.c Thu Sep 27 16:07:39 2001 @@ -17,47 +17,59 @@ #include #include #include +#include #define NETCONSOLE_VERSION 0x01 #define BUFLEN 10000 +#ifndef min +#define min(a,b) ((a) < (b) ? (a) : (b)) +#endif + int main (int argc, char **argv) { struct sockaddr_in saddr, caddr; int udp_socket; - unsigned char buf[BUFLEN]; - int len, port; + unsigned char buf[BUFLEN], sysbuf[BUFLEN]; + unsigned int sysoff = 0; + int len, port = 6666; struct sockaddr_in addr; int addr_len = sizeof(addr); + int noserver = 1; memset(&addr, 0, addr_len); memset(&saddr, 0, addr_len); memset(&caddr, 0, addr_len); - if (argc != 7) { - fprintf(stderr, "usage: netconsole-client -server -client -port \n"); + if (argc != 3 && argc != 5 && argc != 7) { + fprintf(stderr, "usage: netconsole-client --client [--port [--server ]]\n"); exit(-1); } - port = atol(argv[6]); - printf("displaying netconsole output from server %s, client %s, UDP port %d.\n", argv[2], argv[4], port); + if (argc > 4) + port = atol(argv[4]); + printf("listening on interface %s:%d for server %s:%d.\n", argv[2], port, argc > 6 ? argv[6] : "ANY", port); udp_socket = socket(PF_INET, SOCK_DGRAM, 0); - saddr.sin_family = AF_INET; - saddr.sin_port = htons(port); - saddr.sin_addr.s_addr = inet_addr(argv[2]); - caddr.sin_family = AF_INET; caddr.sin_port = htons(port); - caddr.sin_addr.s_addr = inet_addr(argv[4]); + caddr.sin_addr.s_addr = inet_addr(argv[2]); + + if (argc > 5) { + saddr.sin_family = AF_INET; + saddr.sin_port = htons(port); + saddr.sin_addr.s_addr = inet_addr(argv[6]); + noserver = 0; + } if (bind(udp_socket, (struct sockaddr *)&caddr, sizeof(caddr))) { perror("could not bind UDP socket!\n"); exit(-1); } + openlog("netconsole", 0, LOG_KERN); while (1) { len = recvfrom(udp_socket, buf, BUFLEN, 0, (struct sockaddr *)&addr, &addr_len); if (len <= 0) { @@ -65,10 +77,15 @@ exit(-1); } buf[len] = 0; - if (!memcmp(&addr, &saddr, addr_len)) { - unsigned int offset; + if (noserver || !memcmp(&addr, &saddr, addr_len)) { + unsigned int offset, skip; + unsigned int priority = LOG_WARNING, new_priority; + unsigned char *nl; + if (buf[0] != NETCONSOLE_VERSION) { - printf("[netconsole server has version %d, client supports only version %d! exiting.]\n", buf[0], NETCONSOLE_VERSION); + printf("[netconsole server has version %d, " + "client supports only version %d! " + "exiting.]\n", *buf, NETCONSOLE_VERSION); exit(-1); } @@ -76,10 +93,42 @@ offset = (offset << 8) | buf[2]; offset = (offset << 8) | buf[3]; offset = (offset << 8) | buf[4]; + skip = 5; - printf("(%d): %s", offset, buf+5); + printf("%s", buf + skip); fflush(stdout); + if (sysoff == 0 && + sscanf(buf + skip, "<%d>", &new_priority) == 1) { + if (new_priority <= LOG_DEBUG) { + priority = new_priority; + skip += 3; + } + } + while ((nl = strchr(buf + skip, '\n'))) { + int used, left; + + used = (nl - (buf + skip)) + 1; + left = sizeof(sysbuf) - sysoff - 1; + + strncat(sysbuf + sysoff, buf + skip, + min(used, left)); + /* FIXME: need to print source hostname/IP */ + syslog(priority, "%s", sysbuf); + sysbuf[(sysoff = 0)] = '\0'; + skip += min(used, left); + } + if (buf[skip]) { + strncat(sysbuf + sysoff, buf + skip, + sizeof(sysbuf) - sysoff - 1); + sysoff += strlen(buf + skip); + if (sysoff >= sizeof(sysbuf)) { + syslog(priority, "%s", sysbuf); + sysbuf[(sysoff = 0)] = '\0'; + } + } + } } + closelog(); return 0; } ========================= 8139too-poll.diff ============================== --- linux/drivers/net/8139too.c.orig Tue Jul 31 15:15:28 2001 +++ linux/drivers/net/8139too.c Thu Sep 27 10:15:59 2001 @@ -619,6 +619,9 @@ static void rtl8139_init_ring (struct net_device *dev); static int rtl8139_start_xmit (struct sk_buff *skb, struct net_device *dev); +#ifdef HAVE_POLL_CONTROLLER +static void rtl8139_poll (struct net_device *dev); +#endif static void rtl8139_interrupt (int irq, void *dev_instance, struct pt_regs *regs); static int rtl8139_close (struct net_device *dev); @@ -965,6 +968,9 @@ dev->get_stats = rtl8139_get_stats; dev->set_multicast_list = rtl8139_set_rx_mode; dev->do_ioctl = netdev_ioctl; +#ifdef HAVE_POLL_CONTROLLER + dev->poll_controller = rtl8139_poll; +#endif dev->tx_timeout = rtl8139_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; @@ -2201,6 +2207,20 @@ return 0; } + +#ifdef HAVE_POLL_CONTROLLER +/* + * Polling 'interrupt' - used by things like netconsole to send skbs + * without having to re-enable interrupts. It's not called while + * the interrupt routine is executing. + */ +static void rtl8139_poll(struct net_device *dev) +{ + disable_irq(dev->irq); + rtl8139_interrupt(dev->irq, dev, NULL); + enable_irq(dev->irq); +} +#endif static int netdev_ethtool_ioctl (struct net_device *dev, void *useraddr) { -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert From owner-netdev@oss.sgi.com Fri Sep 28 18:37:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8T1bHI25833 for netdev-outgoing; Fri, 28 Sep 2001 18:37:17 -0700 Received: from osdlab.pdx.osdl.net (air-1.osdlab.org [65.201.151.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8T1bCD25829 for ; Fri, 28 Sep 2001 18:37:12 -0700 Received: from osdlab.org (dragon.pdx.osdl.net [172.20.1.27]) by osdlab.pdx.osdl.net (8.11.2/8.11.2) with ESMTP id f8T1axS12699; Fri, 28 Sep 2001 18:36:59 -0700 Message-ID: <3BB52510.7D41538A@osdlab.org> Date: Fri, 28 Sep 2001 18:34:08 -0700 From: "Randy.Dunlap" Organization: OSDL X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Dilger CC: Ingo Molnar , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [patch] netconsole-2.4.10-B1 References: <20010928010819.A434@turbolinux.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1758 Lines: 59 Andreas Dilger wrote: > > On Sep 27, 2001 08:38 +0200, Ingo Molnar wrote: > > the patch also includes Andrew Morton's suggestion to add the > > HAVE_POLL_CONTROLLER define for easier network-driver integration. The > > eepro100.c changes now use this define. > > > > the new utilities-tarball is at: > > > > http://redhat.com/~mingo/netconsole-patches/netconsole-client-20010927.tar.gz > > A few minor changes to the code, after testing it a bit locally (note that I > am using kernel patch C1): [snip] > Finally, a patch to netconsole-client.c which does a few things: > - remove "offset" from output, it appears meaningless and screws formatting. > - allow the client to receive messages from multiple servers, unless a > single server is specified. > TODO: allow client/server to be specified by both hostname/IP > TODO: allow different client/server port numbers? Do we care? Hi, I hope to be able to use this, but... I must admit that I'm confused by the terms server, client, and target. 1. This is what I first thought: server = the logging machine, client = machine under test, and that "target" = client? 2. Then I was told this: target == the machine to log to (== logging server) so I thought that if the target is the server, then the client must run on the machine under test. But the client program won't be started early enough during boot for that to help me. 3. Then I was told this: netconsole-client is the server and mingo should rename it ;-) 4. And finally this: netconsole-client == target kernel == source WHOA! Stop the presses. Can someone say this more clearly, and I'd suggest not using 3 names when 2 will do (probably get rid of "target" and use client/server, or use some other terminology). ~Randy From owner-netdev@oss.sgi.com Sat Sep 29 09:32:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8TGWLx04941 for netdev-outgoing; Sat, 29 Sep 2001 09:32:21 -0700 Received: from otter.mbay.net (root@otter.mbay.net [206.40.79.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8TGWID04938 for ; Sat, 29 Sep 2001 09:32:19 -0700 Received: from localhost (jalvo@localhost) by otter.mbay.net (8.11.4/8.11.4) with ESMTP id f8TGW0R19148; Sat, 29 Sep 2001 09:32:01 -0700 Date: Sat, 29 Sep 2001 09:32:00 -0700 (PDT) From: John Alvord To: Ingo Molnar cc: "Randy.Dunlap" , Andreas Dilger , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [patch] netconsole-2.4.10-B1 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: 1059 Lines: 31 On Sat, 29 Sep 2001, Ingo Molnar wrote: > > sorry :-) definitions of netconsole-terms: > > 'server': the host that is the source of the messages. Ie. the box that > runs the netconsole.o module. It serves log messages to the > client. > > 'client': the host that receives the messages. This box is running the > netconsole-client.c program. > > 'target': the host that gets the messages sent - ie. the client. > > 'target IP address': the IP address of the 'target'. > > 'target ethernet address': the local-net host or first-hop router that > gets the netconsole UDP packets sent. Ie. it > does not necesserily match the MAC address of > the 'target'. > > (i can see where the confusion comes from, 'syslog servers' are ones that > receieve syslogs. It's a backwards term i think. 'netconsole servers' are > the ones that produce the messages.) > > does it make more sense now? :) Would this scheme work for crash dump capturing? john From owner-netdev@oss.sgi.com Sat Sep 29 09:40:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8TGeu005279 for netdev-outgoing; Sat, 29 Sep 2001 09:40:56 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8TGesD05274 for ; Sat, 29 Sep 2001 09:40:54 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f8TGeRi17048; Sat, 29 Sep 2001 19:40:27 +0300 Date: Sat, 29 Sep 2001 19:40:27 +0300 (EEST) From: Pekka Savola To: Ingo Molnar cc: "Randy.Dunlap" , Andreas Dilger , , , Subject: Re: [patch] netconsole-2.4.10-B1 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: 738 Lines: 19 On Sat, 29 Sep 2001, Ingo Molnar wrote: > (i can see where the confusion comes from, 'syslog servers' are ones that > receieve syslogs. It's a backwards term i think. 'netconsole servers' are > the ones that produce the messages.) Speaking of which, would it be too big a burden (or is it supported already), that the oopses or dumps would be sent off to an off-link syslog server? This would ease the use in occasions where you don't expect a crash (ie: no listener in local network), but do log on remote syslogd's considerably. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Sat Sep 29 15:37:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8TMbin10592 for netdev-outgoing; Sat, 29 Sep 2001 15:37:44 -0700 Received: from webber.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8TMbdD10588 for ; Sat, 29 Sep 2001 15:37:39 -0700 Received: from webber.adilger.int (adilger@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id f8TMb2L7019366; Sat, 29 Sep 2001 16:37:02 -0600 Received: (from adilger@localhost) by webber.adilger.int (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) id f8TMb0BI019364; Sat, 29 Sep 2001 16:37:00 -0600 From: Andreas Dilger Date: Sat, 29 Sep 2001 16:37:00 -0600 To: Pekka Savola Cc: Ingo Molnar , "Randy.Dunlap" , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [patch] netconsole-2.4.10-B1 Message-ID: <20010929163659.J930@turbolinux.com> Mail-Followup-To: Pekka Savola , Ingo Molnar , "Randy.Dunlap" , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1331 Lines: 28 On Sep 29, 2001 19:40 +0300, Pekka Savola wrote: > Speaking of which, would it be too big a burden (or is it supported > already), that the oopses or dumps would be sent off to an off-link syslog > server? > > This would ease the use in occasions where you don't expect a crash (ie: > no listener in local network), but do log on remote syslogd's > considerably. That was in the patch I just sent to Ingo - the "client" logs all of the messages to syslog. However, it is not "perfect" yet, in that you need to be able to select whether or not you really want it sent to syslog, and for some reason, even though I have LOG_KERN as the type, it only gets logged to /var/log/messages and not /var/log/kern.log (on my system at least) (this was in the TODO list, which I'm not in the position to work on right now). For crash dumps and such (which you don't want sent to syslog) it may be useful to have a different message type (with its own offset numbers), so the client knows to save it to a different file, for example, and will handle out-of-order messages, and sparse memory dumps. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert From owner-netdev@oss.sgi.com Sat Sep 29 17:05:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8U05aL11916 for netdev-outgoing; Sat, 29 Sep 2001 17:05:36 -0700 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8U05WD11910 for ; Sat, 29 Sep 2001 17:05:33 -0700 Received: by chiara.elte.hu (Postfix, from userid 17806) id A176E1FCE; Sat, 29 Sep 2001 11:55:07 +0200 (CEST) Date: Sat, 29 Sep 2001 11:52:43 +0200 (CEST) From: Ingo Molnar Reply-To: To: "Randy.Dunlap" Cc: Andreas Dilger , , , Subject: Re: [patch] netconsole-2.4.10-B1 In-Reply-To: <3BB52510.7D41538A@osdlab.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 921 Lines: 27 sorry :-) definitions of netconsole-terms: 'server': the host that is the source of the messages. Ie. the box that runs the netconsole.o module. It serves log messages to the client. 'client': the host that receives the messages. This box is running the netconsole-client.c program. 'target': the host that gets the messages sent - ie. the client. 'target IP address': the IP address of the 'target'. 'target ethernet address': the local-net host or first-hop router that gets the netconsole UDP packets sent. Ie. it does not necesserily match the MAC address of the 'target'. (i can see where the confusion comes from, 'syslog servers' are ones that receieve syslogs. It's a backwards term i think. 'netconsole servers' are the ones that produce the messages.) does it make more sense now? :) Ingo From owner-netdev@oss.sgi.com Sat Sep 29 20:38:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8U3crQ15162 for netdev-outgoing; Sat, 29 Sep 2001 20:38:53 -0700 Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8U3cnD15159 for ; Sat, 29 Sep 2001 20:38:49 -0700 Received: from garbo.localnet (h2n3fls20o70.telia.com [213.66.176.2]) by mailg.telia.com (8.11.6/8.11.6) with ESMTP id f8U3cNS05983; Sun, 30 Sep 2001 05:38:23 +0200 (CEST) Received: from tiger.localnet ([192.168.1.2]) by garbo.localnet with esmtp (Exim 3.32 #1 (Debian)) id 15nXQs-0003jE-00; Sun, 30 Sep 2001 05:38:22 +0200 Received: from localhost ([127.0.0.1] helo=canit.se) by tiger.localnet with esmtp (Exim 3.32 #1 (Debian)) id 15nXQr-0000Yw-00; Sun, 30 Sep 2001 05:38:21 +0200 Message-ID: <3BB693AC.6E2DB9F4@canit.se> Date: Sun, 30 Sep 2001 05:38:20 +0200 From: Kenneth Johansson X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: mingo@elte.hu CC: "Randy.Dunlap" , Andreas Dilger , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [patch] netconsole-2.4.10-B1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1222 Lines: 37 Ingo Molnar wrote: > sorry :-) definitions of netconsole-terms: > > 'server': the host that is the source of the messages. Ie. the box that > runs the netconsole.o module. It serves log messages to the > client. > > 'client': the host that receives the messages. This box is running the > netconsole-client.c program. > > 'target': the host that gets the messages sent - ie. the client. > > 'target IP address': the IP address of the 'target'. > > 'target ethernet address': the local-net host or first-hop router that > gets the netconsole UDP packets sent. Ie. it > does not necesserily match the MAC address of > the 'target'. > > (i can see where the confusion comes from, 'syslog servers' are ones that > receieve syslogs. It's a backwards term i think. 'netconsole servers' are > the ones that produce the messages.) > Servers is usually the thing waiting for something to be sent to it, the client is the sending part(initiator). this works for web servers , X servers, log servers but strangley not for netconsole where everything is backwards. > > does it make more sense now? :) > Not really :) From owner-netdev@oss.sgi.com Sun Sep 30 00:53:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8U7rtT18080 for netdev-outgoing; Sun, 30 Sep 2001 00:53:55 -0700 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8U7rpD18077 for ; Sun, 30 Sep 2001 00:53:51 -0700 Received: from 1-011.ctame701-1.telepar.net.br (1-011.ctame701-1.telepar.net.br [200.181.137.11]) by netbank.com.br (Postfix) with ESMTP id 88F5F46827; Sun, 30 Sep 2001 04:48:46 -0300 (BRST) Received: (from localhost user: 'riel', uid#500) by imladris.surriel.com with ESMTP id ; Sun, 30 Sep 2001 04:52:54 -0300 Date: Sun, 30 Sep 2001 04:52:49 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Kenneth Johansson Cc: , "Randy.Dunlap" , Andreas Dilger , , , Subject: Re: [patch] netconsole-2.4.10-B1 In-Reply-To: <3BB693AC.6E2DB9F4@canit.se> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1152 Lines: 35 On Sun, 30 Sep 2001, Kenneth Johansson wrote: > Ingo Molnar wrote: > > > sorry :-) definitions of netconsole-terms: > > > > 'server': the host that is the source of the messages. Ie. the box that > > runs the netconsole.o module. It serves log messages to the > > client. > > > > 'client': the host that receives the messages. This box is running the > > netconsole-client.c program. > > Servers is usually the thing waiting for something to be sent to it, > the client is the sending part(initiator). this works for web servers > , X servers, log servers but strangley not for netconsole where > everything is backwards. Owww crap. The majority of web traffic is _from_ the server _to_ the client. Same for ftp, realaudio, etc... In fact, usually the server is the _remote_ machine and the client is the _local_ machine. Anybody who believes in having the client remote and the server local should be shipped off to whereever the server is ;) regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to aardvark@nl.linux.org (spam digging piggy) From owner-netdev@oss.sgi.com Sun Sep 30 04:15:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8UBFal20613 for netdev-outgoing; Sun, 30 Sep 2001 04:15:36 -0700 Received: from mta7-svc.virgin.net (mta7-svc.virgin.net [62.253.164.47]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8UBFVD20610 for ; Sun, 30 Sep 2001 04:15:32 -0700 Received: from cerise.nosuchdomain.co.uk ([62.252.68.94]) by mta3-svc.virgin.net (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20010930105746.ZZGS23417.mta3-svc.virgin.net@cerise.nosuchdomain.co.uk>; Sun, 30 Sep 2001 11:57:46 +0100 Received: (from glynn@localhost) by cerise.nosuchdomain.co.uk (8.11.6/8.11.6) id f8UAmkQ07123; Sun, 30 Sep 2001 11:48:46 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15286.63630.291982.555919@cerise.nosuchdomain.co.uk> Date: Sun, 30 Sep 2001 11:48:46 +0100 To: Rik van Riel Cc: , , Subject: Re: [patch] netconsole-2.4.10-B1 In-Reply-To: References: <3BB693AC.6E2DB9F4@canit.se> X-Mailer: VM 6.94 under 21.4 (patch 4) "Artificial Intelligence (candidate #1)" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1640 Lines: 44 Rik van Riel wrote: > > > sorry :-) definitions of netconsole-terms: > > > > > > 'server': the host that is the source of the messages. Ie. the box that > > > runs the netconsole.o module. It serves log messages to the > > > client. > > > > > > 'client': the host that receives the messages. This box is running the > > > netconsole-client.c program. > > > > Servers is usually the thing waiting for something to be sent to it, > > the client is the sending part(initiator). this works for web servers > > , X servers, log servers but strangley not for netconsole where > > everything is backwards. > > Owww crap. The majority of web traffic is _from_ the > server _to_ the client. Same for ftp, realaudio, etc... ... whereas with SMTP, syslog, printer (lpd) etc, it's the other way around. Some servers are primarily "sources", while others are primarily "sinks". Sources are more common, and most users are probably more familiar with sources than sinks. > In fact, usually the server is the _remote_ machine and > the client is the _local_ machine. But not for for X, NAS, ident ... Local is a relative term. Presumably you meant local relative to a user. There are all kinds of generalisations one could make about individual protocols, none of which are ultimately relevant to the client/server distinction. As Ingo points out, although it could have been more clear, the actual distinction between client and server is that the client initiates the communication, while the server responds (cf "originate" and "answer" in telephone terminology). -- Glynn Clements From owner-netdev@oss.sgi.com Sun Sep 30 05:25:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8UCPt526312 for netdev-outgoing; Sun, 30 Sep 2001 05:25:55 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8UCPqD26309 for ; Sun, 30 Sep 2001 05:25:52 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f8UCPXl16936; Sun, 30 Sep 2001 06:25:33 -0600 Date: Sun, 30 Sep 2001 06:25:33 -0600 Message-Id: <200109301225.f8UCPXl16936@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Rik van Riel Cc: Kenneth Johansson , , "Randy.Dunlap" , Andreas Dilger , , , Subject: Re: [patch] netconsole-2.4.10-B1 In-Reply-To: References: <3BB693AC.6E2DB9F4@canit.se> Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1003 Lines: 26 Rik van Riel writes: > Owww crap. The majority of web traffic is _from_ the > server _to_ the client. Same for ftp, realaudio, etc... > > In fact, usually the server is the _remote_ machine and > the client is the _local_ machine. Anybody who believes > in having the client remote and the server local should > be shipped off to whereever the server is ;) Let's see, with X, the server is local (at least, it's local to where I've placed my ass) and the client is remote. I usually think of "server" as the box that's running all the time, providing a service to multiple clients. In this case, the netconsole server should always be running, accepting log messages for storage. The clients (which are transitory, otherwise netconsole wouldn't be needed:-), initiate work for the server to do. Face it, Ingo's use of "client" and "server" is contrary to accepted usage. You can't finesse around it. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-netdev@oss.sgi.com Sun Sep 30 12:45:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8UJjXu31210 for netdev-outgoing; Sun, 30 Sep 2001 12:45:33 -0700 Received: from osdlab.pdx.osdl.net (air-1.osdlab.org [65.201.151.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8UJjRD31207 for ; Sun, 30 Sep 2001 12:45:28 -0700 Received: from osdlab.org (dragon.pdx.osdl.net [172.20.1.27]) by osdlab.pdx.osdl.net (8.11.2/8.11.2) with ESMTP id f8UJjES26479; Sun, 30 Sep 2001 12:45:16 -0700 Message-ID: <3BB77591.C1349C09@osdlab.org> Date: Sun, 30 Sep 2001 12:42:09 -0700 From: "Randy.Dunlap" Organization: OSDL X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: mingo@elte.hu CC: Andreas Dilger , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [patch] netconsole-2.4.10-B1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1099 Lines: 30 Ingo Molnar wrote: > > sorry :-) definitions of netconsole-terms: > > 'server': the host that is the source of the messages. Ie. the box that > runs the netconsole.o module. It serves log messages to the > client. > > 'client': the host that receives the messages. This box is running the > netconsole-client.c program. > > 'target': the host that gets the messages sent - ie. the client. > > 'target IP address': the IP address of the 'target'. > > 'target ethernet address': the local-net host or first-hop router that > gets the netconsole UDP packets sent. Ie. it > does not necesserily match the MAC address of > the 'target'. > > (i can see where the confusion comes from, 'syslog servers' are ones that > receieve syslogs. It's a backwards term i think. 'netconsole servers' are > the ones that produce the messages.) > > does it make more sense now? :) Thanks for the definitions. I can work with them, although I think that there's much room for improvement... ~Randy From owner-netdev@oss.sgi.com Sun Sep 30 13:29:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8UKTQ832003 for netdev-outgoing; Sun, 30 Sep 2001 13:29:26 -0700 Received: from osdlab.pdx.osdl.net (air-1.osdlab.org [65.201.151.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8UKTJD31999 for ; Sun, 30 Sep 2001 13:29:19 -0700 Received: from osdlab.org (dragon.pdx.osdl.net [172.20.1.27]) by osdlab.pdx.osdl.net (8.11.2/8.11.2) with ESMTP id f8UKT3S26604; Sun, 30 Sep 2001 13:29:03 -0700 Message-ID: <3BB77FD7.696CFC58@osdlab.org> Date: Sun, 30 Sep 2001 13:25:59 -0700 From: "Randy.Dunlap" Organization: OSDL X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: mingo@elte.hu, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, jgarzik@mandrakesoft.com Subject: Re: [patch] netconsole-2.4.10-B1 References: <3BB77591.C1349C09@osdlab.org> Content-Type: multipart/mixed; boundary="------------BC742B6CC3660A9A3E7C6B46" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2477 Lines: 88 This is a multi-part message in MIME format. --------------BC742B6CC3660A9A3E7C6B46 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Randy.Dunlap" wrote: > > Ingo Molnar wrote: > > > > > > does it make more sense now? :) > > Thanks for the definitions. I can work with them, > although I think that there's much room for improvement... and I did. Eliminating typos on 'insmod netconsole.o ...' helps. :) Here's 3c59x.c patched for netconsole (HAVE_POLL_CONTROLLER). Ingo, you _are_ planning to use most or all of Andreas's patches, aren't you? I'm interested in using netconsole early (during boot). Any problems doing that, other than getting module parameters to it? I can fix that part. ~Randy --------------BC742B6CC3660A9A3E7C6B46 Content-Type: text/plain; charset=us-ascii; name="3c59x-poll.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="3c59x-poll.patch" --- linux/drivers/net/3c59x.c.org Sun Aug 12 12:27:18 2001 +++ linux/drivers/net/3c59x.c Sun Sep 30 12:37:39 2001 @@ -842,6 +842,7 @@ static int vortex_ioctl(struct net_device *dev, struct ifreq *rq, int cmd); static void vortex_tx_timeout(struct net_device *dev); static void acpi_set_WOL(struct net_device *dev); +static void vorboom_poll(struct net_device *dev); /* This driver uses 'options' to pass the media type, full-duplex flag, etc. */ /* Option count limit only -- unlimited interfaces are supported. */ @@ -1328,6 +1329,9 @@ dev->set_multicast_list = set_rx_mode; dev->tx_timeout = vortex_tx_timeout; dev->watchdog_timeo = (watchdog * HZ) / 1000; +#ifdef HAVE_POLL_CONTROLLER + dev->poll_controller = &vorboom_poll; +#endif if (pdev && vp->enable_wol) { vp->pm_state_valid = 1; pci_save_state(vp->pdev, vp->power_state); @@ -2295,6 +2299,29 @@ handler_exit: spin_unlock(&vp->lock); } + +#ifdef HAVE_POLL_CONTROLLER + +/* + * Polling 'interrupt' - used by things like netconsole to send skbs + * without having to re-enable interrupts. It's not called while + * the interrupt routine is executing. + */ + +static void vorboom_poll (struct net_device *dev) +{ + struct vortex_private *vp = (struct vortex_private *)dev->priv; + + disable_irq(dev->irq); + if (vp->full_bus_master_tx) + boomerang_interrupt(dev->irq, dev, 0); + else + vortex_interrupt(dev->irq, dev, 0); + enable_irq(dev->irq); +} + +#endif + static int vortex_rx(struct net_device *dev) { --------------BC742B6CC3660A9A3E7C6B46-- From owner-netdev@oss.sgi.com Sun Sep 30 21:10:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f914AM707095 for netdev-outgoing; Sun, 30 Sep 2001 21:10:22 -0700 Received: from webber.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f914AJD07092 for ; Sun, 30 Sep 2001 21:10:20 -0700 Received: from webber.adilger.int (adilger@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id f9149rL7005223; Sun, 30 Sep 2001 22:09:53 -0600 Received: (from adilger@localhost) by webber.adilger.int (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) id f9149oUI005221; Sun, 30 Sep 2001 22:09:50 -0600 From: Andreas Dilger Date: Sun, 30 Sep 2001 22:09:50 -0600 To: "Randy.Dunlap" Cc: mingo@elte.hu, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, jgarzik@mandrakesoft.com Subject: Re: [patch] netconsole-2.4.10-B1 Message-ID: <20010930220950.K930@turbolinux.com> Mail-Followup-To: "Randy.Dunlap" , mingo@elte.hu, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, jgarzik@mandrakesoft.com References: <3BB77591.C1349C09@osdlab.org> <3BB77FD7.696CFC58@osdlab.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BB77FD7.696CFC58@osdlab.org> User-Agent: Mutt/1.3.22i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1036 Lines: 22 On Sep 30, 2001 13:25 -0700, Randy.Dunlap wrote: > I'm interested in using netconsole early (during boot). > Any problems doing that, other than getting module parameters > to it? I can fix that part. I was thinking about this as well. It should be relatively easy to allow a line line "console=eth0,XX:XX:XX:XX:XX:XX,a.b.c.d" or similar. The only slight problem might be in configuring the interface early enough in the boot process. AFAIK (which isn't much in this area) the serial console has special "console" code which allows it to be used very early in the boot process. You would obviously need to have the network driver compiled into the kernel and not a module. Maybe Ingo can hack something where it is possible to initialize the network code very early in the boot process? Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert