* wireless netns work
@ 2009-06-18 12:35 ` Johannes Berg
0 siblings, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2009-06-18 12:35 UTC (permalink / raw)
To: linux-wireless; +Cc: Netdev
[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]
Hi,
You've all seen the netns patches fly by -- time to explain what I'm
doing maybe?
First, I've not copied all patches to both lists, please look at
http://johannes.sipsolutions.net/patches/kernel/all/LATEST/ for all the
patches with netns in their name, as there are:
## netns work [sent]
006-wext-netns.patch
007-netns-rcu.patch
008-genl-netns.patch
009-mac80211-netns.patch
010-netns-export-get-by-pid.patch
## netns work [rfc]
011-cfg80211-netns.patch
## play together
012-mac80211-allow-netns.patch
## HACK HACK HACK
013-mac80211-no-netdev-dev.patch
Also, to play with it you will need the netns branch of iw, which has
this simple commit:
http://git.sipsolutions.net/gitweb.cgi?p=iw.git;a=commitdiff;h=518d4092312a8b02bdb49163ae403de7abc9bdee
Also grab ns_exec and compile it:
http://johannes.sipsolutions.net/files/ns_exec.c.txt
Now compile your kernel with all the above patches (including the HACK
one) and let's play:
# modprobe mac80211_hsim
open a new terminal, and in it do
# ns_exec -c -n /bin/bash
and note the PID. In the new shell, also do
# ip link set lo up
Then in the old terminal, do
# iw phy#0 set netns PID-from-above
You'll get a sysfs complaint. Now, in the old terminal:
# ip addr add 192.168.12.1/24 dev wlan1
and in the new netns terminal:
# ip addr add 192.168.12.2/24 dev wlan0
Now you can run hostapd on one of them and connect to the other. This
bit works fine. Once the link is established, you _should_ also be able
to ping between the two, but that doesn't work.
Oddly, the link works unidirectionally in both directions, if I ping
from either side tcpdump shows the echo requests on the other side, but
no echo reply is being generated. Still investigating why this is, since
it works fine with veth. Ideas why this is broken would be
appreciated :)
(and to play with veth, do
# ip link add type veth
# ip link set veth0 netns <PID>
# ip addr add ...
)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* wireless netns work
@ 2009-06-18 12:35 ` Johannes Berg
0 siblings, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2009-06-18 12:35 UTC (permalink / raw)
To: linux-wireless; +Cc: Netdev
[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]
Hi,
You've all seen the netns patches fly by -- time to explain what I'm
doing maybe?
First, I've not copied all patches to both lists, please look at
http://johannes.sipsolutions.net/patches/kernel/all/LATEST/ for all the
patches with netns in their name, as there are:
## netns work [sent]
006-wext-netns.patch
007-netns-rcu.patch
008-genl-netns.patch
009-mac80211-netns.patch
010-netns-export-get-by-pid.patch
## netns work [rfc]
011-cfg80211-netns.patch
## play together
012-mac80211-allow-netns.patch
## HACK HACK HACK
013-mac80211-no-netdev-dev.patch
Also, to play with it you will need the netns branch of iw, which has
this simple commit:
http://git.sipsolutions.net/gitweb.cgi?p=iw.git;a=commitdiff;h=518d4092312a8b02bdb49163ae403de7abc9bdee
Also grab ns_exec and compile it:
http://johannes.sipsolutions.net/files/ns_exec.c.txt
Now compile your kernel with all the above patches (including the HACK
one) and let's play:
# modprobe mac80211_hsim
open a new terminal, and in it do
# ns_exec -c -n /bin/bash
and note the PID. In the new shell, also do
# ip link set lo up
Then in the old terminal, do
# iw phy#0 set netns PID-from-above
You'll get a sysfs complaint. Now, in the old terminal:
# ip addr add 192.168.12.1/24 dev wlan1
and in the new netns terminal:
# ip addr add 192.168.12.2/24 dev wlan0
Now you can run hostapd on one of them and connect to the other. This
bit works fine. Once the link is established, you _should_ also be able
to ping between the two, but that doesn't work.
Oddly, the link works unidirectionally in both directions, if I ping
from either side tcpdump shows the echo requests on the other side, but
no echo reply is being generated. Still investigating why this is, since
it works fine with veth. Ideas why this is broken would be
appreciated :)
(and to play with veth, do
# ip link add type veth
# ip link set veth0 netns <PID>
# ip addr add ...
)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: wireless netns work
@ 2009-06-18 12:55 ` Johannes Berg
0 siblings, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2009-06-18 12:55 UTC (permalink / raw)
To: linux-wireless; +Cc: Netdev
On Thu, 2009-06-18 at 14:35 +0200, Johannes Berg wrote:
> Oddly, the link works unidirectionally in both directions, if I ping
> from either side tcpdump shows the echo requests on the other side, but
> no echo reply is being generated. Still investigating why this is, since
> it works fine with veth. Ideas why this is broken would be
> appreciated :)
Ok, the missing piece of the puzzle is this patch:
http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-hwsim-skb-cleanup.patch
root@(none):~# ping -Q 0x80 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
Warning: time of day goes back (-311263us), taking countermeasures.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.487 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.122 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.121 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.130 ms
(this is between net namespaces on the same user-mode-linux instance)
Wireshark also shows the packets on hwsim0:
No. Time Source Destination Protocol Info
9 0.709807 10.0.0.2 10.0.0.1 ICMP Echo (ping) request
Frame 9 (130 bytes on wire, 130 bytes captured)
Arrival Time: Jun 18, 2009 14:47:40.533741000
[Time delta from previous captured frame: 0.010281000 seconds]
[Time delta from previous displayed frame: 0.010281000 seconds]
[Time since reference or first frame: 0.709807000 seconds]
Frame Number: 9
Frame Length: 130 bytes
Capture Length: 130 bytes
[Frame is marked: True]
[Protocols in frame: radiotap:wlan:llc:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp]
Radiotap Header v0, Length 14
Header revision: 0
Header pad: 0
Header length: 14
Present flags: 0x0000000e
.... .... .... .... .... .... .... ...0 = TSFT: False
.... .... .... .... .... .... .... ..1. = Flags: True
.... .... .... .... .... .... .... .1.. = Rate: True
.... .... .... .... .... .... .... 1... = Channel: True
.... .... .... .... .... .... ...0 .... = FHSS: False
.... .... .... .... .... .... ..0. .... = DBM Antenna Signal: False
.... .... .... .... .... .... .0.. .... = DBM Antenna Noise: False
.... .... .... .... .... .... 0... .... = Lock Quality: False
.... .... .... .... .... ...0 .... .... = TX Attenuation: False
.... .... .... .... .... ..0. .... .... = DB TX Attenuation: False
.... .... .... .... .... .0.. .... .... = DBM TX Attenuation: False
.... .... .... .... .... 0... .... .... = Antenna: False
.... .... .... .... ...0 .... .... .... = DB Antenna Signal: False
.... .... .... .... ..0. .... .... .... = DB Antenna Noise: False
.... .... .... .... .0.. .... .... .... = FCS in header: False
.... .... .... .0.. .... .... .... .... = Channel+: False
0... .... .... .... .... .... .... .... = Ext: False
Flags: 0x00
.... ...0 = CFP: False
.... ..0. = Preamble: Long
.... .0.. = WEP: False
.... 0... = Fragmentation: False
...0 .... = FCS at end: False
..0. .... = Data Pad: False
.0.. .... = Bad FCS: False
0... .... = Short GI: False
Data Rate: 1.0 Mb/s
Channel frequency: 2462 [BG 11]
Channel type: 802.11b (0x00a0)
.... .... ...0 .... = Turbo: False
.... .... ..1. .... = Complementary Code Keying (CCK): True
.... .... .0.. .... = Orthogonal Frequency-Division Multiplexing (OFDM): False
.... .... 1... .... = 2 GHz spectrum: True
.... ...0 .... .... = 5 GHz spectrum: False
.... ..0. .... .... = Passive: False
.... .0.. .... .... = Dynamic CCK-OFDM: False
.... 0... .... .... = Gaussian Frequency Shift Keying (GFSK): False
...0 .... .... .... = GSM (900MHz): False
..0. .... .... .... = Static Turbo: False
.0.. .... .... .... = Half Rate Channel (10MHz Channel Width): False
0... .... .... .... = Quarter Rate Channel (5MHz Channel Width): False
IEEE 802.11 Data, Flags: .......T
Type/Subtype: Data (0x20)
Frame Control: 0x0108 (Normal)
Version: 0
Type: Data frame (2)
Subtype: 0
Flags: 0x1
DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0) (0x01)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
Duration: 218
BSS Id: 02:00:00:00:00:00 (02:00:00:00:00:00)
Source address: 02:00:00:00:01:00 (02:00:00:00:01:00)
Destination address: 02:00:00:00:00:00 (02:00:00:00:00:00)
Fragment number: 0
Sequence number: 52
Logical-Link Control
DSAP: SNAP (0xaa)
IG Bit: Individual
SSAP: SNAP (0xaa)
CR Bit: Command
Control field: U, func=UI (0x03)
000. 00.. = Command: Unnumbered Information (0x00)
.... ..11 = Frame type: Unnumbered frame (0x03)
Organization Code: Encapsulated Ethernet (0x000000)
Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.2 (10.0.0.2), Dst: 10.0.0.1 (10.0.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00)
1000 00.. = Differentiated Services Codepoint: Class Selector 4 (0x20)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: ICMP (0x01)
Header checksum: 0x2627 [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.2 (10.0.0.2)
Destination: 10.0.0.1 (10.0.0.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0 ()
Checksum: 0xdbb9 [correct]
Identifier: 0xb503
Sequence number: 9 (0x0009)
Data (56 bytes)
Data: 6C373A4A00000000F5E40C00000000001011121314151617...
0000 00 00 0e 00 0e 00 00 00 00 02 9e 09 a0 00 08 01 ................
0010 da 00 02 00 00 00 00 00 02 00 00 00 01 00 02 00 ................
0020 00 00 00 00 40 03 aa aa 03 00 00 00 08 00 45 80 ....@.........E.
0030 00 54 00 00 40 00 40 01 26 27 0a 00 00 02 0a 00 .T..@.@.&'......
0040 00 01 08 00 db b9 b5 03 00 09 6c 37 3a 4a 00 00 ..........l7:J..
0050 00 00 f5 e4 0c 00 00 00 00 00 10 11 12 13 14 15 ................
0060 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0070 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0080 36 37 67
No. Time Source Destination Protocol Info
10 0.709841 10.0.0.1 10.0.0.2 ICMP Echo (ping) reply
Frame 10 (130 bytes on wire, 130 bytes captured)
Arrival Time: Jun 18, 2009 14:47:40.533775000
[Time delta from previous captured frame: 0.000034000 seconds]
[Time delta from previous displayed frame: 0.000034000 seconds]
[Time since reference or first frame: 0.709841000 seconds]
Frame Number: 10
Frame Length: 130 bytes
Capture Length: 130 bytes
[Frame is marked: True]
[Protocols in frame: radiotap:wlan:llc:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp]
Radiotap Header v0, Length 14
Header revision: 0
Header pad: 0
Header length: 14
Present flags: 0x0000000e
.... .... .... .... .... .... .... ...0 = TSFT: False
.... .... .... .... .... .... .... ..1. = Flags: True
.... .... .... .... .... .... .... .1.. = Rate: True
.... .... .... .... .... .... .... 1... = Channel: True
.... .... .... .... .... .... ...0 .... = FHSS: False
.... .... .... .... .... .... ..0. .... = DBM Antenna Signal: False
.... .... .... .... .... .... .0.. .... = DBM Antenna Noise: False
.... .... .... .... .... .... 0... .... = Lock Quality: False
.... .... .... .... .... ...0 .... .... = TX Attenuation: False
.... .... .... .... .... ..0. .... .... = DB TX Attenuation: False
.... .... .... .... .... .0.. .... .... = DBM TX Attenuation: False
.... .... .... .... .... 0... .... .... = Antenna: False
.... .... .... .... ...0 .... .... .... = DB Antenna Signal: False
.... .... .... .... ..0. .... .... .... = DB Antenna Noise: False
.... .... .... .... .0.. .... .... .... = FCS in header: False
.... .... .... .0.. .... .... .... .... = Channel+: False
0... .... .... .... .... .... .... .... = Ext: False
Flags: 0x00
.... ...0 = CFP: False
.... ..0. = Preamble: Long
.... .0.. = WEP: False
.... 0... = Fragmentation: False
...0 .... = FCS at end: False
..0. .... = Data Pad: False
.0.. .... = Bad FCS: False
0... .... = Short GI: False
Data Rate: 1.0 Mb/s
Channel frequency: 2462 [BG 11]
Channel type: 802.11b (0x00a0)
.... .... ...0 .... = Turbo: False
.... .... ..1. .... = Complementary Code Keying (CCK): True
.... .... .0.. .... = Orthogonal Frequency-Division Multiplexing (OFDM): False
.... .... 1... .... = 2 GHz spectrum: True
.... ...0 .... .... = 5 GHz spectrum: False
.... ..0. .... .... = Passive: False
.... .0.. .... .... = Dynamic CCK-OFDM: False
.... 0... .... .... = Gaussian Frequency Shift Keying (GFSK): False
...0 .... .... .... = GSM (900MHz): False
..0. .... .... .... = Static Turbo: False
.0.. .... .... .... = Half Rate Channel (10MHz Channel Width): False
0... .... .... .... = Quarter Rate Channel (5MHz Channel Width): False
IEEE 802.11 Data, Flags: ......F.
Type/Subtype: Data (0x20)
Frame Control: 0x0208 (Normal)
Version: 0
Type: Data frame (2)
Subtype: 0
Flags: 0x2
DS status: Frame from DS to a STA via AP(To DS: 0 From DS: 1) (0x02)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
Duration: 314
Destination address: 02:00:00:00:01:00 (02:00:00:00:01:00)
BSS Id: 02:00:00:00:00:00 (02:00:00:00:00:00)
Source address: 02:00:00:00:00:00 (02:00:00:00:00:00)
Fragment number: 0
Sequence number: 33
Logical-Link Control
DSAP: SNAP (0xaa)
IG Bit: Individual
SSAP: SNAP (0xaa)
CR Bit: Command
Control field: U, func=UI (0x03)
000. 00.. = Command: Unnumbered Information (0x00)
.... ..11 = Frame type: Unnumbered frame (0x03)
Organization Code: Encapsulated Ethernet (0x000000)
Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.2 (10.0.0.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00)
1000 00.. = Differentiated Services Codepoint: Class Selector 4 (0x20)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0xe172 (57714)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: ICMP (0x01)
Header checksum: 0x84b4 [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.1 (10.0.0.1)
Destination: 10.0.0.2 (10.0.0.2)
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0 ()
Checksum: 0xe3b9 [correct]
Identifier: 0xb503
Sequence number: 9 (0x0009)
Data (56 bytes)
Data: 6C373A4A00000000F5E40C00000000001011121314151617...
0000 00 00 0e 00 0e 00 00 00 00 02 9e 09 a0 00 08 02 ................
0010 3a 01 02 00 00 00 01 00 02 00 00 00 00 00 02 00 :...............
0020 00 00 00 00 10 02 aa aa 03 00 00 00 08 00 45 80 ..............E.
0030 00 54 e1 72 00 00 40 01 84 b4 0a 00 00 01 0a 00 .T.r..@.........
0040 00 02 00 00 e3 b9 b5 03 00 09 6c 37 3a 4a 00 00 ..........l7:J..
0050 00 00 f5 e4 0c 00 00 00 00 00 10 11 12 13 14 15 ................
0060 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0070 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0080 36 37 67
Yay!
johannes
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: wireless netns work
@ 2009-06-18 12:55 ` Johannes Berg
0 siblings, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2009-06-18 12:55 UTC (permalink / raw)
To: linux-wireless; +Cc: Netdev
On Thu, 2009-06-18 at 14:35 +0200, Johannes Berg wrote:
> Oddly, the link works unidirectionally in both directions, if I ping
> from either side tcpdump shows the echo requests on the other side, but
> no echo reply is being generated. Still investigating why this is, since
> it works fine with veth. Ideas why this is broken would be
> appreciated :)
Ok, the missing piece of the puzzle is this patch:
http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-hwsim-skb-cleanup.patch
root@(none):~# ping -Q 0x80 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
Warning: time of day goes back (-311263us), taking countermeasures.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.487 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.122 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.121 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.130 ms
(this is between net namespaces on the same user-mode-linux instance)
Wireshark also shows the packets on hwsim0:
No. Time Source Destination Protocol Info
9 0.709807 10.0.0.2 10.0.0.1 ICMP Echo (ping) request
Frame 9 (130 bytes on wire, 130 bytes captured)
Arrival Time: Jun 18, 2009 14:47:40.533741000
[Time delta from previous captured frame: 0.010281000 seconds]
[Time delta from previous displayed frame: 0.010281000 seconds]
[Time since reference or first frame: 0.709807000 seconds]
Frame Number: 9
Frame Length: 130 bytes
Capture Length: 130 bytes
[Frame is marked: True]
[Protocols in frame: radiotap:wlan:llc:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp]
Radiotap Header v0, Length 14
Header revision: 0
Header pad: 0
Header length: 14
Present flags: 0x0000000e
.... .... .... .... .... .... .... ...0 = TSFT: False
.... .... .... .... .... .... .... ..1. = Flags: True
.... .... .... .... .... .... .... .1.. = Rate: True
.... .... .... .... .... .... .... 1... = Channel: True
.... .... .... .... .... .... ...0 .... = FHSS: False
.... .... .... .... .... .... ..0. .... = DBM Antenna Signal: False
.... .... .... .... .... .... .0.. .... = DBM Antenna Noise: False
.... .... .... .... .... .... 0... .... = Lock Quality: False
.... .... .... .... .... ...0 .... .... = TX Attenuation: False
.... .... .... .... .... ..0. .... .... = DB TX Attenuation: False
.... .... .... .... .... .0.. .... .... = DBM TX Attenuation: False
.... .... .... .... .... 0... .... .... = Antenna: False
.... .... .... .... ...0 .... .... .... = DB Antenna Signal: False
.... .... .... .... ..0. .... .... .... = DB Antenna Noise: False
.... .... .... .... .0.. .... .... .... = FCS in header: False
.... .... .... .0.. .... .... .... .... = Channel+: False
0... .... .... .... .... .... .... .... = Ext: False
Flags: 0x00
.... ...0 = CFP: False
.... ..0. = Preamble: Long
.... .0.. = WEP: False
.... 0... = Fragmentation: False
...0 .... = FCS at end: False
..0. .... = Data Pad: False
.0.. .... = Bad FCS: False
0... .... = Short GI: False
Data Rate: 1.0 Mb/s
Channel frequency: 2462 [BG 11]
Channel type: 802.11b (0x00a0)
.... .... ...0 .... = Turbo: False
.... .... ..1. .... = Complementary Code Keying (CCK): True
.... .... .0.. .... = Orthogonal Frequency-Division Multiplexing (OFDM): False
.... .... 1... .... = 2 GHz spectrum: True
.... ...0 .... .... = 5 GHz spectrum: False
.... ..0. .... .... = Passive: False
.... .0.. .... .... = Dynamic CCK-OFDM: False
.... 0... .... .... = Gaussian Frequency Shift Keying (GFSK): False
...0 .... .... .... = GSM (900MHz): False
..0. .... .... .... = Static Turbo: False
.0.. .... .... .... = Half Rate Channel (10MHz Channel Width): False
0... .... .... .... = Quarter Rate Channel (5MHz Channel Width): False
IEEE 802.11 Data, Flags: .......T
Type/Subtype: Data (0x20)
Frame Control: 0x0108 (Normal)
Version: 0
Type: Data frame (2)
Subtype: 0
Flags: 0x1
DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0) (0x01)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
Duration: 218
BSS Id: 02:00:00:00:00:00 (02:00:00:00:00:00)
Source address: 02:00:00:00:01:00 (02:00:00:00:01:00)
Destination address: 02:00:00:00:00:00 (02:00:00:00:00:00)
Fragment number: 0
Sequence number: 52
Logical-Link Control
DSAP: SNAP (0xaa)
IG Bit: Individual
SSAP: SNAP (0xaa)
CR Bit: Command
Control field: U, func=UI (0x03)
000. 00.. = Command: Unnumbered Information (0x00)
.... ..11 = Frame type: Unnumbered frame (0x03)
Organization Code: Encapsulated Ethernet (0x000000)
Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.2 (10.0.0.2), Dst: 10.0.0.1 (10.0.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00)
1000 00.. = Differentiated Services Codepoint: Class Selector 4 (0x20)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: ICMP (0x01)
Header checksum: 0x2627 [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.2 (10.0.0.2)
Destination: 10.0.0.1 (10.0.0.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0 ()
Checksum: 0xdbb9 [correct]
Identifier: 0xb503
Sequence number: 9 (0x0009)
Data (56 bytes)
Data: 6C373A4A00000000F5E40C00000000001011121314151617...
0000 00 00 0e 00 0e 00 00 00 00 02 9e 09 a0 00 08 01 ................
0010 da 00 02 00 00 00 00 00 02 00 00 00 01 00 02 00 ................
0020 00 00 00 00 40 03 aa aa 03 00 00 00 08 00 45 80 ....@.........E.
0030 00 54 00 00 40 00 40 01 26 27 0a 00 00 02 0a 00 .T..@.@.&'......
0040 00 01 08 00 db b9 b5 03 00 09 6c 37 3a 4a 00 00 ..........l7:J..
0050 00 00 f5 e4 0c 00 00 00 00 00 10 11 12 13 14 15 ................
0060 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0070 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0080 36 37 67
No. Time Source Destination Protocol Info
10 0.709841 10.0.0.1 10.0.0.2 ICMP Echo (ping) reply
Frame 10 (130 bytes on wire, 130 bytes captured)
Arrival Time: Jun 18, 2009 14:47:40.533775000
[Time delta from previous captured frame: 0.000034000 seconds]
[Time delta from previous displayed frame: 0.000034000 seconds]
[Time since reference or first frame: 0.709841000 seconds]
Frame Number: 10
Frame Length: 130 bytes
Capture Length: 130 bytes
[Frame is marked: True]
[Protocols in frame: radiotap:wlan:llc:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp]
Radiotap Header v0, Length 14
Header revision: 0
Header pad: 0
Header length: 14
Present flags: 0x0000000e
.... .... .... .... .... .... .... ...0 = TSFT: False
.... .... .... .... .... .... .... ..1. = Flags: True
.... .... .... .... .... .... .... .1.. = Rate: True
.... .... .... .... .... .... .... 1... = Channel: True
.... .... .... .... .... .... ...0 .... = FHSS: False
.... .... .... .... .... .... ..0. .... = DBM Antenna Signal: False
.... .... .... .... .... .... .0.. .... = DBM Antenna Noise: False
.... .... .... .... .... .... 0... .... = Lock Quality: False
.... .... .... .... .... ...0 .... .... = TX Attenuation: False
.... .... .... .... .... ..0. .... .... = DB TX Attenuation: False
.... .... .... .... .... .0.. .... .... = DBM TX Attenuation: False
.... .... .... .... .... 0... .... .... = Antenna: False
.... .... .... .... ...0 .... .... .... = DB Antenna Signal: False
.... .... .... .... ..0. .... .... .... = DB Antenna Noise: False
.... .... .... .... .0.. .... .... .... = FCS in header: False
.... .... .... .0.. .... .... .... .... = Channel+: False
0... .... .... .... .... .... .... .... = Ext: False
Flags: 0x00
.... ...0 = CFP: False
.... ..0. = Preamble: Long
.... .0.. = WEP: False
.... 0... = Fragmentation: False
...0 .... = FCS at end: False
..0. .... = Data Pad: False
.0.. .... = Bad FCS: False
0... .... = Short GI: False
Data Rate: 1.0 Mb/s
Channel frequency: 2462 [BG 11]
Channel type: 802.11b (0x00a0)
.... .... ...0 .... = Turbo: False
.... .... ..1. .... = Complementary Code Keying (CCK): True
.... .... .0.. .... = Orthogonal Frequency-Division Multiplexing (OFDM): False
.... .... 1... .... = 2 GHz spectrum: True
.... ...0 .... .... = 5 GHz spectrum: False
.... ..0. .... .... = Passive: False
.... .0.. .... .... = Dynamic CCK-OFDM: False
.... 0... .... .... = Gaussian Frequency Shift Keying (GFSK): False
...0 .... .... .... = GSM (900MHz): False
..0. .... .... .... = Static Turbo: False
.0.. .... .... .... = Half Rate Channel (10MHz Channel Width): False
0... .... .... .... = Quarter Rate Channel (5MHz Channel Width): False
IEEE 802.11 Data, Flags: ......F.
Type/Subtype: Data (0x20)
Frame Control: 0x0208 (Normal)
Version: 0
Type: Data frame (2)
Subtype: 0
Flags: 0x2
DS status: Frame from DS to a STA via AP(To DS: 0 From DS: 1) (0x02)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
Duration: 314
Destination address: 02:00:00:00:01:00 (02:00:00:00:01:00)
BSS Id: 02:00:00:00:00:00 (02:00:00:00:00:00)
Source address: 02:00:00:00:00:00 (02:00:00:00:00:00)
Fragment number: 0
Sequence number: 33
Logical-Link Control
DSAP: SNAP (0xaa)
IG Bit: Individual
SSAP: SNAP (0xaa)
CR Bit: Command
Control field: U, func=UI (0x03)
000. 00.. = Command: Unnumbered Information (0x00)
.... ..11 = Frame type: Unnumbered frame (0x03)
Organization Code: Encapsulated Ethernet (0x000000)
Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.2 (10.0.0.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00)
1000 00.. = Differentiated Services Codepoint: Class Selector 4 (0x20)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0xe172 (57714)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: ICMP (0x01)
Header checksum: 0x84b4 [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.1 (10.0.0.1)
Destination: 10.0.0.2 (10.0.0.2)
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0 ()
Checksum: 0xe3b9 [correct]
Identifier: 0xb503
Sequence number: 9 (0x0009)
Data (56 bytes)
Data: 6C373A4A00000000F5E40C00000000001011121314151617...
0000 00 00 0e 00 0e 00 00 00 00 02 9e 09 a0 00 08 02 ................
0010 3a 01 02 00 00 00 01 00 02 00 00 00 00 00 02 00 :...............
0020 00 00 00 00 10 02 aa aa 03 00 00 00 08 00 45 80 ..............E.
0030 00 54 e1 72 00 00 40 01 84 b4 0a 00 00 01 0a 00 .T.r..@.........
0040 00 02 00 00 e3 b9 b5 03 00 09 6c 37 3a 4a 00 00 ..........l7:J..
0050 00 00 f5 e4 0c 00 00 00 00 00 10 11 12 13 14 15 ................
0060 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0070 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0080 36 37 67
Yay!
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: wireless netns work
2009-06-18 12:55 ` Johannes Berg
(?)
@ 2009-06-18 17:16 ` Nick Kossifidis
2009-06-18 21:43 ` Luis R. Rodriguez
-1 siblings, 1 reply; 11+ messages in thread
From: Nick Kossifidis @ 2009-06-18 17:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Netdev
2009/6/18 Johannes Berg <johannes@sipsolutions.net>:
> On Thu, 2009-06-18 at 14:35 +0200, Johannes Berg wrote:
>
>> Oddly, the link works unidirectionally in both directions, if I ping
>> from either side tcpdump shows the echo requests on the other side, but
>> no echo reply is being generated. Still investigating why this is, since
>> it works fine with veth. Ideas why this is broken would be
>> appreciated :)
>
> Ok, the missing piece of the puzzle is this patch:
> http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-hwsim-skb-cleanup.patch
>
> root@(none):~# ping -Q 0x80 10.0.0.1
> PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
> Warning: time of day goes back (-311263us), taking countermeasures.
> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.487 ms
> 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.122 ms
> 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.121 ms
> 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.130 ms
>
Well done !!!
Don't you think it's time we create a mac80211 test suite based on hwsim ?
I think it's an interesting project...
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: wireless netns work
2009-06-18 17:16 ` Nick Kossifidis
@ 2009-06-18 21:43 ` Luis R. Rodriguez
2009-06-18 21:48 ` Johannes Berg
0 siblings, 1 reply; 11+ messages in thread
From: Luis R. Rodriguez @ 2009-06-18 21:43 UTC (permalink / raw)
To: Nick Kossifidis, Georgy Berdyshev; +Cc: Johannes Berg, linux-wireless, Netdev
On Thu, Jun 18, 2009 at 10:16 AM, Nick Kossifidis<mickflemm@gmail.com> wrote:
> 2009/6/18 Johannes Berg <johannes@sipsolutions.net>:
>> On Thu, 2009-06-18 at 14:35 +0200, Johannes Berg wrote:
>>
>>> Oddly, the link works unidirectionally in both directions, if I ping
>>> from either side tcpdump shows the echo requests on the other side, but
>>> no echo reply is being generated. Still investigating why this is, since
>>> it works fine with veth. Ideas why this is broken would be
>>> appreciated :)
>>
>> Ok, the missing piece of the puzzle is this patch:
>> http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-hwsim-skb-cleanup.patch
>>
>> root@(none):~# ping -Q 0x80 10.0.0.1
>> PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
>> Warning: time of day goes back (-311263us), taking countermeasures.
>> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.487 ms
>> 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.122 ms
>> 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.121 ms
>> 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.130 ms
>>
>
> Well done !!!
>
> Don't you think it's time we create a mac80211 test suite based on hwsim ?
> I think it's an interesting project...
Certainly, there's a GSOC project going on for exactly this purpose:
http://wireless.kernel.org/en/developers/GSoC/2009/Automation_of_testing
Cc'ing the student working on it, Georgy.
BTW : a good review of when namespace stuff started to get merged:
http://lwn.net/Articles/219794/
By reading this still I am still unclear what to cheer for with my pom
poms. Can you clarify a little what this means for wireless? Let me
explain a little where I am confused
For example, I see you used mac80211_hwsim and was able to use two
wlan interfaces to talk to each other. This seems great for testing
purposes but it remains unclear to me the advantage of testing with
separate namespaces vs creating two wlan interfaces on one namespace
with mac80211_hwsim.
Also, it remains unclear to me what the implications for real device
usage though. So for example ath9k has support creating multiple
wiphys and it uses its own schedular to also support communication on
two separate channels. Does supporting different namespaces have
implication on how we can support multiple wiphys in the future? Mind
you I have yet to review all the patches, but if you create a
secondary namespace and have a mac80211 wireless driver loaded how
does sharing the device work?
Luis
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: wireless netns work
@ 2009-06-18 21:48 ` Johannes Berg
0 siblings, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2009-06-18 21:48 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Nick Kossifidis, Georgy Berdyshev, linux-wireless, Netdev
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
On Thu, 2009-06-18 at 14:43 -0700, Luis R. Rodriguez wrote:
> For example, I see you used mac80211_hwsim and was able to use two
> wlan interfaces to talk to each other. This seems great for testing
> purposes but it remains unclear to me the advantage of testing with
> separate namespaces vs creating two wlan interfaces on one namespace
> with mac80211_hwsim.
You cannot ping within one namespace and have the packets actually flow
over the virtual 'air'.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: wireless netns work
@ 2009-06-18 21:48 ` Johannes Berg
0 siblings, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2009-06-18 21:48 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Nick Kossifidis, Georgy Berdyshev, linux-wireless, Netdev
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
On Thu, 2009-06-18 at 14:43 -0700, Luis R. Rodriguez wrote:
> For example, I see you used mac80211_hwsim and was able to use two
> wlan interfaces to talk to each other. This seems great for testing
> purposes but it remains unclear to me the advantage of testing with
> separate namespaces vs creating two wlan interfaces on one namespace
> with mac80211_hwsim.
You cannot ping within one namespace and have the packets actually flow
over the virtual 'air'.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: wireless netns work
2009-06-18 21:48 ` Johannes Berg
(?)
@ 2009-06-18 22:04 ` Luis R. Rodriguez
2009-06-18 22:06 ` Johannes Berg
-1 siblings, 1 reply; 11+ messages in thread
From: Luis R. Rodriguez @ 2009-06-18 22:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: Nick Kossifidis, Georgy Berdyshev, linux-wireless, Netdev
On Thu, Jun 18, 2009 at 2:48 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-06-18 at 14:43 -0700, Luis R. Rodriguez wrote:
>
>> For example, I see you used mac80211_hwsim and was able to use two
>> wlan interfaces to talk to each other. This seems great for testing
>> purposes but it remains unclear to me the advantage of testing with
>> separate namespaces vs creating two wlan interfaces on one namespace
>> with mac80211_hwsim.
>
> You cannot ping within one namespace and have the packets actually flow
> over the virtual 'air'.
I see, thanks! How does using a separate namespace fix this limitation?
Luis
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: wireless netns work
@ 2009-06-18 22:06 ` Johannes Berg
0 siblings, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2009-06-18 22:06 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Nick Kossifidis, Georgy Berdyshev, linux-wireless, Netdev
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
On Thu, 2009-06-18 at 15:04 -0700, Luis R. Rodriguez wrote:
> On Thu, Jun 18, 2009 at 2:48 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> > On Thu, 2009-06-18 at 14:43 -0700, Luis R. Rodriguez wrote:
> >
> >> For example, I see you used mac80211_hwsim and was able to use two
> >> wlan interfaces to talk to each other. This seems great for testing
> >> purposes but it remains unclear to me the advantage of testing with
> >> separate namespaces vs creating two wlan interfaces on one namespace
> >> with mac80211_hwsim.
> >
> > You cannot ping within one namespace and have the packets actually flow
> > over the virtual 'air'.
>
> I see, thanks! How does using a separate namespace fix this limitation?
Well that's the magic ;) Think of it as having one copy of the
networking stack per netns.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: wireless netns work
@ 2009-06-18 22:06 ` Johannes Berg
0 siblings, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2009-06-18 22:06 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Nick Kossifidis, Georgy Berdyshev, linux-wireless, Netdev
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
On Thu, 2009-06-18 at 15:04 -0700, Luis R. Rodriguez wrote:
> On Thu, Jun 18, 2009 at 2:48 PM, Johannes Berg<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> > On Thu, 2009-06-18 at 14:43 -0700, Luis R. Rodriguez wrote:
> >
> >> For example, I see you used mac80211_hwsim and was able to use two
> >> wlan interfaces to talk to each other. This seems great for testing
> >> purposes but it remains unclear to me the advantage of testing with
> >> separate namespaces vs creating two wlan interfaces on one namespace
> >> with mac80211_hwsim.
> >
> > You cannot ping within one namespace and have the packets actually flow
> > over the virtual 'air'.
>
> I see, thanks! How does using a separate namespace fix this limitation?
Well that's the magic ;) Think of it as having one copy of the
networking stack per netns.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-06-18 22:07 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-18 12:35 wireless netns work Johannes Berg
2009-06-18 12:35 ` Johannes Berg
2009-06-18 12:55 ` Johannes Berg
2009-06-18 12:55 ` Johannes Berg
2009-06-18 17:16 ` Nick Kossifidis
2009-06-18 21:43 ` Luis R. Rodriguez
2009-06-18 21:48 ` Johannes Berg
2009-06-18 21:48 ` Johannes Berg
2009-06-18 22:04 ` Luis R. Rodriguez
2009-06-18 22:06 ` Johannes Berg
2009-06-18 22:06 ` Johannes Berg
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.