* Linux 2.6.11-rc2 Got IPv6 Ready Logo Phase-1
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-05-19 10:32 UTC (permalink / raw)
To: usagi-announce, netdev, linux-kernel; +Cc: torvalds, davem, usagi-core
[-- Attachment #1: Type: Text/Plain, Size: 1302 bytes --]
Dear all,
USAGI Project is pleased to announce a special news.
The Linux mainline kernel (version 2.6.11-rc2) is approved by IPv6 Forum
in IPv6 Ready Logo Phase-1 Program <http://www.ipv6ready.org>.
[Approved Document]
o Host Role - LogoID 01-000276
<http://www.ipv6ready.org/logo_db/logo_search2.php?logoid_number=01-000276>
o Router Role - LogoID 01-000275
<http://www.ipv6ready.org/logo_db/logo_search2.php?logoid_number=01-000275>
*) For router role, radvd in usagi-tools was used at the certification.
The version of usagi-tools is sV6READYP1-20050121_20050124.
[Sources]
o Linux-2.6.11-rc2
<ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.11-rc2.tar.bz2>
(36,966,213 Bytes, md5sum: f18456c9da900820fba98576832d598c)
o USAGI tools (sV6READYP1-20050121_20050124)
<ftp://ftp.linux-ipv6.org/pub/usagi/snap/split/usagi-tool-sV6READYP1-20050121_20050124.tar.bz2>
(6,024,344 Bytes, md5sum: 199fd40a6caa80990efb61cd5f8cfbae)
Although we are allowed to use the Logo only for the certified version,
of course you can use the functionalities with the later versions,
such as 2.6.11.
Thank you.
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
USAGI Project: http://www.linux-ipv6.org
GPG FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: Network card driver problem (znb.o/tulip)
From: Kosta Todorovic @ 2005-05-19 8:02 UTC (permalink / raw)
To: jgarzik; +Cc: tulip-users, netdev
In-Reply-To: <efe3b00605031021513b7268d1@mail.gmail.com>
Whats the best 4-port NIC currently available? I'm interested in
purchasing 10 4-port NICs as a replacement for my current cards.
I am looking for 10/100Mbps and a good driver for linux (2.4.x and
2.6.x). Preferably a mainstream company but thats not priority.
Could the community please recommend the best card available? Money is
not an issue since im really interested in the best of the best.
Any suggestions?
Regards,
Kosta
On 3/11/05, Kosta Todorovic <kostodo@gmail.com> wrote:
> My company has recently purchased several ZNYX ZX274 network cards.
> These cards are Four Channel, 10/100 PCI Adapters. They use Intel chipsets.
>
> Unfortunately there exists no drivers for linux amd64 architecture.
> There are 32bit drivers found at:
> http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally
> they wont compile under my amd64 system.
>
> The driver itself is called znb.o and can be downloaded from ZNYX's
> website. I spoke to support staff there but they told me they have
> discontinued support and development for this series of cards.
>
> The system I am running gentoo and have tried both 2.4.x and 2.6.x
> kernels but no luck.
>
> Unfortunately there is NO 64bit drivers available for ANY platform. not even MS.
>
> Does anyone know of a customised znb.o driver built for amd64?
> Is there any chance of anyone modifying the source code of the driver
> to compile under a amd64 system?
>
> I've noticed that "tulip" drivers get loaded as a module at boot time.
> but they dont function correctly. (lets you start the device and
> attach ips but cant talk through it)
>
> Is there any variants of the tulip driver that will work for this?
>
> Help much appreciated.
>
>
> /proc/pci extract for network cards:
>
> Bus 5, device 5, function 0:
> Ethernet controller: Digital Equipment Corporation DECchip
> 21142/43 (#30) (rev 65).
> IRQ 30.
> Master Capable. Latency=128. Min Gnt=20.Max Lat=40.
> I/O at 0x0 [0x7f].
> Non-prefetchable 32 bit memory at 0xfa1ff400 [0xfa1ff7ff].
> Bus 5, device 4, function 0:
> Ethernet controller: Digital Equipment Corporation DECchip
> 21142/43 (#29) (rev 65).
> IRQ 29.
> Master Capable. No bursts. Min Gnt=20.Max Lat=40.
> I/O at 0x0 [0x7f].
> Non-prefetchable 32 bit memory at 0xf9f00000 [0xf9f003ff].
>
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: Evgeniy Polyakov @ 2005-05-19 7:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: herbert, netdev, davem
In-Reply-To: <20050519000809.2fca25c5.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]
On Thu, 2005-05-19 at 00:08 -0700, Andrew Morton wrote:
> Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> >
> > > Is there any reason for being able to do that?
> >
> > It was created to be able to load several different connector devices
> > from different modules [basically it was module1.ko unit=10, module2.ko
> > unit=11 and so on].
>
> Loading multiple instances of the same module so that we get multiple
> instances of its data structures? That's fairly ghastly.
It was not the same module.
it was quite different module which implemented similar functionality
and used different connector device for different purposes.
> We should remove the feature. If there is demonstrated need for multiple
> instances then it should be done by more conventional means - syscall,
> allocation of a device major then use the minor as a selector or whatever.
It is easy to use feature which prevents problems
with situation when the same socket number is used, for example,
in 2.6 kernel while connector uses it in -mm tree.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: Andrew Morton @ 2005-05-19 7:08 UTC (permalink / raw)
To: johnpol; +Cc: herbert, netdev, davem
In-Reply-To: <1116486385.21310.82.camel@uganda>
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
>
> > Is there any reason for being able to do that?
>
> It was created to be able to load several different connector devices
> from different modules [basically it was module1.ko unit=10, module2.ko
> unit=11 and so on].
Loading multiple instances of the same module so that we get multiple
instances of its data structures? That's fairly ghastly.
We should remove the feature. If there is demonstrated need for multiple
instances then it should be done by more conventional means - syscall,
allocation of a device major then use the minor as a selector or whatever.
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: Evgeniy Polyakov @ 2005-05-19 7:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: herbert, netdev, David S. Miller
In-Reply-To: <20050518234552.4aef6d02.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]
On Wed, 2005-05-18 at 23:45 -0700, Andrew Morton wrote:
> Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> >
> > On Wed, 2005-05-18 at 22:27 -0700, Andrew Morton wrote:
> > > Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > > >
> > > > Andrew Morton <akpm@osdl.org> wrote:
> > > > >
> > > > > This is the second report of this happening.
> > > > >
> > > > > FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory
> > >
> > > Ah yes, thanks. netlink_kernel_create() has a dumbish return-value protocol.
> > >
> > > > This probably means that someone has stolen the NETLINK_NFLOG id.
> > >
> > > cn_init() uses NETLINK_NFLOG. Peculiar.
> >
> > Yep...
>
> Bah.
>
> > One may use "unit" module parameter to specify different socket.
>
> Is there any reason for being able to do that?
It was created to be able to load several different connector devices
from different modules [basically it was module1.ko unit=10, module2.ko
unit=11 and so on].
> > Should I ask David Miller to allocate new one specially for connector?
>
> Dave?
>
>
> diff -puN include/linux/netlink.h~connector-netlink-id-fix include/linux/netlink.h
> --- 25/include/linux/netlink.h~connector-netlink-id-fix 2005-05-18 23:44:43.000000000 -0700
> +++ 25-akpm/include/linux/netlink.h 2005-05-18 23:44:43.000000000 -0700
> @@ -14,6 +14,7 @@
> #define NETLINK_SELINUX 7 /* SELinux event notifications */
> #define NETLINK_ARPD 8
> #define NETLINK_AUDIT 9 /* auditing */
> +#define NETLINK_CONNECTOR 10 /* kernel connector */
> #define NETLINK_ROUTE6 11 /* af_inet6 route comm channel */
> #define NETLINK_IP6_FW 13
> #define NETLINK_DNRTMSG 14 /* DECnet routing messages */
> diff -puN drivers/connector/connector.c~connector-netlink-id-fix drivers/connector/connector.c
> --- 25/drivers/connector/connector.c~connector-netlink-id-fix 2005-05-18 23:44:43.000000000 -0700
> +++ 25-akpm/drivers/connector/connector.c 2005-05-18 23:44:43.000000000 -0700
> @@ -33,7 +33,7 @@ MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Evgeniy Polyakov <johnpol@2ka.mipt.ru>");
> MODULE_DESCRIPTION("Generic userspace <-> kernelspace connector.");
>
> -static int unit = NETLINK_NFLOG;
> +static int unit = NETLINK_CONNECTOR;
> static u32 cn_idx = CN_IDX_CONNECTOR;
> static u32 cn_val = CN_VAL_CONNECTOR;
>
> _
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: Andrew Morton @ 2005-05-19 6:45 UTC (permalink / raw)
To: johnpol; +Cc: herbert, netdev, David S. Miller
In-Reply-To: <1116484313.21310.78.camel@uganda>
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
>
> On Wed, 2005-05-18 at 22:27 -0700, Andrew Morton wrote:
> > Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > >
> > > Andrew Morton <akpm@osdl.org> wrote:
> > > >
> > > > This is the second report of this happening.
> > > >
> > > > FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory
> >
> > Ah yes, thanks. netlink_kernel_create() has a dumbish return-value protocol.
> >
> > > This probably means that someone has stolen the NETLINK_NFLOG id.
> >
> > cn_init() uses NETLINK_NFLOG. Peculiar.
>
> Yep...
Bah.
> One may use "unit" module parameter to specify different socket.
Is there any reason for being able to do that?
> Should I ask David Miller to allocate new one specially for connector?
Dave?
diff -puN include/linux/netlink.h~connector-netlink-id-fix include/linux/netlink.h
--- 25/include/linux/netlink.h~connector-netlink-id-fix 2005-05-18 23:44:43.000000000 -0700
+++ 25-akpm/include/linux/netlink.h 2005-05-18 23:44:43.000000000 -0700
@@ -14,6 +14,7 @@
#define NETLINK_SELINUX 7 /* SELinux event notifications */
#define NETLINK_ARPD 8
#define NETLINK_AUDIT 9 /* auditing */
+#define NETLINK_CONNECTOR 10 /* kernel connector */
#define NETLINK_ROUTE6 11 /* af_inet6 route comm channel */
#define NETLINK_IP6_FW 13
#define NETLINK_DNRTMSG 14 /* DECnet routing messages */
diff -puN drivers/connector/connector.c~connector-netlink-id-fix drivers/connector/connector.c
--- 25/drivers/connector/connector.c~connector-netlink-id-fix 2005-05-18 23:44:43.000000000 -0700
+++ 25-akpm/drivers/connector/connector.c 2005-05-18 23:44:43.000000000 -0700
@@ -33,7 +33,7 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Evgeniy Polyakov <johnpol@2ka.mipt.ru>");
MODULE_DESCRIPTION("Generic userspace <-> kernelspace connector.");
-static int unit = NETLINK_NFLOG;
+static int unit = NETLINK_CONNECTOR;
static u32 cn_idx = CN_IDX_CONNECTOR;
static u32 cn_val = CN_VAL_CONNECTOR;
_
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: Evgeniy Polyakov @ 2005-05-19 6:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: Herbert Xu, netdev
In-Reply-To: <20050518222729.007887b8.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 810 bytes --]
On Wed, 2005-05-18 at 22:27 -0700, Andrew Morton wrote:
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >
> > Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > This is the second report of this happening.
> > >
> > > FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory
>
> Ah yes, thanks. netlink_kernel_create() has a dumbish return-value protocol.
>
> > This probably means that someone has stolen the NETLINK_NFLOG id.
>
> cn_init() uses NETLINK_NFLOG. Peculiar.
Yep...
One may use "unit" module parameter to specify different socket.
Should I ask David Miller to allocate new one specially for connector?
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: Andrew Morton @ 2005-05-19 5:27 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Evgeniy Polyakov
In-Reply-To: <E1DYcyg-0005fP-00@gondolin.me.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > This is the second report of this happening.
> >
> > FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory
Ah yes, thanks. netlink_kernel_create() has a dumbish return-value protocol.
> This probably means that someone has stolen the NETLINK_NFLOG id.
cn_init() uses NETLINK_NFLOG. Peculiar.
^ permalink raw reply
* Re: igmp snooping?
From: Jonathan Day @ 2005-05-19 5:09 UTC (permalink / raw)
To: David Stevens, hadi; +Cc: Lennert Buytenhek, netdev
The information there is excellent, but I would add
one note of caution. IGMPv3 is extensible, and one of
the early extensions out there is for privacy and
security. (No big surprise, there.)
Unless you can guarantee that an IGMPv3 packet will
not contain any extensions not directly supported by
the underlying system, how much of the information you
can snoop on once the packet has been parsed by the
kernel is going to be implementation-dependent.
Now, in 99.99% of all cases, you're not going to have
any significant IGMPv3 traffic, as barely anyone uses
it yet and IGMP specifies that the highest common
version will be used in a group. Thus, if the group
contains IPMPv2 or even IGMPv1 members, none of what
I've written is the least bit important.
If all the systems are using the same OS, then it also
doesn't matter, as anything supported in one will be
supported in the others.
Any case that is left over is the case where you may
need to intercept the traffic prior to it being parsed
by the usual IGMP handler in the kernel. Even so,
you're still using a userspace application, you'd just
want to use one of the pseudo network devices to run a
copy of the traffic to your program.
So the direst case you could possibly imagine is
certainly very doable, and most cases are considerably
easier.
--- David Stevens <dlstevens@us.ibm.com> wrote:
> If you put the interface in multicast promiscuous
> mode (set flag
> IFF_ALLMULTI),
> you can receive all hardware groups without joining.
>
> For IGMP and MLD packets, one way to do that pat in
> an application is to
> create
> a raw socket and specify the protocol there. So, to
> receive all reports
> for any version of IGMP sent to any group, you can
> create a socket like
> this:
>
> s = socket(PF_INET, SOCK_RAW, IPPROTO_IGMP);
>
>
> For MLDv1 and MLDv2 (IPv6), they are part of ICMPv6,
> but you can use
> ICMPV6_FILTER with the MLD report types to receive
> only those.
>
> You can get the receiving interface as ancillary
> data on a recvmsg()
> call with the IPV6_PKTINFO socket option on Linux
> systems
> (IPV6_RECVPKTINFO when RFC 3542 compliant) for IPv6
> and
> similarly with IP_PKTINFO with IPv4, I believe. You
> also can get this
> information by restricting the socket to receiving
> on a particular
> interface, if you don't want one socket to handle
> multiple interfaces.
> Then, you know which interface by which socket you
> received on.
>
> So, you should be able to do most, possibly all, of
> what you want at
> application level without modification to the
> kernel, if you're looking
> to do this in an application and not a kernel
> module.
>
> +-DLS
>
>
>
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/online.html
^ permalink raw reply
* Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming
From: David S. Miller @ 2005-05-19 5:00 UTC (permalink / raw)
To: niv; +Cc: jdmason, shemminger, netdev
In-Reply-To: <428BD7E7.5080207@us.ibm.com>
From: Nivedita Singhvi <niv@us.ibm.com>
Date: Wed, 18 May 2005 17:03:51 -0700
> I think this is a good thing to have, gives us performance
> gain (equivalent to using/not using checksum offload) and
> has very little impact on the bridging layer, and is
> independent of the virtualization stuff..
I agree but keep in mind that when bridging over non-checksumming
devices it will be more expensive. Especially for TCP.
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: Herbert Xu @ 2005-05-19 4:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev
In-Reply-To: <20050518202458.55a63d37.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> This is the second report of this happening.
>
> FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory
This probably means that someone has stolen the NETLINK_NFLOG id.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: Andrew Morton @ 2005-05-19 3:24 UTC (permalink / raw)
To: netdev
This is the second report of this happening.
Begin forwarded message:
Date: Wed, 18 May 2005 23:10:49 -0400
From: Nick Orlov <bugfixer@list.ru>
To: linux-kernel@vger.kernel.org
Cc: akpm@osdl.org
Subject: 2.6.12-rc4-mm[12] - ULOG problem
ipt_ULOG fails to load starting from 2.6.12-rc4-mm1 with the following
error message:
FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory
rc3-mm3 works fine.
Unfortunately, I wont have time to do a binary search till the weekend,
but I hope you'll point suspicious patch(es) without it.
Any additional info available by request.
--
With best wishes,
Nick Orlov.
^ permalink raw reply
* Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming
From: Herbert Xu @ 2005-05-19 2:41 UTC (permalink / raw)
To: Jon Mason; +Cc: shemminger, netdev
In-Reply-To: <20050518235329.GA17946@us.ibm.com>
Jon Mason <jdmason@us.ibm.com> wrote:
>
> checksum and scatter gather as features of the bridge device. In the
> case that the physical ethernet device does not support scatter
> gather or hardware checksum, dev_queue_xmit() will check the
> dev->features and do the necessary linearization and calculate the
> checksum.
Unfortunately skb_linearize is a lot more expensive than not
generating the non-linear skb's in the first place.
So this is going to hurt people using the bridge devices over
physical devices that don't support SG.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [IPSEC] Verify key payload in verify_one_algo
From: Herbert Xu @ 2005-05-19 2:15 UTC (permalink / raw)
To: David S. Miller, netdev
In-Reply-To: <20050519020302.GA20285@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Hi Dave:
We need to verify that the payload contains enough data so that
attach_one_algo can copy alg_key_len bits from the payload.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: xfrm-user-2 --]
[-- Type: text/plain, Size: 533 bytes --]
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -34,14 +34,21 @@ static int verify_one_alg(struct rtattr
{
struct rtattr *rt = xfrma[type - 1];
struct xfrm_algo *algp;
+ int len;
if (!rt)
return 0;
- if ((rt->rta_len - sizeof(*rt)) < sizeof(*algp))
+ len = (rt->rta_len - sizeof(*rt)) - sizeof(*algp);
+ if (len < 0)
return -EINVAL;
algp = RTA_DATA(rt);
+
+ len -= (algp->alg_key_len + 7U) / 8;
+ if (len < 0)
+ return -EINVAL;
+
switch (type) {
case XFRMA_ALG_AUTH:
if (!algp->alg_key_len &&
^ permalink raw reply
* Re: igmp snooping?
From: jamal @ 2005-05-19 2:13 UTC (permalink / raw)
To: David Stevens; +Cc: Lennert Buytenhek, netdev
In-Reply-To: <OF6CAB3867.F641224F-ON88257006.00079FC5-88257006.00098A9E@us.ibm.com>
On Wed, 2005-18-05 at 18:44 -0700, David Stevens wrote:
> If you put the interface in multicast promiscuous mode (set flag
> IFF_ALLMULTI),
> you can receive all hardware groups without joining.
>
> For IGMP and MLD packets, one way to do that pat in an application is to
> create
> a raw socket and specify the protocol there. So, to receive all reports
> for any version of IGMP sent to any group, you can create a socket like
> this:
>
> s = socket(PF_INET, SOCK_RAW, IPPROTO_IGMP);
>
>
> For MLDv1 and MLDv2 (IPv6), they are part of ICMPv6, but you can use
> ICMPV6_FILTER with the MLD report types to receive only those.
>
> You can get the receiving interface as ancillary data on a recvmsg()
> call with the IPV6_PKTINFO socket option on Linux systems
> (IPV6_RECVPKTINFO when RFC 3542 compliant) for IPv6 and
> similarly with IP_PKTINFO with IPv4, I believe. You also can get this
> information by restricting the socket to receiving on a particular
> interface, if you don't want one socket to handle multiple interfaces.
> Then, you know which interface by which socket you received on.
>
Better approach than i proposed.
> So, you should be able to do most, possibly all, of what you want at
> application level without modification to the kernel, if you're looking
> to do this in an application and not a kernel module.
I think it belongs in user space. I would say its probably time that STP
also got moved out. The fact it's in the kernel has hurt addition of
interesting new features.
cheers,
jamal
^ permalink raw reply
* [IPSEC] Fixed alg_key_len usage in attach_one_algo
From: Herbert Xu @ 2005-05-19 2:03 UTC (permalink / raw)
To: David S. Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
Hi Dave:
This bug was discovered by a Linux box running in a remote corner
of Australia :)
The variable alg_key_len is in bits and not bytes. The function
attach_one_algo is currently using it as if it were in bytes.
This causes it to read memory which may not be there.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: xfrm-user-1 --]
[-- Type: text/plain, Size: 649 bytes --]
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -162,6 +162,7 @@ static int attach_one_algo(struct xfrm_a
struct rtattr *rta = u_arg;
struct xfrm_algo *p, *ualg;
struct xfrm_algo_desc *algo;
+ int len;
if (!rta)
return 0;
@@ -173,11 +174,12 @@ static int attach_one_algo(struct xfrm_a
return -ENOSYS;
*props = algo->desc.sadb_alg_id;
- p = kmalloc(sizeof(*ualg) + ualg->alg_key_len, GFP_KERNEL);
+ len = sizeof(*ualg) + (ualg->alg_key_len + 7U) / 8;
+ p = kmalloc(len, GFP_KERNEL);
if (!p)
return -ENOMEM;
- memcpy(p, ualg, sizeof(*ualg) + ualg->alg_key_len);
+ memcpy(p, ualg, len);
*algpp = p;
return 0;
}
^ permalink raw reply
* Re: igmp snooping?
From: David Stevens @ 2005-05-19 1:44 UTC (permalink / raw)
To: hadi; +Cc: Lennert Buytenhek, netdev
In-Reply-To: <1116465059.6240.20.camel@localhost.localdomain>
If you put the interface in multicast promiscuous mode (set flag
IFF_ALLMULTI),
you can receive all hardware groups without joining.
For IGMP and MLD packets, one way to do that pat in an application is to
create
a raw socket and specify the protocol there. So, to receive all reports
for any version of IGMP sent to any group, you can create a socket like
this:
s = socket(PF_INET, SOCK_RAW, IPPROTO_IGMP);
For MLDv1 and MLDv2 (IPv6), they are part of ICMPv6, but you can use
ICMPV6_FILTER with the MLD report types to receive only those.
You can get the receiving interface as ancillary data on a recvmsg()
call with the IPV6_PKTINFO socket option on Linux systems
(IPV6_RECVPKTINFO when RFC 3542 compliant) for IPv6 and
similarly with IP_PKTINFO with IPv4, I believe. You also can get this
information by restricting the socket to receiving on a particular
interface, if you don't want one socket to handle multiple interfaces.
Then, you know which interface by which socket you received on.
So, you should be able to do most, possibly all, of what you want at
application level without modification to the kernel, if you're looking
to do this in an application and not a kernel module.
+-DLS
^ permalink raw reply
* Re: another git excuse patch
From: Herbert Xu @ 2005-05-19 1:28 UTC (permalink / raw)
To: jamal; +Cc: netdev, David S. Miller
In-Reply-To: <1116465825.6240.27.camel@localhost.localdomain>
On Wed, May 18, 2005 at 09:23:45PM -0400, jamal wrote:
>
> Against Herbert's ipsec-2.6.git.
>
> Small fixup to use netlink macros instead of hardcoding.
> Signed-off-by: Jamal Hadi Salim
Thanks, I'll add it to my collection.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* another git excuse patch
From: jamal @ 2005-05-19 1:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 141 bytes --]
Against Herbert's ipsec-2.6.git.
Small fixup to use netlink macros instead of hardcoding.
Signed-off-by: Jamal Hadi Salim
cheers,
jamal
[-- Attachment #2: ipsec12_p --]
[-- Type: text/plain, Size: 635 bytes --]
net/xfrm/xfrm_user.c: needs update
Index: net/xfrm/xfrm_user.c
===================================================================
--- c24f26cfe03081d10a3a3f66d5d3e503395090b4/net/xfrm/xfrm_user.c (mode:100644)
+++ uncommitted/net/xfrm/xfrm_user.c (mode:100644)
@@ -1114,9 +1114,9 @@
static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c)
{
struct sk_buff *skb;
+ int len = NLMSG_LENGTH(sizeof(struct xfrm_user_expire));
- /* fix to do alloc using NLM macros */
- skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC);
+ skb = alloc_skb(len, GFP_ATOMIC);
if (skb == NULL)
return -ENOMEM;
^ permalink raw reply
* Re: igmp snooping?
From: jamal @ 2005-05-19 1:10 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev
In-Reply-To: <20050518221401.GA11148@xi.wantstofly.org>
On Thu, 2005-19-05 at 00:14 +0200, Lennert Buytenhek wrote:
> Hi,
>
> Is someone working on igmp snooping (and/or active discovery) for
> bridging yet? I currently have a need for this, so if noone is
> working on it yet, I'll probably give it a go myself.
>
Not that i know of - someone else may.
> AFAICS, for the kernel part:
> - Add capability to add/modify/delete multicast (ethernet) addresses
> in the forwarding database. Each multicast fdb entry contains a port
> bitmask of ports that are interested in this address.
You would probably also need to do a SIOCADDMULTI for those ports -
unless bridging puts all those ports in promisc mode. If it doesnt go
promisc, you _may_ also need to worry about boundary conditions when the
tiny physical devices hardware multicast entries start overflowing.
> - Lookup multicast addresses in the forwarding path, instead of flooding
> every packet.
> - Policy decision on whether to drop or flood traffic for multicast
> addresses that have no corresponding fdb entry.
Make this configurable. i.e flood on miss, drop on miss, pass to user
space(daemon if one exists) on a miss.
> - Add capability for userland to 'steal' IGMP packets. (I.e. to be able
> to prevent them from being forwarded.)
>
That would be the the last policy above.
I think you will also need to have something that just listens to the
different IGMP variants (maybe a packet socket with a pcap filter).
The nice thing about pcap (in mmaped format) is it will tell you about
the ifindex of port it arrived on.
> And some userspace daemon that implements the necessary bits.
>
> Ideas?
>
Above. Also take note of:
http://www.ietf.org/internet-drafts/draft-ietf-magma-snoop-12.txt
Many years of experience there on snooping IGMP.
I think your most exciting challenge would be snooping IGMPv3 ;->
cheers,
jamal
^ permalink raw reply
* patch: small fixup
From: jamal @ 2005-05-19 0:36 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
My first git patch (dangerously knowledgeable after 30 minutes of
snorting blobs;->) against net-2.6.git. Consider this an excuse to send
a git patch ;->
--
Fixup simple action define to be consistent with other net/sched files
Signed-off-by: Jamal Hadi Salim
cheers,
jamal
[-- Attachment #2: act_g.p --]
[-- Type: text/x-pascal, Size: 528 bytes --]
include/net/act_generic.h: needs update
Index: include/net/act_generic.h
===================================================================
--- 999772bc591650ab8b58d2c7a225ae83ecb6697f/include/net/act_generic.h (mode:100644)
+++ uncommitted/include/net/act_generic.h (mode:100644)
@@ -2,8 +2,8 @@
* include/net/act_generic.h
*
*/
-#ifndef ACT_GENERIC_H
-#define ACT_GENERIC_H
+#ifndef _NET_ACT_GENERIC_H
+#define _NET_ACT_GENERIC_H
static inline int tcf_defact_release(struct tcf_defact *p, int bind)
{
int ret = 0;
^ permalink raw reply
* Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming
From: Nivedita Singhvi @ 2005-05-19 0:03 UTC (permalink / raw)
To: Jon Mason; +Cc: shemminger, netdev
In-Reply-To: <20050518235329.GA17946@us.ibm.com>
Jon Mason wrote:
> Currently, locally generated ethernet traffic does not take advantage of
> hardware checksum offload when acting as a child device under a bridge
> device. This is because the upper layers do not see the available
> features of the child devices only the features of the bridge device
> (which is empty).
>
> There is an easy solution for this (see patch below), include hardware
> checksum and scatter gather as features of the bridge device. In the
> case that the physical ethernet device does not support scatter
> gather or hardware checksum, dev_queue_xmit() will check the
> dev->features and do the necessary linearization and calculate the
> checksum.
>
> Signed-off-by: Jon Mason <jdmason@us.ibm.com>
>
> --- net/bridge/br_device.c.orig 2005-05-13 11:23:02.552751024 -0500
> +++ net/bridge/br_device.c 2005-05-13 11:25:39.155943720 -0500
> @@ -101,4 +101,5 @@ void br_dev_setup(struct net_device *dev
> dev->tx_queue_len = 0;
> dev->set_mac_address = NULL;
> dev->priv_flags = IFF_EBRIDGE;
> + dev->features = NETIF_F_HW_CSUM | NETIF_F_SG;
> }
Stephen,
I think this is a good thing to have, gives us performance
gain (equivalent to using/not using checksum offload) and
has very little impact on the bridging layer, and is
independent of the virtualization stuff..
thanks,
Nivedita
^ permalink raw reply
* [PATCH] Ethernet Bridging: Enable Hardware Checksumming
From: Jon Mason @ 2005-05-18 23:53 UTC (permalink / raw)
To: shemminger; +Cc: netdev
Currently, locally generated ethernet traffic does not take advantage of
hardware checksum offload when acting as a child device under a bridge
device. This is because the upper layers do not see the available
features of the child devices only the features of the bridge device
(which is empty).
There is an easy solution for this (see patch below), include hardware
checksum and scatter gather as features of the bridge device. In the
case that the physical ethernet device does not support scatter
gather or hardware checksum, dev_queue_xmit() will check the
dev->features and do the necessary linearization and calculate the
checksum.
Signed-off-by: Jon Mason <jdmason@us.ibm.com>
--- net/bridge/br_device.c.orig 2005-05-13 11:23:02.552751024 -0500
+++ net/bridge/br_device.c 2005-05-13 11:25:39.155943720 -0500
@@ -101,4 +101,5 @@ void br_dev_setup(struct net_device *dev
dev->tx_queue_len = 0;
dev->set_mac_address = NULL;
dev->priv_flags = IFF_EBRIDGE;
+ dev->features = NETIF_F_HW_CSUM | NETIF_F_SG;
}
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf @ 2005-05-18 23:31 UTC (permalink / raw)
To: David Stevens; +Cc: Herbert Xu, netdev, netdev-bounce, rick.jones2
In-Reply-To: <OFD80D42F2.31DFC921-ON88257005.007ABBCD-88257005.007B23EA@us.ibm.com>
* David Stevens <OFD80D42F2.31DFC921-ON88257005.007ABBCD-88257005.007B23EA@us.ibm.com> 2005-05-18 15:24
> If you're going to add an IP option, you can eliminate the
> problem entirely. Just add an "extended IP ID" IP option and give
> it as many bits as you want-- make that the high order of an n+16-bit
> IP ID.
I was thinking of something more nasty such as using as value
for this flag (IP_DF|IP_MF) ;->
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Nivedita Singhvi @ 2005-05-18 22:39 UTC (permalink / raw)
To: David Stevens; +Cc: Herbert Xu, netdev, netdev-bounce, rick.jones2, Thomas Graf
In-Reply-To: <OFD80D42F2.31DFC921-ON88257005.007ABBCD-88257005.007B23EA@us.ibm.com>
David Stevens wrote:
> netdev-bounce@oss.sgi.com wrote on 05/18/2005 02:46:54 PM:
>
>
>>Thomas Graf <tgraf@suug.ch> wrote:
>>
>>>Wild thought: We could introduce a new ip option stating that the id
>>>generator uses a serial approach which would give us the possibility
>>>to measure the absolute distance and resolve this issue in a perfect
>>>matter for everyone supporting this extension. ;->
>
>
>>Well Linux does that anyway (apart from Suse) so all we need to do
>>is to tell everyone doing NFS over gigabit to use Linux :)
>
>
> If you're going to add an IP option, you can eliminate the
> problem entirely. Just add an "extended IP ID" IP option and give
> it as many bits as you want-- make that the high order of an n+16-bit
> IP ID.
> The IP timestamp option, if done per frag and required to be
> the same for all frags, could be used in this way, since you
> presumably won't wrap without incrementing that by at least 1. :-)
>
> +-DLS
Whatever happened to UDP Path MTU? While we're at this, can't
we start kicking some path-MTU-broken butt?
thanks,
Nivedita
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox