Hacker's ramblings

Windows 8 (or 8.1) is one of the not-so-popular operating systems. Even Microsoft employees admit Windows 8 is 'the new Vista'. Ok, they failed on that. Perhaps Windows 9 will be better.

Now that we have that out, there are a number of weird things in that OS. The one bugging me most is the fact that the full screen app icons that appear when you move the cursor to the top-left corner of your desktop are failing to display. This happens to me very often. It seems to have something to do with sleep/hibernate on my Win8 laptop. It should look like this:

But it looks like this instead:

Not cool.
There are some shadows from the icons, but nothing usable or nothing that I could use to identify which icon is for which app.

I don't know what's the problem, but I found a fix. The culprit is your classic explorer.exe. The fix is simple. Zap your Windows Explorer with a magic kill process -wand and create a new better one. The new explorer won't know anything about already running full-screen apps, but it will sure learn if you manage to get into one.

Here is the fix. First start the Task Manager. Since the idea is to kill explorer.exe, you'll need a tool to eradicate the old one and make sure you can start a new one. The sequence starts from Task Manager's Details tab-sheet:

After that your explorer will be back and your icons will be back after you visit all of your apps.

John do, a reader of this blog made a serious break-trough! Via SSH on B593 prompt, he found the flashtest-command. Before this I had no knowledge about such command, but see what I can do with this new information:

# flashtest
Usage: flashtest {info|read|write|erase|export|load} {addr} {len} [data]
Format:
flashtest    help
flashtest    info
flashtest    read      addr    len
flashtest    write     addr    len    {data}
flashtest    erase     addr    len
flashtest    export    addr    len

Well ... the info sound interesting. Let's see:

# flashtest info
 flash  block  size  :  0x40000 (256k Bytes)
  flash  block  num   :  0x40 (64 Blocks)
  flash  total  size  :  0x1000000 (16M Bytes)
  flash  partation  info :
  ---------------------------------------------------------------
  Name                  Address                    Usage
 ---------------------------------------------------------------
  Boot                  0x0---0x40000            Bootloader
  Image             0x40000---0xA40000           Main  image
  Image            0xA40000---0xE00000           Subject  image
  Curcfg           0xE00000---0xE40000           Curcent  config
  Faccfg           0xE40000---0xE80000           Factury  config
  Tmpcfg           0xE80000---0xF00000           Temp  config
  Fixcfg           0xF00000---0xF40000           Fixed  config
  Logcfg           0xF40000---0xF80000           Log  config
  TR069            0xF80000---0xFC0000           TR069  cert
  Nvram            0xFC0000---0xFFFFFF           Nvram

Current config! Really!? (Mis-typed as Curcent config). The run-time -only /var/curcfg.xml's real storage has eluded me this far. Let's explore that further:

# flashtest export 0xE00000 65536
Read data: addr = 0xe00000, len = 0x10000 ...
Begin write to file
Export done

What did it do? Where it wrote to? Some poking around reveals:

# cd /tmp/
# ls -l
----------    1 0        0           65536 flashinfo.bin

Oh yes! The next thing is to get my hands on to the file. In the B593 firmware's Busybox there is only a limited set of tools.

Let's use the USB/FTP-hack for transferring the file. The idea is to plug an USB-stick into B593. Any FAT32-formatted stick will do, it is totally irrelevant if there are files or not. Early firmwares are known to have a flaw in them. You can mount the entire filesystem into FTP-server and transfer file to/from the box. Setup goes like this:

Make sure you have the FTP-server running, add a user to the new mount and set the directory as ../.. It is really important to do that! That effectively breaks out of /mnt/usb2_1 into /. See this pic:

I added user with name test. Now let's see if the FTP-connection works from an external machine:

# ftp 192.168.1.1
Connected to 192.168.1.1 (192.168.1.1).
220 bftpd %v at 192.168.1.1 ready.
Name (192.168.1.1:user): test
331 Password please.
Password:
230 User logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /tmp
250 OK
ftp> dir
227 Entering Passive Mode (192,168,1,1,166,124)
150 BINARY data connection established.
----------   1 0        0        65536 May 21 19:26 flashinfo.bin
226 Directory list has been submitted.
ftp>

Oh yes! The extracted NVRAM-binary is there. Let's download it:

ftp> get flashinfo.bin
local: flashinfo.bin remote: flashinfo.bin
227 Entering Passive Mode (192,168,1,1,144,190)
150 BINARY data connection established.
226 File transmission successful.
65536 bytes received in 0.06 secs (1092.41 Kbytes/sec)

A brief analysis of the file reveals:

# hexdump -C flashinfo.bin | head -3
00000000  3e 00 64 fe 3c 3f 78 6d  6c 20 76 65 72 73 69 6f  |>.d.<?xml versio|
00000010  6e 3d 22 31 2e 30 22 20  3f 3e 0a 3c 49 6e 74 65  |n="1.0" ?>.<Inte|
00000020  72 6e 65 74 47 61 74 65  77 61 79 44 65 76 69 63  |rnetGatewayDevic|

# hexdump -C flashinfo.bin | tail -5
000064f0  65 77 61 79 44 65 76 69  63 65 43 6f 6e 66 69 67  |ewayDeviceConfig|
00006500  3e 0a 00 ff ff ff ff ff  ff ff ff ff ff ff ff ff  |>...............|
00006510  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00010000

The first 4 bytes of 3e 00 64 fe are bit of a mystery. I don't know what the 3e 00 is for, but the 64 fe is obvious! It is the length of the XML-file following the header bytes. I can confirm that the entire /var/curcfg.xml is there. Unchanged. Intact!

My next move is to try altering the curcfg.xml and write it back. There is a chance of locking myself out of my own B593, so ... I need to be really careful with this. If everything works as I expect, my next move is to write tools for allowing people to access their devices as they want to.

I'd like to extend my gratitude to Mr. John do. This really is ground-breaking stuff allowing us to new lengths with Huawei B593 hacking. Thank you, sir!

This is something that has been bugging me since November. In my post about different models, I stated that I have a u-12 (and still do). Last year I did setup a s-22 to a friend and got to see that it is pretty much the same. However, "pretty much the same" is not exactly the same.

The s-22 is a newer model and it has been well established, that it has a TDD 2600 MHz added into it. All the FDD frequencies are exactly the same than in u-12.

In the comments of my post, a user suggested that s-22 differs from u-12 by having only one USB-connector. At the time I was unable to find proof of that, all the pictures I could found of alleged s-22 units had no difference for a u-12 unit.

Now the situation has changed. In my ventures of the wonderful Internet I found an article What's the difference between HUAWEI B593s-22 and B593u-12? and it has a picture of both units side by side in it. Nice! But which one is which?

Just to make sure that s-22 is in the left and u-12 is in the right, I'll post a fresh picture of my own u-12 unit:

Also to close the case I also found a vendor page with a nice picture of s-22 in it, see HUAWEI B593s-22 4G LTE CPE [B593s-22]. It has a picture of the unit in the page, and their s-22 looks exactly the same than the left unit in the picture, and exactly NOT the same than my u-12. Apparently s-22 does not have a power switch, it lacks the side USB-connector and SIM-card -slot has been changed into a tray. Lot of differences to spot, actually.

So I'm confident that s-22 is very much re-designed both in hardware and firmware. The hardware side is surely changed because of the new(ish) 4G TDD radio interface. And while Huawei engineers were at it, they changed also the firmware in number of ways, one of them being to resist hacking attempts better than their 1st gen version did. This is also a well established fact, s-22 firmware has a completely different structure than u-12 firmware.

Now me and everybody else should be able to identify the units by a simple visual inspection.

I got a comment from John, he told me that a telco in Germany called Telekom has SP104 firmware out for B593 u-12. They seem to call it Speedport LTE II. The download link to the firmware is http://hilfe.telekom.de/dlp/eki/downloads/Speedport/Speedport%20LTE%20II/Firmware_Speedport_LTE_II_V100R001C748SP104.zip

The UI has English language, so it should be usable for us non-German speaking users too.

As usual, I did download and extract the firmware and all looks ok to me. Also as usual, I didn't test it. If you do, please comment how it went.

Update 21th May 2014:
Today John told me that, Telekom released a security update SP105 firmware. There is little information what the fix is, but you can get the lates from this link http://www.telekom.de/dlp/eki/downloads/Speedport/Speedport%20LTE%20II/Firmware_Speeport_LTE_II_B593u-12_V100R001C748SP105.zip

The latest PHP versions are available for CentOS Plesk Panel admins. If you are using my YUM-repo as suggested, the update should be a painless one.

I managed to get the FPM running for PHP 5.4, for the PHP 5.5 it is still pending. Example:

# service php-fpm54 status     
php-fpm (pid  4318) is running...

Please note, that the FPM is still work-in-progress and it may contain bugs.

The latest PHP FPM has a fix for CVE-2014-0185. It is not a really dangerous one, it just takes care of 0666 permissions for the FastCGI unix-socket. It can be considered a security flaw if any local user can execute code via FastCGI-interface. Most web-servers don't have many local users, but this flaw can be combined with other security issues to get more gain out of it.

I got a comment about the firmware version numbers. How can you tell which one is a newer and which one is older? Well ... Huawei really does make this one difficult. I'm guessing all this has to do with the fact that any regular user should be insulated from the fact that his/hers hardware is manufactured by Huawei. Your beloved telco should be their face and you should be doing business with them and only them. Screw that! This is 2014 and the age of social networking in the Internet. Openness is the only real way to go.

Here is what I gatehered for B593 u-12. This is a list of firwares from oldest to newest:

This is for B593 s-22:

Just to be clear:
I don't know any of this to be factually correct, nor I can back any of this up from an "official" source. Feel free to correct me or suggest any other interpretation.

Update 18th May 2014:
Bilbo dropped me a comment with a link into https://app.box.com/s/0uim7fp7j4dzet2bpmhp. It provides more details about version numbering scheme Huawei uses. I did update the table headers with this new information.

Ok. The thing with trackbacks is, that they're used only for spam! Hate it.

Seven years ago it was said that 53% of all pings is spam. Today I'd say 100% of all pings is spam or sping. There is no point in allowing pings or trackbacks.

My blog software is Serendipity. It has following instructions for removing trackback links. Unfortunately the platform is well known and simply removing the links from HTML doesn't do the trick. The "official" word from Serendipity authors is to start using a plugin for managing spam trackbacks. Ok, since all of it is spam why bother!

This is what I put into my .htaccess:

# Deny trackbacks
RewriteCond %{REQUEST_METHOD} =POST
RewriteCond %{REQUEST_URI} =/comment.php
RewriteCond %{QUERY_STRING} type=trackback
RewriteRule .* - [F,L]

It has three rules in it to deny a POST request into comment.php having parameters type=trackback. A trackback will look like this on my Apache log:

POST /comment.php?type=trackback&entry_id=83 HTTP/1.0

Now the spammers should be gone and stay gone!

My blog has been on a low maintenance mode, due to the fact that I had other engagements. I was moving to a new house which has an FTTH or Fiber to the Home -connection.

The incoming connection is a 1000BASE-BX Ethernet and the connection carries also a IPTV streams in it. Of the given 1 Gbit/s I'm currently purchasing 250 Mbit/s downlink and 50 Mbit/s uplink. This costs me ~60 € per month. Not very expensive for such a quality bit, huh? There is a one-time building cost for 1800+ € for the connection, but that is not slowing me down.

In detail the connection is implemented with an Ethernet fiber to copper media converter and a CATV-module doing IPTV to DVB-C (SD-channels) and DVB-C2 (HD channels) media conversion. During the setup, the fiber-guy first built couple of meters of indoors cabling connected to the thick ground fiber. Indoor fiber connects to a Swedish made Inteno FG500 box. It looks like this:

In the first picture, there are 4 gigabit Ethernet (copper) connectors and a power connector to the CATV-module. Ethernet ports 1 to 3 are routed with a firewall and NAT, but luckily the port 4 is a bridged one and that's the one I'm using. From that I can get a public IP-address directly from ISP's DHCP-server.

The box splits into two halves, CATV and the "regular" Ethernet part. Parts are connected via power and fiber connectors:

The router has internal IP-address of 192.168.1.1 and it contains very typical web-interface for managing the box. Management looks like this:

WAN-parts are configured to copper Ethernet-ports with interface grouping:

It took me a while to figure all this out. It really matters to which LAN-port the cable is connected to. The WLAN-part can be deactivated and I did just that. I dislike those integrated crappy boxes very much, they are unreliable, insecure and what else ... Being a Linux-man I want to use my favorite Linksys and DD-WRT for any wireless needs.

This has got to be the best part of having a FTTH. The speed! Oh my god! Here are some sample results:

When analysing the results, two things come to my mind. First, Speedtest.net and the measuring servers it has don't go beyond 100 Mbit/s in any conditions (the software displays a maximum of 100 Mbit/s in it). Second, when measuring really fast speeds like I have here, the measurements are very unreliable and the results vary quite a lot when running number of tests in a sequence. In all cases, the downlink measurement is never 100 Mbit/s or even near it. 88 Mbit/s is pretty far from 100, or from the 250 Mbit/s what I'm paying. The uplink measurements are even worse. Those servers don't expect to be hit that hard (perhaps they see a DoS-burst?). Finally, ping 0 ms does not sound very reliable either. I'd assume 2-3 ms to be a best reading in the optimal conditions.

I've been running with this connection for a couple days only, but the assumption is that the uptimes it can keep are amazing. An ADSL-connection is pretty stable, but a fiber should be the rock-solid way to go, that's what I'm expecting from it.

Update Oct 2014:

Speedtest.net indeed goes beyond 100 Mbit/s:

My home Linux box is always on and to make sure it stays on I have an uninterruptible power supply for it. APC is very well supported in Linux by open-source apcupsd. Pretty much all other UPSes are supported by NUT, but for some strange reason APC has a separate project.

Update 20th May 2018: There is a new post about APC UPS batteries here.

Couple days ago the UPS started to beep. My house had electricity and there was no apparent fault. Except that I got an e-mail from apcupsd "UPS battery needs changing NOW". Aow crap! The batteries had reached their end of life. I confirmed the status with apcaccess and got status of:
STATUS : ONLINE REPLACEBATT NOBATT

Every 12 hours, the UPS releases a burst of beeps and I find that very annoying. It was time to go shopping for new batteries. Luckily my unit uses Replacement Battery Cartridge #7, which is popular and generally well available and the price ~200 € isn't too bad. The next thing is to get the old ones out and new ones in. APC user's manual says that battery pack is hot-swappable, so it should be an easy thing to do. Apparently the first thing to do is remove the front cover:

It has nice holes on the sides. I guess the idea is to put your fingers into them an pull hard.

When the front cover is loose, a ribbon-cable and a metal cover is revaled.

There are two phillips-head screws to hold the metal cover in place:

When the metal cover is removed, the battery pack is visible:

There is a plastic tab at the bottom. I guess it is there, so that batteries can be pulled out. Now that the metal cover is removed, the batteries are not attached to anything:

The final thing to do is to disconnect the battery pack:

Now the UPS keeps beeping a lot. It is annoyed by the fact, that it cannot find a battery. Since I don't have any original APC software on my computer I found out that the audible beep can be silenced. First make sure that the apcupsd is not running:
systemctl stop apcupsd.service

Now the apctest can be used to change any of the UPS-parameters:

Current alarm setting: ENABLED
Press...
 E to Enable alarms
 D to Disable alarms
 Q to Quit with no changes
Your choice: Select function: d

New alarm setting: DISABLED

Now there is the blissful silence. It is much nicer to operate with the new battery pack.

Obviously the idea is to reverse the instruction. Connect the new battery, slide it in and tighten the screws and attach the front cover back.

I guess, the new battery should last at least 3 years before I'll be getting a completely new UPS. There simply is no point in running a really old UPS with brand new batteries. I guess the UPS technology will still evolve so that a new tech is required after half a decade.

Today, this tuesday, is the last time Windows XP gets security updates from Microsoft. Apparently Dutch and UK governments are willing to pay seven figure sums per year to keep their XPs running, but the rest of us, anything smaller than a government we don't get to have those. Last autumn I visited Windows 8.1 release in Helsinki and there a Microsoft MVP said "Microsoft is not that evil company, they just might release something really critical if it comes down to that". There was some chuckling in the crowd. Anyway, very interesting things will happen to XP, see the CVE-list for non-fixed flaws.

In Finnish media, the XP has gotten a lot of media coverage all year. I guess it got to the point of scaring regular users in the national TV. This I figured when my mother called me about her Windows 7. The another thing was at my neighbor's computer. She has an old XP-box with really poor specs. She asked for my help, but after initial assessment there was nothing I could do with her old computer. I happened to have an old Dell OptiPlex GX260 desktop computer with steroids, a SSD-drive in a ATA-to-SATA -adapter. I was about to do the decent thing and comply with EU 2002/96/EC directive, aka. throw the electronic junk where all electronic junk ends up at. The computer has only 512 MiB memory, but given the 2,0 GHz Pentium 4 CPU, it runs 2009 released Windows 7 in a reasonable acceptable manner. The best part for my neighbor was, that I promised to donate the hardware free of charge. It was only a matter of getting a license key for Windows 7.

My old OptiPlex booted from installation DVD without problems, I must say I was amazed about that. Any old low-quality CD/DVD-drive typically has issues with dust in the lens and the read head eventually deteriorates to the point, that the drive refuses to read anything. Anyway, the Windows 7 installer found the SATA-connected SSD-drive, the installer copied the files, booted for the initial Out-Of-the-Box-Experience. Everything seemed to be ok, I had network connectivity and even some sound.

What every legacy PC does after install is, that the display resolution is something unbelievable. This case I had a VGA 640x480. It sure looked nice on my 22" LCD-screen!
The thing is: no W7 drivers for my Dell. It seems to have a built-in Intel 82845G graphics adapter in it. The Dell support knows about my machine and the display driver in its Download Center, but the latest supported OS they have is Windows XP. WDDM driver model was introduced in Vista and XDDM drivers was the last one Intel ever did for 82845G. This was confirmed in Microsoft TechNet's Windows 7 IT Pro forums discussion How do I get Windows 7 Graphic driver for the Intel 82845G Graphics Controller?

Lucky for me, somebody had posted a link to another article For Older Hardware to Run on Windows 7 How to Install intel 82845G graphics driver on Window 7, and there was a solution for my exact problem. I didn't realize that it was possible to still use XDDM drivers, but it is possible. In device manager, there is a Add Legacy hardware:

I took the 82845G driver package 14.10.3, unzipped it and Windows 2000 XDDM driver installed. After rebooting the Windows 7, everything was ok. The driver actually claims it can go up to 2048x1536, but given the analog VGA-connector I chose not to go that far.

Finally, I installed Microsoft Security Essentials into it and I was done. My neighbor had a nice "new" computer till year 2020. I'm wishing people would upgrade before that, but knowing that doing nothing is always the preferred action on non-hackers, so plenty of people will be taken by surprise when Windows 7 updates run out.

Us server guys are becoming a rare breed. Any server-related tasks can be outsourced to any free-of-charge cloud service provider. One very good example of that is e-mail, nobody runs their own mail server nowadays. Companies are using external services and any regular Joe and Jane have gone for Gmail years ago. However, once in a while something funny happens and people want a NSA-free e-mail account.

The fact is that every Linux-installation has a mail server installed and running in it. The purpose for the mail server is to deliver local in-server mail to user(s), also depending on your Internet-connection it may be possible to send outgoing mail to the wild wild Net. Most ISPs block this due to excessive spamming from consumer's computers.

Setting up a receiving Postfix MTA is outside of this blog post, but my idea is to present you configuration help to:

1. Configure Postfix to tunnel outgoing e-mail via you ISP's SMTP
2. (optional) Redirect root's e-mail to an external mailbox
3. (optional) Increase mail transport security by using TLS encryption for e-mail
   

So ... here goes.

Configure Postfix to tunnel outgoing e-mail via you ISP's SMTP

To fight spam most (all reasonable) ISPs have blocked outgoing TCP/25 traffic. This very effectively makes your computer not being able to inject new e-mails into receiving servers. Because of this, for example Google instructs users to use TCP-ports 465 or 587 instead, see their setup instructions.

For a mail server (like your Postfix), that is not a solution. Your box must be able to deliver e-mail to any server's TCP/25. All ISPs I've ever seen share a SMTP-server for their customers. The idea is to route all your external e-mail to that server, it will relay the e-mail to the final destination. Remember, that as a spam prevention measure, the amount of mail you can send via ISP's SMTP is limited. For example my ISP has a 50 e-mails per hour policy. It simply refuses to serve any excess requests based on IP-address of the sender.

The subject of routing outgoing e-mail is covered (among many others) in this article with title Configuring postfix to forward all email to a smtp gateway. All you have to do is add:
transport_maps = hash:/etc/postfix/transport
into your Postfix's main.cf. Typically there is a transport-file, but it does not contain your ISP's configuration in it.

Example:
My ISP TeliaSonera Finland has a SMTP running @ mail.inet.fi. Initially I had following line in my transport-file:
*         smtp:mail.inet.fi

But it didn't work! Looking into source code src/trivial-rewrite/resolve.c reveals that Postfix keeps resolving the address via MX-record. The correct one will be:
*         smtp:195.156.147.15

This setting will skip any resolving of the given address and use the given IP-address as-is.

Test the setup by sending e-mail to one of your own external addresses. It can be achieved by running something like this:
date | mail -s "Testing outgoing mail" test@user.at.somewhere

Confirm the functionality from Postfix's log, it should read something like this:

postfix/pickup[12869]: D13F8209AF: uid=0 from=<user>
postfix/cleanup[13427]: D13F8209AF: message-id=<20140407161546.D13F8209AF@my.linux.box>
postfix/qmgr[2185]: D13F8209AF: from=<user@my.linux.box>, size=482, nrcpt=1 (queue active)
postfix/smtp[13429]: D13F8209AF: to=<test@user.at.somewhere>, relay=195.156.147.15[195.156.147.15]:25, delay=0.35, delays=0.06/0.01/0.04/0.24, dsn=2.0.0, status=sent (250 <529734CF0ADA3B46> Mail accepted)
postfix/qmgr[2185]: D13F8209AF: removed

It clearly says "Mail accepted" and Postfix's queue manager eventually removes the outgoing mail from outgoing queue. Remember to confirm, that the mail landed to the external mailbox.

Redirect root's e-mail to an external mailbox

A good starting point is to look at /etc/aliases. For example OpenSuse has this in it:

# It is probably best to not work as user root and redirect all
# email to "root" to the address of a HUMAN who deals with this
# system's problems. Then you don't have to check for important
# email too often on the root account.

So, I put this into my aliases:

root:           test@user.at.somewhere

There is a catch ... Having that in /etc/aliases won't work for your system's internal e-mails. Now that your box is not a receiving mail server, all of you mail is internal. You can confirm the non-functionality by:
date | mail -s "Testing outgoing root mail" root

Your maillog will read something like in the previous example. Mail will be routed to your ISP's SMTP, but the problem is, that the e-mail address is wrong. It will read root@your.server.name, your ISP does not have a clue what to do with such a mail, and it will bounce back. Now that your server cannot receive mail, the bounce will be dropped and is lost.

There is a fix for that. The two articles of Rewriting to address on postfix local aliases and Postfix masquerading or changing outgoing SMTP email or mail address will contain clues how to do it. I added following line into my main.cf:
smtp_generic_maps = hash:/etc/postfix/generic

The /etc/postfix/generic will read:
root@your.server.name        test@user.at.somewhere

Postmap the transport-file, reload the postfix-service and test again. Now Postfix will re-write the outgoing e-mail properly as planned. The re-write can not be confirmed from the maillog, it will display the original root@your.server.name in there. However, on the receiving end the e-mail address will be correct.

Increase mail transport security by using TLS encryption for e-mail

The last item on my checklist is to start encrypting the mail. Note that this is pointless if your ISP does not support encryption. If it does and your Postfix is not configured to use encryption, you will get a lot of "warning: no entropy for TLS key generation: disabling TLS support" in your maillog.

As a prerequisite, you will need a SSL-certificate. Any certificate will do, even a crappy self-signed one. I'd never recommend using self-signed certificates, but if you're lazy and don't want to get a free one from the net, go for the path of least resistance. This is what I have in main.cf:

# SSL/TLS
# SMTP (sending)
smtp_tls_security_level = may
smtp_tls_key_file = /etc/ssl/private/the.certificate.key
smtp_tls_cert_file = /etc/ssl/certs/the.certificate.cer
smtp_tls_CApath = /etc/ssl/certs

To confirm that TLS is being used will look like this on received e-mails headers:

Received: from mail.inet.fi ([2001:15d8:172::]) by
 mx.google.com with ESMTPS id 1si12730620lam.174.2014.04.07.09.57.37 for
 <test@user.at.somewhere> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256
 bits=128/128); Mon, 07 Apr 2014 09:57:37 -0700 (PDT)
Received: from your.server.name ([172.16.141.138])
 (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested) by mail.inet.fi (Postfix) with
 ESMTPS id E75004355F for <test@user.at.somewhere>; Mon,  7 Apr 2014 19:57:35
 +0300 (EEST)

Notice how both servers specify the TLS cipher used. In this case Google's server uses only 128-bit encryption.

Note:
You don't need to enable tlsmgr in master.cf for any this to work. I've seen incorrect instructions about that. To repeat: For sending TLS-encrypted e-mail having tlsmgr is not necessary.

An active contributor for this blog, Mr. nos_com71 was kind enough to notify me about a firmware he found. It is from Polkomtel, a Polish telco. You can download the package from this link @ Norton Zone cloud. I had issues with the download, but using a different browser on another machine solved it for me.

I didn't install the firmware into my s-12, but as usual, I extracted it and confirmed its contents and version of V100R001C69SP103, which is quite new. In the Bjørn Grønli's spreadsheet the newest one he found is a SP102, but this Polish one seems to be a notch newer.

If any of you test this one out, please tell us about it.

One day I came back to my computer and saw a firewall notice about netsession_win.exe requesting access to listen UDP-requests.

Ok, I thought, that happens sometimes. An application needs permission to access The Net. This time it was a permission to receive traffic. Wait a minute! I don't remember installing anything that would require building a server on my box.

Apparently I'm not alone with my question, Mr. Scott Hanselman at CSI: My Computer - What is netsession_win.exe from Akamai and how did it get on my system? is pondering the same issue. He chose to keep it running, I chose not to.

Reasoning:

• I confirmed the facts from Mr. Hanselman blog post: the Akamai signature in the binary is valid, at least it looks like a valid one to me. This alone is definitely not a reason to kill the app.
  
• I don't know any purpose for such an application.
  
• A server binary is located at my %LOCALAPPDATA%, definitely not the place for a piece of server software to be running from.
• Anybody who installed the application and made it run did not ask for my permission for doing so.
• The application will run on each login based on a registry setting placed into HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run Mr. Hanselman located a service in his computer. My computer did not have that. I still don't like unknown applications to run all the time.
• It does not feel legit to me. All these combined make the application shady and it gives me chills.
  

Guys at Akamai:
This is not the way to do it! Revise your policy of putting spyware into people's computers.

I'm in the IRC 24/7. For the "idling" on my favorite channel I have used EPIC4 for a very long time. Couple of decades, in fact. The project is in a bad shape. Anything IRC-related is. For the record: I'll be the last dinosaur to punch the clock for the last time and turn off the lights when I notice that I'll be idling there alone. It won't come for another couple of decades, though.

Based on epicsol.org website, there is actually nobody to contact about EPIC4 bugs, no mailing list anymore (last one died 2009) nor any contact e-mail or a form. So, there literally is nobody who I could notify about anything. Writing on my own blog about it is pretty much all I can do for the project.

Back to business... My Linux-box is a mail-host and whenever something new arrives, it is really nice to get notified about that while doing absolutely nothing on the channel. However, when I stopped using mbox for storing the mail in my box, my favorite IRC-client stopped doing the notifying. It didn't not have the code for the more effective Maildir format. It does now.

My stuff is at http://opensource.hqcodeshop.com/EPIC/4/
It contains 64-bit RPM for Fedora 20 and the .src.rpm if you want to do the build by yourself. Note that my version is the latest EPIC4 2.10.4, not the Fedora-boxed 2.10.2.

To start using the Maildir-mode, say:
set mail_type maildir
in your .ircrc-file. The thing relies on $MAIL-environment variable to know where your mail is stored at.

Update 31th March 2014:
I actually got hold of Mr. Jeremy Nelson, the author or EPIC4 and EPIC5. He took my patch and said that it will be released in 2.10.5. We had a brief conversation in #epic-channel and he also said, that he is about to publish the EPIC5 project in Github.

My patch (epic4-2.10.1-maildir.patch) is as follows:

diff -aur epic4-2.10.1/include/config.h epic4-2.10.1.JT/include/config.h
--- epic4-2.10.1/include/config.h    2006-06-18 20:33:51.000000000 +0300
+++ epic4-2.10.1.JT/include/config.h    2012-08-30 13:22:20.319515332 +0300
@@ -412,7 +412,7 @@
 #define DEFAULT_LOGFILE "irc.log"
 #define DEFAULT_MAIL 2
 #define DEFAULT_MAIL_INTERVAL 60
-/ #define DEFAULT_MAIL_TYPE "mbox" /
+#define DEFAULT_MAIL_TYPE "mbox"
 #define DEFAULT_MAX_RECONNECTS 4
 #define DEFAULT_METRIC_TIME 0
 #define DEFAULT_MODE_STRIPPER 0
diff -aur epic4-2.10.1/include/vars.h epic4-2.10.1.JT/include/vars.h
--- epic4-2.10.1/include/vars.h    2006-06-18 20:33:51.000000000 +0300
+++ epic4-2.10.1.JT/include/vars.h    2012-08-30 13:24:19.719723226 +0300
@@ -93,7 +93,7 @@
     LOG_REWRITE_VAR,
     MAIL_VAR,
     MAIL_INTERVAL_VAR,
-    / MAIL_TYPE_VAR, /
+    MAIL_TYPE_VAR,
     MANGLE_INBOUND_VAR,
     MANGLE_LOGFILES_VAR,
     MANGLE_OUTBOUND_VAR,
diff -aur epic4-2.10.1/source/mail.c epic4-2.10.1.JT/source/mail.c
--- epic4-2.10.1/source/mail.c    2006-06-18 20:33:51.000000000 +0300
+++ epic4-2.10.1.JT/source/mail.c    2012-08-30 15:25:05.568641118 +0300
@@ -353,7 +353,7 @@
         return 0;
     }

-    maildir_path = malloc_strdup(tmp_maildir_path);
+    maildir_path = malloc_strdup(maildir);
     maildir_last_changed = -1;
     return 1;
 }
@@ -375,13 +375,29 @@
 {
     int    count = 0;
     DIR     dir;
+    Filename     tmp_maildir_path;
+    struct dirent*    dir_data;

-    if ((dir = opendir(maildir_path)))
+    strlcpy(tmp_maildir_path, maildir_path, sizeof(Filename));
+    strlcat(tmp_maildir_path, "/new", sizeof(Filename));
+    if ((dir = opendir(tmp_maildir_path)))
     {
-        while (readdir(dir) != NULL)
-            count++;
+        while ((dir_data = readdir(dir)) != NULL) {
+            if (dir_data->d_name[0] != '.')
+                count++;
+        }
+        closedir(dir);
+    }
+
+    strlcpy(tmp_maildir_path, maildir_path, sizeof(Filename));
+    strlcat(tmp_maildir_path, "/cur", sizeof(Filename));
+    if ((dir = opendir(tmp_maildir_path)))
+    {
+        while ((dir_data = readdir(dir)) != NULL) {
+            if (dir_data->d_name[0] != '.')
+                count++;
+        }
         closedir(dir);
-        count -= 2;    / Don't count . or .. /
     }

     return count;
@@ -398,6 +414,7 @@
 {
     Stat    sb;
     Stat     stat_buf;
+    Filename     tmp_maildir_path;

     if (ptr)
         stat_buf = (Stat )ptr;
@@ -408,8 +425,11 @@
         if (!init_maildir_checking())
             return 0;        / Can't find maildir /

+    strlcpy(tmp_maildir_path, maildir_path, sizeof(Filename));
+    strlcat(tmp_maildir_path, "/new", sizeof(Filename));
+
     / If there is no mailbox, there is no mail! /
-    if (stat(maildir_path, stat_buf) == -1)
+    if (stat(tmp_maildir_path, stat_buf) == -1)
         return 0;

     /
@@ -547,6 +567,10 @@
     update_mail_level2_maildir();
     if (status == 2)
     {
+        Filename     tmp_maildir_path;
+        strlcpy(tmp_maildir_path, maildir_path, sizeof(Filename));
+        strlcat(tmp_maildir_path, "/new", sizeof(Filename));
+
         / XXX Ew.  Evil. Gross. /
         ts.actime = stat_buf.st_atime;
         ts.modtime = stat_buf.st_mtime;
@@ -642,6 +666,27 @@

 void    set_mail_type (const void stuff)
 {
-    / EPIC4 cannot switch mailbox types (yet) /
+    const char     value;
+    struct mail_checker new_checker;
+    char    old_mailval[16];
+
+    value = (const char )stuff;
+
+    if (value == NULL)
+        new_checker = NULL;
+    else if (!my_stricmp(value, "MBOX"))
+        new_checker = &mail_types[0];
+    else if (!my_stricmp(value, "MAILDIR"))
+        new_checker = &mail_types[1];
+    else
+    {
+        say("/SET MAIL_TYPE must be MBOX or MAILDIR.");
+        return;
+    }
+
+    snprintf(old_mailval, sizeof(old_mailval), "%d", get_int_var(MAIL_VAR));
+    set_var_value(MAIL_VAR, zero);
+    checkmail = new_checker;
+    set_var_value(MAIL_VAR, old_mailval);
 }

diff -aur epic4-2.10.1/source/vars.c epic4-2.10.1.JT/source/vars.c
--- epic4-2.10.1/source/vars.c    2008-03-17 05:42:46.000000000 +0200
+++ epic4-2.10.1.JT/source/vars.c    2012-08-30 13:14:54.801014647 +0300
@@ -194,7 +194,7 @@
     { "LOG_REWRITE",        STR_TYPE_VAR,    0, 0, NULL, NULL, 0, 0 },
     { "MAIL",            INT_TYPE_VAR,    DEFAULT_MAIL, 0, NULL, set_mail, 0, 0 },
     { "MAIL_INTERVAL",        INT_TYPE_VAR,    DEFAULT_MAIL_INTERVAL, 0, NULL, set_mail_interval, 0, 0 },
-    / { "MAIL_TYPE",            STR_TYPE_VAR,    0, 0, NULL, set_mail_type, 0, 0 }, /
+    { "MAIL_TYPE",            STR_TYPE_VAR,    0, 0, NULL, set_mail_type, 0, 0 },
     { "MANGLE_INBOUND",        STR_TYPE_VAR,    0, 0, NULL, set_mangle_inbound, 0, 0 },
     { "MANGLE_LOGFILES",        STR_TYPE_VAR,    0, 0, NULL, set_mangle_logfiles, 0, 0 },
     { "MANGLE_OUTBOUND",        STR_TYPE_VAR,    0, 0, NULL, set_mangle_outbound, 0, 0 },
@@ -350,7 +350,7 @@
     set_string_var(HIGHLIGHT_CHAR_VAR, DEFAULT_HIGHLIGHT_CHAR);
     set_string_var(LASTLOG_LEVEL_VAR, DEFAULT_LASTLOG_LEVEL);
     set_string_var(LOG_REWRITE_VAR, NULL);
-    / set_string_var(MAIL_TYPE_VAR, DEFAULT_MAIL_TYPE); /
+    set_string_var(MAIL_TYPE_VAR, DEFAULT_MAIL_TYPE);
     set_string_var(MANGLE_INBOUND_VAR, NULL);
     set_string_var(MANGLE_LOGFILES_VAR, NULL);
     set_string_var(MANGLE_OUTBOUND_VAR, NULL);

I don't have a Windows-domain at home, so the Internet time client (NTP) is on relaxed settings. Your typical Microsoft documentation about NTP will have phrases like: "The default value for domain members is 10. The default value for stand-alone clients and servers is 15" in it. So, it really makes a difference if the computer is in a domain or not.

It is a well established fact, that the hardware clock on your computer is quite inaccurate. On a modern computer, there is no point in using expensive hardware to make the clock run smoothly, you can always set the time from a reliable clock source from Internet. That's what the NTP was made decades ago, to make sure that everybody has the same time in their boxes.

The real question here is: Why does my Windows 7 clock skew so much? I have set up the internet time, but it still is inaccurate.

As a Linux-guy I love doing my stuff on the command-line. To question about the clock skew I'll do:

w32tm /monitor /computers:-the-NTP-server-

... and it will respond something like NTP: -0.7900288s offset from local clock. So it's almost a second behind the accurate time source.

The initial fix is easy, force it to get the accurate time from the configured time server:

w32tm /resync

But I cannot be doing that all the time. Why cannot the computer maintain a well disciplined clock like I configured it to do? There must be something fishy about that.

A command like:

w32tm /query /status

will say that Poll Interval: 10 (1024s), but I cannot confirm that requests for every 1024 seconds (or less). It simply does not do that. There is a TechNet article with the title of Windows Time Service Tools and Settings describing a registry setting of MaxPollInterval located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config, but that has no real relevance here. The update mechanism does not obey that setting.

However, Microsoft's knowledge base article 884776 titled How to configure the Windows Time service against a large time offset gives more insight about the update interval. It describes a registry value of SpecialPollInterval located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient for manual peers. I'm guessing I have a manual peer, whatever that means. I don't have a domain and I did set the server manually. The original value seems to be 604800 seconds, making that 7 days or a week. Whoa! Way too much for me.

While sniffing the network traffic with the Wireshark, indeed I can confirm that putting a small value into that will make my Windows 7 to poll on that interval. I put 10 seconds there, and it seems to work. For any real life scenario 10 seconds to update time is ridiculous. For a computer on a domain, the value is 3600 seconds, making the updates for every hour. I chose to use that.

Please note that changing the registry value requires a restart for the Windows time client. From a command line a:

net stop w32time
net start w32time

will do the trick and start using the newly set registry value. You can also restart the Windows Time service from GUI.

Now my computer's time seems to stick with a reasonable accuracy. I'm still considering of purchasing a GPS-time box of my own. They seem to be quite expensive, though.