Hi,
Can Wireless network cards receive and transmit on two channels at once?
I am thinking of implementing a way for a wireless VoIP phone on Linux
being able to hand off from one AP to another without dropping the call.
For this to work, the wireless card must be able to chat on two channels
On 07-02-04 10:42 James Courtier-Dutton wrote:
Hi,
Can Wireless network cards receive and transmit on two channels at once?
I am thinking of implementing a way for a wireless VoIP phone on Linux
being able to hand off from one AP to another without dropping the call.
For this to work, the
James,
Can Wireless network cards receive and transmit on two channels at once?
No cards that I know of contain two PHYs which would (afaict) be
required for this.
johannes
signature.asc
Description: This is a digitally signed message part
remove unneeded call to skb_queue_len (skb_dequeue already checks queuelen) and
replace a sizeof() by a Netlink Macro
Signed-off-by: Thomas Hisch [EMAIL PROTECTED]
---
sorry, my previous version of this patch didn't conform to the Codingstyle
document.
now everything should be fine.
On 2/4/07, David Miller [EMAIL PROTECTED] wrote:
From: Thomas Hisch [EMAIL PROTECTED]
Date: Sun, 4 Feb 2007 15:29:21 +0100
remove unneeded call to skb_queue_len (skb_dequeue already checks queuelen)
and
replace a sizeof() by a Netlink Macro
Signed-off-by: Thomas Hisch [EMAIL PROTECTED]
From: Thomas Hisch [EMAIL PROTECTED]
Date: Sun, 4 Feb 2007 15:29:21 +0100
remove unneeded call to skb_queue_len (skb_dequeue already checks queuelen)
and
replace a sizeof() by a Netlink Macro
Signed-off-by: Thomas Hisch [EMAIL PROTECTED]
You don't understand the code you are editing :-)
On 2/4/07, Parag Warudkar [EMAIL PROTECTED] wrote:
I am running 2.6.20 and have trouble with stalled connections. For
instance, if I try to download a debian ISO image using wget, the
connection runs fine for few seconds and then stalls for ever.
In my router logs I see a ton of messages like
On Thu, 2007-02-01 at 12:04 +0100, Jens Osterkamp wrote:
Ishizaki-san,
This patch partially works on celleb but remains
following several problems.
1. It doesn't recover once an ethernet cable which is
connected to a spider_net card is unpluged.
My understanding is that you are
We use bcm5461. There is a possibility that we don't know the appropriate
setting which is applicable for both type of switches.
Have you tested the existing 54xx code in sungem_phy.c ? We use that
with 5462 at least in K2 and all sorts of 54xx chips and it works
fine... Just setup the right
Shinta-san, let me know when an updated version of your
patches are available, I'd like to include them in 2.6.21
Thank you.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Wed, 31 Jan 2007 14:42:50 +0900 (JST)
[IPV6] ROUTE: Do not route packets to link-local address on other device.
With help from Wei Dong [EMAIL PROTECTED].
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Applied, thank you.
-
To
Dear David,
Thank you for your consideration.
Updated patches will be ready by Feb 7th (Wednesday) 22:00 JST at the latest.
Hopefully I can send them earlier, after finishing tests for the kernel
with the patch set that incorporates all the comments received.
Regards,
Shinta
On Sun, 04 Feb
From: ahendry [EMAIL PROTECTED]
Date: Thu, 04 Jan 2007 14:37:15 +1100
View the active forwarded call list
cat /proc/net/x25/forward
Signed-off-by: Andrew Hendry [EMAIL PROTECTED]
Applied, thanks a lot.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
From: James Morris [EMAIL PROTECTED]
Date: Thu, 1 Feb 2007 18:44:48 -0500 (EST)
A quick dirty solution, which is what I think the BSD kernels do, is to
still drop the packet but just not return an error to the app. The app
then just sees a slight delay on the initial connection, as if a
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
received and so the machine can't get an IP address. I tried reverting
all the -mm changes to drivers/net/forcedeth.c, which didn't help. The
network
On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock [EMAIL PROTECTED] wrote:
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
received and so the machine can't get an IP address. I tried reverting
* Parag Warudkar [EMAIL PROTECTED] [070205 00:57]:
On 2/4/07, Parag Warudkar [EMAIL PROTECTED] wrote:
I am running 2.6.20 and have trouble with stalled connections. For
instance, if I try to download a debian ISO image using wget, the
connection runs fine for few seconds and then stalls for
Andrew Morton wrote:
On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock [EMAIL PROTECTED] wrote:
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
received and so the machine can't get an IP address.
On Sun, 04 Feb 2007 23:48:33 -0600 Robert Hancock [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock [EMAIL PROTECTED] wrote:
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
2.6.20-rc6. There's no errors in dmesg, but
On Sun, 4 Feb 2007, Robert Hancock wrote:
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
received and so the machine can't get an IP address. I tried reverting all the
-mm changes to
From: Baruch Even [EMAIL PROTECTED]
Date: Fri, 02 Feb 2007 16:41:16 +0200
Only advance the SACK fast-path pointer for the first block, the fast-path
assumes that only the first block advances next time so we should not move the
cached skb for the next sack blocks.
Signed-Off-By: Baruch Even
From: Baruch Even [EMAIL PROTECTED]
Date: Fri, 02 Feb 2007 16:41:21 +0200
Move DSACK code outside the SACK fast-path checking code. If the DSACK
determined that the information was too old we stayed with a partial cache
copied. Most likely this matters very little since the next packet will
From: Baruch Even [EMAIL PROTECTED]
Date: Fri, 02 Feb 2007 16:41:27 +0200
We clear the unused parts of the SACK cache, This prevents us from mistakenly
taking the cache data if the old data in the SACK cache is the same as the
data
in the SACK block. This assumes that we never receive an
23 matches
Mail list logo
