Jump to content

0jf5

Active Members
  • Content Count

    29
  • Joined

  • Last visited

About 0jf5

  • Rank
    Hak5 Fan

Recent Profile Visitors

1,532 profile views
  1. 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.
  2. 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.
  3. Do this to capture your logs after reboot: https://forums.hak5.org/index.php?/topic/31342-save-syslog/?hl=syslog
  4. 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
  5. 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?
  6. 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
  7. 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
  8. 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.
  9. 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 b
  10. 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
  11. 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.
  12. 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 pla
  13. 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.
  14. 802.11b is only 11Mbps - tcp/ip overhead - signal strength = 11-XMbps switch to a or g for faster speeds.
×
×
  • Create New...