* [PATCH net] net: eth: altera: Change access ports to mdio for all xMII applications
From: Vince Bridgers @ 2015-02-12 16:47 UTC (permalink / raw)
To: netdev, nios2-dev, linux-kernel; +Cc: vbridger, vbridger, kailng, dwesterg
Change use of Altera TSE's MDIO access from phy 0 registers to phy 1
registers. This allows support for GMII, MII, RGMII, and SGMII
designs where the external PHY is always accesible through
Altera TSE's MDIO phy 1 registers and Altera's PCS is accessible
through MDIO phy 0 registers for SGMII applications.
Signed-off-by: Vince Bridgers <vbridger@opensource.altera.com>
Tested-by: Kai Lin Ng <kailng@altera.com>
Tested-by: Dalon Westergreen <dwesterg@gmail.com>
---
drivers/net/ethernet/altera/altera_tse_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c b/drivers/net/ethernet/altera/altera_tse_main.c
index 996bdf1..a1ee261 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -105,11 +105,11 @@ static int altera_tse_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
/* set MDIO address */
csrwr32((mii_id & 0x1f), priv->mac_dev,
- tse_csroffs(mdio_phy0_addr));
+ tse_csroffs(mdio_phy1_addr));
/* get the data */
return csrrd32(priv->mac_dev,
- tse_csroffs(mdio_phy0) + regnum * 4) & 0xffff;
+ tse_csroffs(mdio_phy1) + regnum * 4) & 0xffff;
}
static int altera_tse_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
@@ -120,10 +120,10 @@ static int altera_tse_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
/* set MDIO address */
csrwr32((mii_id & 0x1f), priv->mac_dev,
- tse_csroffs(mdio_phy0_addr));
+ tse_csroffs(mdio_phy1_addr));
/* write the data */
- csrwr32(value, priv->mac_dev, tse_csroffs(mdio_phy0) + regnum * 4);
+ csrwr32(value, priv->mac_dev, tse_csroffs(mdio_phy1) + regnum * 4);
return 0;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] bridge: netfilter: Move sysctl-specific error code inside #ifdef
From: David Miller @ 2015-02-12 16:45 UTC (permalink / raw)
To: geert; +Cc: netdev, bridge, linux-kernel
In-Reply-To: <1423750647-30389-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Thu, 12 Feb 2015 15:17:27 +0100
> If CONFIG_SYSCTL=n:
>
> net/bridge/br_netfilter.c: In function ‘br_netfilter_init’:
> net/bridge/br_netfilter.c:996: warning: label ‘err1’ defined but not used
>
> Move the label and the code after it inside the existing #ifdef to get
> rid of the warning.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: compat: Ignore MSG_CMSG_COMPAT in compat_sys_{send,recv}msg
From: David Miller @ 2015-02-12 16:41 UTC (permalink / raw)
To: catalin.marinas; +Cc: netdev, linux-kernel, will.deacon, luto
In-Reply-To: <1423744087-21317-1-git-send-email-catalin.marinas@arm.com>
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Thu, 12 Feb 2015 12:28:07 +0000
> With commit a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg), the
> MSG_CMSG_COMPAT flag is blocked at the compat syscall entry points,
> changing the kernel compat behaviour from the one before the commit it
> was trying to fix (1be374a0518a, net: Block MSG_CMSG_COMPAT in
> send(m)msg and recv(m)msg).
>
> On 32-bit kernels (!CONFIG_COMPAT), MSG_CMSG_COMPAT is 0 and the native
> 32-bit sys_sendmsg() allows flag 0x80000000 to be set (it is ignored by
> the kernel). However, on a 64-bit kernel, the compat ABI is different
> with commit a7526eb5d06b.
>
> This patch changes the compat_sys_{send,recv}msg behaviour to the one
> prior to commit 1be374a0518a.
>
> The problem was found running 32-bit LTP (sendmsg01) binary on an arm64
> kernel. Arguably, LTP should not pass 0xffffffff as flags to sendmsg()
> but the general rule is not to break user ABI (even when the user
> behaviour is not entirely sane).
>
> Fixes: a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg)
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
I think this is a very poor LTP test.
Setting MSG_* bits that aren't supported by the protocol in any way
gives undefined semantics. You may get an error, it may be silently
ignored, etc.
I'm not applying this, sorry.
^ permalink raw reply
* Re: [PATCH] net: ip: Do not allow connection to remote port zero
From: Eric Dumazet @ 2015-02-12 16:21 UTC (permalink / raw)
To: Tom Marshall; +Cc: netdev
In-Reply-To: <20150212052428.GB10785@eden.sea.cyngn.com>
On Wed, 2015-02-11 at 21:24 -0800, Tom Marshall wrote:
> On Wed, Feb 11, 2015 at 08:06:14PM -0800, Eric Dumazet wrote:
> > On Wed, 2015-02-11 at 16:58 -0800, Tom Marshall wrote:
> > > Port zero is reserved according to IANA.
> > >
> > > Note UDP sendto is already disallowed if dport is zero.
> >
> > I have no idea why we should prevent such thing.
>
> * It is marked "reserved" by IANA.
>
> * UDP packets with dport=0 are already prevented from being sent.
>
> * Many routers will either drop the packets or, worse, send back a RST to a
> SYN destined for port 0.
Some networking/supervision applications might use this knowledge to
send TCP probes with dport=0, expecting to get an RST, knowing no
listener could possibly answer with a SYNACK.
If you take a look at traceroute -p TCP, you'll be shocked that it sends
malformed TCP packets. IANA never complained about this, so far.
^ permalink raw reply
* Re: [PATCH 2/2] dsa: mv88e6131: support fixed PHYs
From: Florian Fainelli @ 2015-02-12 16:13 UTC (permalink / raw)
To: Tobias Waldekranz; +Cc: netdev
In-Reply-To: <20150212141317.GB12318@gmail.com>
2015-02-12 6:13 GMT-08:00 Tobias Waldekranz <tobias@waldekranz.com>:
> Statically setup the PCS Control on the MAC to match the fixed PHY.
bcm_sf2 supports both fixed PHYs and regular PHYs, yet we do not need
to get access to the fixed PHY status from the adjust_link callback
because you could implement a separate fixed_link_update callback for
that purpose.
Did not that work for you?
>
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
> ---
> drivers/net/dsa/mv88e6131.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
> index eadb27c..d2b2fcf 100644
> --- a/drivers/net/dsa/mv88e6131.c
> +++ b/drivers/net/dsa/mv88e6131.c
> @@ -337,6 +337,48 @@ mv88e6131_phy_write(struct dsa_switch *ds,
> return mv88e6xxx_phy_write_ppu(ds, addr, regnum, val);
> }
>
> +static void mv88e6131_adjust_link(struct dsa_switch *ds, int port,
> + struct phy_device *phy)
> +{
> + u16 pcs_ctrl;
> +
> + /* PPU will configure MACs with physical PHYs */
> + if (!fixed_phy_get_status(phy))
> + return;
> +
> + pcs_ctrl = mv88e6xxx_reg_read(ds, REG_PORT(port), 1);
> +
> + /* clear all forced settings */
> + pcs_ctrl &= ~0xff;
> + pcs_ctrl |= BIT(2) | BIT(4) | BIT(6);
> +
> + switch (phy->speed) {
> + case 10:
> + break;
> + case 100:
> + pcs_ctrl |= BIT(0);
> + break;
> + case 1000:
> + pcs_ctrl |= BIT(1);
> + break;
> +
> + default:
> + netdev_err(ds->ports[port], "unsupported speed: %d\n", phy->speed);
> + }
> +
> + if (phy->duplex)
> + pcs_ctrl |= BIT(3);
> +
> + if (phy->link)
> + pcs_ctrl |= BIT(5);
> +
> + if (phy->pause)
> + pcs_ctrl |= BIT(7);
> +
> + mv88e6xxx_reg_write(ds, REG_PORT(port), 1, pcs_ctrl);
> + return;
> +}
> +
> static struct mv88e6xxx_hw_stat mv88e6131_hw_stats[] = {
> { "in_good_octets", 8, 0x00, },
> { "in_bad_octets", 4, 0x02, },
> @@ -398,6 +440,7 @@ struct dsa_switch_driver mv88e6131_switch_driver = {
> .set_addr = mv88e6xxx_set_addr_direct,
> .phy_read = mv88e6131_phy_read,
> .phy_write = mv88e6131_phy_write,
> + .adjust_link = mv88e6131_adjust_link,
> .poll_link = mv88e6xxx_poll_link,
> .get_strings = mv88e6131_get_strings,
> .get_ethtool_stats = mv88e6131_get_ethtool_stats,
> --
> 1.8.4.357.g8d83871.dirty
> --
> 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
--
Florian
^ permalink raw reply
* Re: [PATCH] net: ip: Do not allow connection to remote port zero
From: Tom Marshall @ 2015-02-12 15:34 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Eric Dumazet, netdev
In-Reply-To: <54DCB082.2040207@cogentembedded.com>
On Thu, Feb 12, 2015 at 04:54:10PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 2/12/2015 9:23 AM, Tom Marshall wrote:
>
> >>* UDP packets with dport=0 are already prevented from being sent.
>
> >FYI, I tried to trace where this code (disallowing udp packets with dport=0)
> >came from. It predates git history, and I don't have any way to access
> >anything prior.
>
> Tried https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/?
Thanks, I didn't know about that.
The logic predates that tree also. Which means prior to 2.5.0 or so.
^ permalink raw reply
* Re: [PATCH] ipv6: fix possible deadlock in ip6_fl_purge / ip6_fl_gc
From: David Miller @ 2015-02-12 15:13 UTC (permalink / raw)
To: jstancek; +Cc: netdev, linux-kernel
In-Reply-To: <a26e3a5267c2a8816655018c5d46adcf52e71948.1423659369.git.jstancek@redhat.com>
From: Jan Stancek <jstancek@redhat.com>
Date: Wed, 11 Feb 2015 14:06:23 +0100
> Use spin_lock_bh in ip6_fl_purge() to prevent following potentially
> deadlock scenario between ip6_fl_purge() and ip6_fl_gc() timer.
...
> Signed-off-by: Jan Stancek <jstancek@redhat.com>
Applied.
^ permalink raw reply
* [PATCH] bridge: netfilter: Move sysctl-specific error code inside #ifdef
From: Geert Uytterhoeven @ 2015-02-12 14:17 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller
Cc: bridge, netdev, linux-kernel, Geert Uytterhoeven
If CONFIG_SYSCTL=n:
net/bridge/br_netfilter.c: In function ‘br_netfilter_init’:
net/bridge/br_netfilter.c:996: warning: label ‘err1’ defined but not used
Move the label and the code after it inside the existing #ifdef to get
rid of the warning.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
net/bridge/br_netfilter.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 65728e0dc4ffd011..0ee453fad3de6521 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -987,15 +987,12 @@ static int __init br_netfilter_init(void)
if (brnf_sysctl_header == NULL) {
printk(KERN_WARNING
"br_netfilter: can't register to sysctl.\n");
- ret = -ENOMEM;
- goto err1;
+ nf_unregister_hooks(br_nf_ops, ARRAY_SIZE(br_nf_ops));
+ return -ENOMEM;
}
#endif
printk(KERN_NOTICE "Bridge firewalling registered\n");
return 0;
-err1:
- nf_unregister_hooks(br_nf_ops, ARRAY_SIZE(br_nf_ops));
- return ret;
}
static void __exit br_netfilter_fini(void)
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] dsa: mv88e6131: support fixed PHYs
From: Tobias Waldekranz @ 2015-02-12 14:13 UTC (permalink / raw)
To: netdev
Statically setup the PCS Control on the MAC to match the fixed PHY.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
drivers/net/dsa/mv88e6131.c | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index eadb27c..d2b2fcf 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -337,6 +337,48 @@ mv88e6131_phy_write(struct dsa_switch *ds,
return mv88e6xxx_phy_write_ppu(ds, addr, regnum, val);
}
+static void mv88e6131_adjust_link(struct dsa_switch *ds, int port,
+ struct phy_device *phy)
+{
+ u16 pcs_ctrl;
+
+ /* PPU will configure MACs with physical PHYs */
+ if (!fixed_phy_get_status(phy))
+ return;
+
+ pcs_ctrl = mv88e6xxx_reg_read(ds, REG_PORT(port), 1);
+
+ /* clear all forced settings */
+ pcs_ctrl &= ~0xff;
+ pcs_ctrl |= BIT(2) | BIT(4) | BIT(6);
+
+ switch (phy->speed) {
+ case 10:
+ break;
+ case 100:
+ pcs_ctrl |= BIT(0);
+ break;
+ case 1000:
+ pcs_ctrl |= BIT(1);
+ break;
+
+ default:
+ netdev_err(ds->ports[port], "unsupported speed: %d\n", phy->speed);
+ }
+
+ if (phy->duplex)
+ pcs_ctrl |= BIT(3);
+
+ if (phy->link)
+ pcs_ctrl |= BIT(5);
+
+ if (phy->pause)
+ pcs_ctrl |= BIT(7);
+
+ mv88e6xxx_reg_write(ds, REG_PORT(port), 1, pcs_ctrl);
+ return;
+}
+
static struct mv88e6xxx_hw_stat mv88e6131_hw_stats[] = {
{ "in_good_octets", 8, 0x00, },
{ "in_bad_octets", 4, 0x02, },
@@ -398,6 +440,7 @@ struct dsa_switch_driver mv88e6131_switch_driver = {
.set_addr = mv88e6xxx_set_addr_direct,
.phy_read = mv88e6131_phy_read,
.phy_write = mv88e6131_phy_write,
+ .adjust_link = mv88e6131_adjust_link,
.poll_link = mv88e6xxx_poll_link,
.get_strings = mv88e6131_get_strings,
.get_ethtool_stats = mv88e6131_get_ethtool_stats,
--
1.8.4.357.g8d83871.dirty
^ permalink raw reply related
* [PATCH 1/2] phylib: support reading the status of a fixed PHY
From: Tobias Waldekranz @ 2015-02-12 14:12 UTC (permalink / raw)
To: netdev
This makes it possible to check if a PHY is fixed or physical.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
drivers/net/phy/fixed_phy.c | 17 +++++++++++++++++
include/linux/phy_fixed.h | 9 +++++++++
2 files changed, 26 insertions(+)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index a08a3c7..5575345 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -156,6 +156,23 @@ static int fixed_mdio_write(struct mii_bus *bus, int phy_addr, int reg_num,
return 0;
}
+const struct fixed_phy_status *fixed_phy_get_status(struct phy_device *phydev)
+{
+ struct fixed_mdio_bus *fmb = &platform_fmb;
+ struct fixed_phy *fp;
+
+ if (!phydev || !phydev->bus || phydev->bus->priv != fmb)
+ return NULL;
+
+ list_for_each_entry(fp, &fmb->phys, node) {
+ if (fp->addr == phydev->addr)
+ return &fp->status;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL(fixed_phy_get_status);
+
/*
* If something weird is required to be done with link/speed,
* network driver is able to assign a function to implement this.
diff --git a/include/linux/phy_fixed.h b/include/linux/phy_fixed.h
index 7e75bfe..e783b8d 100644
--- a/include/linux/phy_fixed.h
+++ b/include/linux/phy_fixed.h
@@ -12,6 +12,9 @@ struct fixed_phy_status {
struct device_node;
#if IS_ENABLED(CONFIG_FIXED_PHY)
+extern const struct fixed_phy_status *fixed_phy_get_status(
+ struct phy_device *phydev);
+
extern int fixed_phy_add(unsigned int irq, int phy_id,
struct fixed_phy_status *status);
extern struct phy_device *fixed_phy_register(unsigned int irq,
@@ -22,6 +25,12 @@ extern int fixed_phy_set_link_update(struct phy_device *phydev,
int (*link_update)(struct net_device *,
struct fixed_phy_status *));
#else
+static inline const struct fixed_phy_status *fixed_phy_get_status(
+ struct phy_device *phydev)
+{
+ return NULL;
+};
+
static inline int fixed_phy_add(unsigned int irq, int phy_id,
struct fixed_phy_status *status)
{
--
1.8.4.357.g8d83871.dirty
^ permalink raw reply related
* Re: Ethernet: how to disable gigabit support
From: Florian Fainelli @ 2015-02-12 14:12 UTC (permalink / raw)
To: Pavel Machek; +Cc: kernel list, netdev
In-Reply-To: <20150206135706.GB25683@amd>
2015-02-06 5:57 GMT-08:00 Pavel Machek <pavel@ucw.cz>:
> On Thu 2015-02-05 14:44:55, Florian Fainelli wrote:
>> On 05/02/15 12:25, Pavel Machek wrote:
>> > Hi!
>> >
>> > This happened on more than one project: there's gigabit-capable chip,
>> > but the connector is not designed for gigabit speed.
>> >
>> > I'd like to have speed autonegotiation, but not offer gigabit (as it
>> > will not work).
>> >
>> > Is there way to do that without hacking the kernel? Should mii-tool do
>> > that?
>>
>> Since you use the PHY library, you should be able to do something like
>> this in your PHY driver prior to starting the PHY state machine:
>>
>> phydev->supported &= PHY_BASIC_FEATURES (effectively masking Gigabit
>> capability)
>
> Thanks, that did the trick.
> Pavel
> (But still it would be nice to have a generic way of doing this,
> using something like mii-tool.)
You can also force that by setting the "max-speed" property in the
Ethernet PHY node, the PHY library will populate the supported bitmask
accordingly and remove speeds which are not supposed to be supported.
I have to admit it has been a while since I used mii-tool, so the
ioctl() side on the PHY library might be off.
--
Florian
^ permalink raw reply
* Re: [PATCH] net: ip: Do not allow connection to remote port zero
From: Sergei Shtylyov @ 2015-02-12 13:54 UTC (permalink / raw)
To: Tom Marshall, Eric Dumazet; +Cc: netdev
In-Reply-To: <20150212062335.GA12626@eden.sea.cyngn.com>
Hello.
On 2/12/2015 9:23 AM, Tom Marshall wrote:
>> * UDP packets with dport=0 are already prevented from being sent.
> FYI, I tried to trace where this code (disallowing udp packets with dport=0)
> came from. It predates git history, and I don't have any way to access
> anything prior.
Tried https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured
From: Sergei Shtylyov @ 2015-02-12 13:52 UTC (permalink / raw)
To: Zhu Yanjun, netdev, mst, jasowang, viro, davem
In-Reply-To: <1423719323-4667-2-git-send-email-Yanjun.Zhu@windriver.com>
Hello.
On 2/12/2015 8:35 AM, Zhu Yanjun wrote:
> From: Zhu Yanjun <yanjun.zhu@windriver.com>
> The default speed of normal nic is 1000M while the default speed
> of tun is 10M. Now the default speed of tun is changed to 1000M.
> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
> The command "ethtool -s tun0 speed 10/100/1000" can configure the
> speed of tun dynamically.
> CC: Michael S. Tsirkin <mst@redhat.com>
> CC: Jason Wang <jasowang@redhat.com>
> CC: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@windriver.com>
> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
> ---
> drivers/net/tun.c | 36 +++++++++++++++++++++++++++++++++++-
> include/uapi/linux/if_tun.h | 5 +++++
> 2 files changed, 40 insertions(+), 1 deletion(-)
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 8c8dc16..64f4dcc 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
[...]
> @@ -2257,9 +2260,18 @@ static struct miscdevice tun_miscdev = {
>
> static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> {
> + struct tun_struct *tun = netdev_priv(dev);
> +
> + /*Get the speed of tun*/
Please add spaces after /* and before */.
[...]
> @@ -2287,6 +2299,27 @@ static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info
> }
> }
>
> +static int tun_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> +{
> + struct tun_struct *tun = netdev_priv(dev);
> + u32 speed = ethtool_cmd_speed(cmd);
> +
> + if (10 == speed) {
> + tun->flags &= ~TUN_CTRL_SPD_100;
> + tun->flags &= ~TUN_CTRL_SPD_1000;
Can't you clear both bits at once?
> + tun->flags |= TUN_CTRL_SPD_10;
> + } else if (100 == speed) {
> + tun->flags &= ~TUN_CTRL_SPD_10;
> + tun->flags &= ~TUN_CTRL_SPD_1000;
> + tun->flags |= TUN_CTRL_SPD_100;
> + } else {
> + tun->flags &= ~TUN_CTRL_SPD_10;
> + tun->flags &= ~TUN_CTRL_SPD_100;
> + tun->flags |= TUN_CTRL_SPD_1000;
> + }
This is asking to be a *switch* statement.
[...]
> diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> index 50ae243..78a09a7 100644
> --- a/include/uapi/linux/if_tun.h
> +++ b/include/uapi/linux/if_tun.h
> @@ -66,6 +66,11 @@
> #define IFF_PERSIST 0x0800
> #define IFF_NOFILTER 0x1000
>
> +/*add speed control, default 1000M*/
Same remark about the comment style as above.
[...]
WBR, Sergei
^ permalink raw reply
* Fw: [Bug 93121] New: fib_lookup failed to find blackhole or prohibit or unreachable routes
From: Stephen Hemminger @ 2015-02-12 13:45 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Thu, 12 Feb 2015 08:36:12 +0000
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "shemminger@linux-foundation.org" <shemminger@linux-foundation.org>
Subject: [Bug 93121] New: fib_lookup failed to find blackhole or prohibit or unreachable routes
https://bugzilla.kernel.org/show_bug.cgi?id=93121
Bug ID: 93121
Summary: fib_lookup failed to find blackhole or prohibit or
unreachable routes
Product: Networking
Version: 2.5
Kernel Version: since v3.6
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: shemminger@linux-foundation.org
Reporter: alexandergusarov@gmail.com
Regression: No
Trying functional of blackhole | prohibit | unreachable routes i have found
that kernel always generate ICMP Network Unreachable (type 3 code 0) packets as
reply to packets going to blackhole route.
It seems to after removing routing cache in kernel 3.6 fib_lookup() failed to
find something in FIB.
Trying functional on different versions of kernel show me that functional is
broken after kernel 3.5.
I tried:
Ubuntu 10.04 whith 2.6.32 kernel - OK
Ubuntu 10.04 whith 3.0.0 kernel - OK
Ubuntu 12.04 whith 3.2.0 kernel - OK
Ubuntu 12.04 whith 3.5.0 kernel - OK
Ubuntu 12.04 whith 3.8.0 kernel - ERROR
Ubuntu 14.04 whith 3.13.0 kernel - ERROR
Ubuntu 15.04 whith 3.18.0 kernel - ERROR (daily build)
Steps to reproduce:
1) Two linux machines whith static IP adresses
Alpha - 192.168.1.1/24
Beta - 192.168.1.2/24
2) on Beta add route to 192.168.128.0/17 and blackhole routes to subbets
$ ip route add 192.168.128.0/17 via 192.168.1.1
$ ip route add blackhole 192.168.128.0/19
$ ip route add prohibit 192.168.160.0/19
$ ip route add unreachable 192.168.192.0/19
3) on Alpha add route to 192.168.128.0/17
$ ip route add 192.168.128.0/17 via 192.168.1.2
4) on Alpha ping 192.168.128.1 (expected no reply)
$ ping 192.168.128.1
PING 192.168.128.1 (192.168.128.1) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Net Unreachable
From 192.168.1.1 icmp_seq=2 Destination Net Unreachable
...
5) on Alpha ping 192.168.160.1 (expected reply "Packet Filtred")
$ ping 192.168.160.1
PING 192.168.160.1 (192.168.160.1) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Net Unreachable
From 192.168.1.1 icmp_seq=2 Destination Net Unreachable
...
6) on Alpha ping 192.168.192.1 (expected reply "Host Unreachable")
$ ping 192.168.192.1
PING 192.168.192.1 (192.168.192.1) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Net Unreachable
From 192.168.1.1 icmp_seq=2 Destination Net Unreachable
...
I apologize for my bad English
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: Some question about 802.1Q VLAN
From: Stephen Hemminger @ 2015-02-12 13:40 UTC (permalink / raw)
To: 安理 李剑; +Cc: netdev
In-Reply-To: <79f6e3b1.10533.14b723e5dc4.Coremail.dovelijian@163.com>
On Tue, 10 Feb 2015 14:47:44 +0800 (CST)
安理 李剑 <dovelijian@163.com> wrote:
>
>
>
>
> HI…I am a Linux VLAN user. Now, I encounter some question about 802.1Q VLAN in my wireless AP. My Linux kernel version is 2.6.31.
>
> Plese see my setting:
> vconfig add eth0 10
> vconfig add ath0 10
> ifconfig eth0.10 up
> ifconfig ath0.10 up
> brctl addbr br0
> brctl addbr br1
> brctl addif br0 ath0
> brctl addif br0 eth0
> brctl addif br1 ath0.10
> brctl addif br1 eth0.10
> ifconfig br0 up
> ifconfig br1 up
>
> The eth0 and ath0 is real network card in my AP,and the ath0 is the wireless card.
>
> Question:
> Two station associate AP by wireless,the two station and AP use same VLAN setting like my describe.One station br0 Ip address is 192.168.1.10/24,br1 ip address is 192.168.2.10/24;other station br0 ip address is 192.169.1.11/24, br1 ip address is 192.168.2.12/24.The AP is used bridge the data from station.
> But now use station1 ping station2: ping 192.168.1.11,it is successed; ping 192.168.2.12,it is failed!!!
> I don’t know the reason about the fail situation ,I need some help.
> Thank you!
Wireless internally is point to point and does support true promiscious
mode. Typically AP's implement Ethernet level (L2) NAT to deal with this.
^ permalink raw reply
* Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured
From: Stephen Hemminger @ 2015-02-12 12:55 UTC (permalink / raw)
To: Zhu Yanjun; +Cc: netdev, mst, jasowang, viro, davem
In-Reply-To: <1423719323-4667-2-git-send-email-Yanjun.Zhu@windriver.com>
On Thu, 12 Feb 2015 13:35:23 +0800
Zhu Yanjun <Yanjun.Zhu@windriver.com> wrote:
> From: Zhu Yanjun <yanjun.zhu@windriver.com>
>
> The default speed of normal nic is 1000M while the default speed
> of tun is 10M. Now the default speed of tun is changed to 1000M.
> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
> The command "ethtool -s tun0 speed 10/100/1000" can configure the
> speed of tun dynamically.
>
> CC: Michael S. Tsirkin <mst@redhat.com>
> CC: Jason Wang <jasowang@redhat.com>
> CC: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@windriver.com>
> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Why limit to 10/100/1000 speed?
Ethtool speed can be any value
>
^ permalink raw reply
* [PATCH] net: compat: Ignore MSG_CMSG_COMPAT in compat_sys_{send,recv}msg
From: Catalin Marinas @ 2015-02-12 12:28 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Will Deacon, Andy Lutomirski, David S. Miller
With commit a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg), the
MSG_CMSG_COMPAT flag is blocked at the compat syscall entry points,
changing the kernel compat behaviour from the one before the commit it
was trying to fix (1be374a0518a, net: Block MSG_CMSG_COMPAT in
send(m)msg and recv(m)msg).
On 32-bit kernels (!CONFIG_COMPAT), MSG_CMSG_COMPAT is 0 and the native
32-bit sys_sendmsg() allows flag 0x80000000 to be set (it is ignored by
the kernel). However, on a 64-bit kernel, the compat ABI is different
with commit a7526eb5d06b.
This patch changes the compat_sys_{send,recv}msg behaviour to the one
prior to commit 1be374a0518a.
The problem was found running 32-bit LTP (sendmsg01) binary on an arm64
kernel. Arguably, LTP should not pass 0xffffffff as flags to sendmsg()
but the general rule is not to break user ABI (even when the user
behaviour is not entirely sane).
Fixes: a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg)
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
net/compat.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/net/compat.c b/net/compat.c
index 3236b4167a32..94d3d5e97883 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -711,24 +711,18 @@ static unsigned char nas[21] = {
COMPAT_SYSCALL_DEFINE3(sendmsg, int, fd, struct compat_msghdr __user *, msg, unsigned int, flags)
{
- if (flags & MSG_CMSG_COMPAT)
- return -EINVAL;
return __sys_sendmsg(fd, (struct user_msghdr __user *)msg, flags | MSG_CMSG_COMPAT);
}
COMPAT_SYSCALL_DEFINE4(sendmmsg, int, fd, struct compat_mmsghdr __user *, mmsg,
unsigned int, vlen, unsigned int, flags)
{
- if (flags & MSG_CMSG_COMPAT)
- return -EINVAL;
return __sys_sendmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT);
}
COMPAT_SYSCALL_DEFINE3(recvmsg, int, fd, struct compat_msghdr __user *, msg, unsigned int, flags)
{
- if (flags & MSG_CMSG_COMPAT)
- return -EINVAL;
return __sys_recvmsg(fd, (struct user_msghdr __user *)msg, flags | MSG_CMSG_COMPAT);
}
@@ -751,9 +745,6 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct compat_mmsghdr __user *, mmsg,
int datagrams;
struct timespec ktspec;
- if (flags & MSG_CMSG_COMPAT)
- return -EINVAL;
-
if (timeout == NULL)
return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT, NULL);
^ permalink raw reply related
* Re: bride: IPv6 multicast snooping enhancements
From: Vasily Averin @ 2015-02-12 12:01 UTC (permalink / raw)
To: Linus Lüssing
Cc: netdev, bridge, Stephen Hemminger, David S. Miller, linux-kernel,
Herbert Xu, Cong Wang
In-Reply-To: <20150212114117.GC3665@odroid>
On 12.02.2015 14:41, Linus Lüssing wrote:
> On Tue, Feb 10, 2015 at 04:59:09PM +0300, Vasily Averin wrote:
>> I'm trying to fix ICMPv6 processing broken in OpenVZ after rebase to last RHEL6u6 kernel.
>> After some unclear manipulation bridge begins to forward icmp6 NS (fe02::1) into wrong port,
>> and at present I do not found the reason of this failure.
>
> fe02::1 seems uncommon for ICMPv6 NS messages. Would you mind
> making some dumps for ~10 minutes with tcpdump on all bridge ports
> and the bridge interface itself with a filter "icmp6" and uploading the
> result somewhere?
>
> Also provide a dump from "bridge mdb show dev $bridge" please (if
> possible - not sure whether that's available on the ancient 2.6.32
> kernel as used on RHEL6u6).
Thank you, "bridge mdb show" helps me to find an external router.
Therefore bridge forwarded all locally generated multicasts to external port.
Then forwarded messages was lost or was filtered or
just incorrectly processed, but in any case they never returned back.
So as far as I understand bridge itself works correctly,
it isn't responsible for external troubles.
Thank you,
Vasily Averin
^ permalink raw reply
* Re: bride: IPv6 multicast snooping enhancements
From: Linus Lüssing @ 2015-02-12 11:41 UTC (permalink / raw)
To: Vasily Averin
Cc: netdev, bridge, Stephen Hemminger, David S. Miller, linux-kernel,
Herbert Xu, Cong Wang
In-Reply-To: <54DA0EAD.60002@parallels.com>
On Tue, Feb 10, 2015 at 04:59:09PM +0300, Vasily Averin wrote:
> I'm trying to fix ICMPv6 processing broken in OpenVZ after rebase to last RHEL6u6 kernel.
> After some unclear manipulation bridge begins to forward icmp6 NS (fe02::1) into wrong port,
> and at present I do not found the reason of this failure.
fe02::1 seems uncommon for ICMPv6 NS messages. Would you mind
making some dumps for ~10 minutes with tcpdump on all bridge ports
and the bridge interface itself with a filter "icmp6" and uploading the
result somewhere?
Also provide a dump from "bridge mdb show dev $bridge" please (if
possible - not sure whether that's available on the ancient 2.6.32
kernel as used on RHEL6u6).
Cheers, Linus
^ permalink raw reply
* Re: [PATCH net-next 1/3] r8152: separate USB_RX_EARLY_AGG
From: Sergei Shtylyov @ 2015-02-12 11:37 UTC (permalink / raw)
To: Hayes Wang, netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2EE92DB@RTITMBSV03.realtek.com.tw>
Hello.
On 2/12/2015 5:36 AM, Hayes Wang wrote:
> [...]
>>> + ocp_data = tp->coalesce / 8;
>> Why not do it in the initializer?
> This is for patch #3. The patch #3 would use this function.
The new function is already called in this patch.
> The unit of the relative setting from the ethtool is 1 us.
> However, the unit for the hw is 8 us. Therefore, I save the
> value with the unit of 1 us, and transfer it to the unit of
> the hw when setting.
You're replying to the question I didn't ask. I was just suggesting:
u32 ocp_data = tp->coalesce / 8;
>>> + ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_TIMEOUT, ocp_data);
... if you don't want to pass 'tp->coalesce / 8' directly here.
>>> +}
>>> +
>>> +static void r8153_set_rx_early_size(struct r8152 *tp)
>>> +{
>>> + struct net_device *dev = tp->netdev;
>> Not sure you actually need this variable.
> If I replace dev->mtu with tp->netdev->mtu, the line would
> more than 80 characters. This is used to avoid it. Should
> I remove it?
OK, you can keep it.
>>> + u32 ocp_data;
>>> +
>>> + ocp_data = (agg_buf_sz - dev->mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
>> Why not in initializer?
> This is for patch #2. The patch #2 would use this function.
The new function is again used in this patch already.
> It has to be re-calculated when the mtu is changed, or the
> function is called when the linking status changes to ON.
You're again replying to the question I didn't ask. I was just suggesting:
u32 ocp_data = (agg_buf_sz - dev->mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
>>> + ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data);
... if you don't want to pass that expression directly here.
[...]
>>> @@ -3911,6 +3907,13 @@ static int rtl8152_probe(struct
>>> usb_interface *intf,
>>> tp->mii.reg_num_mask = 0x1f;
>>> tp->mii.phy_id = R8152_PHY_ID;
>>>
>>> + if (udev->speed == USB_SPEED_SUPER)
>>> + tp->coalesce = COALESCE_SUPER;
>>> + else if (udev->speed == USB_SPEED_HIGH)
>>> + tp->coalesce = COALESCE_HIGH;
>>> + else
>>> + tp->coalesce = COALESCE_SLOW;
>> This is asking to be a *switch* statement.
> Excuse me. I don't understand what you mean.
switch (udev->speed) {
case USB_SPEED_SUPER:
tp->coalesce = COALESCE_SUPER;
break;
case USB_SPEED_HIGH:
tp->coalesce = COALESCE_HIGH;
break;
default:
tp->coalesce = COALESCE_SLOW;
}
> The usb speed is determined when the device is plugged on
> the usb host controller or usb hub. The usb speed wouldn't
> chage unless you unplug the device and plug it to another
> port with different usb speed. Therefore, I provide different
> default values for different usb speed.
I didn't ask for explanations here either. :-)
> Best Regards,
> Hayes
WBR, Sergei
^ permalink raw reply
* Re: xt_recent broken in kernel 3.19.0 + PATCH
From: Chris Vine @ 2015-02-12 11:11 UTC (permalink / raw)
To: Florian Westphal
Cc: Cong Wang, Linux Kernel Mailing List, netfilter-devel,
Linux Kernel Network Developers
In-Reply-To: <20150212105417.0379fed8@bother.homenet>
On Thu, 12 Feb 2015 10:54:17 +0000
Chris Vine <chris@cvine.freeserve.co.uk> wrote:
[snip]
> On further testing I see that that patch only solves the problem if
> SSH_TRIES is set to a power of two boundary. You still get an error
> loading the rule if it is anything else. I think there is something
> wrong with the nstamp_mask heuristic which is used here.
I now find that that is not right either. I had to rmmod xt_recent to
get it to drop its previous setting. With that done, the patch does
indeed seem to work for all values of SSH_TRIES.
Chris
^ permalink raw reply
* Re: xt_recent broken in kernel 3.19.0 + PATCH
From: Chris Vine @ 2015-02-12 10:54 UTC (permalink / raw)
To: Florian Westphal
Cc: Cong Wang, Linux Kernel Mailing List, netfilter-devel,
Linux Kernel Network Developers
In-Reply-To: <20150212102616.786da70c@bother.homenet>
On Thu, 12 Feb 2015 10:26:16 +0000
Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> On Thu, 12 Feb 2015 09:35:33 +0100
> Florian Westphal <fw@strlen.de> wrote:
> > Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > > (Cc'ing netdev and netfilter-devel lists)
> >
> > Thanks for forwarding.
> >
> > > > Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> > > >> iptables -D SSH_CHAIN -m conntrack --ctstate NEW \
> > > >> -m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount
> > > >> $SSH_TRIES -j DROP
> > > > --- linux-3.19.0/net/netfilter/xt_recent.c~ 2015-02-10
> > > > 09:18:44.657376355 +0000 +++
> > > > linux-3.19.0/net/netfilter/xt_recent.c 2015-02-11
> > > > 17:58:33.311608835 +0000 @@ -378,7 +378,7 @@
> > > > mutex_lock(&recent_mutex); t = recent_table_lookup(recent_net,
> > > > info->name); if (t != NULL) {
> > > > - if (info->hit_count > t->nstamps_max_mask) {
> > > > + if (info->hit_count > t->nstamps_max_mask + 1) {
> >
> > Looks good. Chris, could you formally submit this patch to
> > netfilter-devel@vger.kernel.org?
> >
> > Thanks!
>
> Done.
On further testing I see that that patch only solves the problem if
SSH_TRIES is set to a power of two boundary. You still get an error
loading the rule if it is anything else. I think there is something
wrong with the nstamp_mask heuristic which is used here.
Chris
^ permalink raw reply
* Re: xt_recent broken in kernel 3.19.0 + PATCH
From: Chris Vine @ 2015-02-12 10:26 UTC (permalink / raw)
To: Florian Westphal
Cc: Cong Wang, Linux Kernel Mailing List, netfilter-devel,
Linux Kernel Network Developers
In-Reply-To: <20150212083533.GC22887@breakpoint.cc>
On Thu, 12 Feb 2015 09:35:33 +0100
Florian Westphal <fw@strlen.de> wrote:
> Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > (Cc'ing netdev and netfilter-devel lists)
>
> Thanks for forwarding.
>
> > > Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> > >> iptables -D SSH_CHAIN -m conntrack --ctstate NEW \
> > >> -m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount
> > >> $SSH_TRIES -j DROP
> > > --- linux-3.19.0/net/netfilter/xt_recent.c~ 2015-02-10
> > > 09:18:44.657376355 +0000 +++
> > > linux-3.19.0/net/netfilter/xt_recent.c 2015-02-11
> > > 17:58:33.311608835 +0000 @@ -378,7 +378,7 @@
> > > mutex_lock(&recent_mutex); t = recent_table_lookup(recent_net,
> > > info->name); if (t != NULL) {
> > > - if (info->hit_count > t->nstamps_max_mask) {
> > > + if (info->hit_count > t->nstamps_max_mask + 1) {
>
> Looks good. Chris, could you formally submit this patch to
> netfilter-devel@vger.kernel.org?
>
> Thanks!
Done.
Chris
^ permalink raw reply
* Re: [PATCH] iwl4965: Enable checking of format strings
From: Rasmus Villemoes @ 2015-02-12 10:20 UTC (permalink / raw)
To: Rustad, Mark D
Cc: Stanislaw Gruszka, Kalle Valo, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <60178C37-F104-430E-92EB-B6DDFAEB2F99@intel.com>
On Thu, Feb 12 2015, "Rustad, Mark D" <mark.d.rustad@intel.com> wrote:
> On Feb 11, 2015, at 2:51 PM, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
>
>> Since these fmt_* variables are just const char*, and not const
>> char[], gcc (and smatch) doesn't to type checking of the arguments to
>> the printf functions. Since the linker knows perfectly well to merge
>> identical string constants, there's no point in having three static
>> pointers waste memory and give an extra level of indirection.
>>
>> This removes over 100 "non-constant format argument" warnings from
>> smatch, accounting for about 20% of all such warnings in an
>> allmodconfig.
>>
>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>> ---
>> drivers/net/wireless/iwlegacy/4965-debug.c | 7 +++----
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/iwlegacy/4965-debug.c b/drivers/net/wireless/iwlegacy/4965-debug.c
>> index e0597bfdddb8..18855325cc1c 100644
>> --- a/drivers/net/wireless/iwlegacy/4965-debug.c
>> +++ b/drivers/net/wireless/iwlegacy/4965-debug.c
>> @@ -28,10 +28,9 @@
>> #include "common.h"
>> #include "4965.h"
>>
>> -static const char *fmt_value = " %-30s %10u\n";
>> -static const char *fmt_table = " %-30s %10u %10u %10u %10u\n";
>> -static const char *fmt_header =
>> - "%-32s current cumulative delta max\n";
>
> Why not change these to:
> static const char fmt_value[] = " %-30s %10u\n";
> static const char fmt_table[] = " %-30s %10u %10u %10u %10u\n";
> static const char fmt_header[] =
> "%-32s current cumulative delta max\n";
>
> I think that is better than the macros and avoids the extra pointers that I agree are useless.
Rather weak arguments, but I have three of them :-)
(1) If I'm reading some code and spot a non-constant format argument, I
sometimes track back to see how e.g. fmt_value is defined. If I then see
it's a macro, I immediately think "ok, the compiler is doing
type-checking". If it is a const char[], I have to remember that gcc
also does it in that case (as opposed to for example const char*const).
(2) The names of these variables themselves may end up wasting a few
bytes in the image.
(3) gcc/the linker doesn't merge identical const char[] arrays across
translation units. It also doesn't consider their tails for merging with
string literals. So although these specific strings are unlikely to
appear elsewhere, a string such as "%10u\n" or "max\n" couldn't be
merged with one of the above.
Rasmus
^ permalink raw reply
* RE: [PATCH next v3 3/6] bonding: Implement port churn-machine (AD standard 43.4.17).
From: David Laight @ 2015-02-12 9:58 UTC (permalink / raw)
To: 'Mahesh Bandewar', Jay Vosburgh, Andy Gospodarek,
Veaceslav Falico, Nikolay Aleksandrov, David Miller
Cc: Maciej Zenczykowski, netdev, Eric Dumazet
In-Reply-To: <1423715066-9345-1-git-send-email-maheshb@google.com>
From: Bandewar
> The Chrun Detection machines detect the situation where a port is operable,
^^^^^ spelling
> but the Actor and Partner have not attached the link to an Aggregator and
> brought the link into operation within a bound time period. Under normal
> operation of the LACP, aggrement between Actor and Partner should be reached
> very rapidly. Continued failure to reach aggrement can be symptomatic of
> device failure.
...
^ 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