Le 12/05/2016 01:34, Alexander Aring a écrit :
[snip]
> But I don't know how it works when the $PHY isn't visible inside the
> namespace where the interface should be changed to. But wireless should
> have the same behaviour then, that the macvlan/veth/etc. the corresponding
> wireless phy isn't visible in the namespace. Seems there exists some
> "parent" device inside one namespace and macvlan/veth can be moved to
> other namespaces, but I am not an expert into that. :-)
Yes, the virtual interface (macvlan/veth,ip tunnels, vxlan, etc.) is created in
the namespace of the physical netns. After, the virtual interface is moved to
another netns (with 'ip link set foo netns bar'). This is called x-netns: the
upper par of the interface and the link part are not in the same netns.
With 'ip -d link' it's possible to show the link netns. There is an nsid which
identified the link netns. The nsid is valid only in the current netns (ie the
same netns can have another nsid in another netns).
Usually, there are explicit boundary in the code when crossing netns (see
skb_scrub_packet for example).
Example with a gre interface:
# create a gre interface in netns1
ip netns exec netns1 ip link add dev tun1 type gre local 10.0.0.1 \
remote 10.0.0.2
# move it in netns2: the link netns is still in netns1
ip netns exec netns1 ip link set tun1 netns netns2
or (completely equivalent):
# assign a nsid to netns1 in netns2
ip exec netns2 ip netns set netns1 1234
# create a gre interface in netns2 with its link netns in netns1
ip exec netns2 ip link add tun1 link-netnsid 1234 type gre local 10.0.0.1 \
remote 10.0.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
