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.

I've never gotten more than 5.06Mbps with this exact same configuration regardless of wireless device and location. I thought it was just me.

Do this to capture your logs after reboot: https://forums.hak5.org/index.php?/topic/31342-save-syslog/?hl=syslog

Jan 1 02:01:05 Pineapple daemon.info hostapd: wlan0: STA d8:b3:77:f1:85:30 IEEE 802.11: authenticated Jan 1 02:01:05 Pineapple daemon.info hostapd: wlan0: STA d8:b3:77:f1:85:30 IEEE 802.11: associated (aid 2) Jan 1 02:03:39 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:58:5d:0d IEEE 802.11: authenticated Jan 1 02:03:39 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:58:5d:0d IEEE 802.11: associated (aid 3) Jan 1 02:33:26 Pineapple daemon.info hostapd: wlan0: STA d8:b3:77:f1:85:30 IEEE 802.11: disassociated due to inactivity Jan 1 02:33:27 Pineapple daemon.info hostapd: wlan0: STA d8:b3:77:f1:85:30 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) Jan 1 02:33:35 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:58:5d:0d IEEE 802.11: disassociated due to inactivity Jan 1 02:33:37 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:58:5d:0d IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) Jan 1 04:51:21 Pineapple daemon.info hostapd: wlan0: STA d8:b3:77:f1:85:30 IEEE 802.11: authenticated Jan 1 04:51:21 Pineapple daemon.info hostapd: wlan0: STA d8:b3:77:f1:85:30 IEEE 802.11: associated (aid 2) Jan 1 04:51:56 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:58:5d:0d IEEE 802.11: authenticated Jan 1 04:51:56 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:58:5d:0d IEEE 802.11: associated (aid 3) Jan 1 05:17:50 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:58:5d:0d IEEE 802.11: authenticated Jan 1 05:17:50 Pineapple daemon.info hostapd: wlan0: STA 00:90:4b:58:5d:0d IEEE 802.11: associated (aid 3) Jan 1 05:58:43 Pineapple daemon.info hostapd: wlan0: STA d8:b3:77:f1:85:30 IEEE 802.11: disassociated due to inactivity Jan 1 05:58:44 Pineapple daemon.info hostapd: wlan0: STA d8:b3:77:f1:85:30 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) Jan 1 15:02:39 Pineapple daemon.info hostapd: wlan0: STA d8:b3:77:f1:85:30 IEEE 802.11: authenticated Jan 1 15:02:39 Pineapple daemon.info hostapd: wlan0: STA d8:b3:77:f1:85:30 IEEE 802.11: associated (aid 2) also this issue is back https://forums.hak5.org/index.php?/topic/31120-unstable-tx-power-on-ar9331/#entry234207 Also not sure why my bug report on ntpd not starting was closed. Testing it on 2 devices out of X may not be the best sample size if there's an issue. It appears literally nothing has improved on my end regardless of firmware updates from 1.0-1.3 and the replacement pineapple. Please direct me on the proper channel to get a refund. Thanks

server or client?

If the Karma SSID is different than what is in /etc/config/wireless (set by the karma tab on the web interface), is the SSID supposed to revert back to that of /etc/config/wireless once karma is turned off?

syslogs are stored only in memory therefore if it's rebooting on its own you'll never see anything logged as to why. you can write, and therefore store, syslog data onto the sd card to solve that probem with this script: https://forums.hak5.org/index.php?/topic/31342-save-syslog/?hl=syslog

throw this in /etc/rc.local, or make an init script, and/or throw a wrapper around it to make it persistant. Syslog data is currently only saved in memory which is limited to 0-XMB depending on what you're doing. This will throw everything into an actual log file and retain data after reboot. Code is probbaly ugly but made sense at 2am and seems to work: #!/bin/sh #Change whatever paths and filenames you want, feel free to modify as needed sdcard="/sd" log="$sdcard"/syslog/syslog if [ ! -d "$sdcard" ]; then echo "Please mount your sd card and set the \"sdcard\" variable" elif [ ! -d "$sdcard"/syslog ]; then mkdir "$sdcard"/syslog if [ -e "$log" ]; then /sbin/logread -f >> "$log" else /sbin/logread > "$log" /sbin/logread -f >> "$log" fi else if [ -e "$log" ]; then /sbin/logread -f >> "$log" else /sbin/logread > "$log" /sbin/logread -f >> "$log" fi fi

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.

Could be, you can make a hack fix for the deauth issue by throwing this into /etc/rc.local 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 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

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

is your work lan using dhcp or static ips? Does your work lan require any type of authorization for mac addrs added to the switch ie cisco port securtiy? the one size fits all "switch to dhcp" doesn't even scratch the surface of network configuration.

If you've got a dedicated box for a router, benchmark from that first then check the wifi devices. Otherwise benchmark first from your fastest box w/ the least # of hops between you and your isp, then test the wifi devices. Getting 16Mbps+ when the isp caps @ 15 usually means there's some caching going on somewhere. Idealy you run 20+ (more is better) benchmarks from the same source and calculate the avg and stdev. do the same from different speed test sites so you can get an idea of the statistical range you are likely to achieve. If you're not on a dedicated line, ie cable, time of day plays a big factor.

LOL! Another way to do it is to generate a poll of random macs 1-X, whitelist all of them and pull randomly from the pool and removing the current mac from the pool. or... make a wraper for whatever the current built in mac changer script that comes w/ the mk5 which automaticaly whitelists after a change. This is probbaly the cleanest method thats 5-10min in scripting to acomplish.

802.11b is only 11Mbps - tcp/ip overhead - signal strength = 11-XMbps switch to a or g for faster speeds.