JoeyPogoPlugE02 Wrote: > I think it was TEN who mentioned being hammered on port 21 22 actually (standard only because one irresponsible provider fake-RSTs secure connections on other ports, as if it was the Great Firewall of China), but several 10000 SSH break-in attempts later I'm happy to report the iptables contrived at http://forum.doozan.com/read.php?2,20609,20799#msg-20799 et sby TEN - Debian
bodhi Wrote: > > For the Pi's sake as well as the Pogo's BTW, > > could anyone port this "transceiver of all trades" > > http://www.harctoolbox.org/lirc_rpi.html ? > > I will take a look at compiling this into Kirkwood > plug first, if successful then Oxnas. Great! :) For the RF I'm thinking of something like http://www.ebay.com/itm/Geby TEN - Debian
bodhi Wrote: > > Speaking of GPIO pins, do you see a way to use > > them (or the internal serial port if you happen > to > > have one wired up) for > > http://lirc.org/receivers.html & > > http://lirc.org/transmitters.html and/or ISM RF > > transceivers (the latter requiring neither line > of > > sight nor baseband modulation in softwaby TEN - Off-Topic
JoeyPogoPlugE02 Wrote: > And now your laugh for the day > http://www.theguardian.com/technology/2015/feb/09/ > raspberry-pi-2-camera-flash-power-off > > I did NOT know that! That laugh was lost since I had to read some irresponsibly scandalized reporting calling it "Xenongate", as if firing an EM pulse weapon ;) (visible or otherwise) next to an exposed unshielby TEN - Debian
TEN Wrote: > Reliability of irsend transmissions on this > hardware has been improved over configurations > from http://lirc.org/remotes by re-sampling the > respective controls in raw mode as follows (for > lirc-0.8.7), but the results (3 retries approx. > required for proper reception by the controlled > appliances) still suggest there might be a problem > withby TEN - Debian
bodhi Wrote: > > > though unlikely in spite of negotiable USB current, is there by any chance a way to > > > completely cut & re-enable power to one particular port in software > > > (that would open up some nice control opportunities) ? > > > > We could do it with GPIO. I recall there is a > > shell utility somewhere that allows you to >by TEN - Off-Topic
bodhi Wrote: > TEN, It is difficult to find the right thread because you're not registered Actually I have been for a few weeks now, but it's probably the Reliability thread you're referring to where I'd mentioned this some days after getting myself an account at last: http://forum.doozan.com/read.php?8,20700,20714#msg-20714 > this issue about the front USB port oby TEN - Debian
restamp Wrote: ------------------------------------------------------- > I posted some information about how to set up x10d > and get it running on my website: > > http://stampfli.us/x10/ > > It's a lot to assimilate in one sitting, > especially if you are not already well-versed in > the details from a Unix perspective. Plus, I > haven't really wby TEN - Debian
bodhi Wrote: > Does the X10 interfere with other RF equipments in your environment? In Europe, permissible transmit power for X10 on the mains is so limited indeed that CFL lighting, starters and switching PSUs become much of an obstacle to the signal, in particular until a (low-frequency, unlike PLC networking) phase coupler has been installed. The newer A10 modules are said to be muby TEN - Debian
restamp Wrote: ------------------------------------------------------- > I have never used heyu, but I do run run a highly > modified, i.e., almost completely rewritten, > version of Dan Lanciani's "x10d" on my Plug and > find it works quite well for me. It compiles with > a simple "make x10d". [...] I could cobble > together some quick notes, alby TEN - Debian
heyu-2.11-rc1.tar.gz from http://www.heyu.org/download/ should be a more recent implementation than http://search.cpan.org/~bbirth/ControlX10-CM11-2.09/CM11.pm to control some shutter switches and lighting over powerline. https://groups.google.com/forum/#!topic/domuslink-users/I7LSvx8H13U tells me http://x10linux.blogspot.de/2012/08/installing-heyu-on-raspberry-pi.html can be done even for ARMv5by TEN - Debian
QuotebodhiI've just peeked at the code (difference between Dockstar and Pogo E02). Yes, there was a missing configuration for jffs2 in Pogo E02 u-boot! I will add this in the next release. Feel free to take a cascade like mine in http://archlinuxarm.org/forum/viewtopic.php?f=30&t=8383#p46069 to automagically fall back to each of the various possible USB and NAND OSs from your default envby TEN - uBoot
QuoteFrederick GraysonI find the denyhosts package more than adequate for dealing with ssh brute force abuse. Sure, quite a useful /etc/hosts.deny IPS approach (requiring Python which is no default either) like the aforementioned http://la-samhna.de/library/brutessh.html#4 - but besides sharing options like yours, the purpose of these posts has been to illustrate how to create customizable, slighby TEN - Debian
QuoteJohnWYes it might not work... The two different adapters i got with my V4 and Mobile work with 230V 50HZ.Which way did you find to save on the aforementioned US$80 postage & get the cashback from Sweden?by TEN - Debian
restamp Wrote: > > Limiting the number of password attempts per ssh logon to 2 (i.e. allow for 1 human typo) > > rather than 5 would also be helpful, if anyone knows where this should best be set. > > It's set in /etc/ssh/sshd_config: "MaxAuthTries 2" Thanks, :) indeed, followed by service ssh restart, and it won't be long until after just 2 hack aby TEN - Debian
JohnW Wrote: > Too bad shipping to Sweden is $80 USD... Doh... Would non-U.S. addresses be eligible to rebate at all (standard "mail-in your immortal soul, SSN, Driver's License etc. in hope for a refund cheque - that cannot be cashed at a foreign bank anyway" procedure) ? And while power cords with the Euro plug could be found, do these units come with a multi-voltageby TEN - Debian
TL;DR: Thwart about 95% of logging & load from ssh brute-force attacks (mainly from mainland China at present): /etc/network/if-up.d/iptables (chmod 755) of#!/bin/sh iptables-restore < /etc/iptables/rules.v4 with the contents below for the latter file *filter :INPUT ACCEPT [52:3440] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [36:5048] :SSHbrute - [0:0] -A INPUT -i eth0 -p tcp -m tcp --by TEN - Debian
bodhi wrote: > Is the link above correct? :) Not exactly, mine are as black (with a nod to Henry Ford ;-)) as my "Pink" Pogos, rather than white as in http://www.dacal.com.tw/cd-library-ii/ Thanks to the unchanged form factor, what they really host are all-seasons BluRays (liberated from their often unreasonably damage-prone cardboard sleeves) or DVDs of everything I should haby TEN - Debian
bodhi Wrote: ------------------------------------------------------- > > > locale: Cannot set LC_ALL to default locale: No such file or directory > > > For locale I'm not too sure what should be the > > canonical approach (certainly not setting LC_ALL > > which is a testing override only) to stop perl etc. from nagging. > > Below was what I did tby TEN - Debian
bodhi Wrote: > you can go back to wheezy and run kernel 3.18.5. The cause of crashes being reproducible in a LIRC module moved to kernel, I may rather not want to upgrade to the bug though. ;-) Can't tell whether 3.19.1 handles mceusb any better, since there's little interest at http://archlinuxarm.org/forum/viewtopic.php?f=6&t=8652 which is using that kernel already.by TEN - Debian
bodhi wrote: > TEN wrote: > > happy to report that with one more Xlyne stick > > of similar speed and capacity [...] method 4b as > > su (re-arranged for minimal input & risk of error) > > worked just fine Sadly kernel 3.18.5's implementation of LIRC seems way too crash-prone for production, cf. http://forum.doozan.com/read.php?2,20609,20753#msg-20753 wby TEN - Debian
Here's the experience with FDT jessie on kernel 3.18.5 so far, after hours of apt-get update && apt-get upgrade: QuotePreparing to unpack .../tzdata_2015b-1_all.deb ... Unpacking tzdata (2015b-1) over (2015a-1) ... Setting up tzdata (2015b-1) ... locale: Cannot set LC_ALL to default locale: No such file or directory Current default time zone: 'SystemV/PST8PDT' Localby TEN - Debian
As I couldn't make kernel 3.18.5 boot from an Intenso 8GB stick (though one of the same batch worked with Arch's 3.19) and resorted to 3.16 instead in http://forum.doozan.com/read.php?3,19419,20577#msg-20577, I am happy to report that with one more Xlyne stick of similar speed and capacity (and less of a Blinkenlight :)) that had been in the mail, going through the steps for method 4b aby TEN - Debian
bodhi wrote: > TEN wrote: > > Well, in these cases it did fall back into stock > > How's Jeff running fsck on boot? I thought some > > versions of his uBoot were just alternating the > > boot order between retries. > > U-boot itsef does not really do anything, but > Jeff's env for bootcmd has a reset at the end. > That's the conventiby TEN - Off-Topic
bodhi Wrote: > TEN Wrote: > > Very similar: Dockstar ometimes ... would need > > a few cycles to launch from USB after power outages, > but I understand that was a function of Jeff's uBoot. > > I think rather Jeff's setup allows a corrupted > rootfs have a chance to be fixed and boot again. Well, in these cases it did fall back into stock - which isby TEN - Off-Topic
Very similar: Dockstar even had a power-hungry DVB-T stick and 4-in-1 hub on it but worked well 24/7 for half a decade. Sometimes it would need a few cycles to launch from USB after power outages, but I understand that was a function of Jeff's uBoot. Never had one of the specially-cased hard disks particularly made for its cradle on it, but rather a mini-to-regular USB adapter with a stick.by TEN - Off-Topic
QuotebodhiI'd guess there were changes in the default setup for latest versions ... I did not explicitly change the defaults at all in the basic rootfs (I left it up to individuals to tailor their rootfs).It seems https://wiki.debian.org/nftables has been retracted even on jessie. Not sure what is firewalling actually in your 3.16 release, as there's no iptables binary either. So Iby TEN - Debian
QuotebodhiSomething is not right. The halt command can't be executed that fast. I've never seen my boxes fail to turn off the LED while shuttingdown! But if it works with a few extra seconds shutting down, so be it :)Now there we have it; you've exposed a Secret Agency skunkworks project building a Beowulf cluster of nitrogen-cooled Pogoplugs overclocked to 4+GHz each, computing foby TEN - Debian
> Is the echo command located before the halt command in /etc/init.d/halt? It is, and actually sleep 5 in between just before the log_action_msg "Will now halt" does the trick: Then the LED has time to be turned off - while I can't trace the code path from the file change to settting GPIO, this looks like a race condition of the harmless kind. FWIW these look OK to me: Macby TEN - Debian
QuoteTENQuotebodhiQuoteTENShouldn't the LED go dark (echo 0 >/sys/class/leds/status:green:health/brightness) on halt, to signal when it's safe to pull the plug (or light up then if it was off during normal operation?) It should. See /etc/init.d/halt. It turns off the LED, not just going dark. And it turns on Green in /etc/rc.local. echo none > /sys/class/leds/status:green:healtby TEN - Debian