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
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.
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
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
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
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
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
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
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
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
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
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
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
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().)
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
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
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
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
* 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
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
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
* 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
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
23 matches
Mail list logo
