* Re: [RFC] ip / ifconfig redesign
From: John Heffner @ 2005-12-05 22:56 UTC (permalink / raw)
To: Jeroen Massar; +Cc: Marc Singer, Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <4394C3D4.9050909@unfix.org>
Jeroen Massar wrote:
> John Heffner wrote:
>
>>Jeroen Massar wrote:
>>
>>>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.
>>
>>Not true. See RFC 1122, section 3.3.4. The standard leaves this
>>decision up to the implementation, for good reason.
>
>
> RFC1122 is a document about multicast. ARP is broadcast see the very old
> RFC826/STD0037. Multicast didn't even work on much of the hardware from
> the times that that document was written.
??? RFC 1122 is the Hosts Requirements RFC. It applies to any host
implementing IP. Maybe you're thinking of 1112?
-John
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Jeroen Massar @ 2005-12-05 22:48 UTC (permalink / raw)
To: John Heffner; +Cc: Marc Singer, Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <4394BCD5.1060505@psc.edu>
[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]
John Heffner wrote:
> Jeroen Massar wrote:
>> 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.
>
> Not true. See RFC 1122, section 3.3.4. The standard leaves this
> decision up to the implementation, for good reason.
RFC1122 is a document about multicast. ARP is broadcast see the very old
RFC826/STD0037. Multicast didn't even work on much of the hardware from
the times that that document was written.
Probably the best text about this subject can be found in RFC1027:
8<-----------
2.4 Sanity checks
Care must be taken by the network and gateway administrators to keep
the network masks the same on all the subnet gateway machines. The
most common error is to set the network mask on a host without a
subnet implementation to include the subnet number. This causes the
host to fail to attempt to send packets to hosts not on its local
subnet. Adjusting its routing tables will not help, since it will
not know how to route to subnets.
If the IP networks of the source and target hosts of an ARP request
are different, an ARP subnet gateway implementation should not
reply. This is to prevent the ARP subnet gateway from being used to
reach foreign IP networks and thus possibly bypass security checks
provided by IP gateways.
-------------->8
Which is almost the same as what I noted. Note that the document is
about Proxy ARP, when a host is responding ARP queries for an IP on a
different link, this is exactly what it is doing: proxy arp.
> This topic has been discussed many times on a variety of mailing lists.
> I think the best way to do this is to make the behavior configurable,
> which Linux currently does.
As long as the default is off I am fine with it, people turning it on
themselves break their own network :)
Greets,
Jeroen
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Rick Jones @ 2005-12-05 22:43 UTC (permalink / raw)
To: John Heffner
Cc: Jeroen Massar, Marc Singer, Ben Greear, Al Boldi, netdev,
linux-net
In-Reply-To: <4394BF9E.90303@psc.edu>
John Heffner wrote:
> Rick Jones wrote:
>
>> That's the discussion related to things like the "Strong ES" (end
>> system) model right? As such, isn't that discussing what _IP_ may do
>> rather than what ARP may do? 1122 doesn't say much about the
>> interfaces/MAC's that should be part of a given ARP reply. ARP seems
>> to be RFC 826 and probably others, and the algorithm described in 826
>> doesn't seem to be specific on the topic of interfaces - at least not
>> to my really brief read.
>>
>> rick jones
>
>
> Yes, but if an interface will accept packets for a certain IP address,
> and will send packets with that IP address, is there any reason it can't
> ARP for that address?
If ARP RFC's say it shouldn't :) (I don't know that it does) ARP is ARP,
accepting IPs is IP. The maze of twisty passages may be similar, but they are
distinct.
Is a MAC address a property of the host, or of the interface connected to the host?
rick jones
is on netdev, so no need for direct reply to my address...
^ permalink raw reply
* Registration Confirmation
From: office @ 2005-12-05 22:37 UTC (permalink / raw)
To: ralf
[-- Attachment #1: Type: text/plain, Size: 119 bytes --]
Account and Password Information are attached!
***** Go to: http://www.intraware.de
***** Email: postman@intraware.de
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: John Heffner @ 2005-12-05 22:30 UTC (permalink / raw)
To: Rick Jones
Cc: Jeroen Massar, Marc Singer, Ben Greear, Al Boldi, netdev,
linux-net
In-Reply-To: <4394BF11.2070205@hp.com>
Rick Jones wrote:
> That's the discussion related to things like the "Strong ES" (end
> system) model right? As such, isn't that discussing what _IP_ may do
> rather than what ARP may do? 1122 doesn't say much about the
> interfaces/MAC's that should be part of a given ARP reply. ARP seems to
> be RFC 826 and probably others, and the algorithm described in 826
> doesn't seem to be specific on the topic of interfaces - at least not to
> my really brief read.
>
> rick jones
Yes, but if an interface will accept packets for a certain IP address,
and will send packets with that IP address, is there any reason it can't
ARP for that address?
-John
^ permalink raw reply
* ¢³øL¦
From: mahomaho094dsh @ 2005-12-05 22:29 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
* Re: [RFC] ip / ifconfig redesign
From: Rick Jones @ 2005-12-05 22:28 UTC (permalink / raw)
To: John Heffner
Cc: Jeroen Massar, Marc Singer, Ben Greear, Al Boldi, netdev,
linux-net
In-Reply-To: <4394BCD5.1060505@psc.edu>
John Heffner wrote:
> Jeroen Massar wrote:
>
>> 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.
>
>
> Not true. See RFC 1122, section 3.3.4. The standard leaves this
> decision up to the implementation, for good reason.
>
> From 1122 (note the use of MAY, not MUST or SHOULD):
> "
> There are two key requirement issues related to multihoming:
>
> (A) A host MAY silently discard an incoming datagram whose
> destination address does not correspond to the physical
> interface through which it is received.
>
> (B) A host MAY restrict itself to sending (non-source-
> routed) IP datagrams only through the physical
> interface that corresponds to the IP source address of
> the datagrams.
> "
That's the discussion related to things like the "Strong ES" (end system) model
right? As such, isn't that discussing what _IP_ may do rather than what ARP may
do? 1122 doesn't say much about the interfaces/MAC's that should be part of a
given ARP reply. ARP seems to be RFC 826 and probably others, and the algorithm
described in 826 doesn't seem to be specific on the topic of interfaces - at
least not to my really brief read.
rick jones
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: John Heffner @ 2005-12-05 22:19 UTC (permalink / raw)
To: Jeroen Massar; +Cc: Marc Singer, Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <43947FEB.7020504@unfix.org>
Jeroen Massar wrote:
> 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.
Not true. See RFC 1122, section 3.3.4. The standard leaves this
decision up to the implementation, for good reason.
From 1122 (note the use of MAY, not MUST or SHOULD):
"
There are two key requirement issues related to multihoming:
(A) A host MAY silently discard an incoming datagram whose
destination address does not correspond to the physical
interface through which it is received.
(B) A host MAY restrict itself to sending (non-source-
routed) IP datagrams only through the physical
interface that corresponds to the IP source address of
the datagrams.
"
This topic has been discussed many times on a variety of mailing lists.
I think the best way to do this is to make the behavior configurable,
which Linux currently does.
-John
^ permalink raw reply
* Re: [2.6 patch] move some code to net/ipx/af_ipx.c
From: Adrian Bunk @ 2005-12-05 21:35 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Matt Mackall, acme, Andrew Morton, linux-kernel, netdev
In-Reply-To: <39e6f6c70511181224r20801b61j87c856c703ab2b4d@mail.gmail.com>
On Fri, Nov 18, 2005 at 06:24:10PM -0200, Arnaldo Carvalho de Melo wrote:
> On 11/18/05, Adrian Bunk <bunk@stusta.de> wrote:
> > On Mon, Nov 14, 2005 at 02:57:07AM +0100, Adrian Bunk wrote:
> > > 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/)
>
> Thanks Adrian, from a quick glance looks OK, I'll review it later
> today to see if everything is fine wrt appletalk, tr, etc.
Any result from your review?
> - Arnaldo
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: [RFC] ip / ifconfig redesign
From: Marc Singer @ 2005-12-05 21:03 UTC (permalink / raw)
To: Ben Greear; +Cc: 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:
> >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.
Why? The routing determines connectivity, not ARP. AFAIK, ARP
requests are not made on interfaces that lack that the network being
queried.
If I put a host with an address on network 12 onto an ethernet segment
for network 10 and then ARP for addresses on network 10, I ought to be
able to send packets to those hosts (baring a firewal). However, I
won't be able to get anything back because those hosts don't know how
to send to network 12. Misconfiguration? Yes. Non-compliant? No.
> 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.
Anyway, I haven't seen a good reason to change the current behavior.
While the above described functionality is missing, no one has made a
case to support it.
^ 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
* 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: 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: 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: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: [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: 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: 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: 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: 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: [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: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: 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: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: 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