Hans Schillstrom | 1 Dec 01:25 2011

Re: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark

On Wednesday, November 30, 2011 16:51:35 Patrick McHardy wrote:
> On 11/25/2011 10:36 AM, Hans Schillstrom wrote:
> > +__u32 hmark_v6(struct sk_buff *skb, const struct xt_action_param *par)
> > +{
> > +	struct xt_hmark_info *info = (struct xt_hmark_info *)par->targinfo;
> > +	int nhoff, poff, hdrlen;
> > +	u32 addr1, addr2, hash;
> > +	struct ipv6hdr *ip6;
> > +	u8 nexthdr;
> > +	int frag = 0, ip6hdrlvl = 0;	/* Header level */
> > +	struct ipv6_opt_hdr _hdr, *hp;
> > +	union {
> > +		u32 v32;
> > +		u16 v16[2];
> > +	} ports;
> > +
> > +	ports.v32 = 0;
> > +	nhoff = skb_network_offset(skb);
> > +
> > +hdr_new:
> > +	/* Get header info */
> > +	ip6 = (struct ipv6hdr *) (skb->data + nhoff);
> > +	nexthdr = ip6->nexthdr;
> > +	hdrlen = sizeof(struct ipv6hdr);
> > +	hp = skb_header_pointer(skb, nhoff + hdrlen, sizeof(_hdr),&_hdr);
> > +
> > +	while (nexthdr) {
> > +		switch (nexthdr) {
> > +		case IPPROTO_ICMPV6:
> > +			/* ICMP Error then move ptr to inner header */
(Continue reading)

Hans Schillstrom | 1 Dec 01:52 2011

Re: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark


On Wednesday, November 30, 2011 19:28:15 Pablo Neira Ayuso wrote:
> On Wed, Nov 30, 2011 at 04:27:26PM +0100, Patrick McHardy wrote:
> > On 11/28/2011 10:36 AM, Hans Schillstrom wrote:
> > >>If you don't want to use conntrack in your setup and you want to handle
> > >>fragments, then you have to configure HMARK to calculate the hashing
> > >>based on the network addresses. If you want to fully support fragments,
> > >>then enable conntrack and you can configure HMARK to calculate the
> > >>hashing based on network address + transport bits.
> > >>
> > >>Fix this by removing the fragmentation handling, then assume that
> > >>people can select between two hashing configuration for HMARK. One
> > >>based for network address which is fragment-safe, one that uses the
> > >>transport layer information, that requires conntrack. Otherwise, I
> > >>don't see a sane way to handle this situation.
> > >Correct me if I'm wrong here,
> > >If conntrack is enabled hmark don't see the packet until it is reassembled and
> > >in that case the fragmentation header is removed.
> > >
> > >So, with conntrack HMARK will operate on full packets not fragments
> > >without conntrack ports will not be used on any fragment
> > 
> > Correct.
> 
> To complete what Patrick said. They are collected but not linearized.
> That's why you have to use skb_header_pointer.
OK, thanks
I'll will do that.

> 
(Continue reading)

Tom Herbert | 1 Dec 02:04 2011
Picon

Re: [PATCH v4 06/10] e1000e: Support for byte queue limits

> whats wrong with using total_tx_bytes or buffer_info->bytecount?  it
> contains the "bytes on the wire" value which will be slightly larger
> than skb->len, but avoids warming the skb->len cacheline unnecessarily.
>

This makes sense.  I made the changes, but the limits computed are
much higher than with using sbk->len.  I suspect there may be a bug in
GSO path.

For instance, in the driver at:

  bytecount = ((segs - 1) * skb_headlen(skb)) + skb->len;

I see cases like:

  segs=34, skb_header_len(skb)=70, skb->len=49298 so bytecount=51608

Which seems reasonable... but, I also see things like:

  segs=45, skb_header_len(skb)=1522, skb->len=65226, so bytecount= 132194
                                                      ^^^^
Which doesn't seem right at all.  I am thinking there may be a bug
setting skb->data_len improperly.

Tom
Maciej Żenczykowski | 1 Dec 02:18 2011
Picon

[PATCH] netconsole: implement ipv4 tos support

From: Maciej Żenczykowski <maze <at> google.com>

Signed-off-by: Maciej Żenczykowski <maze <at> google.com>
---
 Documentation/networking/netconsole.txt |    1 +
 drivers/net/netconsole.c                |   28 ++++++++++++++++++++++++++++
 include/linux/netpoll.h                 |    1 +
 net/core/netpoll.c                      |    4 +++-
 4 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt
index 8d02207..a02374f 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
 <at>  <at>  -94,6 +94,7  <at>  <at>  The interface exposes these parameters of a netconsole target to userspace:
 	remote_ip	Remote agent's IP address		(read-write)
 	local_mac	Local interface's MAC address		(read-only)
 	remote_mac	Remote agent's MAC address		(read-write)
+	tos		TOS byte value to utilize		(read-write)

 The "enabled" attribute is also used to control whether the parameters of
 a target can be updated or not -- you can modify the parameters of only
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index e888202..d24d5df 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
 <at>  <at>  -90,6 +90,7  <at>  <at>  static DEFINE_SPINLOCK(target_list_lock);
  *		remote_ip	(read-write)
  *		local_mac	(read-only)
  *		remote_mac	(read-write)
(Continue reading)

Stephen Hemminger | 1 Dec 02:34 2011

Re: [PATCH] netconsole: implement ipv4 tos support

On Wed, 30 Nov 2011 17:18:50 -0800
Maciej Żenczykowski <zenczykowski <at> gmail.com> wrote:

> From: Maciej Żenczykowski <maze <at> google.com>
> 
> Signed-off-by: Maciej Żenczykowski <maze <at> google.com>

Why make it an option? TOS should always be set to interactive
traffic (like telnet and slogin)

Tom Herbert | 1 Dec 02:48 2011
Picon

Bug in computing data_len in tcp_sendmsg?

I believe that skb->data_len might no be computed correctly in
tcp_sendmsg.  Specifically, when skb_add_data_nocache (or
skb_add_data) is called skb->data_len is not updated (skb_put only
updates skb->len).  This results in the datalen in the head skbuf
being zero so any subsequent uses of the value lead to incorrect
results.  For instance, skb_headlen returns the length of the head
skbu data and not just that of the headers.  If I'm reading this
correctly, it's a pretty fundamental bug.

I don't have a fix for this yet.

Tom
Maciej Żenczykowski | 1 Dec 03:11 2011
Picon

Re: [PATCH] netconsole: implement ipv4 tos support

> Why make it an option? TOS should always be set to interactive
> traffic (like telnet and slogin)

Because 'interactive' doesn't mean anything.  You don't know what
value of tos defines 'interactive' traffic on my network.
I may also consider network console/debug/dump/etc traffic less
important then say serving web traffic, and thus not even want it to
be considered 'interactive' in the first place.

TOS values are relevant within a LAN/WAN/Organization/AS, but are not
relevant internet-wide.
Almost all AS-boundary gateways/routers will do TOS remarking to their
own internal specifications.

- Maciej
Stephen Hemminger | 1 Dec 03:27 2011

Re: [PATCH] netconsole: implement ipv4 tos support

On Wed, 30 Nov 2011 18:11:32 -0800
Maciej Żenczykowski <zenczykowski <at> gmail.com> wrote:

> > Why make it an option? TOS should always be set to interactive
> > traffic (like telnet and slogin)
> 
> Because 'interactive' doesn't mean anything.  You don't know what
> value of tos defines 'interactive' traffic on my network.
> I may also consider network console/debug/dump/etc traffic less
> important then say serving web traffic, and thus not even want it to
> be considered 'interactive' in the first place.
> 
> TOS values are relevant within a LAN/WAN/Organization/AS, but are not
> relevant internet-wide.
> Almost all AS-boundary gateways/routers will do TOS remarking to their
> own internal specifications.
> 
> - Maciej

Giving the user choice in general is good, but network configuration
is already confusing enough.

Although interpretation of TOS is per organization, in practice the
values are standardized in places like RFC4594. For example, routing protocols
all use IPTOS_PREC_INTERNETCONTROL = 0xc0

Li Wei | 1 Dec 03:30 2011

Re: Is there any necessary to add multicast route for a loopback device?

Hi David,

what's your opinion?

> Hi all,
> 
> I found that since Fedora 15, it use systemd as the 'init'. When systemd start 
> it would config the ipv6 address(::1/128) for 'lo' and start it. While adding 
> this address to 'lo', kernel will call addrconf_add_mroute() to set a multicast
> route for 'lo' with rt->dst.error = -ENETUNREACH. After that, when I send multi-
> cast message, the route subsystem return a route with .error set to NETUNREACH.
> 
> Is there any necessary to add multicast route for a loopback device? 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

roy.qing.li | 1 Dec 03:37 2011
Picon

[PATCH] net/core: fix rollback handler in register_netdevice_notifier

From: RongQing.Li <roy.qing.li <at> gmail.com>

Within nested statements, the break statement terminates only the
do, for, switch, or while statement that immediately encloses it,
So replace the break with goto.

Signed-off-by: RongQing.Li <roy.qing.li <at> gmail.com>
---
 net/core/dev.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 278463e..88876fa 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
 <at>  <at>  -1387,7 +1387,7  <at>  <at>  rollback:
 	for_each_net(net) {
 		for_each_netdev(net, dev) {
 			if (dev == last)
-				break;
+				goto outroll;

 			if (dev->flags & IFF_UP) {
 				nb->notifier_call(nb, NETDEV_GOING_DOWN, dev);
 <at>  <at>  -1398,6 +1398,7  <at>  <at>  rollback:
 		}
 	}

+outroll:
 	raw_notifier_chain_unregister(&netdev_chain, nb);
(Continue reading)


Gmane