Jump to content

0jf5

Active Members
  • Posts

    29
  • Joined

  • Last visited

Posts posted by 0jf5

  1. I have just tried and with the Pineapple connected via ethernet to my PC, a client who is connecting to the Pineapple sees a dramatic decadence on the download speed (from 28.13 Mbps to 3.59 Mbps). Ping and upload are instead almost the same.

    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.

  2. 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

  3. 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?

  4. 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
    
  5. 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

  6. 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

  7. 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.

  8. you must forgive me for my n00bness, as well as my racial handicap, but as much as i'm into fucking myself real good, if you go randomising your MAC address, doesn't it make you susceptible to getting penetrated by your own device re the use of MAC address blacklisting/whitelisting?

    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.

  9. What software/hardware are y'all using to get these measurements?

    I've used 5 so far, kismet, tcpdump, wifi analyzer on android, airodump-ng and LinSSID, all show the same thing. FYI kismet says their signal meter isn't acurate at all, which is why I used 4 more on 3 clients.

    I have a Fluke OptiView XG at work but at this point it's going to confirm what the others already have.

    http://www.cdw.com/shop/products/Fluke-OptiView-XG-Wireless-Analysis-Tablet-with-AirMagnet-WiFi-Analyzer-Sp/3023709.aspx

    The fluke is nice, we have a larger procurve wireless WAN that we use it to troubleshoot with.

    Even though the ar9331 is consumer grade hardware, it still should hold fairly stable tx until total clients reaches X and the cpu hangs. I bought an alfa ap121u (same box the mk4 runs on) which should be here w/in the week to compare and use instead of the mk5

  10. That would strike me as odd as karma is not running.

    Monitoring signal while not being connected yields relatively normal TX however -5X dBm is good but still weak for a client that is now 36 inches from the AP.

    10da7wy.png

    Once connected TX improves to -4dBm (excellent) and oscillates in an aprox 50dBm range. Karma still off, pineapple is just doing ICS. That's an incredibly unstable TX range.

    vryn21.png

    When karma is on, TX jumps to an expected -5dBm (it should be this good all the time from this location) k19bg8.jpg

    When a client connects, TX drops again

    303kzzm.jpg

    As I mentioned in the other thread, when a client is connected non karma and begins a file transfer >=1MB/sec the client gets booted and pineapple reports the deauth do to inactivity. The client can then not connect unless the pineapple is rebooted (see this: https://forums.hak5.org/index.php?/topic/31047-hostapd-deauthenticated-due-to-inactivity-timer-deauthremove/?p=233702 ). At no point does the blue LED flash indicating traffic on wlan0 regardless if Karma is on or off, it never happens.

  11. Here's an update to my thread here https://forums.hak5.org/index.php?/topic/31047-hostapd-deauthenticated-due-to-inactivity-timer-deauthremove/

    This appears to be a hardware issue (which may be causing the deauth problem) as tx power is all over the place. Those readings are from 30ft away from the pineapple. At a minimum it should be -60dBm and not have a 20+/-dBm range w/ gaps in signal. See attached pics and note the pattern.

    For reference the other AP's in the pics are the neighbors.... >=200ft from me.

    Additionally, it's my understanding that the blue LED should light up when traffic is passed over the AR9331. Mine never does.

    Settings:

    root@Pineapple:~# cat /etc/config/system 
    
    config system
    	option hostname 'Pineapple'
    	option timezone 'GMT6'
    
    config timeserver 'ntp'
    	list server '0.openwrt.pool.ntp.org'
    	list server '1.openwrt.pool.ntp.org'
    	list server '2.openwrt.pool.ntp.org'
    	list server '3.openwrt.pool.ntp.org'
    	option enable_server '0'
    
    config led
    	option name 'ethernet'
    	option sysfs 'mk5:amber:lan'
    	option trigger 'netdev'
    	option dev 'eth0'
    	option mode 'link tx rx'
    
    config led
    	option name 'wlan0'
    	option sysfs 'mk5:blue:wlan0'
    	option trigger 'netdev'
    	option dev 'wlan0'
    	option mode 'link tx rx'
    
    config led
    	option name 'wlan1'
    	option sysfs 'mk5:red:wlan1'
    	option trigger 'netdev'
    	option dev 'wlan1'
    	option mode 'link tx rx'
    

    I sent in a request for an exchange on 11/24 and haven't heard anything back yet.

    post-45780-0-18930000-1385793322_thumb.p

    post-45780-0-90538500-1385793322_thumb.p

×
×
  • Create New...