* fedora-netdev.1 IPv6 freeze [Re: [ANNOUNCE] fedora-netdev kernel repository]
From: Pekka Savola @ 2005-11-16 10:46 UTC (permalink / raw)
To: linville, linville,
Development discussions related to Fedora Core; +Cc: netdev
In-Reply-To: <20051114205110.GK25755@redhat.com>
On Mon, 14 Nov 2005, John W. Linville wrote:
> http://people.redhat.com/linville/kernels/fedora-netdev/
I guess the test can be termed a 'success' because after updating from
2.6.14-1.1637_FC4 to 2.6.14-1.1637_FC4.netdev.1, I get 100%
reproducible kernel hang (everything just freezes as it is, no message
to /var/log/messages or anywhere) after I run '/sbin/ip -6 r l' or try
to use IPv6 in basically any other way on my ThinkPad laptop with
external orinoco_cs WLAN card.
Any thoughts for the next steps?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove ISA legacy functions
From: Al Viro @ 2005-11-16 3:56 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jeff Garzik, Adrian Bunk, Andrew Morton, linux-kernel, linux-scsi,
netdev, jonathan, tlinux-users, Jaroslav Kysela
In-Reply-To: <20051112134820.GG7992@ftp.linux.org.uk>
On Sat, Nov 12, 2005 at 01:48:20PM +0000, Al Viro wrote:
> On Fri, Nov 11, 2005 at 10:29:18PM -0700, Matthew Wilcox wrote:
> > I think they work fine everywhere. Adrian wants to remove the API they
> > use.
> >
> > I think this is a bad idea. The drivers should be converted.
>
> They are - I'll send patches later today...
NB: never say these words on a Friday night or you'll get a visit from
Murphy.
Apologies for delay, patches sent.
^ permalink raw reply
* Re: [PATCH]small fix for __ipv6_addr_type(...)
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-11-16 1:10 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: yanzheng, netdev, linux-kernel, yoshfuji
In-Reply-To: <437A5F42.3080100@hp.com>
In article <437A5F42.3080100@hp.com> (at Tue, 15 Nov 2005 17:20:50 -0500), Vlad Yasevich <vladislav.yasevich@hp.com> says:
> No, according to RFC 4007, loopback is considered a link-local
> address.
Agreed. RFC3484 also explicitly says that loopback is treated as link-local.
--yoshfuji
^ permalink raw reply
* Re: [PATCH]small fix for __ipv6_addr_type(...)
From: Vlad Yasevich @ 2005-11-15 22:20 UTC (permalink / raw)
To: Yan Zheng; +Cc: netdev, linux-kernel, yoshfuji
In-Reply-To: <4376F2CE.4050003@21cn.com>
No, according to RFC 4007, loopback is considered a link-local
address.
-vlad
Yan Zheng wrote:
> Hi.
>
> I think the scope for loopback address should be node local.
>
> Regards
>
> Signed-off-by: Yan Zheng <yanzheng@21cn.com>
>
> ========================================================================
> --- linux-2.6.15-rc1/net/ipv6/addrconf.c 2005-11-13
> 12:23:06.000000000 +0800
> +++ linux/net/ipv6/addrconf.c 2005-11-13 15:50:03.000000000 +0800
> @@ -249,7 +249,7 @@ int __ipv6_addr_type(const struct in6_ad
>
> if (addr->s6_addr32[3] == htonl(0x00000001))
> return (IPV6_ADDR_LOOPBACK | IPV6_ADDR_UNICAST |
> -
> IPV6_ADDR_SCOPE_TYPE(IPV6_ADDR_SCOPE_LINKLOCAL)); /* addr-select 3.4 */
> +
> IPV6_ADDR_SCOPE_TYPE(IPV6_ADDR_SCOPE_NODELOCAL)); /* addr-select 3.4 */
>
> return (IPV6_ADDR_COMPATv4 | IPV6_ADDR_UNICAST |
> IPV6_ADDR_SCOPE_TYPE(IPV6_ADDR_SCOPE_GLOBAL)); /*
> addr-select 3.3 */
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] ebtables: port ebt*[u]log.c to nf[netlink]_log
From: Bart De Schuymer @ 2005-11-15 18:21 UTC (permalink / raw)
To: David S. Miller
Cc: Harald Welte, netdev-u79uwXL29TY76Z2rM5mHXA,
ebtables-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi Dave,
Below is a patch from Harald, slightly altered by me to merge some
printk's.
Please apply,
Bart
[NETFILTER] ebtables: Support nf_log API from ebt_log and ebt_ulog
This makes ebt_log and ebt_ulog use the new nf_log api. This enables
the bridging packet filter to log packets e.g. via nfnetlink_log.
Signed-off-by: Bart De Schuymer <bdschuym-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
Signed-off-by: Harald Welte <laforge-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org>
--- linux-2.6.14.2/net/bridge/netfilter/Kconfig.old 2005-11-15 18:00:10.000000000 +0000
+++ linux-2.6.14.2/net/bridge/netfilter/Kconfig 2005-11-15 18:00:24.891607224 +0000
@@ -196,9 +196,13 @@ config BRIDGE_EBT_LOG
To compile it as a module, choose M here. If unsure, say N.
config BRIDGE_EBT_ULOG
- tristate "ebt: ulog support"
+ tristate "ebt: ulog support (OBSOLETE)"
depends on BRIDGE_NF_EBTABLES
help
+ This option enables the old bridge-specific "ebt_ulog" implementation
+ which has been obsoleted by the new "nfnetlink_log" code (see
+ CONFIG_NETFILTER_NETLINK_LOG).
+
This option adds the ulog watcher, that you can use in any rule
in any ebtables table. The packet is passed to a userspace
logging daemon using netlink multicast sockets. This differs
--- linux-2.6.14.2/net/bridge/netfilter/ebt_log.c.old 2005-11-15 18:00:04.000000000 +0000
+++ linux-2.6.14.2/net/bridge/netfilter/ebt_log.c 2005-11-15 18:05:38.000000000 +0000
@@ -3,6 +3,7 @@
*
* Authors:
* Bart De Schuymer <bdschuym-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
+ * Harald Welte <laforge-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org>
*
* April, 2002
*
@@ -10,6 +11,7 @@
#include <linux/netfilter_bridge/ebtables.h>
#include <linux/netfilter_bridge/ebt_log.h>
+#include <linux/netfilter.h>
#include <linux/module.h>
#include <linux/ip.h>
#include <linux/if_arp.h>
@@ -55,27 +57,30 @@ static void print_MAC(unsigned char *p)
}
#define myNIPQUAD(a) a[0], a[1], a[2], a[3]
-static void ebt_log(const struct sk_buff *skb, unsigned int hooknr,
- const struct net_device *in, const struct net_device *out,
- const void *data, unsigned int datalen)
+static void
+ebt_log_packet(unsigned int pf, unsigned int hooknum,
+ const struct sk_buff *skb, const struct net_device *in,
+ const struct net_device *out, const struct nf_loginfo *loginfo,
+ const char *prefix)
{
- struct ebt_log_info *info = (struct ebt_log_info *)data;
- char level_string[4] = "< >";
+ unsigned int bitmask;
- level_string[1] = '0' + info->loglevel;
spin_lock_bh(&ebt_log_lock);
- printk(level_string);
- printk("%s IN=%s OUT=%s ", info->prefix, in ? in->name : "",
- out ? out->name : "");
+ printk("<%c>%s IN=%s OUT=%s MAC source = ", '0' + loginfo->u.log.level,
+ prefix, in ? in->name : "", out ? out->name : "");
- printk("MAC source = ");
print_MAC(eth_hdr(skb)->h_source);
printk("MAC dest = ");
print_MAC(eth_hdr(skb)->h_dest);
printk("proto = 0x%04x", ntohs(eth_hdr(skb)->h_proto));
- if ((info->bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto ==
+ if (loginfo->type == NF_LOG_TYPE_LOG)
+ bitmask = loginfo->u.log.logflags;
+ else
+ bitmask = NF_LOG_MASK;
+
+ if ((bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto ==
htons(ETH_P_IP)){
struct iphdr _iph, *ih;
@@ -84,10 +89,9 @@ static void ebt_log(const struct sk_buff
printk(" INCOMPLETE IP header");
goto out;
}
- printk(" IP SRC=%u.%u.%u.%u IP DST=%u.%u.%u.%u,",
- NIPQUAD(ih->saddr), NIPQUAD(ih->daddr));
- printk(" IP tos=0x%02X, IP proto=%d", ih->tos,
- ih->protocol);
+ printk(" IP SRC=%u.%u.%u.%u IP DST=%u.%u.%u.%u, IP "
+ "tos=0x%02X, IP proto=%d", NIPQUAD(ih->saddr),
+ NIPQUAD(ih->daddr), ih->tos, ih->protocol);
if (ih->protocol == IPPROTO_TCP ||
ih->protocol == IPPROTO_UDP) {
struct tcpudphdr _ports, *pptr;
@@ -104,7 +108,7 @@ static void ebt_log(const struct sk_buff
goto out;
}
- if ((info->bitmask & EBT_LOG_ARP) &&
+ if ((bitmask & EBT_LOG_ARP) &&
((eth_hdr(skb)->h_proto == htons(ETH_P_ARP)) ||
(eth_hdr(skb)->h_proto == htons(ETH_P_RARP)))) {
struct arphdr _arph, *ah;
@@ -144,6 +148,21 @@ static void ebt_log(const struct sk_buff
out:
printk("\n");
spin_unlock_bh(&ebt_log_lock);
+
+}
+
+static void ebt_log(const struct sk_buff *skb, unsigned int hooknr,
+ const struct net_device *in, const struct net_device *out,
+ const void *data, unsigned int datalen)
+{
+ struct ebt_log_info *info = (struct ebt_log_info *)data;
+ struct nf_loginfo li;
+
+ li.type = NF_LOG_TYPE_LOG;
+ li.u.log.level = info->loglevel;
+ li.u.log.logflags = info->bitmask;
+
+ nf_log_packet(PF_BRIDGE, hooknr, skb, in, out, &li, info->prefix);
}
static struct ebt_watcher log =
@@ -154,13 +173,32 @@ static struct ebt_watcher log =
.me = THIS_MODULE,
};
+static struct nf_logger ebt_log_logger = {
+ .name = "ebt_log",
+ .logfn = &ebt_log_packet,
+ .me = THIS_MODULE,
+};
+
static int __init init(void)
{
- return ebt_register_watcher(&log);
+ int ret;
+
+ ret = ebt_register_watcher(&log);
+ if (ret < 0)
+ return ret;
+ if (nf_log_register(PF_BRIDGE, &ebt_log_logger) < 0) {
+ printk(KERN_WARNING "ebt_log: not logging via system console "
+ "since somebody else already registered for PF_INET\n");
+ /* we cannot make module load fail here, since otherwise
+ * ebtables userspace would abort */
+ }
+
+ return 0;
}
static void __exit fini(void)
{
+ nf_log_unregister_logger(&ebt_log_logger);
ebt_unregister_watcher(&log);
}
--- linux-2.6.14.2/net/bridge/netfilter/ebt_ulog.c.old 2005-11-15 18:00:02.000000000 +0000
+++ linux-2.6.14.2/net/bridge/netfilter/ebt_ulog.c 2005-11-15 18:00:24.000000000 +0000
@@ -3,6 +3,7 @@
*
* Authors:
* Bart De Schuymer <bdschuym-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
+ * Harald Welte <laforge-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org>
*
* November, 2004
*
@@ -115,14 +116,13 @@ static struct sk_buff *ulog_alloc_skb(un
return skb;
}
-static void ebt_ulog(const struct sk_buff *skb, unsigned int hooknr,
+static void ebt_ulog_packet(unsigned int hooknr, const struct sk_buff *skb,
const struct net_device *in, const struct net_device *out,
- const void *data, unsigned int datalen)
+ const struct ebt_ulog_info *uloginfo, const char *prefix)
{
ebt_ulog_packet_msg_t *pm;
size_t size, copy_len;
struct nlmsghdr *nlh;
- struct ebt_ulog_info *uloginfo = (struct ebt_ulog_info *)data;
unsigned int group = uloginfo->nlgroup;
ebt_ulog_buff_t *ub = &ulog_buffers[group];
spinlock_t *lock = &ub->lock;
@@ -216,6 +216,39 @@ alloc_failure:
goto unlock;
}
+/* this function is registered with the netfilter core */
+static void ebt_log_packet(unsigned int pf, unsigned int hooknum,
+ const struct sk_buff *skb, const struct net_device *in,
+ const struct net_device *out, const struct nf_loginfo *li,
+ const char *prefix)
+{
+ struct ebt_ulog_info loginfo;
+
+ if (!li || li->type != NF_LOG_TYPE_ULOG) {
+ loginfo.nlgroup = EBT_ULOG_DEFAULT_NLGROUP;
+ loginfo.cprange = 0;
+ loginfo.qthreshold = EBT_ULOG_DEFAULT_QTHRESHOLD;
+ loginfo.prefix[0] = '\0';
+ } else {
+ loginfo.nlgroup = li->u.ulog.group;
+ loginfo.cprange = li->u.ulog.copy_len;
+ loginfo.qthreshold = li->u.ulog.qthreshold;
+ strlcpy(loginfo.prefix, prefix, sizeof(loginfo.prefix));
+ }
+
+ ebt_ulog_packet(hooknum, skb, in, out, &loginfo, prefix);
+}
+
+static void ebt_ulog(const struct sk_buff *skb, unsigned int hooknr,
+ const struct net_device *in, const struct net_device *out,
+ const void *data, unsigned int datalen)
+{
+ struct ebt_ulog_info *uloginfo = (struct ebt_ulog_info *)data;
+
+ ebt_ulog_packet(hooknr, skb, in, out, uloginfo, NULL);
+}
+
+
static int ebt_ulog_check(const char *tablename, unsigned int hookmask,
const struct ebt_entry *e, void *data, unsigned int datalen)
{
@@ -240,6 +273,12 @@ static struct ebt_watcher ulog = {
.me = THIS_MODULE,
};
+static struct nf_logger ebt_ulog_logger = {
+ .name = EBT_ULOG_WATCHER,
+ .logfn = &ebt_log_packet,
+ .me = THIS_MODULE,
+};
+
static int __init init(void)
{
int i, ret = 0;
@@ -265,6 +304,13 @@ static int __init init(void)
else if ((ret = ebt_register_watcher(&ulog)))
sock_release(ebtulognl->sk_socket);
+ if (nf_log_register(PF_BRIDGE, &ebt_ulog_logger) < 0) {
+ printk(KERN_WARNING "ebt_ulog: not logging via ulog "
+ "since somebody else already registered for PF_BRIDGE\n");
+ /* we cannot make module load fail here, since otherwise
+ * ebtables userspace would abort */
+ }
+
return ret;
}
@@ -273,6 +319,7 @@ static void __exit fini(void)
ebt_ulog_buff_t *ub;
int i;
+ nf_log_unregister_logger(&ebt_ulog_logger);
ebt_unregister_watcher(&ulog);
for (i = 0; i < EBT_ULOG_MAXNLGROUPS; i++) {
ub = &ulog_buffers[i];
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
^ permalink raw reply
* Re: [PATCH 00/10]: Netfilter IPsec support
From: Marco Berizzi @ 2005-11-15 15:50 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel
In-Reply-To: <Pine.LNX.4.62.0511111243310.32138@kaber.coreworks.de>
How are handled NAT-T packets (udp/4500) with these patches?
Patrick McHardy wrote:
>
>On Fri, 11 Nov 2005, Gerd v. Egidy wrote:
>
>>Hi,
>>
>>>This is the latest set patches for netfilter IPsec support.
>>>The use of netif_rx for the innermost SA if it used transport
>>>mode has been replaced by explicit NF_HOOK calls in
>>>xfrm{4,6}_input.c.
>>
>>Could you please describe the solution you implemented a bit more? There
>>was
>>just so many back and forth that I'm confused now.
>
>OK, some explanation. In tunnel mode, packets go through the stack
>again after decapsulation and hit the PRE_ROUTING and LOCAL_IN or FORWARD
>hook, depending on if it is a local packet or is forwarded. For symetry,
>there are now some additional hooks on the output path which pass the
>packet through LOCAL_OUT and POST_ROUTING after tunnel mode transforms.
>This part behaves just as any other tunnel. Transport mode is special,
>we usually don't want to see packets before or after transport mode
>transforms except if it was the plain text packet (the transport
>mode SA is the innermost SA of the bundle). On the output path this
>already works because packets always hit netfilter before reaching
>the transforms, on the input path packets are manually passed through
>PRE_ROUTING and INPUT in this case. For NAT we do two things:
>when a packet is NATed after already beeing routed (including
>the xfrm lookup), it is routed again. If an incoming packet is NATed
>before the policy check, the policy check reconstructs how the packet
>looked before NAT.
>
>>
>>If I use it with iptables, do the transport mode packets go through INPUT
>>and
>>OUTPUT twice, decrypted and encrypted?
>
>Yes, if the transport mode transform in the innermost transform
>of the bundle (or the only one).
>
>>
>>If I use it with iptables, do the tunnel mode packets go through FORWARD
>>or
>>INPUT and OUTPUT twice, decrypted and encrypted?
>
>Yes.
>
>>Can I do NAT in tunnel and transport mode?
>
>Yes, even NATing forwarded packets and protecting them using a transport
>mode SA works.
>
>>what about the policy match patches, why are they only posted "for
>>completeness" and as 11/12 of 10? Aren't they ready yet?
>
>They should be fine.
>
^ permalink raw reply
* Re: [PATCH 02/10]: [NETFILTER]: Defer fragmentation in ip_output when connection tracking is used
From: Herbert Xu @ 2005-11-15 10:44 UTC (permalink / raw)
To: Patrick McHardy
Cc: Kernel Netdev Mailing List, Netfilter Development Mailinglist
In-Reply-To: <43740DB5.9070206@trash.net>
On Fri, Nov 11, 2005 at 03:19:17AM +0000, Patrick McHardy wrote:
> [NETFILTER]: Defer fragmentation in ip_output when connection tracking is used
>
> This allows to get rid of the okfn use in ip_refrag and save the useless
> fragmentation/defragmentation step when NAT is used.
I'm slightly uneasy about this change because for POST_ROUTING, the
defragmentation occurs in the middle of the hook, NF_IP_PRI_NAT_SRC.
This means that things like the mangle table currently sees the
fragments as opposed to the whole packet. This patch will change
that.
Now I'm not saying that this is necessarily a bad thing. In fact,
for all I know it might make more sense to do this. But we should
consider the possible implications before embarking on it.
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
* TCPXM
From: Alan Menegotto @ 2005-11-15 8:29 UTC (permalink / raw)
To: netdev
Hi.
I'm doing a graduation research where the goal is create a new protocol
in the linux kernel. The protocol choosen was TCPXM, an hybrid reliable
sender-initiated multicast/unicast aimed for small environment such as
grids.
In the last two months I studied the network subsystem, thinking about
how is the best way to struct the code, best structs, etc....
The source code will be based on source code of some other protocol
(like appletalk or ipx, for example).
Is this the right way to start the implementation? Do you have any
advices to me?
--
Thanks
Alan Menegotto
^ permalink raw reply
* Re: [BUG] netpoll is unable to handle skb's using packet split
From: David S. Miller @ 2005-11-15 6:45 UTC (permalink / raw)
To: mpm; +Cc: jeffrey.t.kirsher, linux-kernel, netdev
In-Reply-To: <20051115062947.GI31287@waste.org>
From: Matt Mackall <mpm@selenic.com>
Date: Mon, 14 Nov 2005 22:29:47 -0800
> Can we make any assumptions about the size and position of fragments.
> For instance, will the first N data bytes of a UDP packet all be in
> the same fragment?
Nope, they can be fragmented any way possible.
For packet parsing, you don't need any of this anyways.
Just use the things that the normal network input stack
uses, for example you could use something like
skb_header_pointer(), or pskb_may_pull().
For example, a clean way to parse a UDP header at the
front of an SKB is:
struct udphdr *uh, _tmp;
uh = skb_header_pointer(skb, 0, sizeof(_tmp), &_tmp);
if (uh->sport = foo && uh->dport == bar)
...
The UDP input path uses:
struct udphdr *uh;
if (!pskb_may_pull(skb, sizeof(struct udphdr)))
goto header_error;
uh = skb->h.uh;
Unfortunately, pskb_may_pull() may need to call __pskb_pull_tail()
which in turn might do a pskb_expand_head() and thus a GFP_ATOMIC
memory allocation.
^ permalink raw reply
* Re: [BUG] netpoll is unable to handle skb's using packet split
From: Matt Mackall @ 2005-11-15 6:29 UTC (permalink / raw)
To: David S. Miller; +Cc: jeffrey.t.kirsher, linux-kernel, netdev
In-Reply-To: <20051114.214130.57199557.davem@davemloft.net>
On Mon, Nov 14, 2005 at 09:41:30PM -0800, David S. Miller wrote:
> From: "David S. Miller" <davem@davemloft.net>
> Date: Mon, 14 Nov 2005 21:39:22 -0800 (PST)
>
> > From: Matt Mackall <mpm@selenic.com>
> > Date: Mon, 14 Nov 2005 21:23:58 -0800
> >
> > > What is "packet split" in this context?
> >
> > It's a mode of buffering used by the e1000 driver.
>
> BTW, the issue is that in packet split mode, the e1000 driver is
> feeding paged based non-linear SKBs into the stack on receive which is
> completely legal but aparently netpoll or something parsing netpoll RX
> packets does not handle it properly.
The bug is in netpoll. It's non-linear ignorant. We probably can't
call skb_linearize because it wants to kmalloc, but we probably can
follow the fragment. Or, worst case, we can manually linearize into an
SKB in our private pool.
Can we make any assumptions about the size and position of fragments.
For instance, will the first N data bytes of a UDP packet all be in
the same fragment?
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] - Fixes sparse warning in ipv6/ipv6_sockglue.c
From: David S. Miller @ 2005-11-15 5:43 UTC (permalink / raw)
To: lcapitulino; +Cc: akpm, linux-kernel, netdev
In-Reply-To: <20051114095422.5cc4727f.lcapitulino@mandriva.com.br>
From: Luiz Fernando Capitulino <lcapitulino@mandriva.com.br>
Date: Mon, 14 Nov 2005 09:54:22 -0200
> The patch below fixes the following sparse warning:
>
> net/ipv6/ipv6_sockglue.c:291:13: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Luiz Capitulino <lcapitulino@mandriva.com.br>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH]IPv6: small fix for ipv6_dev_get_saddr(...)
From: David S. Miller @ 2005-11-15 5:42 UTC (permalink / raw)
To: yoshfuji; +Cc: yanzheng, netdev, linux-kernel
In-Reply-To: <20051115.102237.101993116.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Tue, 15 Nov 2005 10:22:37 +0900 (JST)
> In article <43786A16.9070100@21cn.com> (at Mon, 14 Nov 2005 18:42:30 +0800), Yan Zheng <yanzheng@21cn.com> says:
>
> > The "score.rule++" doesn't make any sense for me.
> > According to codes above, I think it should be "hiscore.rule++;" .
>
> Oops, you're right.
>
> > Signed-off-by: Yan Zheng<yanzheng@21cn.com>
> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [BUG] netpoll is unable to handle skb's using packet split
From: David S. Miller @ 2005-11-15 5:41 UTC (permalink / raw)
To: mpm; +Cc: jeffrey.t.kirsher, linux-kernel, netdev
In-Reply-To: <20051114.213922.16377460.davem@davemloft.net>
From: "David S. Miller" <davem@davemloft.net>
Date: Mon, 14 Nov 2005 21:39:22 -0800 (PST)
> From: Matt Mackall <mpm@selenic.com>
> Date: Mon, 14 Nov 2005 21:23:58 -0800
>
> > What is "packet split" in this context?
>
> It's a mode of buffering used by the e1000 driver.
BTW, the issue is that in packet split mode, the e1000 driver is
feeding paged based non-linear SKBs into the stack on receive which is
completely legal but aparently netpoll or something parsing netpoll RX
packets does not handle it properly.
That's why the reporter suggested that perhaps an skb_linearize()
call could be added to fix the problem, but it is unknown whether
that call can be made in the context in which it would be needed.
^ permalink raw reply
* Re: [BUG] netpoll is unable to handle skb's using packet split
From: David S. Miller @ 2005-11-15 5:39 UTC (permalink / raw)
To: mpm; +Cc: jeffrey.t.kirsher, linux-kernel, netdev
In-Reply-To: <20051115052358.GG31287@waste.org>
From: Matt Mackall <mpm@selenic.com>
Date: Mon, 14 Nov 2005 21:23:58 -0800
> What is "packet split" in this context?
It's a mode of buffering used by the e1000 driver.
^ permalink raw reply
* Re: [BUG] netpoll is unable to handle skb's using packet split
From: Matt Mackall @ 2005-11-15 5:23 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: linux-kernel, netdev
In-Reply-To: <9929d2390511141315t2fb15b2aucbbebcbe4cec7ef1@mail.gmail.com>
On Mon, Nov 14, 2005 at 01:15:38PM -0800, Jeff Kirsher wrote:
> When using packet split, netpoll times out when doing a netdump.
What is "packet split" in this context? You ought to cc: the netdump
people as well, as it's not part of the mainline kernel.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH]IPv6: small fix for ipv6_dev_get_saddr(...)
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-11-15 1:22 UTC (permalink / raw)
To: yanzheng, davem; +Cc: netdev, linux-kernel, yoshfuji
In-Reply-To: <43786A16.9070100@21cn.com>
In article <43786A16.9070100@21cn.com> (at Mon, 14 Nov 2005 18:42:30 +0800), Yan Zheng <yanzheng@21cn.com> says:
> The "score.rule++" doesn't make any sense for me.
> According to codes above, I think it should be "hiscore.rule++;" .
Oops, you're right.
> Signed-off-by: Yan Zheng<yanzheng@21cn.com>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> /* Rule 8: Use longest matching prefix */
> - if (hiscore.rule < 8)
> + if (hiscore.rule < 8) {
> hiscore.matchlen = ipv6_addr_diff(&ifa_result->addr, daddr);
> - score.rule++;
> + hiscore.rule++;
> + }
> score.matchlen = ipv6_addr_diff(&ifa->addr, daddr);
> if (score.matchlen > hiscore.matchlen) {
> score.rule = 8;
>
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply
* [BUG] netpoll is unable to handle skb's using packet split
From: Jeff Kirsher @ 2005-11-14 21:15 UTC (permalink / raw)
To: linux-kernel, netdev, mpm
When using packet split, netpoll times out when doing a netdump.
Server logs:
--netdump[14973]: Got too many timeouts in handshaking, ignoring
client 172.0.2.250
--netdump[14973]: Got too many timeouts waiting for SHOW_STATUS for
client 172.0.2.250, rebooting it.
When packet split is not used, netpoll dumps correctly. This was
reproduced using the initial setup:
HP DL380G3 (Server)
RHEL4 U1
7170 NIC
e1000 driver
HP DL380G4 (Client)
RHEL3 U5
7170 NIC
e1000 driver
We also tested using the latest RHEL4 U2 on the client, with the same results.
Netpoll does not appear to be able to handle skb's using packet split,
a possible resolution would be to test for packet split and to use
skb_linearize() in netpoll to resolve the issue.
--
Cheers,
Jeff
^ permalink raw reply
* [ANNOUNCE] fedora-netdev kernel repository
From: John W. Linville @ 2005-11-14 20:51 UTC (permalink / raw)
To: fedora-list, fedora-announce-list, fedora-devel-list; +Cc: netdev, linux-kernel
Fedora-netdev!
This message is to announce the availability of a new Fedora-based
kernel repository. The kernels available there are based upon
the standard Fedora kernels, with the addition of current upstream
networking patches which are more recent than the Fedora kernel's
upstream base. More information is available here:
http://people.redhat.com/linville/kernels/fedora-netdev/
The purpose of this repository is two-fold: 1) to make bleeding-edge
linux kernel networking developments available to Fedora users who
need or want access to them; and, 2) to open-up the Fedora user
base as a better testing resource for the kernel netdev community.
I hope this will prove to be a win-win situation for both camps.
If you are a Fedora user with an interest or need for the latest
developments in Linux kernel networking, then _please_ try the
kernels from this repository. Your testing and feedback is greatly
appreciated, desperately requested, and graciously accepted.
Thanks in advance!
Please feel free to contact me at this address regarding these
kernels or other Fedora-related issues (especially networking).
If your interest is coming from the netdev/upstream side of the house,
you may want to contact me as linville@tuxdriver.com instead.
Thanks,
John
P.S. For those who just want to cut to the chase, do this (as root):
cd /etc/yum.repos.d
wget http://people.redhat.com/linville/kernels/fedora-netdev/fedora-netdev.repo
yum update
--
John W. Linville
linville@redhat.com
^ permalink raw reply
* Re: Re: [PATCH] ebtables: Port ebt_[u]log.c to nf[netlink]_log
From: Ingo Oeser @ 2005-11-14 12:09 UTC (permalink / raw)
To: Harald Welte
Cc: Bart De Schuymer, Linux Netdev List,
ebtables-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20051112094936.GA27644-XKR8MNpNCaUy1wpV0ib6OjPN8QKu1tr+@public.gmane.org>
Hi Harald,
would you mind merging the prink()s ...
Harald Welte wrote:
> diff --git a/net/bridge/netfilter/ebt_log.c b/net/bridge/netfilter/ebt_log.c
> --- a/net/bridge/netfilter/ebt_log.c
> +++ b/net/bridge/netfilter/ebt_log.c
> @@ -55,17 +57,19 @@ static void print_MAC(unsigned char *p)
> }
>
> #define myNIPQUAD(a) a[0], a[1], a[2], a[3]
> -static void ebt_log(const struct sk_buff *skb, unsigned int hooknr,
> - const struct net_device *in, const struct net_device *out,
> - const void *data, unsigned int datalen)
> +static void
> +ebt_log_packet(unsigned int pf, unsigned int hooknum,
> + const struct sk_buff *skb, const struct net_device *in,
> + const struct net_device *out, const struct nf_loginfo *loginfo,
> + const char *prefix)
> {
> - struct ebt_log_info *info = (struct ebt_log_info *)data;
> char level_string[4] = "< >";
> + unsigned int bitmask;
>
> - level_string[1] = '0' + info->loglevel;
> + level_string[1] = '0' + loginfo->u.log.level;
> spin_lock_bh(&ebt_log_lock);
> printk(level_string);
> - printk("%s IN=%s OUT=%s ", info->prefix, in ? in->name : "",
> + printk("%s IN=%s OUT=%s ", prefix, in ? in->name : "",
> out ? out->name : "");
>
> printk("MAC source = ");
... here ...
> @@ -75,7 +79,12 @@ static void ebt_log(const struct sk_buff
>
> printk("proto = 0x%04x", ntohs(eth_hdr(skb)->h_proto));
>
... and here?
> - if ((info->bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto ==
> + if (loginfo->type == NF_LOG_TYPE_LOG)
> + bitmask = loginfo->u.log.logflags;
> + else
> + bitmask = NF_LOG_MASK;
> +
> + if ((bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto ==
> htons(ETH_P_IP)){
> struct iphdr _iph, *ih;
>
I prefer evil printk()s over multiple ones :-)
Regards
Ingo Oeser
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
^ permalink raw reply
* [PATCH] - Fixes sparse warning in ipv6/ipv6_sockglue.c
From: Luiz Fernando Capitulino @ 2005-11-14 11:54 UTC (permalink / raw)
To: akpm; +Cc: lkml, netdev
Hi,
The patch below fixes the following sparse warning:
net/ipv6/ipv6_sockglue.c:291:13: warning: Using plain integer as NULL pointer
Signed-off-by: Luiz Capitulino <lcapitulino@mandriva.com.br>
net/ipv6/ipv6_sockglue.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -287,7 +287,7 @@ int ipv6_setsockopt(struct sock *sk, int
{
struct ipv6_txoptions *opt;
if (optlen == 0)
- optval = 0;
+ optval = NULL;
/* hop-by-hop / destination options are privileged option */
retv = -EPERM;
--
Luiz Fernando N. Capitulino
^ permalink raw reply
* [PATCH]IPv6: small fix for ipv6_dev_get_saddr(...)
From: Yan Zheng @ 2005-11-14 10:42 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, yoshfuji
The "score.rule++" doesn't make any sense for me.
According to codes above, I think it should be "hiscore.rule++;" .
Signed-off-by: Yan Zheng<yanzheng@21cn.com>
Index: net/ipv6/addrconf.c
============================================================
--- a/net/ipv6/addrconf.c 2005-11-13 12:23:06.000000000 +0800
+++ b/net/ipv6/addrconf.c 2005-11-14 18:29:27.000000000 +0800
@@ -1045,9 +1045,10 @@ int ipv6_dev_get_saddr(struct net_device
}
#endif
/* Rule 8: Use longest matching prefix */
- if (hiscore.rule < 8)
+ if (hiscore.rule < 8) {
hiscore.matchlen = ipv6_addr_diff(&ifa_result->addr, daddr);
- score.rule++;
+ hiscore.rule++;
+ }
score.matchlen = ipv6_addr_diff(&ifa->addr, daddr);
if (score.matchlen > hiscore.matchlen) {
score.rule = 8;
^ permalink raw reply
* Re: [PATCH 6/15] misc: Trim non-IPX builds
From: Adrian Bunk @ 2005-11-14 1:57 UTC (permalink / raw)
To: Matt Mackall, acme; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <7.282480653@selenic.com>
On Fri, Nov 11, 2005 at 02:35:51AM -0600, Matt Mackall wrote:
> trivial: drop unused 802.3 code if we compile without IPX
>
> (originally from http://wohnheim.fh-wedel.de/~joern/software/kernel/je/25/)
>
> Signed-off-by: Matt Mackall <mpm@selenic.com>
>
> Index: tiny/net/802/Makefile
> ===================================================================
> --- tiny.orig/net/802/Makefile 2005-03-15 00:24:59.000000000 -0600
> +++ tiny/net/802/Makefile 2005-03-15 00:25:48.000000000 -0600
> @@ -2,8 +2,6 @@
> # Makefile for the Linux 802.x protocol layers.
> #
>
> -obj-y := p8023.o
> -
> # Check the p8022 selections against net/core/Makefile.
> obj-$(CONFIG_SYSCTL) += sysctl_net_802.o
> obj-$(CONFIG_LLC) += p8022.o psnap.o
> @@ -11,5 +9,5 @@ obj-$(CONFIG_TR) += p8022.o psnap.o tr.o
> obj-$(CONFIG_NET_FC) += fc.o
> obj-$(CONFIG_FDDI) += fddi.o
> obj-$(CONFIG_HIPPI) += hippi.o
> -obj-$(CONFIG_IPX) += p8022.o psnap.o
> +obj-$(CONFIG_IPX) += p8022.o psnap.o p8023.o
> obj-$(CONFIG_ATALK) += p8022.o psnap.o
This patch isn't bad, but looking closer we could move the contents of
p8023.c as well as the contents of at least p8022.c and pe2.c into
af_ipx.c.
Is the contents of any of these three files expected to be used
outside IPX (closest candidate would be appletalk)?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [2.6 patch] rename hostap.c to hostap_main.c
From: Sam Ravnborg @ 2005-11-13 17:34 UTC (permalink / raw)
To: Adrian Bunk; +Cc: hostap, linux-kernel, jgarzik, netdev
In-Reply-To: <20051113162745.GM21448@stusta.de>
>
> AFAIK you can't build a module hostap.o consisting of multiple objects
> with the source files of one of them named hostap.c (Sam Cc'ed for this).
Correct.
Sam
^ permalink raw reply
* Re: [2.6 patch] rename hostap.c to hostap_main.c
From: Jouni Malinen @ 2005-11-13 16:46 UTC (permalink / raw)
To: Adrian Bunk; +Cc: hostap, linux-kernel, jgarzik, netdev, sam
In-Reply-To: <20051113162745.GM21448@stusta.de>
On Sun, Nov 13, 2005 at 05:27:45PM +0100, Adrian Bunk wrote:
> There's no other change.
>
> If you agree, Jeff might be able to do the
>
> mv drivers/net/wireless/hostap/hostap.c \
> drivers/net/wireless/hostap/hostap_main.c
>
> plus applying the patch below.
OK, I'm okay with that change.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [2.6 patch] rename hostap.c to hostap_main.c
From: Adrian Bunk @ 2005-11-13 16:27 UTC (permalink / raw)
To: hostap, linux-kernel, jgarzik, netdev; +Cc: sam
In-Reply-To: <20051106041543.GC8972@jm.kir.nu>
On Sat, Nov 05, 2005 at 08:15:43PM -0800, Jouni Malinen wrote:
> On Sun, Nov 06, 2005 at 01:53:43AM +0100, Adrian Bunk wrote:
> > I wanted to remove the #include "hostap_ioctl.c" from hostap.c and build
> > hostap_ioctl.c separately, but this doesn't work since hostap.c has the
> > same name as the module.
>
> Is this patch changing anything in hostap.c or is it just a rename of
> the file? Patch file is not exactly ideal for this kind of changes and I
> hope git has a better way of storing this kind of rename.
There's no other change.
If you agree, Jeff might be able to do the
mv drivers/net/wireless/hostap/hostap.c \
drivers/net/wireless/hostap/hostap_main.c
plus applying the patch below.
> I would rather not rename the file, but if this is the only way of
> getting the module built in pieces, I'm okay with the change (assuming
> nothing else changed in hostap.c in this changeset).
>...
AFAIK you can't build a module hostap.o consisting of multiple objects
with the source files of one of them named hostap.c (Sam Cc'ed for this).
> Jouni Malinen PGP id EFC895FA
cu
Adrian
<-- snip -->
I wanted to remove the #include "hostap_ioctl.c" from hostap.c and build
hostap_ioctl.c separately, but this doesn't work since hostap.c has the
same name as the module.
After renaming hostap.c this will be possible.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.14-mm2-full/drivers/net/wireless/hostap/Makefile.old 2005-11-13 17:10:33.000000000 +0100
+++ linux-2.6.14-mm2-full/drivers/net/wireless/hostap/Makefile 2005-11-13 17:11:11.000000000 +0100
@@ -1,3 +1,4 @@
+hostap-y := hostap_main.o
obj-$(CONFIG_HOSTAP) += hostap.o
obj-$(CONFIG_HOSTAP_CS) += hostap_cs.o
^ 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