* Re: [PATCH net-next] sockopt: Make SO_BINDTODEVICE readable
From: Eric Dumazet @ 2012-10-22 21:52 UTC (permalink / raw)
To: Brian Haley; +Cc: Pavel Emelyanov, Linux Netdev List, David Miller
In-Reply-To: <5085BF0A.2030602@hp.com>
On Mon, 2012-10-22 at 17:47 -0400, Brian Haley wrote:
> On 10/22/2012 05:37 PM, Eric Dumazet wrote:
> > On Mon, 2012-10-22 at 17:20 -0400, Brian Haley wrote:
> >
> >> It's not much different from what's there:
> >>
> >> setsockopt("foo");
> >>
> >> rename foo -> bar
> >>
> >> index = getsockopt();
> >> if_indextoname(index) -> "bar"
> >>
> >> I more raised the issue since you pass a 'char *' to setsockopt() but an 'int *'
> >> to getsockopt(), I don't think any other value is non-symmetrical like this.
> >>
> >> -Brian
> >
> > I meant another cpu can be changing dev->name[] content while the
> > strcpy() is done, and you get a mangled devname, like "for" or "bao"
> > instead of "foo" or "bar"
>
> Even when holding the rcu_read_lock()? I'd have to hold the rtnl lock there?
Yes, rcu_read_lock() only makes sure the device doesnt disappear.
But its name can be changed.
You could use a seqcount_t, so that readers dont have to lock rtnl.
But do we really want to return a name here, I am not yet convinced.
^ permalink raw reply
* Re: [PATCH net-next] sockopt: Make SO_BINDTODEVICE readable
From: Ben Hutchings @ 2012-10-22 21:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Brian Haley, Pavel Emelyanov, Linux Netdev List, David Miller
In-Reply-To: <1350942738.8609.1375.camel@edumazet-glaptop>
On Mon, 2012-10-22 at 23:52 +0200, Eric Dumazet wrote:
> On Mon, 2012-10-22 at 17:47 -0400, Brian Haley wrote:
> > On 10/22/2012 05:37 PM, Eric Dumazet wrote:
> > > On Mon, 2012-10-22 at 17:20 -0400, Brian Haley wrote:
> > >
> > >> It's not much different from what's there:
> > >>
> > >> setsockopt("foo");
> > >>
> > >> rename foo -> bar
> > >>
> > >> index = getsockopt();
> > >> if_indextoname(index) -> "bar"
> > >>
> > >> I more raised the issue since you pass a 'char *' to setsockopt() but an 'int *'
> > >> to getsockopt(), I don't think any other value is non-symmetrical like this.
> > >>
> > >> -Brian
> > >
> > > I meant another cpu can be changing dev->name[] content while the
> > > strcpy() is done, and you get a mangled devname, like "for" or "bao"
> > > instead of "foo" or "bar"
> >
> > Even when holding the rcu_read_lock()? I'd have to hold the rtnl lock there?
>
> Yes, rcu_read_lock() only makes sure the device doesnt disappear.
>
> But its name can be changed.
>
> You could use a seqcount_t, so that readers dont have to lock rtnl.
>
> But do we really want to return a name here, I am not yet convinced.
If setsockopt() takes a name then it makes no sense that getsockopt()
would return an index. Perhaps an SO_BINDTOIFINDEX would be useful, but
let's not make SO_BINDTODEVICE mean two different things.
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] tcp: Reject invalid ack_seq to Fast Open sockets
From: Eric Dumazet @ 2012-10-22 21:59 UTC (permalink / raw)
To: H.K. Jerry Chu; +Cc: davem, netdev, ncardwell, ycheng
In-Reply-To: <1350941196-31224-1-git-send-email-hkchu@google.com>
On Mon, 2012-10-22 at 14:26 -0700, H.K. Jerry Chu wrote:
> From: Jerry Chu <hkchu@google.com>
>
> A packet with an invalid ack_seq may cause a TCP Fast Open socket to switch
> to the unexpected TCP_CLOSING state, triggering a BUG_ON kernel panic.
>
> When a FIN packet with an invalid ack_seq# arrives at a socket in
> the TCP_FIN_WAIT1 state, rather than discarding the packet, the current
> code will accept the FIN, causing state transition to TCP_CLOSING.
>
> This may be a small deviation from RFC793, which seems to say that the
> packet should be dropped. Unfortunately I did not expect this case for
> Fast Open hence it will trigger a BUG_ON panic.
>
> It turns out there is really nothing bad about a TFO socket going into
> TCP_CLOSING state so I could just remove the BUG_ON statements. But after
> some thought I think it's better to treat this case like TCP_SYN_RECV
> and return a RST to the confused peer who caused the unacceptable ack_seq
> to be generated in the first place.
>
> Signed-off-by: H.K. Jerry Chu <hkchu@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: listen(2) backlog changes in or around Linux 3.1?
From: Vijay Subramanian @ 2012-10-22 22:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: enh, Venkat Venkatsubra, netdev
In-Reply-To: <1350936519.8609.1239.camel@edumazet-glaptop>
>
> I wonder then if we dont need to retransmit the synack when req moves
> into accept_queue then ?
If I understood the code correctly, the socket moves into accept_queue
only when the
third ack (with or without data) comes in. So, there should be no need
to resend syn-ack. The issue is that there is no mechanism to promote
req sockets which have finished TWHS to accept_queue currently.
Socket can move into accept_queue only when third ack is processed.
If we stop resending synacks, then socket will move into accept_queue
when client sends data.
>
> Or else how the client can 'knows' it can send data to server ?
>From client's point of view, TWHS is finished. Client is already in
established state and
can even now send data. Currently, such packets with data will be
dropped if accept_queue is full.
If accept_queue is not full, socket moves into accept_queue and
established state and processes the data.
I think the only thing my patch does is reorder the tests so that
needless syn-ack retransmissions are stopped.
>
> All these facilities sound very complex and not really usable by clients
> (ie users not willing to wait more than few seconds anyway)
>
Fair enough. We can drop this if it is not worth the trouble or if I
have missed any other scenario.
Thanks for your review and time!
Vijay
^ permalink raw reply
* Re: Bug#690845: ethtool: incorrect WoL detection on Broadcom NX II rev < 12
From: Michael Chan @ 2012-10-22 22:54 UTC (permalink / raw)
To: Teodor MICU; +Cc: 690845, netdev
In-Reply-To: <CAG2Wgfdn52R2FYh77-2ZHCFVwe8d0MOv_4but6aOsU50jF-+Lg@mail.gmail.com>
On Mon, 2012-10-22 at 10:52 +0300, Teodor MICU wrote:
> 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708
> Gigabit Ethernet (rev 11)
It is 5708 B1, and due to some hardware limitations, ethtool initiated
WoL is not supported. Here's the code fragment in bnx2.c:
if ((CHIP_ID(bp) == CHIP_ID_5708_A0) ||
(CHIP_ID(bp) == CHIP_ID_5708_B0) ||
(CHIP_ID(bp) == CHIP_ID_5708_B1) ||
!(REG_RD(bp, BNX2_PCI_CONFIG_3) & BNX2_PCI_CONFIG_3_VAUX_PRESET)) {
bp->flags |= BNX2_FLAG_NO_WOL;
bp->wol = 0;
}
^ permalink raw reply
* Re: [nf-next PATCH v2] ipvs: fix build errors related to config option combinations
From: Simon Horman @ 2012-10-23 0:33 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Pablo Neira Ayuso, fengguang.wu, yuanhan.liu, netdev, lvs-devel,
netfilter-devel, Hans Schillstrom
In-Reply-To: <20121022192245.12620.84466.stgit@dragon>
On Mon, Oct 22, 2012 at 09:22:45PM +0200, Jesper Dangaard Brouer wrote:
> Fix two build error introduced by commit 63dca2c0:
> "ipvs: Fix faulty IPv6 extension header handling in IPVS"
>
> First build error was fairly trivial and can occur, when
> CONFIG_IP_VS_IPV6 is disabled.
>
> The second build error was tricky, and can occur when deselecting
> both all Netfilter and IPVS, but selecting CONFIG_IPV6. This is
> caused by "kernel/sysctl_binary.c" including "net/ip_vs.h", which
> includes "linux/netfilter_ipv6/ip6_tables.h" causing include
> of "include/linux/netfilter/x_tables.h" which then cannot find
> the typedef nf_hookfn.
>
> Fix this by only including "linux/netfilter_ipv6/ip6_tables.h" in
> case of CONFIG_IP_VS_IPV6 as its already used to guard the usage
> of ipv6_find_hdr().
Thanks, I have verified both of these fixes and I will send a pull
request ASAP.
I do wonder how we might get earlier test coverage of these kinds of problems.
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Reported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
>
> include/net/ip_vs.h | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> index a681ad6..68c69d5 100644
> --- a/include/net/ip_vs.h
> +++ b/include/net/ip_vs.h
> @@ -22,7 +22,7 @@
> #include <linux/ip.h>
> #include <linux/ipv6.h> /* for struct ipv6hdr */
> #include <net/ipv6.h>
> -#if IS_ENABLED(CONFIG_IPV6)
> +#if IS_ENABLED(CONFIG_IP_VS_IPV6)
> #include <linux/netfilter_ipv6/ip6_tables.h>
> #endif
> #if IS_ENABLED(CONFIG_NF_CONNTRACK)
> @@ -212,8 +212,9 @@ ip_vs_fill_iph_addr_only(int af, const struct sk_buff *skb,
> (struct ipv6hdr *)skb_network_header(skb);
> iphdr->saddr.in6 = iph->saddr;
> iphdr->daddr.in6 = iph->daddr;
> - } else {
> + } else
> #endif
> + {
> const struct iphdr *iph =
> (struct iphdr *)skb_network_header(skb);
> iphdr->saddr.ip = iph->saddr;
>
^ permalink raw reply
* [GIT PULL nf-next] IPVS for 3.8
From: Simon Horman @ 2012-10-23 0:50 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Hans Schillstrom, Hans Schillstrom,
Jesper Dangaard Brouer, Fengguang Wu, Yuanhan Liu
Hi Pablo,
please consider the following build fix from Jesper for 3.8.
----------------------------------------------------------------
The following changes since commit bcc58c4d9141160d6448e4589acbd46e5c647518:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next (2012-10-22 12:30:41 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git master
for you to fetch changes up to 54d83efa44aac87983f973abb42c508a25a2b554:
ipvs: fix build errors related to config option combinations (2012-10-23 09:23:40 +0900)
----------------------------------------------------------------
Jesper Dangaard Brouer (1):
ipvs: fix build errors related to config option combinations
include/net/ip_vs.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH] ipvs: fix build errors related to config option combinations
From: Simon Horman @ 2012-10-23 0:50 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Hans Schillstrom, Hans Schillstrom,
Jesper Dangaard Brouer, Fengguang Wu, Yuanhan Liu, Simon Horman
In-Reply-To: <1350953451-19441-1-git-send-email-horms@verge.net.au>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Fix two build error introduced by commit 63dca2c0:
"ipvs: Fix faulty IPv6 extension header handling in IPVS"
First build error was fairly trivial and can occur, when
CONFIG_IP_VS_IPV6 is disabled.
The second build error was tricky, and can occur when deselecting
both all Netfilter and IPVS, but selecting CONFIG_IPV6. This is
caused by "kernel/sysctl_binary.c" including "net/ip_vs.h", which
includes "linux/netfilter_ipv6/ip6_tables.h" causing include
of "include/linux/netfilter/x_tables.h" which then cannot find
the typedef nf_hookfn.
Fix this by only including "linux/netfilter_ipv6/ip6_tables.h" in
case of CONFIG_IP_VS_IPV6 as its already used to guard the usage
of ipv6_find_hdr().
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index a681ad6..68c69d5 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -22,7 +22,7 @@
#include <linux/ip.h>
#include <linux/ipv6.h> /* for struct ipv6hdr */
#include <net/ipv6.h>
-#if IS_ENABLED(CONFIG_IPV6)
+#if IS_ENABLED(CONFIG_IP_VS_IPV6)
#include <linux/netfilter_ipv6/ip6_tables.h>
#endif
#if IS_ENABLED(CONFIG_NF_CONNTRACK)
@@ -212,8 +212,9 @@ ip_vs_fill_iph_addr_only(int af, const struct sk_buff *skb,
(struct ipv6hdr *)skb_network_header(skb);
iphdr->saddr.in6 = iph->saddr;
iphdr->daddr.in6 = iph->daddr;
- } else {
+ } else
#endif
+ {
const struct iphdr *iph =
(struct iphdr *)skb_network_header(skb);
iphdr->saddr.ip = iph->saddr;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] tcp: Reject invalid ack_seq to Fast Open sockets
From: Neal Cardwell @ 2012-10-23 0:56 UTC (permalink / raw)
To: H.K. Jerry Chu; +Cc: David Miller, Netdev, Yuchung Cheng
In-Reply-To: <1350941196-31224-1-git-send-email-hkchu@google.com>
On Mon, Oct 22, 2012 at 5:26 PM, H.K. Jerry Chu <hkchu@google.com> wrote:
> From: Jerry Chu <hkchu@google.com>
>
> A packet with an invalid ack_seq may cause a TCP Fast Open socket to switch
> to the unexpected TCP_CLOSING state, triggering a BUG_ON kernel panic.
>
> When a FIN packet with an invalid ack_seq# arrives at a socket in
> the TCP_FIN_WAIT1 state, rather than discarding the packet, the current
> code will accept the FIN, causing state transition to TCP_CLOSING.
>
> This may be a small deviation from RFC793, which seems to say that the
> packet should be dropped. Unfortunately I did not expect this case for
> Fast Open hence it will trigger a BUG_ON panic.
>
> It turns out there is really nothing bad about a TFO socket going into
> TCP_CLOSING state so I could just remove the BUG_ON statements. But after
> some thought I think it's better to treat this case like TCP_SYN_RECV
> and return a RST to the confused peer who caused the unacceptable ack_seq
> to be generated in the first place.
>
> Signed-off-by: H.K. Jerry Chu <hkchu@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
^ permalink raw reply
* Re: Bug#690845: ethtool: incorrect WoL detection on Broadcom NX II rev < 12
From: Ben Hutchings @ 2012-10-23 1:45 UTC (permalink / raw)
To: Michael Chan, 690845; +Cc: Teodor MICU, netdev
In-Reply-To: <1350946459.8764.145.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
On Mon, 2012-10-22 at 15:54 -0700, Michael Chan wrote:
> On Mon, 2012-10-22 at 10:52 +0300, Teodor MICU wrote:
> > 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708
> > Gigabit Ethernet (rev 11)
>
> It is 5708 B1, and due to some hardware limitations, ethtool initiated
> WoL is not supported.
[...]
Well we knew that much! Is the problem that the system firmware 'owns'
the WoL control registers so the host can't safely change them? Is it
possible to *read* the WoL configuration, if not to change it?
(If even that is not possible, the correct thing to do might be for
ETHTOOL_GWOL to return 'don't know' (EOPNOTSUPP) for this device. But
since ethtool_ops::get_wol (and various other operations) can't return
an error, that would require you to define a separate instance of
ethtool_ops with get_wol = NULL. I should look at fixing that...)
Ben.
--
Ben Hutchings
Humour is the best antidote to reality.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Bug#690845: ethtool: incorrect WoL detection on Broadcom NX II rev < 12
From: Michael Chan @ 2012-10-23 2:18 UTC (permalink / raw)
To: Ben Hutchings; +Cc: 690845, Teodor MICU, netdev
In-Reply-To: <1350956707.5283.48.camel@deadeye.wl.decadent.org.uk>
On Tue, 2012-10-23 at 02:45 +0100, Ben Hutchings wrote:
> Well we knew that much! Is the problem that the system firmware 'owns'
> the WoL control registers so the host can't safely change them? Is it
> possible to *read* the WoL configuration, if not to change it?
It's a hardware problem and I don't understand all the details. There
is an internal PCIX to PCIE bridge on this chip and it gates the NIC's
PME event. During S5 reset, the bridge gets reset by the BIOS and the
WoL setting done by the driver will no longer work. Newer chip revs
have fixed the problem in hardware.
The driver reads the pre-boot WoL setting from NVRAM and it becomes the
ethtool WoL default setting. Apparently, it is also not working in this
case. I know that it doesn't work on some LOM designs as the setting is
actually in BIOS NVRAM as opposed to NIC NVRAM.
^ permalink raw reply
* RE: [PATCH net-next 1/2] r8169: enable ALDPS for power saving
From: hayeswang @ 2012-10-23 2:24 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20121022192748.GA16370@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, October 23, 2012 3:28 AM
> To: Hayeswang
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> jean@google.com
> Subject: Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving
>
[...]
> > @@ -687,6 +687,7 @@ enum features {
> > RTL_FEATURE_WOL = (1 << 0),
> > RTL_FEATURE_MSI = (1 << 1),
> > RTL_FEATURE_GMII = (1 << 2),
> > + RTL_FEATURE_EXTENDED = (1 << 3),
>
> Is there a specific reason why it is not named RTL_FEATURE_ALDPS ?
>
> RTL_FEATURE_EXTENDED is anything but enlightning.
>
The flag is determined if the firmware is loaded. It doesn't mean to enable
ALDPS. Besides ALDPS, the firmware includes the other features about power
saving, performance, hw behavior, and so on. Thus, I think it is the extended
feature. Any suggestion?
[...]
> > @@ -6391,6 +6433,8 @@ static void
> rtl8169_net_suspend(struct net_device *dev)
> > {
> > struct rtl8169_private *tp = netdev_priv(dev);
> >
> > + tp->features &= ~RTL_FEATURE_EXTENDED;
> > +
>
> The commit message does not explain this part.
>
> What are you trying to achieve ?
I don't sure if the firmware code still exists and works after hibernation. I
clear the flag for safe. It would be set again after loading firmware. It is
used to make sure to enable ALDPS with firmware.
>
> After this patch the driver would look like:
> 1. disable ALDPS before setting firmware (unmodified by patch)
> RTL_GIGA_MAC_VER_29 "RTL8105e"
> RTL_GIGA_MAC_VER_30 "RTL8105e"
> RTL_GIGA_MAC_VER_37 "RTL8402"
> RTL_GIGA_MAC_VER_39 "RTL8106e"
>
> 2. apply_firmware (unmodified by patch)
> RTL_GIGA_MAC_VER_25 "RTL8168d/8111d"
> RTL_GIGA_MAC_VER_26 "RTL8168d/8111d"
> RTL_GIGA_MAC_VER_29 "RTL8105e"
> RTL_GIGA_MAC_VER_30 "RTL8105e"
> RTL_GIGA_MAC_VER_32 "RTL8168e/8111e"
> RTL_GIGA_MAC_VER_33 "RTL8168e/8111e"
> RTL_GIGA_MAC_VER_34 "RTL8168evl/8111evl"
> RTL_GIGA_MAC_VER_35 "RTL8168f/8111f"
> RTL_GIGA_MAC_VER_36 "RTL8168f/8111f"
> RTL_GIGA_MAC_VER_37 "RTL8402"
> RTL_GIGA_MAC_VER_38 "RTL8411"
> RTL_GIGA_MAC_VER_39 "RTL8106e"
> RTL_GIGA_MAC_VER_40 "RTL8168g/8111g"
>
> 3. enable ALDPS after firmware
> RTL_GIGA_MAC_VER_34 "RTL8168evl/8111evl"
> RTL_GIGA_MAC_VER_35 "RTL8168f/8111f"
> RTL_GIGA_MAC_VER_36 "RTL8168f/8111f"
> RTL_GIGA_MAC_VER_37 "RTL8402"
> RTL_GIGA_MAC_VER_38 "RTL8411"
> RTL_GIGA_MAC_VER_39 "RTL8106e"
> RTL_GIGA_MAC_VER_40 "RTL8168g/8111g"
>
> The disable/enable ALDPS code is not trivially balanced.
>
> Do we exactly perform the required ALDPS operations ? Nothing more,
> nothing less ?
>
Because the different design between the giga nic and 10/100M nic, the behavior
would be different. For example, you couldn't disable the ALDPS of the giga nic
directly just like the 10/100M (8136 series) one. The giga nic would disable
ALDPS automatically when loading firmware, but the 8136 series wouldn't.
Best Regards,
Hayes
^ permalink raw reply
* 3.7-rc2 regression : file copied to CIFS-mounted directory corrupted
From: Jongman Heo @ 2012-10-23 3:30 UTC (permalink / raw)
To: linux-kernel, netdev, edumazet
Hi, all,
With 3.7-rc2, I noticed that file copied to CIFS-mounted directory is corrupted.
Integrity is checked by md5sum.
1. get md5sum of file located on local (ext4) disk
2. copy the file to CIFS-mounted directory
3. check md5sum of the copied file
Host : Windows 7
Guest : Fedora 16 on VMWare
Kernel : 3.7-rc2
Shared directory exists on Windows 7 Host, and Linux Guest on VMware mounts it using CIFS.
I thought it was related to CIFS or VFS changes, but it wasn't.
Below is a git bisect log, and first bad commit is 5640f768, "net: use a per task frag allocator".
Reverting the commit 5640f768 fixes the corruption issue on CIFS directory.
During revert, I got conflict in net/ipv4/raw.c. I took "parent of 5640f76" hunk to resolve it.
# git bisect log
git bisect start
# bad: [6f0c0580b70c89094b3422ba81118c7b959c7556] Linux 3.7-rc2
git bisect bad 6f0c0580b70c89094b3422ba81118c7b959c7556
# good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6
git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9
# good: [fec344e3f31aa911297cd3a4639432d983b1f324] cifs: change cifs_call_async to use smb_rqst structs
git bisect good fec344e3f31aa911297cd3a4639432d983b1f324
# good: [3d6d854a13844223b603fd7a16a4a4a4afd62c72] cifs: add FL_CLOSE to fl_flags mask in cifs_read_flock
git bisect good 3d6d854a13844223b603fd7a16a4a4a4afd62c72
# good: [f065fd099fc475333fc7a55677a7f64764445d55] CIFS: Fix possible freed pointer dereference in CIFS_SessSetup
git bisect good f065fd099fc475333fc7a55677a7f64764445d55
# bad: [b7a10626c8bc88fd097a8bb4486c89558f89320c] [CIFS] WARN_ON_ONCE if kernel_sendmsg() returns -ENOSPC
git bisect bad b7a10626c8bc88fd097a8bb4486c89558f89320c
# good: [1d4ab9077681b7cce60ff46e3a42fe2dafa0b83d] [CIFS] Fix indentation of fs/cifs/Kconfig entries
git bisect good 1d4ab9077681b7cce60ff46e3a42fe2dafa0b83d
# bad: [aab174f0df5d72d31caccf281af5f614fa254578] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad aab174f0df5d72d31caccf281af5f614fa254578
# good: [d9a807461fc8cc0d6ba589ea0730d139122af012] Merge tag 'usb-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
git bisect good d9a807461fc8cc0d6ba589ea0730d139122af012
# good: [a20acf99f75e49271381d65db097c9763060a1e8] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next
git bisect good a20acf99f75e49271381d65db097c9763060a1e8
# bad: [d379142bc4d9b78cdd9fc5aa696ca1ea083fb7d4] be2net: fixup log messages
git bisect bad d379142bc4d9b78cdd9fc5aa696ca1ea083fb7d4
# good: [2a35cfa591ac63f17815c2d9432b799e37527980] r8169: add D-Link DGE-560T identifiers.
git bisect good 2a35cfa591ac63f17815c2d9432b799e37527980
# good: [9316f0e3c6ba524d8fa14bfded048b252891931a] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
git bisect good 9316f0e3c6ba524d8fa14bfded048b252891931a
# good: [623df484a777f3c00c1ea3d6a7565b8d8ac688a1] tcp: extract code to compute SYNACK RTT
git bisect good 623df484a777f3c00c1ea3d6a7565b8d8ac688a1
# bad: [c523530ce17defe6b28ccfe622c506488f430866] can: c_can: fix segfault during rmmod
git bisect bad c523530ce17defe6b28ccfe622c506488f430866
# good: [6ee584be3ee30f72dec8a8ca87bc10824e27a631] netfilter: nfnetlink_queue: add NFQA_CAP_LEN attribute
git bisect good 6ee584be3ee30f72dec8a8ca87bc10824e27a631
# good: [725b9c0425f54450d1f376befb85dae706ea0c7a] qeth: cleanup channel path descriptor function
git bisect good 725b9c0425f54450d1f376befb85dae706ea0c7a
# good: [0cf833aefaa85bbfce3ff70485e5534e09254773] net: loopback: set default mtu to 64K
git bisect good 0cf833aefaa85bbfce3ff70485e5534e09254773
# bad: [9e49e88958feb41ec701fa34b44723dabadbc28c] filter: add XOR instruction for use with X/K
git bisect bad 9e49e88958feb41ec701fa34b44723dabadbc28c
# bad: [5640f7685831e088fe6c2e1f863a6805962f8e81] net: use a per task frag allocator
git bisect bad 5640f7685831e088fe6c2e1f863a6805962f8e81
# good: [b98b8babd6e3370fadb7c6eaacb00eb2f6344a6c] gianfar: Change default HW Tx queue scheduling mode
git bisect good b98b8babd6e3370fadb7c6eaacb00eb2f6344a6c
^ permalink raw reply
* ipv4 gro receive IHL
From: David Miller @ 2012-10-23 3:46 UTC (permalink / raw)
To: edumazet; +Cc: netdev
Eric why do we force the length field to '5' in the ip_fast_csum()
call of inet_gro_receive()? This happened as part of commit
a9e050f4e7f9d36afe0dcc0bddba864ee442715e ("net: tcp: GRO should be ECN
friendly")
This will cause the checksum check to fail for any IPV4 header with
options.
If that's intended, the way to do this is to reject by checking the
iph->ihl value, rather than doing so obscurely via the checksum call.
^ permalink raw reply
* [PATCH net-next 00/15] 6lowpan: Some more bug fixes
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hello,
This patch serie fixes a few bugs within the 6lowpan modules and prepares the
integration of the serial driver that will be submitted in a subsequent patch serie.
It should apply cleanly on the latest net-next.
Regards,
Tony Cheneau
Tony Cheneau (15):
6lowpan: lowpan_is_iid_16_bit_compressable() does not detect
compressable address correctly
6lowpan: next header is not properly set upon decompression of a UDP
header.
6lowpan: always enable link-layer acknowledgments
mac802154: turn on ACK when enabled by the upper layers
6lowpan: use short IEEE 802.15.4 addresses for broadcast destination
6lowpan: fix first fragment (FRAG1) handling
6lowpan: store fragment tag values per device instead of net stack
wide
6lowpan: obtain IEEE802.15.4 sequence number from the MAC layer
6lowpan: add a new parameter in sysfs to turn on/off ACK request at
MAC layer
6lowpan: use the PANID provided by the device instead of a static
value
6lowpan: modify udp compression/uncompression to match the standard
6lowpan: make memory allocation atomic during 6lowpan header creation
mac802154: make mem alloc ATOMIC to prevent "scheduling while atomic"
crashes
mac802154: remove unnecessary spinlocks
mac802154: re-introduce MAC primitives required to send/receive
packets
net/ieee802154/6lowpan.c | 144 ++++++++++++++++++++++++++++++++++++---------
net/ieee802154/6lowpan.h | 14 +++--
net/mac802154/mac802154.h | 2 +
net/mac802154/mac_cmd.c | 22 +++++++-
net/mac802154/mib.c | 33 +++++++----
net/mac802154/wpan.c | 4 +-
6 files changed, 172 insertions(+), 47 deletions(-)
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply
* [PATCH net-next 01/15] 6lowpan: lowpan_is_iid_16_bit_compressable() does not detect compressable address correctly
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1350965397-12384-1-git-send-email-tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
The current test is not RFC6282 compliant. The same issue has been found
out and fixed in Contiki. This patch is basicaly a port of their fix.
Signed-off-by: Tony Cheneau <tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
---
net/ieee802154/6lowpan.h | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index 8c2251f..efd1a57 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h
@@ -87,14 +87,16 @@
#define is_addr_link_local(a) (((a)->s6_addr16[0]) == 0x80FE)
/*
- * check whether we can compress the IID to 16 bits,
- * it's possible for unicast adresses with first 49 bits are zero only.
- */
+* check whether we can compress the IID to 16 bits,
+* it's possible for unicast adresses with first 49 bits are zero only.
+*/
#define lowpan_is_iid_16_bit_compressable(a) \
((((a)->s6_addr16[4]) == 0) && \
- (((a)->s6_addr16[5]) == 0) && \
- (((a)->s6_addr16[6]) == 0) && \
- ((((a)->s6_addr[14]) & 0x80) == 0))
+ (((a)->s6_addr[10]) == 0) && \
+ (((a)->s6_addr[11]) == 0xff) && \
+ (((a)->s6_addr[12]) == 0xfe) && \
+ (((a)->s6_addr[13]) == 0))
+
/* multicast address */
#define is_addr_mcast(a) (((a)->s6_addr[0]) == 0xFF)
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply related
* [PATCH net-next 02/15] 6lowpan: next header is not properly set upon decompression of a UDP header.
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1350965397-12384-1-git-send-email-tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
This causes a drop of the UDP packet.
Signed-off-by: Tony Cheneau <tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
---
net/ieee802154/6lowpan.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 6d42c17..b53a71a4 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -913,9 +913,12 @@ lowpan_process_data(struct sk_buff *skb)
}
/* UDP data uncompression */
- if (iphc0 & LOWPAN_IPHC_NH_C)
+ if (iphc0 & LOWPAN_IPHC_NH_C) {
if (lowpan_uncompress_udp_header(skb))
goto drop;
+ hdr.nexthdr = UIP_PROTO_UDP;
+ }
+
/* Not fragmented package */
hdr.payload_len = htons(skb->len);
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply related
* [PATCH net-next 03/15] 6lowpan: always enable link-layer acknowledgments
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1350965397-12384-1-git-send-email-tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
This feature is especially important when using fragmentation, because
the reassembly mechanism can not recover from the loss of a fragment.
Note that some hardware ignore this flag and not will not transmit any
acknowledgments if this is set.
Signed-off-by: Tony Cheneau <tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
---
net/ieee802154/6lowpan.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index b53a71a4..49d91df 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -589,6 +589,10 @@ static int lowpan_header_create(struct sk_buff *skb,
mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+ /* request acknowledgment when possible */
+ if (!lowpan_is_addr_broadcast(daddr))
+ mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
+
return dev_hard_header(skb, lowpan_dev_info(dev)->real_dev,
type, (void *)&da, (void *)&sa, skb->len);
}
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply related
* [PATCH net-next 04/15] mac802154: turn on ACK when enabled by the upper layers
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1350965397-12384-1-git-send-email-tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
Signed-off-by: Tony Cheneau <tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
---
net/mac802154/wpan.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/mac802154/wpan.c b/net/mac802154/wpan.c
index f30f6d4..d6aea7f 100644
--- a/net/mac802154/wpan.c
+++ b/net/mac802154/wpan.c
@@ -149,6 +149,8 @@ static int mac802154_header_create(struct sk_buff *skb,
head[pos++] = mac_cb(skb)->seq; /* DSN/BSN */
fc = mac_cb_type(skb);
+ if (mac_cb_is_ackreq(skb))
+ fc |= IEEE802154_FC_ACK_REQ;
if (!saddr) {
spin_lock_bh(&priv->mib_lock);
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply related
* [PATCH net-next 05/15] 6lowpan: use short IEEE 802.15.4 addresses for broadcast destination
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1350965397-12384-1-git-send-email-tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
It is intended that the IEEE 802.15.4 standard uses the 0xFFFF short address (2
bytes) for message broadcasting.
Signed-off-by: Tony Cheneau <tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
---
net/ieee802154/6lowpan.c | 21 +++++++++++++--------
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 49d91df..8a2ee95 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -577,21 +577,26 @@ static int lowpan_header_create(struct sk_buff *skb,
* this isn't implemented in mainline yet, so currently we assign 0xff
*/
{
+ mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+
/* prepare wpan address data */
sa.addr_type = IEEE802154_ADDR_LONG;
sa.pan_id = 0xff;
-
- da.addr_type = IEEE802154_ADDR_LONG;
- da.pan_id = 0xff;
-
- memcpy(&(da.hwaddr), daddr, 8);
memcpy(&(sa.hwaddr), saddr, 8);
- mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+ da.pan_id = 0xff;
+ /* if the destination address is the broadcast address,
+ use short address */
+ if (lowpan_is_addr_broadcast(daddr)) {
+ da.addr_type = IEEE802154_ADDR_SHORT;
+ da.short_addr = IEEE802154_ADDR_BROADCAST;
+ } else {
+ da.addr_type = IEEE802154_ADDR_LONG;
+ memcpy(&(da.hwaddr), daddr, 8);
- /* request acknowledgment when possible */
- if (!lowpan_is_addr_broadcast(daddr))
+ /* request acknowledgment */
mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
+ }
return dev_hard_header(skb, lowpan_dev_info(dev)->real_dev,
type, (void *)&da, (void *)&sa, skb->len);
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply related
* [PATCH net-next 06/15] 6lowpan: fix first fragment (FRAG1) handling
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1350965397-12384-1-git-send-email-tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
The first fragment, FRAG1, must contain some payload according to the
specs. However, as it is currently written, the first fragment will
remain empty and only contain the 6lowpan headers.
This patch also extract the transport layer information from the first
fragment. This information is later on use when uncompressing UDP
header.
Signed-off-by: Tony Cheneau <tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
---
net/ieee802154/6lowpan.c | 54 +++++++++++++++++++++++++++++++++++----------
1 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 8a2ee95..38cecaf 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -654,7 +654,7 @@ static void lowpan_fragment_timer_expired(unsigned long entry_addr)
}
static struct lowpan_fragment *
-lowpan_alloc_new_frame(struct sk_buff *skb, u8 len, u16 tag)
+lowpan_alloc_new_frame(struct sk_buff *skb, u16 len, u16 tag)
{
struct lowpan_fragment *frame;
@@ -735,6 +735,18 @@ lowpan_process_data(struct sk_buff *skb)
/* adds the 3 MSB to the 8 LSB to retrieve the 11 bits length */
len = ((iphc0 & 7) << 8) | slen;
+ if ((iphc0 & LOWPAN_DISPATCH_MASK) == LOWPAN_DISPATCH_FRAG1) {
+ pr_debug("%s received a FRAG1 packet (tag: %d, "
+ "size of the entire IP packet: %d)"
+ , __func__, tag, len);
+ } else { /* FRAGN */
+ if (lowpan_fetch_skb_u8(skb, &offset))
+ goto unlock_and_drop;
+ pr_debug("%s received a FRAGN packet (tag: %d, "
+ "size of the entire IP packet: %d, "
+ "offset: %d)", __func__, tag, len, offset * 8);
+ }
+
/*
* check if frame assembling with the same tag is
* already in progress
@@ -749,17 +761,13 @@ lowpan_process_data(struct sk_buff *skb)
/* alloc new frame structure */
if (!found) {
+ pr_debug("%s first fragment received for tag %d, "
+ "begin packet reassembly", __func__, tag);
frame = lowpan_alloc_new_frame(skb, len, tag);
if (!frame)
goto unlock_and_drop;
}
- if ((iphc0 & LOWPAN_DISPATCH_MASK) == LOWPAN_DISPATCH_FRAG1)
- goto unlock_and_drop;
-
- if (lowpan_fetch_skb_u8(skb, &offset)) /* fetch offset */
- goto unlock_and_drop;
-
/* if payload fits buffer, copy it */
if (likely((offset * 8 + skb->len) <= frame->length))
skb_copy_to_linear_data_offset(frame->skb, offset * 8,
@@ -777,6 +785,10 @@ lowpan_process_data(struct sk_buff *skb)
list_del(&frame->list);
spin_unlock_bh(&flist_lock);
+ pr_debug("%s successfully reassembled fragment "
+ "(tag %d)", __func__, tag);
+
+
dev_kfree_skb(skb);
skb = frame->skb;
kfree(frame);
@@ -976,13 +988,13 @@ static int lowpan_get_mac_header_length(struct sk_buff *skb)
static int
lowpan_fragment_xmit(struct sk_buff *skb, u8 *head,
- int mlen, int plen, int offset)
+ int mlen, int plen, int offset, int type)
{
struct sk_buff *frag;
int hlen, ret;
- /* if payload length is zero, therefore it's a first fragment */
- hlen = (plen == 0 ? LOWPAN_FRAG1_HEAD_SIZE : LOWPAN_FRAGN_HEAD_SIZE);
+ hlen = (type == LOWPAN_DISPATCH_FRAG1 ? LOWPAN_FRAG1_HEAD_SIZE :
+ LOWPAN_FRAGN_HEAD_SIZE);
lowpan_raw_dump_inline(__func__, "6lowpan fragment header", head, hlen);
@@ -1025,7 +1037,18 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
head[2] = tag >> 8;
head[3] = tag & 0xff;
- err = lowpan_fragment_xmit(skb, head, header_length, 0, 0);
+ err = lowpan_fragment_xmit(skb, head, header_length, LOWPAN_FRAG_SIZE,
+ 0, LOWPAN_DISPATCH_FRAG1);
+
+ if (err) {
+#if DEBUG
+ pr_debug("%s unable to send FRAG1 packet (tag: %d)",
+ __func__, tag);
+#endif /* DEBUG */
+ goto exit;
+ }
+
+ offset = LOWPAN_FRAG_SIZE;
/* next fragment header */
head[0] &= ~LOWPAN_DISPATCH_FRAG1;
@@ -1040,10 +1063,17 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
len = payload_length - offset;
err = lowpan_fragment_xmit(skb, head, header_length,
- len, offset);
+ len, offset, LOWPAN_DISPATCH_FRAGN);
+ if (err) {
+ pr_debug("%s unable to send a subsequent FRAGN packet "
+ "(tag: %d, offset: %d", __func__, tag, offset);
+ goto exit;
+ }
+
offset += len;
}
+exit:
return err;
}
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply related
* [PATCH net-next 07/15] 6lowpan: store fragment tag values per device instead of net stack wide
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1350965397-12384-1-git-send-email-tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
Signed-off-by: Tony Cheneau <tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
---
net/ieee802154/6lowpan.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 38cecaf..eb8003b 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -104,6 +104,7 @@ static const u8 lowpan_llprefix[] = {0xfe, 0x80};
struct lowpan_dev_info {
struct net_device *real_dev; /* real WPAN device ptr */
struct mutex dev_list_mtx; /* mutex for list ops */
+ unsigned short fragment_tag;
};
struct lowpan_dev_record {
@@ -120,7 +121,6 @@ struct lowpan_fragment {
struct list_head list; /* fragments list */
};
-static unsigned short fragment_tag;
static LIST_HEAD(lowpan_fragments);
static DEFINE_SPINLOCK(flist_lock);
@@ -1022,14 +1022,14 @@ lowpan_fragment_xmit(struct sk_buff *skb, u8 *head,
}
static int
-lowpan_skb_fragmentation(struct sk_buff *skb)
+lowpan_skb_fragmentation(struct sk_buff *skb, struct net_device *dev)
{
int err, header_length, payload_length, tag, offset = 0;
u8 head[5];
header_length = lowpan_get_mac_header_length(skb);
payload_length = skb->len - header_length;
- tag = fragment_tag++;
+ tag = lowpan_dev_info(dev)->fragment_tag++;
/* first fragment header */
head[0] = LOWPAN_DISPATCH_FRAG1 | ((payload_length >> 8) & 0x7);
@@ -1095,7 +1095,7 @@ static netdev_tx_t lowpan_xmit(struct sk_buff *skb, struct net_device *dev)
}
pr_debug("frame is too big, fragmentation is needed\n");
- err = lowpan_skb_fragmentation(skb);
+ err = lowpan_skb_fragmentation(skb, dev);
error:
dev_kfree_skb(skb);
out:
@@ -1216,6 +1216,7 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
return -ENODEV;
lowpan_dev_info(dev)->real_dev = real_dev;
+ lowpan_dev_info(dev)->fragment_tag = 0;
mutex_init(&lowpan_dev_info(dev)->dev_list_mtx);
entry = kzalloc(sizeof(struct lowpan_dev_record), GFP_KERNEL);
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply related
* [PATCH net-next 08/15] 6lowpan: obtain IEEE802.15.4 sequence number from the MAC layer
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1350965397-12384-1-git-send-email-tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
This patch sets the sequence number in the frame format. Without this
fix, the sequence number is always set to 0. This makes trafic analysis
very hard.
Signed-off-by: Tony Cheneau <tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
---
net/ieee802154/6lowpan.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index eb8003b..24b83fa 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -578,6 +578,7 @@ static int lowpan_header_create(struct sk_buff *skb,
*/
{
mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+ mac_cb(skb)->seq = ieee802154_mlme_ops(dev)->get_dsn(dev);
/* prepare wpan address data */
sa.addr_type = IEEE802154_ADDR_LONG;
@@ -1123,6 +1124,12 @@ static u16 lowpan_get_short_addr(const struct net_device *dev)
return ieee802154_mlme_ops(real_dev)->get_short_addr(real_dev);
}
+static u8 lowpan_get_dsn(const struct net_device *dev)
+{
+ struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
+ return ieee802154_mlme_ops(real_dev)->get_dsn(real_dev);
+}
+
static struct header_ops lowpan_header_ops = {
.create = lowpan_header_create,
};
@@ -1136,6 +1143,7 @@ static struct ieee802154_mlme_ops lowpan_mlme = {
.get_pan_id = lowpan_get_pan_id,
.get_phy = lowpan_get_phy,
.get_short_addr = lowpan_get_short_addr,
+ .get_dsn = lowpan_get_dsn,
};
static void lowpan_setup(struct net_device *dev)
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply related
* [PATCH net-next 09/15] 6lowpan: add a new parameter in sysfs to turn on/off ACK request at MAC layer
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1350965397-12384-1-git-send-email-tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
Signed-off-by: Tony Cheneau <tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
---
net/ieee802154/6lowpan.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 24b83fa..f8fcdae 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -62,6 +62,8 @@
#include "6lowpan.h"
+static bool req_802154_ack;
+
/* TTL uncompression values */
static const u8 lowpan_ttl_values[] = {0, 1, 64, 255};
@@ -596,7 +598,8 @@ static int lowpan_header_create(struct sk_buff *skb,
memcpy(&(da.hwaddr), daddr, 8);
/* request acknowledgment */
- mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
+ if (req_802154_ack)
+ mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
}
return dev_hard_header(skb, lowpan_dev_info(dev)->real_dev,
@@ -1366,6 +1369,10 @@ static void __exit lowpan_cleanup_module(void)
}
module_init(lowpan_init_module);
+
+module_param(req_802154_ack, bool, 0644);
+MODULE_PARM_DESC(req_802154_ack, "request link-layer (i.e. IEEE 802.15.4) acknowledgments");
+
module_exit(lowpan_cleanup_module);
MODULE_LICENSE("GPL");
MODULE_ALIAS_RTNL_LINK("lowpan");
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply related
* [PATCH net-next 10/15] 6lowpan: use the PANID provided by the device instead of a static value
From: Tony Cheneau @ 2012-10-23 4:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Alan Ott,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1350965397-12384-1-git-send-email-tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
Signed-off-by: Tony Cheneau <tony.cheneau-jNfjcPZKvDhg9hUCZPvPmw@public.gmane.org>
---
net/ieee802154/6lowpan.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index f8fcdae..9711038 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -584,10 +584,12 @@ static int lowpan_header_create(struct sk_buff *skb,
/* prepare wpan address data */
sa.addr_type = IEEE802154_ADDR_LONG;
- sa.pan_id = 0xff;
+ sa.pan_id = ieee802154_mlme_ops(dev)->get_pan_id(dev);
+
memcpy(&(sa.hwaddr), saddr, 8);
+ /* intra-PAN communications */
+ da.pan_id = ieee802154_mlme_ops(dev)->get_pan_id(dev);
- da.pan_id = 0xff;
/* if the destination address is the broadcast address,
use short address */
if (lowpan_is_addr_broadcast(daddr)) {
--
1.7.8.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox