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
* 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
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 mor
* 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[]
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
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
flows
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
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
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:
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_
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 inte
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,
> >
> >
> > >
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 deci
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 nee
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 cas
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:
> >
>
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-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
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, th
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
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 neighb
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.
(W
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
23 matches
Mail list logo
