Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH 2/6] xen-netfront: reduce gso_max_size to account for ethernet header
From: Ben Hutchings @ 2013-03-25 20:49 UTC (permalink / raw)
  To: David Miller
  Cc: eric.dumazet, wei.liu2, xen-devel, netdev, ian.campbell, annie.li,
	konrad.wilk, david.vrabel
In-Reply-To: <20130325.125949.1046297562456662826.davem@davemloft.net>

On Mon, 2013-03-25 at 12:59 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 25 Mar 2013 09:54:32 -0700
> 
> > On Mon, 2013-03-25 at 12:18 -0400, David Miller wrote:
> > 
> >> 
> >> This is effectively the default already, you don't need to change this
> >> value explicitly.
> >> 
> >> ->gso_max_size is set by default to 65536 and then TCP performs this
> >> calculation:
> >> 
> >>                 xmit_size_goal = ((sk->sk_gso_max_size - 1) -                          
> >>                                   inet_csk(sk)->icsk_af_ops->net_header_len -          
> >>                                   inet_csk(sk)->icsk_ext_hdr_len -                     
> >>                                   tp->tcp_header_len);                                 
> >> 
> >> thereby making it adhere to your limits just fine.
> > 
> > For locally generated TCP traffic this is the case.
> 
> Right, and also any other piece of code that is not interpreting the
> gso_max_size value the same way (as "(x - 1) - sizeof_headers") would
> need to be fixed.
[...]

tcp_tso_should_defer() also ignores headers, though I don't think the
check is particularly critical in that case.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply

* Re: [PATCH 1/1] ethernet driver: dm9000: davicom: Upgrade the driver to suit for all DM9000 series chips
From: Jonathan Corbet @ 2013-03-25 20:08 UTC (permalink / raw)
  To: Joseph CHANG
  Cc: David S. Miller, Bill Pemberton, Matthew Leach,
	Greg Kroah-Hartman, Joseph CHANG, Jiri Pirko, netdev,
	linux-kernel
In-Reply-To: <1364198682-1589-1-git-send-email-josright123@gmail.com>

On Mon, 25 Mar 2013 16:04:42 +0800
Joseph CHANG <josright123@gmail.com> wrote:

> From: Joseph CHANG <joseph_chang@davicom.com.tw>
> 
> Some necessary modification for DM9000 series chips to be better in operation!

Interesting, this had been sent to me privately at about the same time.
For the record, here's what I sent back:

From: Jonathan Corbet <corbet@lwn.net>
To: Allen Huang (黃偉格) <allen_huang@davicom.com.tw>
Subject: Re: Davicom Linux driver
Date: Mon, 25 Mar 2013 09:55:48 -0600
Organization: LWN.net

On Mon, 25 Mar 2013 18:31:35 +0800
Allen Huang (黃偉格) <allen_huang@davicom.com.tw> wrote:

> Please see our Linux Patch in the attachment and we would appreciate any
> comments that you have on our driver and/or whether it is ready to go into
> the kernel. Thanks.   

I'll take a quick look at it.  But the only true way to know whether it's
ready, of course, is to post it to the public lists.

> Some necessary modification for DM9000 series chips to be better in operation!  

The patch will be better received if you say what "better in operation"
actually means.  Are you supporting new hardware, adding new features,
fixing bugs?  Hopefully not more than one of those in a single patch.

> Had tested to all of DM9000 series chips, include DM9000E, DM9000A, DM9000B,
> and DM9000C in X86 and ARM embedded Linux system these years.
> 
> Signed-off-by: Joseph CHANG <joseph_chang@davicom.com.tw>
> ---
>  drivers/net/ethernet/davicom/dm9000.c |   28 +++++++++++++++++++++++-----
>  drivers/net/ethernet/davicom/dm9000.h |    4 +++-
>  2 files changed, 26 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
> index 8cdf025..54bdc92 100644
> --- a/drivers/net/ethernet/davicom/dm9000.c
> +++ b/drivers/net/ethernet/davicom/dm9000.c
> @@ -47,7 +47,8 @@
>  #define DM9000_PHY		0x40	/* PHY address 0x01 */
>  
>  #define CARDNAME	"dm9000"
> -#define DRV_VERSION	"1.31"
> +/* [KERN-ADD-1](upgrade) */  

I would lose the [KERN-ADD*] comments, those will certainly draw some
grumbling when the patch is posted publicly.  They don't add any value; the
repository will show which changes were made when.

> +#define DRV_VERSION	"1.39"
>  
>  /*
>   * Transmit timeout, default 5 seconds.
> @@ -671,10 +672,16 @@ dm9000_poll_work(struct work_struct *w)
>  			if (netif_msg_link(db))
>  				dm9000_show_carrier(db, new_carrier, nsr);
>  
> -			if (!new_carrier)
> +			/* [KERN-ADD-2] */
> +			if (!new_carrier) {
>  				netif_carrier_off(ndev);
> -			else
> +				netdev_info(ndev, "[%s Ethernet Driver, V%s]: Link-Down!!\n",
> +					CARDNAME, DRV_VERSION);
> +			} else {
>  				netif_carrier_on(ndev);
> +				netdev_info(ndev, "[%s Ethernet Driver, V%s]: Link-Up!!\n",
> +					CARDNAME, DRV_VERSION);
> +			}  

So "better in operation" means more log messages?  This, too, will likely
draw complaints.  That could be a lot of log messages!  The additional
information is also probably unnecessary, netdev_info() should print the
relevant device information.

>  		}
>  	} else
>  		mii_check_media(&db->mii, netif_msg_link(db), 0);
> @@ -794,6 +801,9 @@ dm9000_init_dm9000(struct net_device *dev)
>  			(dev->features & NETIF_F_RXCSUM) ? RCSR_CSUM : 0);
>  
>  	iow(db, DM9000_GPCR, GPCR_GEP_CNTL);	/* Let GPIO0 output */
> +    /* [KERN-ADD-3] */
> +	dm9000_phy_write(dev, 0, 0, 0x8000); /* reset PHY */
> +	mdelay(2);  

Magic constants aren't good, you can't define a symbol for that?

dm900_poll_work() is a workqueue function, right?  So it can sleep.  So you
should almost certainly use msleep() rather than mdelay().

>  	ncr = (db->flags & DM9000_PLATF_EXT_PHY) ? NCR_EXT_PHY : 0;
>  
> @@ -830,6 +840,8 @@ dm9000_init_dm9000(struct net_device *dev)
>  	db->tx_pkt_cnt = 0;
>  	db->queue_pkt_len = 0;
>  	dev->trans_start = jiffies;
> +    /* [KERN-ADD-4]	*/
> +	dm9000_phy_write(dev, 0, 27, 0xE100);  

Again, can we avoid the magic constants?

>  }
>  
>  /* Our watchdog timed out. Called by the networking layer */
> @@ -1181,7 +1193,8 @@ dm9000_open(struct net_device *dev)
>  
>  	/* GPIO0 on pre-activate PHY, Reg 1F is not set by reset */
>  	iow(db, DM9000_GPR, 0);	/* REG_1F bit0 activate phyxcer */
> -	mdelay(1); /* delay needs by DM9000B */
> +	/* [KERN-ADD-5](Enable PHY) */
> +	mdelay(2); /* delay needs by DM9000B */  

You say "Enable PHY" but I see no change that does that?
Again, msleep() would be better here - an open function can certainly
sleep! 

>  	/* Initialize DM9000 board */
>  	dm9000_reset(db);
> @@ -1311,6 +1324,8 @@ dm9000_shutdown(struct net_device *dev)
>  
>  	/* RESET device */
>  	dm9000_phy_write(dev, 0, MII_BMCR, BMCR_RESET);	/* PHY RESET */
> +    /* [KERN-ADD-6](NOTICE)(by)("if (!db->wake_state) ..") */
> +    /* iow(db, DM9000_GPR, 0x01); */
>  	iow(db, DM9000_GPR, 0x01);	/* Power-Down PHY */  

What is the purpose of this change?

>  	iow(db, DM9000_IMR, IMR_PAR);	/* Disable all interrupt */
>  	iow(db, DM9000_RCR, 0x00);	/* Disable RX */
> @@ -1465,6 +1480,8 @@ dm9000_probe(struct platform_device *pdev)
>  	/* fill in parameters for net-dev structure */
>  	ndev->base_addr = (unsigned long)db->io_addr;
>  	ndev->irq	= db->irq_res->start;
> +    /* [KERN-ADD-7] */
> +	netdev_info(ndev, "[dm9] %s ndev->irq=%x\n", __func__, ndev->irq);  

That should be unnecessary; that information is available in
/proc/interrupts, and probably via ethtool too.

>  	/* ensure at least we have a default set of IO routines */
>  	dm9000_set_io(db, iosize);
> @@ -1502,7 +1519,8 @@ dm9000_probe(struct platform_device *pdev)
>  	db->flags |= DM9000_PLATF_SIMPLE_PHY;
>  #endif
>  
> -	dm9000_reset(db);
> +    /* [KERN-ADD-8](SPECIAL WHEN INIT_OF_PROBE)[takeover"dm9000_reset(db)"] */
> +	iow(db, DM9000_NCR, NCR_MAC_LBK | NCR_RST); /* 0x03 */  

What is accomplished by this change?  Should it maybe be a parameter to
dm9000_reset()?

>  	/* try multiple times, DM9000 sometimes gets the read wrong */
>  	for (i = 0; i < 8; i++) {
> diff --git a/drivers/net/ethernet/davicom/dm9000.h b/drivers/net/ethernet/davicom/dm9000.h
> index 55688bd..d644506 100644
> --- a/drivers/net/ethernet/davicom/dm9000.h
> +++ b/drivers/net/ethernet/davicom/dm9000.h
> @@ -69,7 +69,9 @@
>  #define NCR_WAKEEN          (1<<6)
>  #define NCR_FCOL            (1<<4)
>  #define NCR_FDX             (1<<3)
> -#define NCR_LBK             (3<<1)
> +
> +#define NCR_RESERVED        (3<<1)
> +#define NCR_MAC_LBK         (1<<1) /* [kern-add-0] */
>  #define NCR_RST	            (1<<0)
>  
>  #define NSR_SPEED           (1<<7)
> -- 
> 1.7.1
>   
Hope that helps,

jon

^ permalink raw reply

* Re: [PATCH v2 net-next 1/5] GRE: Refactor GRE tunneling code.
From: David Miller @ 2013-03-25 20:23 UTC (permalink / raw)
  To: pshelar; +Cc: stephen, netdev, jesse
In-Reply-To: <20130325.153934.1155634067907894585.davem@davemloft.net>

From: David Miller <davem@davemloft.net>
Date: Mon, 25 Mar 2013 15:39:34 -0400 (EDT)

> From: Pravin Shelar <pshelar@nicira.com>
> Date: Mon, 25 Mar 2013 12:30:46 -0700
> 
>> On Tue, Mar 19, 2013 at 2:56 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Pravin Shelar <pshelar@nicira.com>
>>> Date: Tue, 19 Mar 2013 14:38:11 -0700
>>>
>>>> On Tue, Mar 19, 2013 at 2:26 PM, David Miller <davem@davemloft.net> wrote:
>>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>>> Date: Tue, 19 Mar 2013 14:21:41 -0700
>>>>>
>>>>>> Doesn't build with this patch alone (ie. not bisectable).
>>>>>>
>>>>>>   CC [M]  net/ipv6/ip6_gre.o
>>>>>> net/ipv6/ip6_gre.c:41:27: fatal error: net/ip_tunnel.h: No such file or directory
>>>>>> compilation terminated.
>>>>>
>>>>> Oh well, too late, it's all already in my tree.
>>>>
>>>> sorry about that.
>>>> I am sending update patch soon.
>>>
>>> There is nothing for you to send, what's in my tree is not changing.
>> 
>> I do not see these patches in net-next and now there are few conflicts
>> due GRE commits.
>> Do you want me to send updated patches against latest net-next?
> 
> You need to send whatever relative fixes are necessary.

Actually I see where the confusion is.

I thought I had applied v3 of this series, looks like I didn't,
so yes you should respin this fixing the build problems Stephen
pointed out.

Thanks.

^ permalink raw reply

* Re: [PATCH 3/3] dsa: fix freeing of sparse port allocation
From: Florian Fainelli @ 2013-03-25 19:55 UTC (permalink / raw)
  To: David Laight; +Cc: davem, netdev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B71B3@saturn3.aculab.com>

Le lundi 25 mars 2013 17:03:23, David Laight a écrit :
> > If we have defined a sparse port allocation which is non-contiguous and
> > contains gaps, the code freeing port_names will just stop when it
> > encouters a first NULL port_names, which is not right, we should iterate
> > over all possible number of ports (DSA_MAX_PORTS) until we are done.
> 
> ...
> 
> >  		port_index = 0;
> > 
> > -		while (pd->chip[i].port_names &&
> > -			pd->chip[i].port_names[++port_index])
> > -			kfree(pd->chip[i].port_names[port_index]);
> > +		while (port_index < DSA_MAX_PORTS) {
> > +			if (pd->chip[i].port_names[port_index])
> > +				kfree(pd->chip[i].port_names[port_index]);
> > +			port_index++;
> > +		}
> 
> A couple of 'odd' differences:
> 
> The old code checked pd->chip[i].port_names (as if it
> might be a pointer) that is absent from the new version.
> (If it is separately allocated it is leaked).
> 
> The new code tests and frees pd->chip[i].port_names[0]
> whereas the old code ignored the 0th entry.

The old code was wrong, it was off by one for the first array index, and would 
stop whenever it encountered the first NULL port_names[index] so we would not 
skip other these and free the possibly non-NULL next one.

I think the current code is now correct, but thanks for the review!
--
Florian

^ permalink raw reply

* Re: [PATCH v2 net-next 1/5] GRE: Refactor GRE tunneling code.
From: David Miller @ 2013-03-25 19:39 UTC (permalink / raw)
  To: pshelar; +Cc: stephen, netdev, jesse
In-Reply-To: <CALnjE+rjnWs7z3_R3k6Fy_8jzYb7jJL-LnkjypTBmsyXs-xuhA@mail.gmail.com>

From: Pravin Shelar <pshelar@nicira.com>
Date: Mon, 25 Mar 2013 12:30:46 -0700

> On Tue, Mar 19, 2013 at 2:56 PM, David Miller <davem@davemloft.net> wrote:
>> From: Pravin Shelar <pshelar@nicira.com>
>> Date: Tue, 19 Mar 2013 14:38:11 -0700
>>
>>> On Tue, Mar 19, 2013 at 2:26 PM, David Miller <davem@davemloft.net> wrote:
>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>> Date: Tue, 19 Mar 2013 14:21:41 -0700
>>>>
>>>>> Doesn't build with this patch alone (ie. not bisectable).
>>>>>
>>>>>   CC [M]  net/ipv6/ip6_gre.o
>>>>> net/ipv6/ip6_gre.c:41:27: fatal error: net/ip_tunnel.h: No such file or directory
>>>>> compilation terminated.
>>>>
>>>> Oh well, too late, it's all already in my tree.
>>>
>>> sorry about that.
>>> I am sending update patch soon.
>>
>> There is nothing for you to send, what's in my tree is not changing.
> 
> I do not see these patches in net-next and now there are few conflicts
> due GRE commits.
> Do you want me to send updated patches against latest net-next?

You need to send whatever relative fixes are necessary.

^ permalink raw reply

* Re: [PATCH 1/2] netfilter: reset nf_trace in nf_reset
From: Pablo Neira Ayuso @ 2013-03-25 19:31 UTC (permalink / raw)
  To: Gao feng; +Cc: netfilter-devel, netdev
In-Reply-To: <1363931322-2286-1-git-send-email-gaofeng@cn.fujitsu.com>

On Fri, Mar 22, 2013 at 01:48:41PM +0800, Gao feng wrote:
> We forgot to clear the nf_trace of sk_buff in nf_reset,
> When we use veth device, this nf_trace information will
> be leaked from one net namespace to another net namespace.

Applied to the nf tree, thanks Gao.

^ permalink raw reply

* Re: [PATCH v2 net-next 1/5] GRE: Refactor GRE tunneling code.
From: Pravin Shelar @ 2013-03-25 19:30 UTC (permalink / raw)
  To: David Miller; +Cc: stephen, netdev, jesse
In-Reply-To: <20130319.175612.1450380502469601673.davem@davemloft.net>

On Tue, Mar 19, 2013 at 2:56 PM, David Miller <davem@davemloft.net> wrote:
> From: Pravin Shelar <pshelar@nicira.com>
> Date: Tue, 19 Mar 2013 14:38:11 -0700
>
>> On Tue, Mar 19, 2013 at 2:26 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>> Date: Tue, 19 Mar 2013 14:21:41 -0700
>>>
>>>> Doesn't build with this patch alone (ie. not bisectable).
>>>>
>>>>   CC [M]  net/ipv6/ip6_gre.o
>>>> net/ipv6/ip6_gre.c:41:27: fatal error: net/ip_tunnel.h: No such file or directory
>>>> compilation terminated.
>>>
>>> Oh well, too late, it's all already in my tree.
>>
>> sorry about that.
>> I am sending update patch soon.
>
> There is nothing for you to send, what's in my tree is not changing.

I do not see these patches in net-next and now there are few conflicts
due GRE commits.
Do you want me to send updated patches against latest net-next?

^ permalink raw reply

* Re: [Xen-devel] [PATCH 5/6] xen-netback: coalesce slots before copying
From: Wei Liu @ 2013-03-25 19:09 UTC (permalink / raw)
  To: David Vrabel
  Cc: Wei Liu, Ian Campbell, konrad.wilk@oracle.com,
	netdev@vger.kernel.org, xen-devel@lists.xen.org,
	annie.li@oracle.com
In-Reply-To: <51509789.8090608@citrix.com>

On Mon, Mar 25, 2013 at 06:29:29PM +0000, David Vrabel wrote:
> >>
> > 
> > Are you suggesting move the default macro value to header file? It is
> > just an estimation, I have no knowledge of the accurate maximum value,
> > so I think make it part of the protocol a bad idea.
> 
> How is the author of a new frontend supposed to know how many slots they
> can use per packet if it is not precisely defined?
> 

A new frontend shuold use the scheme you mentioned below to get the
maximum value. For old frontends that cannot be fixed, administrator can
configure max_skb_slots to accommodate their need.

> > Do you have a handle on the maximum value?
> 
> Backends should provide the value to the frontend via a xenstore key
> (e.g., max-slots-per-frame).  This value should be at least 18 (the
> historical value of MAX_SKB_FRAGS).
> 
> The frontend may use up to this specified value or 17 if the
> max-slots-per-frame key is missing.
> 
> Supporting at least 18 in the backend is required for existing
> frontends.  Limiting frontends to 17 allows them to work with all
> backends (including recent Linux version that only supported 17).
> 
> It's not clear why 19 or 20 were suggested as possible values.  I
> checked back to 2.6.18 and MAX_SKB_FRAGS there is (65536/PAGE_SIZE + 2)

Because the check is >= MAX_SKB_FRAGS originally and James Harper told
me that "Windows stops counting on 20".

> == 18.
> 
> Separately, it may be sensible for the backend to drop packets with more
> frags than max-slots-per-frame up to some threshold where anything more
> is considered malicious (i.e., 1 - 18 slots is a valid packet, 19-20 are
> dropped and 21 or more is a fatal error).
> 

Why drop the packet when we are able to process it? Frontend cannot know
it has crossed the line anyway.


Wei.

^ permalink raw reply

* Re: [PATCH] libertas: drop maintainership
From: John W. Linville @ 2013-03-25 18:59 UTC (permalink / raw)
  To: Dan Williams; +Cc: Joe Perches, netdev, linux-wireless, Daniel Drake, Bing Zhao
In-Reply-To: <1363629095.6437.10.camel@dcbw.foobar.com>

On Mon, Mar 18, 2013 at 12:51:35PM -0500, Dan Williams wrote:
> On Mon, 2013-03-18 at 10:23 -0700, Joe Perches wrote:
> > On Mon, 2013-03-18 at 11:48 -0500, Dan Williams wrote:
> > > Would be better maintained by somebody who actualy has time for it.
> > []
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > []
> > > -MARVELL LIBERTAS WIRELESS DRIVER
> > > -M:	Dan Williams <dcbw@redhat.com>
> > > -L:	libertas-dev@lists.infradead.org
> > > -S:	Maintained
> > > -F:	drivers/net/wireless/libertas/
> > 
> > I think it better to mark it as Orphan
> > and maybe leave the list.
> > 
> > Maybe:
> > 
> > MARVELL LIBERTAS WIRELESS DRIVER
> > L:	libertas-dev@lists.infradead.org
> > S:	Orphan
> > F:	drivers/net/wireless/libertas/
> > 
> > or
> > 
> > MARVELL LIBERTAS WIRELESS DRIVER
> > S:	Orphan
> > F:	drivers/net/wireless/libertas/
> 
> I can do that; I wasn't quite sure how to do this.  A quick check showed
> patches that did what mine did, and oddly MAINTAINERS has no section for
> dropping maintainership that I could quickly find.  If this is what
> others prefer I'm happy to resubmit?

I probably would prefer an "Orphan" listing as well...

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: [PATCH regression/bisected] Revert "brcmsmac: support 4313iPA"
From: John W. Linville @ 2013-03-25 18:58 UTC (permalink / raw)
  To: David Herrmann
  Cc: Piotr Haber, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arend van Spriel,
	brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
	netdev-u79uwXL29TY76Z2rM5mHXA, Pieter-Paul Giesberts
In-Reply-To: <CANq1E4TsM6yoSt9aELFan0ayEw3PSfYCe+PEe35YFHzZ-9rTuA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Mon, Mar 18, 2013 at 02:58:08PM +0100, David Herrmann wrote:
> Hi Piotr
> 
> On Mon, Mar 18, 2013 at 2:49 PM, Piotr Haber <phaber-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> > On 03/18/13 11:45, David Herrmann wrote:
> >> This reverts commit b6fc28a158076ca2764edc9a6d1e1402f56e1c0c. It breaks
> >> wireless AP reconnection on: (14e4:4727)
> >>   Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller
> >>
> >> Any attempt to reconnect to an AP results in timeouts no matter how near to the
> >> AP I am:
> >>  00:10:40 $nb kernel: wlan0: authenticate with 00:18:39:0a:8e:23
> >>  00:10:40 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 1/3)
> >>  00:10:40 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 2/3)
> >>  00:10:41 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 3/3)
> >>  00:10:41 $nb kernel: wlan0: authentication with 00:18:39:0a:8e:23 timed out
> >> ---
> >> Hi
> >>
> >> I tried coming up with a fix instead of reverting this commit, but the commit is
> >> way to big for me to understand what's going on. Sorry.
> >>
> >> With linux-3.8 connecting to an AP broke on my machine. I could connect to an AP
> >> one time, but any further attempt resulted in:
> >>  00:10:40 $nb kernel: wlan0: authenticate with 00:18:39:0a:8e:23
> >>  00:10:40 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 1/3)
> >>  00:10:40 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 2/3)
> >>  00:10:41 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 3/3)
> >>  00:10:41 $nb kernel: wlan0: authentication with 00:18:39:0a:8e:23 timed out
> >>
> >> Even sitting right next to the AP didn't help so I started bisecting and it
> >> turned out to be:
> >>   "brcmsmac: support 4313iPA" b6fc28a158076ca2764edc9a6d1e1402f56e1c0c
> >> Please revert it.
> >>
> >> Thanks
> >> David
> >>
> > Hi,
> > unfortunately this is not a first report of this patch breaking 4313 for some users.
> > I'm pretty confident that it is hardware revision related as we have 4313ePA and iPA boards running
> > successfully in our test setup.
> > Could you aid us in effort of finding the problem by supplying the contents of this debugfs file:
> > <debugfs_mount>/brcmsmac/bcma0:0/hardware
> 
> Hi
> 
> $ cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware
> board vendor: 185f
> board type: 51a
> board revision: 1408
> board flags: 8402a01
> board flags2: 880
> firmware revision: 262032b
> 
> I can also try partial reverts of that commit, but I really don't know
> which parts might be important.

Are we going to see a fix for this (very) soon?  Or should I just go
ahead and revert this patch?

-- 
John W. Linville		Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org			might be all we have.  Be ready.
--
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 net-next] ptp: increase the maximum number of clocks
From: Richard Cochran @ 2013-03-25 18:51 UTC (permalink / raw)
  To: Jiri Benc; +Cc: David Miller, netdev
In-Reply-To: <20130325170855.0194ce13@griffin>

On Mon, Mar 25, 2013 at 05:08:55PM +0100, Jiri Benc wrote:
> On Sat, 23 Mar 2013 18:59:15 +0100, Richard Cochran wrote:
> > Jiri, do you want to work on making the number of clocks essentially
> > unlimited? If not, I can take a look at this, but not right away.
> 
> I'm currently thinking of using just /dev/ptp for all PHCs in the
> system and specifying the desired network device (ifindex, likely)
> by an ioctl as the very first operation. What do you think? If this
> is viable, I can try to implement it.

While that might work for the PTP ioctls, it won't for the main
clock_gettime/settime/adjtime call. As you wrote below, these take a
dynamic clockid_t (which comes from a file descriptor), and so each
device needs its own, unique file system node.

For better or worse, we are stuck with char devs, unless we want to
redo the clock_xyz API. I certainly don't want to. We can have over a
million PTP clocks on a single major number. That should be enough.

IIRC, it is possible to grow the range of minor numbers
incrementally. Perhaps you could take a look at that?

Thanks,
Richard
 
> As for netlink, I don't see how to do that without reimplementing the
> whole kernel<->user space timer API. The API expects clockid_t which
> is either a const (a new constant wouldn't help, we can have multiple
> PHCs in the system), or a dynamic value. There is no space for more
> dynamic values as far as I can see, all combinations of the three lower
> bits are already defined. It seems we're left with file descriptors.
> 
>  Jiri
> 
> -- 
> Jiri Benc

^ permalink raw reply

* Re: [PATCH 2/6] xen-netfront: reduce gso_max_size to account for ethernet header
From: David Miller @ 2013-03-25 18:39 UTC (permalink / raw)
  To: wei.liu2
  Cc: xen-devel, netdev, Ian.Campbell, annie.li, konrad.wilk,
	david.vrabel
In-Reply-To: <20130325183206.GA7004@zion.uk.xensource.com>

From: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 25 Mar 2013 18:32:06 +0000

> On Mon, Mar 25, 2013 at 04:18:09PM +0000, David Miller wrote:
>> From: Wei Liu <wei.liu2@citrix.com>
>> Date: Mon, 25 Mar 2013 11:08:18 +0000
>> 
>> > The maximum packet including ethernet header that can be handled by netfront /
>> > netback wire format is 65535. Reduce gso_max_size accordingly.
>> > 
>> > Drop skb and print warning when skb->len > 65535. This can 1) save the effort
>> > to send malformed packet to netback, 2) help spotting misconfiguration of
>> > netfront in the future.
>> > 
>> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> 
>> This is effectively the default already, you don't need to change this
>> value explicitly.
>> 
>> ->gso_max_size is set by default to 65536 and then TCP performs this
>> calculation:
>> 
>>                 xmit_size_goal = ((sk->sk_gso_max_size - 1) -                          
>>                                   inet_csk(sk)->icsk_af_ops->net_header_len -          
>>                                   inet_csk(sk)->icsk_ext_hdr_len -                     
>>                                   tp->tcp_header_len);                                 
> 
> OK. But I see similar fix for a physical nic (commit b7e5887e0e414b), am
> I missing something here?
> 
> And the symptom is that if I don't reserve headroom I see skb->len =
> 65538. Can you shed some light on this?

See Eric's reply.  If a GRO frame is forwarded we don't make the GSO size
checks on the send size as we should.

^ permalink raw reply

* Re: [PATCH 2/6] xen-netfront: reduce gso_max_size to account for ethernet header
From: Wei Liu @ 2013-03-25 18:32 UTC (permalink / raw)
  To: David Miller
  Cc: xen-devel@lists.xen.org, netdev@vger.kernel.org, Ian Campbell,
	annie.li@oracle.com, konrad.wilk@oracle.com, David Vrabel
In-Reply-To: <20130325.121809.2023305728304341952.davem@davemloft.net>

On Mon, Mar 25, 2013 at 04:18:09PM +0000, David Miller wrote:
> From: Wei Liu <wei.liu2@citrix.com>
> Date: Mon, 25 Mar 2013 11:08:18 +0000
> 
> > The maximum packet including ethernet header that can be handled by netfront /
> > netback wire format is 65535. Reduce gso_max_size accordingly.
> > 
> > Drop skb and print warning when skb->len > 65535. This can 1) save the effort
> > to send malformed packet to netback, 2) help spotting misconfiguration of
> > netfront in the future.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> This is effectively the default already, you don't need to change this
> value explicitly.
> 
> ->gso_max_size is set by default to 65536 and then TCP performs this
> calculation:
> 
>                 xmit_size_goal = ((sk->sk_gso_max_size - 1) -                          
>                                   inet_csk(sk)->icsk_af_ops->net_header_len -          
>                                   inet_csk(sk)->icsk_ext_hdr_len -                     
>                                   tp->tcp_header_len);                                 

OK. But I see similar fix for a physical nic (commit b7e5887e0e414b), am
I missing something here?

And the symptom is that if I don't reserve headroom I see skb->len =
65538. Can you shed some light on this?


Wei.

> 
> thereby making it adhere to your limits just fine.

^ permalink raw reply

* Re: [Xen-devel] [PATCH 5/6] xen-netback: coalesce slots before copying
From: David Vrabel @ 2013-03-25 18:29 UTC (permalink / raw)
  To: Wei Liu
  Cc: David Vrabel, Wei Liu, Ian Campbell, konrad.wilk@oracle.com,
	netdev@vger.kernel.org, xen-devel@lists.xen.org,
	annie.li@oracle.com
In-Reply-To: <CAOsiSVV8gtKqFxyAr3XN9YF78WjtFqzvx5mnA1dKTrS_4qzXBw@mail.gmail.com>

On 25/03/13 16:58, Wei Liu wrote:
> On Mon, Mar 25, 2013 at 4:34 PM, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 25/03/13 15:47, Wei Liu wrote:
>>> On Mon, Mar 25, 2013 at 3:13 PM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>> On 25/03/13 11:08, Wei Liu wrote:
>>>>> This patch tries to coalesce tx requests when constructing grant copy
>>>>> structures. It enables netback to deal with situation when frontend's
>>>>> MAX_SKB_FRAGS is larger than backend's MAX_SKB_FRAGS.
>>>>>
>>>>> It defines max_skb_slots, which is a estimation of the maximum number of slots
>>>>> a guest can send, anything bigger than that is considered malicious. Now it is
>>>>> set to 20, which should be enough to accommodate Linux (16 to 19).
>>>>
>>>> This maximum needs to be defined as part of the protocol and added to
>>>> the interface header.
>>>>
>>>
>>> No, this is not part of the protocol and not a hard limit. It is
>>> configurable by system administrator.
>>
>> There is no mechanism by which the front and back ends can negotiate
>> this value, so it does need to be a fixed value that is equal or greater
>> than the max from any front or back end that has ever existed.
>>
> 
> Are you suggesting move the default macro value to header file? It is
> just an estimation, I have no knowledge of the accurate maximum value,
> so I think make it part of the protocol a bad idea.

How is the author of a new frontend supposed to know how many slots they
can use per packet if it is not precisely defined?

> Do you have a handle on the maximum value?

Backends should provide the value to the frontend via a xenstore key
(e.g., max-slots-per-frame).  This value should be at least 18 (the
historical value of MAX_SKB_FRAGS).

The frontend may use up to this specified value or 17 if the
max-slots-per-frame key is missing.

Supporting at least 18 in the backend is required for existing
frontends.  Limiting frontends to 17 allows them to work with all
backends (including recent Linux version that only supported 17).

It's not clear why 19 or 20 were suggested as possible values.  I
checked back to 2.6.18 and MAX_SKB_FRAGS there is (65536/PAGE_SIZE + 2)
== 18.

Separately, it may be sensible for the backend to drop packets with more
frags than max-slots-per-frame up to some threshold where anything more
is considered malicious (i.e., 1 - 18 slots is a valid packet, 19-20 are
dropped and 21 or more is a fatal error).

>> The reason for this patch is that this wasn't properly specified and
>> changes outside of netback broke the protocol.
>>
>>>> [...]
>>>>> +             /* Setting any number other than
>>>>> +              * INVALID_PENDING_RING_IDX indicates this slot is
>>>>> +              * starting a new packet / ending a previous packet.
>>>>> +              */
>>>>> +             pending_tx_info->head = 0;
>>>>
>>>> This doesn't look needed.  It will be initialized again when reusing t
>>>> his pending_tx_info again, right?
>>>>
>>>
>>> Yes, it is needed. Otherwise netback responses to invalid tx_info and
>>> cause netfront to crash before coming into the re-initialization path.
>>
>> Maybe I'm missing something but this is after the make_tx_reponse()
>> call, and immediately after this pending_tx_info is returned to the
>> pending ring as free.
>>
> 
> So it is a bit tricky here. Let me clarify this, the head field is
> used to indicate the start of a new tx requests queue and the end of
> previous queue.

Ok, I get this now.

David

^ permalink raw reply

* [PATCH net-next (TAKE 4) 6/6] firewire net, ipv6: IPv6 over Firewire (RFC3146) support.
From: YOSHIFUJI Hideaki @ 2013-03-25 18:26 UTC (permalink / raw)
  To: davem, stefanr; +Cc: netdev, linux1394-devel, stephan.gatzka, yoshfuji

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
V4: remove rfc3146 unit directory on module exit + minor clean-ups.
---
 drivers/firewire/Kconfig |    6 ++--
 drivers/firewire/net.c   |   79 +++++++++++++++++++++++++++++++++++++++++++---
 net/ipv6/addrconf.c      |   20 +++++++++++-
 3 files changed, 96 insertions(+), 9 deletions(-)

diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig
index 7224533..7a701a5 100644
--- a/drivers/firewire/Kconfig
+++ b/drivers/firewire/Kconfig
@@ -47,9 +47,9 @@ config FIREWIRE_NET
 	tristate "IP networking over 1394"
 	depends on FIREWIRE && INET
 	help
-	  This enables IPv4 over IEEE 1394, providing IP connectivity with
-	  other implementations of RFC 2734 as found on several operating
-	  systems.  Multicast support is currently limited.
+	  This enables IPv4/IPv6 over IEEE 1394, providing IP connectivity
+	  with other implementations of RFC 2734/3146 as found on several
+	  operating systems.  Multicast support is currently limited.
 
 	  To compile this driver as a module, say M here:  The module will be
 	  called firewire-net.
diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index 790017e..5679633 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -1,5 +1,6 @@
 /*
  * IPv4 over IEEE 1394, per RFC 2734
+ * IPv6 over IEEE 1394, per RFC 3146
  *
  * Copyright (C) 2009 Jay Fenlason <fenlason@redhat.com>
  *
@@ -46,6 +47,7 @@
 
 #define IANA_SPECIFIER_ID		0x00005eU
 #define RFC2734_SW_VERSION		0x000001U
+#define RFC3146_SW_VERSION		0x000002U
 
 #define IEEE1394_GASP_HDR_SIZE	8
 
@@ -505,6 +507,9 @@ static int fwnet_finish_incoming_packet(struct net_device *net,
 	switch (ether_type) {
 	case ETH_P_ARP:
 	case ETH_P_IP:
+#if IS_ENABLED(CONFIG_IPV6)
+	case ETH_P_IPV6:
+#endif
 		break;
 	default:
 		goto err;
@@ -768,7 +773,12 @@ static void fwnet_receive_broadcast(struct fw_iso_context *context,
 	ver = be32_to_cpu(buf_ptr[1]) & 0xffffff;
 	source_node_id = be32_to_cpu(buf_ptr[0]) >> 16;
 
-	if (specifier_id == IANA_SPECIFIER_ID && ver == RFC2734_SW_VERSION) {
+	if (specifier_id == IANA_SPECIFIER_ID &&
+	    (ver == RFC2734_SW_VERSION
+#if IS_ENABLED(CONFIG_IPV6)
+	     || ver == RFC3146_SW_VERSION
+#endif
+	    )) {
 		buf_ptr += 2;
 		length -= IEEE1394_GASP_HDR_SIZE;
 		fwnet_incoming_packet(dev, buf_ptr, length, source_node_id,
@@ -971,16 +981,27 @@ static int fwnet_send_packet(struct fwnet_packet_task *ptask)
 		u8 *p;
 		int generation;
 		int node_id;
+		unsigned int sw_version;
 
 		/* ptask->generation may not have been set yet */
 		generation = dev->card->generation;
 		smp_rmb();
 		node_id = dev->card->node_id;
 
+		switch (ptask->skb->protocol) {
+		default:
+			sw_version = RFC2734_SW_VERSION;
+			break;
+#if IS_ENABLED(CONFIG_IPV6)
+		case htons(ETH_P_IPV6):
+			sw_version = RFC3146_SW_VERSION;
+#endif
+		}
+
 		p = skb_push(ptask->skb, IEEE1394_GASP_HDR_SIZE);
 		put_unaligned_be32(node_id << 16 | IANA_SPECIFIER_ID >> 8, p);
 		put_unaligned_be32((IANA_SPECIFIER_ID & 0xff) << 24
-						| RFC2734_SW_VERSION, &p[4]);
+						| sw_version, &p[4]);
 
 		/* We should not transmit if broadcast_channel.valid == 0. */
 		fw_send_request(dev->card, &ptask->transaction,
@@ -1248,6 +1269,9 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct net_device *net)
 	switch (proto) {
 	case htons(ETH_P_ARP):
 	case htons(ETH_P_IP):
+#if IS_ENABLED(CONFIG_IPV6)
+	case htons(ETH_P_IPV6):
+#endif
 		break;
 	default:
 		goto fail;
@@ -1490,7 +1514,7 @@ static int fwnet_probe(struct device *_dev)
 		goto out;
 
 	list_add_tail(&dev->dev_link, &fwnet_device_list);
-	dev_notice(&net->dev, "IPv4 over IEEE 1394 on card %s\n",
+	dev_notice(&net->dev, "IP over IEEE 1394 on card %s\n",
 		   dev_name(card->device));
  have_dev:
 	ret = fwnet_add_peer(dev, unit, device);
@@ -1579,6 +1603,14 @@ static const struct ieee1394_device_id fwnet_id_table[] = {
 		.specifier_id = IANA_SPECIFIER_ID,
 		.version      = RFC2734_SW_VERSION,
 	},
+#if IS_ENABLED(CONFIG_IPV6)
+	{
+		.match_flags  = IEEE1394_MATCH_SPECIFIER_ID |
+				IEEE1394_MATCH_VERSION,
+		.specifier_id = IANA_SPECIFIER_ID,
+		.version      = RFC3146_SW_VERSION,
+	},
+#endif
 	{ }
 };
 
@@ -1616,6 +1648,30 @@ static struct fw_descriptor rfc2374_unit_directory = {
 	.data   = rfc2374_unit_directory_data
 };
 
+#if IS_ENABLED(CONFIG_IPV6)
+static const u32 rfc3146_unit_directory_data[] = {
+	0x00040000,	/* directory_length		*/
+	0x1200005e,	/* unit_specifier_id: IANA	*/
+	0x81000003,	/* textual descriptor offset	*/
+	0x13000002,	/* unit_sw_version: RFC 3146	*/
+	0x81000005,	/* textual descriptor offset	*/
+	0x00030000,	/* descriptor_length		*/
+	0x00000000,	/* text				*/
+	0x00000000,	/* minimal ASCII, en		*/
+	0x49414e41,	/* I A N A			*/
+	0x00030000,	/* descriptor_length		*/
+	0x00000000,	/* text				*/
+	0x00000000,	/* minimal ASCII, en		*/
+	0x49507636,	/* I P v 6			*/
+};
+
+static struct fw_descriptor rfc3146_unit_directory = {
+	.length = ARRAY_SIZE(rfc3146_unit_directory_data),
+	.key    = (CSR_DIRECTORY | CSR_UNIT) << 24,
+	.data   = rfc3146_unit_directory_data
+};
+#endif
+
 static int __init fwnet_init(void)
 {
 	int err;
@@ -1624,11 +1680,17 @@ static int __init fwnet_init(void)
 	if (err)
 		return err;
 
+#if IS_ENABLED(CONFIG_IPV6)
+	err = fw_core_add_descriptor(&rfc3146_unit_directory);
+	if (err)
+		goto out;
+#endif
+
 	fwnet_packet_task_cache = kmem_cache_create("packet_task",
 			sizeof(struct fwnet_packet_task), 0, 0, NULL);
 	if (!fwnet_packet_task_cache) {
 		err = -ENOMEM;
-		goto out;
+		goto out2;
 	}
 
 	err = driver_register(&fwnet_driver.driver);
@@ -1636,7 +1698,11 @@ static int __init fwnet_init(void)
 		return 0;
 
 	kmem_cache_destroy(fwnet_packet_task_cache);
+out2:
+#if IS_ENABLED(CONFIG_IPV6)
+	fw_core_remove_descriptor(&rfc3146_unit_directory);
 out:
+#endif
 	fw_core_remove_descriptor(&rfc2374_unit_directory);
 
 	return err;
@@ -1647,11 +1713,14 @@ static void __exit fwnet_cleanup(void)
 {
 	driver_unregister(&fwnet_driver.driver);
 	kmem_cache_destroy(fwnet_packet_task_cache);
+#if IS_ENABLED(CONFIG_IPV6)
+	fw_core_remove_descriptor(&rfc3146_unit_directory);
+#endif
 	fw_core_remove_descriptor(&rfc2374_unit_directory);
 }
 module_exit(fwnet_cleanup);
 
 MODULE_AUTHOR("Jay Fenlason <fenlason@redhat.com>");
-MODULE_DESCRIPTION("IPv4 over IEEE1394 as per RFC 2734");
+MODULE_DESCRIPTION("IP over IEEE1394 as per RFC 2734/3146");
 MODULE_LICENSE("GPL");
 MODULE_DEVICE_TABLE(ieee1394, fwnet_id_table);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index fa36a67..12e1cec 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -70,6 +70,7 @@
 #include <net/snmp.h>
 
 #include <net/af_ieee802154.h>
+#include <net/firewire.h>
 #include <net/ipv6.h>
 #include <net/protocol.h>
 #include <net/ndisc.h>
@@ -1736,6 +1737,20 @@ static int addrconf_ifid_eui64(u8 *eui, struct net_device *dev)
 	return 0;
 }
 
+static int addrconf_ifid_ieee1394(u8 *eui, struct net_device *dev)
+{
+	union fwnet_hwaddr *ha;
+
+	if (dev->addr_len != FWNET_ALEN)
+		return -1;
+
+	ha = (union fwnet_hwaddr *)dev->dev_addr;
+
+	memcpy(eui, &ha->uc.uniq_id, sizeof(ha->uc.uniq_id));
+	eui[0] ^= 2;
+	return 0;
+}
+
 static int addrconf_ifid_arcnet(u8 *eui, struct net_device *dev)
 {
 	/* XXX: inherit EUI-64 from other interface -- yoshfuji */
@@ -1800,6 +1815,8 @@ static int ipv6_generate_eui64(u8 *eui, struct net_device *dev)
 		return addrconf_ifid_gre(eui, dev);
 	case ARPHRD_IEEE802154:
 		return addrconf_ifid_eui64(eui, dev);
+	case ARPHRD_IEEE1394:
+		return addrconf_ifid_ieee1394(eui, dev);
 	}
 	return -1;
 }
@@ -2641,7 +2658,8 @@ static void addrconf_dev_config(struct net_device *dev)
 	    (dev->type != ARPHRD_FDDI) &&
 	    (dev->type != ARPHRD_ARCNET) &&
 	    (dev->type != ARPHRD_INFINIBAND) &&
-	    (dev->type != ARPHRD_IEEE802154)) {
+	    (dev->type != ARPHRD_IEEE802154) &&
+	    (dev->type != ARPHRD_IEEE1394)) {
 		/* Alas, we support only Ethernet autoconfiguration. */
 		return;
 	}
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH net-next (TAKE 4) 5/6] firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.
From: YOSHIFUJI Hideaki @ 2013-03-25 18:26 UTC (permalink / raw)
  To: davem, stefanr; +Cc: netdev, linux1394-devel, stephan.gatzka, yoshfuji

Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.

IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address.  This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo.  By doing this, The neighbour
module in networking subsystem can cache them.

Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
      information will not be used in the driver when sending.

When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo.  The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.

This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.

Here, extended "hardware address" is defined as follows:

union fwnet_hwaddr {
	u8 u[16];
	struct {
		__be64 uniq_id;		/* EUI-64			*/
		u8 max_rec;		/* max packet size		*/
		u8 sspd;		/* max speed			*/
		__be16 fifo_hi;		/* hi 16bits of FIFO addr	*/
		__be32 fifo_lo;		/* lo 32bits of FIFO addr	*/
	} __packed uc;
};

Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.

One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha).  This difference is handled in the ARP subsystem.

CC: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

---
V4: Fix receiver side - ARP was not accepted.
---
 drivers/firewire/net.c |  153 ++++++++----------------------------------------
 include/linux/if_arp.h |   12 +++-
 include/net/firewire.h |   25 ++++++++
 net/ipv4/arp.c         |   27 +++++++--
 4 files changed, 82 insertions(+), 135 deletions(-)
 create mode 100644 include/net/firewire.h

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index cb8aa86..790017e 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -28,6 +28,7 @@
 
 #include <asm/unaligned.h>
 #include <net/arp.h>
+#include <net/firewire.h>
 
 /* rx limits */
 #define FWNET_MAX_FRAGMENTS		30 /* arbitrary, > TX queue depth */
@@ -57,33 +58,6 @@
 #define RFC2374_HDR_LASTFRAG	2	/* last fragment	*/
 #define RFC2374_HDR_INTFRAG	3	/* interior fragment	*/
 
-#define RFC2734_HW_ADDR_LEN	16
-
-struct rfc2734_arp {
-	__be16 hw_type;		/* 0x0018	*/
-	__be16 proto_type;	/* 0x0806       */
-	u8 hw_addr_len;		/* 16		*/
-	u8 ip_addr_len;		/* 4		*/
-	__be16 opcode;		/* ARP Opcode	*/
-	/* Above is exactly the same format as struct arphdr */
-
-	__be64 s_uniq_id;	/* Sender's 64bit EUI			*/
-	u8 max_rec;		/* Sender's max packet size		*/
-	u8 sspd;		/* Sender's max speed			*/
-	__be16 fifo_hi;		/* hi 16bits of sender's FIFO addr	*/
-	__be32 fifo_lo;		/* lo 32bits of sender's FIFO addr	*/
-	__be32 sip;		/* Sender's IP Address			*/
-	__be32 tip;		/* IP Address of requested hw addr	*/
-} __packed;
-
-/* This header format is specific to this driver implementation. */
-#define FWNET_ALEN	8
-#define FWNET_HLEN	10
-struct fwnet_header {
-	u8 h_dest[FWNET_ALEN];	/* destination address */
-	__be16 h_proto;		/* packet type ID field */
-} __packed;
-
 static bool fwnet_hwaddr_is_multicast(u8 *ha)
 {
 	return !!(*ha & 1);
@@ -196,8 +170,6 @@ struct fwnet_peer {
 	struct list_head peer_link;
 	struct fwnet_device *dev;
 	u64 guid;
-	u64 fifo;
-	__be32 ip;
 
 	/* guarded by dev->lock */
 	struct list_head pd_list; /* received partial datagrams */
@@ -227,6 +199,15 @@ struct fwnet_packet_task {
 };
 
 /*
+ * Get fifo address embedded in hwaddr
+ */
+static __u64 fwnet_hwaddr_fifo(union fwnet_hwaddr *ha)
+{
+	return (u64)get_unaligned_be16(&ha->uc.fifo_hi) << 32
+	       | get_unaligned_be32(&ha->uc.fifo_lo);
+}
+
+/*
  * saddr == NULL means use device source address.
  * daddr == NULL means leave destination address (eg unresolved arp).
  */
@@ -518,7 +499,6 @@ static int fwnet_finish_incoming_packet(struct net_device *net,
 					bool is_broadcast, u16 ether_type)
 {
 	struct fwnet_device *dev;
-	static const __be64 broadcast_hw = cpu_to_be64(~0ULL);
 	int status;
 	__be64 guid;
 
@@ -537,76 +517,11 @@ static int fwnet_finish_incoming_packet(struct net_device *net,
 
 	/*
 	 * Parse the encapsulation header. This actually does the job of
-	 * converting to an ethernet frame header, as well as arp
-	 * conversion if needed. ARP conversion is easier in this
-	 * direction, since we are using ethernet as our backend.
-	 */
-	/*
-	 * If this is an ARP packet, convert it. First, we want to make
-	 * use of some of the fields, since they tell us a little bit
-	 * about the sending machine.
+	 * converting to an ethernet-like pseudo frame header.
 	 */
-	if (ether_type == ETH_P_ARP) {
-		struct rfc2734_arp *arp1394;
-		struct arphdr *arp;
-		unsigned char *arp_ptr;
-		u64 fifo_addr;
-		u64 peer_guid;
-		struct fwnet_peer *peer;
-		unsigned long flags;
-
-		arp1394   = (struct rfc2734_arp *)skb->data;
-		arp       = (struct arphdr *)skb->data;
-		arp_ptr   = (unsigned char *)(arp + 1);
-		peer_guid = get_unaligned_be64(&arp1394->s_uniq_id);
-		fifo_addr = (u64)get_unaligned_be16(&arp1394->fifo_hi) << 32
-				| get_unaligned_be32(&arp1394->fifo_lo);
-
-		spin_lock_irqsave(&dev->lock, flags);
-		peer = fwnet_peer_find_by_guid(dev, peer_guid);
-		if (peer) {
-			peer->fifo = fifo_addr;
-			peer->ip = arp1394->sip;
-		}
-		spin_unlock_irqrestore(&dev->lock, flags);
-
-		if (!peer) {
-			dev_notice(&net->dev,
-				   "no peer for ARP packet from %016llx\n",
-				   (unsigned long long)peer_guid);
-			goto no_peer;
-		}
-
-		/*
-		 * Now that we're done with the 1394 specific stuff, we'll
-		 * need to alter some of the data.  Believe it or not, all
-		 * that needs to be done is sender_IP_address needs to be
-		 * moved, the destination hardware address get stuffed
-		 * in and the hardware address length set to 8.
-		 *
-		 * IMPORTANT: The code below overwrites 1394 specific data
-		 * needed above so keep the munging of the data for the
-		 * higher level IP stack last.
-		 */
-
-		arp->ar_hln = 8;
-		/* skip over sender unique id */
-		arp_ptr += arp->ar_hln;
-		/* move sender IP addr */
-		put_unaligned(arp1394->sip, (u32 *)arp_ptr);
-		/* skip over sender IP addr */
-		arp_ptr += arp->ar_pln;
-
-		if (arp->ar_op == htons(ARPOP_REQUEST))
-			memset(arp_ptr, 0, sizeof(u64));
-		else
-			memcpy(arp_ptr, net->dev_addr, sizeof(u64));
-	}
-
-	/* Now add the ethernet header. */
 	guid = cpu_to_be64(dev->card->guid);
 	if (dev_hard_header(skb, net, ether_type,
-			   is_broadcast ? &broadcast_hw : &guid,
+			   is_broadcast ? net->broadcast : net->dev_addr,
 			   NULL, skb->len) >= 0) {
 		struct fwnet_header *eth;
 		u16 *rawp;
@@ -649,7 +564,6 @@ static int fwnet_finish_incoming_packet(struct net_device *net,
 
 	return 0;
 
- no_peer:
  err:
 	net->stats.rx_errors++;
 	net->stats.rx_dropped++;
@@ -1355,11 +1269,12 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct net_device *net)
 		ptask->dest_node   = IEEE1394_ALL_NODES;
 		ptask->speed       = SCODE_100;
 	} else {
-		__be64 guid = get_unaligned((__be64 *)hdr_buf.h_dest);
+		union fwnet_hwaddr *ha = (union fwnet_hwaddr *)hdr_buf.h_dest;
+		__be64 guid = get_unaligned(&ha->uc.uniq_id);
 		u8 generation;
 
 		peer = fwnet_peer_find_by_guid(dev, be64_to_cpu(guid));
-		if (!peer || peer->fifo == FWNET_NO_FIFO_ADDR)
+		if (!peer)
 			goto fail;
 
 		generation         = peer->generation;
@@ -1367,32 +1282,12 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct net_device *net)
 		max_payload        = peer->max_payload;
 		datagram_label_ptr = &peer->datagram_label;
 
-		ptask->fifo_addr   = peer->fifo;
+		ptask->fifo_addr   = fwnet_hwaddr_fifo(ha);
 		ptask->generation  = generation;
 		ptask->dest_node   = dest_node;
 		ptask->speed       = peer->speed;
 	}
 
-	/* If this is an ARP packet, convert it */
-	if (proto == htons(ETH_P_ARP)) {
-		struct arphdr *arp = (struct arphdr *)skb->data;
-		unsigned char *arp_ptr = (unsigned char *)(arp + 1);
-		struct rfc2734_arp *arp1394 = (struct rfc2734_arp *)skb->data;
-		__be32 ipaddr;
-
-		ipaddr = get_unaligned((__be32 *)(arp_ptr + FWNET_ALEN));
-
-		arp1394->hw_addr_len    = RFC2734_HW_ADDR_LEN;
-		arp1394->max_rec        = dev->card->max_receive;
-		arp1394->sspd		= dev->card->link_speed;
-
-		put_unaligned_be16(dev->local_fifo >> 32,
-				   &arp1394->fifo_hi);
-		put_unaligned_be32(dev->local_fifo & 0xffffffff,
-				   &arp1394->fifo_lo);
-		put_unaligned(ipaddr, &arp1394->sip);
-	}
-
 	ptask->hdr.w0 = 0;
 	ptask->hdr.w1 = 0;
 	ptask->skb = skb;
@@ -1507,8 +1402,6 @@ static int fwnet_add_peer(struct fwnet_device *dev,
 
 	peer->dev = dev;
 	peer->guid = (u64)device->config_rom[3] << 32 | device->config_rom[4];
-	peer->fifo = FWNET_NO_FIFO_ADDR;
-	peer->ip = 0;
 	INIT_LIST_HEAD(&peer->pd_list);
 	peer->pdg_size = 0;
 	peer->datagram_label = 0;
@@ -1538,6 +1431,7 @@ static int fwnet_probe(struct device *_dev)
 	struct fwnet_device *dev;
 	unsigned max_mtu;
 	int ret;
+	union fwnet_hwaddr *ha;
 
 	mutex_lock(&fwnet_device_mutex);
 
@@ -1582,8 +1476,15 @@ static int fwnet_probe(struct device *_dev)
 	net->mtu = min(1500U, max_mtu);
 
 	/* Set our hardware address while we're at it */
-	put_unaligned_be64(card->guid, net->dev_addr);
-	put_unaligned_be64(~0ULL, net->broadcast);
+	ha = (union fwnet_hwaddr *)net->dev_addr;
+	put_unaligned_be64(card->guid, &ha->uc.uniq_id);
+	ha->uc.max_rec = dev->card->max_receive;
+	ha->uc.sspd = dev->card->link_speed;
+	put_unaligned_be16(dev->local_fifo >> 32, &ha->uc.fifo_hi);
+	put_unaligned_be32(dev->local_fifo & 0xffffffff, &ha->uc.fifo_lo);
+
+	memset(net->broadcast, -1, net->addr_len);
+
 	ret = register_netdev(net);
 	if (ret)
 		goto out;
@@ -1632,8 +1533,6 @@ static int fwnet_remove(struct device *_dev)
 	mutex_lock(&fwnet_device_mutex);
 
 	net = dev->netdev;
-	if (net && peer->ip)
-		arp_invalidate(net, peer->ip);
 
 	fwnet_remove_peer(peer, dev);
 
diff --git a/include/linux/if_arp.h b/include/linux/if_arp.h
index 89b4614..f563907 100644
--- a/include/linux/if_arp.h
+++ b/include/linux/if_arp.h
@@ -33,7 +33,15 @@ static inline struct arphdr *arp_hdr(const struct sk_buff *skb)
 
 static inline int arp_hdr_len(struct net_device *dev)
 {
-	/* ARP header, plus 2 device addresses, plus 2 IP addresses. */
-	return sizeof(struct arphdr) + (dev->addr_len + sizeof(u32)) * 2;
+	switch (dev->type) {
+#if IS_ENABLED(CONFIG_FIREWIRE_NET)
+	case ARPHRD_IEEE1394:
+		/* ARP header, device address and 2 IP addresses */
+		return sizeof(struct arphdr) + dev->addr_len + sizeof(u32) * 2;
+#endif
+	default:
+		/* ARP header, plus 2 device addresses, plus 2 IP addresses. */
+		return sizeof(struct arphdr) + (dev->addr_len + sizeof(u32)) * 2;
+	}
 }
 #endif	/* _LINUX_IF_ARP_H */
diff --git a/include/net/firewire.h b/include/net/firewire.h
new file mode 100644
index 0000000..31bcbfe
--- /dev/null
+++ b/include/net/firewire.h
@@ -0,0 +1,25 @@
+#ifndef _NET_FIREWIRE_H
+#define _NET_FIREWIRE_H
+
+/* Pseudo L2 address */
+#define FWNET_ALEN	16
+union fwnet_hwaddr {
+	u8 u[FWNET_ALEN];
+	/* "Hardware address" defined in RFC2734/RF3146 */
+	struct {
+		__be64 uniq_id;		/* EUI-64			*/
+		u8 max_rec;		/* max packet size		*/
+		u8 sspd;		/* max speed			*/
+		__be16 fifo_hi;		/* hi 16bits of FIFO addr	*/
+		__be32 fifo_lo;		/* lo 32bits of FIFO addr	*/
+	} __packed uc;
+};
+
+/* Pseudo L2 Header */
+#define FWNET_HLEN	18
+struct fwnet_header {
+	u8 h_dest[FWNET_ALEN];	/* destination address */
+	__be16 h_proto;		/* packet type ID field */
+} __packed;
+
+#endif
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index fea4929..247ec19 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -654,11 +654,19 @@ struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip,
 	arp_ptr += dev->addr_len;
 	memcpy(arp_ptr, &src_ip, 4);
 	arp_ptr += 4;
-	if (target_hw != NULL)
-		memcpy(arp_ptr, target_hw, dev->addr_len);
-	else
-		memset(arp_ptr, 0, dev->addr_len);
-	arp_ptr += dev->addr_len;
+
+	switch (dev->type) {
+#if IS_ENABLED(CONFIG_FIREWIRE_NET)
+	case ARPHRD_IEEE1394:
+		break;
+#endif
+	default:
+		if (target_hw != NULL)
+			memcpy(arp_ptr, target_hw, dev->addr_len);
+		else
+			memset(arp_ptr, 0, dev->addr_len);
+		arp_ptr += dev->addr_len;
+	}
 	memcpy(arp_ptr, &dest_ip, 4);
 
 	return skb;
@@ -781,7 +789,14 @@ static int arp_process(struct sk_buff *skb)
 	arp_ptr += dev->addr_len;
 	memcpy(&sip, arp_ptr, 4);
 	arp_ptr += 4;
-	arp_ptr += dev->addr_len;
+	switch (dev_type) {
+#if IS_ENABLED(CONFIG_FIREWIRE_NET)
+	case ARPHRD_IEEE1394:
+		break;
+#endif
+	default:
+		arp_ptr += dev->addr_len;
+	}
 	memcpy(&tip, arp_ptr, 4);
 /*
  *	Check for bad requests for 127.x.x.x and requests for multicast
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH net-next (TAKE 4) 4/6] firewire net: Ignore spd and max_payload advertised by ARP.
From: YOSHIFUJI Hideaki @ 2013-03-25 18:26 UTC (permalink / raw)
  To: davem, stefanr; +Cc: netdev, linux1394-devel, stephan.gatzka, yoshfuji

Stefan Richter <stefanr@s5r6.in-berlin.de> says:
| As far as I can tell, it would be best to ignore max_rec and sspd from ARP
| and NDP but keep using the respective information from firewire-core
| instead (handed over by fwnet_probe()).
|
| Why?  As I noted earlier, RFC 2734:1999 and RFC 3146:2001 were apparently
| written with a too simplistic notion of IEEE 1394 bus topology, resulting
| in max_rec and sspd in ARP-1394 and NDP-1394 to be useless, IMO.
|
| Consider a bus like this:
|
|     A ---- B ==== C
|
| A, B, C are all IP-over-1394 capable nodes.  ---- is an S400 cable hop,
| and ==== is an S800 cable hop.
|
| In case of unicasts or multicasts in which node A is involved as
| transmitter or receiver, as well as in case of broadcasts, the speeds
| S100, S200, S400 work and speed S400 is optimal.
|
| In case of anything else, IOW in case of unicasts or multicasts in which
| only nodes B and C are involved, the speeds S100, S200, S400, S800 work
| and speed S800 is optimal.
|
| Clearly, node A should indicate sspd = S400 in its ARP or NDP packets.
| But which sspd should nodes B and C set there?  Maybe they set S400, which
| would work but would waste half of the available bandwidth in the second
| case.  Or maybe they set S800, which is OK in the second case but would
| prohibit any communication with node A if blindly taken for correct.
|
| On the other hand, firewire-core *always* gives us the correct and optimum
| peer-to-peer speed and asynchronous packet payload, no matter how simple
| or complex the bus topology is and no matter in which temporal order nodes
| join the bus and are discovered.

CC: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
 drivers/firewire/net.c |   16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index 72536e7..cb8aa86 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -552,8 +552,6 @@ static int fwnet_finish_incoming_packet(struct net_device *net,
 		unsigned char *arp_ptr;
 		u64 fifo_addr;
 		u64 peer_guid;
-		unsigned sspd;
-		u16 max_payload;
 		struct fwnet_peer *peer;
 		unsigned long flags;
 
@@ -564,24 +562,10 @@ static int fwnet_finish_incoming_packet(struct net_device *net,
 		fifo_addr = (u64)get_unaligned_be16(&arp1394->fifo_hi) << 32
 				| get_unaligned_be32(&arp1394->fifo_lo);
 
-		sspd = arp1394->sspd;
-		/* Sanity check.  OS X 10.3 PPC reportedly sends 131. */
-		if (sspd > SCODE_3200) {
-			dev_notice(&net->dev, "sspd %x out of range\n", sspd);
-			sspd = SCODE_3200;
-		}
-		max_payload = fwnet_max_payload(arp1394->max_rec, sspd);
-
 		spin_lock_irqsave(&dev->lock, flags);
 		peer = fwnet_peer_find_by_guid(dev, peer_guid);
 		if (peer) {
 			peer->fifo = fifo_addr;
-
-			if (peer->speed > sspd)
-				peer->speed = sspd;
-			if (peer->max_payload > max_payload)
-				peer->max_payload = max_payload;
-
 			peer->ip = arp1394->sip;
 		}
 		spin_unlock_irqrestore(&dev->lock, flags);
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH net-next (TAKE 4) 3/6] firewire net: Allocate address handler before registering net_device.
From: YOSHIFUJI Hideaki @ 2013-03-25 18:25 UTC (permalink / raw)
  To: davem, stefanr; +Cc: netdev, linux1394-devel, stephan.gatzka, yoshfuji

Allocate FIFO address before registering net_device.
This is preparation to change the pseudo hardware address format
for firewire devices to include the offset of the FIFO for receipt
of unicast datagrams, instead of mangling ARP/NDP messages in the
driver layer.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
 drivers/firewire/net.c |   22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index 7c2e16a..72536e7 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -1286,13 +1286,9 @@ static int fwnet_open(struct net_device *net)
 	struct fwnet_device *dev = netdev_priv(net);
 	int ret;
 
-	ret = fwnet_fifo_start(dev);
-	if (ret)
-		return ret;
-
 	ret = fwnet_broadcast_start(dev);
 	if (ret)
-		goto out;
+		return ret;
 
 	netif_start_queue(net);
 
@@ -1301,9 +1297,6 @@ static int fwnet_open(struct net_device *net)
 	spin_unlock_irq(&dev->lock);
 
 	return 0;
-out:
-	fwnet_fifo_stop(dev);
-	return ret;
 }
 
 /* ifdown */
@@ -1312,9 +1305,7 @@ static int fwnet_stop(struct net_device *net)
 	struct fwnet_device *dev = netdev_priv(net);
 
 	netif_stop_queue(net);
-
 	fwnet_broadcast_stop(dev);
-	fwnet_fifo_stop(dev);
 
 	return 0;
 }
@@ -1593,6 +1584,11 @@ static int fwnet_probe(struct device *_dev)
 	dev->card = card;
 	dev->netdev = net;
 
+	ret = fwnet_fifo_start(dev);
+	if (ret < 0)
+		goto out;
+	dev->local_fifo = dev->handler.offset;
+
 	/*
 	 * Use the RFC 2734 default 1500 octets or the maximum payload
 	 * as initial MTU
@@ -1616,10 +1612,10 @@ static int fwnet_probe(struct device *_dev)
 	if (ret && allocated_netdev) {
 		unregister_netdev(net);
 		list_del(&dev->dev_link);
-	}
  out:
-	if (ret && allocated_netdev)
+		fwnet_fifo_stop(dev);
 		free_netdev(net);
+	}
 
 	mutex_unlock(&fwnet_device_mutex);
 
@@ -1660,6 +1656,8 @@ static int fwnet_remove(struct device *_dev)
 	if (list_empty(&dev->peer_list)) {
 		unregister_netdev(net);
 
+		fwnet_fifo_stop(dev);
+
 		for (i = 0; dev->queued_datagrams && i < 5; i++)
 			ssleep(1);
 		WARN_ON(dev->queued_datagrams);
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH net-next (TAKE 4) 2/6] firewire net: Send L2 multicast via GASP.
From: YOSHIFUJI Hideaki @ 2013-03-25 18:25 UTC (permalink / raw)
  To: davem, stefanr; +Cc: netdev, linux1394-devel, stephan.gatzka, yoshfuji

Send L2 multicast packet via GASP (Global asynchronous stream packet) by
seeing the multicast bit in the L2 hardware address, not by seeing upper-
layer protocol address.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
 drivers/firewire/net.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index d438c5b..7c2e16a 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -84,6 +84,11 @@ struct fwnet_header {
 	__be16 h_proto;		/* packet type ID field */
 } __packed;
 
+static bool fwnet_hwaddr_is_multicast(u8 *ha)
+{
+	return !!(*ha & 1);
+}
+
 /* IPv4 and IPv6 encapsulation header */
 struct rfc2734_header {
 	u32 w0;
@@ -626,7 +631,7 @@ static int fwnet_finish_incoming_packet(struct net_device *net,
 		skb_reset_mac_header(skb);
 		skb_pull(skb, sizeof(*eth));
 		eth = (struct fwnet_header *)skb_mac_header(skb);
-		if (*eth->h_dest & 1) {
+		if (fwnet_hwaddr_is_multicast(eth->h_dest)) {
 			if (memcmp(eth->h_dest, net->broadcast,
 				   net->addr_len) == 0)
 				skb->pkt_type = PACKET_BROADCAST;
@@ -1366,10 +1371,7 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct net_device *net)
 	 * Set the transmission type for the packet.  ARP packets and IP
 	 * broadcast packets are sent via GASP.
 	 */
-	if (memcmp(hdr_buf.h_dest, net->broadcast, FWNET_ALEN) == 0
-	    || proto == htons(ETH_P_ARP)
-	    || (proto == htons(ETH_P_IP)
-		&& IN_MULTICAST(ntohl(ip_hdr(skb)->daddr)))) {
+	if (fwnet_hwaddr_is_multicast(hdr_buf.h_dest)) {
 		max_payload        = dev->broadcast_xmt_max_payload;
 		datagram_label_ptr = &dev->broadcast_xmt_datagramlabel;
 
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH net-next (TAKE 4) 1/6] firewire net: Accept IPv4 and ARP only.
From: YOSHIFUJI Hideaki @ 2013-03-25 18:25 UTC (permalink / raw)
  To: davem, stefanr; +Cc: netdev, linux1394-devel, stephan.gatzka, yoshfuji

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
 drivers/firewire/net.c |   21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index c1898ad..d438c5b 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -517,6 +517,14 @@ static int fwnet_finish_incoming_packet(struct net_device *net,
 	int status;
 	__be64 guid;
 
+	switch (ether_type) {
+	case ETH_P_ARP:
+	case ETH_P_IP:
+		break;
+	default:
+		goto err;
+	}
+
 	dev = netdev_priv(net);
 	/* Write metadata, and then pass to the receive level */
 	skb->dev = net;
@@ -653,6 +661,7 @@ static int fwnet_finish_incoming_packet(struct net_device *net,
 	return 0;
 
  no_peer:
+ err:
 	net->stats.rx_errors++;
 	net->stats.rx_dropped++;
 
@@ -1340,9 +1349,17 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct net_device *net)
 	 * We might need to rebuild the header on tx failure.
 	 */
 	memcpy(&hdr_buf, skb->data, sizeof(hdr_buf));
-	skb_pull(skb, sizeof(hdr_buf));
-
 	proto = hdr_buf.h_proto;
+
+	switch (proto) {
+	case htons(ETH_P_ARP):
+	case htons(ETH_P_IP):
+		break;
+	default:
+		goto fail;
+	}
+
+	skb_pull(skb, sizeof(hdr_buf));
 	dg_size = skb->len;
 
 	/*
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH net-next (TAKE 4) 0/6] IPv6 over Firewire
From: YOSHIFUJI Hideaki @ 2013-03-25 18:25 UTC (permalink / raw)
  To: davem, stefanr; +Cc: netdev, linux1394-devel, stephan.gatzka, yoshfuji

This is take 4 of supporting IPv6 over Firewire (IEEE 1394) based on
RFC3146.

Take 3->4:
- Fix receiving 1394 ARP, which comes without arp$tha.
- Remove rfc3146 unit directory on module exit.
- other minor clean-ups - minimize diffs.

YOSHIFUJI Hideaki (6):
  firewire net: Accept IPv4 and ARP only.
  firewire net: Send L2 multicast via GASP.
  firewire net: Allocate address handler before registering net_device.
  firewire net: Ignore spd and max_payload advertised by ARP.
  firewire net, ipv4 arp: Extend hardware address and remove
    driver-level packet inspection.
  firewire net, ipv6: IPv6 over Firewire (RFC3146) support.

 drivers/firewire/Kconfig |    6 +-
 drivers/firewire/net.c   |  301 +++++++++++++++++++++-------------------------
 include/linux/if_arp.h   |   12 +-
 include/net/firewire.h   |   25 ++++
 net/ipv4/arp.c           |   27 ++++-
 net/ipv6/addrconf.c      |   20 ++-
 6 files changed, 213 insertions(+), 178 deletions(-)
 create mode 100644 include/net/firewire.h

-- 
1.7.9.5

^ permalink raw reply

* [PATCH] net: Print functions in /proc/net/ptype without the offset.
From: David Miller @ 2013-03-25 18:13 UTC (permalink / raw)
  To: netdev


It's always zero.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/core/net-procfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c
index 3174f19..569d355 100644
--- a/net/core/net-procfs.c
+++ b/net/core/net-procfs.c
@@ -271,7 +271,7 @@ static int ptype_seq_show(struct seq_file *seq, void *v)
 		else
 			seq_printf(seq, "%04x", ntohs(pt->type));
 
-		seq_printf(seq, " %-8s %pF\n",
+		seq_printf(seq, " %-8s %pf\n",
 			   pt->dev ? pt->dev->name : "", pt->func);
 	}
 
-- 
1.7.11.7

^ permalink raw reply related

* Re: [PATCH net] ipv6: fix bad free of addrconf_init_net
From: David Miller @ 2013-03-25 17:57 UTC (permalink / raw)
  To: honkiko; +Cc: netdev, stephen
In-Reply-To: <1364233965-17093-1-git-send-email-honkiko@gmail.com>

From: Hong Zhiguo <honkiko@gmail.com>
Date: Tue, 26 Mar 2013 01:52:45 +0800

> Signed-off-by: Hong Zhiguo <honkiko@gmail.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH net-next] netlink: add missing length check of rtnl msg
From: David Miller @ 2013-03-25 17:54 UTC (permalink / raw)
  To: honkiko; +Cc: netdev, stephen, tgraf
In-Reply-To: <1364232143-16754-1-git-send-email-honkiko@gmail.com>

From: Hong Zhiguo <honkiko@gmail.com>
Date: Tue, 26 Mar 2013 01:22:23 +0800

> When the legacy array rtm_min still exists, the length check within these 
> functions is covered by rtm_min[RTM_NEWTFILTER], rtm_min[RTM_NEWQDISC] 
> and rtm_min[RTM_NEWTCLASS].
> 
> But after Thomas Graf removed rtm_min several days ago, these checks are 
> missing. 
> 
> Other doit functions should be OK.
> 
> Signed-off-by: Hong Zhiguo <honkiko@gmail.com>

This looks good, Thomas please review.

^ permalink raw reply

* [PATCH net] ipv6: fix bad free of addrconf_init_net
From: Hong Zhiguo @ 2013-03-25 17:52 UTC (permalink / raw)
  To: netdev; +Cc: davem, stephen, Hong Zhiguo

Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
---
 net/ipv6/addrconf.c |   26 ++++++++++----------------
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index fa36a67..e7d81cd 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4852,26 +4852,20 @@ static void addrconf_sysctl_unregister(struct inet6_dev *idev)
 
 static int __net_init addrconf_init_net(struct net *net)
 {
-	int err;
+	int err = -ENOMEM;
 	struct ipv6_devconf *all, *dflt;
 
-	err = -ENOMEM;
-	all = &ipv6_devconf;
-	dflt = &ipv6_devconf_dflt;
+	all = kmemdup(&ipv6_devconf, sizeof(ipv6_devconf), GFP_KERNEL);
+	if (all == NULL)
+		goto err_alloc_all;
 
-	if (!net_eq(net, &init_net)) {
-		all = kmemdup(all, sizeof(ipv6_devconf), GFP_KERNEL);
-		if (all == NULL)
-			goto err_alloc_all;
+	dflt = kmemdup(&ipv6_devconf_dflt, sizeof(ipv6_devconf_dflt), GFP_KERNEL);
+	if (dflt == NULL)
+		goto err_alloc_dflt;
 
-		dflt = kmemdup(dflt, sizeof(ipv6_devconf_dflt), GFP_KERNEL);
-		if (dflt == NULL)
-			goto err_alloc_dflt;
-	} else {
-		/* these will be inherited by all namespaces */
-		dflt->autoconf = ipv6_defaults.autoconf;
-		dflt->disable_ipv6 = ipv6_defaults.disable_ipv6;
-	}
+	/* these will be inherited by all namespaces */
+	dflt->autoconf = ipv6_defaults.autoconf;
+	dflt->disable_ipv6 = ipv6_defaults.disable_ipv6;
 
 	net->ipv6.devconf_all = all;
 	net->ipv6.devconf_dflt = dflt;
-- 
1.7.10.4

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox