[PATCH] s2io LRO bugs
a) initiate_new_session() sets ->tcp_ack to ntohl(...); everything
else stores and expects to find there the net-endian value.
b) check for monotonic timestamps in verify_l3_l4_lro_capable()
compares the value sitting in TCP option (right there in the skb->data,
net-endian 32bit) with the value picked from earlier packet.
Doing that without ntohl() is an interesting idea and it might even
work occasionally; unfortunately, it's quite broken.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/net/s2io.c | 20 ++--
drivers/net/s2io.h |2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 9d80f1c..aef0875 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -7898,7 +7898,7 @@ static void initiate_new_session(struct lro *lro, u8 *l2h,
lro->iph = ip;
lro->tcph = tcp;
lro->tcp_next_seq = tcp_pyld_len + ntohl(tcp->seq);
- lro->tcp_ack = ntohl(tcp->ack_seq);
+ lro->tcp_ack = tcp->ack_seq;
lro->sg_num = 1;
lro->total_len = ntohs(ip->tot_len);
lro->frags_len = 0;
@@ -7907,10 +7907,10 @@ static void initiate_new_session(struct lro *lro, u8
*l2h,
* already been done.
*/
if (tcp->doff == 8) {
- u32 *ptr;
- ptr = (u32 *)(tcp+1);
+ __be32 *ptr;
+ ptr = (__be32 *)(tcp+1);
lro->saw_ts = 1;
- lro->cur_tsval = *(ptr+1);
+ lro->cur_tsval = ntohl(*(ptr+1));
lro->cur_tsecr = *(ptr+2);
}
lro->in_use = 1;
@@ -7936,7 +7936,7 @@ static void update_L3L4_header(struct s2io_nic *sp,
struct lro *lro)
/* Update tsecr field if this session has timestamps enabled */
if (lro->saw_ts) {
- u32 *ptr = (u32 *)(tcp + 1);
+ __be32 *ptr = (__be32 *)(tcp + 1);
*(ptr+2) = lro->cur_tsecr;
}
@@ -7961,10 +7961,10 @@ static void aggregate_new_rx(struct lro *lro, struct
iphdr *ip,
lro->window = tcp->window;
if (lro->saw_ts) {
- u32 *ptr;
+ __be32 *ptr;
/* Update tsecr and tsval from this packet */
- ptr = (u32 *) (tcp + 1);
- lro->cur_tsval = *(ptr + 1);
+ ptr = (__be32 *) (tcp + 1);
+ lro->cur_tsval = ntohl(*(ptr + 1));
lro->cur_tsecr = *(ptr + 2);
}
}
@@ -8015,11 +8015,11 @@ static int verify_l3_l4_lro_capable(struct lro *l_lro,
struct iphdr *ip,
/* Ensure timestamp value increases monotonically */
if (l_lro)
- if (l_lro->cur_tsval > *((u32 *)(ptr+2)))
+ if (l_lro->cur_tsval > ntohl(*((__be32 *)(ptr+2
return -1;
/* timestamp echo reply should be non-zero */
- if (*((u32 *)(ptr+6)) == 0)
+ if (*((__be32 *)(ptr+6)) == 0)
return -1;
}
diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h
index cc1797a..899d60c 100644
--- a/drivers/net/s2io.h
+++ b/drivers/net/s2io.h
@@ -797,7 +797,7 @@ struct lro {
int in_use;
__be16 window;
u32 cur_tsval;
- u32 cur_tsecr;
+ __be32 cur_tsecr;
u8 saw_ts;
};
--
1.5.3.GIT
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] via-velocity big-endian support
* killed multibyte bitfields in fixed-endian structs
* annotated
* added conversions where needed
* fixed a couple of obvious brainos in (ifdefed out) zerocopy
stuff
Note that it's absofsckinglutely untested. It should not give differences
in behaviour on l-e, but that's in the famous last words category...
Review and testing is welcome.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index 35cd65d..0fa1e4b 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -681,7 +681,7 @@ static void velocity_rx_reset(struct velocity_info *vptr)
* Init state, all RD entries belong to the NIC
*/
for (i = 0; i < vptr->options.numrx; ++i)
- vptr->rd_ring[i].rdesc0.owner = OWNED_BY_NIC;
+ vptr->rd_ring[i].rdesc0.len |= OWNED_BY_NIC;
writew(vptr->options.numrx, ®s->RBRDU);
writel(vptr->rd_pool_dma, ®s->RDBaseLo);
@@ -777,7 +777,7 @@ static void velocity_init_registers(struct velocity_info
*vptr,
vptr->int_mask = INT_MASK_DEF;
- writel(cpu_to_le32(vptr->rd_pool_dma), ®s->RDBaseLo);
+ writel(vptr->rd_pool_dma, ®s->RDBaseLo);
writew(vptr->options.numrx - 1, ®s->RDCSize);
mac_rx_queue_run(regs);
mac_rx_queue_wake(regs);
@@ -785,7 +785,7 @@ static void velocity_init_registers(struct velocity_info
*vptr,
writew(vptr->options.numtx - 1, ®s->TDCSize);
for (i = 0; i < vptr->num_txq; i++) {
- writel(cpu_to_le32(vptr->td_pool_dma[i]),
&(regs->TDBaseLo[i]));
+ writel(vptr->td_pool_dma[i], ®s->TDBaseLo[i]);
mac_tx_queue_run(regs, i);
}
@@ -1195,7 +1195,7 @@ static inline void velocity_give_many_rx_descs(struct
velocity_info *vptr)
dirty = vptr->rd_dirty - unusable;
for (avail = vptr->rd_filled & 0xfffc; avail; avail--) {
dirty = (dirty > 0) ? dirty - 1 : vptr->options.numrx - 1;
- vptr->rd_ring[dirty].rdesc0.owner = OWNED_BY_NIC;
+ vptr->rd_ring[dirty].rdesc0.len |= OWNED_BY_NIC;
}
writew(vptr->rd_filled & 0xfffc, ®s->RBRDU);
@@ -1210,7 +1210,7 @@ static int velocity_rx_refill(struct velocity_info *vptr)
struct rx_desc *rd = vptr->rd_ring + dirty;
/* Fine for an all zero Rx desc at init time as well */
- if (rd->rdesc0.owner == OWNED_BY_NIC)
+ if (rd->rdesc0.len & OWNED_BY_NIC)
break;
if (!vptr->rd_info[dirty].skb) {
@@ -1409,31 +1409,33 @@ static int velocity_rx_srv(struct velocity_info *vptr,
int status)
do {
struct rx_desc *rd = vptr->rd_ring + rd_curr;
+ u16 rsr;
if (!vptr->rd_info[rd_curr].skb)
break;
- if (rd->rdesc0.owner == OWNED_BY_NIC)
+ if (rd->rdesc0.len & OWNED_BY_NIC)
break;
rmb();
+ rsr = le16_to_cpu(rd->rdesc0.RSR);
/*
* Don't drop CE or RL error frame although RXOK is off
*/
- if ((rd->rdesc0.RSR & RSR_RXOK) || (!(rd->rdesc0.RSR &
RSR_RXOK) && (rd->rdesc0.RSR & (RSR_CE | RSR_RL {
+ if (rsr & (RSR_RXOK | RSR_CE | RSR_RL)) {
if (velocity_receive_frame(vptr, rd_curr) < 0)
stats->rx_dropped++;
} else {
- if (rd->rdesc0.RSR & RSR_CRC)
+ if (rsr & RSR_CRC)
stats->rx_crc_errors++;
- if (rd->rdesc0.RSR & RSR_FAE)
+ if (rsr & RSR_FAE)
stats->rx_frame_errors++;
stats->rx_dropped++;
}
- rd->inten = 1;
+ rd->size |= RX_INTEN;
vptr->dev->last_rx = jiffies;
@@ -1554,16 +1556,17 @@ static int velocity_receive_frame(struct velocity_info
*vptr, int idx)
struct net_device_stats *stats = &vptr->stats;
struct velocity_rd_info *rd_info = &(vptr->rd_info[idx]);
struct rx_desc *rd = &(vptr->rd_ring[idx]);
- int pkt_len = rd->rdesc0.len;
+ int pkt_len = le16_to_cpu(rd->rdesc0.len) & 0x3fff;
+ u16 rsr = le16_to_cpu(rd->rdesc0.RSR);
struct sk_buff *skb;
- if (rd->rdesc0.RSR & (RSR_STP | RSR_EDP)) {
+ if (rsr & (RSR_STP | RSR_EDP)) {
VELOCITY_PRT(MSG_LEVEL_VERBOSE, KERN_ERR " %s : the received
frame span multple RDs.\n", vptr->dev->name);
stats->rx_length_errors++;
return -EINVAL;
}
- if (rd->rdesc0.RSR & RSR_MAR)
+ if (rsr & RSR_MAR)
vptr
Re: [ETH]: Combine format_addr() with print_mac().
On Fri, 2007-12-21 at 23:02 -0800, Joe Perches wrote:
> On Fri, 2007-12-21 at 19:58 -0800, Michael Chan wrote:
> > > ssize_t? shouldn't it be size_t?
> > I'm just keeping the prototype unchanged as originally defined in net-
> > sysfs.c
>
> It's painless to change the prototype.
> size_t seems more sensible.
>
I'll change the internal function to use size_t, but the exported
function for sysfs use will be ssize_t since sysfs uses ssize_t.
Here's the revised patch:
[ETH]: Combine format_addr() with print_mac().
print_mac() used many most net drivers and format_addr() used by
net-sysfs.c are very similar and they can be intergrated.
format_addr() is also identically redefined in the qla4xxx iscsi
driver.
Export a new function sysfs_format_mac() to be used by net-sysfs,
qla4xxx and others in the future. Both print_mac() and
sysfs_format_mac() call _format_mac_addr() to do the formatting.
Changed print_mac() to use unsigned char * to be consistent with
net_device struct's dev_addr. Added buffer length overrun checking
as suggested by Joe Perches.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Cc: Joe Perches <[EMAIL PROTECTED]>
Cc: Mike Christie <[EMAIL PROTECTED]>
Cc: David Somayajulu <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index 89460d2..4e9cf18 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -173,18 +173,6 @@ static void qla4xxx_conn_stop(struct iscsi_cls_conn *conn,
int flag)
printk(KERN_ERR "iscsi: invalid stop flag %d\n", flag);
}
-static ssize_t format_addr(char *buf, const unsigned char *addr, int len)
-{
- int i;
- char *cp = buf;
-
- for (i = 0; i < len; i++)
- cp += sprintf(cp, "%02x%c", addr[i],
- i == (len - 1) ? '\n' : ':');
- return cp - buf;
-}
-
-
static int qla4xxx_host_get_param(struct Scsi_Host *shost,
enum iscsi_host_param param, char *buf)
{
@@ -193,7 +181,7 @@ static int qla4xxx_host_get_param(struct Scsi_Host *shost,
switch (param) {
case ISCSI_HOST_PARAM_HWADDRESS:
- len = format_addr(buf, ha->my_mac, MAC_ADDR_LEN);
+ len = sysfs_format_mac(buf, ha->my_mac, MAC_ADDR_LEN);
break;
case ISCSI_HOST_PARAM_IPADDRESS:
len = sprintf(buf, "%d.%d.%d.%d\n", ha->ip_address[0],
diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
index cc002cb..7a1e011 100644
--- a/include/linux/if_ether.h
+++ b/include/linux/if_ether.h
@@ -124,12 +124,14 @@ int eth_header_parse(const struct sk_buff *skb, unsigned
char *haddr);
extern struct ctl_table ether_table[];
#endif
+extern ssize_t sysfs_format_mac(char *buf, const unsigned char *addr, int len);
+
/*
* Display a 6 byte device address (MAC) in a readable format.
*/
-#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x"
-extern char *print_mac(char *buf, const u8 *addr);
-#define DECLARE_MAC_BUF(var) char var[18] __maybe_unused
+extern char *print_mac(char *buf, const unsigned char *addr);
+#define MAC_BUF_SIZE 18
+#define DECLARE_MAC_BUF(var) char var[MAC_BUF_SIZE] __maybe_unused
#endif
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index e41f4b9..7635d3f 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -95,17 +95,6 @@ NETDEVICE_SHOW(type, fmt_dec);
NETDEVICE_SHOW(link_mode, fmt_dec);
/* use same locking rules as GIFHWADDR ioctl's */
-static ssize_t format_addr(char *buf, const unsigned char *addr, int len)
-{
- int i;
- char *cp = buf;
-
- for (i = 0; i < len; i++)
- cp += sprintf(cp, "%02x%c", addr[i],
- i == (len - 1) ? '\n' : ':');
- return cp - buf;
-}
-
static ssize_t show_address(struct device *dev, struct device_attribute *attr,
char *buf)
{
@@ -114,7 +103,7 @@ static ssize_t show_address(struct device *dev, struct
device_attribute *attr,
read_lock(&dev_base_lock);
if (dev_isalive(net))
- ret = format_addr(buf, net->dev_addr, net->addr_len);
+ ret = sysfs_format_mac(buf, net->dev_addr, net->addr_len);
read_unlock(&dev_base_lock);
return ret;
}
@@ -124,7 +113,7 @@ static ssize_t show_broadcast(struct device *dev,
{
struct net_device *net = to_net_dev(dev);
if (dev_isalive(net))
- return format_addr(buf, net->broadcast, net->addr_len);
+ return sysfs_format_mac(buf, net->broadcast, net->addr_len);
return -EINVAL;
}
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 6b2e454..a7b4175 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -359,10 +359,34 @@ struct net_device *alloc_etherdev_mq(int sizeof_priv,
unsigned int queue_count)
}
EXPORT_SYMBOL(alloc_etherdev_mq);
-char *print_mac(char *buf, const u8 *addr)
+static size_t _format_mac_addr(char *buf, int buflen,
+
[RFC] potential bugs in nexten
* what are default: doing in netxen_nic_hw_write_wx()/netxen_nic_hw_read_wx()? Unlike all other cases they do iomem->iomem copying and AFAICS they are never actually triggered. * netxen_nic_flash_print() reads the entire user_info from card *in* *host-endian*, then uses user_info.serial_number[]. a) do we need to read the rest? b) more interesting question, don't we need cpu_to_le32() here? After all, that sucker is an array of char, so we want it in the same order regardless of the host... * in netxen_nic_xmit_frame() we do hw->cmd_desc_head[saved_producer].flags_opcode = cpu_to_le16(hw->cmd_desc_head[saved_producer].flags_opcode); hw->cmd_desc_head[saved_producer].num_of_buffers_total_length = cpu_to_le32(hw->cmd_desc_head[saved_producer]. num_of_buffers_total_length); Huh? Everything that modifies either of those does so in little-endian already. This code appeared in commit 6c80b18df3537d1221ab34555c150bccbfd90260 (NetXen: Port swap feature for multi port cards); what's going on there? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] potential bug in cxgb3
int t3_seeprom_wp(struct adapter *adapter, int enable)
{
return t3_seeprom_write(adapter, EEPROM_STAT_ADDR, enable ? 0xc : 0);
}
looks fishy, since t3_seeprom_write() takes the last argument in little-endian,
converts to host-endian and feeds it to pci_write_config_dword(). Passing it
a host-endian instead will end up with different values seen by the card on
l-e and b-e hosts. Shouldn't it be s/0xc/cpu_to_le32(0xc) ?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] netem: trace enhancement: kernel
This patch applies to kernel 2.6.23.
It enhances the network emulator netem with the possibility
to read all delay/drop/duplicate etc values from a trace file.
This trace file contains for each packet to be processed one value.
The values are read from the file in a user space process called
flowseed. These values are sent to the netem module with the help of
rtnetlink sockets.
In the netem module the values are "cached" in buffers.
The number of buffers is configurable upon start of netem.
If a buffer is empty the netem module sends a rtnetlink notification
to the flowseed process.
Upon receiving such a notification this process sends
the next 1000 values to the netem module.
signed-off-by: Ariane Keller <[EMAIL PROTECTED]>
---
diff -uprN -X linux-2.6.23.8/Documentation/dontdiff
linux-2.6.23.8/include/linux/pkt_sched.h
linux-2.6.23.8_mod/include/linux/pkt_sched.h
--- linux-2.6.23.8/include/linux/pkt_sched.h 2007-11-16
19:14:27.0 +0100
+++ linux-2.6.23.8_mod/include/linux/pkt_sched.h 2007-12-21
19:42:49.0 +0100
@@ -439,6 +439,9 @@ enum
TCA_NETEM_DELAY_DIST,
TCA_NETEM_REORDER,
TCA_NETEM_CORRUPT,
+ TCA_NETEM_TRACE,
+ TCA_NETEM_TRACE_DATA,
+ TCA_NETEM_STATS,
__TCA_NETEM_MAX,
};
@@ -454,6 +457,26 @@ struct tc_netem_qopt
__u32 jitter; /* random jitter in latency (us) */
};
+struct tc_netem_stats
+{
+ int packetcount;
+ int packetok;
+ int normaldelay;
+ int drops;
+ int dupl;
+ int corrupt;
+ int novaliddata;
+ int reloadbuffer;
+};
+
+struct tc_netem_trace
+{
+ __u32 fid; /*flowid */
+ __u32 def; /* default action 0 = no delay, 1 = drop*/
+ __u32 ticks; /* number of ticks corresponding to 1ms */
+ __u32 nr_bufs; /* number of buffers to save trace data*/
+};
+
struct tc_netem_corr
{
__u32 delay_corr; /* delay correlation */
diff -uprN -X linux-2.6.23.8/Documentation/dontdiff
linux-2.6.23.8/include/net/flowseed.h
linux-2.6.23.8_mod/include/net/flowseed.h
--- linux-2.6.23.8/include/net/flowseed.h 1970-01-01 01:00:00.0
+0100
+++ linux-2.6.23.8_mod/include/net/flowseed.h 2007-12-21
19:43:24.0 +0100
@@ -0,0 +1,34 @@
+/* flowseed.h header file for the netem trace enhancement
+ */
+
+#ifndef _FLOWSEED_H
+#define _FLOWSEED_H
+#include
+
+/* must be divisible by 4 (=#pkts)*/
+#define DATA_PACKAGE 4000
+#define DATA_PACKAGE_ID 4008
+
+/* struct per flow - kernel */
+struct tcn_control
+{
+ struct list_head full_buffer_list;
+ struct list_head empty_buffer_list;
+ struct buflist * buffer_in_use;
+ int *offsetpos; /* pointer to actual pos in the buffer in use */
+ int flowid;
+};
+
+struct tcn_statistic
+{
+ int packetcount;
+ int packetok;
+ int normaldelay;
+ int drops;
+ int dupl;
+ int corrupt;
+ int novaliddata;
+ int reloadbuffer;
+};
+
+#endif
diff -uprN -X linux-2.6.23.8/Documentation/dontdiff
linux-2.6.23.8/include/net/pkt_sched.h
linux-2.6.23.8_mod/include/net/pkt_sched.h
--- linux-2.6.23.8/include/net/pkt_sched.h 2007-11-16 19:14:27.0
+0100
+++ linux-2.6.23.8_mod/include/net/pkt_sched.h 2007-12-21
19:42:49.0 +0100
@@ -72,6 +72,9 @@ extern void qdisc_watchdog_cancel(struct
extern struct Qdisc_ops pfifo_qdisc_ops;
extern struct Qdisc_ops bfifo_qdisc_ops;
+extern int qdisc_notify_pid(int pid, struct nlmsghdr *n, u32 clid,
+ struct Qdisc *old, struct Qdisc *new);
+
extern int register_qdisc(struct Qdisc_ops *qops);
extern int unregister_qdisc(struct Qdisc_ops *qops);
extern struct Qdisc *qdisc_lookup(struct net_device *dev, u32 handle);
diff -uprN -X linux-2.6.23.8/Documentation/dontdiff
linux-2.6.23.8/net/core/rtnetlink.c linux-2.6.23.8_mod/net/core/rtnetlink.c
--- linux-2.6.23.8/net/core/rtnetlink.c 2007-11-16 19:14:27.0 +0100
+++ linux-2.6.23.8_mod/net/core/rtnetlink.c 2007-12-21
19:42:49.0 +0100
@@ -460,7 +460,7 @@ int rtnetlink_send(struct sk_buff *skb,
NETLINK_CB(skb).dst_group = group;
if (echo)
atomic_inc(&skb->users);
- netlink_broadcast(rtnl, skb, pid, group, GFP_KERNEL);
+ netlink_broadcast(rtnl, skb, pid, group, gfp_any());
if (echo)
err = netlink_unicast(rtnl, skb, pid, MSG_DONTWAIT);
return err;
diff -uprN -X linux-2.6.23.8/Documentation/dontdiff
linux-2.6.23.8/net/sched/sch_api.c linux-2.6.23.8_mod/net/sched/sch_api.c
--- linux-2.6.23.8/net/sched/sch_api.c 2007-11-16 19:14:27.0 +0100
+++ linux-2.6.23.8_mod/net/sched/sch_api.c 2007-12-21 19:42:49.0
+0100
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -841,6 +842,62 @@ rtattr_failure:
nlmsg_trim(skb, b);
return -1;
}
+static int tc_fill(struct sk_buff *skb, struct Qdisc *q, u32 clid,
+
Re: [PATCH 0/2] netem: trace enhancement: iproute
The iproute patch is to big to send on the mailing list,
since the distribution data have changed the directory.
For ease of discussion I add the important changes in this mail.
signed-of-by: Ariane Keller <[EMAIL PROTECTED]
---
diff -uprN iproute2-2.6.23/netem/trace/flowseed.c
iproute2-2.6.23_buf/netem/trace/flowseed.c
--- iproute2-2.6.23/netem/trace/flowseed.c 1970-01-01 01:00:00.0
+0100
+++ iproute2-2.6.23_buf/netem/trace/flowseed.c 2007-12-12
08:43:01.0 +0100
@@ -0,0 +1,209 @@
+/* flowseed.cflowseedprocess to deliver values for packet delay,
+ * duplication, loss and curruption form userspace to netem
+ *
+ * This program is free software; you can redistribute it
and/or
+ * modify it under the terms of the GNU General Public
License
+ * as published by the Free Software Foundation; either
version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Ariane Keller <[EMAIL PROTECTED]> ETH Zurich
+ * Rainer Baumann <[EMAIL PROTECTED]> ETH Zurich
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "utils.h"
+#include "linux/pkt_sched.h"
+
+#define DATA_PACKAGE 4000
+#define DATA_PACKAGE_ID DATA_PACKAGE + sizeof(unsigned int) + sizeof(int)
+#define TCA_BUF_MAX (64*1024)
+/* maximal amount of parallel flows */
+struct rtnl_handle rth;
+unsigned int loop;
+int infinity = 0;
+int fdflowseed;
+char *sendpkg;
+int fid;
+int initialized = 0;
+int semid;
+int moreData = 1, r = 0, rold = 0;
+FILE * file;
+
+
+int printfct(const struct sockaddr_nl *who,
+ struct nlmsghdr *n,
+ void *arg)
+{
+ struct {
+ struct nlmsghdr n;
+ struct tcmsgt;
+ charbuf[TCA_BUF_MAX];
+ } req;
+ struct tcmsg *t = NLMSG_DATA(n);
+ struct rtattr *tail = NULL;
+ struct tc_netem_qopt opt;
+ memset(&opt, 0, sizeof(opt));
+
+ if(n->nlmsg_type == RTM_DELQDISC) {
+ goto outerr;
+ }
+ else if(n->nlmsg_type == RTM_NEWQDISC){
+ initialized = 1;
+
+ memset(&req, 0, sizeof(req));
+ req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcmsg));
+ req.n.nlmsg_flags = NLM_F_REQUEST;
+ req.n.nlmsg_type = RTM_NEWQDISC;
+ req.t.tcm_family = AF_UNSPEC;
+ req.t.tcm_handle = t->tcm_handle;
+ req.t.tcm_parent = t->tcm_parent;
+ req.t.tcm_ifindex = t->tcm_ifindex;
+
+ tail = NLMSG_TAIL(&req.n);
+again:
+ if (loop <= 0 && !infinity){
+ goto out;
+ }
+ if ((r = read(fdflowseed, sendpkg + rold, DATA_PACKAGE - rold))
>= 0) {
+ if (r + rold < DATA_PACKAGE) {
+ /* Tail of input file reached,
+ set rest at start from next iteration */
+ rold = r;
+ fprintf(file, "flowseed: at end of file.\n");
+
+ if (lseek(fdflowseed, 0L, SEEK_SET) < 0){
+ perror("lseek reset");
+ goto out;
+ }
+ goto again;
+ }
+ r = 0;
+ rold = 0;
+ memcpy(sendpkg + DATA_PACKAGE, &fid, sizeof(int));
+ memcpy(sendpkg + DATA_PACKAGE + sizeof(int), &moreData,
sizeof(int));
+
+ /* opt has to be added for each netem request */
+ if (addattr_l(&req.n, TCA_BUF_MAX, TCA_OPTIONS, &opt,
sizeof(opt)) < 0){
+ perror("add options");
+ return -1;
+ }
+
+ if(addattr_l(&req.n, TCA_BUF_MAX, TCA_NETEM_TRACE_DATA, sendpkg,
DATA_PACKAGE_ID) < 0){
+ perror("add data\n");
+ return -1;
+ }
+
+ tail->rta_len = (void *)NLMSG_TAIL(&req.n) - (void
*)tail;
+
+ if(rtnl_send(&rth, (char*)&req, req.n.nlmsg_len) < 0){
+ perror("send data");
+ return -1;
+ }
+ return 0;
+ }
+ }
+/* no more data, what to do? we send a notification to the kernel module */
+out:
+ fprintf(stderr, "flowseed: Tail of input file reached. Exit.\n");
+ fprintf(file, "flowseed: Tail of input file reached. Exit.\n");
+ moreData = 0;
+ memcpy(sendpkg + DATA_PACKAGE, &fid, sizeof(int));
+ memcpy(sendpkg + DATA_PACKAGE + sizeof
Re: [PATCH 0/2] netem: trace enhancement
I have added the possibility to configure the number of buffers used to store the trace data for packet delays. The complete command to start netem with a trace file is: tc qdisc add dev eth1 root netem trace path/to/trace/file.bin buf 3 loops 1 0 with buf: the number of buffers to be used loops: how many times to loop through the tracefile the last argument is optional and specifies whether the default is to drop packets or 0-delay them. The patches are available at: http://www.tcn.hypert.net/tcn_kernel_2_6_23_confbuf http://www.tcn.hypert.net/tcn_iproute2_2_6_23_confbuf I'm looking forward for your comments! Thanks! Ariane Ben Greear wrote: Ariane Keller wrote: Yes, for short-term starvation it helps certainly. But I'm still not convinced that it is really necessary to add more buffers, because I'm not sure whether the bottleneck is really the loading of data from user space to kernel space. Some basic tests have shown that the kernel starts loosing packets at approximately the same packet rate regardless whether we use netem, or netem with the trace extension. But if you have contrary experience I'm happy to add a parameter which defines the number of buffers. I have no numbers, so if you think it works, then that is fine with me. If you actually run out of the trace buffers, do you just continue to run with the last settings? If so, that would keep up throughput even if you are out of trace buffers... What rates do you see, btw? (pps, bps). Thanks, Ben -- Ariane Keller Communication Systems Research Group, ETH Zurich Web: http://www.csg.ethz.ch/people/arkeller Office: ETZ G 60.1, Gloriastrasse 35, 8092 Zurich -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ipv4_devconf.arp_accept mystery
Hello, I have a question regarding unsolicited ARPs in ipv4/arp.c As I understand, by default this feature is disabled; How can one set this feature ? When working with ipv4_devconf.arp_accept is 0 by default. This is with 2.6.21 kernel. I wanted ipv4_devconf.arp_accept to be set to 1. I added: net.ipv4.conf.default.arp_accept = 1 net.ipv4.conf.eth0.arp_accept = 1 in /etc/sysctl.conf and rebooted. I have: cat /proc/sys/net/ipv4/conf/default/arp_accept => 1 cat /proc/sys/net/ipv4/conf/eth0/arp_accept =>1 Yet ,the printk() I added shows that ipv4_devconf.arp_accept shows 0 !! Could it be that this variable could not be set ? or is it dependent upon other things ? BTW, in newer kernel version we have IPV4_DEVCONF_ALL(ARP_ACCEPT) instead. So if anybody knows how to set this macro (instead)to be 1, it will be also fine. Ian -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
David Shwatrz <[EMAIL PROTECTED]> wrote:
>
> Hi,
> Oop, I am TWICE sorry ! I wrongly attached a wrong, empty file.
> Attached here is the patch.
>
> Regarding your answer; I accept it and I will soon send a revised
> version of this patch (making changes to
> arp_netdev_event() and ndisc_netdev_event().)
> I had IPv4 in mind, there is no reason that it will no be also in IPv6.
Hmm, why can't you do this from user-space?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6] [NEIGH] [resend] Updating affected neighbours when about MAC address change in arp_netdev_event()
Hello,
This is a resend of the patch according to Yoshifuji comment. I will
send a patch for IPv6 later.
We know that changes in MAC addresses are not frequent but
we are working on a special, highly advanced networking Linux based project
in our LABs, where we do change MAC addresses of an interface quite frequently.
(We do not go totally wild; the MAC addresses we are changing into are
from a set of given MAC addresses).
Normally, when we change a MAC address of some interface, the
relevant neighbours in the LAN which have entries with the previous MAC
address are not sent any update notification; instead, it is there
regular timers mechanisms which update the MAC address to the new
one in their ARP tables.
I had written a small patch to neigh_changeaddr() in net/ipv4/arp.c
against the 2.6 git net tree, which sends a gratuitous ARP to update
the list of
all the involved neighbours with the change of MAC address.
The patch is for arp_netdev_event() only.
This patch was tested and it does work in my LAB; if such a patch is
not needed,
I wonder why ?
It seems to me that it could not cause any troubles.
BTW, I had noticed that in irlan driver, there is such a mechanism
of sending a gratuitous ARP to update all the
neighbours when a MAC address is changed.
Signed-off-by: David Shwartz <[EMAIL PROTECTED]>
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 08174a2..7b1162b 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -1185,6 +1185,8 @@ out:
static int arp_netdev_event(struct notifier_block *this, unsigned long event,
void *ptr)
{
+ struct in_device *in_dev;
+ struct in_ifaddr *ifa;
struct net_device *dev = ptr;
if (dev->nd_net != &init_net)
@@ -1194,6 +1196,22 @@ static int arp_netdev_event(struct notifier_block *this,
unsigned long event, vo
case NETDEV_CHANGEADDR:
neigh_changeaddr(&arp_tbl, dev);
rt_cache_flush(0);
+
+ /* Send gratuitous ARP to the neighbours to update their arp
tables */
+
+ rcu_read_lock();
+ in_dev = __in_dev_get_rcu(dev);
+ if (in_dev == NULL)
+ goto out;
+ for (ifa = in_dev->ifa_list; ifa; ifa = ifa->ifa_next)
+ arp_send(ARPOP_REQUEST, ETH_P_ARP,
+ ifa->ifa_address,
+ dev,
+ ifa->ifa_address,
+ NULL, dev->dev_addr, NULL);
+out:
+ rcu_read_unlock();
+
break;
default:
break;
Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
Yoshfuji, Thanks, you are right ! soon I will send the patches. Thanks ! DS On Dec 23, 2007 3:13 PM, YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]> (at Sun, 23 Dec 2007 15:04:37 +0200), "David > Shwatrz" <[EMAIL PROTECTED]> says: > > > Hello, > > > > > > >You should iterate all of ifa_list (for IPv4) / addr_list (for IPv6). > > > For IPv6, we also have anycast (maintained by ac_list) as well. > > > > I am not sure that we need to iterate all of ifa_list in IPv4. > > The reason is that we end with arp_send, and it initiates a broadcast. > > So all neighbours will receive it and update their arp tables > > accordingly. > > The dest hw in the arp_send is NULL according to this patch ; this means > > that > > we will assign dev->broadcast to dest_hw in apr_create(). > > > > It seems to me there's no reason to send more than one broadcast. > > Urgh? what is happend if you have multiple IPv4 addresses on the device? > > > > In IPv6, I need to check, since it is multicast. > > Please read RFC2461 Section 7.2.6. In short we should send a few > unsolicited NA, but I think you can start from sending once per an > address. > > --yoshfuji > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
On Sun, 2007-23-12 at 22:04 +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: > If the secondary MACs are used with ARP/NDP, we should take care of > that, but I think we use the primary MAC for ARP/NDP, no? > (In other words, we always use primary MAC for ARP reply / NA, no?) I think it maybe a policy decision; In the IPV4 case, where the system owns the IP addresses for the classical scenario where there is a single MAC address per ethx then we always respond with MAC address of ethx wherever the arp request was received from. I think it is different in the case of IPV6 where the eth device owns the IP address, no? i.e is that where you are drawing the concept of primary MAC? The case of multiple MACs per interface requires further policy resolution IMO. It would be nice to be able to tell the kernel which MAC to use when responding for which ip address it owns. This can be then easily mapped to the routing table src address selection. Patrick? cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
In article <[EMAIL PROTECTED]> (at Sun, 23 Dec 2007 15:04:37 +0200), "David Shwatrz" <[EMAIL PROTECTED]> says: > Hello, > > > >You should iterate all of ifa_list (for IPv4) / addr_list (for IPv6). > > For IPv6, we also have anycast (maintained by ac_list) as well. > > I am not sure that we need to iterate all of ifa_list in IPv4. > The reason is that we end with arp_send, and it initiates a broadcast. > So all neighbours will receive it and update their arp tables > accordingly. > The dest hw in the arp_send is NULL according to this patch ; this means that > we will assign dev->broadcast to dest_hw in apr_create(). > > It seems to me there's no reason to send more than one broadcast. Urgh? what is happend if you have multiple IPv4 addresses on the device? > In IPv6, I need to check, since it is multicast. Please read RFC2461 Section 7.2.6. In short we should send a few unsolicited NA, but I think you can start from sending once per an address. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ip xfrm bug
On Sun, 2007-16-12 at 15:43 +0800, Herbert Xu wrote:
> Jamal's going to hate me but setkey(8) already uses this so we're
> stuck with it anyway.
>
> The test is
>
> up->index % 8 >= 3
>
> This is true iff it's a socket policy.
I would have loved it if user space had a say ;->
In the case of tc actions for example; the (table) index abides to the
following rules:
if user space specified one in rule insertion then {
if available, use the allowed entry {
} else if inuse {
if replace flag is set then {
replace
} else {
return error
}
} else {
grab the next available index
}
makes management from user space much simpler.
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
In article <[EMAIL PROTECTED]> (at Sun, 23 Dec 2007 07:46:15 -0500), jamal <[EMAIL PROTECTED]> says: > On Sun, 2007-23-12 at 21:38 +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: > > In article <[EMAIL PROTECTED]> (at Sun, 23 Dec 2007 14:24:00 +0200), "David > > Shwatrz" <[EMAIL PROTECTED]> says: > > > > > Regarding your answer; I accept it and I will soon send a revised > > > version of this patch (making changes to > > > arp_netdev_event() and ndisc_netdev_event().) > > > I had IPv4 in mind, there is no reason that it will no be also in IPv6. > > > > You should iterate all of ifa_list (for IPv4) / addr_list (for IPv6). > > For IPv6, we also have anycast (maintained by ac_list) as well. > > > > Hrm, how is this going to work for the case of multiple MACs on a > device? > Changing one MAC address doesnt equate to issuing a grat arp with _the > new MAC_ for all ifa (given each MAC may be map to a different ifa) If the secondary MACs are used with ARP/NDP, we should take care of that, but I think we use the primary MAC for ARP/NDP, no? (In other words, we always use primary MAC for ARP reply / NA, no?) --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
Hello, >You should iterate all of ifa_list (for IPv4) / addr_list (for IPv6). > For IPv6, we also have anycast (maintained by ac_list) as well. I am not sure that we need to iterate all of ifa_list in IPv4. The reason is that we end with arp_send, and it initiates a broadcast. So all neighbours will receive it and update their arp tables accordingly. The dest hw in the arp_send is NULL according to this patch ; this means that we will assign dev->broadcast to dest_hw in apr_create(). It seems to me there's no reason to send more than one broadcast. In IPv6, I need to check, since it is multicast. Thoughts ? Regards, DS On Dec 23, 2007 2:38 PM, YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]> (at Sun, 23 Dec 2007 14:24:00 +0200), "David > Shwatrz" <[EMAIL PROTECTED]> says: > > > Regarding your answer; I accept it and I will soon send a revised > > version of this patch (making changes to > > arp_netdev_event() and ndisc_netdev_event().) > > I had IPv4 in mind, there is no reason that it will no be also in IPv6. > > You should iterate all of ifa_list (for IPv4) / addr_list (for IPv6). > For IPv6, we also have anycast (maintained by ac_list) as well. > > --yoshfuji > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
On Sun, 2007-23-12 at 21:38 +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: > In article <[EMAIL PROTECTED]> (at Sun, 23 Dec 2007 14:24:00 +0200), "David > Shwatrz" <[EMAIL PROTECTED]> says: > > > Regarding your answer; I accept it and I will soon send a revised > > version of this patch (making changes to > > arp_netdev_event() and ndisc_netdev_event().) > > I had IPv4 in mind, there is no reason that it will no be also in IPv6. > > You should iterate all of ifa_list (for IPv4) / addr_list (for IPv6). > For IPv6, we also have anycast (maintained by ac_list) as well. > Hrm, how is this going to work for the case of multiple MACs on a device? Changing one MAC address doesnt equate to issuing a grat arp with _the new MAC_ for all ifa (given each MAC may be map to a different ifa) cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
In article <[EMAIL PROTECTED]> (at Sun, 23 Dec 2007 14:24:00 +0200), "David Shwatrz" <[EMAIL PROTECTED]> says: > Regarding your answer; I accept it and I will soon send a revised > version of this patch (making changes to > arp_netdev_event() and ndisc_netdev_event().) > I had IPv4 in mind, there is no reason that it will no be also in IPv6. You should iterate all of ifa_list (for IPv4) / addr_list (for IPv6). For IPv6, we also have anycast (maintained by ac_list) as well. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
Hi,
Oop, I am TWICE sorry ! I wrongly attached a wrong, empty file.
Attached here is the patch.
Regarding your answer; I accept it and I will soon send a revised
version of this patch (making changes to
arp_netdev_event() and ndisc_netdev_event().)
I had IPv4 in mind, there is no reason that it will no be also in IPv6.
Regads,
David Shwatrz
On Dec 23, 2007 2:11 PM, YOSHIFUJI Hideaki / 吉藤英明
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> (at Sun, 23 Dec 2007 13:41:36 +0200), "David
> Shwatrz" <[EMAIL PROTECTED]> says:
>
> > I had written a small patch to neigh_changeaddr() in net/core/neighbour.c
> > against the 2.6 git net tree, which sends a gratuitous ARP to update
> > the list of
> > all the involved neighbours with the change of MAC address.
> > The patch is for neigh_changeaddr() only.
>
> Though I can see no patch, but I disagree. ;-)
> I do think you should change arp_netdev_event() and ndisc_netdev_event().
>
> --yoshfuji
>
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 29b8ee4..ddeae82 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -36,6 +36,9 @@
#include
#include
+#include
+#include
+
#define NEIGH_DEBUG 1
#define NEIGH_PRINTK(x...) printk(x)
@@ -228,9 +231,26 @@ static void neigh_flush_dev(struct neigh_table *tbl,
struct net_device *dev)
void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev)
{
+ struct in_device *in_dev;
write_lock_bh(&tbl->lock);
neigh_flush_dev(tbl, dev);
write_unlock_bh(&tbl->lock);
+
+ /* Send a gratuitous ARP to the neighbours to update their arp tables */
+
+ rcu_read_lock();
+ in_dev = __in_dev_get_rcu(dev);
+ if (in_dev == NULL)
+ goto out;
+ if (in_dev->ifa_list)
+
+ arp_send(ARPOP_REQUEST, ETH_P_ARP,
+in_dev->ifa_list->ifa_address,
+dev,
+in_dev->ifa_list->ifa_address,
+NULL, dev->dev_addr, NULL);
+out:
+ rcu_read_unlock();
}
int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev)
Re: [PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
In article <[EMAIL PROTECTED]> (at Sun, 23 Dec 2007 13:41:36 +0200), "David Shwatrz" <[EMAIL PROTECTED]> says: > I had written a small patch to neigh_changeaddr() in net/core/neighbour.c > against the 2.6 git net tree, which sends a gratuitous ARP to update > the list of > all the involved neighbours with the change of MAC address. > The patch is for neigh_changeaddr() only. Though I can see no patch, but I disagree. ;-) I do think you should change arp_netdev_event() and ndisc_netdev_event(). --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6][NEIGH] Updating affected neighbours when about MAC address change
Hello, Attached here is the patch - please read the following text here below: We know that changes in MAC addresses are not frequent but we are working on a special, highly advanced networking Linux based project in our LABs, where we do change MAC addresses of an interface quite frequently. (We do not go totally wild; the MAC addresses we are changing into are from a set of given MAC addresses). Normally, when we change a MAC address of some interface, the relevant neighbours in the LAN which have entries with the previous MAC address are not sent any update notification; instead, it is there regular timers mechanisms which update the MAC address to the new one in their ARP tables. I had written a small patch to neigh_changeaddr() in net/core/neighbour.c against the 2.6 git net tree, which sends a gratuitous ARP to update the list of all the involved neighbours with the change of MAC address. The patch is for neigh_changeaddr() only. This patch was tested and it does work in my LAB; if such a patch is not needed, I wonder why ? It seems to me that it could not cause any troubles. BTW, I had noticed that in irlan driver, there is such a mechanism of sending a gratuitous ARP to update all the neighbours when a MAC address is changed. Signed-off-by: David Shwatrz <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6][NEIGH] Updating affected neighbours about MAC address change
Hello, We know that changes in MAC addresses are not frequent but we are working on a special, highly advanced networking Linux based project in our LABs, where we do change MAC addresses of an interface quite frequently. (We do not go totally wild; the MAC addresses we are changing into are from a set of given MAC addresses). Normally, when we change a MAC address of some interface, the relevant neighbours in the LAN which have entries with the previous MAC address are not sent any update notification; instead, it is there regular timers mechanisms which update the MAC address to the new one in their ARP tables. I had written a small patch to neigh_changeaddr() in net/core/neighbour.c against the 2.6 git net tree, which sends a gratuitous ARP to update the list of all the involved neighbours with the change of MAC address. The patch is for neigh_changeaddr() only. This patch was tested and it does work in my LAB; if such a patch is not needed, I wonder why ? It seems to me that it could not cause any troubles. BTW, I had noticed that in irlan driver, there is such a mechanism of sending a gratuitous ARP to update all the neighbours when a MAC address is changed. Signed-off-by: David Shwatrz <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
