* [net-next v2 6/8] ixgbe: add syfs interface for to export read only driver information
From: Jeff Kirsher @ 2012-05-01 8:51 UTC (permalink / raw)
To: davem; +Cc: Don Skidmore, netdev, gospo, sassmann, bhutchings, Jeff Kirsher
In-Reply-To: <1335862269-28914-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Don Skidmore <donald.c.skidmore@intel.com>
This patch exports non-thermal (which was done via hwmon in an earlier
patch) data to sysfs which isn't readily available elsewhere. All of the
fields are read only as this interface is to only export driver data.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sysfs.c | 322 +++++++++++++++++++++++-
1 files changed, 317 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sysfs.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sysfs.c
index aa41fb7..6601986 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sysfs.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sysfs.c
@@ -41,6 +41,310 @@
* This file provides a sysfs interface to export information from the
* driver. The information presented is READ-ONLY.
*/
+
+static struct net_device *ixgbe_get_netdev(struct kobject *kobj)
+{
+ struct net_device *netdev;
+ struct kobject *parent = kobj->parent;
+ struct device *device_info_kobj;
+
+ if (kobj == NULL)
+ return NULL;
+
+ device_info_kobj = container_of(parent, struct device, kobj);
+ if (device_info_kobj == NULL)
+ return NULL;
+
+ netdev = container_of(device_info_kobj, struct net_device, dev);
+ return netdev;
+}
+
+static struct ixgbe_adapter *ixgbe_get_adapter(struct kobject *kobj)
+{
+ struct ixgbe_adapter *adapter;
+ struct net_device *netdev = ixgbe_get_netdev(kobj);
+
+ if (netdev == NULL)
+ return NULL;
+
+ adapter = netdev_priv(netdev);
+ return adapter;
+}
+
+static ssize_t ixgbe_rxupacks(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct ixgbe_hw *hw;
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ hw = &adapter->hw;
+ if (hw == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no hw data\n");
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", IXGBE_READ_REG(hw, IXGBE_TPR));
+}
+
+static ssize_t ixgbe_rxmpacks(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct ixgbe_hw *hw;
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ hw = &adapter->hw;
+ if (hw == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no hw data\n");
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", IXGBE_READ_REG(hw, IXGBE_MPRC));
+}
+
+static ssize_t ixgbe_rxbpacks(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct ixgbe_hw *hw;
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ hw = &adapter->hw;
+ if (hw == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no hw data\n");
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", IXGBE_READ_REG(hw, IXGBE_BPRC));
+}
+
+static ssize_t ixgbe_txupacks(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct ixgbe_hw *hw;
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ hw = &adapter->hw;
+ if (hw == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no hw data\n");
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", IXGBE_READ_REG(hw, IXGBE_TPT));
+}
+
+static ssize_t ixgbe_txmpacks(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct ixgbe_hw *hw;
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ hw = &adapter->hw;
+ if (hw == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no hw data\n");
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", IXGBE_READ_REG(hw, IXGBE_MPTC));
+}
+
+static ssize_t ixgbe_txbpacks(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct ixgbe_hw *hw;
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ hw = &adapter->hw;
+ if (hw == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no hw data\n");
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", IXGBE_READ_REG(hw, IXGBE_BPTC));
+}
+
+static ssize_t ixgbe_maclla1(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct ixgbe_hw *hw;
+ u16 eeprom_buff[6];
+ int first_word = 0x37;
+ int word_count = 6;
+ int rc;
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ hw = &adapter->hw;
+ if (hw == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no hw data\n");
+
+ rc = hw->eeprom.ops.read_buffer(hw, first_word, word_count,
+ eeprom_buff);
+ if (rc)
+ return snprintf(buf, PAGE_SIZE, "error: reading buffer\n");
+
+ switch (hw->bus.func) {
+ case 0:
+ return snprintf(buf, PAGE_SIZE, "0x%04X%04X%04X\n",
+ eeprom_buff[0],
+ eeprom_buff[1],
+ eeprom_buff[2]);
+ case 1:
+ return snprintf(buf, PAGE_SIZE, "0x%04X%04X%04X\n",
+ eeprom_buff[3],
+ eeprom_buff[4],
+ eeprom_buff[5]);
+ }
+
+ return snprintf(buf, PAGE_SIZE, "unexpected port %d\n", hw->bus.func);
+}
+
+static ssize_t ixgbe_txdscqsz(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", adapter->tx_ring[0]->count);
+}
+
+static ssize_t ixgbe_rxdscqsz(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", adapter->rx_ring[0]->count);
+}
+
+static ssize_t ixgbe_rxqavg(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ int index;
+ int diff = 0;
+ u16 ntc;
+ u16 ntu;
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ for (index = 0; index < adapter->num_rx_queues; index++) {
+ ntc = adapter->rx_ring[index]->next_to_clean;
+ ntu = adapter->rx_ring[index]->next_to_use;
+
+ if (ntc >= ntu)
+ diff += (ntc - ntu);
+ else
+ diff += (adapter->rx_ring[index]->count - ntu + ntc);
+ }
+
+ if (adapter->num_rx_queues <= 0)
+ return snprintf(buf, PAGE_SIZE,
+ "can't calculate, number of queues %d\n",
+ adapter->num_rx_queues);
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", diff/adapter->num_rx_queues);
+}
+
+static ssize_t ixgbe_txqavg(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ int index;
+ int diff = 0;
+ u16 ntc;
+ u16 ntu;
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ for (index = 0; index < adapter->num_tx_queues; index++) {
+ ntc = adapter->tx_ring[index]->next_to_clean;
+ ntu = adapter->tx_ring[index]->next_to_use;
+
+ if (ntc >= ntu)
+ diff += (ntc - ntu);
+ else
+ diff += (adapter->tx_ring[index]->count - ntu + ntc);
+ }
+
+ if (adapter->num_tx_queues <= 0)
+ return snprintf(buf, PAGE_SIZE,
+ "can't calculate, number of queues %d\n",
+ adapter->num_tx_queues);
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", diff/adapter->num_tx_queues);
+}
+
+static ssize_t ixgbe_funcnbr(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct ixgbe_adapter *adapter = ixgbe_get_adapter(kobj);
+
+ if (adapter == NULL)
+ return snprintf(buf, PAGE_SIZE, "error: no adapter\n");
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", adapter->num_vfs);
+}
+
+/* Initialize the attributes */
+static struct kobj_attribute ixgbe_sysfs_rxupacks_attr =
+ __ATTR(rxupacks, 0444, ixgbe_rxupacks, NULL);
+static struct kobj_attribute ixgbe_sysfs_rxmpacks_attr =
+ __ATTR(rxmpacks, 0444, ixgbe_rxmpacks, NULL);
+static struct kobj_attribute ixgbe_sysfs_rxbpacks_attr =
+ __ATTR(rxbpacks, 0444, ixgbe_rxbpacks, NULL);
+static struct kobj_attribute ixgbe_sysfs_txupacks_attr =
+ __ATTR(txupacks, 0444, ixgbe_txupacks, NULL);
+static struct kobj_attribute ixgbe_sysfs_txmpacks_attr =
+ __ATTR(txmpacks, 0444, ixgbe_txmpacks, NULL);
+static struct kobj_attribute ixgbe_sysfs_txbpacks_attr =
+ __ATTR(txbpacks, 0444, ixgbe_txbpacks, NULL);
+static struct kobj_attribute ixgbe_sysfs_maclla1_attr =
+ __ATTR(maclla1, 0444, ixgbe_maclla1, NULL);
+static struct kobj_attribute ixgbe_sysfs_txdscqsz_attr =
+ __ATTR(txdscqsz, 0444, ixgbe_txdscqsz, NULL);
+static struct kobj_attribute ixgbe_sysfs_rxdscqsz_attr =
+ __ATTR(rxdscqsz, 0444, ixgbe_rxdscqsz, NULL);
+static struct kobj_attribute ixgbe_sysfs_txqavg_attr =
+ __ATTR(txqavg, 0444, ixgbe_txqavg, NULL);
+static struct kobj_attribute ixgbe_sysfs_rxqavg_attr =
+ __ATTR(rxqavg, 0444, ixgbe_rxqavg, NULL);
+static struct kobj_attribute ixgbe_sysfs_funcnbr_attr =
+ __ATTR(funcnbr, 0444, ixgbe_funcnbr, NULL);
+
+static struct attribute *attrs[] = {
+ &ixgbe_sysfs_rxupacks_attr.attr,
+ &ixgbe_sysfs_rxmpacks_attr.attr,
+ &ixgbe_sysfs_rxbpacks_attr.attr,
+ &ixgbe_sysfs_txupacks_attr.attr,
+ &ixgbe_sysfs_txmpacks_attr.attr,
+ &ixgbe_sysfs_txbpacks_attr.attr,
+ &ixgbe_sysfs_maclla1_attr.attr,
+ &ixgbe_sysfs_txdscqsz_attr.attr,
+ &ixgbe_sysfs_rxdscqsz_attr.attr,
+ &ixgbe_sysfs_txqavg_attr.attr,
+ &ixgbe_sysfs_rxqavg_attr.attr,
+ &ixgbe_sysfs_funcnbr_attr.attr,
+ NULL
+};
+
+/* add attributes to a group */
+static struct attribute_group attr_group = {
+ .attrs = attrs,
+};
+
#ifdef CONFIG_IXGBE_HWMON
/* hwmon callback functions */
@@ -185,8 +489,11 @@ static void ixgbe_sysfs_del_adapter(struct ixgbe_adapter *adapter)
hwmon_device_unregister(adapter->ixgbe_hwmon_buff.device);
#endif /* CONFIG_IXGBE_HWMON */
- if (adapter->info_kobj != NULL)
+ if (adapter->info_kobj != NULL) {
+ sysfs_remove_group(adapter->info_kobj, &attr_group);
kobject_put(adapter->info_kobj);
+ adapter->info_kobj = NULL;
+ }
}
/* called from ixgbe_main.c */
@@ -213,17 +520,22 @@ int ixgbe_sysfs_init(struct ixgbe_adapter *adapter)
goto err;
}
+ rc = sysfs_create_group(adapter->info_kobj, &attr_group);
+ if (rc)
+ goto err;
+
#ifdef CONFIG_IXGBE_HWMON
/* If this method isn't defined we don't support thermals */
if (adapter->hw.mac.ops.init_thermal_sensor_thresh == NULL) {
- rc = -EPERM;
- goto err;
+ goto exit;
}
/* Don't create thermal hwmon interface if no sensors present */
rc = adapter->hw.mac.ops.init_thermal_sensor_thresh(&adapter->hw);
- if (rc)
- goto err;
+ if (rc) {
+ rc = 0;
+ goto exit;
+ }
/*
* Allocation space for max attributs
--
1.7.7.6
^ permalink raw reply related
* [net-next 7/8] ixgbe: Deny MACVLAN requests from VFs with admin set MAC
From: Jeff Kirsher @ 2012-05-01 8:51 UTC (permalink / raw)
To: davem; +Cc: Greg Rose, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1335862269-28914-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
If the host VMM administrator has set the virtual function device's
MAC address then also deny VF requests for MACVLAN filters.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Garrett, Robert <robertx.e.garrett@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 88a58cb..3985637 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -635,6 +635,12 @@ static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
}
break;
case IXGBE_VF_SET_MACVLAN:
+ if (adapter->vfinfo[vf].pf_set_mac) {
+ e_warn(drv, "VF %d requested MACVLAN filter but is "
+ "administratively denied\n", vf);
+ retval = -1;
+ break;
+ }
index = (msgbuf[0] & IXGBE_VT_MSGINFO_MASK) >>
IXGBE_VT_MSGINFO_SHIFT;
/*
--
1.7.7.6
^ permalink raw reply related
* [net-next 8/8] ixgbe: Reset max_vfs to zero when user request is out of range
From: Jeff Kirsher @ 2012-05-01 8:51 UTC (permalink / raw)
To: davem; +Cc: Greg Rose, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1335862269-28914-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
If the user request for the number of VFs in the max_vfs parameter is
out of range then reset the value to the default value of zero. This
makes the behavior of the ixgbe driver the same as for the igb driver.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Robert Garrett <robertx.e.garrett@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index e8897cc..688c7bb 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -133,7 +133,7 @@ static struct notifier_block dca_notifier = {
static unsigned int max_vfs;
module_param(max_vfs, uint, 0);
MODULE_PARM_DESC(max_vfs,
- "Maximum number of virtual functions to allocate per physical function");
+ "Maximum number of virtual functions to allocate per physical function - default is zero and maximum value is 63");
#endif /* CONFIG_PCI_IOV */
static unsigned int allow_unsupported_sfp;
@@ -6778,9 +6778,10 @@ static void __devinit ixgbe_probe_vf(struct ixgbe_adapter *adapter,
/* The 82599 supports up to 64 VFs per physical function
* but this implementation limits allocation to 63 so that
* basic networking resources are still available to the
- * physical function
+ * physical function. If the user requests greater thn
+ * 63 VFs then it is an error - reset to default of zero.
*/
- adapter->num_vfs = (max_vfs > 63) ? 63 : max_vfs;
+ adapter->num_vfs = (max_vfs > 63) ? 0 : max_vfs;
ixgbe_enable_sriov(adapter, ii);
#endif /* CONFIG_PCI_IOV */
}
--
1.7.7.6
^ permalink raw reply related
* [PATCH net-next] netem: add ECN capability
From: Eric Dumazet @ 2012-05-01 9:11 UTC (permalink / raw)
To: David Miller
Cc: netdev, Tom Herbert, Neal Cardwell, Hagen Paul Pfeifer,
Stephen Hemminger
From: Eric Dumazet <edumazet@google.com>
Add ECN (Explicit Congestion Notification) marking capability to netem
tc qdisc add dev eth0 root netem drop 0.5 ecn
Instead of dropping packets, try to ECN mark them.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/pkt_sched.h | 1 +
net/sched/sch_netem.c | 18 +++++++++++++++---
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h
index 410b33d..ffe975c 100644
--- a/include/linux/pkt_sched.h
+++ b/include/linux/pkt_sched.h
@@ -509,6 +509,7 @@ enum {
TCA_NETEM_CORRUPT,
TCA_NETEM_LOSS,
TCA_NETEM_RATE,
+ TCA_NETEM_ECN,
__TCA_NETEM_MAX,
};
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 1109731..231cd11 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -26,6 +26,7 @@
#include <net/netlink.h>
#include <net/pkt_sched.h>
+#include <net/inet_ecn.h>
#define VERSION "1.3"
@@ -78,6 +79,7 @@ struct netem_sched_data {
psched_tdiff_t jitter;
u32 loss;
+ u32 ecn;
u32 limit;
u32 counter;
u32 gap;
@@ -374,9 +376,12 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
++count;
/* Drop packet? */
- if (loss_event(q))
- --count;
-
+ if (loss_event(q)) {
+ if (q->ecn && INET_ECN_set_ce(skb))
+ sch->qstats.drops++; /* mark packet */
+ else
+ --count;
+ }
if (count == 0) {
sch->qstats.drops++;
kfree_skb(skb);
@@ -706,6 +711,7 @@ static const struct nla_policy netem_policy[TCA_NETEM_MAX + 1] = {
[TCA_NETEM_CORRUPT] = { .len = sizeof(struct tc_netem_corrupt) },
[TCA_NETEM_RATE] = { .len = sizeof(struct tc_netem_rate) },
[TCA_NETEM_LOSS] = { .type = NLA_NESTED },
+ [TCA_NETEM_ECN] = { .type = NLA_U32 },
};
static int parse_attr(struct nlattr *tb[], int maxtype, struct nlattr *nla,
@@ -776,6 +782,9 @@ static int netem_change(struct Qdisc *sch, struct nlattr *opt)
if (tb[TCA_NETEM_RATE])
get_rate(sch, tb[TCA_NETEM_RATE]);
+ if (tb[TCA_NETEM_ECN])
+ q->ecn = nla_get_u32(tb[TCA_NETEM_ECN]);
+
q->loss_model = CLG_RANDOM;
if (tb[TCA_NETEM_LOSS])
ret = get_loss_clg(sch, tb[TCA_NETEM_LOSS]);
@@ -902,6 +911,9 @@ static int netem_dump(struct Qdisc *sch, struct sk_buff *skb)
if (nla_put(skb, TCA_NETEM_RATE, sizeof(rate), &rate))
goto nla_put_failure;
+ if (q->ecn && nla_put_u32(skb, TCA_NETEM_ECN, q->ecn))
+ goto nla_put_failure;
+
if (dump_loss_model(q, skb) != 0)
goto nla_put_failure;
^ permalink raw reply related
* Re: [PATCH net-next] netem: add ECN capability
From: Hagen Paul Pfeifer @ 2012-05-01 9:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Tom Herbert, Neal Cardwell,
Stephen Hemminger
In-Reply-To: <1335863465.11396.45.camel@edumazet-glaptop>
Nice!
* Eric Dumazet | 2012-05-01 11:11:05 [+0200]:
> u32 loss;
>+ u32 ecn;
Why no bool here Eric?
> u32 limit;
> u32 counter;
> u32 gap;
>@@ -374,9 +376,12 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
> ++count;
>
> /* Drop packet? */
>- if (loss_event(q))
>- --count;
>-
>+ if (loss_event(q)) {
>+ if (q->ecn && INET_ECN_set_ce(skb))
>+ sch->qstats.drops++; /* mark packet */
>+ else
>+ --count;
>+ }
> if (count == 0) {
> sch->qstats.drops++;
> kfree_skb(skb);
>@@ -706,6 +711,7 @@ static const struct nla_policy netem_policy[TCA_NETEM_MAX + 1] = {
> [TCA_NETEM_CORRUPT] = { .len = sizeof(struct tc_netem_corrupt) },
> [TCA_NETEM_RATE] = { .len = sizeof(struct tc_netem_rate) },
> [TCA_NETEM_LOSS] = { .type = NLA_NESTED },
>+ [TCA_NETEM_ECN] = { .type = NLA_U32 },
This netem API, what a heck ... Ideal we would extend TCA_NETEM_LOSS
somehow[tm], but yes ... ;(
Acked-by: Hagen Paul Pfeifer <hagen@jauu.net>
^ permalink raw reply
* Re: [PATCH net-next] netem: add ECN capability
From: Dave Taht @ 2012-05-01 10:14 UTC (permalink / raw)
To: Hagen Paul Pfeifer
Cc: Eric Dumazet, David Miller, netdev, Tom Herbert, Neal Cardwell,
Stephen Hemminger
In-Reply-To: <20120501092849.GB3453@hell>
On Tue, May 1, 2012 at 2:28 AM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> Nice!
Applause as well! While this is something of a fork of this
discussion, I would rather like to resurrect a variant of the old
'time in queue' patch...
http://patchwork.ozlabs.org/patch/125329/
As best as I recall we'd run into trouble with combining things like
netem and complex qdiscs, because we had basically overrun the size of
the control block.
And then there was a long discussion of all that and I forget if any
conclusion was reached.
An alternative to reducing the length of the control block was to find
some way to leverage this sanely in the qdisc layer...
#define HAVE_HW_TIME_STAMP
/**
* struct skb_shared_hwtstamps - hardware time stamps
* @hwtstamp: hardware time stamp transformed into duration
* since arbitrary point in time
* @syststamp: hwtstamp transformed to system time base
*
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
^ permalink raw reply
* Re: [PATCH net-next] net: add a prefetch in socket backlog processing
From: Joe Perches @ 2012-05-01 11:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1335854091.11396.21.camel@edumazet-glaptop>
On Tue, 2012-05-01 at 08:34 +0200, Eric Dumazet wrote:
> On Mon, 2012-04-30 at 20:24 -0700, Joe Perches wrote:
> > On Tue, 2012-05-01 at 04:07 +0200, Eric Dumazet wrote:
> > > From: Eric Dumazet <edumazet@google.com>
> > > TCP or UDP stacks have big enough latencies that prefetching next
> > > pointer is worth it.
> > >
> > > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > > ---
> > > net/core/sock.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/net/core/sock.c b/net/core/sock.c
> > > index 836bca6..1a88351 100644
> > > --- a/net/core/sock.c
> > > +++ b/net/core/sock.c
> > > @@ -1700,6 +1700,7 @@ static void __release_sock(struct sock *sk)
> > > do {
> > > struct sk_buff *next = skb->next;
> > >
> > > + prefetch(next);
> > > WARN_ON_ONCE(skb_dst_is_noref(skb));
> > > skb->next = NULL;
> > > sk_backlog_rcv(sk, skb);
> >
> > Hi Eric.
> >
> > Why should next be "prefetch"ed when
> > two lines below it's set to null and
> > the only use is as a pointer not as
> > an apparently undereferenced pointer?
> Thats because you have no idea of what is happening ?
Sometimes true. Ask my wife though and you
might get a "almost always true" reply.
Here it's true because I just glossed over the
code and didn't notice the loop control variable
was actually next (skb).
> next points to the next skb in list (after this skb)
>
> prefetch(next) instructs CPU to preload its cache with the memory
> content of first cache line of next skb (it contains its own ->next
> pointer)
>
> After prefetch(next), we clear skb->next before continuing, but we later
> will need the memory we preloaded in cpu cache at next iteration.
>
> Basically this patch avoids one memory cache miss per iteration.
That's true for cpus with sufficient cache but prefetch
might be wasteful for cpus without (like some ARMs).
Some of the sk_backlog_rcv functions like tcp_v4_do_rcv
can be relatively large.
It might be useful to have a target cpu compile time
test precede this prefetch.
cheers, Joe
^ permalink raw reply
* Re: [PATCH net-next] net: add a prefetch in socket backlog processing
From: Eric Dumazet @ 2012-05-01 12:29 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, netdev
In-Reply-To: <1335873153.26217.35.camel@joe2Laptop>
On Tue, 2012-05-01 at 04:52 -0700, Joe Perches wrote:
> That's true for cpus with sufficient cache but prefetch
> might be wasteful for cpus without (like some ARMs).
>
> Some of the sk_backlog_rcv functions like tcp_v4_do_rcv
> can be relatively large.
You speak of icache here. Thats different matter.
My patch does a prefetch of data (dcache)
>
> It might be useful to have a target cpu compile time
> test precede this prefetch.
How this prefetch() is different than other ones in kernel ?
We optimize linux for cpus with a minimum cache, not for the ones with
less than 16KB caches.
For old cpus, you can use linux 2.4 it works much better.
If you believe there is an issue on a particular arch, I suggest you
talk with arch maintainer about ARCH_HAS_PREFETCH being undefined on
this arch.
^ permalink raw reply
* Re: [PATCH] mwl8k: Add 0x2a02 PCI device-id (Marvell 88W8361)
From: Lennert Buytenhek @ 2012-05-01 12:47 UTC (permalink / raw)
To: sedat.dilek
Cc: John W. Linville, linux-wireless, netdev, linux-kernel, lautriv,
Jim Cromie
In-Reply-To: <CA+icZUWQmCRdjucb4+Nf24_zbJ4fzzp7zjqhKjXE6U01rppDfA@mail.gmail.com>
On Fri, Apr 27, 2012 at 11:53:28PM +0200, Sedat Dilek wrote:
> >> So, Lennert if you want more testing - What? How? etc.
> >
> > For one, the output of 'iw phy', please.
> >
> > Also, does monitor mode work? Do you get plausible channel/rxpower
> > values in tcpdump in monitor mode?
> >
> > Are there any messages in the syslog about failing commands?
>
> On 1st sight, logs look fine:
>
> [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4,
> 00173f3bdde3, STA firmware 2.1.4.25
>
> But WLAN connection is not that fast and stable as lautriv reports
> (several abnormalities were observed).
iwconfig saying "Bit Rate=1 Mb/s" can be safely ignored. If there is
a bitrate indication on transmitted packets in tcpdump, then that's
bogus too, as rate control is done in hardware. (I.e. if you want to
verify the rate at which a packet is transmitted, you'll have to sniff
from another machine.)
^ permalink raw reply
* Re: [PATCH] mwl8k: Add 0x2a02 PCI device-id (Marvell 88W8361)
From: Lennert Buytenhek @ 2012-05-01 12:51 UTC (permalink / raw)
To: sedat.dilek-Re5JQEeQqe8AvxtiuMwx3w
Cc: John W. Linville, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, lautriv, Jim Cromie
In-Reply-To: <CA+icZUXSaEMA=KbQP9UQcU6ZMBh8QD2sv-O=6r_Ly8is==gvSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote:
> > On 1st sight, logs look fine:
> >
> > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4,
> > 00173f3bdde3, STA firmware 2.1.4.25
> >
> > But WLAN connection is not that fast and stable as lautriv reports
> > (several abnormalities were observed).
> >
> > I requested a tarball which includes:
> > * dmesg (Linux-3.3.3)
> > * e_n_a (/etc/network/interfaces)
> > * ifconfig output
> > * iwconfig output
> > * iw_phy output
> > * ps_axu (WPA) output
> >
> > lautriv will be so kind to be around on #linux-wireless/Freenode the
> > next days (UTC+2: German/Swiss local-time).
> > Just ping him.
> >
> > Hope you have fun, together!
> >
> > - Sedat -
>
> A new tarball from lautriv with same outputs as before, but now tested
> with Linux-3.4-rc4.
The output looks good enough for me to ACK adding the PCI ID.
Can the firmware being used here be submitted to the linux-firmware
git tree?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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] mwl8k: Add 0x2a02 PCI device-id (Marvell 88W8361)
From: Lennert Buytenhek @ 2012-05-01 12:51 UTC (permalink / raw)
To: Jim Cromie; +Cc: sedat.dilek, John W. Linville, linux-wireless, netdev, lautriv
In-Reply-To: <CAJfuBxwz2PmNY37VB7Wx+GdQcOcS6Y96EM_JNtvs-dyv-imL6g@mail.gmail.com>
On Sat, Apr 28, 2012 at 05:11:06PM -0600, Jim Cromie wrote:
> That said, bitrate is quite low, I havent looked at why.
>
> jimc@chumly:~/projects/lx/wifi/mwl8k-8361p-logs$ grep -i MBit *
> iw-dev-wlan0-link: tx bitrate: 11.0 MBit/s
> iw-dev-wlan1-link: tx bitrate: 1.0 MBit/s
> iw-dev-wlan1-station-dump: tx bitrate: 1.0 MBit/s
> iw-dev-wlan1-station-get-00:14:d1:e8:65:0a: tx bitrate: 1.0 MBit/s
You can ignore those values, they don't reflect the actual
transmittion rate in use.
^ permalink raw reply
* Re: [PATCH net-next] net: add a prefetch in socket backlog processing
From: Joe Perches @ 2012-05-01 13:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1335875351.11396.55.camel@edumazet-glaptop>
On Tue, 2012-05-01 at 14:29 +0200, Eric Dumazet wrote:
> On Tue, 2012-05-01 at 04:52 -0700, Joe Perches wrote:
>
> > That's true for cpus with sufficient cache but prefetch
> > might be wasteful for cpus without (like some ARMs).
> >
> > Some of the sk_backlog_rcv functions like tcp_v4_do_rcv
> > can be relatively large.
>
> You speak of icache here. Thats different matter.
>
> My patch does a prefetch of data (dcache)
Actually I meant cpus with an integrated cache
like the old arm 710 and the sh3/7710.
I think those are still possible compilation
targets, but perhaps no one cares anymore.
> How this prefetch() is different than other ones in kernel ?
I'm not suggesting prefetch isn't useful.
If prefetch improves performance for the general case
it's good. If the prefetch can also be trivially
compile time wrapped to not impact older supported
targets, I think that's good too.
> For old cpus, you can use linux 2.4 it works much better.
Deprecating older targets may not be a bad thing either.
cheers, Joe
^ permalink raw reply
* Re: [PATCH 00/10 net-next] l2tp: misc fixes and add L2TPv3 IP encap over IPv6
From: David Miller @ 2012-05-01 13:38 UTC (permalink / raw)
To: jchapman; +Cc: netdev
In-Reply-To: <4F9FA0ED.7000402@katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Tue, 01 May 2012 09:38:05 +0100
> On 30/04/12 18:46, David Miller wrote:
>> From: James Chapman <jchapman@katalix.com>
>> Date: Mon, 30 Apr 2012 08:48:45 +0100
>>
>>> This patch series includes several L2TP fixes / cleanups and adds
>>> L2TPv3 IP encapsulation support for IPv6, building on the L2TP UDP
>>> IPv6 support recently added by Ben LaHaise.
>>
>> Series applied to net-next, thanks James.
>
> Thanks Dave.
> For some reason, I can't see the commits in the net-next tree. Are they
> still in your local tree?
This is what happens when one does GIT work on 4 different computers
during the day :-)
Pushed out and should be visible now, sorry about that :-)
^ permalink raw reply
* Re: [PATCH net-next] netem: add ECN capability
From: David Miller @ 2012-05-01 13:40 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, therbert, ncardwell, hagen, shemminger
In-Reply-To: <1335863465.11396.45.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 01 May 2012 11:11:05 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Add ECN (Explicit Congestion Notification) marking capability to netem
>
> tc qdisc add dev eth0 root netem drop 0.5 ecn
>
> Instead of dropping packets, try to ECN mark them.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: add a prefetch in socket backlog processing
From: David Miller @ 2012-05-01 13:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1335838029.11396.12.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 01 May 2012 04:07:09 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> TCP or UDP stacks have big enough latencies that prefetching next
> pointer is worth it.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: skb_peek()/skb_peek_tail() cleanups
From: David Miller @ 2012-05-01 13:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1335839506.11396.17.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 01 May 2012 04:31:46 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> remove useless casts and rename variables for less confusion.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, I really need to get back to completing the list_head
conversion :-/
^ permalink raw reply
* Re: [PATCH] net: fix two typos in skbuff.h
From: David Miller @ 2012-05-01 13:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1335857356.11396.31.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 01 May 2012 09:29:16 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> fix kernel doc typos in function names
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: pull request: batman-adv 2012-05-01
From: David Miller @ 2012-05-01 13:53 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1335859266-7546-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Date: Tue, 1 May 2012 10:00:59 +0200
> this is the new version of my previous pull request (issued on 2012-04-29).
> I'd like to see this changesin net-next/linux-3.5.
>
> In this pull request I entirely removed the D.A.T. code, that as we were
> discussing in the previous thread, needs some rewriting to avoid directly
> dealing with the neigh table.
>
> This patchset only contains fixes and cleanups.
When I pull this tree I start to get an enormous number of objects
sent over, way more than your pull request indicates:
[davem@bql net-next]$ git pull git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem
remote: Counting objects: 42485, done.
remote: Compressing objects: 100% (7640/7640), done.
Receiving objects: 12% (4594/36644), 1.42 MiB | 56 KiB/s C-c C-c
I Ctrl-C'd this because I don't even want to see what this is going to crap
into my tree.
You have something totally inappropriate in there, and I think your changes
are not based upon my net-next tree, but rather something entirely else.
I took a quick look and it looks like you prepared this against either
Linus's tree or the 'net' tree.
NEVER DO THIS.
You must based your changes exactly, and solely, upon the tree you
want me to pull your stuff it into. It is never appropriate to make
changes against another tree, and then ask me to pull the result of
that into mine.
Please do not waste my time with garbage like this.
^ permalink raw reply
* Re: [PATCH] mwl8k: Add 0x2a02 PCI device-id (Marvell 88W8361)
From: Sedat Dilek @ 2012-05-01 13:54 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: John W. Linville, linux-wireless, netdev, linux-kernel, lautriv,
Jim Cromie, Ben Hutchings, Hauke Mehrtens
In-Reply-To: <20120501125102.GN3157@wantstofly.org>
[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]
On Tue, May 1, 2012 at 2:51 PM, Lennert Buytenhek
<buytenh@wantstofly.org> wrote:
> On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote:
>
>> > On 1st sight, logs look fine:
>> >
>> > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4,
>> > 00173f3bdde3, STA firmware 2.1.4.25
>> >
>> > But WLAN connection is not that fast and stable as lautriv reports
>> > (several abnormalities were observed).
>> >
>> > I requested a tarball which includes:
>> > * dmesg (Linux-3.3.3)
>> > * e_n_a (/etc/network/interfaces)
>> > * ifconfig output
>> > * iwconfig output
>> > * iw_phy output
>> > * ps_axu (WPA) output
>> >
>> > lautriv will be so kind to be around on #linux-wireless/Freenode the
>> > next days (UTC+2: German/Swiss local-time).
>> > Just ping him.
>> >
>> > Hope you have fun, together!
>> >
>> > - Sedat -
>>
>> A new tarball from lautriv with same outputs as before, but now tested
>> with Linux-3.4-rc4.
[ CC hauke (OpenWrt) and Ben Hutchings (linux-firmware maintainer) ]
> The output looks good enough for me to ACK adding the PCI ID.
>
> Can the firmware being used here be submitted to the linux-firmware
> git tree?
I can't say much about the firmware [1] inclusion or the procedure of
it into linux-firmware [2].
Maybe, Ben can explain the procedure and what has to be considered
before inclusion in linux-firmware.
The original firmware and helper images were extracted from a Netgear
Windows driver [1].
>From what I read in the OpenWrt forum posting [3]: You wanted to care
for inclusion:
"Firmware isn't included in the kernel tree anymore, there's the
linux-firmware git tree for that these days. I will contact some
people at Marvell to ask whether 8361P firmware can be included
there."
Some more concerns...
Dunno, if [4] is really correct and how to use one and same device-id
for 8363 ***and*** 8361P:
...
{ PCI_VDEVICE(MARVELL, 0x2a02), .driver_data = MWL8363, },
...
Curious about a statement from hauke...
Adding the device-id in case of 8361P is not enough (see attached patch)
I am looking forward to having support for 8361P soon.
- Sedat -
P.S.: I have re-added Readme and patch as there are new CCs.
[1] ftp://downloads.netgear.com/files/wn311t_4_2_setup.exe
[2] http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary
[3] https://forum.openwrt.org/viewtopic.php?pid=110039#p110039
[4] https://dev.openwrt.org/changeset/21167
[-- Attachment #2: mwl8k_extract_firmware_v2.txt --]
[-- Type: text/plain, Size: 1347 bytes --]
##### HOWTO: Extract the firmware for the mwl8k Linux WLAN driver #####
### HELP-1: https://forum.openwrt.org/viewtopic.php?pid=103243#p103243
### HELP-2: https://forum.openwrt.org/viewtopic.php?pid=110004#p110004
### THREAD: http://marc.info/?t=133551792600004&r=1&w=2
### Install some tools to inspect file containing firmware blob
sudo apt-get install cabextract unshield
### Working directory
mkdir mwl8k
cd mwl8k
### Download c-file (extract firmware) and Windows setup file (incl. firmware)
mkdir files
cd files
wget -O mrv8k_extract_fw.c 'http://marc.info/?l=linux-wireless&m=126540674419330&q=p3'
wget ftp://downloads.netgear.com/files/wn311t_4_2_setup.exe
### Extract firmware blob
mkdir .tmp ../firmware
cabextract -F Disk1/data*.* -d .tmp wn311t_4_2_setup.exe
unshield -g Driver -d .tmp x .tmp/Disk1/data1.cab
gcc -o mrv8k_extract_fw mrv8k_extract_fw.c
./mrv8k_extract_fw .tmp/Driver/netmw145.sys
mv *.fw ../firmware/
rm -r -f .tmp
### Check MD5SUM and rename firmware/helper image files for 8361P/8363
[ Known MD5SUMS for 8361P ]
48c79b085f7f5a590d3dbc15647e519f *fmimage_8XX0.fw
0fe11f415adbbd5e8ca03641705c4a6c *helper_8XX0.fw
cd ../firmware
md5sum -b *.fw
mv fmimage_8XX0.fw fmimage_8361p.fw
mv helper_8XX0.fw helper_8361p.fw
mv fmimage_8XX1.fw fmimage_8363.fw
mv helper_8XX1.fw helper_8363.fw
-dileks // 27-Apr-2012
[-- Attachment #3: 0001-mwl8k-Add-support-for-MWL8361P.patch --]
[-- Type: application/octet-stream, Size: 2171 bytes --]
From 1a586a1f21f820de0ea06c5382a69191d93d80fe Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Fri, 27 Apr 2012 13:46:02 +0200
Subject: [PATCH] mwl8k: Add support for MWL8361P
Follow discussion in [1] for more details about adding driver
support and howto extract firmware files.
$ sudo modinfo mwl8k | egrep -i '8361p|2a02'
firmware: mwl8k/fmimage_8361p.fw
firmware: mwl8k/helper_8361p.fw
alias: pci:v000011ABd00002A02sv*sd*bc*sc*i*
Compile-tested against Linux-3.4-rc4+.
[1] http://marc.info/?t=133551792600004&r=1&w=2
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/net/wireless/mwl8k.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index b48674b..3ea9b8e 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -5225,6 +5225,7 @@ static void mwl8k_finalize_join_worker(struct work_struct *work)
}
enum {
+ MWL8361P = 0,
MWL8363 = 0,
MWL8687,
MWL8366,
@@ -5235,6 +5236,11 @@ enum {
#define MWL8K_8366_AP_FW(api) _MWL8K_8366_AP_FW(api)
static struct mwl8k_device_info mwl8k_info_tbl[] __devinitdata = {
+ [MWL8361P] = {
+ .part_name = "88w8361p",
+ .helper_image = "mwl8k/helper_8361p.fw",
+ .fw_image_sta = "mwl8k/fmimage_8361p.fw",
+ },
[MWL8363] = {
.part_name = "88w8363",
.helper_image = "mwl8k/helper_8363.fw",
@@ -5255,6 +5261,8 @@ static struct mwl8k_device_info mwl8k_info_tbl[] __devinitdata = {
},
};
+MODULE_FIRMWARE("mwl8k/helper_8361p.fw");
+MODULE_FIRMWARE("mwl8k/fmimage_8361p.fw");
MODULE_FIRMWARE("mwl8k/helper_8363.fw");
MODULE_FIRMWARE("mwl8k/fmimage_8363.fw");
MODULE_FIRMWARE("mwl8k/helper_8687.fw");
@@ -5264,6 +5272,7 @@ MODULE_FIRMWARE("mwl8k/fmimage_8366.fw");
MODULE_FIRMWARE(MWL8K_8366_AP_FW(MWL8K_8366_AP_FW_API));
static DEFINE_PCI_DEVICE_TABLE(mwl8k_pci_id_table) = {
+ { PCI_VDEVICE(MARVELL, 0x2a02), .driver_data = MWL8361P, },
{ PCI_VDEVICE(MARVELL, 0x2a0a), .driver_data = MWL8363, },
{ PCI_VDEVICE(MARVELL, 0x2a0c), .driver_data = MWL8363, },
{ PCI_VDEVICE(MARVELL, 0x2a24), .driver_data = MWL8363, },
--
1.7.9.5
^ permalink raw reply related
* Re: pull request: batman-adv 2012-05-01
From: David Miller @ 2012-05-01 13:56 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20120501.095308.1750249183824872989.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Tue, 01 May 2012 09:53:08 -0400 (EDT)
> I took a quick look and it looks like you prepared this against either
> Linus's tree or the 'net' tree.
Even worse, you based this on the linux-next tree.
What in the world is wrong with you?
What in your mind makes you think I want to pull in all
of the rest of the linux-next stuff into MY TREE?
I'm really pissed off. Don't send me pull requests for at least
a week, I don't want to deal with you at all at this point.
^ permalink raw reply
* Re: [net-next v2 6/8] ixgbe: add syfs interface for to export read only driver information
From: David Miller @ 2012-05-01 14:02 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: donald.c.skidmore, netdev, gospo, sassmann, bhutchings
In-Reply-To: <1335862269-28914-7-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 1 May 2012 01:51:07 -0700
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> This patch exports non-thermal (which was done via hwmon in an earlier
> patch) data to sysfs which isn't readily available elsewhere. All of the
> fields are read only as this interface is to only export driver data.
>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Tested-by: Stephen Ko <stephen.s.ko@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
I don't like it.
Some of this stuff is generic and belongs somewhere like ethtool, for
example the descriptor sizes and queue sizes.
The others are reading registers, and we have an ethtool API for that
already.
But putting anything like this in sysfs is pointless, because the
stuff that other cards have too will then go into differently named
sysfs files which, as is oft repeated here, is a terrible user
experience.
If you want to do this right, add a new ethtool interface that allows
the publication of card specific unchanging values, in a style like
what we already do for statistics. Have one query that gets the
string list, and then another which fetches the actual values.
I hate sysfs, don't send me any more patches that add sysfs files for
networking devices. :-)
^ permalink raw reply
* Re: pull request: batman-adv 2012-05-01
From: Antonio Quartulli @ 2012-05-01 14:12 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20120501.095626.666012983167129504.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]
On Tue, May 01, 2012 at 09:56:26 -0400, David Miller wrote:
> From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Date: Tue, 01 May 2012 09:53:08 -0400 (EDT)
>
> > I took a quick look and it looks like you prepared this against either
> > Linus's tree or the 'net' tree.
>
> Even worse, you based this on the linux-next tree.
>
> What in the world is wrong with you?
>
> What in your mind makes you think I want to pull in all
> of the rest of the linux-next stuff into MY TREE?
>
> I'm really pissed off. Don't send me pull requests for at least
> a week, I don't want to deal with you at all at this point.
I'm really sorry David.
You are right, when pulling the remote branch I wrongly chose the incorrect repo
from git.kernel.org (don't know what was going on in my brain and I swapped
net-next with linux-next) :-(. I paid my inexperience. But at least I (and
others) can learn from my errors.
Sorry for wasting your time.
I will surely avoid this in the future.
Best regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH 0/2] iproute2: add support for L2TP over IPv6, add manpage
From: James Chapman @ 2012-05-01 14:25 UTC (permalink / raw)
To: netdev
The "ip l2tp" commands already support L2TP over IPv4. These patches
add support for L2TP over IPv6 and add a man page covering the command
set.
The patches depend on the L2TP IPv6 patch series recently applied to
net-next. The local copy of kernel header files should be updated in
the iproute2 tree before applying these patches.
Chris Elston (1):
iproute2: allow IPv6 addresses for l2tp local and remote parameters
James Chapman (1):
iproute2: add ip-l2tp man page
ip/ipl2tp.c | 59 ++++++--
man/man8/ip-l2tp.8 | 376 ++++++++++++++++++++++++++++++++++++++++++++++++++++
man/man8/ip.8 | 3 +-
3 files changed, 423 insertions(+), 15 deletions(-)
create mode 100644 man/man8/ip-l2tp.8
^ permalink raw reply
* [PATCH 2/2] iproute2: add ip-l2tp man page
From: James Chapman @ 2012-05-01 14:25 UTC (permalink / raw)
To: netdev
In-Reply-To: <1335882323-6219-1-git-send-email-jchapman@katalix.com>
Add a man page to cover the "ip l2tp" commands. Add a reference to it
in the main ip page.
This version removes the unnecessary setting of promiscuous mode
in the examples.
Signed-off-by: James Chapman <jchapman@katalix.com>
---
man/man8/ip-l2tp.8 | 376 ++++++++++++++++++++++++++++++++++++++++++++++++++++
man/man8/ip.8 | 3 +-
2 files changed, 378 insertions(+), 1 deletions(-)
create mode 100644 man/man8/ip-l2tp.8
diff --git a/man/man8/ip-l2tp.8 b/man/man8/ip-l2tp.8
new file mode 100644
index 0000000..18a83d4
--- /dev/null
+++ b/man/man8/ip-l2tp.8
@@ -0,0 +1,376 @@
+.TH IP\-L2TP 8 "19 Apr 2012" "iproute2" "Linux"
+.SH "NAME"
+ip-l2tp - L2TPv3 static unmanaged tunnel configuration
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B l2tp
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+.ti -8
+.BR "ip l2tp add tunnel"
+.br
+.B remote
+.RI "[ " ADDR " ]"
+.B local
+.RI "[ " ADDR " ]"
+.br
+.B tunnel_id
+.IR ID
+.B peer_tunnel_id
+.IR ID
+.br
+.RB "[ " encap " { " ip " | " udp " } ]"
+.br
+.RB "[ " udp_sport
+.IR PORT
+.RB " ] [ " udp_dport
+.IR PORT
+.RB " ]"
+.br
+.ti -8
+.BR "ip l2tp add session"
+.RB "[ " name
+.IR NAME
+.RB " ]"
+.br
+.B tunnel_id
+.IR ID
+.B session_id
+.IR ID
+.B peer_session_id
+.IR ID
+.br
+.RB "[ " cookie
+.IR HEXSTR
+.RB " ] [ " peer_cookie
+.IR HEXSTR
+.RB " ]"
+.br
+.RB "[ " offset
+.IR OFFSET
+.RB " ] [ " peer_offset
+.IR OFFSET
+.RB " ]"
+.br
+.ti -8
+.BR "ip l2tp del tunnel"
+.B tunnel_id
+.IR ID
+.br
+.ti -8
+.BR "ip l2tp del session"
+.B tunnel_id
+.IR ID
+.B session_id
+.IR ID
+.br
+.ti -8
+.BR "ip l2tp show tunnel"
+.B "[" tunnel_id
+.IR ID
+.B "]"
+.br
+.ti -8
+.BR "ip l2tp show session"
+.B "[" tunnel_id
+.IR ID
+.B "] [" session_id
+.IR ID
+.B "]"
+.br
+.ti -8
+.IR NAME " := "
+.IR STRING
+.ti -8
+.IR ADDR " := { " IP_ADDRESS " }"
+.ti -8
+.IR PORT " := { " NUMBER " }"
+.ti -8
+.IR ID " := { " NUMBER " }"
+.ti -8
+.ti -8
+.IR HEXSTR " := { 8 or 16 hex digits (4 / 8 bytes) }"
+.SH DESCRIPTION
+The
+.B ip l2tp
+commands are used to establish static, or so-called
+.I unmanaged
+L2TPv3 ethernet tunnels. For unmanaged tunnels, there is no L2TP
+control protocol so no userspace daemon is required - tunnels are
+manually created by issuing commands at a local system and at a remote
+peer.
+.PP
+L2TPv3 is suitable for Layer-2 tunnelling. Static tunnels are useful
+to establish network links across IP networks when the tunnels are
+fixed. L2TPv3 tunnels can carry data of more than one session. Each
+session is identified by a session_id and its parent tunnel's
+tunnel_id. A tunnel must be created before a session can be created in
+the tunnel.
+.PP
+When creating an L2TP tunnel, the IP address of the remote peer is
+specified, which can be either an IPv4 or IPv6 address. The local IP
+address to be used to reach the peer must also be specified. This is
+the address on which the local system will listen for and accept
+received L2TP data packets from the peer.
+.PP
+L2TPv3 defines two packet encapsulation formats: UDP or IP. UDP
+encapsulation is most common. IP encapsulation uses a dedicated IP
+protocol value to carry L2TP data without the overhead of UDP. Use IP
+encapsulation only when there are no NAT devices or firewalls in the
+network path.
+.PP
+When an L2TPv3 ethernet session is created, a virtual network
+interface is created for the session, which must then be configured
+and brought up, just like any other network interface. When data is
+passed through the interface, it is carried over the L2TP tunnel to
+the peer. By configuring the system's routing tables or adding the
+interface to a bridge, the L2TP interface is like a virtual wire
+(pseudowire) connected to the peer.
+.PP
+Establishing an unmanaged L2TPv3 ethernet pseudowire involves manually
+creating L2TP contexts on the local system and at the peer. Parameters
+used at each site must correspond or no data will be passed. No
+consistency checks are possible since there is no control protocol
+used to establish unmanaged L2TP tunnels. Once the virtual network
+interface of a given L2TP session is configured and enabled, data can
+be transmitted, even if the peer isn't yet configured. If the peer
+isn't configured, the L2TP data packets will be discarded by
+the peer.
+.PP
+To establish an unmanaged L2TP tunnel, use
+.B l2tp add tunnel
+and
+.B l2tp add session
+commands described in this document. Then configure and enable the
+tunnel's virtual network interface, as required.
+.PP
+Note that unmanaged tunnels carry only ethernet frames. If you need to
+carry PPP traffic (L2TPv2) or your peer doesn't support unmanaged
+L2TPv3 tunnels, you will need an L2TP server which implements the L2TP
+control protocol. The L2TP control protocol allows dynamic L2TP
+tunnels and sessions to be established and provides for detecting and
+acting upon network failures.
+.SS ip l2tp add tunnel - add a new tunnel
+.TP
+.BI name " NAME "
+sets the session network interface name. Default is l2tpethN.
+.TP
+.BI tunnel_id " ID"
+set the tunnel id, which is a 32-bit integer value. Uniquely
+identifies the tunnel. The value used must match the peer_tunnel_id
+value being used at the peer.
+.TP
+.BI peer_tunnel_id " ID"
+set the peer tunnel id, which is a 32-bit integer value assigned to
+the tunnel by the peer. The value used must match the tunnel_id value
+being used at the peer.
+.TP
+.BI remote " ADDR"
+set the IP address of the remote peer. May be specified as an IPv4
+address or an IPv6 address.
+.TP
+.BI local " ADDR"
+set the IP address of the local interface to be used for the
+tunnel. This address must be the address of a local interface. May be
+specified as an IPv4 address or an IPv6 address.
+.TP
+.BI encap " ENCAP"
+set the encapsulation type of the tunnel.
+.br
+Valid values for encapsulation are:
+.BR udp ", " ip "."
+.TP
+.BI udp_sport " PORT"
+set the UDP source port to be used for the tunnel. Must be present
+when udp encapsulation is selected. Ignored when ip encapsulation is
+selected.
+.TP
+.BI udp_dport " PORT"
+set the UDP destination port to be used for the tunnel. Must be
+present when udp encapsulation is selected. Ignored when ip
+encapsulation is selected.
+.SS ip l2tp del tunnel - destroy a tunnel
+.TP
+.BI tunnel_id " ID"
+set the tunnel id of the tunnel to be deleted. All sessions within the
+tunnel must be deleted first.
+.SS ip l2tp show tunnel - show information about tunnels
+.TP
+.BI tunnel_id " ID"
+set the tunnel id of the tunnel to be shown. If not specified,
+information about all tunnels is printed.
+.SS ip l2tp add session - add a new session to a tunnel
+.TP
+.BI name " NAME "
+sets the session network interface name. Default is l2tpethN.
+.TP
+.BI tunnel_id " ID"
+set the tunnel id, which is a 32-bit integer value. Uniquely
+identifies the tunnel into which the session will be created. The
+tunnel must already exist.
+.TP
+.BI session_id " ID"
+set the session id, which is a 32-bit integer value. Uniquely
+identifies the session being created. The value used must match the
+peer_session_id value being used at the peer.
+.TP
+.BI peer_session_id " ID"
+set the peer session id, which is a 32-bit integer value assigned to
+the session by the peer. The value used must match the session_id
+value being used at the peer.
+.TP
+.BI cookie " HEXSTR"
+sets an optional cookie value to be assigned to the session. This is a
+4 or 8 byte value, specified as 8 or 16 hex digits,
+e.g. 014d3636deadbeef. The value must match the peer_cookie value set
+at the peer. The cookie value is carried in L2TP data packets and is
+checked for expected value at the peer. Default is to use no cookie.
+.TP
+.BI peer_cookie " HEXSTR"
+sets an optional peer cookie value to be assigned to the session. This
+is a 4 or 8 byte value, specified as 8 or 16 hex digits,
+e.g. 014d3636deadbeef. The value must match the cookie value set at
+the peer. It tells the local system what cookie value to expect to
+find in received L2TP packets. Default is to use no cookie.
+.TP
+.BI offset " OFFSET"
+sets the byte offset from the L2TP header where user data starts in
+transmitted L2TP data packets. This is hardly ever used. If set, the
+value must match the peer_offset value used at the peer. Default is 0.
+.TP
+.BI peer_offset " OFFSET"
+sets the byte offset from the L2TP header where user data starts in
+received L2TP data packets. This is hardly ever used. If set, the
+value must match the offset value used at the peer. Default is 0.
+.SS ip l2tp del session - destroy a session
+.TP
+.BI tunnel_id " ID"
+set the tunnel id in which the session to be deleted is located.
+.TP
+.BI session_id " ID"
+set the session id of the session to be deleted.
+.SS ip l2tp show session - show information about sessions
+.TP
+.BI tunnel_id " ID"
+set the tunnel id of the session(s) to be shown. If not specified,
+information about sessions in all tunnels is printed.
+.TP
+.BI session_id " ID"
+set the session id of the session to be shown. If not specified,
+information about all sessions is printed.
+.SH EXAMPLES
+.PP
+.SS Setup L2TP tunnels and sessions
+.nf
+site-A:# ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 \\
+ encap udp local 1.2.3.4 remote 5.6.7.8 \\
+ udp_sport 5000 udp_dport 6000
+site-A:# ip l2tp add session tunnel_id 3000 session_id 1000 \\
+ peer_session_id 2000
+
+site-B:# ip l2tp add tunnel tunnel_id 4000 peer_tunnel_id 3000 \\
+ encap udp local 5.6.7.8 remote 1.2.3.4 \\
+ udp_sport 6000 udp_dport 5000
+site-B:# ip l2tp add session tunnel_id 4000 session_id 2000 \\
+ peer_session_id 1000
+
+site-A:# ip link set l2tpeth0 up mtu 1488
+
+site-B:# ip link set l2tpeth0 up mtu 1488
+.fi
+.PP
+Notice that the IP addresses, UDP ports and tunnel / session ids are
+matched and reversed at each site.
+.SS Configure as IP interfaces
+The two interfaces can be configured with IP addresses if only IP data
+is to be carried. This is perhaps the simplest configuration.
+.PP
+.nf
+site-A:# ip addr add 10.42.1.1 peer 10.42.1.2 dev l2tpeth0
+
+site-B:# ip addr add 10.42.1.2 peer 10.42.1.1 dev l2tpeth0
+
+site-A:# ping 10.42.1.2
+.fi
+.PP
+Now the link should be usable. Add static routes as needed to have
+data sent over the new link.
+.PP
+.SS Configure as bridged interfaces
+To carry non-IP data, the L2TP network interface is added to a bridge
+instead of being assigned its own IP address, using standard Linux
+utilities. Since raw ethernet frames are then carried inside the
+tunnel, the MTU of the L2TP interfaces must be set to allow space for
+those headers.
+.PP
+.nf
+site-A:# ip link set l2tpeth0 up mtu 1446
+site-A:# brctl addbr br0
+site-A:# brctl addif br0 l2tpeth0
+site-A:# brctl addif br0 eth0
+site-A:# ip link set br0 up
+.fi
+.PP
+If you are using VLANs, setup a bridge per VLAN and bridge each VLAN
+over a separate L2TP session. For example, to bridge VLAN ID 5 on eth1
+over an L2TP pseudowire:
+.PP
+.nf
+site-A:# ip link set l2tpeth0 up mtu 1446
+site-A:# brctl addbr brvlan5
+site-A:# brctl addif brvlan5 l2tpeth0.5
+site-A:# brctl addif brvlan5 eth1.5
+site-A:# ip link set brvlan5 up
+.fi
+.PP
+Adding the L2TP interface to a bridge causes the bridge to forward
+traffic over the L2TP pseudowire just like it forwards over any other
+interface. The bridge learns MAC addresses of hosts attached to each
+interface and intelligently forwards frames from one bridge port to
+another. IP addresses are not assigned to the l2tpethN interfaces. If
+the bridge is correctly configured at both sides of the L2TP
+pseudowire, it should be possible to reach hosts in the peer's bridged
+network.
+.PP
+When raw ethernet frames are bridged across an L2TP tunnel, large
+frames may be fragmented and forwarded as individual IP fragments to
+the recipient, depending on the MTU of the physical interface used by
+the tunnel. When the ethernet frames carry protocols which are
+reassembled by the recipient, like IP, this isn't a problem. However,
+such fragmentation can cause problems for protocols like PPPoE where
+the recipient expects to receive ethernet frames exactly as
+transmitted. In such cases, it is important that frames leaving the
+tunnel are reassembled back into a single frame before being
+forwarded on. To do so, enable netfilter connection tracking
+(conntrack) or manually load the Linux netfilter degrag modules at
+each tunnel endpoint.
+.PP
+.nf
+site-A:# modprobe nf_degrag_ipv4
+
+site-B:# modprobe nf_degrag_ipv4
+.fi
+.PP
+If L2TP is being used over IPv6, use the IPv6 degrag module.
+.SH INTEROPABILITY
+.PP
+Unmanaged (static) L2TPv3 tunnels are supported by some network
+equipment equipment vendors such as Cisco.
+.PP
+In Linux, L2TP Hello messages are not supported in unmanaged
+tunnels. Hello messages are used by L2TP clients and servers to detect
+link failures in order to automate tearing down and reestablishing
+dynamic tunnels. If a non-Linux peer supports Hello messages in
+unmanaged tunnels, it must be turned off to interoperate with Linux.
+.SH SEE ALSO
+.br
+.BR brctl (8)
+.BR ip (8)
+.SH AUTHOR
+James Chapman <jchapman@katalix.com>
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 0f9f454..ede3d12 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -113,7 +113,7 @@ host addresses.
.TP
.B l2tp
-- tunnel PPP over IP (L2TP).
+- tunnel ethernet over IP (L2TPv3).
.TP
.B link
@@ -205,6 +205,7 @@ was written by Alexey N. Kuznetsov and added in Linux 2.2.
.SH SEE ALSO
.BR ip-address (8),
.BR ip-addrlabel (8),
+.BR ip-l2tp (8),
.BR ip-link (8),
.BR ip-maddress (8),
.BR ip-monitor (8),
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] iproute2: allow IPv6 addresses for l2tp local and remote parameters
From: James Chapman @ 2012-05-01 14:25 UTC (permalink / raw)
To: netdev; +Cc: Chris Elston
In-Reply-To: <1335882323-6219-1-git-send-email-jchapman@katalix.com>
From: Chris Elston <celston@katalix.com>
Adds support for parsing IPv6 addresses to the parameters local and
remote in the l2tp commands. Requires netlink attributes L2TP_ATTR_IP6_SADDR
and L2TP_ATTR_IP6_DADDR, added in a required kernel patch already submitted
to netdev.
Also enables printing of IPv6 addresses returned by the L2TP_CMD_TUNNEL_GET
request.
Signed-off-by: Chris Elston <celston@katalix.com>
Signed-off-by: James Chapman <jchapman@katalix.com>
---
ip/ipl2tp.c | 59 +++++++++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index c5683f5..a05e1a3 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -50,8 +50,8 @@ struct l2tp_parm {
uint8_t cookie[8];
int peer_cookie_len;
uint8_t peer_cookie[8];
- struct in_addr local_ip;
- struct in_addr peer_ip;
+ inet_prefix local_ip;
+ inet_prefix peer_ip;
uint16_t pw_type;
uint16_t mtu;
@@ -97,6 +97,8 @@ static int create_tunnel(struct l2tp_parm *p)
struct genlmsghdr g;
char buf[1024];
} req;
+ uint32_t local_attr = L2TP_ATTR_IP_SADDR;
+ uint32_t peer_attr = L2TP_ATTR_IP_DADDR;
memset(&req, 0, sizeof(req));
req.n.nlmsg_type = genl_family;
@@ -110,8 +112,14 @@ static int create_tunnel(struct l2tp_parm *p)
addattr8(&req.n, 1024, L2TP_ATTR_PROTO_VERSION, 3);
addattr16(&req.n, 1024, L2TP_ATTR_ENCAP_TYPE, p->encap);
- addattr32(&req.n, 1024, L2TP_ATTR_IP_SADDR, p->local_ip.s_addr);
- addattr32(&req.n, 1024, L2TP_ATTR_IP_DADDR, p->peer_ip.s_addr);
+ if (p->local_ip.family == AF_INET6)
+ local_attr = L2TP_ATTR_IP6_SADDR;
+ addattr_l(&req.n, 1024, local_attr, &p->local_ip.data, p->local_ip.bytelen);
+
+ if (p->peer_ip.family == AF_INET6)
+ peer_attr = L2TP_ATTR_IP6_DADDR;
+ addattr_l(&req.n, 1024, peer_attr, &p->peer_ip.data, p->peer_ip.bytelen);
+
if (p->encap == L2TP_ENCAPTYPE_UDP) {
addattr16(&req.n, 1024, L2TP_ATTR_UDP_SPORT, p->local_udp_port);
addattr16(&req.n, 1024, L2TP_ATTR_UDP_DPORT, p->peer_udp_port);
@@ -225,13 +233,14 @@ static void print_cookie(char *name, const uint8_t *cookie, int len)
static void print_tunnel(const struct l2tp_data *data)
{
const struct l2tp_parm *p = &data->config;
+ char buf[INET6_ADDRSTRLEN];
printf("Tunnel %u, encap %s\n",
p->tunnel_id,
p->encap == L2TP_ENCAPTYPE_UDP ? "UDP" :
p->encap == L2TP_ENCAPTYPE_IP ? "IP" : "??");
- printf(" From %s ", inet_ntoa(p->local_ip));
- printf("to %s\n", inet_ntoa(p->peer_ip));
+ printf(" From %s ", inet_ntop(p->local_ip.family, p->local_ip.data, buf, sizeof(buf)));
+ printf("to %s\n", inet_ntop(p->peer_ip.family, p->peer_ip.data, buf, sizeof(buf)));
printf(" Peer tunnel %u\n",
p->peer_tunnel_id);
@@ -315,10 +324,30 @@ static int get_response(struct nlmsghdr *n, void *arg)
if (attrs[L2TP_ATTR_RECV_TIMEOUT])
p->reorder_timeout = rta_getattr_u64(attrs[L2TP_ATTR_RECV_TIMEOUT]);
- if (attrs[L2TP_ATTR_IP_SADDR])
- p->local_ip.s_addr = rta_getattr_u32(attrs[L2TP_ATTR_IP_SADDR]);
- if (attrs[L2TP_ATTR_IP_DADDR])
- p->peer_ip.s_addr = rta_getattr_u32(attrs[L2TP_ATTR_IP_DADDR]);
+ if (attrs[L2TP_ATTR_IP_SADDR]) {
+ p->local_ip.family = AF_INET;
+ p->local_ip.data[0] = rta_getattr_u32(attrs[L2TP_ATTR_IP_SADDR]);
+ p->local_ip.bytelen = 4;
+ p->local_ip.bitlen = -1;
+ }
+ if (attrs[L2TP_ATTR_IP_DADDR]) {
+ p->peer_ip.family = AF_INET;
+ p->peer_ip.data[0] = rta_getattr_u32(attrs[L2TP_ATTR_IP_DADDR]);
+ p->peer_ip.bytelen = 4;
+ p->peer_ip.bitlen = -1;
+ }
+ if (attrs[L2TP_ATTR_IP6_SADDR]) {
+ p->local_ip.family = AF_INET6;
+ memcpy(&p->local_ip.data, RTA_DATA(attrs[L2TP_ATTR_IP6_SADDR]),
+ p->local_ip.bytelen = 16);
+ p->local_ip.bitlen = -1;
+ }
+ if (attrs[L2TP_ATTR_IP6_DADDR]) {
+ p->peer_ip.family = AF_INET6;
+ memcpy(&p->peer_ip.data, RTA_DATA(attrs[L2TP_ATTR_IP6_DADDR]),
+ p->peer_ip.bytelen = 16);
+ p->peer_ip.bitlen = -1;
+ }
if (attrs[L2TP_ATTR_UDP_SPORT])
p->local_udp_port = rta_getattr_u16(attrs[L2TP_ATTR_UDP_SPORT]);
if (attrs[L2TP_ATTR_UDP_DPORT])
@@ -529,10 +558,12 @@ static int parse_args(int argc, char **argv, int cmd, struct l2tp_parm *p)
p->ifname = *argv;
} else if (strcmp(*argv, "remote") == 0) {
NEXT_ARG();
- p->peer_ip.s_addr = get_addr32(*argv);
+ if (get_addr(&p->peer_ip, *argv, AF_UNSPEC))
+ invarg("invalid remote address\n", *argv);
} else if (strcmp(*argv, "local") == 0) {
NEXT_ARG();
- p->local_ip.s_addr = get_addr32(*argv);
+ if (get_addr(&p->local_ip, *argv, AF_UNSPEC))
+ invarg("invalid local address\n", *argv);
} else if ((strcmp(*argv, "tunnel_id") == 0) ||
(strcmp(*argv, "tid") == 0)) {
__u32 uval;
@@ -648,10 +679,10 @@ static int do_add(int argc, char **argv)
missarg("peer_tunnel_id");
if (p.tunnel) {
- if (p.local_ip.s_addr == 0)
+ if (p.local_ip.family == AF_UNSPEC)
missarg("local");
- if (p.peer_ip.s_addr == 0)
+ if (p.peer_ip.family == AF_UNSPEC)
missarg("remote");
if (p.encap == L2TP_ENCAPTYPE_UDP) {
--
1.7.0.4
^ permalink raw reply related
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