* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-18 5:53 UTC (permalink / raw)
To: sfr
Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm
In-Reply-To: <20110818152214.661858a61496993aaef2c704@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 18 Aug 2011 15:22:14 +1000
> Mikey asks: Will Dave take these updates if we get Acks from the
> maintainers? :-)
I'm more than happy to :-)
^ permalink raw reply
* [PATCH] fix IBM EMAC driver after rename.
From: Tony Breeds @ 2011-08-18 6:13 UTC (permalink / raw)
To: Netdev List, David Miller, Jeff Kirsher
In commit 9aa3283595451ca093500ff0977b106e1f465586 (ehea/ibm*: Move the
IBM drivers) the IBM_NEW_EMAC* were renames to IBM_EMAC*
The conversion was incomplete so that even if the driver was added to
the .config it wasn't built, but there were no errors)
This should fix those omissions.
Tested on a canyondlands board.
---
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/40x/Kconfig | 12 +++---
arch/powerpc/platforms/44x/Kconfig | 54 ++++++++++++++++----------------
arch/powerpc/platforms/cell/Kconfig | 8 ++--
drivers/net/ethernet/ibm/emac/Makefile | 10 +++---
drivers/net/ethernet/ibm/emac/core.c | 12 +++---
drivers/net/ethernet/ibm/emac/core.h | 16 +++++-----
drivers/net/ethernet/ibm/emac/debug.h | 2 +-
drivers/net/ethernet/ibm/emac/mal.c | 6 ++--
drivers/net/ethernet/ibm/emac/mal.h | 4 +-
drivers/net/ethernet/ibm/emac/rgmii.h | 4 +-
drivers/net/ethernet/ibm/emac/tah.h | 4 +-
drivers/net/ethernet/ibm/emac/zmii.h | 4 +-
12 files changed, 68 insertions(+), 68 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index d733d7c..b5d8706 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -130,21 +130,21 @@ config 405GP
bool
select IBM405_ERR77
select IBM405_ERR51
- select IBM_NEW_EMAC_ZMII
+ select IBM_EMAC_ZMII
config 405EP
bool
config 405EX
bool
- select IBM_NEW_EMAC_EMAC4
- select IBM_NEW_EMAC_RGMII
+ select IBM_EMAC_EMAC4
+ select IBM_EMAC_RGMII
config 405EZ
bool
- select IBM_NEW_EMAC_NO_FLOW_CTRL
- select IBM_NEW_EMAC_MAL_CLR_ICINTSTAT
- select IBM_NEW_EMAC_MAL_COMMON_ERR
+ select IBM_EMAC_NO_FLOW_CTRL
+ select IBM_EMAC_MAL_CLR_ICINTSTAT
+ select IBM_EMAC_MAL_COMMON_ERR
config 405GPR
bool
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index e958b6f..762322c 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -23,7 +23,7 @@ config BLUESTONE
default n
select PPC44x_SIMPLE
select APM821xx
- select IBM_NEW_EMAC_RGMII
+ select IBM_EMAC_RGMII
help
This option enables support for the APM APM821xx Evaluation board.
@@ -122,8 +122,8 @@ config CANYONLANDS
select PPC4xx_PCI_EXPRESS
select PCI_MSI
select PPC4xx_MSI
- select IBM_NEW_EMAC_RGMII
- select IBM_NEW_EMAC_ZMII
+ select IBM_EMAC_RGMII
+ select IBM_EMAC_ZMII
help
This option enables support for the AMCC PPC460EX evaluation board.
@@ -135,8 +135,8 @@ config GLACIER
select 460EX # Odd since it uses 460GT but the effects are the same
select PCI
select PPC4xx_PCI_EXPRESS
- select IBM_NEW_EMAC_RGMII
- select IBM_NEW_EMAC_ZMII
+ select IBM_EMAC_RGMII
+ select IBM_EMAC_ZMII
help
This option enables support for the AMCC PPC460GT evaluation board.
@@ -161,7 +161,7 @@ config EIGER
select 460SX
select PCI
select PPC4xx_PCI_EXPRESS
- select IBM_NEW_EMAC_RGMII
+ select IBM_EMAC_RGMII
help
This option enables support for the AMCC PPC460SX evaluation board.
@@ -260,59 +260,59 @@ config 440EP
bool
select PPC_FPU
select IBM440EP_ERR42
- select IBM_NEW_EMAC_ZMII
+ select IBM_EMAC_ZMII
select USB_ARCH_HAS_OHCI
config 440EPX
bool
select PPC_FPU
- select IBM_NEW_EMAC_EMAC4
- select IBM_NEW_EMAC_RGMII
- select IBM_NEW_EMAC_ZMII
+ select IBM_EMAC_EMAC4
+ select IBM_EMAC_RGMII
+ select IBM_EMAC_ZMII
config 440GRX
bool
- select IBM_NEW_EMAC_EMAC4
- select IBM_NEW_EMAC_RGMII
- select IBM_NEW_EMAC_ZMII
+ select IBM_EMAC_EMAC4
+ select IBM_EMAC_RGMII
+ select IBM_EMAC_ZMII
config 440GP
bool
- select IBM_NEW_EMAC_ZMII
+ select IBM_EMAC_ZMII
config 440GX
bool
- select IBM_NEW_EMAC_EMAC4
- select IBM_NEW_EMAC_RGMII
- select IBM_NEW_EMAC_ZMII #test only
- select IBM_NEW_EMAC_TAH #test only
+ select IBM_EMAC_EMAC4
+ select IBM_EMAC_RGMII
+ select IBM_EMAC_ZMII #test only
+ select IBM_EMAC_TAH #test only
config 440SP
bool
config 440SPe
bool
- select IBM_NEW_EMAC_EMAC4
+ select IBM_EMAC_EMAC4
config 460EX
bool
select PPC_FPU
- select IBM_NEW_EMAC_EMAC4
- select IBM_NEW_EMAC_TAH
+ select IBM_EMAC_EMAC4
+ select IBM_EMAC_TAH
config 460SX
bool
select PPC_FPU
- select IBM_NEW_EMAC_EMAC4
- select IBM_NEW_EMAC_RGMII
- select IBM_NEW_EMAC_ZMII
- select IBM_NEW_EMAC_TAH
+ select IBM_EMAC_EMAC4
+ select IBM_EMAC_RGMII
+ select IBM_EMAC_ZMII
+ select IBM_EMAC_TAH
config APM821xx
bool
select PPC_FPU
- select IBM_NEW_EMAC_EMAC4
- select IBM_NEW_EMAC_TAH
+ select IBM_EMAC_EMAC4
+ select IBM_EMAC_TAH
# 44x errata/workaround config symbols, selected by the CPU models above
config IBM440EP_ERR42
diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig
index 67d5009..2e7ff0c 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -17,10 +17,10 @@ config PPC_CELL_NATIVE
select PPC_CELL_COMMON
select MPIC
select PPC_IO_WORKAROUNDS
- select IBM_NEW_EMAC_EMAC4
- select IBM_NEW_EMAC_RGMII
- select IBM_NEW_EMAC_ZMII #test only
- select IBM_NEW_EMAC_TAH #test only
+ select IBM_EMAC_EMAC4
+ select IBM_EMAC_RGMII
+ select IBM_EMAC_ZMII #test only
+ select IBM_EMAC_TAH #test only
default n
config PPC_IBM_CELL_BLADE
diff --git a/drivers/net/ethernet/ibm/emac/Makefile b/drivers/net/ethernet/ibm/emac/Makefile
index 0b5c995..ed6470c 100644
--- a/drivers/net/ethernet/ibm/emac/Makefile
+++ b/drivers/net/ethernet/ibm/emac/Makefile
@@ -2,10 +2,10 @@
# Makefile for the PowerPC 4xx on-chip ethernet driver
#
-obj-$(CONFIG_IBM_NEW_EMAC) += ibm_newemac.o
+obj-$(CONFIG_IBM_EMAC) += ibm_newemac.o
ibm_newemac-y := mal.o core.o phy.o
-ibm_newemac-$(CONFIG_IBM_NEW_EMAC_ZMII) += zmii.o
-ibm_newemac-$(CONFIG_IBM_NEW_EMAC_RGMII) += rgmii.o
-ibm_newemac-$(CONFIG_IBM_NEW_EMAC_TAH) += tah.o
-ibm_newemac-$(CONFIG_IBM_NEW_EMAC_DEBUG) += debug.o
+ibm_newemac-$(CONFIG_IBM_EMAC_ZMII) += zmii.o
+ibm_newemac-$(CONFIG_IBM_EMAC_RGMII) += rgmii.o
+ibm_newemac-$(CONFIG_IBM_EMAC_TAH) += tah.o
+ibm_newemac-$(CONFIG_IBM_EMAC_DEBUG) += debug.o
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index 70cb7d8..6e014ae 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -90,7 +90,7 @@ MODULE_LICENSE("GPL");
/* If packet size is less than this number, we allocate small skb and copy packet
* contents into it instead of just sending original big skb up
*/
-#define EMAC_RX_COPY_THRESH CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD
+#define EMAC_RX_COPY_THRESH CONFIG_IBM_EMAC_RX_COPY_THRESHOLD
/* Since multiple EMACs share MDIO lines in various ways, we need
* to avoid re-using the same PHY ID in cases where the arch didn't
@@ -1618,7 +1618,7 @@ static void emac_parse_rx_error(struct emac_instance *dev, u16 ctrl)
static inline void emac_rx_csum(struct emac_instance *dev,
struct sk_buff *skb, u16 ctrl)
{
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
+#ifdef CONFIG_IBM_EMAC_TAH
if (!ctrl && dev->tah_dev) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
++dev->stats.rx_packets_csum;
@@ -2577,7 +2577,7 @@ static int __devinit emac_init_config(struct emac_instance *dev)
of_device_is_compatible(np, "ibm,emac-440gr"))
dev->features |= EMAC_FTR_440EP_PHY_CLK_FIX;
if (of_device_is_compatible(np, "ibm,emac-405ez")) {
-#ifdef CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL
+#ifdef CONFIG_IBM_EMAC_NO_FLOW_CTRL
dev->features |= EMAC_FTR_NO_FLOW_CONTROL_40x;
#else
printk(KERN_ERR "%s: Flow control not disabled!\n",
@@ -2601,7 +2601,7 @@ static int __devinit emac_init_config(struct emac_instance *dev)
/* Enable TAH/ZMII/RGMII features as found */
if (dev->tah_ph != 0) {
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
+#ifdef CONFIG_IBM_EMAC_TAH
dev->features |= EMAC_FTR_HAS_TAH;
#else
printk(KERN_ERR "%s: TAH support not enabled !\n",
@@ -2611,7 +2611,7 @@ static int __devinit emac_init_config(struct emac_instance *dev)
}
if (dev->zmii_ph != 0) {
-#ifdef CONFIG_IBM_NEW_EMAC_ZMII
+#ifdef CONFIG_IBM_EMAC_ZMII
dev->features |= EMAC_FTR_HAS_ZMII;
#else
printk(KERN_ERR "%s: ZMII support not enabled !\n",
@@ -2621,7 +2621,7 @@ static int __devinit emac_init_config(struct emac_instance *dev)
}
if (dev->rgmii_ph != 0) {
-#ifdef CONFIG_IBM_NEW_EMAC_RGMII
+#ifdef CONFIG_IBM_EMAC_RGMII
dev->features |= EMAC_FTR_HAS_RGMII;
#else
printk(KERN_ERR "%s: RGMII support not enabled !\n",
diff --git a/drivers/net/ethernet/ibm/emac/core.h b/drivers/net/ethernet/ibm/emac/core.h
index 4fec084..fa3ec57 100644
--- a/drivers/net/ethernet/ibm/emac/core.h
+++ b/drivers/net/ethernet/ibm/emac/core.h
@@ -47,8 +47,8 @@
#include "tah.h"
#include "debug.h"
-#define NUM_TX_BUFF CONFIG_IBM_NEW_EMAC_TXB
-#define NUM_RX_BUFF CONFIG_IBM_NEW_EMAC_RXB
+#define NUM_TX_BUFF CONFIG_IBM_EMAC_TXB
+#define NUM_RX_BUFF CONFIG_IBM_EMAC_RXB
/* Simple sanity check */
#if NUM_TX_BUFF > 256 || NUM_RX_BUFF > 256
@@ -72,7 +72,7 @@ static inline int emac_rx_size(int mtu)
#define EMAC_DMA_ALIGN(x) ALIGN((x), dma_get_cache_alignment())
#define EMAC_RX_SKB_HEADROOM \
- EMAC_DMA_ALIGN(CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM)
+ EMAC_DMA_ALIGN(CONFIG_IBM_EMAC_RX_SKB_HEADROOM)
/* Size of RX skb for the given MTU */
static inline int emac_rx_skb_size(int mtu)
@@ -335,21 +335,21 @@ enum {
EMAC_FTRS_ALWAYS = 0,
EMAC_FTRS_POSSIBLE =
-#ifdef CONFIG_IBM_NEW_EMAC_EMAC4
+#ifdef CONFIG_IBM_EMAC_EMAC4
EMAC_FTR_EMAC4 | EMAC_FTR_EMAC4SYNC |
EMAC_FTR_HAS_NEW_STACR |
EMAC_FTR_STACR_OC_INVERT | EMAC_FTR_440GX_PHY_CLK_FIX |
#endif
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
+#ifdef CONFIG_IBM_EMAC_TAH
EMAC_FTR_HAS_TAH |
#endif
-#ifdef CONFIG_IBM_NEW_EMAC_ZMII
+#ifdef CONFIG_IBM_EMAC_ZMII
EMAC_FTR_HAS_ZMII |
#endif
-#ifdef CONFIG_IBM_NEW_EMAC_RGMII
+#ifdef CONFIG_IBM_EMAC_RGMII
EMAC_FTR_HAS_RGMII |
#endif
-#ifdef CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL
+#ifdef CONFIG_IBM_EMAC_NO_FLOW_CTRL
EMAC_FTR_NO_FLOW_CONTROL_40x |
#endif
EMAC_FTR_460EX_PHY_CLK_FIX |
diff --git a/drivers/net/ethernet/ibm/emac/debug.h b/drivers/net/ethernet/ibm/emac/debug.h
index e596c77..90477fe 100644
--- a/drivers/net/ethernet/ibm/emac/debug.h
+++ b/drivers/net/ethernet/ibm/emac/debug.h
@@ -24,7 +24,7 @@
#include "core.h"
-#if defined(CONFIG_IBM_NEW_EMAC_DEBUG)
+#if defined(CONFIG_IBM_EMAC_DEBUG)
struct emac_instance;
struct mal_instance;
diff --git a/drivers/net/ethernet/ibm/emac/mal.c b/drivers/net/ethernet/ibm/emac/mal.c
index d268f40..f3c50b9 100644
--- a/drivers/net/ethernet/ibm/emac/mal.c
+++ b/drivers/net/ethernet/ibm/emac/mal.c
@@ -577,8 +577,8 @@ static int __devinit mal_probe(struct platform_device *ofdev)
}
if (of_device_is_compatible(ofdev->dev.of_node, "ibm,mcmal-405ez")) {
-#if defined(CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT) && \
- defined(CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR)
+#if defined(CONFIG_IBM_EMAC_MAL_CLR_ICINTSTAT) && \
+ defined(CONFIG_IBM_EMAC_MAL_COMMON_ERR)
mal->features |= (MAL_FTR_CLEAR_ICINTSTAT |
MAL_FTR_COMMON_ERR_INT);
#else
@@ -616,7 +616,7 @@ static int __devinit mal_probe(struct platform_device *ofdev)
init_dummy_netdev(&mal->dummy_dev);
netif_napi_add(&mal->dummy_dev, &mal->napi, mal_poll,
- CONFIG_IBM_NEW_EMAC_POLL_WEIGHT);
+ CONFIG_IBM_EMAC_POLL_WEIGHT);
/* Load power-on reset defaults */
mal_reset(mal);
diff --git a/drivers/net/ethernet/ibm/emac/mal.h b/drivers/net/ethernet/ibm/emac/mal.h
index 6608421..d06f985 100644
--- a/drivers/net/ethernet/ibm/emac/mal.h
+++ b/drivers/net/ethernet/ibm/emac/mal.h
@@ -245,10 +245,10 @@ enum {
MAL_FTRS_ALWAYS = 0,
MAL_FTRS_POSSIBLE =
-#ifdef CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT
+#ifdef CONFIG_IBM_EMAC_MAL_CLR_ICINTSTAT
MAL_FTR_CLEAR_ICINTSTAT |
#endif
-#ifdef CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR
+#ifdef CONFIG_IBM_EMAC_MAL_COMMON_ERR
MAL_FTR_COMMON_ERR_INT |
#endif
0,
diff --git a/drivers/net/ethernet/ibm/emac/rgmii.h b/drivers/net/ethernet/ibm/emac/rgmii.h
index d697990..9296b6c 100644
--- a/drivers/net/ethernet/ibm/emac/rgmii.h
+++ b/drivers/net/ethernet/ibm/emac/rgmii.h
@@ -54,7 +54,7 @@ struct rgmii_instance {
struct platform_device *ofdev;
};
-#ifdef CONFIG_IBM_NEW_EMAC_RGMII
+#ifdef CONFIG_IBM_EMAC_RGMII
extern int rgmii_init(void);
extern void rgmii_exit(void);
@@ -77,6 +77,6 @@ extern void *rgmii_dump_regs(struct platform_device *ofdev, void *buf);
# define rgmii_set_speed(x,y,z) do { } while(0)
# define rgmii_get_regs_len(x) 0
# define rgmii_dump_regs(x,buf) (buf)
-#endif /* !CONFIG_IBM_NEW_EMAC_RGMII */
+#endif /* !CONFIG_IBM_EMAC_RGMII */
#endif /* __IBM_NEWEMAC_RGMII_H */
diff --git a/drivers/net/ethernet/ibm/emac/tah.h b/drivers/net/ethernet/ibm/emac/tah.h
index 61dbeca..3437ab4 100644
--- a/drivers/net/ethernet/ibm/emac/tah.h
+++ b/drivers/net/ethernet/ibm/emac/tah.h
@@ -70,7 +70,7 @@ struct tah_instance {
#define TAH_MR_DTFP 0x00100000
#define TAH_MR_DIG 0x00080000
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
+#ifdef CONFIG_IBM_EMAC_TAH
extern int tah_init(void);
extern void tah_exit(void);
@@ -90,6 +90,6 @@ extern void *tah_dump_regs(struct platform_device *ofdev, void *buf);
# define tah_get_regs_len(x) 0
# define tah_dump_regs(x,buf) (buf)
-#endif /* !CONFIG_IBM_NEW_EMAC_TAH */
+#endif /* !CONFIG_IBM_EMAC_TAH */
#endif /* __IBM_NEWEMAC_TAH_H */
diff --git a/drivers/net/ethernet/ibm/emac/zmii.h b/drivers/net/ethernet/ibm/emac/zmii.h
index 1333fa2..ceaed82 100644
--- a/drivers/net/ethernet/ibm/emac/zmii.h
+++ b/drivers/net/ethernet/ibm/emac/zmii.h
@@ -51,7 +51,7 @@ struct zmii_instance {
struct platform_device *ofdev;
};
-#ifdef CONFIG_IBM_NEW_EMAC_ZMII
+#ifdef CONFIG_IBM_EMAC_ZMII
extern int zmii_init(void);
extern void zmii_exit(void);
@@ -73,6 +73,6 @@ extern void *zmii_dump_regs(struct platform_device *ofdev, void *buf);
# define zmii_set_speed(x,y,z) do { } while(0)
# define zmii_get_regs_len(x) 0
# define zmii_dump_regs(x,buf) (buf)
-#endif /* !CONFIG_IBM_NEW_EMAC_ZMII */
+#endif /* !CONFIG_IBM_EMAC_ZMII */
#endif /* __IBM_NEWEMAC_ZMII_H */
--
1.7.6
^ permalink raw reply related
* [patch net-2.6] forcedeth: call vlan_mode only if hw supports vlans
From: Jiri Pirko @ 2011-08-18 6:37 UTC (permalink / raw)
To: netdev; +Cc: davem, mirqus, mingo, torvalds, akpm
If hw does not support vlans, dont call nv_vlan_mode because it has no point.
I believe that this should fix issues on older non-vlan supportive
chips (like Ingo has).
Reported-ty: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/forcedeth.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index e55df30..6d5fbd4 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -5615,7 +5615,8 @@ static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_i
goto out_error;
}
- nv_vlan_mode(dev, dev->features);
+ if (id->driver_data & DEV_HAS_VLAN)
+ nv_vlan_mode(dev, dev->features);
netif_carrier_off(dev);
--
1.7.6
^ permalink raw reply related
* Re: [patch net-2.6] forcedeth: call vlan_mode only if hw supports vlans
From: David Miller @ 2011-08-18 6:50 UTC (permalink / raw)
To: jpirko; +Cc: netdev, mirqus, mingo, torvalds, akpm
In-Reply-To: <1313649471-31555-1-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 18 Aug 2011 08:37:51 +0200
> If hw does not support vlans, dont call nv_vlan_mode because it has no point.
> I believe that this should fix issues on older non-vlan supportive
> chips (like Ingo has).
>
> Reported-ty: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] fix IBM EMAC driver after rename.
From: Oliver Hartkopp @ 2011-08-18 6:50 UTC (permalink / raw)
To: Tony Breeds; +Cc: Netdev List, David Miller, Jeff Kirsher
In-Reply-To: <20110818061354.GD19739@ozlabs.org>
On 18.08.2011 08:13, Tony Breeds wrote:
> In commit 9aa3283595451ca093500ff0977b106e1f465586 (ehea/ibm*: Move the
> IBM drivers) the IBM_NEW_EMAC* were renames to IBM_EMAC*
>
> The conversion was incomplete so that even if the driver was added to
> the .config it wasn't built, but there were no errors)
>
> This should fix those omissions.
>
(..)
What about renaming of newemac -> emac in this part of the Makefile?
> diff --git a/drivers/net/ethernet/ibm/emac/Makefile b/drivers/net/ethernet/ibm/emac/Makefile
> index 0b5c995..ed6470c 100644
> --- a/drivers/net/ethernet/ibm/emac/Makefile
> +++ b/drivers/net/ethernet/ibm/emac/Makefile
> @@ -2,10 +2,10 @@
> # Makefile for the PowerPC 4xx on-chip ethernet driver
> #
>
> -obj-$(CONFIG_IBM_NEW_EMAC) += ibm_newemac.o
> +obj-$(CONFIG_IBM_EMAC) += ibm_newemac.o
here s/ibm_newemac.o/ibm_emac.o/
>
> ibm_newemac-y := mal.o core.o phy.o
> -ibm_newemac-$(CONFIG_IBM_NEW_EMAC_ZMII) += zmii.o
> -ibm_newemac-$(CONFIG_IBM_NEW_EMAC_RGMII) += rgmii.o
> -ibm_newemac-$(CONFIG_IBM_NEW_EMAC_TAH) += tah.o
> -ibm_newemac-$(CONFIG_IBM_NEW_EMAC_DEBUG) += debug.o
> +ibm_newemac-$(CONFIG_IBM_EMAC_ZMII) += zmii.o
> +ibm_newemac-$(CONFIG_IBM_EMAC_RGMII) += rgmii.o
> +ibm_newemac-$(CONFIG_IBM_EMAC_TAH) += tah.o
> +ibm_newemac-$(CONFIG_IBM_EMAC_DEBUG) += debug.o
and here s/ibm_newemac-/ibm_emac-/ ???
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH] fix IBM EMAC driver after rename.
From: David Miller @ 2011-08-18 6:49 UTC (permalink / raw)
To: tony; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <20110818061354.GD19739@ozlabs.org>
From: Tony Breeds <tony@bakeyournoodle.com>
Date: Thu, 18 Aug 2011 16:13:55 +1000
> In commit 9aa3283595451ca093500ff0977b106e1f465586 (ehea/ibm*: Move the
> IBM drivers) the IBM_NEW_EMAC* were renames to IBM_EMAC*
>
> The conversion was incomplete so that even if the driver was added to
> the .config it wasn't built, but there were no errors)
>
> This should fix those omissions.
>
> Tested on a canyondlands board.
You also need to select the dependencies, such as "ETHERNET" for this
to be correct.
^ permalink raw reply
* protect raw sockets
From: Naveen B N (nbn) @ 2011-08-18 8:15 UTC (permalink / raw)
To: netdev
Hi All,
Is there a way to enforce IPsec protection for packets sent from
application using RAW_SOCKET.
My analysis is to add a code at the raw_sendmsg() & raw_v4_input() to
call xfrm_policy_check() ..
Is it a good method to proceed or is there a better and smart way to
achieve this .
Hoping for some guide lines ..
Thanks in advance ..
Thanks and Regards
Naveen
^ permalink raw reply
* Re: protect raw sockets
From: krbmit siso @ 2011-08-18 8:28 UTC (permalink / raw)
To: netdev, ipsec-tools-users, ipsec-tools-devel, ikev2-devel,
Timo Teräs
In-Reply-To: <A2354B6A9F807641B21EEABD666ECEEA011AFCE2@XMB-BGL-416.cisco.com>
Hi Timo,
Thanks for your reply .
Yes i did explore this yesterday and i was successful in sending the IKE
messages unprotected after using the below code only for UDP sockets.
int setsockopt_bypass(int fd, int family)
{
struct sadb_x_policy policy;
int level, optname;
switch (family) {
case AF_INET:
level = IPPROTO_IP;
optname = IP_IPSEC_POLICY;
break;
case AF_INET6:
level = IPPROTO_IPV6;
optname = IPV6_IPSEC_POLICY;
break;
default:
return -1;
}
memset(&policy, 0, sizeof(policy));
policy.sadb_x_policy_len = PFKEY_UNIT64(sizeof(policy));
policy.sadb_x_policy_exttype = SADB_X_EXT_POLICY;
policy.sadb_x_policy_type = IPSEC_POLICY_BYPASS;
policy.sadb_x_policy_dir = IPSEC_DIR_INBOUND;
if (setsockopt(fd, level, optname, &policy, sizeof(policy)) == -1) {
return -1;
}
policy.sadb_x_policy_dir = IPSEC_DIR_OUTBOUND;
if (setsockopt(fd, level, optname, &policy, sizeof(policy)) == -1) {
return -1;
}
return 0;
}
But i did try the same on RAW socket by setting the policy has
policy.sadb_x_policy_type = IPSEC_POLICY_ENTRUST|IPSEC_POLICY_IPSEC;
But the packet is going unprotected .
Please show some light on how to protect RAW packets if there is a Policy
matching in the SPD saying it need to be protected.
I have checked the posting there is no help on this isues , could
you please give some options , if it is possible from Application.
Thanks and Regards
Naveen
On Thu, Aug 18, 2011 at 1:45 PM, Naveen B N (nbn) <nbn@cisco.com> wrote:
> Hi All,
> Is there a way to enforce IPsec protection for packets sent from
> application using RAW_SOCKET.
>
> My analysis is to add a code at the raw_sendmsg() & raw_v4_input() to
> call xfrm_policy_check() ..
> Is it a good method to proceed or is there a better and smart way to
> achieve this .
>
> Hoping for some guide lines ..
>
> Thanks in advance ..
>
> Thanks and Regards
> Naveen
> --
> 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
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 41312] New: Regression: some web services (e.g. Dropbox, Amazon Cloud Reader) stops working in 3.1-rc2
From: Michel Alexandre Salim @ 2011-08-18 10:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugme-daemon
In-Reply-To: <20110817134106.015135cd.akpm@linux-foundation.org>
On Wed, Aug 17, 2011 at 10:41 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
Replying via email; please let me know if there's any further tests I
can do. I forgot to add the system details: tested on
- Fedora 15 x86_64, wireless network (ath9k)
- Fedora 15 x86_64, wired network (e1000e)
> On Wed, 17 Aug 2011 20:17:05 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=41312
>>
>> Summary: Regression: some web services (e.g. Dropbox, Amazon
>> Cloud Reader) stops working in 3.1-rc2
>> Product: Networking
>> Version: 2.5
>> Kernel Version: 3.1-rc2
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: IPV4
>> AssignedTo: shemminger@linux-foundation.org
>> ReportedBy: salimma@fedoraproject.org
>> Regression: Yes
>>
>>
>> Created an attachment (id=69102)
>> --> (https://bugzilla.kernel.org/attachment.cgi?id=69102)
>> (working) config for kernel 3.0
>>
>> Dropbox and Amazon Cloud Reader works just fine on kernel 3.0, but the former
>> does not work on 3.1-rc1 and 3.1-rc2, and the latter does not work on 3.1-rc2
>> (I no longer have a copy of the 3.1-rc1 build I did).
>>
>> With Dropbox, ps reports that the daemon process is in an uninterruptible
>> state, and it cannot be killed (even with kill -9). Setting SELinux to
>> permissive does not affect things (and Dropbox works with SELinux set to
>> enforcing with kernel 3.0).
>>
>> With Cloud Reader, on Chrome, it does not display any book -- I perpetually get
>> the "refreshing" icon.
>>
>> Will attach kernel configurations (I keep the 3.0 and 3.1-rc2 configs as
>> similar as possible, by using 'make oldconfig' on 3.0 with 3.1-rc2's .config.
>>
>> Reported on Dropbox's forum: http://forums.dropbox.com/topic.php?id=43140
>>
>
>
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma@fedoraproject.org | GPG key ID: 78884778
Jabber: hircus@jabber.ccc.de | IRC: hircus@irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
^ permalink raw reply
* [PATCH NEXT 1/1] MAINTAINERS: change netxen_nic maintainers
From: amit.salecha @ 2011-08-18 10:44 UTC (permalink / raw)
To: davem
Cc: netdev, ameen.rahman, Amit Kumar Salecha, Sony Chacko,
Rajesh Borundia
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
I will no longer maintain netxen_nic driver.
Sony Chacko and Rajesh Borundia are taking over.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Cc: Sony Chacko <sony.chacko@qlogic.com>
Cc: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
MAINTAINERS | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d374c6f..79edb1c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4495,7 +4495,8 @@ F: include/linux/if_*
F: include/linux/*device.h
NETXEN (1/10) GbE SUPPORT
-M: Amit Kumar Salecha <amit.salecha@qlogic.com>
+M: Sony Chacko <sony.chacko@qlogic.com>
+M: Rajesh Borundia <rajesh.borundia@qlogic.com>
L: netdev@vger.kernel.org
W: http://www.qlogic.com
S: Supported
--
1.7.3.3
^ permalink raw reply related
* Re: [PATCH NEXT 1/1] MAINTAINERS: change netxen_nic maintainers
From: David Miller @ 2011-08-18 11:13 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, sony.chacko, rajesh.borundia
In-Reply-To: <1313664250-14639-1-git-send-email-amit.salecha@qlogic.com>
From: <amit.salecha@qlogic.com>
Date: Thu, 18 Aug 2011 03:44:10 -0700
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> I will no longer maintain netxen_nic driver.
> Sony Chacko and Rajesh Borundia are taking over.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied, thank you.
^ permalink raw reply
* [PATCH net-next-2.6] be2net: Storing the 'vid' got by the grp5 event instead of storing the vlan_tag
From: Somnath Kotur @ 2011-08-18 16:40 UTC (permalink / raw)
To: netdev, davem; +Cc: Somnath Kotur
Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 4278595..bec039d 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -140,7 +140,7 @@ static void be_async_grp5_pvid_state_process(struct be_adapter *adapter,
struct be_async_event_grp5_pvid_state *evt)
{
if (evt->enabled)
- adapter->pvid = le16_to_cpu(evt->tag);
+ adapter->pvid = le16_to_cpu(evt->tag) & VLAN_VID_MASK;
else
adapter->pvid = 0;
}
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 7c98d8e..cbc10c9 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1277,8 +1277,7 @@ static struct be_rx_compl_info *be_rx_compl_get(struct be_rx_obj *rxo)
if (!lancer_chip(adapter))
rxcp->vlan_tag = swab16(rxcp->vlan_tag);
- if (((adapter->pvid & VLAN_VID_MASK) ==
- (rxcp->vlan_tag & VLAN_VID_MASK)) &&
+ if (adapter->pvid == (rxcp->vlan_tag & VLAN_VID_MASK) &&
!adapter->vlan_tag[rxcp->vlan_tag])
rxcp->vlanf = 0;
}
--
1.5.6.1
^ permalink raw reply related
* Re: [PATCH] bnx2x: downgrade Max BW error message to debug
From: Michal Schmidt @ 2011-08-18 11:37 UTC (permalink / raw)
To: eilong; +Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <1313603055.12483.3.camel@lb-tlvb-eilong.il.broadcom.com>
On Wed, 17 Aug 2011 20:44:15 +0300 Eilon Greenstein wrote:
> I think that we should use DP instead of DBG_ERR. How about this one:
...
> Can you sing-off on somethign like this?
OK, let's use DP. Thanks!
Subject: [PATCH v2] bnx2x: downgrade Max BW error message to debug
There are valid configurations where Max BW is configured to zero for
some VNs.
Print the message only if debugging is enabled and do not call the
configuration "illegal".
[v2: use DP(), not BNX2X_DBG_ERR(); recommended by Eilon Greenstein.]
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
index 223bfee..9059aef 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
@@ -1481,8 +1481,8 @@ static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, u32 mf_cfg)
u16 max_cfg = (mf_cfg & FUNC_MF_CFG_MAX_BW_MASK) >>
FUNC_MF_CFG_MAX_BW_SHIFT;
if (!max_cfg) {
- BNX2X_ERR("Illegal configuration detected for Max BW - "
- "using 100 instead\n");
+ DP(NETIF_MSG_LINK,
+ "Max BW configured to 0 - using 100 instead\n");
max_cfg = 100;
}
return max_cfg;
--
1.7.6
^ permalink raw reply related
* Re: [Bug 41212] New: [regression] [3.1-git] ipoib causes kernel panic (NULL pointer dereference)
From: Bernd Schubert @ 2011-08-18 11:44 UTC (permalink / raw)
To: Erez Shitrit
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAAk-MO9Y4h7scaJEE9aFKw9sp=VF3YZrT+oY2xvQY9tvGhvOTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Erez,
maybe it is another bug? Do you have the stack trace?
Any I guess you are the networking expert ;) I only looked at the
3.1-ipoib issue, as it prevented me too boot at all and I couldn't do my
real work...
Cheers,
Bernd
On 08/17/2011 11:06 AM, Erez Shitrit wrote:
> Hi Bernd,
> you are right, but it still happened. (also no changes in IPoIB between
> the tags, it might connected to the networking? )
>
> Thanks, Erez
>
> On Tue, Aug 16, 2011 at 1:34 PM, Bernd Schubert
> <bernd.schubert-97jfqw80gc6171pxa8y+qA@public.gmane.org <mailto:bernd.schubert-97jfqw80gc6171pxa8y+qA@public.gmane.org>> wrote:
>
> Hello Erez,
>
> are you sure? Commit 69cce1d1404968f78b177a0314f582 2d5afdbbfb is
> not in 3.0 yet and I also don't see how 3.0 should fail there, as it
> tests immediately for "if (likely(skb_dst(skb)"
>
>
> Thanks,
> Bernd
>
>
> On 08/16/2011 10:06 AM, Erez Shitrit wrote:
>
> Hi,
> it happened in 3.0 also, if you take the git tag v3.0-rc7 and
> below it
> will work.
>
> Thanks, Erez
>
> On Mon, Aug 15, 2011 at 6:40 PM, <bugzilla-daemon@bugzilla.
> kernel.org <mailto:bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org>
> <mailto:bugzilla-daemon@ bugzilla.kernel.org
> <mailto:bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org>>> wrote:
>
> https://bugzilla.kernel.org/ show_bug.cgi?id=41212
> <https://bugzilla.kernel.org/show_bug.cgi?id=41212>
>
> Summary: [regression] [3.1-git] ipoib causes
> kernel panic
> (NULL
> pointer dereference)
> Product: Networking
> Version: 2.5
> Kernel Version: 3.1-git
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org
> <mailto:acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
> <mailto:acme@ghostprotocols. net <mailto:acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>>
>
> ReportedBy: bernd.schubert-97jfqw80gc6171pxa8y+qA@public.gmane.org
> <mailto:bernd.schubert-97jfqw80gc6171pxa8y+qA@public.gmane.org>
> <mailto:bernd.schubert@ fastmail.fm
> <mailto:bernd.schubert-97jfqw80gc6171pxa8y+qA@public.gmane.org>>
>
> CC: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> <mailto:linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> <mailto:linux-rdma@vger. kernel.org
> <mailto:linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>>
>
> Regression: Yes
>
>
> Each time when I start IPoIB with any 3.1-rcX git version I
> tested
> so far I get
> a kernel panic. This didn't happen in 3.0 yet.
>
>
> fslab2 login: [ 114.392408] EXT4-fs (sdc): barriers disabled
> [ 114.449737] EXT4-fs (sdc): mounted filesystem with
> writeback data
> mode.
> Opts: journal_async_commit,barrier= 0,data=writeback
> [ 240.944030] BUG: unable to handle kernel NULL pointer
> dereference at
> 0000000000000040
> [ 240.948007] IP: [<ffffffffa0366ce9>]
> ipoib_start_xmit+0x39/0x280
> [ib_ipoib]
> [ 240.948007] PGD 1f964f067 PUD 1f9bf2067 PMD 0
> [ 240.948007] Oops: 0000 [#1] SMP
> [ 240.948007] CPU 1
> [ 240.948007] Modules linked in: ext4 mbcache jbd2 crc16 nfsd
> ib_umad rdma_ucm
> rdma_cm iw_cm ib_addr ib_uverbs ib_ipoib sg ib_cm ib_sa ipv6
> sd_mod
> crc_t10dif
> loop arcmsr md_mod pcspkr ib_mthca ib_mad ib_core 8250_pnp fuse
> af_packet nfs
> lockd fscache auth_rpcgss nfs_acl sunrpc btrfs lzo_decompress
> lzo_compress
> zlib_deflate crc32c libcrc32c crypto_hash crypto_algapi
> ata_generic
> pata_acpi
> e1000 pata_amd sata_nv libata scsi_mod unix [last unloaded:
> scsi_wait_scan]
> [ 240.948007]
> [ 240.948007] Pid: 0, comm: kworker/0:0 Not tainted
> 3.1.0-rc2+ #29
> Supermicro
> H8DCE/H8DCE
> [ 240.948007] RIP: 0010:[<ffffffffa0366ce9>]
> [<ffffffffa0366ce9>]
> ipoib_start_xmit+0x39/0x280 [ib_ipoib]
> [ 240.948007] RSP: 0018:ffff8801ffc03c10 EFLAGS: 00010246
> [ 240.948007] RAX: 0000000000000000 RBX: ffff8801f99ea000 RCX:
> 0000000000004420
> [ 240.948007] RDX: 0000000000000000 RSI: ffff8801f99ea000 RDI:
> ffff8801f9afd500
> [ 240.948007] RBP: ffff8801ffc03c40 R08: ffff8801f940d49c R09:
> ffff8801f9852240
> [ 240.948007] R10: 0000000000000000 R11: 0000000000000020 R12:
> ffff8801f9afd500
> [ 240.948007] R13: 0000000000000050 R14: ffff8801f99ea600 R15:
> ffff8801f9852280
> [ 240.948007] FS: 00007f0b66016700(0000)
> GS:ffff8801ffc00000(0000)
> knlGS:0000000000000000
> [ 240.948007] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 240.948007] CR2: 0000000000000040 CR3: 00000001f9a65000 CR4:
> 00000000000006e0
> [ 240.948007] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 240.948007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 240.948007] Process kworker/0:0 (pid: 0, threadinfo
> ffff8800bfe82000, task
> ffff8800bfe6f1a0)
> [ 240.948007] Stack:
> [ 240.948007] 0000000000000010 ffff8801f9afd500
> 0000000000004420
> 0000000000000050
> [ 240.948007] ffff8801f99ea000 ffff8801f9852280
> ffff8801ffc03ca0
> ffffffff812cd5e0
> [ 240.948007] 0000000000000001 ffffffffa03721a0
> ffffffff8131f680
> ffff8801fa110540
> [ 240.948007] Call Trace:
> [ 240.948007] <IRQ>
> [ 240.948007] [<ffffffff812cd5e0>]
> dev_hard_start_xmit+0x2a0/ 0x590
> [ 240.948007] [<ffffffff8131f680>] ? arp_create+0x70/0x200
> [ 240.948007] [<ffffffff812e8e1f>] sch_direct_xmit+0xef/0x1c0
> [ 240.948007] [<ffffffff812cd9f9>] dev_queue_xmit+0x129/0x3b0
> [ 240.948007] [<ffffffff8131f853>] arp_send+0x43/0x50
> [ 240.948007] [<ffffffff8131f96b>] arp_solicit+0x10b/0x240
>
> --
> Configure bugmail: https://bugzilla.kernel.org/
> userprefs.cgi?tab=email
> <https://bugzilla.kernel.org/userprefs.cgi?tab=email>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> <mailto:majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> <mailto:majordomo-u79uwXL29TasMV2rI37PzA@public.gmane.org org
> <mailto:majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>>
>
> More majordomo info at http://vger.kernel.org/
> majordomo-info.html <http://vger.kernel.org/majordomo-info.html>
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] bnx2x: downgrade Max BW error message to debug
From: Eilon Greenstein @ 2011-08-18 12:22 UTC (permalink / raw)
To: Michal Schmidt
Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <20110818133751.3ba77279@brian.englab.brq.redhat.com>
On Thu, 2011-08-18 at 04:37 -0700, Michal Schmidt wrote:
> On Wed, 17 Aug 2011 20:44:15 +0300 Eilon Greenstein wrote:
> > I think that we should use DP instead of DBG_ERR. How about this one:
> ...
> > Can you sing-off on somethign like this?
>
> OK, let's use DP. Thanks!
>
>
> Subject: [PATCH v2] bnx2x: downgrade Max BW error message to debug
>
> There are valid configurations where Max BW is configured to zero for
> some VNs.
> Print the message only if debugging is enabled and do not call the
> configuration "illegal".
>
> [v2: use DP(), not BNX2X_DBG_ERR(); recommended by Eilon Greenstein.]
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Acked-by: Eilon Greenstein <eilong@broadcom.com>
Thanks Michal!
^ permalink raw reply
* Re: Linux vs FreeBSD Which is correct.
From: Stephen Clark @ 2011-08-18 12:42 UTC (permalink / raw)
To: Pascal Hambourg; +Cc: Rémi Denis-Courmont, Linux Kernel Network Developers
In-Reply-To: <4E4C2178.1000809@plouf.fr.eu.org>
On 08/17/2011 04:15 PM, Pascal Hambourg wrote:
> Hello,
>
> Stephen Clark a écrit :
>
>> On 08/17/2011 01:17 PM, Rémi Denis-Courmont wrote:
>>
>>> Le mercredi 17 août 2011 20:03:18 Stephen Clark, vous avez écrit :
>>>
>>>
>>>> I have run into a situation where if I ping our HQ the response comes
>>>> back on a different
>>>> interface than what the request went out on. FreeBSD is happy and says
>>>> it got the response,
>>>> Linux is not and gives no indication it got a response.
>>>>
>>>> So is FreeBSD wrong or is Linux wrong?
>>>>
> Neither is right or wrong. It partly depends whether you want to enforce
> so-called "weak" or "strong" host model.
>
>
>>> Most distributions enable reverse path filtering by default.
>>> It can be disabled:
>>> # echo -n 0> /proc/sys/net/ipv4/conf/all/rp_filter
>>>
>>> But you should probably fix the configuration instead (e.g. /etc/sysctl.conf).
>>>
>>>
>> Sorry that didn't help either.
>>
> Since some kernel version the logic of this sysctl has changed from
> AND(all, $interface) to MAX(all, $interface). So you must set
> net/ipv4/conf/$interface/rp_filter to 0 too to disable it.
> Or set net/ipv4/conf/all/rp_filter to 2 to make it weaker.
>
>
I guess I don't really understand what reverse path filter stuff is all
about, much less making it weaker.
But using 2 made the pings responses be seen.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: [RFC PATCH] net: vlan: 802.1ad S-VLAN support
From: Ben Hutchings @ 2011-08-18 14:38 UTC (permalink / raw)
To: David Lamparter; +Cc: netdev, Patrick McHardy
In-Reply-To: <1310936105-3494206-1-git-send-email-equinox@diac24.net>
On Sun, 2011-07-17 at 22:55 +0200, David Lamparter wrote:
> this adds support for 802.1ad S-VLANs, which basically are regular VLANs
> with a different protocol field. also supported are the legacy QinQ
> 9100/9200/9300 ethertypes. as with the CFI bit for 802.1Q, the DEI bit
> is blissfully ignored.
>
> this patch modifies the 802.1Q code, but keeps the regular VLAN
> acceleration architecture unchanged. the S-VLAN code does not use that;
> I am not aware of any NIC implementing it for ethertypes other than
> 8100.
[...]
I've not heard of multiple-VLAN-tag-insertion, but any controller that
implements a generic 16-bit checksum should be able to do TX checksum
offload regardless of the number of tags present. So I think VLAN
devices should have their own vlan_features set to at least:
NETIF_F_HW_CSUM | NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HIGHDM
Some controllers that rely on header parsing for TX checksum offload can
also handle multiple VLAN tags; our current chips recognise up to 3 VLAN
tags with any of those Ethertypes. It would be good to have some way
for physical device drivers to advertise this feature so that nested
VLAN devices can take advantage of it. (I am definitely *not* proposing
vlan2_features, vlan3_features, which wouldn't even be sufficient to
represent Ethertype constraints.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: protect raw sockets
From: krbmit siso @ 2011-08-18 15:01 UTC (permalink / raw)
To: netdev, ipsec-tools-users, ipsec-tools-devel, ikev2-devel,
Timo Teräs
In-Reply-To: <CABjs8yWMgyyPHC1Nfgs2TZ1ixN7Khq0OimEhUhTs-Ux_9LAx5g@mail.gmail.com>
Hi All,
After adding the below code in net/ipv4/raw.c in function raw_send_hdrinc()
I am able to see packet sent using RAW_SOCKET getting protected .
Please let me know how can it be done better and provide it has a feature
, so that others can also use it if packet sent using RAW_SOCKET
needs to be protected.
/************** net/ipv4/raw.c *************/
struct flowi fl;
struct dst_entry *dst;
int res;
if (xfrm_decode_session(skb, &fl, AF_INET)<0){
printk("\n xfrm_decode_session FAILED \n");
XFRM_INC_STATS(net, LINUX_MIB_XFRMFWDHDRERROR);
return 0;
}
dst = skb_dst(skb);
printk("\n xfrm_lookup called \n");
res = xfrm_lookup(net, &dst, &fl, NULL, 0) == 0;
skb_dst_set(skb, dst);
err = NF_HOOK(PF_INET, NF_INET_LOCAL_OUT, skb, NULL, rt->u.dst.dev,
dst_output);
/*************************************************/
Thanks and Regards
Naveen
On Thu, Aug 18, 2011 at 1:58 PM, krbmit siso <krbmit@gmail.com> wrote:
> Hi Timo,
>
> Thanks for your reply .
> Yes i did explore this yesterday and i was successful in sending the IKE
> messages unprotected after using the below code only for UDP sockets.
>
> int setsockopt_bypass(int fd, int family)
> {
> struct sadb_x_policy policy;
> int level, optname;
>
> switch (family) {
> case AF_INET:
> level = IPPROTO_IP;
> optname = IP_IPSEC_POLICY;
> break;
> case AF_INET6:
> level = IPPROTO_IPV6;
> optname = IPV6_IPSEC_POLICY;
> break;
> default:
> return -1;
> }
>
> memset(&policy, 0, sizeof(policy));
> policy.sadb_x_policy_len = PFKEY_UNIT64(sizeof(policy));
> policy.sadb_x_policy_exttype = SADB_X_EXT_POLICY;
> policy.sadb_x_policy_type = IPSEC_POLICY_BYPASS;
> policy.sadb_x_policy_dir = IPSEC_DIR_INBOUND;
> if (setsockopt(fd, level, optname, &policy, sizeof(policy)) == -1) {
> return -1;
> }
> policy.sadb_x_policy_dir = IPSEC_DIR_OUTBOUND;
> if (setsockopt(fd, level, optname, &policy, sizeof(policy)) == -1) {
> return -1;
> }
> return 0;
> }
>
> But i did try the same on RAW socket by setting the policy has
> policy.sadb_x_policy_type = IPSEC_POLICY_ENTRUST|IPSEC_POLICY_IPSEC;
> But the packet is going unprotected .
> Please show some light on how to protect RAW packets if there is a Policy
> matching in the SPD saying it need to be protected.
> I have checked the posting there is no help on this isues , could
> you please give some options , if it is possible from Application.
>
>
> Thanks and Regards
> Naveen
>
> On Thu, Aug 18, 2011 at 1:45 PM, Naveen B N (nbn) <nbn@cisco.com> wrote:
>> Hi All,
>> Is there a way to enforce IPsec protection for packets sent from
>> application using RAW_SOCKET.
>>
>> My analysis is to add a code at the raw_sendmsg() & raw_v4_input() to
>> call xfrm_policy_check() ..
>> Is it a good method to proceed or is there a better and smart way to
>> achieve this .
>>
>> Hoping for some guide lines ..
>>
>> Thanks in advance ..
>>
>> Thanks and Regards
>> Naveen
>> --
>> 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
>>
>
^ permalink raw reply
* Re: [RFC] bridge: allow passing link-local multicast
From: Nick Carter @ 2011-08-18 15:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Ed Swierk, netdev, David Lamparter, bridge
In-Reply-To: <20110815150501.3a6cc432@nehalam.ftrdhcpuser.net>
On 15 August 2011 23:05, Stephen Hemminger <shemminger@vyatta.com> wrote:
> Several users have wanted to forward 802.1x EAP multicast
> packets through a bridge. And there has been a couple of
> attempts at allowing some form of this in the past.
>
> If a bridge does not have spanning tree turned on, then it should
> act like a pure hub and forward all traffic. This makes it fully
> transparent, and if there is another bridge using spanning tree
> the STP packets will still work for detecting loops in the network.
>
> If bridge has STP enabled, then the default behavior is to
> process all link-local multicasts locally. The expectation is
> that if 802.1x or other protocol using link-local multicasts
> that a service (or proxy) for that protocol will be used.
>
> Optionally, a sysctl value can be set to allow non STP packets
> to still be forwarded. I chose sysctl for this because it is
> where such modifications exist when doing IP or netfilter.
> There are other filtering/configuration options that are needed
> and this is a better way to enable them.
>
> Thanks to David Lamparter, and others for bringing this up.
> Users who need this facility should provide feedback, is this
> a usable solution?
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> Patch against net-next
>
> Documentation/networking/ip-sysctl.txt | 4 ++
> net/bridge/Makefile | 2 -
> net/bridge/br.c | 12 ++++++
> net/bridge/br_input.c | 30 ++++++++++++++++-
> net/bridge/br_private.h | 5 ++
> net/bridge/br_sysctl.c | 57 +++++++++++++++++++++++++++++++++
> 6 files changed, 107 insertions(+), 3 deletions(-)
>
> --- a/Documentation/networking/ip-sysctl.txt 2011-08-15 10:58:36.451532115 -0700
> +++ b/Documentation/networking/ip-sysctl.txt 2011-08-15 11:39:57.719438766 -0700
> @@ -1289,6 +1289,10 @@ bridge-nf-filter-pppoe-tagged - BOOLEAN
> 0 : disable this.
> Default: 1
>
> +bridge-forward-link-local - BOOLEAN
> + 1 : pass link-local multicasts through bridge in STP mode
> + 0 : disable this.
> + Default: 0
>
> proc/sys/net/sctp/* Variables:
>
> --- a/net/bridge/Makefile 2011-08-15 10:30:25.203595742 -0700
> +++ b/net/bridge/Makefile 2011-08-15 11:22:38.139477877 -0700
> @@ -9,7 +9,7 @@ bridge-y := br.o br_device.o br_fdb.o br
> br_stp_if.o br_stp_timer.o br_netlink.o
>
> bridge-$(CONFIG_SYSFS) += br_sysfs_if.o br_sysfs_br.o
> -
> +bridge-$(CONFIG_SYSCTL) += br_sysctl.o
> bridge-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o
>
> bridge-$(CONFIG_BRIDGE_IGMP_SNOOPING) += br_multicast.o
> --- a/net/bridge/br.c 2011-08-15 10:30:48.755594855 -0700
> +++ b/net/bridge/br.c 2011-08-15 10:33:07.215589647 -0700
> @@ -60,6 +60,12 @@ static int __init br_init(void)
> if (err)
> goto err_out4;
>
> +#ifdef CONFIG_SYSCTL
> + err = br_sysctl_init();
> + if (err)
> + goto err_out5;
> +#endif
> +
> brioctl_set(br_ioctl_deviceless_stub);
>
> #if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE)
> @@ -67,6 +73,9 @@ static int __init br_init(void)
> #endif
>
> return 0;
> +
> +err_out5:
> + br_netlink_fini();
> err_out4:
> unregister_netdevice_notifier(&br_device_notifier);
> err_out3:
> @@ -84,6 +93,9 @@ static void __exit br_deinit(void)
> {
> stp_proto_unregister(&br_stp_proto);
>
> +#ifdef CONFIG_SYSCTL
> + br_sysctl_fini();
> +#endif
> br_netlink_fini();
> unregister_netdevice_notifier(&br_device_notifier);
> brioctl_set(NULL);
> --- a/net/bridge/br_input.c 2011-08-15 10:40:21.435573311 -0700
> +++ b/net/bridge/br_input.c 2011-08-15 11:39:57.719438766 -0700
> @@ -16,11 +16,18 @@
> #include <linux/netdevice.h>
> #include <linux/etherdevice.h>
> #include <linux/netfilter_bridge.h>
> +#include <linux/llc.h>
> +#include <net/llc.h>
> +#include <net/llc_pdu.h>
> +
> #include "br_private.h"
>
> /* Bridge group multicast address 802.1d (pg 51). */
> const u8 br_group_address[ETH_ALEN] = { 0x01, 0x80, 0xc2, 0x00, 0x00, 0x00 };
>
> +/* Should link-local packets be forwarded (in STP mode) */
> +int br_forward_link_local;
> +
> /* Hook for brouter */
> br_should_route_hook_t __rcu *br_should_route_hook __read_mostly;
> EXPORT_SYMBOL(br_should_route_hook);
> @@ -138,6 +145,17 @@ static inline int is_link_local(const un
> return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | ((a[2] ^ b[2]) & m)) == 0;
> }
>
> +/* Identify Spanning Tree packets based on header */
Why can't we use the 802.1D specified STP group address to identify ?
The existing code uses that address.
I know you said on another thread that there are people using other addresses.
Who are these people ?
Are they following any standard ?
What address / address range are they using ?
Thanks,
Nick
> +static bool is_stp_bpdu(struct sk_buff *skb)
> +{
> + struct llc_pdu_un *pdu = llc_pdu_un_hdr(skb);
> +
> + return skb->protocol == htons(ETH_P_802_2) &&
> + pdu->ctrl_1 == LLC_PDU_TYPE_U &&
> + pdu->dsap == LLC_SAP_BSPAN &&
> + pdu->ssap == LLC_SAP_BSPAN;
> +}
> +
> /*
> * Return NULL if skb is handled
> * note: already called with rcu_read_lock
> @@ -166,8 +184,16 @@ rx_handler_result_t br_handle_frame(stru
> if (skb->protocol == htons(ETH_P_PAUSE))
> goto drop;
>
> - /* If STP is turned off, then forward */
> - if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0)
> + /* If STP is turned off, then in hub mode */
> + if (p->br->stp_enabled == BR_NO_STP)
> + goto forward;
> +
> + /*
> + * If STP is on
> + * then Always handle STP packets locally,
> + * other packets can be forwarded if sysctl is enabled.
> + */
> + if (!is_stp_bpdu(skb) && br_forward_link_local)
> goto forward;
>
> if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
> --- a/net/bridge/br_private.h 2011-08-15 10:38:35.587577293 -0700
> +++ b/net/bridge/br_private.h 2011-08-15 10:57:36.983534352 -0700
> @@ -284,6 +284,7 @@ struct br_input_skb_cb {
> pr_debug("%s: " format, (br)->dev->name, ##args)
>
> extern struct notifier_block br_device_notifier;
> +extern int br_forward_link_local;
> extern const u8 br_group_address[ETH_ALEN];
>
> /* called under bridge lock */
> @@ -546,6 +547,10 @@ extern int br_sysfs_renameif(struct net_
> extern int br_sysfs_addbr(struct net_device *dev);
> extern void br_sysfs_delbr(struct net_device *dev);
>
> +/* br_sysctl.c */
> +extern int br_sysctl_init(void);
> +extern void br_sysctl_fini(void);
> +
> #else
>
> #define br_sysfs_addif(p) (0)
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ b/net/bridge/br_sysctl.c 2011-08-15 11:41:00.819436393 -0700
> @@ -0,0 +1,57 @@
> +/*
> + * Sysctl settings for bridge
> + *
> + * Authors:
> + * Stephen Hemminger <shemminger@osdl.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <linux/ip.h>
> +#include <linux/netdevice.h>
> +#include <linux/skbuff.h>
> +#include <linux/if_arp.h>
> +#include <linux/if_ether.h>
> +#include <linux/if_vlan.h>
> +#include <linux/if_pppox.h>
> +#include <linux/sysctl.h>
> +
> +#include "br_private.h"
> +
> +static struct ctl_table bridge_table[] = {
> + {
> + .procname = "bridge-forward-link-local",
> + .data = &br_forward_link_local,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec
> + },
> +};
> +
> +static struct ctl_path bridge_ctl_path[] = {
> + { .procname = "net", },
> + { .procname = "bridge", },
> + { },
> +};
> +
> +static struct ctl_table_header *br_sysctl;
> +
> +int __init br_sysctl_init(void)
> +{
> + br_sysctl = register_sysctl_paths(bridge_ctl_path, bridge_table);
> + if (br_sysctl == NULL)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +void __exit br_sysctl_fini(void)
> +{
> + unregister_net_sysctl_table(br_sysctl);
> +}
>
^ permalink raw reply
* Re: [RFC] bridge: allow passing link-local multicast
From: Stephen Hemminger @ 2011-08-18 15:10 UTC (permalink / raw)
To: Nick Carter; +Cc: Ed Swierk, netdev, David Lamparter, bridge
In-Reply-To: <CAEJpZP0fOydMMbgquAud7dfwcO28BXAMzAwnMjSZO6TvEjxgpQ@mail.gmail.com>
On Thu, 18 Aug 2011 16:06:19 +0100
Nick Carter <ncarter100@gmail.com> wrote:
> Why can't we use the 802.1D specified STP group address to identify ?
> The existing code uses that address.
> I know you said on another thread that there are people using other addresses.
> Who are these people ?
> Are they following any standard ?
> What address / address range are they using ?
The group address can be reprogrammed, and it is settable on other
routing equipment. People do it to create spanning tree domains.
^ permalink raw reply
* Re: [Bug 41212] New: [regression] [3.1-git] ipoib causes kernel panic (NULL pointer dereference)
From: Roland Dreier @ 2011-08-18 15:50 UTC (permalink / raw)
To: Bernd Schubert; +Cc: Erez Shitrit, linux-rdma, netdev
In-Reply-To: <4E4A47BE.9090903@fastmail.fm>
Remember that kernels after the release of 3.0 but before 3.1-rc1 will
report their version as 3.0 (even though they may have lots of commits
that went in after the 3.0 release). Could that be the explanation?
On Tue, Aug 16, 2011 at 3:34 AM, Bernd Schubert
<bernd.schubert@fastmail.fm> wrote:
> Hello Erez,
>
> are you sure? Commit 69cce1d1404968f78b177a0314f5822d5afdbbfb is not in 3.0
> yet and I also don't see how 3.0 should fail there, as it tests immediately
> for "if (likely(skb_dst(skb)"
>
>
> Thanks,
> Bernd
>
> On 08/16/2011 10:06 AM, Erez Shitrit wrote:
>>
>> Hi,
>> it happened in 3.0 also, if you take the git tag v3.0-rc7 and below it
>> will work.
>>
>> Thanks, Erez
^ permalink raw reply
* Re: [RFC] bridge: allow passing link-local multicast
From: Nick Carter @ 2011-08-18 15:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Ed Swierk, netdev, David Lamparter, bridge
In-Reply-To: <20110818081019.4b9bb79e@nehalam.ftrdhcpuser.net>
On 18 August 2011 16:10, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Thu, 18 Aug 2011 16:06:19 +0100
> Nick Carter <ncarter100@gmail.com> wrote:
>
>> Why can't we use the 802.1D specified STP group address to identify ?
>> The existing code uses that address.
>> I know you said on another thread that there are people using other addresses.
>> Who are these people ?
>> Are they following any standard ?
>> What address / address range are they using ?
>
> The group address can be reprogrammed, and it is settable on other
> routing equipment. People do it to create spanning tree domains.
>
But before the new
+ if (!is_stp_bpdu(skb) && br_forward_link_local)
check, we have already checked
if (unlikely(is_link_local(dest))) {
So the frame must have a link local destination. If the reprogrammed
group address is outside of the link local range then the new code in
this patch will never be hit. If the reprogrammed group address is in
the link local range then i'd suggest my previous group_fwd_mask patch
is cleaner and more flexible.
Nick
^ permalink raw reply
* [patch net-2.6] vlan: reset headers on accel emulation path
From: Jiri Pirko @ 2011-08-18 16:35 UTC (permalink / raw)
To: netdev; +Cc: davem, gregkh, kaber, shemminger, eric.dumazet
It's after all necessary to do reset headers here. The reason is we
cannot depend that it gets reseted in __netif_receive_skb once skb is
reinjected. For incoming vlanids without vlan_dev, vlan_do_receive()
returns false with skb != NULL and __netif_reveive_skb continues, skb is
not reinjected.
This might be good material for 3.0-stable as well
Reported-by: Mike Auty <mike.auty@gmail.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
net/8021q/vlan_core.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 5f27f8e..f1f2f7b 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -167,6 +167,8 @@ struct sk_buff *vlan_untag(struct sk_buff *skb)
if (unlikely(!skb))
goto err_free;
+ skb_reset_network_header(skb);
+ skb_reset_transport_header(skb);
return skb;
err_free:
--
1.7.6
^ permalink raw reply related
* Re: [Bugme-new] [Bug 41152] New: kernel 3.0 and above fails to handle vlan id 0 (802.1p) packets properly without hardware acceleration
From: Jiri Pirko @ 2011-08-18 16:37 UTC (permalink / raw)
To: Mike Auty; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <4E4C4549.6020802@gmail.com>
Thu, Aug 18, 2011 at 12:48:41AM CEST, mike.auty@gmail.com wrote:
>On 17/08/11 11:59, Jiri Pirko wrote:
>>
>> I just obtained very similar card (8086:422b). Going to look at it right
>> away.
>>
>> One more thing. What do you use to generate vlan0 tagged packets? I'm
>> using pktgen with "vlan_id 0". Would you please try that it behaves the
>> same for you?
>>
>
>Sorry, I haven't been using pktgen. I've got an actual device (a
>Samsung android phone) which seems to tag all normal outbound packets
>with this type of vlan tag. I only discovered a month ago that I needed
>the 8021q module to be able to talk to it, and then suddenly it stopped
>working once I moved to the 3.0 kernel.
>
>I might not have made it clear, but the packets are received (in so much
>as the packet is definitely sent, and it's seen by tools such as
>wireshark), but no reply is ever sent. I've attached packet logs from
>the 3.0.1 kernel and the 2.6.39.3 kernel. Oddly the tagging only seems
>to be used on the first SYN,ACK packet, but again I don't know enough
>about the pipeline or what the Samsung kernel's doing to cause that.
>
>I hope that's of some help? I may be able to get systemtap support
>rolled into my kernel tomorrow at some point, but if not then it will
>have to wait until the weekend. I don't know if that will provide
>useful information for debugging this, but I am happy to run whatever
>tests I can to figure this out...
>
>Mike 5:)
Patch posted:
http://patchwork.ozlabs.org/patch/110535/
sorry I forgot to cc you Mike. Thanks a lot for report!
Jirka
^ permalink raw reply
* Re: [RFC] bridge: allow passing link-local multicast
From: Stephen Hemminger @ 2011-08-18 16:39 UTC (permalink / raw)
To: Nick Carter; +Cc: Ed Swierk, netdev, David Lamparter, bridge
In-Reply-To: <CAEJpZP2FGhPmTi0+eS+QRhj4y+aqfQHnEUrjmOOLHUay1SuAKg@mail.gmail.com>
On Thu, 18 Aug 2011 16:52:45 +0100
Nick Carter <ncarter100@gmail.com> wrote:
> On 18 August 2011 16:10, Stephen Hemminger <shemminger@vyatta.com> wrote:
> > On Thu, 18 Aug 2011 16:06:19 +0100
> > Nick Carter <ncarter100@gmail.com> wrote:
> >
> >> Why can't we use the 802.1D specified STP group address to identify ?
> >> The existing code uses that address.
> >> I know you said on another thread that there are people using other addresses.
> >> Who are these people ?
> >> Are they following any standard ?
> >> What address / address range are they using ?
> >
> > The group address can be reprogrammed, and it is settable on other
> > routing equipment. People do it to create spanning tree domains.
> >
> But before the new
> + if (!is_stp_bpdu(skb) && br_forward_link_local)
> check, we have already checked
> if (unlikely(is_link_local(dest))) {
> So the frame must have a link local destination. If the reprogrammed
> group address is outside of the link local range then the new code in
> this patch will never be hit. If the reprogrammed group address is in
> the link local range then i'd suggest my previous group_fwd_mask patch
> is cleaner and more flexible.
The problem is that the group_fwd_mask is specific to the address
not the protocol.
^ 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