* 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
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-05 19:11 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <43948CC8.6000107@pobox.com>
On Mon, 05 Dec 2005 13:54:00 -0500, Jeff Garzik wrote:
> 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.
I have no favorite chipset. I read tons of source code of different
drivers instead. Current 802.11 code supports no management stuff at
all. And nearly every driver needs support for it - ask any developer of
wireless driver except James Ketrenos (oh, wait a moment - although ipw
devices do, unlike other devices, a lot of work in firmware, he is
implementing in the driver some management stuff too - strange, is not
his own "stack" good enough even for himself?).
And, as you might notice, I sent many patches. Only minor ones were
accepted. And then I started (and attended) a debate among wireless
developers about concepts of 802.11 stack, do you remember? And it gave
us interesting results. That results were implemented (patches were sent
and not accepted).
It may appears that I stopped afterwards, but it is not true. Nearly
after that debate had finished, Jouni announced opensourcing of the
stack he has been working on for several years. From that time I have
been trying to get familiar with that stack, it is quite complex. I have
one semi-working driver for it now and I think I know about issues of
the stack.
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: Linux 2.6.15-rc5: sk98lin broken
From: Bill Davidsen @ 2005-12-05 19:13 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: Linux Kernel Mailing List, shemminger, netdev
In-Reply-To: <20051204234320.GA7478@linuxtv.org>
Johannes Stezenbach wrote:
> 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.
I can confirm that 2.6.15-rc3 works as well:
eth0: 3Com Gigabit LOM (3C940)
PrefPort:A RlmtMode:Check Link State
ip_tables: (C) 2000-2002 Netfilter core team
ip_tables: (C) 2000-2002 Netfilter core team
eth0: network connection up using port A
speed: 100
autonegotiation: yes
duplex mode: full
flowctrl: symmetric
irq moderation: disabled
scatter-gather: enabled
No messages from ping, although the pig is somewhat slower than I would
expect, ~200us response time.
Looks like a regression, I can't try the latest kernel until Friday,
it's 260 miles round trip to the machine if it doesn't boot cleanly.
>
>
> Johannes
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-05 19:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Joseph Jezak, mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <4394902C.8060100@pobox.com>
On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik wrote:
> 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.
Hostap uses only encryption code, which was copied from - guess who -
hostap. Everything other must be done by the hostap driver itself.
bcm43xx can use - like every other driver - only constants and defines
from ieee80211.h. This is the reason why they are trying to implement
"softmac" on top of it. But that work was already done by Jouni.
> > 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?
I meant that every driver tries to implements its own "softmac". This is
not the way to go, right?
> > 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.
Heh? We have one nearly finished stack (and no, it's not the one in
kernel). Why should we try to implement a new stack instead of fixing
some issues of the nearly finished one?
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [PATCH linux-2.6.15-rc5] sk98lin: rx checksum offset not set
From: Johannes Stezenbach @ 2005-12-05 19:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, Linux Kernel Mailing List, netdev
In-Reply-To: <20051205110040.47adf428@localhost.localdomain>
On Mon, Dec 05, 2005, Stephen Hemminger wrote:
> The checksum offsets for receive offload were not being set correctly.
>
> Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
I can confirm that this patch fixes the problem for me.
Thanks,
Johannes
> 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: Jiri Benc @ 2005-12-05 19:31 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Joseph Jezak, mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <20051205191008.GA28433@infradead.org>
On Mon, 5 Dec 2005 19:10:08 +0000, Christoph Hellwig wrote:
> Please stop beeing a freaking jackass. There are various projects using
> the current code. It's not perfect but people are working on it.
Yes, and everyone implements his own softmac (this is the third one I
know about). I tried to put all of these efforts together (google
through the netdev archives) and wrote many patches.
> 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 authors of rtl8180 did it too. And authors of adm8211 too.
> 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)?
This is what I'm doing last two months. But it's not so easy to clean it
up and it seems that nobody else is interested. But it has all of the
features you need (except active scanning) - this is the reason I
stopped to work on improving current in-kernel 802.11 code and focused
on Devicescape's code. It is several years beyond the state that current
code is at now. And it is not an advertisement, it is a fact.
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Christoph Hellwig @ 2005-12-05 19:41 UTC (permalink / raw)
To: Jiri Benc
Cc: Christoph Hellwig, Joseph Jezak, mbuesch, linux-kernel,
bcm43xx-dev, NetDev
In-Reply-To: <20051205203121.48241a08@griffin.suse.cz>
On Mon, Dec 05, 2005 at 08:31:21PM +0100, Jiri Benc wrote:
> > 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 authors of rtl8180 did it too. And authors of adm8211 too.
None of them made it into the kernel tree. As soon as we'll have an
acceptable one everyone will have to use and improve it. I personally
couldn't care less what we start with.
> > 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)?
>
> This is what I'm doing last two months. But it's not so easy to clean it
> up and it seems that nobody else is interested. But it has all of the
> features you need (except active scanning) - this is the reason I
> stopped to work on improving current in-kernel 802.11 code and focused
> on Devicescape's code. It is several years beyond the state that current
> code is at now. And it is not an advertisement, it is a fact.
That's because you still don't get how we do development. The last thing
we want is full-scale rewrites. Submit patches to fix things based on
whatever you want but do it incremental. Anything that just moves existing
functionaly out of the place and adds duplicates with more functionality/
cleaner API/<buzzword of the day> is simply not acceptable.
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Dave Jones @ 2005-12-05 19:53 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jiri Benc, Joseph Jezak, mbuesch, linux-kernel, bcm43xx-dev,
NetDev
In-Reply-To: <4394902C.8060100@pobox.com>
On Mon, Dec 05, 2005 at 02:08:28PM -0500, Jeff Garzik wrote:
> 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.
Orinoco also uses it now no ?
Dave
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-05 20:09 UTC (permalink / raw)
To: Dave Jones
Cc: Jiri Benc, Joseph Jezak, mbuesch, linux-kernel, bcm43xx-dev,
NetDev
In-Reply-To: <20051205195329.GB19964@redhat.com>
Dave Jones wrote:
> On Mon, Dec 05, 2005 at 02:08:28PM -0500, Jeff Garzik wrote:
> > 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.
>
> Orinoco also uses it now no ?
Just the headers, really.
Jeff
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: John W. Linville @ 2005-12-05 20:10 UTC (permalink / raw)
To: Ben Greear; +Cc: Marc Singer, Al Boldi, netdev, linux-net
In-Reply-To: <43948049.3040508@candelatech.com>
On Mon, Dec 05, 2005 at 10:00:41AM -0800, Ben Greear wrote:
> Marc Singer wrote:
> >On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
> >>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.
>
> 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
It was not my intention to derail this discussion to the arp_announce
topic. I only cited it as an example where the IP address <->
interface mapping is not 100% absolute.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-05 20:11 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Joseph Jezak, mbuesch, linux-kernel, NetDev
In-Reply-To: <20051205194146.GA29317@infradead.org>
On Mon, 5 Dec 2005 19:41:46 +0000, Christoph Hellwig wrote:
> None of them made it into the kernel tree. As soon as we'll have an
> acceptable one everyone will have to use and improve it. I personally
> couldn't care less what we start with.
Same with me.
> That's because you still don't get how we do development. The last thing
> we want is full-scale rewrites. Submit patches to fix things based on
> whatever you want but do it incremental.
We have got almost finished and working stack. Everything we need to do
is:
1. identify issues;
2. fix the issues; some of them will need broader discussion;
3. split it into several (potentially a lot of) reviewable patches;
4. clean up the drivers.
I'm in phase 2 now (no interesting results yet). I don't think it is
possible to start by phase 3 and then skip back to 1 and 2... This is
the reason I didn't post anything yet (or did you see some bloated
everything-rewriting patch from me posted on the list?).
But I also don't think it is worth effort to reinvent wheel by writing all
of the stuff again. This is the reason I started to examine Devicescape
code, nothing more.
And if you are familiar with the current in-kernel 802.11 code (and if
you know at least two different drivers), you will probably agree that
many things have to be changed in the current code even if we decided to
build on the top of it, so the result will finally differ a lot and will
be almost incompatible with the current code. (Why? I think I wrote some
explanation already to netdev list - if you don't find it or it is not
understandable, please let me know, I will try again.)
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Michael Buesch @ 2005-12-05 20:23 UTC (permalink / raw)
To: Jiri Benc
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w, NetDev
In-Reply-To: <20051205190038.04b7b7c1-IhiK2ZEFs2oCVLCxKZUutA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]
On Monday 05 December 2005 19:00, you wrote:
> On Sun, 04 Dec 2005 19:50:08 +0100, mbuesch-KuiJ5kEpwI6ELgA04lAiVw@public.gmane.org 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.
This is __not__ "yet another stack". It is an _extension_.
It is all about management frames, which the in-kernel code
does not manage.
We want a working device. The driver is in a state where it
is more or less usable. What is missing, is code to handle
management.
We tried the code from the RTL driver, but it is total crap.
We dropped it again. We thought about using yet another out of
kernel ieee80211 stack, but we began to write an extension
to the in-kernel code. If that was right or wrong, well, that's
the question.
If you _really_ think we should have used $EXTERNAL_STACK,
go and patch the driver to work with it. I would really like
to see it working. It is easy to change the used 80211 stack,
as it is only a task of replacing TX and RX function calls
(and a few parameter settings to the ieee struct on init).
PS: I forgot to mention in the announcement, that the driver has
problems with OFDM (that are all 802.11g) rates. So use 802.11b
rates. 11MBit works fine.
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-05 20:42 UTC (permalink / raw)
To: Michael Buesch; +Cc: linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <200512052123.42357.mbuesch@freenet.de>
On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
> This is __not__ "yet another stack". It is an _extension_.
> It is all about management frames, which the in-kernel code
> does not manage.
But this code should be part of the stack, as nearly every driver needs
it. Management handling should be really managed by the kernel. The same
applies to driver<->userspace communication - there is no need to bother
every driver with it. And so on.
The hard part is that every driver will need a slightly different amount
of this support depending on the amount of features that are provided by
firmware.
> We want a working device. The driver is in a state where it
> is more or less usable. What is missing, is code to handle
> management.
I understand.
> We tried the code from the RTL driver, but it is total crap.
> We dropped it again. We thought about using yet another out of
> kernel ieee80211 stack, but we began to write an extension
> to the in-kernel code. If that was right or wrong, well, that's
> the question.
>
> If you _really_ think we should have used $EXTERNAL_STACK,
> go and patch the driver to work with it.
No. I just think we (everybody) should concentrate at one particular
stack, finish it and merge it. And I'm convinced Jouni's stack is
currently the best solution available - far far from perfect, with many
issues, but still the best - and it will finally save as much time.
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Al Boldi @ 2005-12-05 20:48 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-net, Ben Greear
In-Reply-To: <20051205140057.GC24764@tuxdriver.com>
John W. Linville 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.
> >
> 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...
I am envisaging a complete decoupling of the current implementation to
achieve OSI compliance. And that's not for the sake of OSI but for the sake
of scalability.
This means that it should be possible define a layer 3 network architecture
completely independent of a layer 2 link architecture.
This also means that we are free to choose means other than a layer 2 link to
fulfill layer 3 requests and vice/versa.
And it may open the door to many other things... due to scalability.
Thanks!
--
Al
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Marc Singer @ 2005-12-05 20:56 UTC (permalink / raw)
To: Jeroen Massar; +Cc: Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <43947FEB.7020504@unfix.org>
On Mon, Dec 05, 2005 at 06:59:07PM +0100, Jeroen Massar wrote:
> 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.
Huh? The arp requests don't establish routing and they aren't a
significant source of traffic. Besides, all I suggested is that if a
machine receives an arp request on eth2 for an address it has on
10.100.10/24, it should answer with it's MAC address on eth2.
My readings of the RFC do not address this issue directly. My
understand of this behaviour is from a discussion with someone
regarding iptables.
Moreover, if you allow users to willy-nilly connect to your networks,
you've got a completely different kind of problem on your hands.
^ 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