Joerg Roedel wrote:
+ To configure tunnels an extra tool is required. You can download
+ it from http://zlug.fh-zwickau.de/~joro/projects/ under the
+ EtherIP section. If unsure, say N.
To obtain a list of tunnels, this tool calls SIOCGETTUNNEL
(SIOCDEVPRIVATE + 0) for every
Patrick McHardy wrote:
Joerg Roedel wrote:
On Thu, Sep 14, 2006 at 11:21:22AM +1000, Philip Craig wrote:
Joerg Roedel wrote:
+ To configure tunnels an extra tool is required. You can download
+ it from http://zlug.fh-zwickau.de/~joro/projects/ under the
+ EtherIP section. If unsure
David Miller wrote:
I've been sitting on this patch because afaik the problem which it purports
to fix remains unfixed.
Should I drop it??
Thanks.
Please drop it, the patch submitted didn't give us the feedback
and test results we asked for which is necessary to pinpoint the
true issue
On 04/14/2006 06:26 AM, David S. Miller wrote:
These interfaces were added so that new users of netlink could
write their code more easily.
Unused does not equate to comment out or delete.
Does a GENETLINK Kconfig option make sense (possibly dependant on
EMBEDDED)? I'm unsure whether these
Implement the ethtool eeprom operations for the 8139cp driver.
Tested on x86 and big-endian ARM.
Signed-off-by: Philip Craig [EMAIL PROTECTED]
Index: linux-2.6.17-rc6/drivers/net/8139cp.c
===
--- linux-2.6.17-rc6.orig/drivers/net
The read command for the 93C46/93C56 EEPROMS should be 3 bits plus
the address. This doesn't appear to affect the operation of the
read command, but similar errors for write commands do cause failures.
Signed-off-by: Philip Craig [EMAIL PROTECTED]
Index: linux-2.6.17-rc6/drivers/net/8139cp.c
Implement the ethtool eeprom operations for the 8139cp driver.
Tested on x86 and big-endian ARM.
Signed-off-by: Philip Craig [EMAIL PROTECTED]
Index: linux-2.6.17-rc6/drivers/net/8139cp.c
===
--- linux-2.6.17-rc6.orig/drivers/net
The read command for the 93C46/93C56 EEPROMS should be 3 bits plus
the address. This doesn't appear to affect the operation of the
read command, but similar errors for write commands do cause failures.
Signed-off-by: Philip Craig [EMAIL PROTECTED]
Index: linux-2.6.17-rc6/drivers/net/8139cp.c
Francois Romieu wrote:
Mostly taken from Realtek's driver.
It's a bit yucky but the original is even worse.
This patch fixes a performance regression for my 8169s.
But it appears to have a typo, see below.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Signed-off-by: Darren Salt
Sebastian Kuzminsky wrote:
I'm seeing some weird behavior in TCP. The issue is perfectly
reproducible using netcat and other programs. This is what I do:
1. Open a TCP connection over the loopback (over IPv4).
2. Send a couple of bytes of data each way. No problems.
3.
Sebastian Kuzminsky wrote:
Weird. Why does sending a message from the client make it go again?
The rule that allows packets with an ESTABLISHED state only matches
packets for which the connection is in netfilter's conntrack table.
The connection is removed from the table after the 5 days of
Sebastian Kuzminsky wrote:
Why did the packet from the client cause the connection to be added back
to the conntrack table, but the packet from the server did not?
Because the packet from the client was accepted (by a different
iptables rule).
-
To unsubscribe from this list: send the line
Francois Romieu wrote:
Two thirds of packets are lost because of misalignment. Users of
Asus laptop did apparently not notice it.
Reported on Gigabyte GA-945GM-S2.
Fix for http://bugzilla.kernel.org/show_bug.cgi?id=7517
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
Francois Romieu wrote:
Philip Craig [EMAIL PROTECTED] :
[...]
This patch caused a drop in throughput from 178 Mbits/sec to 135 Mbits/sec
on an Intel XScale IXP465.
Which distribution of packet sizes ?
Just using iperf with the default options, MTU 1500,
forwarding between 2 PCs
Francois Romieu wrote:
The experimental r8169 patch of the day against 2.6.21-rc1 is available at:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21-rc1/
Is 0006-r8169-confusion-between-hardware-and-IP-header-alignment.txt
the only relevant patch?
This only partially helps. Many of the
On 06/22/2006 02:55 PM, Andrew Morton wrote:
- Is there a better way of doing this?
static void ql_swap_mac_addr(u8 * macAddress)
{
#ifdef __BIG_ENDIAN
u8 temp;
temp = macAddress[0];
macAddress[0] = macAddress[1];
macAddress[1] = temp;
temp = macAddress[2];
This patch implements transparent ethernet bridging for gre tunnels.
There are a few outstanding issues.
There is no way for userspace to select the type of gre tunnel. The
#if 0 near the top of the patch forces all gre tunnels to be bridges.
The problem is that userspace uses an IPPROTO_ to
Stephen Hemminger wrote:
On Mon, 31 Jul 2006 20:06:41 +1000
Philip Craig [EMAIL PROTECTED] wrote:
This patch implements transparent ethernet bridging for gre tunnels.
There are a few outstanding issues.
Why not use existing bridge code?
It does use the existing bridge code. Perhaps
Stephen Hemminger wrote:
I am not against making the bridge code smarter to handle other
encapsulation.
Do you mean something like this patch?
The only drawback I see for this approach is that it means you
can only encapsulate the ethernet header if the gre interface is
bridged. That's not
Stephen Hemminger wrote:
I am not against making the bridge code smarter to handle other
encapsulation.
Here's an updated patch that fixes all issues I am aware of.
It generates a random mac address for gre ports, and also stores
a copy of the mac address for ethernet ports, rather than
Stephen Hemminger wrote:
On Wed, 02 Aug 2006 16:17:42 +1000
Philip Craig [EMAIL PROTECTED] wrote:
It generates a random mac address for gre ports, and also stores
a copy of the mac address for ethernet ports, rather than checking
dev-type everywhere.
That looks cleaner. I wonder if using
Lennert Buytenhek wrote:
So now you _need_ bridging in the middle to send ethernet traffic over
a GRE tunnel? Ugh.
Agreed that would not be nice. What is the usage scenario for this?
At least one end of the tunnel will be bridged?
If you really want to send ethernet and non-ethernet traffic
Lennert Buytenhek wrote:
On Thu, Aug 03, 2006 at 07:14:59PM +1000, Philip Craig wrote:
So now you _need_ bridging in the middle to send ethernet traffic over
a GRE tunnel? Ugh.
Agreed that would not be nice. What is the usage scenario for this?
At least one end of the tunnel
Lennert Buytenhek wrote:
I have one machine at home that appears to be on my employer's network
via such a tunnel. I don't use bridging, because I don't need any other
machine at home to access this tunnel. I do want bridging, and not proxy
ARP, because it allows me to run arpwatch, and
Laszlo Attila Toth wrote:
Hello,
Different network interfaces can be grouped using the same group ID. With this
patch fewer netfilter rules are necessary but it may also be used by routing.
This allows an interface to belong to only one group. I expect there are
situations where you want
Joe Perches wrote:
Perhaps it's more sensible to go back to
#ifdef DEBUG
#define pr_debug(fmt, arg...) do {} while (0)
#endif
and give up the printf argument verification
I think argument verification is important. Can you keep it
like this:
#ifdef DEBUG
#define pr_debug(fmt, arg...)
26 matches
Mail list logo
