headers
Andrew Morton | 1 Sep 2004 01:50

Fw: [PATCH] Fix of wrong ipt debug messages


Begin forwarded message:

Date: Tue, 31 Aug 2004 18:42:05 +0400
From: Kirill Korotaev <kksx <at> mail.ru>
To: torvalds <at> osdl.org, akpm <at> osdl.org
Cc: linux-kernel <at> vger.kernel.org
Subject: [PATCH] Fix of wrong ipt debug messages

This patch fixes wrong ipt debug messages.
The problem is that when CONFIG_NETFILTER_DEBUG is set,
parp_redo() can flood debug output like this:

Mar 13 19:57:19 ts1 nf_hook: hook 0 already set.
Mar 13 19:57:19 ts1 skb: pf=0 (unowned) dev=eth0 len=46
.......

Kirill
Attachment (diff-ipt-nfdbgarp-20030317): application/octet-stream, 337 bytes
Permalink | Reply | 0 comments |
headers
Nivedita Singhvi | 1 Sep 2004 02:49
Picon
Favicon

Re: Fw: Re: 2.6.9-rc1-mm2

Andrew Morton wrote:

> Getting an error of:
> 
> net/built-in.o(.text+0x64047): In function `tcp_in_window':
> net/ipv4/netfilter/ip_conntrack_proto_tcp.c:683: undefined reference to `ip_ct_log_invalid'
> net/built-in.o(.text+0x6431f): In function `tcp_error':
> net/ipv4/netfilter/ip_conntrack_proto_tcp.c:792: undefined reference to `ip_ct_log_invalid'
> net/built-in.o(.text+0x64421):net/ipv4/netfilter/ip_conntrack_proto_tcp.c:817: undefined
reference to `ip_ct_log_invalid'
> net/built-in.o(.text+0x64450):net/ipv4/netfilter/ip_conntrack_proto_tcp.c:808: undefined
reference to `ip_ct_log_invalid'
> net/built-in.o(.text+0x64487):net/ipv4/netfilter/ip_conntrack_proto_tcp.c:784: undefined
reference to `ip_ct_log_invalid'
> net/built-in.o(.text+0x6478a):net/ipv4/netfilter/ip_conntrack_proto_tcp.c:877: more
undefined references to `ip_ct_log_invalid' follow
> 
> The error is for all references of the LOG_INVALID macro in
> ip_conntrack_proto_tcp.c.  My guess is that the declaration of
> ip_ct_log_invalid in ip_conntrack_standalone.c landed under a new #define
> that I'm not using in this set of patches, but I can't find where.
> 
> All-important config file appended below.  This is an older config file, but
> make oldconfig was done first, per normal.

>
> # IP: Netfilter Configuration
> #
> # CONFIG_IP_NF_CONNTRACK is not set
> # CONFIG_IP_NF_QUEUE is not set
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jouni Malinen | 1 Sep 2004 04:22
Picon
Picon

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

On Tue, Aug 31, 2004 at 05:37:19PM -0400, Luis R. Rodriguez wrote:
> On Tue, Aug 31, 2004 at 10:14:38PM +0300, Vladimir Kondratiev wrote:
> > - Security is not up-to date either. We need .1x, EAS, TKIP etc. This need to 
> > be done for modern cards to use this infrastructure.
> 
> This is handled by hostap wpa_supplicant now, which is going to be part
> of WE18. The question I think is whether somoene plans on re-doing it on
> wireless-2.6, since as you mentioned it seems WE are being redone on
> davem's patch.

This sounds somewhat confusing.. As far as WPA and IEEE 802.11i
(RSN/WPA2) are concerned, there are number of different components
involved.

One part is in IEEE 802.11 data frame handling (TKIP, CCMP). This is
implemented, e.g., in the current Host AP RX/TX paths more or less
completely. The current implementation is still hardcoded to do this in
software, so it would need to be extended to support offloading
encryption to the wlan card since many of the modern cards have hardware
(or combination of hardware/firmware) implementation of TKIP and CCMP.
In addition, IEEE 802.11e will add some small changes to TKIP/CCMP
processing; Host AP code has places for this for TX (mainly, setting
priority value in the header). RX needs some more work because of
possible reordering of packets with different priorities. This all lives
in the generic 802.11 stack of the kernel.

In addition to data encryption, IEEE 802.11i defines key management
protocol (4-Way/PTK handshake, 2-Way/Group Key handshake) and
optimizations for full IEEE 802.1X authentication (PMKSA caching,
pre-authentication). IEEE 802.1X and EAP authentication is on similar
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Anastasov | 1 Sep 2004 07:04
Picon
Favicon

Re: [RFC] MASQUERADE / policy routing ("Route send us somewhere else")


	Hello,

On Wed, 1 Sep 2004, Herbert Xu wrote:

> > I was mistaken.  In the mpath case there is no source address per
> > nexthop.
>
> Actually, that should still work.
>
> For example, if you're like me and the nexthops all go to different
> devices then it's obviously OK as inet_select_addr will pick the
> right one for the device.  If they're going through the same device
> but to different gateways then it'll still pick the right one for
> the given gateway.

	Yes, if the targets are from some of the GW's subnets. It
is a masquerade drawback not to match by GW because the routing
does not support it but the world is not perfect.

Regards

--
Julian Anastasov <ja <at> ssi.bg>
Permalink | Reply | 0 comments |
headers
Arjan van de Ven | 1 Sep 2004 09:02
Picon
Favicon

Re: [Announce] Update on ipw2100, ipw2200, and support for Intel PRO/Wireless 2915ABG

On Tue, 2004-08-31 at 23:08, James Ketrenos wrote:
> It's been a while since I've updated lkml and netdev on the progress of
> the ipw projects.  Given the recent announcement by Intel for the
> introduction of Intel PRO/Wireless 2915 ABG Network Connection miniPCI
> adapter, I thought now was a good time...

you guys seem to be doing a really great job on these drivers; thanks!
Permalink | Reply | 0 comments |
headers
Rick Lindsley | 1 Sep 2004 10:33
Picon
Favicon

Re: Fw: Re: 2.6.9-rc1-mm2

Thanks for pointing out the specific config options.

Granted a more recent config is warranted .. the one I'm using is
2.6.0-based.  But considering I ran make oldconfig on this and chose
the defaults in each and every case, should I end up with a config that
doesn't compile?  Is there still a config issue here, especially
considering that both rc1 and rc1-mm1 compiled fine using this method?
Or is make oldconfig only going to help for a version or two back?

Rick
Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Sep 2004 10:41

Re: Fw: Re: 2.6.9-rc1-mm2

Rick Lindsley <ricklind <at> us.ibm.com> wrote:
>
> But considering I ran make oldconfig on this and chose
>  the defaults in each and every case, should I end up with a config that
>  doesn't compile?

No, you shouldn't.  This indicates a Kconfig bug.
Permalink | Reply | 0 comments |
headers
YOSHIFUJI Hideaki / 吉藤英明 | 1 Sep 2004 11:02
X-Face
Gravatar

Re: 2.6.9-rc1 oops

In article <1094028647.16908.42.camel <at> hostmaster.org> (at Wed, 01 Sep 2004 10:50:47 +0200), Thomas
Zehetbauer <thomasz <at> hostmaster.org> says:

> I have now created a bug report for this issue:
> http://bugzilla.kernel.org/show_bug.cgi?id=3323

(Plase use netdev...)
I think this is already fixed in current bk tree.

--yoshfuji
Permalink | Reply | 0 comments |
headers
Zhikui Chen | 1 Sep 2004 12:23
Picon
Favicon

Re: HELP for dccp implementation.

Hi, all

If I assign a value such as 0x ee9fbc00 to sk in dccp_rcv (before lookup 
calling), and comment lookkup calling, I get a error report from 
bh_lock_sock(sk) calling inside dccp_rcv, which error report is  
spin_is_locked on uninitialized spinlock ee9fbc00, and spin_lock 
(<NULL>:ee9fbc00) already locked by <NULL>/73.

Do you know its reason? Thanks,

Best regards,

Zhikui

i there,

>Could you please work with 
>Arnaldo Carvalho de Melo <acme <at> conectiva.com.br> since he is
>already working on this - this way we could have a coherent
>implementation.
>He is quiet knowledgeable on the internals of Linux and you could bring
>in the protocol expertise.
>
>cheers,
>jamal
>
>On Wed, 2004-08-25 at 12:46, Zhikui Chen wrote:
>  
>
>>Hi, dear all
(Continue reading)

Permalink | Reply | 2 comments |
headers
Srivatsa Vaddagiri | 1 Sep 2004 13:36
Picon

Re: [RFC] Use RCU for tcp_ehash lookup

On Tue, Aug 31, 2004 at 03:54:20PM +0200, Andi Kleen wrote:
> I bet also when you just do rdtsc timing for the TCP receive
> path the cycle numbers will be way down (excluding the copy).

I got cycle numbers for the lookup routine (with CONFIG_PREEMPT turned off).
They were taken on a 900MHz 8way Intel P3 SMP box.  The results are as below:

-------------------------------------------------------------------------------
			     |	2.6.8.1		      |	2.6.8.1 + my patch
-------------------------------------------------------------------------------
Average cycles 		     |			      |
spent in 		     |			      |
__tcp_v4_lookup_established  |	2970.65               |	668.227
			     | (~3.3 micro-seconds)   | (~0.74 microseconds)
-------------------------------------------------------------------------------

This repesents improvement by a factor of 77.5%!

> 
> And it should also fix the performance problems with
> cat /proc/net/tcp on ppc64/ia64 for large hash tables because the rw locks 
> are gone.

But spinlocks are in! Would that still improve the performance compared to rw 
locks?  (See me earlier note where I have explained that lookup done for 
/proc/net/tcp is _not_ lock-free yet).

> I haven't studied it in detail (yet), just two minor style 
> comments:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane