[Rack] Rewrite of opengate-www script
BenBE1987 at gmx.net
Mon Dec 6 01:45:27 PST 2010
Am Sonntag, den 05.12.2010, 15:44 -0800 schrieb miloh:
> On Sun, Dec 5, 2010 at 12:47 AM, Benny Baumann <BenBE1987 at gmx.net>
> there has been some timing issue / racing condition inside the
> opengate-www script which could be used to buzz the gate
> multiple times
> inside the 30 seconds window. The problem was caused by the
> "sleep" beeing issued last in the script, thus opening a
> window of
> approx. 5-10 seconds for multiple buzzing the gate while
> instance was still processing. Since the load caused by
> buzzing the gate
> could be used to slow down the SSH processing and other script
> activities this could be used for a DoS attack on the gate.
> Thanks for fixing this -- this caused humorous problems (multiple beep
> patterns being played) and sometimes caused the door to fail to open
> at the correct time, do you think it was used to attack the gate?
I doubt it was used in a DoS on the gate. Usually when this happened
many people were at NB and thus more than one person buzzed the gate
> What do you mean by the phrase 'the load caused by buzzing the gate'?
> The system uses 2 parallel port pins on the doorway laptop to trigger
> an optoisolater that is connected to the button wires of the switch
> circuit. A momentary connection causes the door strike to release
> which allows one to push open the door.
I know the mechanism of those functionings as I had a look at the C
source doing this control.
What I ment by "load" was processor load on e.g. pony due to some kind
of DDoS attack people could do delay starting of processes (like sleep)
while starting new bash scripts or instances of ssh to buzz the gate.
The fix I applied not only reduces the racing condition which made this
possible, but also causes all those ssh processes would strike nearly at
the same time after releasing the DDoS load, the gate would buzz not
much longer than the time you'd get by a single buzz. With the old
version you could get to buzz the gate quite easily while preventing the
lock to take effect. Since the lock is now in effect before the gate is
buzzed this period is reduced to a minimum and can't be extended to
> Is the software that drives the parallel port on the doorway laptop
> in need of upgrades?
AFAIK no. Although implementing the lock there would be better.
> I rewrote the script opengate-www from scratch moving the
> sleep command to the FIRST operations of the script. This does
> not fully
> eliminate the racing condition (which would require an atomar
> of starting the sleep and asking for different instances), but
> hitting this racing condition to an absolute minimum.
> Thanks for improving this.
More improvents implemented today. See below.
> I also used this chance to clean up the code and combine some
> code into variables making the overall script more readable.
> Anyone who
> feels like shane to have this code contain more comments is
> free to add
> them. Don't touch the actual ssh and sshpass lines as they are
> a PITA to
> On the special request of Isky I disabled the Text-to-Speech
> feature of
> the opengate-www script which I just had fixed. Although this
> feature -
> if activated - seems to truncate the audio for some reason.
> The opengate script in the same folder looks simular fucked up
> like the
> original opengate-www script. Anyone who feels bored enough is
> encouraged to port my changes over.
> There are a bunch of door opening scripts floating around pony, its
> probably time to clean it up.
> I also have a script called bacngate that plays a personalized tone,
> and other people want to personalize or silence their entry tones, or
> perhaps use audio snippets for door opening (within reason). (cf. the
> circus tone door opener you were working on, ;-)
Created an interface to integrate them by using static keys. More on
this later today.
> Goals to have for improving the door opening script:
> 1)The script could be more modular: Tones should be called from the
> script so they can be personalized or not played at all.
Basically it's implemented this way. The command to play the sound is in
an environment variable. MEans to change it have to be implemented
> 2) The script should barf if the doorway laptop isn't opening the
> door, and perhaps use TTS then: 'please use the intercom to open the
The Web script now does.
> 3) a lockfile can be implemented as Jake said.
Yeah, could ...
> Can you help me implement these ideas Benny? I want to do it but I'll
> need assistance and review.
> While at this I moved the id_dsa key for authenticating with
> different servers for the script to work - with Rubin's
> consent in doing
> so - from his home directory over
> to /var/hg/gate/.ssh-opengate/. The
> directory is 770 root:hg and the keyfiles being 640 root:hg.
> OT: I had to restart the touchpanel notebook at the front
> since it had
> crashed, but it's up and running again.
> The doorway laptop is a weak link, problems with the touchscreen that
> cause the system to fail or look like its failed inevitably cause
> problems with the opengate/opengate-www script working. Instead of
> replacing this system though, add new system for testing in parallel
> until the kinks get ironed out. See below for details:
Yeah, there were requests if I could help with the replacement which I
> Please review the changes of the opengate-www script since I
> cannot tell
> whether there have been any bugs that got in the while porting
> general workflow of the script.
> Last but not least: Rubin suggested to port all the necessary
> stuff for
> opening the gate to a microcontroller which can be plugged
> onto the net
> directly. If anyone has a spare Adruino board or something
> which fulfills at least the following requirements, let me
> - RJ45 (LAN) connector for Ethernet connection
> - Microcontroller with at least 2 KB, but better 4 KB of RAM
> - Board being capable of running Etherape or simular based IP
> - IP-Pins to interconnect with the door circuits
> - Some Speakers or GPIO ports suitable to drive them
> Any additional door opening electronics can be tested and installed on
> the free hanging cat5 wire that's hanging out of the intercom box next
> to the front door:
> Orange-Stripe is connected to a 10v source, and Orange is connected to
> gnd through the buzzer/strike. Anything you want to test should work
> if the switch connects these two wires. I don't think you can power a
> device through the 10v source but it's worth checking out, other than
> just using a wall wart.
Will ask for details once there's some working prototype.
> The 3.5" Insignia Infocast from Best Buy is on sale at $50. From
> what I'm looking at, it's a Chumby one (arm based (maybe i.MX21
> freescale) 3.5 inch resistive touchscreen computer), and its
> 'hackable'. I'll get one for the door.
- Reworked the Web site script
- Modularized the code
- The script now barfs ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 482 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://www.noisebridge.net/pipermail/rack/attachments/20101206/1d0eca99/attachment-0001.pgp
More information about the Rack