Microsoft rulez, after all (MS08-001)

More than two years ago, I was writing the first No Fills TCP RFC draft.
At that time, I wondered if one of the possible features of this new protocol could be a creative use of the RST flag (see section 4.1.1), which I mostly inteded for those Windows system administrators who had to work with a large number of machines on the same subnet.

In the version that hit the web on April, 2006 I wrote (emphasis added):

More aggressive implementation options are being considered, but some are not backward compatible despite being very useful:

  • last hop router receiving a NFRST packet SHOULD rewrite the destination address with the broadcast address of the nework of the destination host. This should achieve the effect of terminating ALL current connections over the network with the sender host.
  • the most extreme semantic of the NFRST flag would be “Reboot”: any networked host (computer, router, …) which receives such a packet MUST schedule an orderly reboot. Without any doubt this would solve many remote administration nightmares.

It is not by chance that we choose local broadcast over a multicast group as the destination of the last hop packet: most of the machines which will benefit the most of this innovative method of remote administration will be running an OS that pioneered the use of broadcast for the most inventive purposes.

But — I have to admit it — MS08-001 came in as a big surprise: Microsoft had thought better, implementing a whole sled of reboot functionalities and leaving us in the dark for two whole years!
Granted, the most exciting features (remote management and reboot) are present — as expected — only in the most recent version of its operating systems (XP, 2003, Vista), but we are used to it, aren’t we?

Please note that those with mixed XP/2003/Vista networks have to choose IGMPv3 management, while Vista-only network administrators can opt for either IGMPv3 or MLDv2 (aka CVE-2007-0069).
Fun does not stop here! Windows 2000 administrators are not left outside alone, there’s the handy RDP management (aka CVE-2007-0066) suitable for the not-so-recent enterprise.

PATCH NOW! :-)

I’m not commenting on the time frame, even if I’d like to, because it’s hard for me to determine how long these have been known but not fixed. I note that that CVE-2007-0059 was the Apple Quicktime bug discovered during the MOAB and reported on January 3, 2007 and that CVE-2007-0075 is an AspBB Remote Password Disclosure which came out on Bugtraq more or less January 4, 2007.
I have no idea if this proves anything at all. I know that CVE numbers get handed out on a first-come first-served basis, and nothing more.

Sun IPX rising!

Warning: this is actually an old post I had forgotten.
I decided to publish it as a thank you note to radrob, for the precious gift of an NVRAM chip for my smallest baby… :-)
If you’re interested in what an NVRAM/IDPROM chip is, this is the best resource on the ‘net, imho.
The chips came from here.

ok banner
SPARCstation IPX, No Keyboard
ROM Rev. 2.9, 64 MB memory installed, Serial #16777215.
Ethernet address ff:ff:ff:ff:ff:ff, Host ID: ffffffff.

WARNING: Unable to determine keyboard type
WARNING: TOD Oscillator NOT Running, Kickstart in Progress ... Incorrect configuration checksum

Setting diag-switch? NVRAM parameter to true

ok banner
SPARCstation IPX, No Keyboard
ROM Rev. 2.9, 64 MB memory installed, Serial #0.
Ethernet address 0:0:0:0:0:0, Host ID: 00000000.
ok .idprom
Format/Type: 0 0 Ethernet: 0 0 0 0 0 0 Date: 0 0 0 0
Serial: 0 0 0 Checksum: 1 Reserved: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

ok 8 0 20 ba dd ec c0ffee mkpl [CTRL+D][CTRL+R]
ok .idprom
Format/Type: 1 57 Ethernet: 8 0 20 ba dd ec Date: 0 0 0 0
Serial: c0 ff ee Checksum: 24 Reserved: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ok banner
SPARCstation IPX, No Keyboard
ROM Rev. 2.9, 64 MB memory installed, Serial #12648430.
Ethernet address 8:0:20:ba:dd:ec, Host ID: 57c0ffee.
ok boot disk1
Boot device: /sbus/esp@0,800000/sd@1,0 File and args:
>> NetBSD/sparc Secondary Boot, Revision 1.14
>> (root@amd, Sun Nov 21 12:38:27 CET 2004)

# uname -a
NetBSD ipx 2.0_RC5 NetBSD 2.0_RC5 (GENERIC) #1: Wed Nov 17 01:01:24 CET 2004
root@amd:/root/netbsd2/src/sys/arch/sparc/compile/obj/GENERIC sparc

I know, it’s not a current version (cross compiled on linux or netbsd, I don’t remember), but good enough for this little beast. Whoknows if I can cross compile on OSX, too. Uhmm…

In other news, I upgraded WP to 2.3.1. 70-something days are enough after a major release, I hope.

*UPDATE* 20071206: Changed radrob site (newer, faster, better, updated!), added link to maxim-ic

Ahah, sigh (Tiscali smtp internal relay sucks)


beepbeep:~ zen$ telnet smtp.tiscali.it 25
Trying 213.205.33.13...
Connected to smtp.tiscali.it.
Escape character is '^]'.
421 averell.tiscali.it Service not available - too many connections

beepbeep:~ zen$ telnet smtp.tiscali.it 25
Trying 213.205.33.13...
Connected to smtp.tiscali.it.
Escape character is '^]'.
220 joe.tiscali.it ESMTP Service (7.3.122) ready

That is, the smtp relay for the entire tiscali network in Italy is a load balancer with ip address 213.205.33.13, which balances over two hosts

  • averell.tiscali.it has address 213.205.33.55
  • joe.tiscali.it has address 213.205.33.54

Anyway, it looks like the balancer has been configured with a dumb round robin (and with limits greater than those configured on the backend hosts). Please note that I’m connecting always from the same IP.
Net result: the balancer is useless. Half of the connections to the service get reset because of a single overloaded host. An innovative way to rate-limit the use of a service.

I’m writing this post waiting for my mails to get through.
Being sick and locked inside home makes me aggressive, did you notice?

MySQL and low memory(?), help needed

Dear lazyweb,
as you may have seen sometimes the SQL backend of this blog dies.
I believe this is caused by the amount of ram available on the machine, but feel free to teach me.
Right now mysql uses

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
23902 mysql 18 0 42M 28M sigwait 0:12 0.83% 0.83% mysqld

I tried to optimize it a little, but had small to none real effect using

query_cache_type = 1
query_cache_size = 1M
query_cache_limit = 1M
thread_cache_size = 3
tmp_table_size = 50000000
key_buffer_size = 6291456

Given that all I have are 192Megs of ram, and the machine is performing happiliy if it weren’t for the DB dying, is there anything I can do? (“Move over to a bigger iron” is not a valid answer).
I think I’m not using InnoDB, and that all tables are MyISAM – if that makes a difference.
I’m on 5.0.2x train already.

In other news, I’m @home in Bologna and I have fever.
It won’t be fun to reach Milan tonight or tomorrow morning. :|

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close