• captainplanet (unregistered) in reply to criticman

    Our (NAPCO) system is that way too. The control boards can operate without a working serial link, but having the link & database up enable you to change the rules as well as operate doors from a workstation. Lets me sleep that much easier.

  • (cs) in reply to g

    The swipecard system ran on Win9x (and might have been designed for Win3.x). The filesystem was FAT. FAT filesystems get slow when a file gets large or even when there are a lot of small files and a directory gets large and fragmented. If the keycard app was written to append a line to the logfile and close it for each swipe, the OS would have to chase the chain of FAT entries to find the end of file each time. There are settings configurable in config.sys to tune the in-memory buffer size and the number of files open at once, but probably nobody did that. Add to this the growth-without-cleanup of the keycard database as cards get replaced and employees join and leave the company, throw in a dash of swapfile growth and fragmentation, and stir. You can easily end up with molasses.

  • (cs)

    I agree that the real wtf is that he was able to open up the door security cabinet. That being said.. it does seem that something happened that night led to the locking and unlocking. I have a feeling that the code didn't process the queue til empty, and only processed the next one. That way if you swiped a bunch, it would queue a bunch, but only process one. Depending on what was involved in the processing made the time variable. Something had to happen to make them start pulling the rest of the items from the queue. Maybe some dysfunctional logic that was supposed to filter out excessive swipes, but in reality just caused the situations described in this article.

  • Worf (unregistered) in reply to Strilanc
    Strilanc:
    This doesn't add up at all. No one noticed doors locking and unlocking all the time? If the delay was measured in days, or even hours, people would notice right away. If you ever were the first to open a door in a day, it would take hours for it to unlock.

    It makes more sense for the queue delay to have been 15-60 seconds, depending on the current demand for unlocking. Something more probably went wrong that night to cause the door to keep locking and unlocking.

    It's possible no one noticed. After all, the office is a noisy place and until it becomes deadly silent would people start to notice the clicks. Plus, if there's any significant number of people getting in and out, clicking would be expected all the time, and it gets tuned out.

    If the delay is say, 60 seconds, then the first person will swipe and wait a minute. But let's say you get impatient and swipe again - you just queued up a request again a minute later. Next guy comes in, swipes his card, and gets in with your swipe. If he's unlucky, he might swipe a few times while waiting for your second swipe to take effect. Add in multiple doors tied to the same system, and it's quite likely a number of swipes got queued up. (Remember, one of the tricks was to swipe it multiple times).

    I suppose eventually, the backlog got so bad that it took days for it to clear. In which case it would click continually throughout the day, with everyone's multiple swipes letting people in through the night and weekends.

    It just took someone to work late to actually notice...

  • (cs) in reply to Maybe Anon
    Maybe Anon:
    The queue file may not have been the same as the log file. It's likely incoming swipes would be added to a cue. Separate thread would do something like:

    Accept incoming swipe, Authenticate, Open Log, Read Log, Save to Log, Open Door.

    which would stop the door being opened until it was logged.

    Otherwise, the door would open and it may not be logged. If you could get the computer / app to crash quick enough, you could get in completely unlogged, so it's better to log it then open the door.

    Another smart design heard from. Try: Accept incoming swipe, Authenticate, Open Door, Open Log, Read Log, Save to Log.

    This would still be incredibly dumb, but at least the only casualty is the log; not some poor dumb bastard with a worthless piece of plastic freezing their ass off in the cryogenically-cooled server room waiting to get through the door to a really really important meeting with the assistant deputy sous-chef of HR.

    BTW You forgot "Close log:" that all-important step that both ensures that you don't run out of Windows handles, and also can't remember exactly what it was that you were doing this time last Tuesday.

    Still really worried about the log? Start another process, or open another thread.

  • NXavier (unregistered) in reply to DOA
    DOA:
    If you could let them use the system for a few generations eventually a whole religion would spring out of this. You would have to fast for an hour, say a prayer and depending on how good you were that day the door would open faster...

    Never assume it's safe to take a drink while reading TDWTF. I'm just lucky that the spew missed my keyboard.

  • RandomWTF (unregistered) in reply to NameNotFoundException
    NameNotFoundException:
    The Real WTF is that nobody has yet commented on the complete and utter stupidity of queuing card swipes. Doors are meant to be instantly accessible. That means, while a card swipe is being processed it makes absolutely no sense to queue up more. Somebody really screwed up this one.

    Not necessarily. At my previous job the door swipe records were also used to compare against our reported hours. They were also used to record who was coming and going.

    As such it was official policy that we must swipe our cards coming and going, even if there was already someone in front of us who had the door opened. "Tailgating", as it was called, was expressly forbidden.

    In that context it makes sense to process and record each and every swipe, even if the door may already be unlocked at the time of certain swipes.

  • Walleye (unregistered)

    This whole story doesn't seem very likely, unless it's in some strange office where all doors are opened regularly more than once a minute. If a particular door were opened only once or twice a day, then it would only unlock hours after the swipe. There must be at least one door that is used infrequently, and there would be no way to get through it.

  • I walked the dinosaur (unregistered) in reply to NXavier

    Do people really actually spew drink contents when reading a funny post, or is it one of those things like ROFLMAO? If you do not in fact actually spew your drink, I recommend using some acronym. IJSMFD?

    Also, the Irish girl is like RIGHT NEXT to this textarea...

  • (cs)

    Is that the same software that will be used to tally the US elections in November?

  • NameNotFoundException (unregistered)

    Finally, at last! Science fiction becomes reality! Maybe they should call it the "self-indulgent door".

  • Ozy (unregistered) in reply to Carl

    N o, over the weekend, the backlog of swipes would get processed, and the first person in on Monday would swipe, wait for his OWN processing time, and then enter. As the day would progress, the queue would get filled again, and each night a portion would get purged.

  • JohnFx (unregistered)

    "He traced a line from the card reader to the reception area just on the other side of the door, and upon further investigation discovered that it ran into a floor-level cabinet which was obscured by a trashcan and some stacks of paper and folders."

    I re-read this a few times looking for a REAL-REAL-WTF, that is, tracing the cord to the reception area outside of the locked door.

  • Anonymous Koward (unregistered)

    This is a very nice WTF. Element of mystery, the forgotten doorkeeper, and a technical (rather than personality) issue.

    CAPTCHA wisi "Who tha F**K are you calling a WISI!"

  • speaking of security... (unregistered)

    fantastic location. open wiring, unlocked cabinet, in the open, obvious function. yep, that'll keep Osama Yo'Momma out, all right ;)

  • Franz Kafka (unregistered) in reply to Chez
    Chez:
    Great story, I thoroughly enjoyed this one :)

    For those confused about the delays, create a text file filled with 300Mb of random text, then open it in notepad. Type one character and hit save. Now multiply those delays by an outdated OS, poorly written code, and ancient hardware. Then you'll understand the long delays.

    Now open it in append mode and see what happens. By the way, notepad can't deal with 300M files.

  • Franz Kafka (unregistered) in reply to real_aardvark
    real_aardvark:
    Maybe Anon:
    The queue file may not have been the same as the log file. It's likely incoming swipes would be added to a cue. Separate thread would do something like:

    Accept incoming swipe, Authenticate, Open Log, Read Log, Save to Log, Open Door.

    which would stop the door being opened until it was logged.

    Otherwise, the door would open and it may not be logged. If you could get the computer / app to crash quick enough, you could get in completely unlogged, so it's better to log it then open the door.

    Another smart design heard from. Try: Accept incoming swipe, Authenticate, Open Door, Open Log, Read Log, Save to Log.

    This would still be incredibly dumb, but at least the only casualty is the log;

    Great - unlogged access.

    Still really worried about the log? Start another process, or open another thread.
    Oh, now the whole file can be corrupted - have you thought this through?
  • Nate (unregistered) in reply to Chez
    Chez:
    Great story, I thoroughly enjoyed this one :)

    For those confused about the delays, create a text file filled with 300Mb of random text, then open it in notepad. Type one character and hit save. Now multiply those delays by an outdated OS, poorly written code, and ancient hardware. Then you'll understand the long delays.

    So I'm going to wager that it was storing the entire log in memory as text, and serializing/writing to disk each time it unlocked the door?

    Or perhaps reading the log file that was being spat out, then re-parsing the text to find out when to unlock again?

  • Jay (unregistered) in reply to NameNotFoundException

    Just speculating, but I'm guessing they wrote swipes to a log file, not with the goal of queueing door-open requests, but rather in order to record every time someone went through the door. So if, say, valuable equipment disappears, someone can look at the log and say, "Hey, the only one in the building at that time was Bob!" Probably the delay in processing was an unintended side-effect. I'm sure when they were testing this, nobody thought to swipe a card a few thousand times to see what happened. The classic IWOMM ("It works on my machine") phenomenon.

  • Right Behind You (unregistered)

    Aah OK, so the moment the hard drive thrashes to death (and it WILL at this rate) the doors stop opening? Wonderful.

  • (cs)

    I replace crap like this on a regular basis (example code in Delphi):

    theLog := TStringList.Create; theLog.LoadFromFile(LogFileName); theLog.Add(NewLogEntry); theLog.SaveToFile(LogFileName); theLog.Free;

    (simplified for lack of a pre or code tag...)

    As far as the original story goes, I'm not so lucky. I'm sure if I had done that, the app would have crashed with a "can't find accesslog.txt" error, the machine would lock up, fail to reboot, and lock me in until maintenance could take the door off the hinges... on Monday. :-/

  • (cs) in reply to Erik
    Erik:
    Yeah. I really expected to find out that a receptionist was notified at every swipe and manually logged the ID and pressed a button to unlock the door, and had set up some timed method for pressing the button after hours.
    That's exactly what I thought! Explains the delay. Explains the oddly-random intervals.
  • Jay (unregistered)

    Years ago I worked at a military base where we had swipe cards to get into sensitive areas of the building. It so happened that the restrooms were in a hallway where the doors on each end opened on to such sensitive areas, so you needed a swipe card to get out of the restroom. Okay fine, no big deal, we all had swipe cards.

    Then one day the base commander decided that most employees shouldn't be able to get into sensitive areas after hours. So, without actually bothering to, say, tell anyone, he had the system changed so that most employees' swipe cards didn't work before 5:30 pm and 7:30 am. I'm sure you can see where this is going: Some poor woman worked a little late, then went to the lady's room just before going home the day the change was made ... and couldn't get out. Fortunately I heard her banging on the door and let her out. We played with the system a little and found that neither of our cards worked anywhere. The next day we called security to report that something was wrong with the system and then they told us about the new policy.

    I don't mind being told that I'm not allowed to work late for no extra money, but personally, I prefer not to be locked in a restroom all night.

  • (cs) in reply to Zylon
    Zylon:
    Then the solution is to institute a scheduled archiving of the log file. E.G.-- make what he did into official policy.

    What are you, simple or something?

    That made me laugh... a lot.

    /Thinking of just the right situation to use this on co-workers...

  • Mr G (unregistered)

    Would be pertty funny if the log files were used for something.

    "So Jenkins, you didn't actually start work this week until sometime late Tuesday morning, so we're docking you a days pay...but you will be getting time-and-a-half for your work on Saturday, and double time for Sunday. Well done."

  • (cs) in reply to Jay
    Jay:
    I don't mind being told that I'm not allowed to work late for no extra money, but personally, I prefer not to be locked in a restroom all night.

    I had something similar happen. Where I work, I go in and out through a back entrance to the building. You open the outside door, which is generally not locked, and that brings you to an alcove where you swipe your card to get into the building.

    Now, they restrict entry/exit after 7:00pm, at which point the swipe readers no longer unlock the inner door, and the outer doors are locked for the night.

    So one day I work late, head toward the exit, walk out the inner door, try to open the outer door, see that it's locked, remember that it's past 7:00pm, and turn around just in time to... click See the inner door lock. Now I'm trapped between the two doors. The inner door is not accepting swipes to get in, and the outer door is locked -- from the inside, yes, but alarmed. I sat and deliberated for a few minutes, tried to think of who I could call, looked for intercoms or cameras, and finding none I went for it -- I unlocked the door, opened it -- which set off the building alarm -- and ran for it.

    I talked to the security guard the next day, and he waved it off -- apparently this happens all the time.

  • sweavo (unregistered) in reply to NameNotFoundException
    NameNotFoundException:
    The Real WTF is that nobody has yet commented on the complete and utter stupidity of queuing card swipes. Doors are meant to be instantly accessible. That means, while a card swipe is being processed it makes absolutely no sense to queue up more. Somebody really screwed up this one.

    Yeah. It shouldn't be queued up, if a second swipe comes in while the computer's busy it should email off and order a second card swipe computer to handle the second swipe. Duh.

  • (cs) in reply to WhiskeyJack
    WhiskeyJack:
    I sat and deliberated for a few minutes, tried to think of who I could call, looked for intercoms or cameras, and finding none I went for it -- I unlocked the door, opened it -- which set off the building alarm -- and ran for it.

    wish we had a video tape of this :) You would look like a robber running away.

  • I Know Who You Are (unregistered) in reply to OzPeter
    OzPeter:
    For changing a critical piece of security infrastructure with out any authorization or approval? I don't see him as a hero but as more of a vigilante.

    A hero would have done an investigation without changing anything and then made a clear and precise report the next day as to what was causing the heartache. At which point a considered response could be made which took the overall situation into account. After all he was new there, so there is no way that he would have been able to take the entire companies position into consideration.

    In fact he did not actually change anything, all he did was fix a symptom. I would guess that as the current log file filled up the system would start to behave in the same way again. So all he achieved was to give himself a virtual wank and a smug look when his coworkers next discussed the improved performance.

    BLAH BLAH BLAH TROLL TROLL TROLL

  • Vox (unregistered) in reply to I walked the dinosaur

    [quote user=" Also, the Irish girl is like RIGHT NEXT to this textarea...[/quote]

    Well, she won't be with us much longer.... <sniff>

  • Anonymous (unregistered) in reply to Jeroen
    Jeroen:
    DOA:
    I must be missing something. If the system was still processing swipes from yesterday, how come people were still able to use the doors. Wouldn't they have to wait a day for their swipe to open the door?
    No I think people just swiped their card and then the door would open because of a swipe made hours/days earlier. That's why the time it took seemed random.

    But wouldn't that be awfull co"incedentical? I mean, it could be if the computer was slacking exactly 24 hours behind, but else... My guess is that the logic is about this: Lock signals key => info to computer => computer checks access rights then:

    1. Access is queued for logging
    2. Signal to lock to release

    That would explain the not that long delays, but not the randomness. (maybe a longer wait if more people used the locks?)

  • He Who Is Looking For Trouble (unregistered)

    WTF. didn't anyone notice that it's clicking all the time during the day?

  • (cs) in reply to Anonymous
    Anonymous:
    I wonder how people reacted when they were *about* to swipe their card, and the door unlocked in front of them...

    They felt like "The Fonz".

  • Max (unregistered)

    Good story, i too enjoyed this story very much.

  • (cs) in reply to OzPeter
    OzPeter:
    For changing a critical piece of security infrastructure with out any authorization or approval? I don't see him as a hero but as more of a vigilante.

    A hero would have done an investigation without changing anything and then made a clear and precise report the next day as to what was causing the heartache. At which point a considered response could be made which took the overall situation into account. After all he was new there, so there is no way that he would have been able to take the entire companies position into consideration.

    In fact he did not actually change anything, all he did was fix a symptom. I would guess that as the current log file filled up the system would start to behave in the same way again. So all he achieved was to give himself a virtual wank and a smug look when his coworkers next discussed the improved performance.

    well... i'm glad i dont work with you

  • StupidPeopleTrick (unregistered)

    this could go either way. Either he is a hero for fixing this. Or someone will put together the file creation date with his 'test' swipe and fire him for messing with a 'secure' system. Either way, access to the box is a problem. Ask yourself how long that machine will be working and ask yourself if you want to be the rat in a cage when it stops working....

  • (cs) in reply to Rob

    this site will give you all the links to surveys. that will pay you money just for a filling out a quick form! these surveys pay you any where from $10-$50 for only like 10min. its so awesome i can make some money on the side for doing almost nothing. well check it out!!!!

    http://adamin.paidetc.hop.clickbank.net/

  • ab (unregistered) in reply to Chez
    Chez:
    Great story, I thoroughly enjoyed this one :)

    For those confused about the delays, create a text file filled with 300Mb of random text, then open it in notepad. Type one character and hit save. Now multiply those delays by an outdated OS, poorly written code, and ancient hardware. Then you'll understand the long delays.

    Just that notepad doesn't open it on append mode. Time echo Foo >> SeveralMB.txt

  • (cs) in reply to Rank Amateur
    Rank Amateur:
    Cleaning was contracted out. The cleaners reported it to their boss. The boss could care less, and said, "Don't worry about it."

    The other other real WTF is that Full Sail has an airplane rather than a sailboat in its logo.

    --RA

    No, the boss could not care less. Otherwise he might've done something. (You know, not caring is caring less than caring lots...)

    The other other other real WTF is that I saw a guy in a Full Sail shirt the other day, in Prague. But the logo was a yacht... (not the American kind, the English-speaking world kind). Guess it wasn't the same Full Sail?

  • (cs) in reply to BradC
    BradC:
    Erik:
    Yeah. I really expected to find out that a receptionist was notified at every swipe and manually logged the ID and pressed a button to unlock the door, and had set up some timed method for pressing the button after hours.
    That's exactly what I thought! Explains the delay. Explains the oddly-random intervals.
    Perhaps you'd care to use the same, oddly persuasive, logic to explain the grassy knoll, that weird flutter on the Stars'n'Stripes on the 'moon', and the well-known fact that everybody in Buck House is, in fact, a twelve-foot baby-eating lizard?

    Reading everybody else's perfectly reasonable explanations might make your eyes bleed. That would be dangerous.

  • (cs) in reply to Franz Kafka
    Franz Kafka:
    Chez:
    Great story, I thoroughly enjoyed this one :)

    For those confused about the delays, create a text file filled with 300Mb of random text, then open it in notepad. Type one character and hit save. Now multiply those delays by an outdated OS, poorly written code, and ancient hardware. Then you'll understand the long delays.

    Now open it in append mode and see what happens. By the way, notepad can't deal with 300M files.

    May I recommend Notepad2?

    Oh ... wait ...

  • (cs) in reply to Franz Kafka
    Franz Kafka:
    real_aardvark:
    Still really worried about the log? Start another process, or open another thread.
    Oh, now the whole file can be corrupted - have you thought this through?
    Issue #1 is that neither you nor I understand the requirements. Let's agree to take a reasonable stab at them. Issue #2 is that you really, really, don't want to impose a random access and/or random lockout policy on employees. Gosh darn that corrupted file. Corrupted how, BTW? Missing entries are not corruption. Missing entries are missing entries. Issue #3 is the entire concept of multi-threading/multi-processing. Add reliable socket connection (or other preferred reliable protocol) between the two; store pitiful little text record at the other end (in a temporary file, if desired) before acking; stir and bake.

    I estimate the total amortised cost of this two-threaded solution to be roughly 20ms per swipe on a Commodore PC. But what the hell do I know? I just work with every single fucking credit card transaction in the entire world. Being a glorified doorman is not my bag, mate.

  • DHager (unregistered) in reply to Strilanc
    Strilanc:
    If the delay was measured in days, or even hours, people would notice right away. If you ever were the first to open a door in a day, it would take hours for it to unlock.
    OriginalPseudonym:
    Eh, I call shenanigans. If it really was still queuing swipes from the day before, what do people do on Monday?

    I hope neither of you guys are writing multithreaded programs for consumer use. :P

    People are getting through the doors on swipes made by other people earlier in the day. They can't tell: It just unlocks.

    The first person of the day would get the door unlocked relatively quickly from THEIR swipe. As the backlog builds up (from excess swipes, impatience, overall load on the system on multiple doors), people would start getting through the door on other people's previous swipes, and their swipes would in turn affect other people in the future.

  • DHager (unregistered) in reply to DHager

    P.S.: A better clarification.

    The logfile is big. But (and this is the important part) it's so big that it's practically a constant delay, on the scale of a day. Each additional swipe barely changes it's relative size.

    total_delay = log_size_delay * queued_items

    So suppose it's a constant 5 seconds per authentication to load and save the file. It does this once per each swipe and unlock.

    Assume ten items in a queue, and we start working.

    It takes 5s for the first item to clear, 10s for the second, 15s for the third, etc.

    On Monday, with no backlog, the door'll be back to 5s delay for the first guy at the first door. By the end of Friday it might be a 1 hour delay, but due to the fact that the door just opens for anyone standing there (regardless of what card they hold) nobody notices.

    By clearing the logfile, the base delay per swipe could go down to .001 second, in which case it's too small compared to traffic for the backlog to ever build up.

  • (cs) in reply to Rob

    [quote][qupte]Jeremy took a deep breath and renamed accesslog.txt to accesslog2.txt. Immediately, a startling clatter of doors locking shut echoed throughout the floor. Justin bit his lip and walked over to the nearest card reader.[/quote]So within the time of writing one sentence he changed his name? ;)[/quote]

    I thought it was a metaphor for the changing filename of the log file.

    Ok, not really.

  • (cs) in reply to savar
    savar:

    well... i'm glad i dont work with you

    Want to back that up with a reason? Or are we just sticking with ad hominen attacks?

    It seems that you have never heard of risk analysis or worked in an industry where your actions have consequences that cannot be undone if you screw up.

    Jeremy dicked with a system that he had no knowledge of, thus any action he took had an unknown risk of failure and an unknown risk of side effects with other systems. A professional would have applied due diligence and assessed the consequences of his actions rather than making the assumption that just being l33t was enough to get by - and then not even be man enough to admit that he had dicked with the system.

  • (cs) in reply to I Know Who You Are
    I Know Who You Are:
    BLAH BLAH BLAH TROLL TROLL TROLL

    Will the real troll please stand up

  • (cs) in reply to Harry

    But does it run on Linux?

  • Burglar (unregistered) in reply to Carl
    Carl:
    If the delay was only about 1.5 days, then what happened on the weekends? If no one swiped their card on Saturday or Sunday, then the door would not open when swiped on Monday morning until mid-day Tuesday, right?
    The company probably would shutdown the system on non-working days for power savings, so the log accumulated is not cleaned up.
  • Rob (unregistered) in reply to Jeroen
    Jeroen:
    DOA:
    I must be missing something. If the system was still processing swipes from yesterday, how come people were still able to use the doors. Wouldn't they have to wait a day for their swipe to open the door?
    No I think people just swiped their card and then the door would open because of a swipe made hours/days earlier. That's why the time it took seemed random.

    Yeah, but how many doors does this place have? How likely is it that someone has tried to swipe the door you are swiping - x hours ago? I can easily picture someone waiting half an hour for door to open!

Leave a comment on “The Haunted Door”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article