-
Posts
44 -
Joined
-
Last visited
Posts posted by Z4ub4d3
-
-
Hmm try follow the factory reset option. Involves putting two of the dip switches in an alternate position turning it on then restarting the pineapple like normal.
-
there certainly are ways... sure that this is not the space to be asking..... perhaps one of the mods can clarify.
-
YouTube funds my tutorials. I can't go back to an iPhone headset duct taped to a homemade PVC pipe mic stand... I just can't.
I understand. Use both, YouTube for continued funding, vimeo for what YouTube rejects.. Just an idea.
-
youtube is for children.. may i recommend https://vimeo.com
-
It's not really an issue of storage space, just thougth I'd try and get it working. Definetly not a necessity.
And the USB drive it formatted to ext4
well i certainly understand that. :)
We don't support USB drives for infusions anymore. As the pineapple requires an SD card inserted, we didn't see why not to offer take this step.
Adding a third option (USB) would just make things messy..
Best Regards,
Sebkinne
this i did not know. as always Seb in with the quick response. (i think he is a non-sleeping robot....
-
given that you can install every infusion plus tons more on the supplied sd card i am wondering why you would want to waste the usb port in such a fashion? now, the only thing i can think of quickly would be to check how the usb stick is formated, i believe it needs to be ext4
(edit for rather bad typo)
-
hehe
the update also fixes an issue where it could generate a single character segment of a mac address and bring down the interface
i think i was previously running into his problem.
-
woot! is now working without any problems. thanks for the update.
-
nice addition. :)
-
I'm kind of confused. Is the large battery with the elite kit called the model "8800?" There only appears to be the small travel pack one (6800) and the large elite pack one (12800).
i am nearly 100% positive that the thread refers to the 6800 and the 8800 is a typo.
-
Infusion files are there.... Not so much with the being installed. I think i recall somebody telling how they got around this in another thread.
-
no hate from me, just a listing of my findings.
-
During my recent battery testing rounds i also was looking at the temps. On average i was running both radios and the processor at or above 50% capacity for full eight to nine hours. For both test i had the pineapple in an enclosed bag with little to no circulation. The temps were never more then slightly warm..... My three cents....
-
i have done some testing of the 6800.
firstly, the test.
i decide to take the simple rout, i set up two cron jobs, one to update a uptime log file every five minutes the other to calculate Pi to 1000 places every three minutes. i also left both radios on. wlan1 i connected to my home router the and wlan0 i left broadcasting as an open ap. i also set up a shell to a aws instance i own so i could reverse shell back in to check up on the logs. i ran this test a total of two times, with full charges in between. the first test i did in two stages as i need the mark V for some actual work. first stage it had a three hour run on the battery, the second stage netted nearly six more hours for a total of about nine hours of uptime. the second test i ran over night at last look it was over eight hours... however when i went to check up on it after the battery died, upon boot using the wall power the log was missing data. i know the log was being written to as i had used the log to check at the eight hour mark. not sure what happened here. both time the battery was charged to full with three solid green lights that stayed solid for a good few hours after usage started. both times it took over 12 hours to get a full charge. not sure if i have a bad unit, i am expecting to much and my usage testing is to high or a combination of both.
the boring stuff.the script for Pi (found online)
#!/bin/bash pi() { export x=`echo "scale=$scale; 4 * a (1)" | bc -l` echo "$x" } if [ "$#" = "1" ] then scale="$1" echo `time pi` else echo "Usage: $0 #" fi
the cron entry for generating the uptime log file
*/5 * * * * uptime >> sd/uplog.log
the cron entry for calling picalc (what i named the script)
*/3 * * * * picalc >> /dev/null
-
Silly question, but are the antennas connected properly?
-
I am not seeing this error, sorry :(
-
1.0.1 under mark V
-
No, it looks like the pbjt.mp3 is missing from that build.
Ill release a fix tonight, hopefully with a couple new features.
Ohhh can't wait to see what the new features are.
-
That's great... After yesterdays bar update it wiped it again. Was going to do it this evening but thanks to you now it's just built in. I know it's something simple but I always want to see that time up there correct even if I'm not connected via client mode and more importantly I want any logs produced in that configuration to be accurate as well.
The logs being correct is the main reason i want the time zone to be set properly as well. Now i do not have to set it manually.
-
Will take a look.
-
ohhh hey great guide. you should update it for the new mark V or make a new one. yabasoya, Scott has screen shots etc :)
-
If you need to change your timezone.
Open up your system file in /etc/config and edit the UTC line, place the appropriate time zone from this list http://wiki.openwrt.org/doc/uci/system#time.zones between the quotes ...
Sorry, on phone or would proved screen shots etc
-
Hey everyone,
Let me clear a few things up:
- SSLStrip: I know many of you are having issues. The easiest way to resolve them is build the fixes (uninstalling some python libraries, creating symlinks, installing sslstrip, etc) right into the SSLStrip infusion, at least right now. What I'll be doing this week, is adding a postinstall script to the SSLStrip package. That means it will run all of these fixes for you upon install. However, this is NOT a bug in the firmware. It is a bug in SSLStrip, at least with newer libraries. However, as we haven't changed SSLStrip or anything to do with it in 1.0.1, I'm not sure what is going wrong.
- Randomroll: The reason randomroll is broken is because of our recent security fixes. The fixes and the result were intentional though. What happens is that ANY file that is not in the /www/ folder has a file prepended and appended. Those check if you are logged in or not and potentially do a few different things in the future. The issue here is that Foxtrot is using symlinks, like he should, as the files are too large. So, the issue is that the files aren't actually in /www/ but rather in a subfolder of /sd/. So, the script we wrote will automatically protect any .php files there.
So, how can we fix it? I'm sure Foxtrot will be pushing this as an update later, but for now, install randomroll as you normally would. Before setting it set up, SSH in and edit the following file: /sd/infusions/randomroll/assets/files/index.php. Go to the VERY end of the file and add <?php exit(); ?> to it. This needs to be the last entry in the file. Once you have completed that step, proceed setting up randomroll (especially the enable index.php). If you have already set up randomroll, first disable index.php and then do the above changes. Then re-enable it.
Karma has in no way changed. It was just brought up in the context of the broken randomroll. I just wanted to clarify this as people might otherwise be deterred from upgrading.
So, if overall the only complain is randomroll, I think it was a successful upgrade.
Best Regards,
Sebkinne
I had a feeling that it was something along these lines. For my part, I carefully and intentionally worded my post so I never indicated a "bug", but that something was introduced, and perhaps expected behavior. This was an upgrade after all with improvements at the security level, and I had a suspicion this was the side effect of an improvement pushed in the new update and not unexpected.
I'm glad to know what the issue is, fix it up, and get on with it, thanks again for taking such good care of us seb! We love you brother! :)
i also did not think it was a bug per say in the update. although, karma was not working for me .. i think it was something i did though as after i reflashed the new update for the second time karma worked fine. /shrug (side note: whether introduced by untended behavior or changes when something breaks it is sort of a bug...)
i must say, WOW!! Seb the turn around time on finding a fix for these issues is nothing short of amazing (no i am not sucking up, genuinely impressed). i have not yet implemented said fixes as i a not near my pineapple but will be doing so son as i can.
as to randomroll being a big deal. um it kinda is. randomroll is the safest, least intrusive, most benign way to demonstrate to people just how vulnerable they leave themselves by using certain lazy measures. randomroll also entertains those being shown and those showing. my three cents (no longer two as it has been adjusted for inflation)
-
Well after a second factory reset and subsequent reinstall reconfigure... Karma seams to be working.
Can't login to 192.168.1.1
in WiFi Pineapple Mark V
Posted
Instructions here https://forums.hak5.org/index.php?/topic/30966-how-to-reset-mark-v-to-system-defaults/?fromsearch=1