Jump to content

Z4ub4d3

Active Members
  • Posts

    44
  • Joined

  • Last visited

Posts posted by Z4ub4d3

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

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

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

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

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

  7. Hey everyone,

    Let me clear a few things up:

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

×
×
  • Create New...