* Re: [RFC 0/7] genetlink: reduce ops size and complexity
From: Johannes Berg @ 2013-11-14 14:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1384420486-8713-1-git-send-email-johannes@sipsolutions.net>
On Thu, 2013-11-14 at 10:14 +0100, Johannes Berg wrote:
> This series of patches updates a few genetlink users and then
> makes the ops a static const array, reducing kernel size and
> code complexity.
FWIW, for the full series (including patches 8 and 9) we get
drivers/net/team/team.c | 2
drivers/net/wireless/mac80211_hwsim.c | 2
include/net/genetlink.h | 17 +---
kernel/taskstats.c | 39 +++------
net/core/drop_monitor.c | 2
net/hsr/hsr_netlink.c | 46 ++++-------
net/ieee802154/ieee802154.h | 19 ++++
net/ieee802154/netlink.c | 28 +++++--
net/ieee802154/nl-mac.c | 61 ++-------------
net/ieee802154/nl-phy.c | 37 +--------
net/ipv4/tcp_metrics.c | 2
net/irda/irnetlink.c | 2
net/l2tp/l2tp_netlink.c | 2
net/netfilter/ipvs/ip_vs_ctl.c | 2
net/netlabel/netlabel_cipso_v4.c | 2
net/netlabel/netlabel_mgmt.c | 2
net/netlabel/netlabel_unlabeled.c | 2
net/netlink/genetlink.c | 133
+++++++++-------------------------
net/nfc/netlink.c | 2
net/openvswitch/datapath.c | 10 +-
net/wimax/op-msg.c | 25 ------
net/wimax/op-reset.c | 17 ----
net/wimax/op-rfkill.c | 21 -----
net/wimax/op-state-get.c | 17 ----
net/wimax/stack.c | 79 ++++++++++----------
net/wimax/wimax-internal.h | 7 +
net/wireless/nl80211.c | 2
27 files changed, 190 insertions(+), 390 deletions(-)
johannes
^ permalink raw reply
* Re: [PATCH 2/3] net: sched: htb: fix condition of failure when rate is 0
From: Eric Dumazet @ 2013-11-14 14:37 UTC (permalink / raw)
To: Yang Yingliang; +Cc: davem, netdev
In-Reply-To: <1384419714-24364-3-git-send-email-yangyingliang@huawei.com>
On Thu, 2013-11-14 at 17:01 +0800, Yang Yingliang wrote:
> When rate32 is 0, it doesn't means wrong.
> Because htb support 64bit rates now, it
> could use rate64.
> So change the condition, when rate32 and
> rate64 are both 0, it goes to failure.
This is not needed at all and buggy.
User land is supposed to provide a not zero 32bit rate.
If it does, too bad. We have to fail.
^ permalink raw reply
* Re: [PATCH 1/3] net: sched: tbf: fix calculation of max_size
From: Eric Dumazet @ 2013-11-14 14:38 UTC (permalink / raw)
To: Yang Yingliang; +Cc: davem, netdev
In-Reply-To: <1384419714-24364-2-git-send-email-yangyingliang@huawei.com>
On Thu, 2013-11-14 at 17:01 +0800, Yang Yingliang wrote:
> Current max_size is caluated from rate table.
> Now, the rate table has been replaced and it's
> not proper to caculate max_size with rate64.
> Use psched_ns_t2l to calculate the max_size.
>
> psched_ns_t2l():convert time in ns to length in
> bytes which to determinate how many bytes can be
> sent in given time.
I have no evidence you fix a real bug.
Please provide a tc script and show us it breaks.
Also CC Jesper you wrote this code.
^ permalink raw reply
* Re: [PATCH 0/2] Netfilter SYNPROXY mss and wscale bugfix
From: Jesper Dangaard Brouer @ 2013-11-14 14:41 UTC (permalink / raw)
To: Martin Topholm; +Cc: pablo, brouer, kaber, netfilter-devel, netdev
In-Reply-To: <1384439731-16296-1-git-send-email-mph@one.com>
On Thu, 14 Nov 2013 15:35:29 +0100
Martin Topholm <mph@one.com> wrote:
> The following series fixes two bugs we have discovered in the netfilter
> module SYNPROXY.
>
> The first is related to the mss option not getting transferred to the
> backend servers.
>
> And the second it related to passing of the windows scaling option.
>
> Martin Topholm (2):
> netfilter: synproxy: send mss option to backend
> netfilter: synproxy: correct wscale option passing
>
> net/ipv4/netfilter/ipt_SYNPROXY.c | 1 +
> net/ipv6/netfilter/ip6t_SYNPROXY.c | 1 +
> net/netfilter/nf_synproxy_core.c | 7 ++++---
> 3 files changed, 6 insertions(+), 3 deletions(-)
ACK series
I have already reviewed the patches offlist with Martin and helped him
on howto submit patches etc.. Nice work Martin :-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Vlad Yasevich @ 2013-11-14 14:41 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG, Veaceslav Falico, Vlad Yasevich
Cc: Linux Netdev List
In-Reply-To: <5284DE65.40105@profihost.ag>
On 11/14/2013 09:29 AM, Stefan Priebe - Profihost AG wrote:
> Am 14.11.2013 15:27, schrieb Vlad Yasevich:
>> On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
>>> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>>>> Can you try out attached patch please. I ran it in my environment and
>>>> always get promisc link when attaching devices to the bridge.
>>>
>>> It's interesting, actually, why do we need to check for IFF_UP at all
>>> when
>>> changing flags.
>>>
>>> The addition of IFF_UP goes up to:
>>>
>>> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
>>> Author: Patrick McHardy <kaber@trash.net>
>>> Date: Tue Oct 7 15:26:48 2008 -0700
>>>
>>> net: only invoke dev->change_rx_flags when device is UP
>>>
>>> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a
>>> VLAN
>>> device down that is in promiscous mode:
>>>
>>> When the VLAN device is set down, the promiscous count on the real
>>> device is decremented by one by vlan_dev_stop(). When removing the
>>> promiscous flag from the VLAN device afterwards, the promiscous
>>> count on the real device is decremented a second time by the
>>> vlan_change_rx_flags() callback.
>>>
>>> ... snip ...
>>>
>>
>> This was applied in 2.6.27 timeframe.
>>
>>> However, I'm not sure that this is still needed, cause:
>>>
>>> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
>>> Author: Matthijs Kooijman <matthijs@stdin.nl>
>>> Date: Mon Oct 31 04:53:13 2011 +0000
>>>
>>> vlan: Don't propagate flag changes on down interfaces.
>>>
>>> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
>>> IFF_PROMISC
>>> flags are cleared or set on the underlying interface. So, if these
>>> flags
>>> are changed on a vlan interface that is not up, the flags underlying
>>> interface might be set or cleared twice.
>>>
>>> Only propagating flag changes when a device is up makes sure this
>>> does
>>> not happen. It also makes sure that an underlying device is not
>>> set to
>>> promiscuous or allmulti mode for a vlan device that is down.
>>>
>>> ... snip ...
>>>
>>
>> And this in 3.2. So how did this work for Stefan in 3.9? Unless there
>> is something in Ubuntu that changed how the stacked interfaces are
>> configured and is keeping interfaces down longer then it used to.
>
> Stop here ;-) in 3.9 it was the other way round.
>
> This one worked:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 \ vmbr1.3000
>> \ ---- tap114i1
>
How are you attaching tap to the vlan device? Or is it attached to
vmbr1?
> this one did not:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 ----- bond1.3000 --- vmbr1v3000
>> \ ---- tap114i1
>
> Now with the patch - the 2nd one works the first one does not.
Ok, in this case, you have a VLAN (bond1.3000) configured on top of
bond interface. That vlan is then attached to the bridge (vmbr1v3000).
The tap interface for your VM (tap114i1) is also attached to the same
bridge. In this case, VM will receive only traffic for VLAN 3000 and
it we receive it untagged.
I guess I'd like to understand what you are trying to achieve.
Thanks working with us on this.
-vlad
>
> Stefan
>
>>> which fixed completely the initial issue with vlans.
>>>
>>> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(),
>>> and
>>> let the drivers using it handle its own logic, as vlan does?
>>>
>>
>> This should work, but this might regress a few drivers. Looking through
>> the callers of dev_set_promiscuity at least DSA driver suffers
>> the same fate as VLAN.
>>
>> -vlad
>>
>>> Something like this:
>>>
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index 8ffc52e..9615cd7 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
>>> *dev, int flags)
>>> {
>>> const struct net_device_ops *ops = dev->netdev_ops;
>>>
>>> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
>>> + if (ops->ndo_change_rx_flags)
>>> ops->ndo_change_rx_flags(dev, flags);
>>> }
>>>
>>>
>>>>
>>>> Thanks
>>>> -vlad
>>
^ permalink raw reply
* [PATCH 0/2] Netfilter SYNPROXY mss and wscale bugfix
From: Martin Topholm @ 2013-11-14 14:35 UTC (permalink / raw)
To: pablo; +Cc: brouer, kaber, netfilter-devel, netdev
The following series fixes two bugs we have discovered in the netfilter
module SYNPROXY.
The first is related to the mss option not getting transferred to the
backend servers.
And the second it related to passing of the windows scaling option.
Martin Topholm (2):
netfilter: synproxy: send mss option to backend
netfilter: synproxy: correct wscale option passing
net/ipv4/netfilter/ipt_SYNPROXY.c | 1 +
net/ipv6/netfilter/ip6t_SYNPROXY.c | 1 +
net/netfilter/nf_synproxy_core.c | 7 ++++---
3 files changed, 6 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 1/2] netfilter: synproxy: send mss option to backend
From: Martin Topholm @ 2013-11-14 14:35 UTC (permalink / raw)
To: pablo; +Cc: brouer, kaber, netfilter-devel, netdev
In-Reply-To: <1384439731-16296-1-git-send-email-mph@one.com>
When the synproxy_parse_options is called on the client ack the mss
option will not be present. Consequently mss wont be included in the
backend syn packet, which falls back to 536 bytes mss.
Therefore XT_SYNPROXY_OPT_MSS is explicitly flagged when recovering mss
value from cookie.
Signed-off-by: Martin Topholm <mph@one.com>
Reviewed-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/ipv4/netfilter/ipt_SYNPROXY.c | 1 +
net/ipv6/netfilter/ip6t_SYNPROXY.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/netfilter/ipt_SYNPROXY.c b/net/ipv4/netfilter/ipt_SYNPROXY.c
index 01cffea..f13bd91 100644
--- a/net/ipv4/netfilter/ipt_SYNPROXY.c
+++ b/net/ipv4/netfilter/ipt_SYNPROXY.c
@@ -244,6 +244,7 @@ synproxy_recv_client_ack(const struct synproxy_net *snet,
this_cpu_inc(snet->stats->cookie_valid);
opts->mss = mss;
+ opts->options |= XT_SYNPROXY_OPT_MSS;
if (opts->options & XT_SYNPROXY_OPT_TIMESTAMP)
synproxy_check_timestamp_cookie(opts);
diff --git a/net/ipv6/netfilter/ip6t_SYNPROXY.c b/net/ipv6/netfilter/ip6t_SYNPROXY.c
index bf9f612..f78f41a 100644
--- a/net/ipv6/netfilter/ip6t_SYNPROXY.c
+++ b/net/ipv6/netfilter/ip6t_SYNPROXY.c
@@ -259,6 +259,7 @@ synproxy_recv_client_ack(const struct synproxy_net *snet,
this_cpu_inc(snet->stats->cookie_valid);
opts->mss = mss;
+ opts->options |= XT_SYNPROXY_OPT_MSS;
if (opts->options & XT_SYNPROXY_OPT_TIMESTAMP)
synproxy_check_timestamp_cookie(opts);
^ permalink raw reply related
* [PATCH net] ip6tnl: fix use after free of fb_tnl_dev
From: Nicolas Dichtel @ 2013-11-14 14:47 UTC (permalink / raw)
To: rostedt
Cc: linux-kernel, stable, gregkh, williams, linux-rt-users, lclaudio,
davem, netdev, Nicolas Dichtel, Willem de Bruijn
In-Reply-To: <20131113211430.1ad3bb7d@gandalf.local.home>
Bug has been introduced by commit bb8140947a24 ("ip6tnl: allow to use rtnl ops
on fb tunnel").
When ip6_tunnel.ko is unloaded, FB device is delete by rtnl_link_unregister()
and then we try to use the pointer in ip6_tnl_destroy_tunnels().
Let's add an handler for dellink, which will never remove the FB tunnel. With
this patch it will no more be possible to remove it via 'ip link del ip6tnl0',
but it's safer.
The same fix was already proposed by Willem de Bruijn <willemb@google.com> for
sit interfaces.
CC: Willem de Bruijn <willemb@google.com>
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/ip6_tunnel.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 583b77e2f69b..c1e11b5d6ccc 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1635,6 +1635,15 @@ static int ip6_tnl_changelink(struct net_device *dev, struct nlattr *tb[],
return ip6_tnl_update(t, &p);
}
+static void ip6_tnl_dellink(struct net_device *dev, struct list_head *head)
+{
+ struct net *net = dev_net(dev);
+ struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
+
+ if (dev != ip6n->fb_tnl_dev)
+ unregister_netdevice_queue(dev, head);
+}
+
static size_t ip6_tnl_get_size(const struct net_device *dev)
{
return
@@ -1699,6 +1708,7 @@ static struct rtnl_link_ops ip6_link_ops __read_mostly = {
.validate = ip6_tnl_validate,
.newlink = ip6_tnl_newlink,
.changelink = ip6_tnl_changelink,
+ .dellink = ip6_tnl_dellink,
.get_size = ip6_tnl_get_size,
.fill_info = ip6_tnl_fill_info,
};
@@ -1715,9 +1725,9 @@ static struct xfrm6_tunnel ip6ip6_handler __read_mostly = {
.priority = 1,
};
-static void __net_exit ip6_tnl_destroy_tunnels(struct ip6_tnl_net *ip6n)
+static void __net_exit ip6_tnl_destroy_tunnels(struct net *net)
{
- struct net *net = dev_net(ip6n->fb_tnl_dev);
+ struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
struct net_device *dev, *aux;
int h;
struct ip6_tnl *t;
@@ -1785,10 +1795,8 @@ err_alloc_dev:
static void __net_exit ip6_tnl_exit_net(struct net *net)
{
- struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
-
rtnl_lock();
- ip6_tnl_destroy_tunnels(ip6n);
+ ip6_tnl_destroy_tunnels(net);
rtnl_unlock();
}
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCH net] sit: fix use after free of fb_tunnel_dev
From: Eric Dumazet @ 2013-11-14 14:47 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: davem, edumazet, nicolas.dichtel, netdev
In-Reply-To: <1384396058-26850-1-git-send-email-willemb@google.com>
On Wed, 2013-11-13 at 21:27 -0500, Willem de Bruijn wrote:
> Bug: The fallback device is created in sit_init_net and assumed to be
> freed in sit_exit_net. First, it is dereferenced in that function, in
> sit_destroy_tunnels:
>
> struct net *net = dev_net(sitn->fb_tunnel_dev);
>
> Prior to this, rtnl_unlink_register has removed all devices that match
> rtnl_link_ops == sit_link_ops.
>
> Commit 205983c43700 added the line
>
> + sitn->fb_tunnel_dev->rtnl_link_ops = &sit_link_ops;
>
> which cases the fallback device to match here and be freed before it
> is last dereferenced.
>
> Fix: This commit adds an explicit .delllink callback to sit_link_ops
> that skips deallocation at rtnl_unlink_register for the fallback
> device. This mechanism is comparable to the one in ip_tunnel.
>
> It also modifies sit_destroy_tunnels and its only caller sit_exit_net
> to avoid the offending dereference in the first place. That double
> lookup is more complicated than required.
>
> Test: The bug is only triggered when CONFIG_NET_NS is enabled. It
> causes a GPF only when CONFIG_DEBUG_SLAB is enabled. Verified that
> this bug exists at the mentioned commit, at davem-net HEAD and at
> 3.11.y HEAD. Verified that it went away after applying this patch.
>
> Fixes: 205983c43700 ("sit: allow to use rtnl ops on fb tunnel")
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: Cannot send unicast Ethernet Frame from tap0 to tap1 via bridge
From: Vlad Yasevich @ 2013-11-14 14:52 UTC (permalink / raw)
To: Albert Krenz, netdev
In-Reply-To: <CAPRaSD6LX4BP51u0kJ6r7OEQHPyykrS+9we9bK6GnB3hbWRAVQ@mail.gmail.com>
On 11/14/2013 06:09 AM, Albert Krenz wrote:
> Hello together,
> i am experiencing a strange behaviour in a bridge which bridges two
> tap Interfaces (namely tap0 and tap1) that are generated by two
> C-Applications.
>
> It looks like the following:
>
> +------------------------+
> +-----------------------+
> | |
> | |
> | Application 1 | ------- tap0 ----- br1 ---- tap1 ----- |
> Application 2 |
> | |
> | |
> +------------------------+
> +-----------------------+
>
> Application 1 creates tap0 and Application 2 creates tap1. The
> creation of the devices is done like in
> https://www.kernel.org/doc/Documentation/networking/tuntap.txt
> Both Applications acces their respective tap-device via File-IO. The
> bridge should bridge the network devices of both tap's.
>
> Here are the MAC-addresses of both tap devices (they only differ in
> the last byte):
> tap0: XX:XX:XX:XX:XX:B4
> tap1: XX:XX:XX:XX:XX:B3
>
> What i want to accomplish is sending an Ethernet Frame (Layer 2, so no
> IP Frames) from Application 1 to Application 2 and vice versa.
> Therefore i am periodically (1 time per second) writing a Frame with
> Dst-addr. of tap1 and Src-addr. of tap0 and vice-versa, to the
> File-descriptor of the respectiv tap-device.
This is your problem. You are trying to use the mac addresses assigned
to the tap devices themselves. Those mac addresses identify the ports
of the bridge and anything destined to those mac addresses is consumed
by the bridge itself.
This works just like any other bridge/switch. You typically address
your packets to some device that sits behind the port, not to the port
itself.
> I can now check the traversing of the Frame via Wireshark from tap0 to
> br1, but it never gets to tap1 and therefore Application 2 never
> receives a Frame. Also in the other direction the Frames never pass
> through br1 but get stuck.
>
> If i am not using the MAC-addr. of the TAP Devices but a random
> unknown Dst-addr like XX:XX:XX:XX:XX:F0 (MAC address not known in the
> bridge) it works like a charm and the Frame passes through the bridge
> and is received by Application 1 or Application 2.
> The same goes for Broadcast/Multicast addresses.
>
> I then tried disabling network Filtering via:
> echo 0 > bridge-nf-call-arptables
> echo 0 > bridge-nf-call-iptables
> echo 0 > bridge-nf-call-ip6tables
> but this didn't do the trick.
>
>
> What also did not work was setting tap0/tap1/br1 into promiscuous
> mode. Maybe i first have to add a routing rule via ebtables? I have
> tried:
> ebtables - A FORWARD -i br1 -o br1 -j ACCEPT
> which i found on the internet and did also not work.
>
> My Questions is now: is it possible to bridge two tap devices to send
> RAW Ethernet Frames between two Applications? I think this should work
> cause it is similar to an KVM/QEMU setup where multiple Virtual Guest
> OS's are also able to communicate between each other (via IP frames).
> So does anyone have an idea what i am missing?
Right. This works in QEMU/KVM because the packets are addressed to the
guest which has a different HW address the the bridge port.
What you can do is assign your application a mac address that is
generated from the mac address of the tap device. Then use those
addresses and it will work.
-vlad
>
> Greetings
> Albert Krenz
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
From: Vlad Yasevich @ 2013-11-14 15:03 UTC (permalink / raw)
To: Michal Kubecek, netdev; +Cc: David S. Miller, Patrick McHardy, John Fastabend
In-Reply-To: <b4ca4f2204f0ffb0bd7f959192462944a8d846a4.1384436410.git.mkubecek@suse.cz>
On 11/14/2013 09:00 AM, Michal Kubecek wrote:
> Introduce helper function macvlan_dev_real_dev which returns the
> underlying device of a macvlan device, similar to vlan_dev_real_dev()
> for 802.1q VLAN devices.
>
> v2: IFF_MACVLAN flag and equivalent of is_macvlan_dev() were
> introduced in the meantime
>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
> ---
> include/linux/if_macvlan.h | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
> index c270285..ac9aab2 100644
> --- a/include/linux/if_macvlan.h
> +++ b/include/linux/if_macvlan.h
> @@ -119,4 +119,20 @@ extern int macvlan_link_register(struct rtnl_link_ops *ops);
> extern netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
> struct net_device *dev);
>
> +#if IS_ENABLED(CONFIG_MACVLAN)
> +static inline struct net_device *
> +macvlan_dev_real_dev(const struct net_device *dev)
> +{
> + struct macvlan_dev *macvlan = netdev_priv(dev);
> +
> + return macvlan->lowerdev;
> +}
> +#else
> +static inline struct net_device *
> +macvlan_dev_real_dev(const struct net_device *dev)
> +{
> + return NULL;
> +}
> +#endif
> +
You may want to do the same here as was done for vlan_dev_real_dev().
This function is not intended to be called blindly and should always
be called after netif_is_macvlan().
-vlad
> #endif /* _LINUX_IF_MACVLAN_H */
>
^ permalink raw reply
* Re: Cannot send unicast Ethernet Frame from tap0 to tap1 via bridge
From: Albert Krenz @ 2013-11-14 15:08 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev
In-Reply-To: <5284E3C1.6030905@gmail.com>
ok, understood. Didn't know that the bridge handels the assigned
network devices as their own ports. Thought it's working like a
regular switch which ports have no mac address.
Thanks for your help.
Greetings
Albert Krenz
2013/11/14 Vlad Yasevich <vyasevich@gmail.com>:
> On 11/14/2013 06:09 AM, Albert Krenz wrote:
>>
>> Hello together,
>> i am experiencing a strange behaviour in a bridge which bridges two
>> tap Interfaces (namely tap0 and tap1) that are generated by two
>> C-Applications.
>>
>> It looks like the following:
>>
>> +------------------------+
>> +-----------------------+
>> | |
>> | |
>> | Application 1 | ------- tap0 ----- br1 ---- tap1 ----- |
>> Application 2 |
>> | |
>> | |
>> +------------------------+
>> +-----------------------+
>>
>> Application 1 creates tap0 and Application 2 creates tap1. The
>> creation of the devices is done like in
>> https://www.kernel.org/doc/Documentation/networking/tuntap.txt
>> Both Applications acces their respective tap-device via File-IO. The
>> bridge should bridge the network devices of both tap's.
>>
>> Here are the MAC-addresses of both tap devices (they only differ in
>> the last byte):
>> tap0: XX:XX:XX:XX:XX:B4
>> tap1: XX:XX:XX:XX:XX:B3
>>
>> What i want to accomplish is sending an Ethernet Frame (Layer 2, so no
>> IP Frames) from Application 1 to Application 2 and vice versa.
>> Therefore i am periodically (1 time per second) writing a Frame with
>> Dst-addr. of tap1 and Src-addr. of tap0 and vice-versa, to the
>> File-descriptor of the respectiv tap-device.
>
>
> This is your problem. You are trying to use the mac addresses assigned
> to the tap devices themselves. Those mac addresses identify the ports of
> the bridge and anything destined to those mac addresses is consumed
> by the bridge itself.
>
> This works just like any other bridge/switch. You typically address
> your packets to some device that sits behind the port, not to the port
> itself.
>
>
>> I can now check the traversing of the Frame via Wireshark from tap0 to
>> br1, but it never gets to tap1 and therefore Application 2 never
>> receives a Frame. Also in the other direction the Frames never pass
>> through br1 but get stuck.
>>
>> If i am not using the MAC-addr. of the TAP Devices but a random
>> unknown Dst-addr like XX:XX:XX:XX:XX:F0 (MAC address not known in the
>> bridge) it works like a charm and the Frame passes through the bridge
>> and is received by Application 1 or Application 2.
>> The same goes for Broadcast/Multicast addresses.
>>
>> I then tried disabling network Filtering via:
>> echo 0 > bridge-nf-call-arptables
>> echo 0 > bridge-nf-call-iptables
>> echo 0 > bridge-nf-call-ip6tables
>> but this didn't do the trick.
>>
>>
>> What also did not work was setting tap0/tap1/br1 into promiscuous
>> mode. Maybe i first have to add a routing rule via ebtables? I have
>> tried:
>> ebtables - A FORWARD -i br1 -o br1 -j ACCEPT
>> which i found on the internet and did also not work.
>>
>> My Questions is now: is it possible to bridge two tap devices to send
>> RAW Ethernet Frames between two Applications? I think this should work
>> cause it is similar to an KVM/QEMU setup where multiple Virtual Guest
>> OS's are also able to communicate between each other (via IP frames).
>> So does anyone have an idea what i am missing?
>
>
> Right. This works in QEMU/KVM because the packets are addressed to the
> guest which has a different HW address the the bridge port.
>
> What you can do is assign your application a mac address that is generated
> from the mac address of the tap device. Then use those
> addresses and it will work.
>
> -vlad
>
>>
>> Greetings
>> Albert Krenz
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: [RFC][PATCH 0/3] net_tstamp: Add SIOCGHWTSTAMP ioctl
From: Ben Hutchings @ 2013-11-14 15:10 UTC (permalink / raw)
To: Richard Cochran; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <20131114074118.GC4908@netboy>
On Thu, 2013-11-14 at 08:41 +0100, Richard Cochran wrote:
> On Thu, Nov 14, 2013 at 02:37:15AM +0000, Ben Hutchings wrote:
> > SIOCSHWTSTAMP returns the real configuration to the application
> > using it, but there is currently no way for any other
> > application to find out the configuration non-destructively.
>
> I guess that the reasoning behind the original interface is that an
> application only wants to know the settings when it needs a particular
> setting in order to operate correctly. This would make the query call
> pointless, since the application might as well just go ahead and set
> the values that it needs.
>
> Do you have a particular use case in mind?
The immediate motivation is wanting to include this information in
diagnostic reports.
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: linux-next: manual merge of the random tree with the net-next tree
From: Markos Chandras @ 2013-11-14 15:17 UTC (permalink / raw)
To: Stephen Rothwell, Daniel Borkmann
Cc: Theodore Ts'o, linux-next, linux-kernel, Hannes Frederic Sowa,
David Miller, netdev
In-Reply-To: <20131113074657.287f83d9669c8144865a77b6@canb.auug.org.au>
On 11/12/2013 08:46 PM, Stephen Rothwell wrote:
> Hi Daniel,
>
> On Tue, 12 Nov 2013 09:55:29 +0100 Daniel Borkmann <dborkman@redhat.com> wrote:
>>
>> On 11/12/2013 05:55 AM, Stephen Rothwell wrote:
>>>
>>> Today's linux-next merge of the random tree got a conflict in
>>> drivers/char/random.c between commit 0244ad004a54 ("random32: add
>>> prandom_reseed_late() and call when nonblocking pool becomes
>>> initialized") from the net-next tree and commit 301f0595c0e7 ("random:
>>> printk notifications for urandom pool initialization") from the random
>>> tree.
>>>
>>> I fixed it up (probably not properly - see below) and can carry the fix
>>> as necessary (no action is required).
>>
>> As per Hannes' suggestion, the result should look like (see cover
>> letter in [1]):
>>
>> if (r->entropy_total > 128) {
>> r->initialized = 1;
>> r->entropy_total = 0;
>> if (r == &nonblocking_pool) {
>> prandom_reseed_late();
>> pr_notice("random: %s pool is initialized\n",
>> r->name);
>> }
>> }
>
> I will use that from today. Thanks.
>
Hi Stephen,
This broke the build for MIPS for the malta_defconfig when using the
latest Mentor toolchain.
In file included from include/linux/fs.h:16:0,
from fs/fuse/fuse_i.h:13,
from fs/fuse/file.c:9:
fs/fuse/file.c: In function 'fuse_file_poll':
include/linux/rbtree.h:82:28: warning: 'parent' may be used
uninitialized in this function [-Wmaybe-uninitialized]
fs/fuse/file.c:2580:27: note: 'parent' was declared here
drivers/char/random.c: In function 'init_std_data':
drivers/char/random.c:1249:1: internal compiler error: in
add_insn_before, at emit-rtl.c:3857
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://sourcery.mentor.com/GNUToolchain/> for instructions.
make[2]: *** [drivers/char/random.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
If you want to reproduce it you can do the following steps:
- Get a MIPS Mentor toolchain from
https://sourcery.mentor.com/GNUToolchain/release2554
- make ARCH=mips CROSS_COMPILE=$TOOLCHAIN_PATH/bin/mips-linux-gnu-
malta_defconfig
- make ARCH=mips CROSS_COMPILE=$TOOLCHAIN_PATH/bin/mips-linux-gnu-
We are working with the toolchain group to come up with a workaround in
the code to resolve the problem.
--
markos
^ permalink raw reply
* Re: [PATCH net] ip6tnl: fix use after free of fb_tnl_dev
From: Willem de Bruijn @ 2013-11-14 15:40 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: rostedt, linux-kernel, stable, gregkh, williams, linux-rt-users,
lclaudio, David Miller, netdev
In-Reply-To: <1384440423-4275-1-git-send-email-nicolas.dichtel@6wind.com>
On Thu, Nov 14, 2013 at 9:47 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> Bug has been introduced by commit bb8140947a24 ("ip6tnl: allow to use rtnl ops
> on fb tunnel").
>
> When ip6_tunnel.ko is unloaded, FB device is delete by rtnl_link_unregister()
> and then we try to use the pointer in ip6_tnl_destroy_tunnels().
>
> Let's add an handler for dellink, which will never remove the FB tunnel. With
> this patch it will no more be possible to remove it via 'ip link del ip6tnl0',
> but it's safer.
>
> The same fix was already proposed by Willem de Bruijn <willemb@google.com> for
> sit interfaces.
>
> CC: Willem de Bruijn <willemb@google.com>
> Reported-by: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Also ran a test similar to the one for sit: `modprobe ip6_tunnel;
rmmod ip6_tunnel` with CONFIG_DEBUG_SLAB=y. This exposed the bug at
HEAD, completes successfully with the patch applied.
^ permalink raw reply
* netfilter: ipset: fix incorret comparison in hash_netnet4_data_equal()
From: Dave Jones @ 2013-11-14 15:41 UTC (permalink / raw)
To: netdev; +Cc: oliver
Both sides of the comparison are the same, looks like a cut-and-paste error.
Spotted by Coverity.
Signed-off-by: Dave Jones <davej@fedoraproject.org>
diff --git a/net/netfilter/ipset/ip_set_hash_netnet.c b/net/netfilter/ipset/ip_set_hash_netnet.c
index 2bc2dec20b00..6226803fc490 100644
--- a/net/netfilter/ipset/ip_set_hash_netnet.c
+++ b/net/netfilter/ipset/ip_set_hash_netnet.c
@@ -59,7 +59,7 @@ hash_netnet4_data_equal(const struct hash_netnet4_elem *ip1,
u32 *multi)
{
return ip1->ipcmp == ip2->ipcmp &&
- ip2->ccmp == ip2->ccmp;
+ ip1->ccmp == ip2->ccmp;
}
static inline int
^ permalink raw reply related
* [PATCH net-next 3/6] 6lowpan: fix udp byte ordering
From: Alexander Aring @ 2013-11-14 15:48 UTC (permalink / raw)
To: alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
jukka.rissanen-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <1384444132-1427-1-git-send-email-alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The incoming udp header in lowpan_compress_udp_header function is
already in network byte order.
Everytime we read this values for source and destination port we need
to convert this value to host byte order.
In the outcoming header we need to set this value in network byte order
which the upcoming process assumes.
Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/6lowpan.c | 41 ++++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index ad6755a..616f2f6 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -338,28 +338,30 @@ lowpan_compress_udp_header(u8 **hc06_ptr, struct sk_buff *skb)
{
struct udphdr *uh = udp_hdr(skb);
- if (((uh->source & LOWPAN_NHC_UDP_4BIT_MASK) ==
- LOWPAN_NHC_UDP_4BIT_PORT) &&
- ((uh->dest & LOWPAN_NHC_UDP_4BIT_MASK) ==
- LOWPAN_NHC_UDP_4BIT_PORT)) {
+ if (((ntohs(uh->source) & LOWPAN_NHC_UDP_4BIT_MASK) ==
+ LOWPAN_NHC_UDP_4BIT_PORT) &&
+ ((ntohs(uh->dest) & LOWPAN_NHC_UDP_4BIT_MASK) ==
+ LOWPAN_NHC_UDP_4BIT_PORT)) {
pr_debug("UDP header: both ports compression to 4 bits\n");
**hc06_ptr = LOWPAN_NHC_UDP_CS_P_11;
*(*hc06_ptr + 1) = /* subtraction is faster */
- (u8)((uh->dest - LOWPAN_NHC_UDP_4BIT_PORT) +
- ((uh->source & LOWPAN_NHC_UDP_4BIT_PORT) << 4));
+ (u8)((ntohs(uh->dest) - LOWPAN_NHC_UDP_4BIT_PORT) +
+ ((ntohs(uh->source) & LOWPAN_NHC_UDP_4BIT_PORT) << 4));
*hc06_ptr += 2;
- } else if ((uh->dest & LOWPAN_NHC_UDP_8BIT_MASK) ==
+ } else if ((ntohs(uh->dest) & LOWPAN_NHC_UDP_8BIT_MASK) ==
LOWPAN_NHC_UDP_8BIT_PORT) {
pr_debug("UDP header: remove 8 bits of dest\n");
**hc06_ptr = LOWPAN_NHC_UDP_CS_P_01;
memcpy(*hc06_ptr + 1, &uh->source, 2);
- *(*hc06_ptr + 3) = (u8)(uh->dest - LOWPAN_NHC_UDP_8BIT_PORT);
+ *(*hc06_ptr + 3) = (u8)(ntohs(uh->dest) -
+ LOWPAN_NHC_UDP_8BIT_PORT);
*hc06_ptr += 4;
- } else if ((uh->source & LOWPAN_NHC_UDP_8BIT_MASK) ==
+ } else if ((ntohs(uh->source) & LOWPAN_NHC_UDP_8BIT_MASK) ==
LOWPAN_NHC_UDP_8BIT_PORT) {
pr_debug("UDP header: remove 8 bits of source\n");
**hc06_ptr = LOWPAN_NHC_UDP_CS_P_10;
- *(*hc06_ptr + 1) = (u8)(uh->source - LOWPAN_NHC_UDP_8BIT_PORT);
+ *(*hc06_ptr + 1) = (u8)(ntohs(uh->source) -
+ LOWPAN_NHC_UDP_8BIT_PORT);
memcpy(*hc06_ptr + 2, &uh->dest, 2);
*hc06_ptr += 4;
} else {
@@ -421,20 +423,21 @@ lowpan_uncompress_udp_header(struct sk_buff *skb, struct udphdr *uh)
break;
case LOWPAN_NHC_UDP_CS_P_01:
memcpy(&uh->source, &skb->data[0], 2);
- uh->dest =
- skb->data[2] + LOWPAN_NHC_UDP_8BIT_PORT;
+ uh->dest = htons(skb->data[2] +
+ LOWPAN_NHC_UDP_8BIT_PORT);
skb_pull(skb, 3);
break;
case LOWPAN_NHC_UDP_CS_P_10:
- uh->source = skb->data[0] + LOWPAN_NHC_UDP_8BIT_PORT;
+ uh->source = htons(skb->data[0] +
+ LOWPAN_NHC_UDP_8BIT_PORT);
memcpy(&uh->dest, &skb->data[1], 2);
skb_pull(skb, 3);
break;
case LOWPAN_NHC_UDP_CS_P_11:
- uh->source =
- LOWPAN_NHC_UDP_4BIT_PORT + (skb->data[0] >> 4);
- uh->dest =
- LOWPAN_NHC_UDP_4BIT_PORT + (skb->data[0] & 0x0f);
+ uh->source = htons(LOWPAN_NHC_UDP_4BIT_PORT +
+ (skb->data[0] >> 4));
+ uh->dest = htons(LOWPAN_NHC_UDP_4BIT_PORT +
+ (skb->data[0] & 0x0f));
skb_pull(skb, 1);
break;
default:
@@ -443,7 +446,7 @@ lowpan_uncompress_udp_header(struct sk_buff *skb, struct udphdr *uh)
}
pr_debug("uncompressed UDP ports: src = %d, dst = %d\n",
- uh->source, uh->dest);
+ ntohs(uh->source), ntohs(uh->dest));
/* copy checksum */
memcpy(&uh->check, &skb->data[0], 2);
@@ -455,7 +458,7 @@ lowpan_uncompress_udp_header(struct sk_buff *skb, struct udphdr *uh)
* frame
*/
uh->len = htons(skb->len + sizeof(struct udphdr));
- pr_debug("uncompressed UDP length: src = %d", uh->len);
+ pr_debug("uncompressed UDP length: src = %d", ntohs(uh->len));
} else {
pr_debug("ERROR: unsupported NH format\n");
goto err;
--
1.8.4.2
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 4/6] 6lowpan: add udp warning for elided checksum
From: Alexander Aring @ 2013-11-14 15:48 UTC (permalink / raw)
To: alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
jukka.rissanen-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <1384444132-1427-1-git-send-email-alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Bit 5 of "UDP LOWPAN_NHC Format" indicate that the checksum can be elided.
The host need to calculate the udp checksum afterwards but this isn't
supported right now.
See:
http://tools.ietf.org/html/rfc6282#section-4.3.3
Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/6lowpan.c | 11 ++++++++---
net/ieee802154/6lowpan.h | 1 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 616f2f6..59678da 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -448,9 +448,14 @@ lowpan_uncompress_udp_header(struct sk_buff *skb, struct udphdr *uh)
pr_debug("uncompressed UDP ports: src = %d, dst = %d\n",
ntohs(uh->source), ntohs(uh->dest));
- /* copy checksum */
- memcpy(&uh->check, &skb->data[0], 2);
- skb_pull(skb, 2);
+ /* checksum */
+ if (tmp & LOWPAN_NHC_UDP_CS_C) {
+ pr_debug("checksum elided currently not supported");
+ goto err;
+ } else {
+ memcpy(&uh->check, &skb->data[0], 2);
+ skb_pull(skb, 2);
+ }
/*
* UDP lenght needs to be infered from the lower layers
diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index 2869c05..2bc231f 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h
@@ -231,6 +231,7 @@
#define LOWPAN_NHC_UDP_CS_P_10 0xF2 /* source = 0xF0 + 8bit inline,
dest = 16 bit inline */
#define LOWPAN_NHC_UDP_CS_P_11 0xF3 /* source & dest = 0xF0B + 4bit inline */
+#define LOWPAN_NHC_UDP_CS_C 0x04 /* checksum elided */
static inline bool lowpan_fetch_skb(struct sk_buff *skb,
void *data, const unsigned int len)
--
1.8.4.2
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 5/6] 6lowpan: udp use lowpan_fetch_skb function
From: Alexander Aring @ 2013-11-14 15:48 UTC (permalink / raw)
To: alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
jukka.rissanen-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <1384444132-1427-1-git-send-email-alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cleanup the lowpan_uncompress_udp_header function to use the
lowpan_fetch_skb function.
Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/6lowpan.c | 40 ++++++++++++++++++----------------------
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 59678da..6d7f253 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -405,40 +405,34 @@ static inline int lowpan_fetch_skb_u16(struct sk_buff *skb, u16 *val)
static int
lowpan_uncompress_udp_header(struct sk_buff *skb, struct udphdr *uh)
{
- u8 tmp;
-
- if (!uh)
- goto err;
+ bool fail;
+ u8 tmp = 0, val = 0;
- if (lowpan_fetch_skb_u8(skb, &tmp))
- goto err;
+ fail = lowpan_fetch_skb(skb, &tmp, 1);
if ((tmp & LOWPAN_NHC_UDP_MASK) == LOWPAN_NHC_UDP_ID) {
pr_debug("UDP header uncompression\n");
switch (tmp & LOWPAN_NHC_UDP_CS_P_11) {
case LOWPAN_NHC_UDP_CS_P_00:
- memcpy(&uh->source, &skb->data[0], 2);
- memcpy(&uh->dest, &skb->data[2], 2);
- skb_pull(skb, 4);
+ fail |= lowpan_fetch_skb(skb, &uh->source, 2);
+ fail |= lowpan_fetch_skb(skb, &uh->dest, 2);
break;
case LOWPAN_NHC_UDP_CS_P_01:
- memcpy(&uh->source, &skb->data[0], 2);
- uh->dest = htons(skb->data[2] +
- LOWPAN_NHC_UDP_8BIT_PORT);
- skb_pull(skb, 3);
+ fail |= lowpan_fetch_skb(skb, &uh->source, 2);
+ fail |= lowpan_fetch_skb(skb, &val, 1);
+ uh->dest = htons(val + LOWPAN_NHC_UDP_8BIT_PORT);
break;
case LOWPAN_NHC_UDP_CS_P_10:
- uh->source = htons(skb->data[0] +
- LOWPAN_NHC_UDP_8BIT_PORT);
- memcpy(&uh->dest, &skb->data[1], 2);
- skb_pull(skb, 3);
+ fail |= lowpan_fetch_skb(skb, &val, 1);
+ uh->source = htons(val + LOWPAN_NHC_UDP_8BIT_PORT);
+ fail |= lowpan_fetch_skb(skb, &uh->dest, 2);
break;
case LOWPAN_NHC_UDP_CS_P_11:
+ fail |= lowpan_fetch_skb(skb, &val, 1);
uh->source = htons(LOWPAN_NHC_UDP_4BIT_PORT +
- (skb->data[0] >> 4));
+ (val >> 4));
uh->dest = htons(LOWPAN_NHC_UDP_4BIT_PORT +
- (skb->data[0] & 0x0f));
- skb_pull(skb, 1);
+ (val & 0x0f));
break;
default:
pr_debug("ERROR: unknown UDP format\n");
@@ -453,8 +447,7 @@ lowpan_uncompress_udp_header(struct sk_buff *skb, struct udphdr *uh)
pr_debug("checksum elided currently not supported");
goto err;
} else {
- memcpy(&uh->check, &skb->data[0], 2);
- skb_pull(skb, 2);
+ fail |= lowpan_fetch_skb(skb, &uh->check, 2);
}
/*
@@ -469,6 +462,9 @@ lowpan_uncompress_udp_header(struct sk_buff *skb, struct udphdr *uh)
goto err;
}
+ if (fail)
+ goto err;
+
return 0;
err:
return -EINVAL;
--
1.8.4.2
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 6/6] 6lowpan: udp use subtraction on both conditions
From: Alexander Aring @ 2013-11-14 15:48 UTC (permalink / raw)
To: alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
jukka.rissanen-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <1384444132-1427-1-git-send-email-alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cleanup code to handle both calculation in the same way.
Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/6lowpan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 6d7f253..d8e1456 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -346,7 +346,7 @@ lowpan_compress_udp_header(u8 **hc06_ptr, struct sk_buff *skb)
**hc06_ptr = LOWPAN_NHC_UDP_CS_P_11;
*(*hc06_ptr + 1) = /* subtraction is faster */
(u8)((ntohs(uh->dest) - LOWPAN_NHC_UDP_4BIT_PORT) +
- ((ntohs(uh->source) & LOWPAN_NHC_UDP_4BIT_PORT) << 4));
+ ((ntohs(uh->source) - LOWPAN_NHC_UDP_4BIT_PORT) << 4));
*hc06_ptr += 2;
} else if ((ntohs(uh->dest) & LOWPAN_NHC_UDP_8BIT_MASK) ==
LOWPAN_NHC_UDP_8BIT_PORT) {
--
1.8.4.2
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH net-next 0/6] 6lowpan: udp compression/uncompression fix
From: Alexander Aring @ 2013-11-14 15:48 UTC (permalink / raw)
To: alex.bluesman.smirnov
Cc: linux-zigbee-devel, werner, jukka.rissanen, dbaryshkov, netdev,
Alexander Aring
The current 6LoWPAN udp compression/uncompression is completely broken.
This patch series fix a lot of udp compression/uncompression issues and
add support parsing with lowpan_fetch_skb function.
Alexander Aring (6):
6lowpan: fix udp nullpointer dereferencing
6lowpan: fix udp compress ordering
6lowpan: fix udp byte ordering
6lowpan: add udp warning for elided checksum
6lowpan: udp use lowpan_fetch_skb function
6lowpan: udp use subtraction on both conditions
net/ieee802154/6lowpan.c | 80 +++++++++++++++++++++++++-----------------------
net/ieee802154/6lowpan.h | 1 +
2 files changed, 43 insertions(+), 38 deletions(-)
--
1.8.4.2
^ permalink raw reply
* [PATCH net-next 2/6] 6lowpan: fix udp compress ordering
From: Alexander Aring @ 2013-11-14 15:48 UTC (permalink / raw)
To: alex.bluesman.smirnov
Cc: linux-zigbee-devel, werner, jukka.rissanen, dbaryshkov, netdev,
Alexander Aring
In-Reply-To: <1384444132-1427-1-git-send-email-alex.aring@gmail.com>
In case ((ntohs(uh->source) & LOWPAN_NHC_UDP_8BIT_MASK) the order of
uncompression is wrong. It's always first source port then destination
port as second.
See:
http://tools.ietf.org/html/rfc6282#section-4.3.3
"Fields carried in-line (in part or in whole) appear in the same order
as they do in the UDP header format"
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
---
net/ieee802154/6lowpan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 8633379..ad6755a 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -359,8 +359,8 @@ lowpan_compress_udp_header(u8 **hc06_ptr, struct sk_buff *skb)
LOWPAN_NHC_UDP_8BIT_PORT) {
pr_debug("UDP header: remove 8 bits of source\n");
**hc06_ptr = LOWPAN_NHC_UDP_CS_P_10;
- memcpy(*hc06_ptr + 1, &uh->dest, 2);
- *(*hc06_ptr + 3) = (u8)(uh->source - LOWPAN_NHC_UDP_8BIT_PORT);
+ *(*hc06_ptr + 1) = (u8)(uh->source - LOWPAN_NHC_UDP_8BIT_PORT);
+ memcpy(*hc06_ptr + 2, &uh->dest, 2);
*hc06_ptr += 4;
} else {
pr_debug("UDP header: can't compress\n");
--
1.8.4.2
^ permalink raw reply related
* [PATCH net-next 1/6] 6lowpan: fix udp nullpointer dereferencing
From: Alexander Aring @ 2013-11-14 15:48 UTC (permalink / raw)
To: alex.bluesman.smirnov
Cc: linux-zigbee-devel, werner, jukka.rissanen, dbaryshkov, netdev,
Alexander Aring
In-Reply-To: <1384444132-1427-1-git-send-email-alex.aring@gmail.com>
Sometimes a nullpointer dereferencing occurs because of using a wrong
pointer arithmetic in udp_uncompression.
This patch changes "**(hc06_ptr + 3)" to the right one "*(*hc06_ptr +
3)". Dereferencing like "**(hc06_ptr + 3)" works in a random case only.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
---
net/ieee802154/6lowpan.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 426b5df..8633379 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -344,7 +344,7 @@ lowpan_compress_udp_header(u8 **hc06_ptr, struct sk_buff *skb)
LOWPAN_NHC_UDP_4BIT_PORT)) {
pr_debug("UDP header: both ports compression to 4 bits\n");
**hc06_ptr = LOWPAN_NHC_UDP_CS_P_11;
- **(hc06_ptr + 1) = /* subtraction is faster */
+ *(*hc06_ptr + 1) = /* subtraction is faster */
(u8)((uh->dest - LOWPAN_NHC_UDP_4BIT_PORT) +
((uh->source & LOWPAN_NHC_UDP_4BIT_PORT) << 4));
*hc06_ptr += 2;
@@ -353,14 +353,14 @@ lowpan_compress_udp_header(u8 **hc06_ptr, struct sk_buff *skb)
pr_debug("UDP header: remove 8 bits of dest\n");
**hc06_ptr = LOWPAN_NHC_UDP_CS_P_01;
memcpy(*hc06_ptr + 1, &uh->source, 2);
- **(hc06_ptr + 3) = (u8)(uh->dest - LOWPAN_NHC_UDP_8BIT_PORT);
+ *(*hc06_ptr + 3) = (u8)(uh->dest - LOWPAN_NHC_UDP_8BIT_PORT);
*hc06_ptr += 4;
} else if ((uh->source & LOWPAN_NHC_UDP_8BIT_MASK) ==
LOWPAN_NHC_UDP_8BIT_PORT) {
pr_debug("UDP header: remove 8 bits of source\n");
**hc06_ptr = LOWPAN_NHC_UDP_CS_P_10;
memcpy(*hc06_ptr + 1, &uh->dest, 2);
- **(hc06_ptr + 3) = (u8)(uh->source - LOWPAN_NHC_UDP_8BIT_PORT);
+ *(*hc06_ptr + 3) = (u8)(uh->source - LOWPAN_NHC_UDP_8BIT_PORT);
*hc06_ptr += 4;
} else {
pr_debug("UDP header: can't compress\n");
--
1.8.4.2
^ permalink raw reply related
* Re: [RFC 0/7] genetlink: reduce ops size and complexity
From: Johannes Berg @ 2013-11-14 16:02 UTC (permalink / raw)
To: netdev
In-Reply-To: <1384420486-8713-1-git-send-email-johannes@sipsolutions.net>
On Thu, 2013-11-14 at 10:14 +0100, Johannes Berg wrote:
> This series of patches updates a few genetlink users and then
> makes the ops a static const array, reducing kernel size and
> code complexity.
>
> Comments welcome.
Well, there were some major bugs in here, but now it seems to work. I'll
repost properly with everybody in CC.
johannes
^ permalink raw reply
* Re: [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
From: Michal Kubecek @ 2013-11-14 15:57 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, David S. Miller, Patrick McHardy, John Fastabend
In-Reply-To: <5284E637.5060805@gmail.com>
On Thu, Nov 14, 2013 at 10:03:19AM -0500, Vlad Yasevich wrote:
> On 11/14/2013 09:00 AM, Michal Kubecek wrote:
> >+#if IS_ENABLED(CONFIG_MACVLAN)
> >+static inline struct net_device *
> >+macvlan_dev_real_dev(const struct net_device *dev)
> >+{
> >+ struct macvlan_dev *macvlan = netdev_priv(dev);
> >+
> >+ return macvlan->lowerdev;
> >+}
> >+#else
> >+static inline struct net_device *
> >+macvlan_dev_real_dev(const struct net_device *dev)
> >+{
> >+ return NULL;
> >+}
> >+#endif
> >+
>
> You may want to do the same here as was done for
> vlan_dev_real_dev(). This function is not intended to be called
> blindly and should always
> be called after netif_is_macvlan().
I'm not sure. It makes sense from the developer point of view: if we
find an inconsistency which must be caused by a bug in kernel code, do
panic so that the bug is found and fixed as soon as possible. However,
I remember a discussion where the point was that BUG() and BUG_ON()
should only be used if there is no way to recover. From this point of
view, WARN or WARN_ONCE might be better choice - but I'm not strictly
opposed to BUG().
Michal Kubecek
^ permalink raw reply
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