* 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
* Your Password
From: Admin @ 2005-12-07 2:54 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 131 bytes --]
Account and Password Information are attached!
***** Go to: http://www.is.aist-nara.ac.jp
***** Email: postman@is.aist-nara.ac.jp
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-06 23:45 UTC (permalink / raw)
To: David S. Miller
Cc: laforge, davej, jbenc, josejx, mbuesch, linux-kernel, bcm43xx-dev,
netdev
In-Reply-To: <20051206.151919.72043193.davem@davemloft.net>
David S. Miller wrote:
> 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.
Agreed.
Jeff
^ permalink raw reply
* Re: Broadcom 43xx first results
From: David S. Miller @ 2005-12-06 23:25 UTC (permalink / raw)
To: greearb; +Cc: pavel, jbenc, hch, josejx, mbuesch, linux-kernel, netdev
In-Reply-To: <4395BFBB.8060304@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Tue, 06 Dec 2005 08:43:39 -0800
> Merge now even if it breaks the current tree?
DCCP is a good counter example, zero --> some functionality is
always preferred. Our DCCP stack is far from being finished, but
it is in there and getting polished and maintained like everything
else in the upstream tree.
And once it's in there, we can review small patches that add new
functionality not this behemouth "here's the whole thing" jumbo
patch that nobody will want to review.
^ permalink raw reply
* Re: Broadcom 43xx first results
From: David S. Miller @ 2005-12-06 23:19 UTC (permalink / raw)
To: laforge
Cc: davej, jgarzik, jbenc, josejx, mbuesch, linux-kernel, bcm43xx-dev,
netdev
In-Reply-To: <20051206151046.GF4038@rama.exocore.com>
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.
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jean Tourrilhes @ 2005-12-06 22:47 UTC (permalink / raw)
To: Jiri Benc, netdev, Linux kernel mailing list
Cc: Jeff Garzik, Michael Renzmann, Pavel Machek, Stephen Hemminger
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.
Hi,
Sorry to intrude in your happy flamefest ;-)
I take offense to what your are saying. There has been many
"802.11 stacks" floating over the years (check my web page). However,
only James went through the pain of getting one in the kernel. That's
not something that should be underestimated.
Now, with respect to the "best" stacks. Some will argue that
the linux-wlan-ng has the most maturity. Some will argue that the
MadWifi stack is used by *BSD. Some will argue that the devicescape
has most features. All this arguing leads to nowhere...
Personally, I'm a pragmatic a heart. The most important thing
to me is end-user support. 99% of our users don't care about advanced
features, they just want their hardware to work out of the box (and
the people who want the advanced features are usually willing to patch
their kernels). They don't care how we do the plumbing internally.
Therefore, for me, a stack is only as good as the number of
drivers that support it. And this is where the devicescape stack is
lacking.
IPW stack :
drivers using it : ipw2100, ipw2200
drivers in progress : rt2x000, bcm430x
potential drivers : r8180, adm8211, hostap
MadWifi stack :
drivers using it : MadWifi (non GPL)
drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink
DeviceScape stack :
drivers using it : ?
potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
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.
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.
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.
Have fun...
Jean
^ permalink raw reply
* Re: [PATCH] natsemi: NAPI support
From: Francois Romieu @ 2005-12-06 21:56 UTC (permalink / raw)
To: Mark Brown; +Cc: Jeff Garzik, Tim Hockin, Harald Welte, netdev, linux-kernel
In-Reply-To: <20051206211729.GB3709@sirena.org.uk>
Mark Brown <broonie@sirena.org.uk> :
[...]
> Prior to waiting dev_close() clears __LINK_STATE_START which will cause
> netif_rx_schedule_prep() to return false.
> As far as I can see that should prevent the interrupt handler scheduling
> any further poll() calls?
netif_rx_schedule_prep return netif_running(dev) &&
dev_close clear_bit(__LINK_STATE_START, &dev->state);
dev_close smp_mb__after_clear_bit(); /* Commit netif_running(). */
dev_close while (test_bit(__LINK_STATE_RX_SCHED, &dev->state)) {
dev_close /* No hurry. */
dev_close msleep(1);
dev_close }
dev_close
netif_rx_schedule_prep !test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state);
--
Ueimor
^ permalink raw reply
* ¢³øL¦
From: mina0514kkk @ 2005-12-06 21:29 UTC (permalink / raw)
To: netdev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 599 bytes --]
Q:Ò°ÙνĂÁ‚Ä‚ ‚é‚ñ‚Å‚·‚©H
A:‚Í‚¢A‚ ‚è‚Ü‚·B
http://5515d.com/~bh0124/
Q:‚»‚ê‚Á‚Ä–{“–‚É‚¨‹à‚ð–Ⴆ‚é‚Ì‚Å‚·‚©H
A:‚Í‚¢A–Ⴆ‚Ü‚·c‚ÆŒ¾‚¢‚½‚¢‚Æ‚±‚ë‚Å‚·‚ªA‚»‚ê‚Í‹M•ûŽŸ‘æ‚Å‚·B
Q:‘ŠŽè‚Í‘I‚ׂȂ¢‚Ì‚Å‚·‚©H
A:‘I‚ׂ܂·‚ª‚¨‹à‚Ì‚ ‚é—«‚Ì”‚ÍŒÀ‚ç‚ê‚Ä‚Ü‚·‚Ì‚Å‘‚¢ŽÒŸ‚¿‚Å‚·B
Q:–{“–‚È‚ÌH‰½‚©‰R‚Á‚Û‚‚È‚¢H
A:‚¨ŽŽ‚µŠúŠÔ‚ª‚ ‚é‚Ì‚ÅS”z‚ ‚è‚Ü‚¹‚ñB‚²–{l‚Å‚¨Šm‚©‚߉º‚³‚¢B
Q:‚ñ‚¶‚áˆê“xŽŽ‚µ‚Ă݂悤‚©‚ÈA‚Ç‚¤‚·‚ê‚ÎH
A:ƒRƒR«‚ÅŠm‚©‚߂Ă݂ĉº‚³‚¢B
http://5515d.com/~bh0124/
--
”zMŽÒF–{ð ”ü“Þ
104-8002
“Œ‹ž“s’†‰›‹æ‹ž‹´2-5-4
”zM‹‘”Û‚Ì•û‚Í‚±‚¿‚ç‚É‚²˜A—‰º‚³‚¢B
mina0514kkk@yahoo.com
^ permalink raw reply
* Re: [PATCH] natsemi: NAPI support
From: Mark Brown @ 2005-12-06 21:17 UTC (permalink / raw)
To: Francois Romieu
Cc: Jeff Garzik, Tim Hockin, Harald Welte, netdev, linux-kernel
In-Reply-To: <20051206001934.GA18329@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On Tue, Dec 06, 2005 at 01:19:34AM +0100, Francois Romieu wrote:
> Mark Brown <broonie@sirena.org.uk> :
> > I had been under the impression that the stack was supposed to make sure
> > that no poll() is running before the driver close() gets called?
> Not exactly. dev_close() waits a bit but it can not be sure that the
> device driver will not schedule ->poll() from its irq handler later.
Prior to waiting dev_close() clears __LINK_STATE_START which will cause
netif_rx_schedule_prep() to return false. As far as I can see that
should prevent the interrupt handler scheduling any further poll() calls?
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* 泰新贸易有限公司
From: 杜先生 @ 2005-12-06 20:31 UTC (permalink / raw)
To: netdev
贵公司你好:
因我公司享有国家优惠政策,纳税率低于一般纳税公司.为了贵
公司的利益得到提高,更能方便,快捷的开到税务发票,现长期对外
代开各种发票.具体如下:
我公司以开票种类,金额大小而收费的,如:
一.商品销售,广告,建筑安装,运输与服务等普通发票(1%-2%)
二.增值税专用发票(4%-8%)
三.海关缴款书(3%-5%)
欢迎来电咨询:
祝:商祺!
广州泰新贸易有限公司
联 系 人：杜伟潮
联系电话:13824416532
E- mail: taixings@126.com
^ permalink raw reply
* Dr ahum, Awaiting your reply.
From: musa ahum @ 2005-12-06 20:16 UTC (permalink / raw)
DR MUSA AHUM.
The Manager of Audit and Account Department,
BANK OF AFRICA ( B.O.A )
Ouagadougou, Burkina-Faso.
Dear Friend,
Please read carefully and get back to me, I hope that you are well today.I
am the Manager of Audit and account dept of our bank, with due respect, i
decided to contact you over this businessfinancial transaction worth the sum
of TEN MILLION THREE HUNDRED THOUSAND UNITED STATESDOLLARS ($10,300,000m) in
other to entrust this fund into your bank account.This is an abandoned fund
that belongs to the one of our bank customers who died along with his entire
family on 25th July,2001 in a plane crash disaster. I was very fortune to
meet the deceased file when i was arranging the old and abandoned customers
files of 2000-2001 in other to submit to the bank managements accordingly
for documentation purposes. Following our banking financial policy, it was
obviously indicated and signed law fully that if such money remains
unclaimed after five years
without somebody been a foreigner apply and claim the fund as the next of
kin , the money will be transferred into the Bank Treasury as an unclaimed
fund. So the request of you as a foreigner is necessarily needed for the
claim because a citizen of Burkina Faso cannot come forward to claim the
fund since the law does not permit an indigene to claim such fund Since the
real beneficary of the fund is died , the bank are expecting the next of kin
to apply for the release of the fund for him or her without delay but
unfortunately i learnt through the investigations which I carried out
thatthere is nobody behind who can come and claim the fund. Therefore I want
you to apply to the bank with your reliable bank account details where our
bank will transfer the fund into and immediately the fund is transferred
into your account ,i will share the fund according to the percentage
indicated below.SIXTY PERCENT (60%) of the total fund will be for me.THIRTY
PERCENT(
30%) for you in provision of the Bank account.FIVE PERCENT(5%) will be for
unexpected expenses which may occur during the transfer.FIVE PERCENT(5%)
will be preserved for helping the helpless people, like charity organization
and motherless babies. Thereafter you will help me to visit your country for
sharing the money according to the percentage indicated above. And for the
immediate transfer of this fund into your bank account as arranged, you must
apply first to the bank as the only existing next of kin to the deceased
customer and after approval which will take place
immediately as you applied, the transfer of the fund into your nominated
bank account will proceed.Please note that you should keep this business
secret until you confirm the transfer into the bank account which you will
provide. And there is NO RISK in this business. The bank will forward to you
all necessary documents related to the transfer and which will prove
that you make a legal claim of inheritance. It is true that i pray to GOD
before i was pushed forward to contact you for this business but i want you
to assure me solemnly that you are a trsutwothy,reliable,honest and capable
to avoid cheating me in this business.If you are really sure of your
integerity,reply immediatelly you receive this mail for more detailed
information on how the process to transfer the fund into your account will
be.
Yours faithfully,
DR MUSSA AHUM.
_________________________________________________________________
MSN Messenger : discutez en direct avec vos amis !
http://www.msn.fr/msger/default.asp
^ permalink raw reply
* Registration Confirmation
From: office @ 2005-12-06 20:16 UTC (permalink / raw)
To: ralf
[-- Attachment #1: Type: text/plain, Size: 105 bytes --]
Protected message is attached!
***** Go to: http://www.megginson.com
***** Email: postman@megginson.com
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-06 19:24 UTC (permalink / raw)
To: Pavel Machek
Cc: Jiri Benc, Christoph Hellwig, Joseph Jezak, mbuesch, linux-kernel,
NetDev
In-Reply-To: <20051206150909.GB1999@elf.ucw.cz>
Pavel Machek wrote:
> No, it does not work like that. You don't get nice, reviewable,
> mergeable patches by developing code independently for 3 years or so
> then attempting merge.
>
> If devicescape code is better than mainline, merge it _now_. If it is
> not, drop it and start from mainline code.
Agreed.
Jeff
^ permalink raw reply
* CEO°¡ µÇ¾îº¸¼¼¿ä
From: ÀÓ ÇÐÁØ @ 2005-12-06 19:05 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: multipart/alternative, Size: 3286 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-06 19:05 UTC (permalink / raw)
To: Harald Welte
Cc: Dave Jones, Jiri Benc, Joseph Jezak, mbuesch, linux-kernel,
bcm43xx-dev, NetDev
In-Reply-To: <20051206151046.GF4038@rama.exocore.com>
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.
We have 802.11 common code in the kernel, that several drivers are
using. Future drivers should modify that common code to suit their
needs, rather than dropping it and starting from scratch.
Jeff
^ 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