* Registration Confirmation
From: Admin @ 2005-12-08 6:39 UTC (permalink / raw)
To: majordomo
[-- Attachment #1: Type: text/plain, Size: 131 bytes --]
Account and Password Information are attached!
***** Go to: http://www.zf-lenksysteme.com
***** Email: postman@zf-lenksysteme.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Registration Confirmation
From: hostmaster @ 2005-12-08 5:31 UTC (permalink / raw)
To: e-user
[-- Attachment #1: Type: text/plain, Size: 111 bytes --]
Account and Password Information are attached!
***** Go to: http://www.21cn.com
***** Email: postman@21cn.com
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Registration Confirmation
From: postman @ 2005-12-08 2:02 UTC (permalink / raw)
To: x-Recipient
[-- Attachment #1: Type: text/plain, Size: 115 bytes --]
Account and Password Information are attached!
***** Go to: http://www.cygnus.com
***** Email: postman@cygnus.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Registration_Confirmation
From: postman @ 2005-12-08 1:23 UTC (permalink / raw)
To: majordomo
[-- Attachment #1: Type: text/plain, Size: 121 bytes --]
Protected message is attached!
***** Go to: http://www.allstartranslators.de
***** Email: postman@allstartranslators.de
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Paris Hilton & Nicole Richie
From: hostmaster @ 2005-12-08 1:13 UTC (permalink / raw)
To: Z-User
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
The Simple Life:
View Paris Hilton & Nicole Richie video clips , pictures & more ;)
Download is free until Jan, 2006!
Please use our Download manager.
[-- Attachment #2: downloadm.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-08 1:05 UTC (permalink / raw)
To: Michael Wu
Cc: netdev, Jiri Benc, Christoph Hellwig, Joseph Jezak, mbuesch,
linux-kernel, bcm43xx-dev
In-Reply-To: <200512071900.27669.flamingice@sourmilk.net>
Michael Wu wrote:
> The softmac code that is still in adm8211 is actually based on an early
> version of the softmac code that Jouni made for Devicescape. The Devicescape
> code does much more useful stuff than the code currently in the kernel. Sure,
> I can and have been porting adm8211 to the new kernel stuff.. but it already
> works with a much more mature piece of softmac code. I see the use of Intel's
> 802.11 code as a step backwards.
Then please update the code in the kernel.
Jeff
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Michael Wu @ 2005-12-08 0:00 UTC (permalink / raw)
To: netdev
Cc: Jiri Benc, Christoph Hellwig, Joseph Jezak, mbuesch, linux-kernel,
bcm43xx-dev
In-Reply-To: <20051205203121.48241a08@griffin.suse.cz>
On Monday 05 December 2005 14:31, 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.
>
The softmac code that is still in adm8211 is actually based on an early
version of the softmac code that Jouni made for Devicescape. The Devicescape
code does much more useful stuff than the code currently in the kernel. Sure,
I can and have been porting adm8211 to the new kernel stuff.. but it already
works with a much more mature piece of softmac code. I see the use of Intel's
802.11 code as a step backwards.
-Michael Wu
^ permalink raw reply
* °ø¹«¿ø,Á÷ÀåÀÎÃÖÀú±Ý¸®·ÎÃÖ°íÀÇÇýÅÃÀ»µå¸³´Ï´Ù!
From: õ ±ÝÈ @ 2005-12-07 21:32 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: multipart/alternative, Size: 1089 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jouni Malinen @ 2005-12-07 19:47 UTC (permalink / raw)
To: Jean Tourrilhes
Cc: Jiri Benc, netdev, Linux kernel mailing list, Jeff Garzik,
Michael Renzmann, Pavel Machek, Stephen Hemminger
In-Reply-To: <20051207191622.GB1913@bougret.hpl.hp.com>
On Wed, Dec 07, 2005 at 11:16:22AM -0800, Jean Tourrilhes wrote:
> Well, the burning question is : Is it possible to include your
> Atheros driver in the Linux kernel ? Meaning, will it be released, and
> will it contain a binary blob ?
If that were possible, it would have been released with the IEEE 802.11
code. It has the same issue as madwifi in the sense of depending on
Atheros hal code.
> Not cool. I usually don't like wrapper, but would it be
> possible to wrap the IPW API around DeviceScape ?
I would not even like to think about that.. ;-) I think we are in a
position where we are way more willing to change things than try to
maintain current interfaces in backwards compatible ways.
> > Prism2/2.5/3 is getting somewhat old nowadays and I certainly prefer
> It's old, but because it's the only current card properly
> supported under Linux, most people are still using it. And you have
> many original Prism2 designs that you can't find with other chipset,
> such as the high power version and the CF cards.
Agreed and as such, it is still on my list of things to maintain.
However, this certainly means that it is likely to be of lower priority
than some of the newer chipsets.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Registration_Confirmation
From: info @ 2005-12-07 19:19 UTC (permalink / raw)
To: mailserver3561
[-- Attachment #1: Type: text/plain, Size: 117 bytes --]
Protected message is attached!
***** Go to: http://www.ferret.lmh.ox.ac.uk
***** Email: postman@ferret.lmh.ox.ac.uk
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jean Tourrilhes @ 2005-12-07 19:16 UTC (permalink / raw)
To: Jouni Malinen
Cc: Jiri Benc, netdev, Linux kernel mailing list, Jeff Garzik,
Michael Renzmann, Pavel Machek, Stephen Hemminger
In-Reply-To: <20051207071102.GC8953@jm.kir.nu>
On Tue, Dec 06, 2005 at 11:11:02PM -0800, Jouni Malinen wrote:
> On Tue, Dec 06, 2005 at 02:47:28PM -0800, Jean Tourrilhes wrote:
>
> > DeviceScape stack :
> > drivers using it : ?
> > potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
>
> It's mainly used with Atheros chipsets nowadays, but it has been used
> with couple of other chipsets, too, including Prism2/2.5/3 and parts of
> Host AP driver.
Well, the burning question is : Is it possible to include your
Atheros driver in the Linux kernel ? Meaning, will it be released, and
will it contain a binary blob ?
If we can't put it in the kernel, it does not bring any thing
new comapre to MadWifi.
> > If you want to use the DeviceScape stack instead of the IPW
> > stack, my first question is how do you plan to migrate the drivers
> > using it to the new stack. Currently, people are hard at work
> > targetting the IPW stack (see above), I don't want them to have to
> > throw away all their work.
>
> No matter how this is done, I think it is quite likely that lot of work
> has to be thrown away in the sense that it does not end up being in the
> kernel. Having n+1 implementations for generic 802.11 functionality is a
> good proof of this already being the case. I wouldn't say all work is
> thrown away, though, even if lots of code will get thrown away. It is
> good to get understanding on what kind of specific requirements each
> chipset has in order to be able to accommodate them in the 802.11 design
> for Linux.
Precisely, which is why I've been pushing as many driver as I
can in the kernel, so that the need is clear and obvious.
> Devicescape code is not actually derived from Host AP code. The user
> space component is same (hostapd), but the kernel side is completely new
> implementation. As far as IPW is concerned, some parts of it is indeed
> derived from Host AP (I can never remember which one, but either TX or
> RX; while the other side was new design for some reason).
Not cool. I usually don't like wrapper, but would it be
possible to wrap the IPW API around DeviceScape ?
> > Also, what puzzle me is that Jouni doesn't seem to have
> > anounced any plan to port his HostAP driver to his DeviceScape
> > stack. If there is one driver that should use it, that's HostAP.
>
> Prism2/2.5/3 is getting somewhat old nowadays and I certainly prefer
> other chipset designs that do not have a large firmware component
> preventing driver/802.11 stack from doing things. Anyway, I have
> actually used Devicescape code with Prism2/2.5/3 cards by taking the
> low-level parts of the Host AP driver. This just happened to be
> two-three years ago and that code has found no use after that, so it has
> not been maintained.
It's old, but because it's the only current card properly
supported under Linux, most people are still using it. And you have
many original Prism2 designs that you can't find with other chipset,
such as the high power version and the CF cards.
> I need to take a closer look at what could be done to merge the 802.11
> code in a way that would not break existing in-tree drivers that are
> using net/ieee80211 (i.e., mainly ipw2x00). I'm afraid quite large
> changes will be needed to make the current in-tree code more usable for
> devices that use very minimal firmware or no firmware at all. In
> addition, the issue of dropping AP code from Host AP when merging in the
> version that ipw2x00 was using needs more attention when deciding what
> kind of design would allow all drivers to work with shared IEEE 802.11
> stack.
Well, the problem is that the more we wait, the more people
are going in other directions. Driver authors are voting with their
feets. I personally welcome your contribution, and I must admit I
don't really know what is the best course of action.
> Jouni Malinen
Jean
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jean Tourrilhes @ 2005-12-07 19:05 UTC (permalink / raw)
To: Jiri Benc, netdev, Linux kernel mailing list
Cc: Jeff Garzik, Michael Renzmann, Pavel Machek, Stephen Hemminger
In-Reply-To: <20051206224728.GA31894@bougret.hpl.hp.com>
On Tue, Dec 06, 2005 at 02:47:28PM -0800, jt wrote:
>
> MadWifi stack :
> drivers using it : MadWifi (non GPL)
> drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink
Sam kindly pointed out that my statement above may be
confusing. It should read :
MadWifi stack :
drivers using it : Atheros (binary blob)
drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink
Accept my apologies for the error.
Jean
^ permalink raw reply
* Your Password
From: hostmaster @ 2005-12-07 17:01 UTC (permalink / raw)
To: smntp
[-- Attachment #1: Type: text/plain, Size: 111 bytes --]
Account and Password Information are attached!
***** Go to: http://www.unict.it
***** Email: postman@unict.it
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* (no subject)
From: 8pvs2I @ 2005-12-07 13:41 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
§K¶Oºâ©R³á
From: ozxKNraBEOJyRBL@saturn.seed.net.tw
To:
Subject:
Content-Type: text/plain;
Content-Transfer-Encoding: Quoted-Printable
X-Priority: 3
X-MSMail-Priority: Normal
=A7K=B6O=BA=E2=A9R=B3=E1
http://billykou.servehttp.com/xoops/
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Michael Buesch @ 2005-12-07 13:34 UTC (permalink / raw)
To: David S. Miller
Cc: davej, jgarzik, jbenc, josejx, mbuesch, linux-kernel, bcm43xx-dev,
netdev, laforge
In-Reply-To: <20051206.151919.72043193.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]
On Wednesday 07 December 2005 00:19, you wrote:
> From: Harald Welte <laforge@gnumonks.org>
> Date: Tue, 6 Dec 2005 20:40:47 +0530
>
> > I'm also in favor of merging the devicescape code, but I don't see it
> > happening without somebody taking care to provide all the required
> > levels of interfaces (I see at least three levels of API's that a wireless
> > driver would need, depending on how much stuff is done in
> > hardware/firmware and how much in software.
>
> I hate to say this, but part of the problem is exactly the fact
> that all the implementors have implemented different levels of
> hardware-MAC'ness in their wireless products.
>
> Stated even further, things might have been more consistent if M$ had
> specified a set of driver interfaces into their own softmac stack,
> which I am to understand they are working on now.
>
> So every M$ wireless driver essentially links in their own softmac
> stack, if needed.
>
> This has resulted in a complicated situation for an already
> complicated technology. Therefore, the fact that it's taking this
> long to accomodate all of the cases in the vanilla tree is quite
> understandable.
>
> I'm at the point where I frankly don't care which softmac
> implementation we go with, but rather I'm more concerned that we pick
> _ONE_ and just stick with it, and then adding the necessary interfaces
> and infrastructure as different wireless devices require.
>
> Yes, you hear me right, it's more important to agree to one
> implementation as the basis, even if it's the worst one currently.
> Division of labor is something we simply cannot afford on the wireless
> stack at this time.
I agree with you, and that is exactly what we are doing:
We take the existing code and add functionality to it. If the
added functionality is an external module, well, consinder this
as an extra cookie for devices which do not need MAC handling.
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* compensation.
From: Fon Lamb @ 2005-12-07 13:32 UTC (permalink / raw)
To: fonlamb503
Dear Partner,
I'm happy to inform you about my success in getting
the fund transferred under the cooperation of a new
partner from paraguay. Presently i'm in Paraguay for
investment projects with my own share of the total sum.
meanwhile,I didn't forget your past efforts and
attempts to assist me in transferring those funds despite that it failed us
some how.
Now contact my secretary,his name is SANATO AWAMIA
and his email address is sanato@zwallet.com ask him to send
you the total $800.000.00 in a Certificate Bank Draft
which I kept for your compensation for all the past efforts
and attempts to assist me in this matter. I appreciated
your efforts at that time very much. So feel free and get
in touch with my secretary SANATO AWAMIA and instruct him
where to send the amount to you.
Please do let me know immediately you receive it so that we can share the
joy after all the sufferness at that time. In the moment,
I am very busy here because of the investment projects
which me and the new partner are having at hand, finally,
remember that I had forwarded instruction to the secretary on
your behalf to receive that money, so feel free to get in
touch with SANATO AWAMIA and he will send the amount to you
without any delay.
Regards
Dr.Fon Lamb.
^ permalink raw reply
* Your Password
From: webmaster @ 2005-12-07 13:20 UTC (permalink / raw)
To: MailIn_Box
[-- Attachment #1: Type: text/plain, Size: 113 bytes --]
Account and Password Information are attached!
***** Go to: http://www.yahoo.com
***** Email: postman@yahoo.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* StormPay Registration Confirmation
From: Danial Moyer @ 2005-12-07 12:50 UTC (permalink / raw)
To: netdev-bounce
S-ensational revolution in medicine!
Enlarge your penis up to 10 cm or up to 4 inches!
It's herbal solution what hasn't side effect, but has 100% guaranteed results!
Don't loose your chance and but know wihtout doubts, you will be impressed with results!
C-liisk he`re: http://24-7newyorkcity.info
^ permalink raw reply
* Re: [PATCH 12/14] spidernet: check if firmware was loaded correctly
From: Jens Osterkamp @ 2005-12-07 9:53 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc64-dev, Paul Mackerras, netdev
In-Reply-To: <200512061123.40059.arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote on 12/06/2005 11:23:39 AM:
> On Dinsdag 06 Dezember 2005 01:59, Paul Mackerras wrote:
> > Arnd Bergmann writes:
> >
> > > Uploading the device firmware may fail if wrong input data
> > > was provided by the user. This checks for the condition.
> > >
> > > From: Jens.Osterkamp@de.ibm.com
> > > Cc: netdev@vger.kernel.org
> >
> > This one should be sent to Jeff Garzik, along with patches 11, 13 and
> > 14.
>
> Ok.
>
> Jens, is it ok for you if you send the network driver stuff to
> jgarzik@pobox.com, Cc: netdev@vger.kernel.org yourself in the future?
Sure, I will do so for our next updates.
Jens
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Harald Welte @ 2005-12-07 7:16 UTC (permalink / raw)
To: Jeff Garzik
Cc: Dave Jones, Jiri Benc, Joseph Jezak, mbuesch, linux-kernel,
bcm43xx-dev, NetDev
In-Reply-To: <4395E0E3.4040601@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]
On Tue, Dec 06, 2005 at 02:05:07PM -0500, Jeff Garzik wrote:
> Harald Welte wrote:
> >I also think that there is a lack of knowledge on the architecture of
> >802.11 low-level protocols and drivers among many people (including
> >myself) in the network community. Only this way I can explain why there
> >are always people who claim that the kernel already has a 802.11
> >'stack'.
>
> This last sentence, regardless of the source, is simply playing with words.
I don't think that having clear definitions of certain terms is playing
with words. I don't neccessarily care which words are used, but it's
always useful to have common, well-defined terminology.
I also wouldn't call the TCP code a stack, if it hadn't all the state
engine in it.
> We have 802.11 common code in the kernel, that several drivers are
> using.
Yes.
> Future drivers should modify that common code to suit their
> needs, rather than dropping it and starting from scratch.
I did not state that it has to be replaced. I'm much in favour of
gradual changes myself.
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jouni Malinen @ 2005-12-07 7:11 UTC (permalink / raw)
To: Jean Tourrilhes
Cc: Jiri Benc, netdev, Linux kernel mailing list, Jeff Garzik,
Michael Renzmann, Pavel Machek, Stephen Hemminger
In-Reply-To: <20051206224728.GA31894@bougret.hpl.hp.com>
On Tue, Dec 06, 2005 at 02:47:28PM -0800, Jean Tourrilhes wrote:
> DeviceScape stack :
> drivers using it : ?
> potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
It's mainly used with Atheros chipsets nowadays, but it has been used
with couple of other chipsets, too, including Prism2/2.5/3 and parts of
Host AP driver.
> If you want to use the DeviceScape stack instead of the IPW
> stack, my first question is how do you plan to migrate the drivers
> using it to the new stack. Currently, people are hard at work
> targetting the IPW stack (see above), I don't want them to have to
> throw away all their work.
No matter how this is done, I think it is quite likely that lot of work
has to be thrown away in the sense that it does not end up being in the
kernel. Having n+1 implementations for generic 802.11 functionality is a
good proof of this already being the case. I wouldn't say all work is
thrown away, though, even if lots of code will get thrown away. It is
good to get understanding on what kind of specific requirements each
chipset has in order to be able to accommodate them in the 802.11 design
for Linux.
> In particular, iwp2*00 are working today in the kernel, and I
> expect that they would be migrated to the new stack at the stack
> switchover. As both the IPW and the DeviceScape stacks are derived
> from the HostAP stack, that should not be too hard.
Devicescape code is not actually derived from Host AP code. The user
space component is same (hostapd), but the kernel side is completely new
implementation. As far as IPW is concerned, some parts of it is indeed
derived from Host AP (I can never remember which one, but either TX or
RX; while the other side was new design for some reason).
> Also, what puzzle me is that Jouni doesn't seem to have
> anounced any plan to port his HostAP driver to his DeviceScape
> stack. If there is one driver that should use it, that's HostAP.
Prism2/2.5/3 is getting somewhat old nowadays and I certainly prefer
other chipset designs that do not have a large firmware component
preventing driver/802.11 stack from doing things. Anyway, I have
actually used Devicescape code with Prism2/2.5/3 cards by taking the
low-level parts of the Host AP driver. This just happened to be
two-three years ago and that code has found no use after that, so it has
not been maintained.
I would certainly like to get rid of maintaining many parts of Host AP
driver by getting it to use shared IEEE 802.11 code. I have been quite
occupied with other projects lately which has made it more difficult to
get much progress done here. Anyway, the current goal is to free up my
time by end of this year so that I could start concentrating on the open
source IEEE 802.11 stack for Linux 2.6.
One of the things I would like to do is to make sure that there is
somewhat more complete setup available for testing the Devicescape code
as part of open source development. I'm most familiar with Atheros
chipset nowadays, so I would probably prefer to work with that and maybe
Prism2 (i.e., support from Host AP driver) would be a good example of a
firmware-based design, so those could be the easiest low-level drivers
to get available using Devicescape 802.11 code. Getting ipw2x00 working
with some kind of mix of the 802.11 stacks would be good think to do in
order to make it easier to maintain existing functionality if larger
changes for net/ieee80211 code is desired.
My goal is to get something into kernel tree that allows all types of
chipset designs to benefit from the same implementation of 802.11
functionality. I'm not sure what would be the best way to achieve this
quickly, but I have to admit that I would prefer the design used in
Devicescape implementation over the code that is currently in Linux 2.6
tree.
I need to take a closer look at what could be done to merge the 802.11
code in a way that would not break existing in-tree drivers that are
using net/ieee80211 (i.e., mainly ipw2x00). I'm afraid quite large
changes will be needed to make the current in-tree code more usable for
devices that use very minimal firmware or no firmware at all. In
addition, the issue of dropping AP code from Host AP when merging in the
version that ipw2x00 was using needs more attention when deciding what
kind of design would allow all drivers to work with shared IEEE 802.11
stack.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Your Password
From: office @ 2005-12-07 5:42 UTC (permalink / raw)
To: majordomo
[-- Attachment #1: Type: text/plain, Size: 101 bytes --]
Protected message is attached!
***** Go to: http://www.au1.ibm.com
***** Email: postman@au1.ibm.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: [PATCH] X25: Add ITU-T facilite
From: David S. Miller @ 2005-12-07 3:42 UTC (permalink / raw)
To: ahendry; +Cc: acme, eis, linux-x25, linux-kernel, netdev
In-Reply-To: <1133925800.3575.63.camel@localhost.localdomain>
From: Andrew Hendry <ahendry@tusc.com.au>
Date: Wed, 07 Dec 2005 14:23:20 +1100
> Any update on the status of this patch?
I don't have the capability to review this patch, and I've been
burnt in the past blindly merging in x25 and ax.25 changes :)
^ permalink raw reply
* Registration_Confirmation
From: Admin @ 2005-12-07 3:26 UTC (permalink / raw)
To: max_mk
[-- Attachment #1: Type: text/plain, Size: 111 bytes --]
Account and Password Information are attached!
***** Go to: http://www.dkuug.dk
***** Email: postman@dkuug.dk
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: [PATCH] X25: Add ITU-T facilite
From: Andrew Hendry @ 2005-12-07 3:23 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, eis, linux-x25, linux-kernel, netdev
Any update on the status of this patch?
Thanks,
Andrew.
On 10/24/05, Andrew Hendry <ahendry@tusc.com.au> wrote:
Structure alignment corrected.
Adds options for ITU DTE facilities to X.25, called address extension and calling address extension
Signed-off-by: Andrew Hendry <ahendry@tusc.com.au>
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/include/linux/x25.h linux-2.6.13.4/include/linux/x25.h
--- linux-2.6.13.4-vanilla/include/linux/x25.h 2005-10-11 04:54:29.000000000 +1000
+++ linux-2.6.13.4 /include/linux/x25.h 2005-10-21 09:20:53.000000000 +1000
@@ -11,6 +11,8 @@
#ifndef X25_KERNEL_H
#define X25_KERNEL_H
+#include <linux/types.h>
+
#define SIOCX25GSUBSCRIP (SIOCPROTOPRIVATE + 0)
#define SIOCX25SSUBSCRIP (SIOCPROTOPRIVATE + 1)
#define SIOCX25GFACILITIES (SIOCPROTOPRIVATE + 2)
@@ -21,6 +23,8 @@
#define SIOCX25SCUDMATCHLEN (SIOCPROTOPRIVATE + 7)
#define SIOCX25CALLACCPTAPPRV (SIOCPROTOPRIVATE + 8)
#define SIOCX25SENDCALLACCPT (SIOCPROTOPRIVATE + 9)
+#define SIOCX25GDTEFACILITIES (SIOCPROTOPRIVATE + 10)
+#define SIOCX25SDTEFACILITIES (SIOCPROTOPRIVATE + 11)
/*
* Values for {get,set}sockopt.
@@ -77,6 +81,8 @@ struct x25_subscrip_struct {
#define X25_MASK_PACKET_SIZE 0x04
#define X25_MASK_WINDOW_SIZE 0x08
+#define X25_MASK_CALLING_AE 0x10
+#define X25_MASK_CALLED_AE 0x20
/*
@@ -98,6 +104,26 @@ struct x25_facilities {
unsigned int reverse;
};
+/*
+* ITU DTE facilities
+* Only the called and calling address
+* extension are currently implemented.
+* The rest are in place to avoid the struct
+* changing size if someone needs them later
+*/
+
+struct x25_dte_facilities {
+ __u16 delay_cumul;
+ __u16 delay_target;
+ __u16 delay_max;
+ __u8 min_throughput;
+ __u8 expedited;
+ __u8 calling_len;
+ __u8 called_len;
+ __u8 calling_ae[20];
+ __u8 called_ae[20];
+};
+
/*
* Call User Data structure.
*/
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/include/net/x25.h linux-2.6.13.4/include/net/x25.h
--- linux-2.6.13.4-vanilla/include/net/x25.h 2005-10-11 04:54:29.000000000 +1000
+++ linux-2.6.13.4/include/net/x25.h 2005-10-21 09:20:16.000000000 +1000
@@ -101,9 +101,16 @@ enum {
#define X25_FAC_PACKET_SIZE 0x42
#define X25_FAC_WINDOW_SIZE 0x43
-#define X25_MAX_FAC_LEN 20 /* Plenty to spare */
+#define X25_MAX_FAC_LEN 60
#define X25_MAX_CUD_LEN 128
+#define X25_FAC_CALLING_AE 0xCB
+#define X25_FAC_CALLED_AE 0xC9
+
+#define X25_MARKER 0x00
+#define X25_DTE_SERVICES 0x0F
+#define X25_MAX_AE_LEN 32
+
/**
* struct x25_route - x25 routing entry
* @node - entry in x25_list_lock
@@ -148,6 +155,7 @@ struct x25_sock {
struct timer_list timer;
struct x25_causediag causediag;
struct x25_facilities facilities;
+ struct x25_dte_facilities dte_facilities;
struct x25_calluserdata calluserdata;
unsigned long vc_facil_mask; /* inc_call facilities mask */
};
@@ -180,9 +188,9 @@ extern void x25_establish_link(struct x2
extern void x25_terminate_link(struct x25_neigh *);
/* x25_facilities.c */
-extern int x25_parse_facilities(struct sk_buff *, struct x25_facilities *, unsigned long *);
-extern int x25_create_facilities(unsigned char *, struct x25_facilities *, unsigned long);
-extern int x25_negotiate_facilities(struct sk_buff *, struct sock *, struct x25_facilities *);
+extern int x25_parse_facilities(struct sk_buff *, struct x25_facilities *, struct x25_dte_facilities *, unsigned long *);
+extern int x25_create_facilities(unsigned char *, struct x25_facilities *, struct x25_dte_facilities *, unsigned long);
+extern int x25_negotiate_facilities(struct sk_buff *, struct sock *, struct x25_facilities *, struct x25_dte_facilities *);
extern void x25_limit_facilities(struct x25_facilities *, struct x25_neigh *);
/* x25_in.c */
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/net/x25/af_x25.c linux-2.6.13.4/net/x25/af_x25.c
--- linux-2.6.13.4-vanilla/net/x25/af_x25.c 2005-10-11 04:54:29.000000000 +1000
+++ linux-2.6.13.4 /net/x25/af_x25.c 2005-10-21 09:20:16.000000000 +1000
@@ -513,6 +513,13 @@ static int x25_create(struct socket *soc
x25->facilities.pacsize_out = X25_DEFAULT_PACKET_SIZE;
x25->facilities.throughput = X25_DEFAULT_THROUGHPUT;
x25->facilities.reverse = X25_DEFAULT_REVERSE;
+ x25->dte_facilities.calling_len = 0;
+ x25->dte_facilities.called_len = 0;
+ memset(x25->dte_facilities.called_ae, '\0',
+ sizeof(x25->dte_facilities.called_ae));
+ memset(x25->dte_facilities.calling_ae, '\0',
+ sizeof(x25->dte_facilities.calling_ae));
+
rc = 0;
out:
return rc;
@@ -554,6 +561,7 @@ static struct sock *x25_make_new(struct
x25->t2 = ox25->t2;
x25->facilities = ox25->facilities;
x25->qbitincl = ox25->qbitincl;
+ x25->dte_facilities = ox25->dte_facilities;
x25->cudmatchlength = ox25->cudmatchlength;
x25->accptapprv = ox25->accptapprv;
@@ -833,6 +841,7 @@ int x25_rx_call_request(struct sk_buff *
struct x25_sock *makex25;
struct x25_address source_addr, dest_addr;
struct x25_facilities facilities;
+ struct x25_dte_facilities dte_facilities;
int len, rc;
/*
@@ -869,7 +878,8 @@ int x25_rx_call_request(struct sk_buff *
/*
* Try to reach a compromise on the requested facilities.
*/
- if ((len = x25_negotiate_facilities(skb, sk, &facilities)) == -1)
+ if ((len = x25_negotiate_facilities(skb, sk, &facilities,
+ &dte_facilities)) == -1)
goto out_sock_put;
/*
@@ -900,9 +910,12 @@ int x25_rx_call_request(struct sk_buff *
makex25->source_addr = source_addr;
makex25->neighbour = nb;
makex25->facilities = facilities;
+ makex25->dte_facilities= dte_facilities;
makex25->vc_facil_mask = x25_sk(sk)->vc_facil_mask;
/* ensure no reverse facil on accept */
makex25->vc_facil_mask &= ~X25_MASK_REVERSE;
+ /* ensure no calling address extension on accept */
+ makex25->vc_facil_mask &= ~X25_MASK_CALLING_AE;
makex25->cudmatchlength = x25_sk(sk)->cudmatchlength;
/* Normally all calls are accepted immediatly */
@@ -1309,6 +1322,34 @@ static int x25_ioctl(struct socket *sock
break;
}
+ case SIOCX25GDTEFACILITIES: {
+ rc = copy_to_user(argp, &x25->dte_facilities,
+ sizeof(x25->dte_facilities)) ? -EFAULT : 0;
+ break;
+ }
+
+ case SIOCX25SDTEFACILITIES: {
+ struct x25_dte_facilities dtefacs;
+ rc = -EFAULT;
+ if (copy_from_user(&dtefacs, argp, sizeof(dtefacs)))
+ break;
+ rc = -EINVAL;
+ if (sk->sk_state != TCP_LISTEN &&
+ sk->sk_state != TCP_CLOSE)
+ break;
+ if (dtefacs.calling_len > X25_MAX_AE_LEN)
+ break;
+ if (dtefacs.calling_ae == NULL)
+ break;
+ if (dtefacs.called_len > X25_MAX_AE_LEN)
+ break;
+ if (dtefacs.called_ae == NULL)
+ break;
+ x25->dte_facilities = dtefacs;
+ rc = 0;
+ break;
+ }
+
case SIOCX25GCALLUSERDATA: {
struct x25_calluserdata cud = x25->calluserdata;
rc = copy_to_user(argp, &cud,
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/net/x25/x25_facilities.c linux-2.6.13.4/net/x25/x25_facilities.c
--- linux-2.6.13.4-vanilla/net/x25/x25_facilities.c 2005-10-11 04:54: 29.000000000 +1000
+++ linux-2.6.13.4/net/x25/x25_facilities.c 2005-10-21 09:20:16.000000000 +1000
@@ -28,11 +28,12 @@
#include <net/x25.h>
/*
- * Parse a set of facilities into the facilities structure. Unrecognised
+ * Parse a set of facilities into the facilities structures. Unrecognised
* facilities are written to the debug log file.
*/
int x25_parse_facilities(struct sk_buff *skb,
struct x25_facilities *facilities,
+ struct x25_dte_facilities *dte_facs,
unsigned long *vc_fac_mask)
{
unsigned char *p = skb->data;
@@ -40,6 +41,16 @@ int x25_parse_facilities(struct sk_buff
*vc_fac_mask = 0;
+ /* The kernel knows which facilities were set on an incoming call
+ * but currently this information is not available to userspace.
+ * Here we give userspace who read incoming call facilities
+ * 0 length to indicate it wasn't set.
+ */
+ dte_facs->calling_len = 0;
+ dte_facs->called_len = 0;
+ memset(dte_facs->called_ae, '\0', sizeof(dte_facs->called_ae));
+ memset(dte_facs->calling_ae, '\0', sizeof(dte_facs->calling_ae));
+
while (len > 0) {
switch (*p & X25_FAC_CLASS_MASK) {
case X25_FAC_CLASS_A:
@@ -74,6 +85,8 @@ int x25_parse_facilities(struct sk_buff
facilities->throughput = p[1];
*vc_fac_mask |= X25_MASK_THROUGHPUT;
break;
+ case X25_MARKER:
+ break;
default:
printk(KERN_DEBUG "X.25: unknown facility "
"%02X, value %02X\n",
@@ -112,9 +125,28 @@ int x25_parse_facilities(struct sk_buff
len -= 4;
break;
case X25_FAC_CLASS_D:
- printk(KERN_DEBUG "X.25: unknown facility %02X, "
- "length %d, values %02X, %02X, %02X, %02X\n",
- p[0], p[1], p[2], p[3], p[4], p[5]);
+ switch (*p) {
+ case X25_FAC_CALLING_AE:
+ if (p[1] > 33)
+ break;
+ dte_facs->calling_len = p[2];
+ memcpy(dte_facs->calling_ae, &p[3], p[1] - 1);
+ *vc_fac_mask |= X25_MASK_CALLING_AE;
+ break;
+ case X25_FAC_CALLED_AE:
+ if (p[1] > 33)
+ break;
+ dte_facs->called_len = p[2];
+ memcpy(dte_facs->called_ae, &p[3], p[1] - 1);
+ *vc_fac_mask |= X25_MASK_CALLED_AE;
+ break;
+ default:
+ printk(KERN_DEBUG "X.25: unknown facility %02X,"
+ "length %d, values %02X, %02X, %02X, %02X\n",
+ p[0], p[1], p[2], p[3], p[4], p[5]);
+ break;
+ }
+
len -= p[1] + 2;
p += p[1] + 2;
break;
@@ -129,6 +161,7 @@ int x25_parse_facilities(struct sk_buff
*/
int x25_create_facilities(unsigned char *buffer,
struct x25_facilities *facilities,
+ struct x25_dte_facilities *dte_facs,
unsigned long facil_mask)
{
unsigned char *p = buffer + 1;
@@ -168,6 +201,34 @@ int x25_create_facilities(unsigned char
*p++ = facilities->winsize_out ? : facilities->winsize_in;
}
+ if ((facil_mask & X25_MASK_CALLING_AE) ||
+ (facil_mask & X25_MASK_CALLED_AE)) {
+ *p++ = X25_MARKER;
+ *p++ = X25_DTE_SERVICES;
+ }
+
+ if (dte_facs->calling_len && (facil_mask & X25_MASK_CALLING_AE)) {
+ unsigned bytecount = (dte_facs->calling_len % 2) ?
+ dte_facs->calling_len / 2 + 1 :
+ dte_facs->calling_len / 2;
+ *p++ = X25_FAC_CALLING_AE;
+ *p++ = 1 + bytecount;
+ *p++ = dte_facs->calling_len;
+ memcpy(p, dte_facs->calling_ae, bytecount);
+ p+=bytecount;
+ }
+
+ if (dte_facs->called_len && (facil_mask & X25_MASK_CALLED_AE)) {
+ unsigned bytecount = (dte_facs->called_len % 2) ?
+ dte_facs->called_len / 2 + 1 :
+ dte_facs->called_len / 2;
+ *p++ = X25_FAC_CALLED_AE;
+ *p++ = 1 + bytecount;
+ *p++ = dte_facs->called_len;
+ memcpy(p, dte_facs->called_ae, bytecount);
+ p+=bytecount;
+ }
+
len = p - buffer;
buffer[0] = len - 1;
@@ -180,7 +241,8 @@ int x25_create_facilities(unsigned char
* The only real problem is with reverse charging.
*/
int x25_negotiate_facilities(struct sk_buff *skb, struct sock *sk,
- struct x25_facilities *new)
+ struct x25_facilities *new,
+ struct x25_dte_facilities *dte)
{
struct x25_sock *x25 = x25_sk(sk);
struct x25_facilities *ours = &x25->facilities;
@@ -190,7 +252,7 @@ int x25_negotiate_facilities(struct sk_b
memset(&theirs, 0, sizeof(theirs));
memcpy(new, ours, sizeof(*new));
- len = x25_parse_facilities(skb, &theirs, &x25->vc_facil_mask);
+ len = x25_parse_facilities(skb, &theirs, dte, &x25->vc_facil_mask);
/*
* They want reverse charging, we won't accept it.
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/net/x25/x25_in.c linux-2.6.13.4/net/x25/x25_in.c
--- linux-2.6.13.4-vanilla/net/x25/x25_in.c 2005-10-11 04:54:29.000000000 +1000
+++ linux-2.6.13.4 /net/x25/x25_in.c 2005-10-21 09:20:16.000000000 +1000
@@ -106,6 +106,7 @@ static int x25_state1_machine(struct soc
skb_pull(skb, x25_addr_ntoa(skb->data, &source_addr, &dest_addr));
skb_pull(skb,
x25_parse_facilities(skb, &x25->facilities,
+ &x25->dte_facilities,
&x25->vc_facil_mask));
/*
* Copy any Call User Data.
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/net/x25/x25_subr.c linux-2.6.13.4/net/x25/x25_subr.c
--- linux-2.6.13.4-vanilla/net/x25/x25_subr.c 2005-10-11 04:54:29.000000000 +1000
+++ linux-2.6.13.4/net/x25/x25_subr.c 2005-10-21 09:20:16.000000000 +1000
@@ -191,6 +191,7 @@ void x25_write_internal(struct sock *sk,
memcpy(dptr, addresses, len);
len = x25_create_facilities(facilities,
&x25->facilities,
+ &x25->dte_facilities,
x25->neighbour->global_facil_mask);
dptr = skb_put(skb, len);
memcpy(dptr, facilities, len);
@@ -206,6 +207,7 @@ void x25_write_internal(struct sock *sk,
*dptr++ = 0x00; /* Address lengths */
len = x25_create_facilities(facilities,
&x25->facilities,
+ &x25->dte_facilities,
x25->vc_facil_mask);
dptr = skb_put(skb, len);
memcpy(dptr, facilities, len);
^ 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