wtap(4): Implement IBSS mode on wtap(4)

[enweiwu]

Summary

Below is the planned commit message:

wtap(4): Implement IBSS mode on wtap(4)

    For TSF and beacon generation, each STA has to start its local TSF timer and send beacon frames when it reaches the state IEEE80211_S_RUN, and the TSF timer will be used when:
    - IBSS merge (mentioned below)
    - beacon frame transmission (mentioned below)
    
    TSF timer is kept in HAL of wtap(4), it’s working by continuously updating its value on timer interrupt simulated by callout_reset().

    When receiving beacons, the STA will be merged into the IBSS if 
    - the STA has the same SSID as the beacon sender
    - the STA's TSF timer is smaller than the beacon sender's TSF timer

After the merging process, the younger STA will be in the IBSS created by the older STA and the STA stops sending beacon frames. So beacon frames will always be sent by the oldest STA in IBSS.

This diff depends on D35752.

Test Plan

create two parent wlan devices wtap0, wtap1

goto tools/tools/wtap/wtap, and follow the commands below (may need the priority of super user) :

./wtap c 0
./wtap c 1

create two child wlan devices (vap) wlan0, wlan1 in IBSS mode (with the same SSID)

Follow the commands below (may need the priority of super user) :

ifconfig wlan0 create wlandev wtap0 wlanmode adhoc ssid test
ifconfig wlan1 create wlandev wtap1 wlanmode adhoc ssid test

use visibility tool to enable communications between wlan0 and wlan1

goto tools/tools/wtap/vis_map, and follow the commands below (may need the priority of super user) :

./vis_map o
./vis_map a 0 1
./vis_map a 1 0

create two jails with vnet

create jail0 with interface wlan0, and create jail1 with interface wlan1. Allow raw sockets and vnet by pass the parameters as following:

jail -c name=jail0 persist vnet vnet.interface=wlan0 allow.raw_sockets
jail -c name=jail1 persist vnet vnet.interface=wlan1 allow.raw_sockets

bring up interfaces and assign IP addresses

Assign wlan0 IP address with 10.0.0.1, wlan1 with 10.0.0.2, and bring them up.

jexec jail0 ifconfig wlan0 inet 10.0.0.1/24 up
jexec jail1 ifconfig wlan1 inet 10.0.0.2/24 up

ping test

Now ping test are available, you can do ping test on either jail0 or jail1 via ping(8).

[lwhsu]

sys/dev/wtap/wtap_hal/hal.c

77

Does it need to acquire giant lock? If no, we can change mpsafe to 1, or, maybe we can use callout_init_mtx(9) and &hal->mtx (which doesn't seem to be use in other place in wtap(4).)

78

if 50 is from spec, please make it as a definition in hal.c

220

Please follow the style of function definition as others in this file, and style(9).

[enweiwu]

sys/dev/wtap/wtap_hal/hal.c

77

OK. We don't need a giant lock, so I will change mpsafe to 1, and use callout_init_mtx(9) to avoid race condition.

220

Sure.

[lwhsu]

sys/dev/wtap/wtap_hal/hal.c

77

OK. We don't need a giant lock, so I will change mpsafe to 1, and use callout_init_mtx(9) to avoid race condition.

Please note that there is no mpsafe parameter in callout_init_mtx(9) so you can only chose one to do.

[enweiwu]

sys/dev/wtap/wtap_hal/hal.c

77

Oops, the "and" above is actually "or".

[enweiwu]

Update diff.

Add mutex lock on timer interrupt in HAL, and re-style the hal.c to comply with style(9).

[adrian]

nice work!

sys/dev/wtap/if_wtapvar.h

137

... is this indented with a tab?

sys/dev/wtap/wtap_hal/hal.c

184

hm, malloc with M_NOWAIT can return NULL, right? Should we check for that?

sys/dev/wtap/wtap_hal/hal.h

48

indenting too!

[enweiwu]

sys/dev/wtap/if_wtapvar.h

137

OK.

sys/dev/wtap/wtap_hal/hal.c

184

Actually, I think we might use M_WAITOK rather than M_NOWAIT, because it's not in the interrupt context. Shall I change this flag in the next diff?

sys/dev/wtap/wtap_hal/hal.h

48

sure.

[bz]

sys/dev/wtap/wtap_hal/hal.c

111

Unrelated; but we should probably fix this "pool"? I don't think this is a special prefix?

184

Yes pleas do.

[adrian]

hi! I think this looks ready to land, right?

sys/dev/wtap/wtap_hal/hal.c

111

yeah ew, let's get this fixed in a subsequent commit?

[lwhsu]

In D35841#821792, @adrian wrote:

hi! I think this looks ready to land, right?

Yes and I'll work with @enweiwu on further improvements.

sys/dev/wtap/wtap_hal/hal.c

111

Sounds good, btw, any suggestions about how to fix this?

[adrian]

sys/dev/wtap/wtap_hal/hal.c

111

Hm, we should look at what ath(4) does for inspiration. :-)

It will create a primary VAP based on the hardware (and in our case we can use the random generator.) For the secondary NICs it does it during VAP clone - it sets the "I'm a local mac address!" bit and then will increment the low byte by one so the hardware mask that's used is kept small (ie it doesn't have to be COMPLETELY promisc, for "anything matching this mask I'll ACK in hardware" reasons.)

For this we can likely get away with supporting either random addresses per interface clone / VAP creation, and ensure we can set it manually when we create the interface. That way automated tests can be written with well known MAC addresses.

[bz]

I'll get this in the next 24 hours.

sys/dev/wtap/wtap_hal/hal.c

111

And when using random, use the FreeBSD prefix we also use for Ethernet. There's a nice function to get one.

If we try to be clever we could do FreeBSD prefix + some wtap unit/vap number thing for the last bits; that way things would be very deterministic to start from for testing as well?