* Re: Fw: [Bugme-new] [Bug 6495] New: Vlan MTU Fragmentation
From: Ben Greear @ 2006-05-05 15:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugme-daemon@kernel-bugs.osdl.org
In-Reply-To: <20060504235628.33041b55.akpm@osdl.org>
Andrew Morton wrote:
>
> Begin forwarded message:
>
> Date: Thu, 4 May 2006 23:15:56 -0700
> From: bugme-daemon@bugzilla.kernel.org
> To: bugme-new@lists.osdl.org
> Subject: [Bugme-new] [Bug 6495] New: Vlan MTU Fragmentation
>
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6495
>
> Summary: Vlan MTU Fragmentation
> Kernel Version: 2.6.16.12
> Status: NEW
> Severity: normal
> Owner: shemminger@osdl.org
> Submitter: slavon@bigtelecom.ru
>
>
> Steps to reproduce:
>
> ifconfing eth0 mtu 1500
> ifconfing eth0.100 mtu 1500
>
> ping www.ru -s 2000
> -- BAD --
>
> ----------------
>
> ifconfing eth0 mtu 1500
> ifconfing eth0.100 mtu 1496
>
> ping www.ru -s 2000
> --NORMAL--
This is almost definately a bug in the ethernet driver. The driver needs
to be modified so that it can send/receive pkts that are MTU + 4 bytes for the
VLAN header.
We need to know what NIC/driver this user is using...
Ben
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Very long list of struct dst_entry in dst_garbage_list
From: Eric Dumazet @ 2006-05-05 16:13 UTC (permalink / raw)
To: netdev
In-Reply-To: <445B11A3.1020407@cosmosbay.com>
I noticed that after a 'ip route flush cache' (manual or timer
triggered) on a busy server, XXXXX entries are added to dst_garbage_list.
(XXXXX depends on the number of established sockets)
Every 1/10th second (DST_GC_MIN) , net/core/dst.c::dst_run_gc() is
fired, and try to free some entries from the list, but many entries have
a non null refcnt and stay in the list for the next run.
Linux version is 2.6.17-rc3.
Do you think a rework of dst_run_gc() function is necessary, (using a
batch mode to limit the number of entries examined at each run), or is
it a "should not happen, something is broken" situation ?
Eric
^ permalink raw reply
* Re: [Netem] where i can find this netem patch?
From: Stephen Hemminger @ 2006-05-05 17:15 UTC (permalink / raw)
To: George Nychis; +Cc: netdev, lartc, netem
In-Reply-To: <445B6A67.7020809@cmu.edu>
On Fri, 05 May 2006 11:08:23 -0400
George Nychis <gnychis@cmu.edu> wrote:
> Hi,
>
> I need help finding this patch that Stephen made.
>
> He sent me a patch, but i do not think its related to the patch that
> solved this problem. I will include the patch he did forward to me at
> the bottom.
> However here is the problem, i even rtied his misspelling of change :)
>
> thorium-ini 15849-tests # tc qdisc add dev ath0 root handle 1:0 netem
> drop 0%
> thorium-ini 15849-tests # tc qdisc add dev ath0 parent 1:1 handle 10:
> xcp capacity 54Mbit limit 500
> thorium-ini 15849-tests # tc qdisc change dev ath0 root handle 1:0 netem
> drop 1%
> RTNETLINK answers: Invalid argument
>
The problem was you are giving handle 1:0 so the change request was
going to xcp. And xcp doesn't understand netem rtnetlink message.
You want to do:
# tc qdisc change dev ath0 root netem drop 1%
^ permalink raw reply
* Re: dBm cutoff at -1dBm is too low
From: Jean Tourrilhes @ 2006-05-05 17:28 UTC (permalink / raw)
To: Pavel Roskin; +Cc: NetDev
In-Reply-To: <1146760665.5294.65.camel@dv>
On Thu, May 04, 2006 at 12:37:45PM -0400, Pavel Roskin wrote:
> Hello, Jean!
>
> I'm converting Orinoco to the dBm reporting, and it turns out that the
> best signal iwconfig will report is -1dBm (0.8mW). This would happen if
> qual->level has its highest value of 255. Please see this code from
> wireless_tools.29.pre10:
>
> len = snprintf(buffer, buflen, "Signal level%c%d dBm ",
> qual->updated & IW_QUAL_LEVEL_UPDATED ? '=' : ':',
> qual->level - 0x100);
Yes, that's correct.
Note that the main limitation is that before I introduced the
explicit IW_QUAL_DBM in WE-19, the way to know if the value was
relative or dBm was to use the 'sign' of it, i.e. value above 0 were
non-dBm. The test is a few line before this snipset :
---------------------------------------------------------
/* Check if the statistics are in dBm or relative */
if((qual->updated & IW_QUAL_DBM)
|| (qual->level > range->max_qual.level))
{
---------------------------------------------------------
There are still quite a few drivers which have not been
converted to use IW_QUAL_DBM, so I don't want to drop the backward
compatibility yet.
> With most cards transmitting at 100mW and some going as high as 500mW,
> it's not unreasonable to expect that the received signal may exceed 1mW
> for closely located receivers with good antennas. I have seen HostAP
> reporting as much as 3mW through the proc filesystem!
My rationale was two fold.
First, such high values are quite unlikely, because cards need
to be very close, which does not happen that often. Power is limited
by spec and power consumption, so unlikely to go higher than
this. Also, I'm surprised that the card receiver does not saturate
with such high receive power, but I would question the accuracy of the
measurement.
Second, the measurement is useful mostly in marginal
conditions. When signal is great, you don't really care, when signal
is low, you want to tweak your system to improve reception.
> Wouldn't it be better to put the cutoff at a higher value? The simplest
> approach would be to treat qual->level and qual->noise as signed char,
> which would put the cutoff and 127dBm. 500 gigawatts should be enough
> for everyone :-)
FCC says Tx 1W @ 2.4 GHz, ETSI says Tx 100mW @ 2.4 Gz. Yeah,
you could use directional antennas. So, realistically, we only need to
extend to +30dBm.
On the other hand, I expect that with MIMO and UWB we would
start to receive signal weaker than what we currently do, and you
don't want to cutoff the bottom of the range (is -128dBm enough ?).
I tried to use 'signed' in the struct a long while ago, and
for some reason it broke left and right, I don't remember the
details. So, whatever we do, it would not be straightforward.
> Regards,
> Pavel Roskin
Have fun...
Jean
^ permalink raw reply
* Re: [x86_64, NET] smp_rmb() in dst_destroy() seems very expensive, ditto in kfree_skb()
From: Andi Kleen @ 2006-05-05 17:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <445B11A3.1020407@cosmosbay.com>
On Friday 05 May 2006 10:49, Eric Dumazet wrote:
> On a dual opteron box, I noticed high oprofile numbers in net/core/dst.c
> , function dst_destroy(struct dst_entry * dst)
>
> It appears the smb_rmb() done at the begining of dst_destroy() is the
> killer (this is a lfence machine instruction, that apparently is doing
> a *lot* of things... may be IO related...) that is responsible for 80%
> of the cpu time used by the whole function.
>
> I dont understand very much all variety of available barriers, and why
> this smb_rmb() is used in dst_destroy().
> I missed the corresponding wmb that should be done somewhere in the dst
> code.
>
> Do we have an alternative to smp_rmb() in the dst_destroy()/ kfree_skb()
> context ?
Eliminating it probably wouldn't help very much - it just flushes the
loads already in flight. If it didn't do that the next smp_rmb() would.
I'm surprised there are that many though. Normally kernel code is spagetti
enough that the CPU cannot speculate too many loads ahead.
But are you 100% sure the cost is not in the lock decl ? That would make
more sense. Perhaps profile for cache misses too and double check?
-Andi
^ permalink raw reply
* Re: sky2 1.3-rc1
From: Thomas Glanzmann @ 2006-05-05 17:35 UTC (permalink / raw)
To: Daniel Drake
Cc: Stephen Hemminger, Bill Hoover, Bertrand Jacquin, micheleschi,
netdev, teppic74
In-Reply-To: <445B626B.1070407@gentoo.org>
Hello,
> > http://developer.osdl.org/shemminger/prototypes/sky2-1.3-rc1.tar.bz2
> v0.15:
> 64 bytes from 10.0.0.138: icmp_seq=2 ttl=64 time=0.467 ms
> v1.3-rc1:
> 64 bytes from 10.0.0.138: icmp_seq=4 ttl=64 time=32.9 ms
I can't confirm this. For me it is just perfect:
64 bytes from 89.106.66.1: icmp_seq=1 ttl=64 time=0.278 ms
0000:04:00.0 Ethernet controller: Marvell Technology Group Ltd.: Unknown device 4361 (rev 17)
Thomas
^ permalink raw reply
* Re: Machine check in bcm43xx_phy_initg
From: Michael Buesch @ 2006-05-05 17:42 UTC (permalink / raw)
To: linville; +Cc: bcm43xx-dev, Andrew Morton, netdev, David Woodhouse
In-Reply-To: <1146849577.2766.18.camel@pmac.infradead.org>
On Friday 05 May 2006 19:19, David Woodhouse wrote:
> On Fri, 2006-05-05 at 12:59 -0400, Joseph Jezak wrote:
> > I fixed the specs, it should be bcm->chip_package == 2, sorry for the
> > mistake.
>
> Thanks. The correct patch should look like this then...
>
> [BCM43xx] Fix access to non-existent PHY registers
>
> Fix the conditions under which we poke at the APHY registers in
> bcm43xx_phy_initg() to avoid a machine check on chips where they don't
> exist.
>
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
John, please apply. I will also send a patch for d80211.
> --- linux-2.6.16.ppc64/drivers/net/wireless/bcm43xx/bcm43xx_phy.c~ 2006-05-04 19:16:09.000000000 +0100
> +++ linux-2.6.16.ppc64/drivers/net/wireless/bcm43xx/bcm43xx_phy.c 2006-05-05 17:22:57.000000000 +0100
> @@ -1287,7 +1287,7 @@ static void bcm43xx_phy_initg(struct bcm
> if (radio->revision == 8)
> bcm43xx_phy_write(bcm, 0x0805, 0x3230);
> bcm43xx_phy_init_pctl(bcm);
> - if (bcm->chip_id == 0x4306 && bcm->chip_package != 2) {
> + if (bcm->chip_id == 0x4306 && bcm->chip_package == 2) {
> bcm43xx_phy_write(bcm, 0x0429,
> bcm43xx_phy_read(bcm, 0x0429) & 0xBFFF);
> bcm43xx_phy_write(bcm, 0x04C3,
>
--
Greetings Michael.
^ permalink raw reply
* [PATCH] bcm43xx-d80211: Fix access to non-existent PHY registers
From: Michael Buesch @ 2006-05-05 17:50 UTC (permalink / raw)
To: John W. Linville; +Cc: bcm43xx-dev, netdev, David Woodhouse
John, this is the same patch as before, but for d80211.
Please apply to wireless-dev.
--
Fix the conditions under which we poke at the APHY registers in
bcm43xx_phy_initg() to avoid a machine check on chips where they don't
exist.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c
index 45da79d..1816f66 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c
@@ -1287,7 +1287,7 @@ static void bcm43xx_phy_initg(struct bcm
if (radio->revision == 8)
bcm43xx_phy_write(bcm, 0x0805, 0x3230);
bcm43xx_phy_init_pctl(bcm);
- if (bcm->chip_id == 0x4306 && bcm->chip_package != 2) {
+ if (bcm->chip_id == 0x4306 && bcm->chip_package == 2) {
bcm43xx_phy_write(bcm, 0x0429,
bcm43xx_phy_read(bcm, 0x0429) & 0xBFFF);
bcm43xx_phy_write(bcm, 0x04C3,
--
Greetings Michael.
^ permalink raw reply related
* Re: sky2 1.3-rc1
From: Stephen Hemminger @ 2006-05-05 17:45 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: Daniel Drake, Bill Hoover, Bertrand Jacquin, micheleschi, netdev,
teppic74
In-Reply-To: <20060505173509.GK2757@cip.informatik.uni-erlangen.de>
On Fri, 5 May 2006 19:35:09 +0200
Thomas Glanzmann <sithglan@stud.uni-erlangen.de> wrote:
> Hello,
>
> > > http://developer.osdl.org/shemminger/prototypes/sky2-1.3-rc1.tar.bz2
>
> > v0.15:
> > 64 bytes from 10.0.0.138: icmp_seq=2 ttl=64 time=0.467 ms
>
> > v1.3-rc1:
> > 64 bytes from 10.0.0.138: icmp_seq=4 ttl=64 time=32.9 ms
>
> I can't confirm this. For me it is just perfect:
>
> 64 bytes from 89.106.66.1: icmp_seq=1 ttl=64 time=0.278 ms
>
> 0000:04:00.0 Ethernet controller: Marvell Technology Group Ltd.: Unknown device 4361 (rev 17)
>
> Thomas
What is happening is that if there is a misconfiguration and irq routing
is messed up (ie edge trigged). The driver will degenerate to polling every 100ms.
If your system is this misconfigured, then ACPI or the BIOS needs to be fixed
and the driver really only needs to work well enough to get the bug report out ;-)
The older driver was doing rewhacking the Transmit IRQ status timer,
so it would give a bogus transmit status interrupt and that was masking
issues.
^ permalink raw reply
* Re: Machine check in bcm43xx_phy_initg
From: David Woodhouse @ 2006-05-05 18:18 UTC (permalink / raw)
To: Michael Buesch; +Cc: linville, bcm43xx-dev, Andrew Morton, netdev
In-Reply-To: <200605051942.39552.mb@bu3sch.de>
On Fri, 2006-05-05 at 19:42 +0200, Michael Buesch wrote:
> > Signed-off-by: David Woodhouse <dwmw2@infradead.org>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
>
> John, please apply. I will also send a patch for d80211.
Would be good to get this into 2.6.17 too.
--
dwmw2
^ permalink raw reply
* Re: Machine check in bcm43xx_phy_initg
From: Michael Buesch @ 2006-05-05 18:27 UTC (permalink / raw)
To: David Woodhouse; +Cc: linville, bcm43xx-dev, Andrew Morton, netdev
In-Reply-To: <1146853122.2766.42.camel@pmac.infradead.org>
On Friday 05 May 2006 20:18, you wrote:
> On Fri, 2006-05-05 at 19:42 +0200, Michael Buesch wrote:
> > > Signed-off-by: David Woodhouse <dwmw2@infradead.org>
> > Signed-off-by: Michael Buesch <mb@bu3sch.de>
> >
> > John, please apply. I will also send a patch for d80211.
>
> Would be good to get this into 2.6.17 too.
Absolutely, as it crashes machines.
That was my intention. ;)
--
Greetings Michael.
^ permalink raw reply
* Re: sky2 1.3-rc1
From: Daniel Drake @ 2006-05-05 18:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Glanzmann, Bill Hoover, Bertrand Jacquin, micheleschi,
netdev, teppic74
In-Reply-To: <20060505104536.2baefa5e@localhost.localdomain>
Stephen Hemminger wrote:
> What is happening is that if there is a misconfiguration and irq routing
> is messed up (ie edge trigged). The driver will degenerate to polling every 100ms.
> If your system is this misconfigured, then ACPI or the BIOS needs to be fixed
> and the driver really only needs to work well enough to get the bug report out ;-)
Ok, thanks for the explanation.
Can you give any hints as to how we can classify this misconfiguration?
Barry's system has a level triggered IRQ assigned to sky2, and that IRQ
is not shared:
http://bugs.gentoo.org/show_bug.cgi?id=132056#c3
I'm just looking for something I can take to the ACPI developers, other
than "its broken because Stephen said so" ;)
Thanks.
Daniel
^ permalink raw reply
* Re: [rfc][patch] ipvs: use proper timeout instead of fixed value
From: Andy Gospodarek @ 2006-05-05 18:57 UTC (permalink / raw)
To: Horms; +Cc: Andy Gospodarek, netdev, wensong, ja
In-Reply-To: <20060505032052.GY32328@verge.net.au>
On Fri, May 05, 2006 at 12:20:54PM +0900, Horms wrote:
>
> Sorry, I missunderstood your patch completely the first time around.
> Yes I think this is an excellent idea. Assuming its tested and works
> I'm happy to sign off on it and prod DaveM.
Horms,
I'll get a setup together and post results when I have them.
-andy
^ permalink raw reply
* [PATCH 1/4] [SCTP]: Allow spillover of receiver buffer to avoid deadlock
From: Sridhar Samudrala @ 2006-05-05 19:14 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
Dave,
Please apply the following 4 SCTP patches to 2.6 tree.
Thanks
Sridhar
[SCTP]: Allow spillover of receive buffer to avoid deadlock.
This patch fixes a deadlock situation in the receive path by allowing
temporary spillover of the receive buffer.
- If the chunk we receive has a tsn that immediately follows the ctsn,
accept it even if we run out of receive buffer space and renege data with
higher TSNs.
- Once we accept one chunk in a packet, accept all the remaining chunks
even if we run out of receive buffer space.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Mark Butler <butlerm@middle.net>
Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---
include/net/sctp/structs.h | 1 +
net/sctp/inqueue.c | 1 +
net/sctp/sm_statefuns.c | 46 ++++++++++++++++++++++++++++++++++----------
3 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index eba99f3..7f4fea1 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -712,6 +712,7 @@ struct sctp_chunk {
__u8 tsn_gap_acked; /* Is this chunk acked by a GAP ACK? */
__s8 fast_retransmit; /* Is this chunk fast retransmitted? */
__u8 tsn_missing_report; /* Data chunk missing counter. */
+ __u8 data_accepted; /* At least 1 chunk in this packet accepted */
};
void sctp_chunk_hold(struct sctp_chunk *);
diff --git a/net/sctp/inqueue.c b/net/sctp/inqueue.c
index 297b895..cf0c767 100644
--- a/net/sctp/inqueue.c
+++ b/net/sctp/inqueue.c
@@ -149,6 +149,7 @@ struct sctp_chunk *sctp_inq_pop(struct s
/* This is the first chunk in the packet. */
chunk->singleton = 1;
ch = (sctp_chunkhdr_t *) chunk->skb->data;
+ chunk->data_accepted = 0;
}
chunk->chunk_hdr = ch;
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 2b9a832..6834032 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -5151,7 +5151,9 @@ static int sctp_eat_data(const struct sc
int tmp;
__u32 tsn;
int account_value;
+ struct sctp_tsnmap *map = (struct sctp_tsnmap *)&asoc->peer.tsn_map;
struct sock *sk = asoc->base.sk;
+ int rcvbuf_over = 0;
data_hdr = chunk->subh.data_hdr = (sctp_datahdr_t *)chunk->skb->data;
skb_pull(chunk->skb, sizeof(sctp_datahdr_t));
@@ -5162,10 +5164,16 @@ static int sctp_eat_data(const struct sc
/* ASSERT: Now skb->data is really the user data. */
/*
- * if we are established, and we have used up our receive
- * buffer memory, drop the frame
- */
- if (asoc->state == SCTP_STATE_ESTABLISHED) {
+ * If we are established, and we have used up our receive buffer
+ * memory, think about droping the frame.
+ * Note that we have an opportunity to improve performance here.
+ * If we accept one chunk from an skbuff, we have to keep all the
+ * memory of that skbuff around until the chunk is read into user
+ * space. Therefore, once we accept 1 chunk we may as well accept all
+ * remaining chunks in the skbuff. The data_accepted flag helps us do
+ * that.
+ */
+ if ((asoc->state == SCTP_STATE_ESTABLISHED) && (!chunk->data_accepted)) {
/*
* If the receive buffer policy is 1, then each
* association can allocate up to sk_rcvbuf bytes
@@ -5176,9 +5184,25 @@ static int sctp_eat_data(const struct sc
account_value = atomic_read(&asoc->rmem_alloc);
else
account_value = atomic_read(&sk->sk_rmem_alloc);
-
- if (account_value > sk->sk_rcvbuf)
- return SCTP_IERROR_IGNORE_TSN;
+ if (account_value > sk->sk_rcvbuf) {
+ /*
+ * We need to make forward progress, even when we are
+ * under memory pressure, so we always allow the
+ * next tsn after the ctsn ack point to be accepted.
+ * This lets us avoid deadlocks in which we have to
+ * drop frames that would otherwise let us drain the
+ * receive queue.
+ */
+ if ((sctp_tsnmap_get_ctsn(map) + 1) != tsn)
+ return SCTP_IERROR_IGNORE_TSN;
+
+ /*
+ * We're going to accept the frame but we should renege
+ * to make space for it. This will send us down that
+ * path later in this function.
+ */
+ rcvbuf_over = 1;
+ }
}
/* Process ECN based congestion.
@@ -5226,6 +5250,7 @@ static int sctp_eat_data(const struct sc
datalen -= sizeof(sctp_data_chunk_t);
deliver = SCTP_CMD_CHUNK_ULP;
+ chunk->data_accepted = 1;
/* Think about partial delivery. */
if ((datalen >= asoc->rwnd) && (!asoc->ulpq.pd_mode)) {
@@ -5242,7 +5267,8 @@ static int sctp_eat_data(const struct sc
* large spill over.
*/
if (!asoc->rwnd || asoc->rwnd_over ||
- (datalen > asoc->rwnd + asoc->frag_point)) {
+ (datalen > asoc->rwnd + asoc->frag_point) ||
+ rcvbuf_over) {
/* If this is the next TSN, consider reneging to make
* room. Note: Playing nice with a confused sender. A
@@ -5250,8 +5276,8 @@ static int sctp_eat_data(const struct sc
* space and in the future we may want to detect and
* do more drastic reneging.
*/
- if (sctp_tsnmap_has_gap(&asoc->peer.tsn_map) &&
- (sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map) + 1) == tsn) {
+ if (sctp_tsnmap_has_gap(map) &&
+ (sctp_tsnmap_get_ctsn(map) + 1) == tsn) {
SCTP_DEBUG_PRINTK("Reneging for tsn:%u\n", tsn);
deliver = SCTP_CMD_RENEGE;
} else {
^ permalink raw reply related
* [PATCH 2/4] [SCTP]: Prevent possible infinite recursion with multiple bundled DATA.
From: Sridhar Samudrala @ 2006-05-05 19:14 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
[SCTP]: Prevent possible infinite recursion with multiple bundled DATA.
There is a rare situation that causes lksctp to go into infinite recursion
and crash the system. The trigger is a packet that contains at least the
first two DATA fragments of a message bundled together. The recursion is
triggered when the user data buffer is smaller that the full data message.
The problem is that we clone the skb for every fragment in the message.
When reassembling the full message, we try to link skbs from the "first
fragment" clone using the frag_list. However, since the frag_list is shared
between two clones in this rare situation, we end up setting the frag_list
pointer of the second fragment to point to itself. This causes
sctp_skb_pull() to potentially recurse indefinitely.
Proposed solution is to make a copy of the skb when attempting to link
things using frag_list.
Signed-off-by: Vladislav Yasevich <vladsilav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---
net/sctp/ulpqueue.c | 27 +++++++++++++++++++++++++--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index 2080b2d..9505c88 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -279,6 +279,7 @@ static inline void sctp_ulpq_store_reasm
static struct sctp_ulpevent *sctp_make_reassembled_event(struct sk_buff_head *queue, struct sk_buff *f_frag, struct sk_buff *l_frag)
{
struct sk_buff *pos;
+ struct sk_buff *new = NULL;
struct sctp_ulpevent *event;
struct sk_buff *pnext, *last;
struct sk_buff *list = skb_shinfo(f_frag)->frag_list;
@@ -297,11 +298,33 @@ static struct sctp_ulpevent *sctp_make_r
*/
if (last)
last->next = pos;
- else
- skb_shinfo(f_frag)->frag_list = pos;
+ else {
+ if (skb_cloned(f_frag)) {
+ /* This is a cloned skb, we can't just modify
+ * the frag_list. We need a new skb to do that.
+ * Instead of calling skb_unshare(), we'll do it
+ * ourselves since we need to delay the free.
+ */
+ new = skb_copy(f_frag, GFP_ATOMIC);
+ if (!new)
+ return NULL; /* try again later */
+
+ new->sk = f_frag->sk;
+
+ skb_shinfo(new)->frag_list = pos;
+ } else
+ skb_shinfo(f_frag)->frag_list = pos;
+ }
/* Remove the first fragment from the reassembly queue. */
__skb_unlink(f_frag, queue);
+
+ /* if we did unshare, then free the old skb and re-assign */
+ if (new) {
+ kfree_skb(f_frag);
+ f_frag = new;
+ }
+
while (pos) {
pnext = pos->next;
^ permalink raw reply related
* [PATCH 3/4] [SCTP]: Fix panic's when receiving fragmented SCTP control chunks.
From: Sridhar Samudrala @ 2006-05-05 19:14 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
[SCTP]: Fix panic's when receiving fragmented SCTP control chunks.
Use pskb_pull() to handle incoming COOKIE_ECHO and HEARTBEAT chunks that
are received as skb's with fragment list.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---
net/sctp/sm_statefuns.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 6834032..27514f3 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -636,8 +636,9 @@ sctp_disposition_t sctp_sf_do_5_1D_ce(co
*/
chunk->subh.cookie_hdr =
(struct sctp_signed_cookie *)chunk->skb->data;
- skb_pull(chunk->skb,
- ntohs(chunk->chunk_hdr->length) - sizeof(sctp_chunkhdr_t));
+ if (!pskb_pull(chunk->skb, ntohs(chunk->chunk_hdr->length) -
+ sizeof(sctp_chunkhdr_t)))
+ goto nomem;
/* 5.1 D) Upon reception of the COOKIE ECHO chunk, Endpoint
* "Z" will reply with a COOKIE ACK chunk after building a TCB
@@ -965,7 +966,8 @@ sctp_disposition_t sctp_sf_beat_8_3(cons
*/
chunk->subh.hb_hdr = (sctp_heartbeathdr_t *) chunk->skb->data;
paylen = ntohs(chunk->chunk_hdr->length) - sizeof(sctp_chunkhdr_t);
- skb_pull(chunk->skb, paylen);
+ if (!pskb_pull(chunk->skb, paylen))
+ goto nomem;
reply = sctp_make_heartbeat_ack(asoc, chunk,
chunk->subh.hb_hdr, paylen);
@@ -1860,8 +1862,9 @@ sctp_disposition_t sctp_sf_do_5_2_4_dupc
* are in good shape.
*/
chunk->subh.cookie_hdr = (struct sctp_signed_cookie *)chunk->skb->data;
- skb_pull(chunk->skb, ntohs(chunk->chunk_hdr->length) -
- sizeof(sctp_chunkhdr_t));
+ if (!pskb_pull(chunk->skb, ntohs(chunk->chunk_hdr->length) -
+ sizeof(sctp_chunkhdr_t)))
+ goto nomem;
/* In RFC 2960 5.2.4 3, if both Verification Tags in the State Cookie
* of a duplicate COOKIE ECHO match the Verification Tags of the
^ permalink raw reply related
* [PATCH 4/4] [SCTP]: Fix state table entries for chunks received in CLOSED state.
From: Sridhar Samudrala @ 2006-05-05 19:14 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
[SCTP]: Fix state table entries for chunks received in CLOSED state.
Discard an unexpected chunk in CLOSED state rather can calling BUG().
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---
net/sctp/sm_statetable.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/sctp/sm_statetable.c b/net/sctp/sm_statetable.c
index 75ef104..8bcca56 100644
--- a/net/sctp/sm_statetable.c
+++ b/net/sctp/sm_statetable.c
@@ -366,9 +366,9 @@ #define TYPE_SCTP_ECN_ECNE { \
/* SCTP_STATE_EMPTY */ \
{.fn = sctp_sf_ootb, .name = "sctp_sf_ootb"}, \
/* SCTP_STATE_CLOSED */ \
- {.fn = sctp_sf_bug, .name = "sctp_sf_bug"}, \
+ {.fn = sctp_sf_discard_chunk, .name = "sctp_sf_discard_chunk"}, \
/* SCTP_STATE_COOKIE_WAIT */ \
- {.fn = sctp_sf_bug, .name = "sctp_sf_bug"}, \
+ {.fn = sctp_sf_discard_chunk, .name = "sctp_sf_discard_chunk"}, \
/* SCTP_STATE_COOKIE_ECHOED */ \
{.fn = sctp_sf_do_ecne, .name = "sctp_sf_do_ecne"}, \
/* SCTP_STATE_ESTABLISHED */ \
@@ -380,7 +380,7 @@ #define TYPE_SCTP_ECN_ECNE { \
/* SCTP_STATE_SHUTDOWN_RECEIVED */ \
{.fn = sctp_sf_do_ecne, .name = "sctp_sf_do_ecne"}, \
/* SCTP_STATE_SHUTDOWN_ACK_SENT */ \
- {.fn = sctp_sf_bug, .name = "sctp_sf_bug"}, \
+ {.fn = sctp_sf_discard_chunk, .name = "sctp_sf_discard_chunk"}, \
} /* TYPE_SCTP_ECN_ECNE */
#define TYPE_SCTP_ECN_CWR { \
@@ -401,7 +401,7 @@ #define TYPE_SCTP_ECN_CWR { \
/* SCTP_STATE_SHUTDOWN_RECEIVED */ \
{.fn = sctp_sf_discard_chunk, .name = "sctp_sf_discard_chunk"}, \
/* SCTP_STATE_SHUTDOWN_ACK_SENT */ \
- {.fn = sctp_sf_bug, .name = "sctp_sf_bug"}, \
+ {.fn = sctp_sf_discard_chunk, .name = "sctp_sf_discard_chunk"}, \
} /* TYPE_SCTP_ECN_CWR */
#define TYPE_SCTP_SHUTDOWN_COMPLETE { \
@@ -647,7 +647,7 @@ #define TYPE_SCTP_PRIMITIVE_REQUESTHEART
/* SCTP_STATE_EMPTY */ \
{.fn = sctp_sf_bug, .name = "sctp_sf_bug"}, \
/* SCTP_STATE_CLOSED */ \
- {.fn = sctp_sf_bug, .name = "sctp_sf_bug"}, \
+ {.fn = sctp_sf_error_closed, .name = "sctp_sf_error_closed"}, \
/* SCTP_STATE_COOKIE_WAIT */ \
{.fn = sctp_sf_do_prm_requestheartbeat, \
.name = "sctp_sf_do_prm_requestheartbeat"}, \
^ permalink raw reply related
* A custom Logo that expresses your company! (ID3712810)
From: Haley Rose @ 2006-05-05 22:41 UTC (permalink / raw)
To: ner
vay
Our art team creates a custom logo for you, based on your needs. Years of experience have taught us how to create a logo that makes a statement that is unique to you.
In a professional manner we learn about your image and how you would like the world to perceive you and your company. With this information we then create a logo that is not only unique but reflects the purpose of you and your company.
For value and a logo that reflects your image, take a few minutes and visit Logo Maker!
http://commend.info.logotip-marke.com
Sincerely,
Logo Design Team
alb bark crewmen
^ permalink raw reply
* Re: sky2 1.3-rc1
From: Stephen Hemminger @ 2006-05-05 19:43 UTC (permalink / raw)
To: Daniel Drake
Cc: Thomas Glanzmann, Bill Hoover, Bertrand Jacquin, micheleschi,
netdev, teppic74
In-Reply-To: <445B9C93.4070406@gentoo.org>
On Fri, 05 May 2006 19:42:27 +0100
Daniel Drake <dsd@gentoo.org> wrote:
> Stephen Hemminger wrote:
> > What is happening is that if there is a misconfiguration and irq routing
> > is messed up (ie edge trigged). The driver will degenerate to polling every 100ms.
> > If your system is this misconfigured, then ACPI or the BIOS needs to be fixed
> > and the driver really only needs to work well enough to get the bug report out ;-)
>
> Ok, thanks for the explanation.
>
> Can you give any hints as to how we can classify this misconfiguration?
> Barry's system has a level triggered IRQ assigned to sky2, and that IRQ
> is not shared:
>
> http://bugs.gentoo.org/show_bug.cgi?id=132056#c3
>
> I'm just looking for something I can take to the ACPI developers, other
> than "its broken because Stephen said so" ;)
Try running idle_timeout=0 module parameter. In that case there will be no
polling timer. If it just hangs, then the problem is missed interrupt.
You could use this to see if you are getting irq's
--- sky2.orig/drivers/net/sky2.c
+++ sky2/drivers/net/sky2.c
@@ -2125,6 +2125,9 @@ static int sky2_poll(struct net_device *
int work_done = 0;
u32 status = sky2_read32(hw, B0_Y2_SP_EISR);
+ if (netif_msg_intr((struct sky2_port *) netdev_priv(dev0)))
+ printk(KERN_DEBUG PFX "poll status %#x\n", status);
+
if (status & Y2_IS_HW_ERR)
sky2_hw_intr(hw);
@@ -2183,6 +2186,9 @@ static irqreturn_t sky2_intr(int irq, vo
if (status == 0 || status == ~0)
return IRQ_NONE;
+ if (netif_msg_intr((struct sky2_port *) netdev_priv(dev0)))
+ printk(KERN_DEBUG PFX "irq status %#x\n", status);
+
prefetch(&hw->st_le[hw->st_idx]);
if (likely(__netif_rx_schedule_prep(dev0)))
__netif_rx_schedule(dev0);
^ permalink raw reply
* [PATCH 1/3] bcm43xx-d80211: check for valid MAC address in SPROM
From: Stefano Brivio @ 2006-05-05 19:55 UTC (permalink / raw)
To: John W. Linville; +Cc: bcm43xx-dev, netdev
Please apply to wireless-dev.
--
Check for valid MAC address in SPROM fields instead of relying on PHY type
while setting the MAC address in the networking subsystem, as some devices
have multiple PHYs.
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 00:50:00.370034536 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 02:43:44.981535888 +0200
@@ -3482,7 +3482,7 @@
bcm43xx_pctl_set_crystal(bcm, 0);
/* Set the MAC address in the networking subsystem */
- if (bcm43xx_current_phy(bcm)->type == BCM43xx_PHYTYPE_A)
+ if (is_valid_ether_addr(bcm->sprom.et1macaddr))
memcpy(bcm->net_dev->dev_addr, bcm->sprom.et1macaddr, 6);
else
memcpy(bcm->net_dev->dev_addr, bcm->sprom.il0macaddr, 6);
--
Ciao
Stefano
^ permalink raw reply
* [PATCH 3/3] bcm43xx-d80211: add PCI ID for bcm4319
From: Stefano Brivio @ 2006-05-05 19:59 UTC (permalink / raw)
To: John W. Linville; +Cc: bcm43xx-dev, netdev
In-Reply-To: <20060505215542.25d310dd@localhost>
Add PCI ID for bcm4319.
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 00:50:00.370034536 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 02:56:42.216378232 +0200
@@ -132,6 +132,8 @@ MODULE_PARM_DESC(fwpostfix, "Postfix for
{ PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4318 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+ /* Broadcom 4319 802.11b/g */
+ { PCI_VENDOR_ID_BROADCOM, 0x4319, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4306 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4320, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4306 802.11a */
--
Ciao
Stefano
^ permalink raw reply
* [PATCH 2/3] bcm43xx-d80211: fix whitespace
From: Stefano Brivio @ 2006-05-05 19:59 UTC (permalink / raw)
To: John W. Linville; +Cc: bcm43xx-dev, netdev
In-Reply-To: <20060505215542.25d310dd@localhost>
Fix whitespace.
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 00:50:00.370034536 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 02:43:44.981535888 +0200
@@ -128,13 +128,13 @@
static struct pci_device_id bcm43xx_pci_tbl[] = {
/* Broadcom 4303 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4307 802.11b */
+ /* Broadcom 4307 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4318 802.11b/g */
+ /* Broadcom 4318 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4306 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4320, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4306 802.11a */
+ /* Broadcom 4306 802.11a */
// { PCI_VENDOR_ID_BROADCOM, 0x4321, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4309 802.11a/b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4324, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
--
Ciao
Stefano
^ permalink raw reply
* [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Larry Finger @ 2006-05-05 20:14 UTC (permalink / raw)
To: netdev, Faidon Liambotis, Rick Jones, Ulrich Kunitz, Harald Welte,
Jouni Malinen, Christoph Hellwig
Thanks to all that responded to my earlier RFC. A number of changes in my thinking are based on
those comments, which came from Christoph Hellwig, Rick Jones, Ulrich Kunitz, Faidon Liambotis,
Jouni Malinen, and Harald Welte. The important points of my proposal are as follows:
* The database will be maintained as a text file to be processed by a userland daemon that will
transform this database into the data structure needed by the ieee80211 code. In addition to the
regulatory data, this file will also contain the information needed for the daemon to set the size
of its data arrays dynamically.
* A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo
structure into the kernel. Information passed to the daemon will be the country code in ASCII and
whether the interface is to be used indoors or outdoors.
* Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit
anyone with moderate skills from hacking the channel/power settings, but such hacking will require
some effort.
* Each channel in the resulting kernel data structure will have appropriate flags set indicating if
it is to be used indoors, outdoors, or both. In addition, if the channel should be used only for
passive scanning, a suitable flag will be set. In the 2.4 GHz band, a flag will indicate if it
should be used for 802.11b, otherwise both b and g mode will be assumed. In the 5.0 GHz bands, a
flag will be set if the channel is to conform with 802.11h or 802.11a standards.
The database consists of two sections. The first relates the Country Codes to a wireless group. The
second section describes the channel parameters for the groups. Shown below is a fragment showing
the Country Code - Group info for a few countries and the definitions for a few of the groups.
Please send me any comments, etc.
Larry
===================================================================
# text file for IEEE80211 Regulatory/Geographical information
#
# Version of 04 May 2006
#
# Information for dynamic array sizing
#
Number of Countries: 100
Number of Groups: 15
#
# Countries listed first
#
# group Country Code Description
#
1 AT Austria (Standard EU)
1 DE Germany (Standard EU)
2 FRI France Indoor (Not Guyana or La Reunion)
3 FRO France Outdoor (Not Guyana or La Reunion)
4 FR1 French Departments of Guyana and La Reunion Indoor
5 FR2 French Departments of Guyana and La Reunion Outdoor
.
.
.
9 US United States (FCC)
#
#
# Groups follow countries
#
Group 0 - Unspecified Country
#
# Band Ch. Range Ch. Spacing Power Flags
#
# Band - b, bg, a, or h
# Ch. Range - Minimum and Maximum Channels for this range
# Ch. Spacing - Number of channels between adjacent entries
# Power in mW EIRP
# Flag Codes
# B - Both Indoor and Outdoor
# I - Indoor Only
# O - Outdoor Only
# P - Passive Scan Only
#
bg 1 - 11 1 100 B
#
Group 1 - General European Union (EU)
#
bg 1 - 13 1 100 B
h 36 - 40 4 200 I
h 52 - 64 4 200 IP
h 100 - 140 4 1000 BP
#
Group 2 - France Indoor (Not Guyana or La Reunion)
#
bg 1 - 13 1 100 I
h 36 - 48 4 200 I
h 52 - 64 4 200 IP
h 100 - 140 4 1000 IP
#
Group 3 - France Outdoor (Not Guyana or La Reunion)
#
bg 1 - 8 1 100 O
bg 9 - 13 1 10 O
h 100 - 140 4 1000 OP
.
.
.
.
#
Group 9 - US (FCC)
#
bg 1 - 11 1 100 B
a 36 - 40 4 200 I
a 52 - 64 4 200 B
a 149 - 161 4 1000 B
#
^ permalink raw reply
* IPv6 connect() from site-local to global IPv6 address.
From: David Woodhouse @ 2006-05-05 21:00 UTC (permalink / raw)
To: NetDev
I've been using and testing IPv6 on a private network.
Machines have RFC1918 IPv4 addresses, with connectivity by NAT to the
outside world. They also have site-local IPv6 addresses. There is
approximately zero chance of getting corporate approval to have external
IPv6 connectivity.
Since updating the kernel to 2.6.16, I've got problems with external
connectivity to hosts which have both IPv4 and (Global) IPv6 addresses
in DNS. Glibc used to return the IPv4 address in the A record first, and
all was well. But now it returns the IPv6 address in the AAAA record
first, and I can't communicate with that. So I get a three-minute
timeout whenever I try to connect to anything in the outside which has
both A and AAAA records.
One of the things which glibc's implementation of RFC3484 address
selection (http://people.redhat.com/drepper/linux-rfc3484.html) does is
to perform a dummy connect() of a SOCK_DGRAM socket to each of the
potential addresses. On older kernels this used to fail when we
attempted to connect to a global IPv6 address and we didn't have a
global IPv6 address of our own...
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:8b0:10b:1:20d:93ff:fe7a:3f2c", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("81.187.2.168")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(33450), sin_addr=inet_addr("172.16.18.126")}, [16]) = 0
Trying 81.187.2.168...
On the newer kernel, the connect() succeeds:
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:8b0:10b:1:20d:93ff:fe7a:3f2c", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(32772), inet_pton(AF_INET6, "::172.16.18.67", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("81.187.2.168")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(32772), sin_addr=inet_addr("172.16.18.67")}, [16]) = 0
Trying 2001:8b0:10b:1:20d:93ff:fe7a:3f2c...
Is this change in behaviour intentional? Is it useful?
How can we get sane behaviour from glibc again? What we had before was
ideal -- if we have an IPv6 default route _and_ we have a Global IPv6
address of our own, then return the Global IPv6 address in the AAAA
record first. Else return the IPv4 address in the A record.
--
dwmw2
^ permalink raw reply
* Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Uli Kunitz @ 2006-05-05 21:08 UTC (permalink / raw)
To: Larry Finger
Cc: netdev, Faidon Liambotis, Rick Jones, Ulrich Kunitz, Harald Welte,
Jouni Malinen, Christoph Hellwig
In-Reply-To: <445BB22B.30505@lwfinger.net>
Larry Finger wrote:
> * A new routine (ieee80211_init_geo ?) will be written to be called by the
> driver to load the geo structure into the kernel. Information passed to the
> daemon will be the country code in ASCII and whether the interface is to be
> used indoors or outdoors.
Would it be possible to support the regulatory domain codes as
used in the outdated table 105 in Corrigendum 1 for 802.11b? The
ZD1211 EEPROM contains only this code. An easy translation
function would be sufficient. Maybe the group codes could be
misused for it.
Uli
--
Uli Kunitz (kune@deine-taler.de)
^ 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