* Re: [PATCH 06/13]: [IPV4/6]: Netfilter IPsec input hooks
From: Patrick McHardy @ 2005-12-04 22:49 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051204221002.GA17056@gondor.apana.org.au>
Herbert Xu wrote:
> On Sun, Dec 04, 2005 at 11:06:02PM +0100, Patrick McHardy wrote:
>
> If there is a DNAT in the way, this will jump to the very start of
> the stack. So if we have a hostile IPsec peer, and the DNAT rules
> are such that this can occur, then we could be in trouble (especially
> because policy/selector verification does not occur until all IPsec
> has been done so we can't check inner address validitiy at this point).
We could return NET_XMIT_BYPASS from ip_xfrm_transport_hook(), although
it looks a bit ugly to use NET_XMIT* on the input path.
^ permalink raw reply
* Re: Linux 2.6.15-rc5: sk98lin broken
From: Johannes Stezenbach @ 2005-12-04 23:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, shemminger, netdev
In-Reply-To: <Pine.LNX.4.64.0512032155290.3099@g5.osdl.org>
On Sat, Dec 03, 2005, Linus Torvalds wrote:
> shemminger@osdl.org:
> sk98lin: fix checksumming code
> sk98lin: add permanent address support
> sk98lin: avoid message confusion with skge
I have an Asus P4P800 "Deluxe" with 3c940 LOM.
If I ping the box I get the following:
Dec 4 22:57:02 abc kernel: [<c0103c00>] dump_stack+0x17/0x19
Dec 4 22:57:02 abc kernel: [<c03b99e9>] netdev_rx_csum_fault+0x27/0x2d
Dec 4 22:57:02 abc kernel: [<c03b75a9>] __skb_checksum_complete+0x5a/0x60
Dec 4 22:57:02 abc kernel: [<c0404c51>] icmp_error+0xbd/0x193
Dec 4 22:57:02 abc kernel: [<c0402291>] ip_conntrack_in+0x67/0x279
Dec 4 22:57:02 abc kernel: [<c03c8cbf>] nf_iterate+0x59/0x7d
Dec 4 22:57:02 abc kernel: [<c03c8d3a>] nf_hook_slow+0x57/0x106
Dec 4 22:57:02 abc kernel: [<c03d1074>] ip_rcv+0x1af/0x580
Dec 4 22:57:02 abc kernel: [<c03ba1ed>] netif_receive_skb+0x15a/0x1ef
Dec 4 22:57:02 abc kernel: [<c03ba301>] process_backlog+0x7f/0x10d
Dec 4 22:57:02 abc kernel: [<c03ba40c>] net_rx_action+0x7d/0x110
Dec 4 22:57:02 abc kernel: [<c01250a2>] __do_softirq+0x72/0xe1
Dec 4 22:57:02 abc kernel: [<c0104ed7>] do_softirq+0x5d/0x61
Dec 4 22:57:02 abc kernel: =======================
Dec 4 22:57:02 abc kernel: [<c01251fa>] irq_exit+0x48/0x4a
Dec 4 22:57:02 abc kernel: [<c0104d9d>] do_IRQ+0x5d/0x8f
Dec 4 22:57:02 abc kernel: [<c010372e>] common_interrupt+0x1a/0x20
Dec 4 22:57:02 abc kernel: [<c0100d51>] cpu_idle+0x49/0xa0
Dec 4 22:57:02 abc kernel: [<c01002d7>] rest_init+0x37/0x39
Dec 4 22:57:02 abc kernel: [<c057f8cf>] start_kernel+0x164/0x177
Dec 4 22:57:02 abc kernel: [<c0100210>] 0xc0100210
(once for each ICMP packet)
2.6.15-rc2 works fine.
Johannes
^ permalink raw reply
* Re: [RFC: -mm patch] drivers/net/wireless/hostap/hostap_main.c shouldn't #include C files
From: Jouni Malinen @ 2005-12-05 2:14 UTC (permalink / raw)
To: Adrian Bunk; +Cc: netdev, hostap, linux-kernel
In-Reply-To: <20051203122309.GD31395@stusta.de>
On Sat, Dec 03, 2005 at 01:23:09PM +0100, Adrian Bunk wrote:
> This patch contains an attempt to properly build hostap.o without
> #incude'ing C files.
Looks good. However, I did not test this now since this did not apply to
netdev-2.6 (it does not have hostap_main.c). Did the hostap.c to
hostap_main.c rename go only to -mm? I would prefer to do this kind of
changes in a single place and I thought netdev-2.6 would be that. I'm
not following -mm tree at all and it would be easier to go through
patches if they are against netdev-2.6 upstream branch.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* (no subject)
From: polpolkim6677 @ 2005-12-05 4:32 UTC (permalink / raw)
^ permalink raw reply
* antic Get promoted with one of our special accessories. stockroom
From: Merav @ 2005-12-05 10:33 UTC (permalink / raw)
To: Leon Malit; +Cc: lockmeter, netdev, knight, glover, andrews, ver, ralf, bates
Do you recall how you said you wanted a new timepiece?
Well, I fell upon an internet address that has hundreds of fantastic ones
and I honestly think you should stop by.
I'm tired of seeing your look of sorrow whenever we go to the mall and you
can't afford luxury things.
You definitely deserve something well-made and these classic pieces are
really feasible.
The shop is convenient, with a rapid dispatchment and cyber order locating
tool.
fj http://au.geocities.com/amedwreathegoodau
I can just picture the overjoyed look on your face when you pick up your
delivery.
These words, in plain English, conveyed an injunction to ring the bell. It
was answered by another Jew: puppyer than Fagin, but nearly as vile and
repulsive in appearance.
ewass eheathers exyugoslav HZ02 easma riff-format
`If she goes I shan't; and if I don't, Laurie won't like it; and it will be
very rude, after he invited only us, to go and drag in Amy. I should think
she'd hate to poke herself where she isn't wanted,' said Jo, crossly, for
she disliked the trouble of overseeing a fidgety child, when she wanted to
enjoy herself. Her tone and manner angered Amy, who began to put her boots
on, saying, in her most aggravating way, `I shall go; Meg says I may; and if
I pay for myself, Laurie hasn't anything to do with it.'
`You can't sit with us, for our seats are reserved, and you mustn't sit
alone; so Laurie will give you his place, and that will spoil our pleasure;
or he'll get another seat for you, and that isn't proper, when you weren't
asked. You shan't stir a step; so you may just stay where you are,' scolded
Jo, crosser than ever, having just pricked her finger in her hurry.
^ permalink raw reply
* ¢³øL¦
From: mahomaho094dsh @ 2005-12-05 12:39 UTC (permalink / raw)
To: netdev
j4mC34LcgrWCxIFCgXmDWoOMg3WJ74FGkeOVXCCL4I/pkF6LfIF6gsaQXIK1gtyCt4FCDQqC
sYLMg1SDQ4NngsmPb46RgrWCxIKigumCzILFk8GVyoLJi5aJwoLwkriCq4FBleWPV4K1gtyC
t4FCDQqKhJDYgsGCvYzwjduC8IuBgt+C6ZROjvsxNTAwlpyIyI/jgsyPl5CrgsaCzIt0g1SD
fIGbg2eM8I3bgvCCtYLEgt2C3IK5gvGCqYFIDQqBnZP8ie+L4IFFie+U75OZgreC14LEj5eQ
q5WJklOBQZJqkKuCzYLcgsGCvYKtl7+L4IKqinyCqYLogtyCuYLxgUINCoGdjI4xgWAyifEo
j5eQq4LJguaC6YFBlpSCzZhigrWNh4KigsUpDQqBnYqEkNiCwYK9itaMV4FBjIuNpZFPkvGB
QYNyg1eDbINYg3CBW4Nng2mBW4FBj5eQq4LMltqTSYLgl2yBWILFgrcNCmh0dHA6Ly93d3cu
NTUxNWQuY29tL35mYzUwMTIvDQqXVJWfgsiPl5Crie+I9YLNk/yJ74vggUWJ75TvgvCVpYLB
gsSTb5hegrWCxIKigtyCt4FCDQqX4oLigqmCtYFBg1SDToOJgsyPl5Crgs2I6pBsguCCooLc
grmC8YLMgsWCsojAkFOCrYK+grOCooFCDQoNCi0tDQqUepBNjtKBRoz8iOSQXpS/DQoxMDIt
MDA3NQ0Kk4yLnpNzkOeR45Nji+aOT5TUkqw2lNSSbg0KlHqQTYuRlNuCzJX7gs2CsYK/gueC
yYKymEGXjYm6grOCooFCDQptYWhvbWFobzA5NGRzaEB5YWhvby5jb20NCg==
^ permalink raw reply
* Highly Recommended Cailis fuDkW
From: Evangelina Vasquez @ 2005-12-05 13:46 UTC (permalink / raw)
To: murray
"Ci-ialis Softabs" is better than Pfizer Viiagrra
and normal Ci-ialis because:
- Guaaraantees 36 hours lasting
- Safe to take, no side effects at all
- Boost and increase se-xual performance
- Haarder e-rectiions and quick recharge
- Proven and certified by experts and doctors
- only $3.99 per tabs
Cllick heree:
http://uk.geocities.com/Dominga95177Sylas3105/
roovvQ
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: John W. Linville @ 2005-12-05 14:01 UTC (permalink / raw)
To: Ben Greear; +Cc: Al Boldi, netdev, linux-net
In-Reply-To: <4391E4FC.1040200@candelatech.com>
On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
> Al Boldi wrote:
>
> >Here specifically, ip/ifconfig is implemented upside-down requiring a
> >link/dev to exist for an address to be defined, in effect containing layer
> >3 inside layer 2, when an address should be allowed to be defined w/o a
> >link/dev much like an app is allowed to be defined w/o an address.
>
> [Removed lkml from CC list]
>
> You can add multiple virtual IP addresses to physical interfaces. It
> makes no sense to have an IP without any association to an interface
> in my opinion. Often, when you have multiple interfaces, you most
> definately
> want different IPs associated specifically with particular interfaces.
> Think about redundant paths, routers, firewalls, and such.
The association between IP addresses and links is already a bit murky.
Reference the arp_announce sysctl for what I mean. I recall Dave M.
emphasizing on at least one occassion that IP addresses belong to
the _box_, not to the link.
I think Al B.'s idea merits some consideration. I definitely think
we blur the distinctions between L2 and L3 a bit too much in places.
Of course, patches would be helpful...
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Jeroen Massar @ 2005-12-05 14:20 UTC (permalink / raw)
To: Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <20051205140057.GC24764@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
John W. Linville wrote:
<SNIP>
> Of course, patches would be helpful...
/sbin/ipadd <address>
#!/bin/sh
ip addr add $1 dev lo
/sbin/ipdel <address>
#!/bin/sh
ip addr del $1 dev lo
/sbin/ipactivate <address> <device>
#!/bin/sh
ip addr add $1 dev $2
/sbin/ipdeactivate <address> <device>
#!/bin/sh
ip addr del $1 dev $2
There are your 'patches'. Add -6's to places for IPv6 versions.
Greets,
Jeroen
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]
^ permalink raw reply
* Bug#341392: (fwd) Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
From: maximilian attems @ 2005-12-05 14:57 UTC (permalink / raw)
To: netdev; +Cc: 341392, Frans Pop
please take a look at belows BUG_ON()
at a quick glance didn't find a patch for that in git-commits-list.
belows kernel has all fixes from the latest 2.6.14.3 stable.
----- Forwarded message from Frans Pop <aragorn@tiscali.nl> -----
Subject: Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
Date: Wed, 30 Nov 2005 13:14:02 +0100
From: Frans Pop <aragorn@tiscali.nl>
To: submit@bugs.debian.org
Package: linux-2.6
Version: 2.6.14-4
Severity: serious
The following error happens on Debian Installer boot in vmware (386 kernel).
This problem was not present in -3.
The system does come up after the error, but it looks so basic (memory
management AFAICT) that I've set RC severity anyway.
Feel free to adjust if you disagree.
Cheers,
FJP
ACPI: Processor [CPU0] (supports 8 throttling states)
kmem_cache_create: duplicate cache UNIX
------------[ cut here ]------------
kernel BUG at mm/slab.c:1807!
invalid operand: 0000 [#1]
Modules linked in: unix thermal processor fan pcnet32 mii uhci_hcd usbcore
CPU: 0
EIP: 0060:[<c013c552>] Not tainted VLI
EFLAGS: 00010202 (2.6.14-2-386)
EIP is at kmem_cache_create+0x4ea/0x64c
eax: 0000002b ebx: c9c26b4c ecx: c02f8080 edx: 0000206b
esi: c0303829 edi: ca86fde9 ebp: c9c26980 esp: c988ff38
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 1605, threadinfo=c988e000 task=c98c8a70)
Stack: c02ba8f8 ca86fde4 0000000a c9a957a0 c9c2699c ffffff80 00000080 c0000000
00000080 ca870080 ca86fd60 0804e154 ca86fde4 c02410d2 ca86fde4 0000015c
00000000 00002000 00000000 00000000 ca804000 ca870080 0804e190 0804e154
Call Trace:
[<c02410d2>] proto_register+0x56/0x1b4
[<ca804000>] af_unix_init+0x0/0x5f [unix]
[<ca80400d>] af_unix_init+0xd/0x5f [unix]
[<c012e8a1>] sys_init_module+0x99/0x16c
[<c01030dd>] syscall_call+0x7/0xb
Code: c9 fc ff ff 55 e8 0f 0e 00 00 59 e9 a9 fd ff ff 90 ff 74 24 30 68 f8 a8 2b c0 e8 6e b3
fd ff ff 05 4c 16 39 c0 0f 8e cb 15 00 00 <0f> 0b 0f 07 0d a0 2b c0 58 5a e9 d7 fd ff ff b8
00 e0 ff ff 21
<6>usbcore: registered new driver usbkbd
drivers/usb/input/usbkbd.c: :USB HID Boot Protocol keyboard driver
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
----- End forwarded message -----
^ permalink raw reply
* ¿À´Ãµµ Æí¾ÈÇϼ¼¿ä?
From: ¹æ ¼±Èñ @ 2005-12-05 16:39 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: multipart/alternative, Size: 2901 bytes --]
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Marc Singer @ 2005-12-05 17:40 UTC (permalink / raw)
To: Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <20051205140057.GC24764@tuxdriver.com>
On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
> > Al Boldi wrote:
> >
> > >Here specifically, ip/ifconfig is implemented upside-down requiring a
> > >link/dev to exist for an address to be defined, in effect containing layer
> > >3 inside layer 2, when an address should be allowed to be defined w/o a
> > >link/dev much like an app is allowed to be defined w/o an address.
> >
> > [Removed lkml from CC list]
> >
> > You can add multiple virtual IP addresses to physical interfaces. It
> > makes no sense to have an IP without any association to an interface
> > in my opinion. Often, when you have multiple interfaces, you most
> > definately
> > want different IPs associated specifically with particular interfaces.
> > Think about redundant paths, routers, firewalls, and such.
>
> The association between IP addresses and links is already a bit murky.
> Reference the arp_announce sysctl for what I mean. I recall Dave M.
> emphasizing on at least one occassion that IP addresses belong to
> the _box_, not to the link.
>
> I think Al B.'s idea merits some consideration. I definitely think
> we blur the distinctions between L2 and L3 a bit too much in places.
>
> Of course, patches would be helpful...
Precisely the case. It should be the case that a box response to an
arp on *any* interface for *any* IP address known to the box.
As for changing the behavior, I haven't seen a compelling reason to
change it. IMHO, without a motivating case, we would be mucking about
without a clear goal.
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Jeroen Massar @ 2005-12-05 17:59 UTC (permalink / raw)
To: Marc Singer; +Cc: Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <20051205174010.GA14101@buici.com>
[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]
Marc Singer wrote:
> On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
>> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
<SNIP>
>> The association between IP addresses and links is already a bit murky.
>> Reference the arp_announce sysctl for what I mean. I recall Dave M.
>> emphasizing on at least one occassion that IP addresses belong to
>> the _box_, not to the link.
>
> Precisely the case. It should be the case that a box response to an
> arp on *any* interface for *any* IP address known to the box.
Thus you have the following nice setup:
10.100.10.0/24 = 10Gbit streaming network
10.100.20.0/24 = 10mbit admin network
10.100.10.1 on eth0
10.100.20.1 on eth2
Then some idiot misconfigures his client box, putting 10.100.10.42/24 on
the NIC that is supposed to be in the admin network only.
Suddenly your 10mbit link is full because the arp's get answered on this
link.
I wonder how many RFC's it violates. An interface must only answer ARP's
on the interface that it is configured on, not anything else.
There is a low level of brokeness here already. When you have:
eth0 = 10.100.10.1/24
eth1 = 192.168.1.1/24
default route towards 192.168.1.250, forwarding enabled.
SMTP on 192.168.1.1.
Now when a client from 10.100.10.5 contacts 192.168.1.1, the FORWARD
chain of iptables is skipped. The packet directly comes into INPUT.
Blocking based on the decision that it is actually being forwarded is
impossible because of this, unless you do -i eth0 -d 192.168.1.1.
Combine this with the above and you can suddenly access internal IP's
when the firewall is configured correctly to block FORWARD's from the
eth1 interface and you have an internal service on 10.100.10.1. You only
have to find a way to be local on the external interface so that you can
do arp's for internal IP's. It will be loved by pesky ISP's who limit
people and disallow them to do NAT of course.
Greets,
Jeroen
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-05 18:00 UTC (permalink / raw)
To: mbuesch; +Cc: linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <E1Eiyw4-0003Ab-FW@www1.emo.freenet-rz.de>
On Sun, 04 Dec 2005 19:50:08 +0100, mbuesch@freenet.de wrote:
> The team is in the progress of writing a SoftwareMAC layer,
> which is needed for the bcm device. The SoftMAC is still very
> incomplete. So do not expect to do any fancy stuff like WPA
> or something line that with it.
Why yet another attempt to write 802.11 stack? Sure, the one currently
in the kernel is unusable and everybody knows about it. But why not to
improve code opensourced by Devicescape some time ago instead of
inventing the wheel again and again? Yes, I know that code is not
perfect and needs a lot of work, but it is the best piece of code we
have available now. And it _does_ support WPA and such - in fact, it is
nearly complete.
Please take a look at http://kernel.org/pub/linux/kernel/people/jbenc/
Thanks,
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Ben Greear @ 2005-12-05 18:00 UTC (permalink / raw)
To: Marc Singer; +Cc: Al Boldi, netdev, linux-net
In-Reply-To: <20051205174010.GA14101@buici.com>
Marc Singer wrote:
> On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
>
>>On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
>>
>>>Al Boldi wrote:
>>>
>>>
>>>>Here specifically, ip/ifconfig is implemented upside-down requiring a
>>>>link/dev to exist for an address to be defined, in effect containing layer
>>>>3 inside layer 2, when an address should be allowed to be defined w/o a
>>>>link/dev much like an app is allowed to be defined w/o an address.
>>>
>>>[Removed lkml from CC list]
>>>
>>>You can add multiple virtual IP addresses to physical interfaces. It
>>>makes no sense to have an IP without any association to an interface
>>>in my opinion. Often, when you have multiple interfaces, you most
>>>definately
>>>want different IPs associated specifically with particular interfaces.
>>>Think about redundant paths, routers, firewalls, and such.
>>
>>The association between IP addresses and links is already a bit murky.
>>Reference the arp_announce sysctl for what I mean. I recall Dave M.
>>emphasizing on at least one occassion that IP addresses belong to
>>the _box_, not to the link.
>>
>>I think Al B.'s idea merits some consideration. I definitely think
>>we blur the distinctions between L2 and L3 a bit too much in places.
>>
>>Of course, patches would be helpful...
>
>
> Precisely the case. It should be the case that a box response to an
> arp on *any* interface for *any* IP address known to the box.
I certainly don't mind if this is a configurable, or even default
behaviour, but we also need the ability to only respond to particular
arps on particular interfaces, based on the IP addresses assigned
to those interfaces. I am able to get this particular arp binding working
today, so I'm not suggesting changes, just mentioning that there are other
configurations than what you mention that are useful to people.
> As for changing the behavior, I haven't seen a compelling reason to
> change it. IMHO, without a motivating case, we would be mucking about
> without a clear goal.
Agreed.
Thanks,
Ben
> -
> 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
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC: -mm patch] drivers/net/wireless/hostap/hostap_main.c shouldn't #include C files
From: Adrian Bunk @ 2005-12-05 18:12 UTC (permalink / raw)
To: hostap, linux-kernel, netdev; +Cc: jgarzik
In-Reply-To: <20051205021409.GB8953@jm.kir.nu>
On Sun, Dec 04, 2005 at 06:14:09PM -0800, Jouni Malinen wrote:
> On Sat, Dec 03, 2005 at 01:23:09PM +0100, Adrian Bunk wrote:
> > This patch contains an attempt to properly build hostap.o without
> > #incude'ing C files.
>
> Looks good. However, I did not test this now since this did not apply to
> netdev-2.6 (it does not have hostap_main.c). Did the hostap.c to
> hostap_main.c rename go only to -mm? I would prefer to do this kind of
> changes in a single place and I thought netdev-2.6 would be that. I'm
> not following -mm tree at all and it would be easier to go through
> patches if they are against netdev-2.6 upstream branch.
The hostap_main.c rename is in the git-netdev-all tree that gets pulled
into -mm. I don't know the exact setup of Jeff's (Cc'ed) git trees.
> Jouni Malinen
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: Broadcom 43xx first results
From: Michael Renzmann @ 2005-12-05 18:14 UTC (permalink / raw)
To: Jiri Benc; +Cc: mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <20051205190038.04b7b7c1@griffin.suse.cz>
Hi.
On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again and again?
Or, in case there is some unknown objection to the mentioned code: use
the 802.11 stack that comes along with MadWifi, which provides things
like virtual interfaces (for multiple SSID support on one physical card)
and WPA support.
Although I'm a bit biased towards MadWifi, I'd second your suggestion to
make use of the Devicescape code. The benefit of having a fully-blown
802.11 stack in the kernel that drivers can make use of has been
discussed before, so I won't go into that yet again.
Bye, Mike
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Joseph Jezak @ 2005-12-05 18:38 UTC (permalink / raw)
To: Jiri Benc
Cc: mbuesch-KuiJ5kEpwI6ELgA04lAiVw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w, NetDev
In-Reply-To: <20051205190038.04b7b7c1-IhiK2ZEFs2oCVLCxKZUutA@public.gmane.org>
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again and again? Yes, I know that code is not
> perfect and needs a lot of work, but it is the best piece of code we
> have available now. And it _does_ support WPA and such - in fact, it
> is nearly complete.
>
> Please take a look at http://kernel.org/pub/linux/kernel/people/jbenc/
We're not writing an entire stack. We're writing a layer that sits in
between the current ieee80211 stack that's already present in the kernel
and drivers that do not have a hardware MAC. Since ieee80211 is already
in use in the kernel today, this seemed like a natural and useful
extension to the existing code. I agree that it's somewhat wasteful to
keep rewriting 802.11 stacks and we considered other options, but it
seemed like a more logical choice to work with what was available and
recommended than to use an external stack.
-Joe
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-05 18:46 UTC (permalink / raw)
To: netdev; +Cc: Jiri Benc, mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <1133806444.4498.35.camel@gimli>
Michael Renzmann wrote:
> Hi.
>
> On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
>
>>Why yet another attempt to write 802.11 stack? Sure, the one currently
>>in the kernel is unusable and everybody knows about it. But why not to
>>improve code opensourced by Devicescape some time ago instead of
>>inventing the wheel again and again?
>
>
> Or, in case there is some unknown objection to the mentioned code: use
> the 802.11 stack that comes along with MadWifi, which provides things
> like virtual interfaces (for multiple SSID support on one physical card)
> and WPA support.
>
> Although I'm a bit biased towards MadWifi, I'd second your suggestion to
> make use of the Devicescape code. The benefit of having a fully-blown
> 802.11 stack in the kernel that drivers can make use of has been
> discussed before, so I won't go into that yet again.
Use the stack that's already in the kernel.
Encouraging otherwise hinders continued wireless progress under Linux.
Jeff
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-05 18:49 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <43948B13.2090509@pobox.com>
On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
> Use the stack that's already in the kernel.
>
> Encouraging otherwise hinders continued wireless progress under Linux.
There is nothing like a "802.11 stack" currently in the kernel,
regardless what James Ketrenos is saying. Sorry.
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-05 18:54 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev, mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <20051205194923.3b868d50@griffin.suse.cz>
Jiri Benc wrote:
> On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
>
>>Use the stack that's already in the kernel.
>>
>>Encouraging otherwise hinders continued wireless progress under Linux.
> There is nothing like a "802.11 stack" currently in the kernel,
> regardless what James Ketrenos is saying. Sorry.
Complete bullshit. There is obviously 802.11 generic code in the
kernel, and that's what _I_ am saying, because it's true.
If it doesn't support your favorite wireless chipset, then submit patches.
Jeff
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-05 18:55 UTC (permalink / raw)
To: Joseph Jezak; +Cc: mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <4394892D.2090100@gentoo.org>
On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> We're not writing an entire stack. We're writing a layer that sits in
> between the current ieee80211 stack that's already present in the kernel
> and drivers that do not have a hardware MAC. Since ieee80211 is already
> in use in the kernel today, this seemed like a natural and useful
> extension to the existing code. I agree that it's somewhat wasteful to
> keep rewriting 802.11 stacks and we considered other options, but it
> seemed like a more logical choice to work with what was available and
> recommended than to use an external stack.
Unfortunately, the only long-term solution is to rewrite completely the
current in-kernel ieee80211 code (I would not call it a "stack") or
replace it with something another. The current code was written for
Intel devices and it doesn't support anything else - so every developer
of a wifi driver tries to implement his own "softmac" now. I cannot see
how this can move as forward and I think we can agree this is not the
way to go.
Rewriting (or, if you like, enhancing) the current 802.11 code seems to
be wasting of time now, when nearly complete Linux stack was opensourced
by Devicescape. We can try to merge it, but I'm not convinced it is
possible, the Devicescape's stack is far more advanced.
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* [PATCH linux-2.6.15-rc5] sk98lin: rx checksum offset not set
From: Stephen Hemminger @ 2005-12-05 19:00 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Johannes Stezenbach, Linux Kernel Mailing List, netdev
In-Reply-To: <20051204234320.GA7478@linuxtv.org>
The checksum offsets for receive offload were not being set correctly.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Index: linux-2.6/drivers/net/sk98lin/skge.c
===================================================================
--- linux-2.6.orig/drivers/net/sk98lin/skge.c
+++ linux-2.6/drivers/net/sk98lin/skge.c
@@ -818,7 +818,7 @@ uintptr_t VNextDescr; /* the virtual bus
/* set the pointers right */
pDescr->VNextRxd = VNextDescr & 0xffffffffULL;
pDescr->pNextRxd = pNextDescr;
- pDescr->TcpSumStarts = 0;
+ if (!IsTx) pDescr->TcpSumStarts = ETH_HLEN << 16 | ETH_HLEN;
/* advance one step */
pPrevDescr = pDescr;
@@ -2169,7 +2169,7 @@ rx_start:
} /* frame > SK_COPY_TRESHOLD */
#ifdef USE_SK_RX_CHECKSUM
- pMsg->csum = pRxd->TcpSums;
+ pMsg->csum = pRxd->TcpSums & 0xffff;
pMsg->ip_summed = CHECKSUM_HW;
#else
pMsg->ip_summed = CHECKSUM_NONE;
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-05 19:08 UTC (permalink / raw)
To: Jiri Benc; +Cc: Joseph Jezak, mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <20051205195543.5a2e2a8d@griffin.suse.cz>
Jiri Benc wrote:
> On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
>
>>We're not writing an entire stack. We're writing a layer that sits in
>>between the current ieee80211 stack that's already present in the kernel
>>and drivers that do not have a hardware MAC. Since ieee80211 is already
>>in use in the kernel today, this seemed like a natural and useful
>>extension to the existing code. I agree that it's somewhat wasteful to
>>keep rewriting 802.11 stacks and we considered other options, but it
>>seemed like a more logical choice to work with what was available and
>>recommended than to use an external stack.
>
>
> Unfortunately, the only long-term solution is to rewrite completely the
> current in-kernel ieee80211 code (I would not call it a "stack") or
> replace it with something another. The current code was written for
> Intel devices and it doesn't support anything else - so every developer
Patently false.
ieee80211 is used by Intel. Some bits used by HostAP, which also
duplicates a lot of ieee80211 code. And bcm43xx. And another couple
drivers found in -mm or out-of-tree.
> of a wifi driver tries to implement his own "softmac" now. I cannot see
> how this can move as forward and I think we can agree this is not the
> way to go.
You're agreeing with only yourself, then?
> Rewriting (or, if you like, enhancing) the current 802.11 code seems to
> be wasting of time now, when nearly complete Linux stack was opensourced
> by Devicescape. We can try to merge it, but I'm not convinced it is
> possible, the Devicescape's stack is far more advanced.
This invalid logic is why we have a ton of wireless stacks, all
duplicating each other.
Jeff
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Christoph Hellwig @ 2005-12-05 19:10 UTC (permalink / raw)
To: Jiri Benc; +Cc: Joseph Jezak, mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <20051205195543.5a2e2a8d@griffin.suse.cz>
On Mon, Dec 05, 2005 at 07:55:43PM +0100, Jiri Benc wrote:
> Unfortunately, the only long-term solution is to rewrite completely the
> current in-kernel ieee80211 code (I would not call it a "stack") or
> replace it with something another. The current code was written for
> Intel devices and it doesn't support anything else - so every developer
> of a wifi driver tries to implement his own "softmac" now. I cannot see
> how this can move as forward and I think we can agree this is not the
> way to go.
Please stop beeing a freaking jackass. There are various projects using
the current code. It's not perfect but people are working on it. And Joseph &
friends are writing a module to support softmac cards in that framework,
which is one of the most urgently needed things right now, because all the
existing softmac frameworks don't work with that code.
And please stop your stupid devicespace advertisements. If you think the
code is so useful why don't you send patches to integrate it with the
currently existing wireless code (after cleaning up the horrible mess
it is currently)?
^ 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