hostapd: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

[0jf5]

Wlan0 as an AP is dropping all clients and won't consistently allow them to reconnect w/o a restart. The funny thing is that the 00:90:4b machine was in the process of transfering files during an apt-get upgrade when the pineapple booted it from the network.

The f0:a2 box syncs various services every 1-2 sec.

A quick google search makes it look like openwrt is riddled with this issue.

syslog:

23:57:32 Pineapple daemon.info hostapd: wlan0: STA f0:a2:25:XX:XX:XX IEEE 802.11: authenticated
23:57:32 Pineapple daemon.info hostapd: wlan0: STA f0:a2:25:XX:XX:XX IEEE 802.11: associated (aid 1)
23:57:29 Pineapple daemon.info hostapd: wlan0: STA f0:a2:25:XX:XX:XX IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
23:56:59 Pineapple daemon.info hostapd: wlan0: STA f0:a2:25:XX:XX:XX IEEE 802.11: disconnected due to excessive missing ACKs
23:55:25 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:XX:XX:XX IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
23:54:55 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:XX:XX:XX IEEE 802.11: disconnected due to excessive missing ACKs
23:52:34 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:XX:XX:XX IEEE 802.11: authenticated
23:52:34 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:XX:XX:XX IEEE 802.11: associated (aid 2)
23:40:06 Pineapple auth.info sshd[1844]: Accepted password for root from 192.168.0.2 port 60018 ssh2

/etc/config/wireless:

config wifi-device  radio0
    option type     mac80211
    option channel  11
    option hwmode    11ng
    option macaddr    00:13:37:XX:XX:XX
    option htmode    HT20
    list ht_capab    SHORT-GI-20
    list ht_capab    SHORT-GI-40
    list ht_capab    RX-STBC1
    list ht_capab    DSSS_CCK-40
    # REMOVE THIS LINE TO ENABLE WIFI:
    # option disabled 1

config wifi-iface
    option device   radio0
    option network  lan
    option mode     ap
    option ssid     Pineapple5_XXXX
    option encryption none

config wifi-device  radio1
    option type     mac80211
    option channel  11
    option hwmode    11g
    option macaddr    00:13:37:XX:XX:XX

    # REMOVE THIS LINE TO ENABLE WIFI:
    # option disabled 1

config wifi-iface
    option device   radio1
    option network  lan
    option mode     ap
    option ssid     Pineapple5_XXXX
    option encryption none

ifconfig:

br-lan    Link encap:Ethernet  HWaddr 00:13:37:XX:XX:XX 
          inet addr:192.168.0.30  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:23310 errors:0 dropped:24 overruns:0 frame:0
          TX packets:18780 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2016992 (1.9 MiB)  TX bytes:2331550 (2.2 MiB)

eth0      Link encap:Ethernet  HWaddr 00:13:37:XX:XX:XX  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:63569 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39201 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:60729778 (57.9 MiB)  TX bytes:3922365 (3.7 MiB)
          Interrupt:4

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:920 errors:0 dropped:0 overruns:0 frame:0
          TX packets:920 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:67539 (65.9 KiB)  TX bytes:67539 (65.9 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:13:37:XX:XX:XX  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:20417 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41317 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1590735 (1.5 MiB)  TX bytes:59256792 (56.5 MiB)

This is 1.0.4 firmware, issue has persisted since 1.0. Is anyone else running into this?

[thesugarat]

The only time I've seen an inactivity error like that is when running Karma. I assumed their devices security was preventing activity.

[0jf5]

I haven't even started using karma yet. Just using the mkV as an AP (which currently it can't do reliably for some reason)

The other thing that ive noticed is that when the AP boots everyone, and after the clients eventually fail to reconnect, signal strengh shows full bars > -50db but when you manually try to connect, the client shows the signal dropping to 1 bar which is generally < -80dbish and it fails to reconnect. As soon as it fails, and is disconnected, signal strength jumps back up to > -50db. This is happening on both clients.

syslog from client side:

Nov 22 20:19:36 pav wpa_supplicant[2251]: wlan1: CTRL-EVENT-DISCONNECTED bssid=00:13:37:XX:XX:XX reason=4
Nov 22 20:19:36 pav kernel: [306928.504071] ieee80211 phy0: wlan1: No probe response from AP 00:13:37:XX:XX:XX after 500ms, disconnecting.
Nov 22 20:19:36 pav kernel: [306928.505297] cfg80211: Calling CRDA to update world regulatory domain
Nov 22 20:19:36 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: completed -> disconnected
Nov 22 20:19:36 pav kernel: [306928.532215] cfg80211: World regulatory domain updated:
Nov 22 20:19:36 pav kernel: [306928.532225] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Nov 22 20:19:36 pav kernel: [306928.532229] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 22 20:19:36 pav kernel: [306928.532233] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Nov 22 20:19:36 pav kernel: [306928.532236] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Nov 22 20:19:36 pav kernel: [306928.532240] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 22 20:19:36 pav kernel: [306928.532243] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 22 20:19:36 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: disconnected -> scanning
Nov 22 20:19:37 pav wpa_supplicant[2251]: wlan1: SME: Trying to authenticate with 00:13:37:XX:XX:XX (SSID='Pineapple5_XXXX' freq=2462 MHz)
Nov 22 20:19:37 pav kernel: [306929.765384] wlan1: authenticate with 00:13:37:XX:XX:XX
Nov 22 20:19:37 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: scanning -> authenticating
Nov 22 20:19:37 pav kernel: [306929.776314] wlan1: send auth to 00:13:37:XX:XX:XX (try 1/3)
Nov 22 20:19:37 pav kernel: [306929.980036] wlan1: send auth to 00:13:37:XX:XX:XX (try 2/3)
Nov 22 20:19:38 pav kernel: [306930.184038] wlan1: send auth to 00:13:37:XX:XX:XX (try 3/3)
Nov 22 20:19:38 pav kernel: [306930.388033] wlan1: authentication with 00:13:37:XX:XX:XX timed out
Nov 22 20:19:38 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: authenticating -> disconnected
Nov 22 20:19:38 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: disconnected -> scanning
Nov 22 20:19:39 pav wpa_supplicant[2251]: wlan1: SME: Trying to authenticate with 00:13:37:XX:XX:XX (SSID='Pineapple5_XXXX' freq=2462 MHz)
Nov 22 20:19:39 pav kernel: [306931.649153] wlan1: authenticate with 00:13:37:XX:XX:XX
Nov 22 20:19:39 pav kernel: [306931.656329] wlan1: direct probe to 00:13:37:XX:XX:XX (try 1/3)
Nov 22 20:19:39 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: scanning -> authenticating
Nov 22 20:19:39 pav kernel: [306931.860039] wlan1: direct probe to 00:13:37:XX:XX:XX (try 2/3)
Nov 22 20:19:40 pav kernel: [306932.064065] wlan1: direct probe to 00:13:37:XX:XX:XX (try 3/3)
Nov 22 20:19:40 pav kernel: [306932.268032] wlan1: authentication with 00:13:37:XX:XX:XX timed out
Nov 22 20:19:40 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: authenticating -> disconnected
Nov 22 20:19:40 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: disconnected -> scanning
Nov 22 20:19:41 pav wpa_supplicant[2251]: wlan1: SME: Trying to authenticate with 00:13:37:XX:XX:XX (SSID='Pineapple5_XXXX' freq=2462 MHz)
Nov 22 20:19:41 pav kernel: [306933.537424] wlan1: authenticate with 00:13:37:XX:XX:XX
Nov 22 20:19:41 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: scanning -> authenticating
Nov 22 20:19:41 pav kernel: [306933.548330] wlan1: direct probe to 00:13:37:XX:XX:XX (try 1/3)
Nov 22 20:19:41 pav kernel: [306933.752040] wlan1: direct probe to 00:13:37:XX:XX:XX (try 2/3)
Nov 22 20:19:41 pav kernel: [306933.956035] wlan1: direct probe to 00:13:37:XX:XX:XX (try 3/3)
Nov 22 20:19:42 pav kernel: [306934.160035] wlan1: authentication with 00:13:37:XX:XX:XX timed out
Nov 22 20:19:42 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: authenticating -> disconnected
Nov 22 20:19:42 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: disconnected -> scanning
Nov 22 20:19:43 pav wpa_supplicant[2251]: wlan1: SME: Trying to authenticate with 00:13:37:XX:XX:XX (SSID='Pineapple5_XXXX' freq=2462 MHz)
Nov 22 20:19:43 pav kernel: [306935.417645] wlan1: authenticate with 00:13:37:XX:XX:XX
Nov 22 20:19:43 pav kernel: [306935.428336] wlan1: direct probe to 00:13:37:XX:XX:XX (try 1/3)
Nov 22 20:19:43 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: scanning -> authenticating
Nov 22 20:19:43 pav kernel: [306935.632037] wlan1: direct probe to 00:13:37:XX:XX:XX (try 2/3)
Nov 22 20:19:43 pav kernel: [306935.836039] wlan1: direct probe to 00:13:37:XX:XX:XX (try 3/3)
Nov 22 20:19:44 pav kernel: [306936.040037] wlan1: authentication with 00:13:37:XX:XX:XX timed out
Nov 22 20:19:44 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: authenticating -> disconnected
Nov 22 20:19:44 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: disconnected -> scanning
Nov 22 20:19:45 pav wpa_supplicant[2251]: wlan1: SME: Trying to authenticate with 00:13:37:XX:XX:XX (SSID='Pineapple5_XXXX' freq=2462 MHz)
Nov 22 20:19:45 pav kernel: [306937.297406] wlan1: authenticate with 00:13:37:XX:XX:XX
Nov 22 20:19:45 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: scanning -> authenticating
Nov 22 20:19:45 pav kernel: [306937.308317] wlan1: direct probe to 00:13:37:XX:XX:XX (try 1/3)
Nov 22 20:19:45 pav kernel: [306937.512035] wlan1: direct probe to 00:13:37:XX:XX:XX (try 2/3)
Nov 22 20:19:45 pav kernel: [306937.716039] wlan1: direct probe to 00:13:37:XX:XX:XX (try 3/3)
Nov 22 20:19:45 pav kernel: [306937.920038] wlan1: authentication with 00:13:37:XX:XX:XX timed out
Nov 22 20:19:45 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: authenticating -> disconnected
Nov 22 20:19:46 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: disconnected -> scanning
Nov 22 20:19:47 pav wpa_supplicant[2251]: wlan1: SME: Trying to authenticate with 00:13:37:XX:XX:XX (SSID='Pineapple5_XXXX' freq=2462 MHz)
Nov 22 20:19:47 pav kernel: [306939.177440] wlan1: authenticate with 00:13:37:XX:XX:XX
Nov 22 20:19:47 pav kernel: [306939.188314] wlan1: direct probe to 00:13:37:XX:XX:XX (try 1/3)
Nov 22 20:19:47 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: scanning -> authenticating
Nov 22 20:19:47 pav kernel: [306939.392037] wlan1: direct probe to 00:13:37:XX:XX:XX (try 2/3)
Nov 22 20:19:47 pav kernel: [306939.596037] wlan1: direct probe to 00:13:37:XX:XX:XX (try 3/3)
Nov 22 20:19:47 pav kernel: [306939.800037] wlan1: authentication with 00:13:37:XX:XX:XX timed out
Nov 22 20:19:47 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: authenticating -> disconnected
Nov 22 20:19:47 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: disconnected -> scanning
Nov 22 20:19:49 pav wpa_supplicant[2251]: wlan1: SME: Trying to authenticate with 00:13:37:XX:XX:XX (SSID='Pineapple5_XXXX' freq=2462 MHz)
Nov 22 20:19:49 pav kernel: [306941.061384] wlan1: authenticate with 00:13:37:XX:XX:XX
Nov 22 20:19:49 pav kernel: [306941.072318] wlan1: direct probe to 00:13:37:XX:XX:XX (try 1/3)
Nov 22 20:19:49 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: scanning -> authenticating
Nov 22 20:19:49 pav kernel: [306941.276036] wlan1: direct probe to 00:13:37:XX:XX:XX (try 2/3)
Nov 22 20:19:49 pav kernel: [306941.480036] wlan1: direct probe to 00:13:37:XX:XX:XX (try 3/3)
Nov 22 20:19:49 pav kernel: [306941.684034] wlan1: authentication with 00:13:37:XX:XX:XX timed out
Nov 22 20:19:49 pav NetworkManager[2163]: <info> (wlan1): supplicant interface state: authenticating -> disconnected

Edited November 23, 2013 by 0jf5

[Darren Kitchen]

I may be experiencing similar issues on one of my pineapples. It'll take some time for me to be able to properly verify that it's the same issue.

After your dropout are you able to reconnect at all or is a power cycle required?

[0jf5]

I can't reconnect at all w/o a reboot of the pineapple even when the client is rebooted and another wifi adaptor is plugged in (built in broadcom and usb alfa RTL8187). I can induce the drop by downloading anything when transfer rates are > 1.xMb/s.

airdump is confirming signal strength of the pineapple wlan0 is fluctuating from -34 (line 186, 29.906450) to -75 (line 104 15.257250) after the disconnect which is a huge range vs the +/- 5db max from the 18 other APs picked up on the same channel. the pineapple is 15ft away from the airmon box one room over.

attached is the pcap of that... "You aren't permitted to upload this kind of file"

shoot me your email addr and i'll send it over.

adding "option disassoc_low_ack 0" to /etc/config/wireless as per https://forum.openwrt.org/viewtopic.php?id=43188 doesn't resolve the issue (there maybe 2 of them, missing ACK's being one) however they recomend using the latest trunk, i dont now which version the pineapple uses.

11:44:30 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:XX:XX:XX IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
11:44:29 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:XX:XX:XX IEEE 802.11: disassociated due to inactivity 

vs

23:57:29 Pineapple daemon.info hostapd: wlan0: STA f0:a2:25:XX:XX:XX IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
23:56:59 Pineapple daemon.info hostapd: wlan0: STA f0:a2:25:XX:XX:XX IEEE 802.11: disconnected due to excessive missing ACKs
23:55:25 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:XX:XX:XX IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
23:54:55 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:XX:XX:XX IEEE 802.11: disconnected due to excessive missing ACKs

no more missing ACK's but clients still get dropped.

during file transfers pwr is ranging from -26 to -74 now. <-- looks like hardware problem.

I was watching signal strength w/ kismet and noticed that once the clients get dropped, the pineapple stops transmitting all together for a period of time (2-3 min) which explains why after it starts sending becons again, clients suddenly "find" the network although they cannot connect to it until the pineapple is rebooted.

Edited November 25, 2013 by 0jf5

[0jf5]

The problem appears to be identified. After getting all the TX problems sorted out by exchanging the MK5, I think i figured out why clients are getting dropped. This problem persists even after hardware was swapped.

https://wifipineapple.com/index.php?portal&bugs&action=view&id=87

The version of hostapd on the mk5 does not (so far) allow/recognize the following parameters to be changed:

ap_max_inactivity & max_listen_interval via /etc/config/wireless. changes manually made to /var/run/hostapd-phyX.conf (these files should probably be in /etc/) are not saved after reboot

Edited December 22, 2013 by 0jf5

[xrad]

So this could be the answer to the only problem I seem to be having.

I can turn on the mark v, not do anything, no karma, and after 10 to 30 minutes I can't connect to it wirelessly.

If I start karma, it doesn't happen (as much) I have had karma running for over 19 hours with no problems.

But I have seen it happen with karma running, just not as much.

I have rebooted so much, I decided to give it a rest and haven't turned it on in 3 days.

[0jf5]

Could be, you can make a hack fix for the deauth issue by throwing this into /etc/rc.local

killall hostapd
echo "ap_max_inactivity=99999" >> /var/run/hostapd-phy0.conf
/usr/sbin/hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf

I found another problem though, wlan0 will stop receiving packets w/o any error on the server side. Clients, will see what i posted in #3 up above

The fix is to manually restart hostapd then Zoooommmmmm magically all the clients can conect w/o a problem. This happens even when the deauth issue is resolved. Again that will happen w/o any errors as far as i can tell from the mk5 side. hostapd w/ -dd -K flags also shows nothing except that your clients are connected ie

wlan0: AP-STA-CONNECTED 00:c0:ca:52:5c:20
wlan0: AP-STA-CONNECTED f0:a2:25:bf:c2:e2
wlan0: AP-STA-CONNECTED 00:90:4b:58:5d:0d

the hostapd on the 1.0.4 and below firmware is completely fkd up to say the least. Since we have no idea what they did to the code to modify it, i'll have to spend some time compiling the 2.0.0 stable on the mk5 and see if it helps. That may prevent karma from working but oh well.

for the deauth issue the sta_info.c in the hostapd 2.0.0 is the area (line 390ish) w/ the STA_DISASSOC case is where all the deauth action happens. Again i don't think it's the origional code that to blame for the deauth issue, it's the way the <=1.0.4 mk5 firmware prevents the ap_max_inactivity from being accepted from /etc/config/wireless, ergo the /etc/rc.local hack

aside from that, why the mk5 hostapd shitcans receiving anything over the radio w/o error orther than ARP i have no idea yet.

take a look at the lights on the mk5 when you're having this problem. they'll be solid green, amber and blue vs flashing amber/blue like normal

Edited December 23, 2013 by 0jf5

[Sebkinne]

Our changes to hostapd have no influence on this - it's the version of hostapd used.

The next firmware upgrade will go into beta soon and be packed with updates (including hostapd+karma).

We certainly do NOT block a specific setting from hostapd. That would be ridiculous. Hostapd has had issues in the past in regards to stability. We are working on it.

Best Regards,

Sebkinne

[0jf5]

Thanks for the update. I'm not saying you're blocking it. I'm saying setting various values set through /etc/config/wireless which populate to /var/run/wifi-phyX.pid don't all populate, hence killing hostapd, appending the config file manually, and restarting the daemon.

[robschoemaker]

This is a pretty old thread, but I still seem to be experiencing the same on my Pineapple. Any definitive solutions yet?

Thanks Rob

[Mr.miYagi]

I have the same Problem here.

Didn't try one of the hacks posted here. Someone can confirm that it works?

[Mr.miYagi]

I added the lines:

killall hostapd

echo "ap_max_inactivity=99999" >> /var/run/hostapd-phy0.conf

/usr/sbin/hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf

With no success. The AP is still kicking and reassoc. the clients.

Some ideas?

Sep 29 15:28:52 Pineapple daemon.info hostapd: wlan0: STA 44:74:6c:3f:xx:xx IEEE 802.11: associated (aid 1)

Sep 29 15:28:52 Pineapple daemon.info hostapd: wlan0: STA 44:74:6c:3f:xx:xx IEEE 802.11: authenticated

Sep 29 15:28:05 Pineapple daemon.info hostapd: wlan0: STA 44:74:6c:3f:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Sep 29 15:28:04 Pineapple daemon.info hostapd: wlan0: STA 44:74:6c:3f:xx:xx IEEE 802.11: disassociated

Sep 29 15:28:04 Pineapple daemon.info hostapd: wlan0: STA 44:74:6c:3f:xx:xx IEEE 802.11: associated (aid 1)

Sep 29 15:28:04 Pineapple daemon.info hostapd: wlan0: STA 44:74:6c:3f:xx:xx IEEE 802.11: authenticated

Sep 29 15:28:01 Pineapple daemon.info hostapd: wlan0: STA 44:74:6c:3f:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Sep 29 15:28:00 Pineapple daemon.info hostapd: wlan0: STA 44:74:6c:3f:xx:xx IEEE 802.11: disassociated

[Smart-Aswood]

Same problem here, still. Using the Pineapple as an AP hasn't been stable. Started new unit yesterday and brought everything up to date before using.

Nov 26 14:34:10 Pineapple daemon.info hostapd: wlan0: STA bla bla bla IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Nov 26 14:34:09 Pineapple daemon.info hostapd: wlan0: STA bla bla bla IEEE 802.11: disassociated due to inactivity

Firmware Version: 2.0.4

[0jf5]

I gave up on this issue, and that's all I'll say about that.

there is far more value in using a raspberry pi w/ usb wireless devices vs a pineapple.

Edited November 29, 2014 by 0jf5

[Smart-Aswood]

I gave up on this issue, and that's all I'll say about that.

there is far more value in using a raspberry pi w/ usb wireless devices vs a pineapple.

I had a holiday weekend in a hotel away from the family, a new MK5 and a new Raspberry B+ so I figured I'd give it a shot. VERY difficult to keep the radio and ethernet on the pi connected. Impossible so far. And then when you accomplish keeping both eth0 and wlan0 running (through trickery) one or the other of them isn't really connected - it's lights are flashing away but you don't have an internet connection through the MK5. I spent 9 hours on rounting tables so I'd be ready when I got the radios figured out. Never happened.

There's people on the internet who say they've done it, but I followed their exact procedure without success.

Not much value in that, far as I'm concerned.

http://www.glennklockwood.com/sa/rpi-wifi-bridge.php

http://hackhappy.org/uncategorized/how-to-use-a-raspberry-pi-to-create-a-wireless-to-wired-network-bridge/

Not sure I believe it.

Mini-PC? Sure it'll work. Raspberry Pi? I don't think the Raspberry Pi hardware supports it.

You're welcome to prove me wrong. At this point I'd enjoy that.

Edited December 1, 2014 by Smart-Aswood

[Smart-Aswood]

Oh shoot, 0jf5, you mean two USB radios on the Raspberry Pi. My apologies. I'm still going to hang with the Pineapple, mainly because of PineAP. And not because what PineAP is right now, but the potential of it. I'm in industrial automation. I lose sleep over Jasager attacks and anyone in automation who doesn't is in for a rude awakening. Pretty soon we're going to be paying $1000/hr for people to patch our systems up and we'll be glad to pay it. It's not just wifi. With some tweaks, PineAP's basic tech could map to any short-haul radio comm.

When automation gets attacked we don't just lose money. Stuff blows up. Very nasty stuff like acids, hydrocarbons and hydrogen sulfide go to atmosphere. Whole industry has a lot of catching up to do.