Problem: Opal Top-Up Pending Collection – RIP, my Opal Card

It’s probably self-evident by now, as a regular user of public transport (and an observant one at that), that I’ve been looking forward to receiving and getting onto the Opal system. While concession holders, including tertiary students, were left to last in the phased roll-out, UNSW was fortunate to be one of the first to introduce the concession Opal to its students amid privacy fears.

20150311_094725Of course, it was all a storm in a teacup – we really had little to no choice. Most of us had to share our data sooner or later, as paper concession tickets were now on a timeline towards death – possibly as soon as the end of the year. Part of that includes the disappearance of these “pre-boarding” validators for the UNSW bus queue. These rechargeable, battery operated units on hand-trolleys utilized the same Datafare 2000 console and two AES Prodata ticket readers for magnetic stripe tickets. These stamped the route number as U11, and were originally introduced in pairs (four readers) to speed up boarding of the large number of passengers to and from UNSW during peak periods.

20150417_115401With the new Opal card, pre-validation was no longer possible or required, as the processing time per user drops dramatically with the NFC card based system. Instead, we now use front and rear door boarding, for an equivalent of four readers per bus (when all operating) and approximately double to triple throughput at an estimate.

Just a few weeks ago, I was very pleased with myself when I finally used up the last ride on my last myBus2 Travelten Concession ticket. Good riddance to paper tickets, to waste, and to slow boarding.


The Honeymoon Period

I did use the card for as many transactions as I could, as avoiding a ticket queue, waiting for a pinpad to process the transaction or fumbling for change is something I’d rather not do if I could avoid it. I did have some paper tickets remaining, so I tried to use them up as soon as possible.


I even topped up with $20 via the online system just so I could keep using it. No dramas, at least, on the first time. Easy enough to use, I didn’t have to think about it anymore. But I didn’t trust it enough to do auto top-up just yet. I mean, why should I expose myself to any more potential risk – manual pre-paid top-up works fine for me on my mobile phones, so I’ll keep it that way on my card.

I enjoyed receiving the benefits – for example, now I get concession discount off off-peak train fares, unlike before. The 60-minute transfer window also makes bus-journey-breakage to visit a computer shop and go home, or the post office, much more economical – sometimes resulting in fares below half the price I used to pay when doing two separate single tickets.

As my usage on Opal became heavier, my balance started to approach the point of nervousness – did I have enough to last me another day? So, as a responsible user, I decided to give the top-up another whirl on Saturday, this time opting for the maximum AU$60 top-up, to prepare the card for another week of travelling.


The top-up was committed to their web interface on the 18th April, and checking my bank’s statement, the cash was successfully taken on the 20th April.


Of course, the online system showed a $60 top-up pending collection, which should mean that it would be applied to the card at the next tap-on at a reader. Jolly good. My next travel appointment was on Tuesday, so I’ll be all set!

Or so I thought …

The Honeymoon is Over

On Tuesday (several days after the online-top-up), when I began my journey, tapping on did not actually show “Top Up” and the new balance, as it did the last time when I did an online top-up. Instead, I had my old balance and the regular “ding” green-screen indicating successful tap-on.

I whipped out my phone … and checked the balance. Top-Up still pending. Hmm. I travelled the day, watching my balance continue its downward spiral towards zero. My only thoughts were … please don’t die on me Opal! I need you to travel!

Screenshot_2015-04-21-11-45-43 Screenshot_2015-04-21-16-50-28

The next time you present your card at a reader? But I have! Numerous times! And your system knows it too – just see the balance …

Waiting wasn’t doing the card any favours, so I decided to bite the bullet and seek help.

Opal Customer Care

There are two main ways to receive support for your Opal card, and none of them involve Sydney Trains staff – after all, Opal is run by an external party. The two methods are via the internet (i.e. by using their support form from the logged-in section on or by phoning the 13 OPAL (13 67 25) phone number, at the cost of a local call (or more if on mobile, and depending on your carrier).

When I reached the university on Tuesday, I sent them a message by the website. Sadly, I heard nothing from them even into the evening when I finally got home. Since 13 OPAL is staffed 24/7, I decided to call them up and see what they had to say.

I generally don’t prefer calling a company purely because I have to sit on the line and listen, or wait on hold, or key in many digits and navigate phone-trees. Opal is no different in this regard, but since I have my VoIP capture system set-up (unfortunately, not immune to packet loss), you can “listen in” on the journey to get to an operator:

  • The Call is Answered – Greeting Message
  • “Thank you for calling Opal Customer Care. To activate your Opal card, press 1. To learn more about the Gold Senior Pensioner Opal Card, or to apply, please press 2. To learn more about the Concession Opal Card, or to apply, press 3. For all other enquiries, press 5.”
    • Note: There is no option 4! I press 5.
  • Opal Card Number Query
  • “If you have your Opal card number, press 1. If you do not have an Opal card number, press 2.”
    • I press 1.
  • Enter Opal Card Number
  • “Please enter your Opal card number – it’s the 16 digit number located on the back of your card.”
    • I enter all 16 digits … making sure not to get it wrong.
  • Confirm the Opal Card Number
  • “Let me confirm the Opal card number you entered. {Zero, Two, Three, Five, Six, Eight}. If that’s correct, press 1. If not, press 2.”
    • Note: I have modified the Opal card number readback for one sample of each unique digit in my Opal card. Missing are samples for 1, 4, 7, 9. I press 1.
  • Enter PIN
  • “Please enter your PIN. It’s the four digit number you provided when you registered your Opal card.”
    • I got a bit stumped, entered in the wrong pin …
  • Wrong PIN
  • “Sorry. That PIN doesn’t match my records. [Pause] Let’s try again.”
    • It redirects to the Enter PIN phrase, and this time I get it right.
  • Main Menu
  • “Main menu. To hear your balance, press 1. To add value to your card, press 2. To hear recent transactions, press 3. To set up auto-top-up, press 4. For more information about Opal, press 5. At any time, you can use the following keys to navigate through the options. Press * to repeat the menu. Press 7 to return to the previous menu. Press 9 to return to the main menu. Press 0 to transfer to a customer service representative.”
    • At long last, we finally get a way to transfer out to a representative. I press 0.
  • Transfer Message
  • “Thank you for calling Opal Customer Care. You are now being transferred to a customer service representative for assistance.”
    • You don’t have to do anything here, but the first time I called, this message failed to play resulting in an awkward silence before something finally happened.
  • Opal Customer Care Queue and Answers
  • [Ring] Thank you for calling Opal Customer Care. Your call is important to us and will be answered by the first available customer service represent … [Call gets answered, name censored out].”

Guess what the first thing they asked me for after describing my problem? Yes, that’s right. They wanted my Opal card number … again. Then they verified all my personal details before proceeding.

I must say, the procedure to get to the representative is relatively longwinded and took several minutes. However, I never had to wait on hold for an appreciable amount of time, and the call was answered by a courteous representative who was understanding and clear with their instructions. The call was relatively brief and answered my questions.

Sadly, it was only after the call to them that they finally responded in writing to the same effect as what was said over the phone. Then they closed the ticket immediately. It seems their online support system is lacking severely as you can’t review your submitted messages or respond to tickets online via the logged-in area of


Lets try some Self-Help

As per the instructions provided above, the first method of self-help is to tap on at a train station, and then tap off after a short delay to force a fee-free tap-on reversal that will update the card status.

I tried this twice, once at Auburn when I managed to trigger the immediate-tap-off protection on the barrier thus resulting in a “Please wait to tap off” message. After waiting a minute, I was allowed out, and then tapped back on to try and continue my journey. No dice, the balance is not updated.

I tried again at Central, this time, waiting an appropriate time to avoid triggering the error message. Still no dice.


Scanned DocumentMy last resort was to do a “small” in person top-up at a bricks and mortar retailer. I was informed that this would consolidate the pending top-up with the top up applied in person and write it onto the card immediately.

I walked around Central station and found a top-up machine next to a few signs advertising its availability.


Earlier last month, I spotted crews installing the machines but I didn’t really have a reason to post the image until now. Anyway, a lady was fumbling with the machine and couldn’t work out what to do with it.


As a result, I visited a shop just next to the station. My balance was dire – just $1.59 at the time. The $20 I paid in cash was added to the card, but that was all. My $60 didn’t turn up and remained pending online. Upon further examination of the receipt, it seems there is some anomalies – notably the Transaction Number showed just 36 – according to the online log, the top-up took place around transaction 102. The card number was also identified but missing the last digit (seems likely the last digit may be a useless check-digit or this may be an ePay terminal special).

At least I could continue travelling, but my $60 is missing … in the ether.

Nope. That Didn’t Work!

I sent them a new online message, a little earlier than before, on Thursday thinking that might give them a chance to answer the query and I wouldn’t have to call in. Sadly, I was wrong, and no answer was forthcoming even into the late evening. I decided to call them, and owing to downtime with my main VSP, I had to go to a backup VSP to complete my call.

Sadly, there wasn’t any way out of this short of blocking the old card as a defective card (i.e. what they do when it’s reported lost/stolen) and reissuing a new card by post which requires activation, with the consolidated balance on the new card. As a result, I will be out of an Opal card for a few days, even with their promise to dispatch it by express. After finalizing the call, the e-mail started coming in …



It was only this morning (Friday) that they finally answered my online query – noting that I had called them up. In short, if you need something fixed, call them up. Their online support is just poor by comparison, despite their insistence that the queries will be faster “because they have all your information”.


As a result, my Opal card is now useless to me, and not valid for any form of transport. [Insert Sad Face]


RIP, my first concession Opal card. 3085 xxxx xxxx 3052, a Mifare DESFire EV1 with UID 0449xxxxxx2c80 you will be missed.

Some Observations of the Opal System

By looking at how the system operates, as an active user of the system, I can make some educated guesses as to how the system is implemented and how it “works”. In short, it is quite a complex system in order to meet everyone’s needs.


The Opal system seems to consist of a few different sorts of readers – the “standalone” sorts that sit on Opal poles at smaller stations, the “barrier integrated” type at larger stations, the “bus” readers which are configured to work with a drivers’ console, and possibly even others that I haven’t encountered due to a lack of “ferry” usage.

The readers themselves are fairly complex pieces of equipment – of course, they have NFC and a colour LCD, but they also seem to have more intelligence in them. I suspect the bus units have a full knowledge of stops, and distances between stops, and rely on the drivers’ console to inform the units of the run number, stop location (GPS or manually selected) to enable a tap-on or tap off. The train readers probably have similar data for the train network distances as well. Each of the readers also has to have knowledge of the time, likely via NTP over network as they all seem to have an IP connection of sorts (as evidenced by the image of the booting reader above). I suspect bus readers, being mobile, rely on some form of 3G/4G connectivity which explains the delays experienced with updating Opal journey data and top-up data.

The readers also have to take on additional duties – aside from just reading cards, deducting fares, writing back to card, the Opal system seems to be a “hybrid” system where the value is stored both on the card and on their servers.

The primary source of data is generally the card, which stores the remaining value on the card, the tap-on data (i.e. location, time), as well as details of the last trip (when last tapped off, what mode, distance at the least) so as to work out whether it’s a transfer or not. As I guess the readers may be NTP synchronized, the time stamp drift between readers may be in the order of tens of seconds – this might result in the time recorded on an Opal card to be more granular (say, minutewise), resulting in the “Please wait to tap off” message on attempting an immediate tap-off cancel. This type of operation allows the card to continue working and to hold balance even in a temporary outage of the back-end or in case of connectivity issues, which is its advantage.

However, the readers must also log all their changes in a journal and upload this periodically back to the back-end so that the online journey log and balance can be updated. This is done relatively frequently (in a matter of minutes) in most cases, so both online and card are kept in sync. In the case of bugs or system failures, then it is possible that things will fall out of sync, and permanently so if data is lost.

The readers must also accept a differences log to apply to new cards they see. All new cards are issued unactivated with no balance written onto the card, and must be presented to a reader within 30/60 days to “collect” the top-up. What this means is that upon receiving your card and activating your card online, Opal must send out a record to all the readers that if it spots your new card tapping on, it needs to apply a credit of the amount you paid when signing up for the card. This allows the credit to remain safe even if the cards are lost in transit.

The differences log also extends to online top-ups, and likely for auto-top-ups as well. This is also probably what allows for the blocked card feature to protect the balances.

As with all databases, the end units will have a limitation as to the number of difference records they can handle purely because of space limitations in storage and processing time limitations when tapping on to “scan” the database for your card’s UID and apply any needed changes, and write it back, all in under one second.

I believe the overflowing of this differences log is the cause of initial top-up delays, which the representative informed me were indeed occurring to varying degrees. This also explains the reasoning behind the phased introduction of the Opal system – otherwise this differences log would be overflowed to the point of system collapse as new cards fail to come online or top up fails to be applied.

By now, you’re probably wondering why they didn’t opt for an “online” transaction system. In fact, it could be possible to have an online system if the barriers were at fixed stations, connected by fibre, backed-up with a very powerful cluster of database servers, as they can process a transaction in 100ms or less, which would be imperceptible. However, to ensure the safety of the data, adding crypto to this may increase the system load and latency slightly. But such an online system becomes vulnerable to loss of connectivity and is not suitable for 3G “mobile” stations due to round trip latency, or retrofitted Opal poles where the only thing available may only be power.

Because the card seems to be the primary source of the data, authorized payment terminals can make alterations to the card data to inject balance onto the card for immediate use – even if it didn’t show up on the back-end’s logs. This appears to be by design, to avoid any requirements on retailers to have a constant internet connection, and to avoid total system collapse if the online-pending-updates continues to cause trouble. I suspect if the top-up data isn’t eventually synchronized, auditing the system for “money leaks” might become difficult.

However, something seems to have gone fishy with my card. The card itself is an NXP MiFare DESFire EV1, which is known to be a secure cryptographic NFC card with special features intended for fare collection systems including methods of ensuring data integrity even in varying field conditions (i.e. card removed before write complete). Unless the card isn’t being used with the right data types and programming order, corruption of the card is extremely unlikely but possible.

The first clue to something fishy about the card comes from the manual top-up where the transaction number doesn’t seem to match. I haven’t done a manual top-up before, so I don’t know if this is by design, but a mismatched number alludes to my other hypothesis about why the card failed. The number 36 would correlate to travel on 18th March, a month ago.

I have a suspicion that the card readers are updated with a differences log for top-ups that includes not only the adjustment required to the card, but also the transaction number it should be taking place at. This allows for the transaction to be done unambiguously in a sequenced manner. However, when I tapped on after my top-up, it may have been during a delay in data or the reader itself was operating off stale data resulting in the expected state of the card (transaction number wise) being different to that of the differences log after my first bus ride.

From then on, all the readers may have refused to apply the adjustment noting that the card status, transaction number wise, is above the expected number where the top up should be applied, in order to avoid double-top-up of the card in case the successful top-up from the previous reader is not yet sent back to the database for clearance from all readers.

As a result, the top-up is “caught in limbo” – readers won’t apply it because the card doesn’t contain the status they expect it to, and the online database system doesn’t seem to update the difference log to “inform” readers to try it again.

Of course, I wasn’t involved in developing the Opal system, and I don’t have any connections to the insides, so I can only surmise its operation based on its observed behaviour. However, it’s hardly encouraging to note that my second top up resulted in the death of a card.

A second possibility is that the card indeed faulted during a write operation and corrupted some non-critical data (transaction count?) which was then “built upon” by following readers. The possible clue to this is when ticket barriers tell you to “Try again with only one card”, or tell you “Invalid”, or error 90, 91, 92, but a retry succeeds. I suspect the cause of this may be due to timing problems, but I’ve always pulled my card out for use with the reader and placed it as close as possible to the target, as I know that an “on air collision”, while designed against in the IEC standard, is a possibility, as is a momentary loss of field in the case of “waving” or “tapping” a card against a reader (as some misinformed passengers seem to do, to bemused faces when it doesn’t work). I don’t expect this to be a major issue though, as the cards were designed against these problems if used according to NXP’s recommendations, and the worst that should happen is that a write fails and the card maintains the previous state.


The Opal card system, having all card types now available, with further sign-ups expected for Concessions through the end of the year, seems to have been a successful rollout in the eyes of the media. That doesn’t, however, mean that it is bug free – which is not necessarily a surprise but comes rather as an annoyance.

If you end up getting “trapped” with an online top-up that you can’t collect, the only solution (as I have been informed) is to have the card replaced which leaves you several days out of a card with no compensation whatsoever. This is hardly the convenience we “signed up” for, and really shouldn’t be happening. Apparently, according to the representative I spoke with, it doesn’t happen “often”.

The procedure is basically the same as blocking a lost card, and transferring the balance to a new card. I think this may have been misdiagnosed as a defective card, as it’s probably the easiest way out of such a problem, but technologically speaking, the data on the card can be repaired.

It seems likely that an inconsistency occurred somewhere along the lines resulting in a failure of the top-up difference data to apply to the card, possibly due to the card being used with a reader with outdated difference data, or having a “sheared” write (which can be avoided with proper use of data-types and write procedures on the MiFare card system) resulting in a corrupted transaction counter on the card. The fact the card can continue to be written and read to, with manual top-up, suggests to me that any failed write did not damage the permissions of the MiFare blocks, which would otherwise reject a read/write request causing the card to be permanently bricked.

The fact that the data is actually synchronized with a back-end database implies to me that it would not be impossible to repair a card based on an agreed synchronized data (if the permissions are not broken), possibly by implementing a new “differences log” mode on the readers to overwrite the card data completely with synthesized data from the online database at the next tap on based on a manual request. However, they might be hesitant to do that for several reasons – as it seems the readers may have too many difference log data to deal with, and it creates another potential avenue for disputes or tampering if the synchronization occurs incorrectly. That being said, allowing retailers to physically top-up cards does cause some security risks as well, but they seem to have no problem with it.

Regardless, I’m out of an Opal card for at least a weekend, so that means no travelling unless I want to revert back to paper and forego any Opal discounts to which I am entitled to. Thanks Opal. If you have trouble with your Opal card, do make sure to call them on 13 OPAL, as their online turn-around times are not particularly great.

Posted in Computing, Travel | Tagged , , , , , | 2 Comments

Lycamobile Data: A Routing Issue or Malicious Blocking?

It hasn’t quite been a year since I joined the Lycamobile family in the quest for cheap data over the superior Telstra network. While initially their “slowness” took on an almost legendary status, they took some strides to improve their data termination which resulted in much more competitive service.

Sadly, it seems that Lycamobile are indeed up to something fishy. Since the Sydney storms, I found that on Tuesday, I was having some issues using the data service at all in the morning (failure to actually start a session) which wasn’t unusual from time to time. As a result, I had to rely on a backup Virgin (Optus) tether from my other phone. By the time the service came back to life in the afternoon, it was unusually slow and had problems loading pages or even holding up a single radio stream.

Fast forward to today, Thursday, and the service isn’t quite the same.

Investigating the Issue

This is probably a little embarrassing, but I do listen to the (relatively uncultured) KIIS 106.5 radio station, currently the top ranking breakfast slot FM station in Sydney. Firing up the trusty TuneIn Radio app on my phone, instead of being greeted by some nice music, it loaded the playlist, then proceeded to sit there attempting to connect before finally going to this error:


Okay, so I thought they might not like me using TuneIn to “tune in” – so I went to the Google Play store to go and try grabbing the iHeartRadio app. Strange, it seems I can’t download any app from the store … it sits there downloading forever.

I could still browse the internet, albeit slowly, so the connectivity was there. I tried a different station – their rivals, and last in the breakfast slot in Sydney, hit104.1. It works …


By now, you might have concluded that there is probably an issue with KIIS 106.5’s streaming servers, and the Google Play store issue might be unrelated.

But hold your horses – I tethered to my Virgin (Optus) backup phone, and KIIS 106.5 and Google Play worked just fine there. I got my iHeartRadio app and still, no audio from Lycamobile, but working just fine from Virgin.

I took it one step further – I used Connectbot to SSH to home and open up a SOCKS proxy on the phone. Then I used Proxydroid to force tunnel TuneIn Radio over the SOCKS proxy. Bingo. Radio streaming just fine … via my home ADSL2+ … through Lycamobile to my end device. Note the wealth of icons thanks to the background apps keeping my radio going.


So it seems something is broken with Lycamobile’s connectivity, or somehow, KIIS 106.5 is “selectively” blocking Lycamobile users from connecting for unknown reasons. I encountered this during both the morning and afternoon rides, and I thought this would be a big issue for me – since my mobile data is used quite often to stream radio (because FM is so noisy and DAB+ isn’t quite the stable service I’d hoped it to be).

We Have to Dig Deeper

In order to dig deeper, I had to set up my mobile-sniffing testbed again. Mobile apps don’t do a great job of telling you what they’re connecting to and how they’re doing so, and so the easiest way for me was to hook up a second access point to my second NIC on my machine, bridged to the first NIC (network with internet access), and do Wireshark captures of the things that didn’t work – namely streaming KIIS 106.5 and downloading Google Play apps.

This would allow me to understand how the phone behaves on the Wi-Fi connection, and then we can set about grabbing the Lycamobile SIM, throwing it in an old USB modem, and then replicating the requests and seeing what happens.

Radio Streaming

Looking at the TuneIn Radio app, it makes a lot of requests to their servers for playlists, similar stations, etc. But the real stream is requested directly from a host known as – that’s Australian Radio Network’s streaming server.


TuneIn Radio pretends to be Windows Media Player as a user agent, and requests an .mp3, thus resulting in a 64kbit/s mono 44.1khz MP3 stream.

iHeartRadio however, is a little bit more … uh, generous with its data request (device ID blanked), and sends a request instead for an .aac stream, resulting in a 32kbit/s stereo AAC stream at 44.1khz sample rate.


In both cases, the request was made to Thus, it seems the failure of both apps is probably a failure to contact the server.

Contacting the server via my home TPG connection is successful and results in audio from the browser on the phone when the direct URL is plugged in:

arn-website Screenshot_2015-04-23-21-03-08

A ping shows a healthy response, and traceroute shows the path it takes to the server:



I then whipped out my old Huawei modem, dialled up a link … note the carrier grade NAT used by Lycamobile


… and tried to get to the server.


No dice. The data is dropped right after the internal carrier grade NAT gear, so it is routed “blackhole”. I don’t know why, but this may be due to a deliberate or unintentional misconfiguration of their routing tables. Whatever it is, it stops at Lycamobile’s border and doesn’t get past it in any way. The DNS resolve is fine though, so it wasn’t “blocked” by that method, nor was it blocked by TCP RST – this is a silent dropping of packets meaning a long wait for the connection establishment process to time out.

Screenshot_2015-04-23-21-03-57Plugging the URL into the phone also sees the browser sitting and waiting for a reply that never comes.

Of course, I had to prove that tracing from the PC modem was fine … so I traced back home via Lycamobile, and despite taking a long route through Japan, it made it. So the lack of a trace to is not due to my hardware or software.


In this trace, we see which is Lycamobile’s public facing side IP. The fact that this is missing above suggests this is an internal Lycamobile routing fault. Maybe this is deliberate?

Google Play Downloads

Trying to troubleshoot the Google Play download issue was a lot more difficult owing to the fact that everything uses SSL, and that Google has many dispersed mirror sites around the world. However, in the two screenshots below, you can see a period of two minutes “stuck” at the “candybar” progress bar waiting for the download to begin. Given it’s a Google app, it should always be available.

Screenshot_2015-04-23-22-01-15 Screenshot_2015-04-23-22-03-21

I had to install a program called Netstat Pro to try to nail this one down. It seems many connections are being attempted to Google’s mirror in Narita, Japan but not successfully connecting to both f11 and f12 (note is Google’s own CDN domain).


The issue with this finding was the reproduction. By dropping the mobile data session, and reconnecting, I found that navigating to was possible and redirected me to Google’s front page, as expected. But downloading the app continued to fail, instead as Google Play tried to use a different mirror this time which seems to be blackholed. Accessing mirrors outside, e.g. TPG’s one which I sniffed from Wi-Fi, seems to be okay but Google Play doesn’t know to use them and only uses the ones Lyca seems to be blocking.

What about Youtube?

The thought then arose – what about another popular, bandwidth intensive service? Lets give Youtube a try … any popular front page video oughta do.


… uh oh. Nothing but a spinning circle. I think this is not a coincidence. Reverting to my TPG-served Wi-Fi resulted in immediate load even before the circle spun around even ONCE.


The problem with radio streaming may see me drop Lycamobile really soon. Unfortunately, if I can’t stream the leading radio station in Sydney over my mobile data connection, something is really wrong. The issue seems to stem within Lycamobile’s own routing, and as far as it goes, seems to me to possibly be deliberate in an attempt to reduce extraneous data usage. This may be to try and “balance the books” by essentially “expiring” unused data credit because of an inability to use it. Needless to say, this is a poor business decision, and I shouldn’t have to use my own VPN to get around it (which essentially means I’m triple-charged because my home VPN relay is downloading and re-uploading, at a latency and packet loss disadvantage).

The problem with Google Play may be indeed a Google problem, or maybe a software “design” thing I don’t know about, as its reproduction is very hit and miss due to the state of “mirror allocation”. However, blocking Google Play downloads may have a noble intention at heart – this might stop users from unexpectedly racking up a whole heap of unintended data usage due to automatic updates (which are normally restricted to Wi-Fi, but if using tethering/Wi-Fi modems, may happen for some end users).

However, I’m inclined to believe that it isn’t. Although I don’t use Youtube very often, I tried to use it today, and it resulted in a spinning logo and nothing else. Obviously, another bandwidth intensive service, and it doesn’t work – this is unlikely to be a coincidence.

Regardless, at the core of the internet, despite all corporate interests, is an expectation of neutrality. This means no discrimination on the type of traffic, the protocol involved, the destination, the source, etc. The internet should be treated as a utility – no prioritising traffic over others, no “quota free” bundling of specific services. It is essential to the fair competition of online services and proper utilization of the technology.

Regardless of the cause, Lycamobile failed to deliver today. I wonder if they will resolve this issue in due course. I have reported the issue to Lycamobile, which I hope will “solve” this problem soon for everyone’s benefit … but I will have to wait to see the result.


I haven’t heard back from Lycamobile, but this morning, things seem back to normal and is reachable once again. A configuration mistake on their behalf, maybe?

Posted in Computing, Telecommunications | Tagged , , , | Leave a comment

Happy Birthday: Facebook Post Experiment & SSH Honeypot

Another birthday, and it’s a reminder that yet another year has passed. Time seems to pass by quickly, even when you do your best to make the most of every day without overloading yourself. That’s just how life is, I suppose. Unfortunately, nothing can stay the same, and that includes me. I am getting older, and likewise, my interests and technology continue to evolve. The only way forward is to keep up with the changes.

While the readers might be familiar with the site’s humble beginnings, it is now regularly serving over 1,800 views a day, at times close to 2,400 views in a day, which is a bit of a stretch for an “economy” hosting plan. Its Alexa rank has slipped to about 500,000, but is still plenty of places above where I thought it would be. I am still trying to make the most of it – balancing expense with quality of service, and using my time to bring readers “unique” content which I have built personally (unless otherwise noted). The monthly views exceed 180GiB of traffic, even with the help of GZIP and CloudFlare caching.

As a result, I’m not always able to keep up with the comments and e-mail that come in. Sorry if I haven’t been able to reply to your e-mail or comment – I simply don’t have the time sometimes, and other times, I really can’t help you out – sometimes due to copyright reasons. I must apologize to some readers, as they get “lost” in the myriad of technology themes, especially those who may have subscribed due to an interest in any “one” particular theme, for example shortwave DX or retrocomputing, which I haven’t had much time to revisit despite having piles of things to put up “when I get around to it.” I always promise to make things easier to navigate, but I never get around to it!

In essence, this has turned into more of a (messy) engineer’s logbook of things I have done, or random-reference resource that people stumble across by Google. While some people may look upon what I have achieved and be envious, rest assured that I regularly look upon their lives in a similar sort of envy. We always want what we don’t have.


To that end, I am trying to be a (little) more social, being the introvert that I am. I hope to meet someone who is truly my “other half” – about time as well, especially when I look around my Facebook feed. However, it’s not easy when you’re as nerdy and introverted as I am.

While I don’t have the time to personally thank everyone for sending me a “happy birthday” post or message, I guess this post (with the obligatory cake photo) will have to do. As a reward, here are the results of two random experiments which I “set up” to happen at about the time of my birthday.

Facebook Post Experiment

This experiment started last year, when I thought it was a good idea to take a look at how many people bothered to wish me Happy Birthday on my Facebook wall. The theme was along the lines of declining engagement with Facebook by users, and originally was supposed to be a tongue-in-cheek about how I might not get any posts.

While there was a big flaw with that finding – namely, my family will probably still continue to post despite the lack of value in doing so, the idea is somewhat solid. Of course, most of the posts were simplistic variations on a simple theme with not much substance, and despite Facebook’s introduction of a reminder system which tells you about birthdays and encourages you to make a post, the trend is firmly downward.


Dividing the number of posts received within the 24 hour period of my birthday with the number of friends, allows us to plot the percentage of friends which posted a message to my wall. While not as dire as initially estimated (under 2%), it is still notably less than last year. I haven’t actually gained many friends in the period (under 2%), so this probably reflects some of my friends “not bothering” anymore. Exactly what I’d expect from declining engagement with Facebook.

As for “template responses”, it seems this year, all of the messages can be categorized as a template response due to their general structure of “happy” + “birthday” + <optional “name”> + <optional ‘!’ repeated n times> + <optional cliche statement>. It was predicted that this would rise to about 95%, so this represents a less thoughtful posting, probably as a result of desensitization by being reminded about birthdays … or more likely, a lack of connection with me “personally”.


The actual number of posts did decrease as expected, and taking an exponential fit (rather than a silly linear one last year), it seems that we’re going to lose one or two posts by next year, despite Facebook (and the world population) continuing to grow.

Is this such a bad thing? Arguably not. If our interactions are templated, and a function of social convention, aside from being a social “lubricant”, the posts serve no real purpose. A reduction in the number of posts might actually save Facebook some storage space in their database, and reduce the energy consumption of their services.

Of course, all of this could be explained by the fact that my Facebook friends don’t actually like me anymore, or consider me their friend … a hypothesis that I’m not willing to discount just yet.

The SSH Honeypot Experiment

For the more technologically inclined people, they would probably like this segment of the post a little more than the last. One of my friends showed me an SSH attack “map” earlier in the month, and I really didn’t think it looked quite right. Being the victim of brute forcing early in the life of this site, I decided to create an SSH honeypot and try to make my own “map” of the attack space.

On 7th April, I bought up a box with OpenSSH running on it, and I opened up port 22 through the router to the box. The box was secured, of course, to avoid actual intrusion, but to “tempt” would-be brute-forcers to the box. The box was continually run from a home ADSL2+ connection, with no publication of the address anywhere.

The box was left running, with the logs from 12th to 18th April (a one week period) inspected and a program written to parse the logs to gain statistics about the actual brute force attempts. The reason the initial logs were discarded was to ensure there was sufficient time for scanners to catch the presence of the box and begin their attempts.

The logs were combed for number of attempts per IP address, and a reverse DNS and geolocation of the IP used to determine country of origin (imprecise, but close enough). The number of attempts for each unique username was recorded as well. Full data at the end of this posting.


Some of the summary findings from this honeypot experiment are as follows:

  • The time from port opening to the first brute force attempt was about 36 minutes.
  • During the survey period, 499 unique IP addresses were caught attempting to login to the box, by pure “scanning” it seems.
  • A total of 142,542 attempts were made, an average of 4.24 seconds between attempts.
  • 96.68% of all attempts were made for the username “root”.
  • Total bandwidth usage exceeded 200MiB on some days in pure traffic spent answering phony SSH requests. This means scanning traffic could reach 6GB in a month, equal to the whole monthly broadband bandwidth allowance for some plans.
  • China and Hong Kong were the main attackers on a number of attempts basis, with Bahrain, China and Hong Kong taking the cake for the number of unique hosts.
  • A check did not correlate any of the attacking IP addresses as ToR exit nodes.
  • Most IP addresses had no reverse DNS records available.

Lets take a look at some of these findings in a graphical format.

Username Hit Count

See the big blue pie? Yep. That’s all the attempts at a password for “root” – so probably best not to have a root account, at least, not under the “root” name.

Username Hit Count excl root

If we exclude “root” from the pie, we get the remaining ~3.6% of attempted account names. Many of the names are standard names you might use, based on application names, or default hard-coded administrative accounts, some of which are device specific. Not all of them can be seen in the legend due to the scale – see data section for full data.

Number of Hosts per Country

Looking at the number of unique hosts by country, interestingly, Bahrain tops the list, followed by China and Hong Kong. The reason for this may be due to malware and worms, because if we plot the number of attempts versus country, then the graph changes considerably.

Number of Attempts by Country

China and Hong Kong both account for about 90% (roughly) of all the brute force attempts. This indicates that they have some concentrated deliberate systematic attacking going on, as opposed to the other countries where quicker and less systematic attempts are done maybe as a quick way to infect neighbouring machines.

Despite what others may say about security through obscurity, running SSH on port 22 is only inviting chatter and wasting bandwidth, and potentially putting you at risk. This is the case if you use other common alternatives, such as 222 or 2222. Moving it to another different port has reduced the load on my SSH-accessible boxes to pretty much that of my own usage, so it’s recommended, along with other SSH authentication best practices.

Data – List of Hosts

IP Country Count Hong Kong 11828 Hong Kong 9105 Vietnam, 44, Hanoi 6807 China, 03, Nanchang 6579 China 5503 China, 03, Nanchang 3429 China, 19, Shenyang 3134 Hong Kong 3060 China, 01, Hefei 2237 China, 03, Nanchang 1851 China, 03, Nanchang 1654 Hong Kong 1630 Hong Kong 1589 Hong Kong 1494 Hong Kong 1458 Hong Kong 1414 Hong Kong 1299 Hong Kong 1299 China, 03, Nanchang 1254 Hong Kong 1252 Hong Kong 1242 China, 04, Nanjing 1191 Hong Kong 1188 Hong Kong 1188 Hong Kong 1177 Hong Kong 1128 Hong Kong 1119 Hong Kong 1093 Hong Kong 1055 Hong Kong 1053 China, 04, Nanjing 1034 Hong Kong 1016 Hong Kong 1011 China, 22, Beijing 987 Hong Kong 981 Hong Kong 975 Hong Kong 951 Hong Kong 938 China, 04, Nanjing 936 China, 03, Nanchang 921 China, 25, Jinan 915 Hong Kong 897 Hong Kong 894 China, 04, Nanjing 885 China, 03, Nanchang 878 China, 04, Nanjing 831 China, 04, Nanjing 810 Hong Kong 800 Hong Kong 799 Hong Kong 798 Hong Kong 792 Hong Kong 791 Hong Kong 781 China, 04, Nanjing 774 Hong Kong 769 Hong Kong 768 Hong Kong 767 China, 04, Nanjing 758 China, 03, Nanchang 753 China, 04, Nanjing 753 Hong Kong 748 China, 04, Nanjing 709 Hong Kong 705 Hong Kong 681 Hong Kong 680 Hong Kong 671 Hong Kong 663 Hong Kong 657 China, 04, Nanjing 654 Hong Kong 630 Hong Kong 623 Hong Kong 600 Hong Kong 594 Hong Kong 588 China, 04, Nanjing 582 China, 04, Nanjing 582 Hong Kong 578 Hong Kong 570 Hong Kong 570 Hong Kong 531 Hong Kong 527 Hong Kong 516 China, 03, Nanchang 507 Hong Kong 501 Hong Kong 501 Hong Kong 501 China, 29, Kunming 496 China, 04, Nanjing 492 China, 04, Nanjing 477 Hong Kong 474 China, 02, Hangzhou 472 China, 04, Nanjing 470 Hong Kong 464 United States, CA, Walnut 462 China, 04, Nanjing 456 China, 04, Nanjing 451 China, 03, Nanchang 450 Hong Kong 437 China, 04, Nanjing 437 China, 03, Nanchang 435 China, 04, Nanjing 424 Hong Kong 420 Hong Kong 414 China, 03, Nanchang 405 China, 04, Nanjing 393 China, 04, Nanjing 385 China, 04, Nanjing 384 Hong Kong 370 China, 04, Nanjing 360 China, 04, Nanjing 357 China, 04, Nanjing 357 Hong Kong 351 Hong Kong 345 Hong Kong 342 China, 04, Nanjing 329 Hong Kong 322 Hong Kong 309 China, 03, Nanchang 306 China, 04, Nanjing 300 Hong Kong 289 China, 03, Nanchang 288 China, 04, Nanjing 281 China, 04, Nanjing 264 China, 03, Nanchang 255 China, 04, Nanjing 255 China, 03, Nanchang 255 China, 03, Nanchang 252 Indonesia 249 China, 04, Nanjing 243 China, 04, Nanjing 225 China, 04, Nanjing 219 Hong Kong 200 China, 04, Nanjing 180 Hong Kong 177 China, 04, Nanjing 174 China, 03, Nanchang 174 Hong Kong 173 Hong Kong 171 China, 03, Nanchang 165 China, 03, Nanchang 163 China, 03, Nanchang 159 United States, TX, San Antonio 157 China, 04, Nanjing 156 China, 03, Nanchang 138 China, 04, Nanjing 138 Brazil 137 China, 04, Nanjing 126 Argentina, 07, Buenos Aires 124 China, 01, Hefei 120 China, 04, Nanjing 117 China, 15, Lanzhou 112 China, 22, Beijing 108 France 108 China, 04, Nanjing 108 Hungary, 04, Tarcal 90 Hong Kong 78 France 68 Sri Lanka 65 France, A8, Paris 49 China, 03, Nanchang 47 China, 03, Nanchang 45 China, 30, Guangzhou 41 Hong Kong 39 Korea, Republic of 35 China, 03, Nanchang 33 China, 04, Nanjing 33 China, 03, Nanchang 31 United States, CA, Santa Clara 30 Russian Federation, 08, Ufa 22 China, 22, Beijing 21 China, 02, Jinhua 20 China, 05, Changchun 18 China, 05, Changchun 17 China, 02, Hangzhou 15 China, 05, Changchun 15 Russian Federation 15 Russian Federation, 48, Moscow 14 Australia, 04, Brisbane 12 China, 30, Guangzhou 11 Bahrain 11 China, 22, Beijing 10 Brazil, 07, Bras?lia 9 China, 04, Nanjing 8 France 7 Bahrain 7 Italy 7 Brazil 7 Brazil 7 Brazil 7 Bahrain, 16, Manama 7 Bahrain 7 Bahrain 7 Italy 7 Bahrain 7 Russian Federation 7 Bahrain 7 Russian Federation, 38, Krasnodar 7 Bahrain 7 Bahrain 7 Bahrain 7 Bahrain 7 Italy 7 Bahrain 7 Bahrain 7 Italy 7 Italy, 10, Cerreto 7 Bahrain 7 Russian Federation 7 Bahrain 7 Bahrain 7 Brazil 7 Bahrain 7 Italy, 07, Rome 7 Italy 7 Bahrain, 16, Manama 6 Bahrain 6 Brazil 6 Bahrain 6 Bahrain 6 Bahrain 6 Italy, 06, Trieste 6 Russian Federation 6 Bahrain 6 Bahrain 6 Brazil 6 Brazil 5 Bahrain 5 Italy, 12, Isola Sant’antonio 5 Russian Federation, 48, Moscow 5 Italy 5 Russian Federation, 48, Moscow 5 Italy 5 Brazil, 26, Itaja? 4 Bahrain 4 Italy, 09, Lissone 4 Brazil, 21, Rio De Janeiro 4 Russian Federation 4 Bahrain 4 Russian Federation 4 Italy, 13, Orta Nova 4 Italy 4 Bahrain 4 Russian Federation 4 Russian Federation 3 Italy, 11, Isernia 3 Bahrain 3 Bahrain 3 Bahrain 3 Brazil 3 Brazil 3 Bahrain 3 Brazil 3 Bahrain 3 Russian Federation, 04, Barnaul 3 Bahrain 3 Italy, 16, Anghiari 3 Bahrain, 16, Manama 3 Russian Federation 3 Brazil, 15, Serrania 3 Italy, 09, Codogno 3 Bahrain 3 Bahrain 3 Bahrain 3 Bahrain 3 Brazil, 27, S?o Paulo 3 China, 23, Shanghai 3 China, 03, Nanchang 3 China, 25, Jinan 2 Bahrain 2 Russian Federation 2 Bahrain, 16, Manama 2 Italy 2 Bahrain 2 Bahrain 2 Brazil 2 Italy, 10, Cerreto 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain 2 Brazil 2 Russian Federation, 71, Yekaterinburg 2 Bahrain 2 China, 04, Nanjing 2 Bahrain, 16, Manama 2 Bahrain 2 Brazil 2 Italy 2 Italy 2 Brazil 2 Bahrain, 16, Manama 2 Brazil 2 Italy, 05, Ravenna 2 Italy, 10, Cerreto 2 Brazil, 23, Santa Maria 2 Russian Federation, 48, Moscow 2 Bahrain 2 Bahrain 2 Bahrain, 15, Hidd 2 Brazil 2 Bahrain, 16, Manama 2 Bahrain 2 Bahrain 2 Bahrain, 19, Tubli 2 Bahrain 2 Brazil 2 Bahrain 2 Brazil, 23, Espumoso 2 Bahrain, 16, Manama 2 Bahrain 2 Brazil 2 Italy, 12, Orbassano 2 Bahrain 2 Bahrain 2 Bahrain 2 Brazil 2 Bahrain 2 Italy, 04, Napoli 2 Pakistan 2 Bahrain 2 Brazil 2 Italy, 04, Montemarano 2 Bahrain, 16, Manama 2 Bahrain, 16, Manama 2 Bahrain 2 Bahrain 2 Bahrain 2 Italy, 12, Torino 2 Brazil, 15, Passos 2 Bahrain 2 Bahrain 2 Italy 2 Italy 2 Bahrain 2 Brazil 2 Brazil 2 Bahrain 2 Bahrain 2 Brazil 2 Bahrain 2 Italy 2 Brazil 2 Bahrain 2 Italy 2 Italy, 04, Cardito 2 China, 02, Jiaxing 2 Brazil 2 Bahrain 2 Bahrain 2 Bahrain 2 Italy 2 Bahrain 2 Brazil, 15, Monlevade 2 Italy 2 Brazil 2 Bahrain 2 Italy, 04, Avellino 2 Italy, 05, Ravenna 2 Bahrain 2 Brazil, 15, Taiobeiras 2 Italy, 09, Milan 2 Bahrain 2 Brazil 2 Bahrain 2 Bahrain, 16, Manama 2 Bahrain 2 Bahrain 2 China, 22, Beijing 2 Bahrain 2 Brazil 2 Russian Federation 2 Bahrain 2 Italy 2 Bahrain 2 Italy, 20, Dolc? 2 Bahrain 2 Italy 2 Italy 2 Russian Federation 2 Brazil 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain 2 Italy 2 Bahrain 2 Italy 2 Russian Federation 2 Brazil 2 Brazil 2 Bahrain 2 Russian Federation 2 Bahrain 2 Bahrain 2 Russian Federation, 59, Ussuri 2 Pakistan 2 Italy, 07, Rome 2 Bahrain 2 Pakistan 2 Pakistan 2 Italy, 16, Figline Valdarno 2 Bahrain 2 Brazil, 27, Pirassununga 2 Brazil 2 Russian Federation, 72, Tambov 2 Russian Federation 2 Bahrain 2 Russian Federation 2 Bahrain 2 Russian Federation, 29, Kemerovo 2 Russian Federation 2 Bahrain, 16, Manama 2 Bahrain 2 Brazil 2 Bahrain 2 Brazil 2 Italy 2 Brazil, 15, Cataguases 2 Brazil 2 Brazil, 27, S?o Paulo 2 Bahrain 2 Brazil 2 Italy 2 Bahrain 2 Brazil 2 Italy 2 Bahrain, 15, Hidd 2 Italy, 12, Predosa 2 Italy 2 Russian Federation 2 Brazil, 26, Gaspar 2 Italy 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain, 16, Manama 2 Bahrain 2 Italy, 09, Milan 2 Italy 2 Brazil, 27, S?o Paulo 2 Bahrain 2 Bahrain 2 Italy 2 Italy 2 Russian Federation 2 Russian Federation, 66, Saint Petersburg 2 Italy, 09, Castiglione Delle Stiviere 2 Italy 2 Brazil 2 Italy 2 Russian Federation 2 Bahrain 2 Bahrain 2 Bahrain 2 Russian Federation 2 Brazil 2 Brazil 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain 2 Italy 2 Bahrain 2 Italy 2 Bahrain, 16, Manama 2 Bahrain 2 Bahrain 2 Bahrain 2 Russian Federation 2 Italy, 04, Napoli 2 Bahrain 2 Brazil 2 Brazil 2 Italy, 05, Piacenza 2 Brazil 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain 2 Bahrain 2 Italy, 05, Ravenna 2 Bahrain 2 Bahrain 2 Italy, 13, Maruggio 2 Russian Federation 2 Brazil 2 Vietnam, 82, Nam Dinh 2 Brazil, 27, S?o Paulo 2 Brazil 1 Bahrain 1 Russian Federation 1 Russian Federation 1 Italy 1 Bahrain 1

Data – List of Usernames

Username Count
root 137812
test 565
nagios 288
admin 256
zabbix 200
guest 199
oracle 98
zxin10 92
git 68
ubuntu 60
tomcat 56
apache 54
weblogic 48
cacti 48
zhaowei 48
www-data 43
web 42
ubnt 42
ftpuser 39
ftp 36
user 33
MGR 33
postgres 32
jboss 32
webadmin 31
mysql 30
squid 30
support 26
info 26
Test 24
boot 22
sysadmin 22
nginx 20
r00t 18
PlcmSpIp 17
dff 16
svn 16
hadoop 16
www 16
java 16
apache2 16
httpd 16
zhangyan 14
vnc 14
plesk 14
vyatta 14
slview 14
deploy 14
xiuzuan 12
alex 12
tom 12
common 12
nobody 12
wangyi 12
operator 11
system 11
Administrator 11
123456 10
123 10
pi 10
usuario 10
grid 10
administrator 10
pgadmin 10
cms 10
patrol 10
bash 8
webapp 8
dev 8
test2 8
david 8
sasaki 8
teamspeak 8
mysql2 8
cvs 8
mongodb 8
smbuser 8
images 8
centos 8
helen 8
john 8
sshusr 8
webuser 8
portal 8
D-Link 8
isadmin 8
infratel 8
setup 7
login 7
service 6
atsuser 6
huawei 6
bin 6
catadmin 6
cactiuser 6
avconroot 6
ds 6
ratan 6
mas 6
testftp 6
tsminst1 6
hmsftp 6
cron 6
syscheck 6
matlab 6
amitj 6
amandabackup 6
lsfadmin 6
office 6
user01 6
apc 6
ftpuser1 6
helpdesk 6
nms 6
jack 6
yang 6
edu 6
webmaster 6
user1 6
manager 6
default 6
mysql1 6
demo 6
db2fenc1 6
mqm 6
eshop 6
redis 6
ved 6
cvsadmin 6
ftptest 6
ajay 6
sshuser 6
jake 6
solr 6
chandru 6
rabbitmq 6
gerrit2 6
vncuser 6
nan 6
nologin 6
webmail 6
blank 5
maint 5
cgi 4
a 4
redmine 4
sybase 4
pos 4
db2inst1 4
vinod 4
hhj 4
epg 4
tanimoto 4
nemoto 4
aaron 4
devdata 4
live 4
deepak 4
air 4
cmsftp 4
medtech 4
himanshu 4
itadmin 4
openbravo 4
rahulb 4
dbuser 4
developer 4
mpi 4
tracking 4
omcuser 4
mandy 4
naveen 4
bmp 4
ces 4
cti 4
msp 4
auser 4
frank 4
anu 4
bao 4
cs 4
gdnslog 4
sw 4
jjs 4
user10 4
cdr 4
digital1 4
johannes 4
max 4
theresa 4
cat 4
kat 4
chris 4
sam 4
janak 4
lisa 4
khaled 4
audrey 4
beyond 4
sandeep 4
nforge 4
postfix 4
upload 4
public 4
emily 4
backuppc 4
security 4
deployer 4
nexus 4
sonar 4
xbian 4
alin 4
test1 4
testuser 4
tester 4
adam 4
deme 4
mongodb2 4
eric 4
db2fenc 4
steven 4
lihan 4
username 4
syncro 4
nfsnobody 4
craft 4
super 4
superuser 4
ts 4
telkom 4
siaga 4
centerback 4
hotbill 4
guestadmin 4
guestuser 4
guestx 4
javaprg 4
resin 4
apache1 4
httpd2 4
httpdocs 4
nagiosadmin 4
nagiosuser 4
ftp1 4
ftpd 4
sshd 3
backup 3
tech 3
sysadm 3
install 3
diag 3
admim 3
cusadmin 3
supervisor 3
browse 3
inads 3
superman 3
lp 3
Polycom 3
piranha 3
op 3
tose 2
dasusr1 2
imapuser 2
inst01 2
wwwrun 2
mgm 2
oracle10 2
psd 2
svnadmin 2
websync 2
cnred 2
oracle11 2
student 2
abc123 2
1 2
2 2
mf 2
business 2
boris 2
chandu 2
apple 2
matthew 2
julien 2
ikeda 2
kas 2
arun 2
gis 2
bill 2
marc 2
jinseok 2
nikhil 2
sghosh 2
jurist 2
dima 2
thomas 2
ktkim 2
kjs 2
hxhtftp 2
user07 2
ldap 2
gopal 2
benny 2
benoit 2
jmpark 2
smg 2
garden 2
hacluster 2
gao 2
ftpadmin 2
controller 2
amavisd 2
rsync 2
jenkins 2
tuxedo 2
gwaf 2
garrysmod 2
xiaow 2
zsofi 2
rtorrent 2
ibmuser 2
hduser 2
asterisk 2
debian 2
oracle2 2
soft 2
temp 2
operador 2
daniel 2
pc 2
polycom 2
server 2
soporte 2
project 2
skaner 2
master 2
servidor 2
log 2
pgsql 2
mike 2
alan 2
git1 2
deploy1 2
gitadmin 2
gittest 2
supersys 2
wasadmin 2
maximo 2
db2inst3 2
db2admin 2
vijay 2
db2inst2 2
db2fenc2 2
vbox 2
ttf 2
iptv 2
alice 2
Sorin 2
amix 2
dede 2
ghost 2
gusr 2
gyaseen 2
kde 2
koba 2
nano 2
nfsnobod 2
paras 2
payment 2
red 2
isa 2
smokey 2
xVIRal 2
amanda 2
martin 2
fidelity 2
z 2
monitor 2
claudia 2
cisco 2
adrian 2
jerry 2
marie 2
rk 2
anna 2
library 2
bruce 2
bob 2
five 2
barbara 2
emma 2
debug 2
adminttd 2
3comcso 2
recovery 2
User 2
volition 2
3play 2
addon 2
airlive 2
kermit 2
dhs3mt 2
at4400 2
mtch 2
mtcl 2
dhs3pms 2
adfexc 2
client 2
halt 2
1234 2
acc 2
device 2
IntraSwitch 2
IntraStack 2
readonly 2
Service 2
manuf 2
dadmin 2
isp 2
installer 2
mediator 2
cellit 2
cmaker 2
netrangr 2
bbsd-client 2
Cisco 2
hsa 2
wlse 2
wlseuser 2
citel 2
comcast 2
PFCUser 2
corecess 2
cgadmin 2
Alphanetworks 2
davox 2
MDaemon 2
draytek 2
tiger 2
netman 2
websecadm 2
MD110 2
anonymous 2
maintainer 2
manage 2
netadmin 2
WP 2
Factory 2
vodafone 2
telecomadmin 2
storwatch 2
vt100 2
superadmin 2
hscroot 2
tmadmin 2
iclock 2
Admin 2
intermec 2
netscreen 2
readwrite 2
bciim 2
bcim 2
bcms 2
bcnas 2
blue 2
cust 2
enquiry 2
init 2
locate 2
rcust 2
scmadmin 2
medion 2
router 2
GlobalAdmin 2
ben 2
Gearguy 2
mythtv 2
tnmspon 2
rpcuser 2
gopher 2
ns 2
ashish 2
naadmin 2
netopia 2
e500 2
vcr 2
m1122 2
telecom 2
disttech 2
mlusr 2
l2 2
l3 2
ro 2
rw 2
rwa 2
spcl 2
ccrusr 2
266344 2
adminview 2
adminstat 2
adminuser 2
cac_admin 2
write 2
echo 2
on 2
telekom 2
adminpldt 2
engmode 2
radware 2
wradmin 2
teacher 2
temp1 2
admin2 2
adminstrator 2
deskalt 2
deskman 2
desknorm 2
deskres 2
replicator 2
RMUser1 2
topicalt 2
topicnorm 2
topicres 2
GEN2 2
eng 2
su 2
31994 2
poll 2
smc 2
mso 2
1.79 2
stratacom 2
surecom 2
sweex 2
target 2
super.super 2
xbox 2
telco 2
tellabs 2
tiara 2
Any 2
enduser 2
VTech 2
witpack 2
rapport 2
1502 2
xd 2
11111 2
unknown 2
sales 2
uploader 2
marketing 2
alu 2
amssys 2
poolerconf 2
ratmin 2
tlkmaddm 2
duktek 2
ipdn 2
netamdm 2
billing100 2
enigma 2
system_user 2
anin 2
sentral 2
itrack 2
sys 1
uucp 1
Posted in Computing, Event, Uncategorized | Tagged , , , , | 7 Comments