wlan0 appears as down despite AP up

[glamrock]

This has been a bit of a heisenbug, but on freshly flashed routers, occasionally wlan will have a state of down, despite an access point being up and usable.

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 3c:97:0e:61:57:47 brd ff:ff:ff:ff:ff:ff
    inet 10.50.1.7/24 brd 10.50.1.255 scope global eth0
    inet6 fe80::3e97:eff:fe61:5747/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 6c:88:14:49:67:b0 brd ff:ff:ff:ff:ff:ff

Noticed again while testing #98.

[dismantl]

can you provide full debug output?

[anest]

i got same situation, code from trunk just broken right now. wlan not up. last working code was for router/1.0 and its "just works".

[dismantl]

Just flagging that this might possibly be related to #94. With debug output we can better determine this.

[glamrock]

Router status debug files for both (linked to avoid cluttering up the thread):
https://gist.github.com/glamrock/8651955
https://gist.github.com/glamrock/8652014

[glamrock]

Yesterday, @prestonrhea was working with a user who identified this problem also. She was using the DR2 RedHook image, so the issue goes back at least that far.

[hawkinswnaf]

@glamrock Based on your debugging output, the problem you are seeing is almost certainly fixed in a pull request that I just entered. I will wait to close this issue until you've verified that new images work, but I am fairly certain that the latest code changes will solve your problem.

[glamrock]

@hawkinswnaf Is that opentechinstitute/commotiond#82? Making a build right now.

[hawkinswnaf]

@glamrock Yes, it is.

[jheretic]

@glamrock, were you able to confirm that this was fixed by opentechinstitute/commotiond#82?

[glamrock]

@jheretic No, however while I was attempting to verify (building and rebuilding due to corrupted build tree), I believe @hawkinswnaf was able to verify the fix.

[jheretic]

This issue didn't crop up in v1.1rc1 testing, so I'm marking it as fixed.