Thursday, 23 January 2014

How deep is your FUD?

When as executive from Microsoft said, "You can just google me, ah um Bing me." There was much chuckling. At the time it was said that Bing was not making money and it was suggested in some publications that they would be happy for someone else to take it off their hands.

Was this a natural slip of the tongue?

If you don't have enough material for your conspiracy theories then try this idea on for size:

"It was a corporate equivalent of a military surgical strike. If Google becomes google in law then their trademark becomes worthless."

Just a moment? What are you on about? (Would be a reasonable question.)

Well, (I would say with deliberate pause) if it can be shown that a trademark has become part of the normal term of a man-in-the-street then it is watered down like a sandcastle on a beach. Just as band-aid, in the USA become the default term for a self-adhesive medical strip and  Hoover, (the vacuum cleaner manufacturer) became the standard word for that item in the UK, if google replaces the word search on the Web and for those that use the Internet, then Google will have hit that interesting point in law that creates a sort of they-should-have-already-made-enough-money point in its corporate life cycle.

If you want to season that plate with some cynicism, (and it is Monday after all) are mistakes and apologies the current state-of-the-art in the corporate PR arsenal?

Monday, 13 January 2014

Outlook 2013 vs Exim 4

I had problems getting Outlook 2013 to play TLS with my exim servers. The solution seemed to be to set Outlook's encryption to 'Auto' and use port 587 (a NON TLS port).  I have both PLAIN and LOGIN auth but Outlook uses the latter. If you are still using a flat auth file that uses the CRYPT hash then there is an example line for you, but I mostly authenticate against a database,
(so that changes don't have to be rolled out in batches.)


exim config snippit:

tls_advertise_hosts = *
daemon_smtp_ports = 25 : 465 : 587
tls_on_connect_ports = 465 : 6465
# some ISPs filter 25 and 465 to their own SMTP servers for 'simplicity' hence I have  6465 for customers with that affliction.


MYSQL_AUTHPLAIN=SELECT  im_server FROM imap,domains WHERE imap.im_doid = domains.do_id and concat(imap.im_userid,'@',domains.do_name) = '$2' ) AND ( im_auth='${hmac{md5}{$3}{$3}}' || im_auth=encrypt('$3',im_auth) || im_auth='${sha1:$3}' )
# transitioning from encrypt to sha1 and merging in an hmac_md5 config

MYSQL_AUTHLOGIN=SELECT  im_server FROM imap,domains WHERE imap.im_doid = domains.do_id and concat(imap.im_userid,'@',domains.do_name) = '$1' AND (  im_auth=encrypt('$2',im_auth) || im_auth='${sha1:$2}' )

begin authenticators
# $1 is the old string for $auth1; $2 = $auth2; $auth3 = $3

plain:
  driver = plaintext
  public_name = PLAIN
  server_condition = ${lookup mysql{MYSQL_AUTHPLAIN}{1}fail}
  server_advertise_condition = ${if def:tls_cipher }
  server_set_id = $2
 
login:
 driver = plaintext
 public_name = LOGIN
 server_prompts = "Username:: : Password::"
 #  server_condition = ${lookup mysql{MYSQL_AUTHLOGIN}{1}fail}
 server_condition = "${if crypteq{$auth2}{${extract{1}{:}{${lookup{$auth1}lsearch{/etc/exim/passwd}{$value}{*:*}}}}}{1}{0}}"
 server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
 server_set_id = $1

 

Example mysql schema, with domains in one table and imap, (and smtp authentication in im_auth) in another:

CREATE TABLE `domains` (
  `do_id` int(255) NOT NULL AUTO_INCREMENT,
  `do_name` varchar(255) NOT NULL,
  `do_status` enum('disabled','suspended','enabled','migrating out','migrating in','registering','desired','disputed','remote') NOT NULL DEFAULT 'remote',
  `do_added` datetime NOT NULL,
  `do_acid` int(255) NOT NULL COMMENT "account id - other table",
  `do_group` int(255) DEFAULT NULL,
  `do_peid` int(255) DEFAULT '0' COMMENT "people ID",
  `do_location` varchar(255) DEFAULT NULL,
  `do_masters` varchar(255) DEFAULT NULL COMMENT 'a ; delimited list of ip addresses',
  PRIMARY KEY (`do_id`)
) ENGINE=MyISAM AUTO_INCREMENT=16 DEFAULT CHARSET=latin1 COMMENT='Domains'


CREATE TABLE `imap` (
  `im_id` int(255) NOT NULL AUTO_INCREMENT,
  `im_userid` varchar(128) NOT NULL COMMENT 'the bit before the at sign',
  `im_doid` int(255) NOT NULL COMMENT 'link to domains.do_id',
  `im_passwd` varchar(74) DEFAULT NULL COMMENT '{HASH}string e.g. {SHA1}shy75adsgf=',
  `im_home` varchar(255) NOT NULL COMMENT 'explicit path on im_server',
  `im_uid` int(11) NOT NULL COMMENT 'probably 8 (mail) though for shell users set it to their uid',
  `im_gid` int(11) NOT NULL COMMENT 'probably 12 (mail) or 8 on some systems',
  `im_server` varchar(128) DEFAULT NULL COMMENT 'mostly this will be the localhost or hostname',
  `im_quota` int(255) DEFAULT NULL COMMENT 'In Megs: 2 petabyte limit',
  `im_peid` int(255) DEFAULT NULL COMMENT 'links to people table',
  `im_auth` varchar(255) DEFAULT NULL COMMENT 'exim authenticates from this if it does not understand im_passwd - useful for migrating from MD5 to SHA256',
  `im_mode` char(4) DEFAULT '0640' COMMENT 'smallint seems wrong',
  `im_dir_mode` char(4) DEFAULT NULL COMMENT 'exim file and dir modes',
  `im_last_seen` datetime DEFAULT '0000-00-00 00:00:00' COMMENT 'the last SMTP,IMAP',
  PRIMARY KEY (`im_id`),
  UNIQUE KEY `im_row` (`im_userid`,`im_doid`)
) ENGINE=MyISAM AUTO_INCREMENT=8 DEFAULT CHARSET=latin1 COMMENT='imap account'

# I've never had to add a NULL imap row to enable SMTP, but that is perfectly possible.

Tuesday, 7 January 2014

SFR is rubbish at IP networks

That title should get someone's attention. Why such a deliberately childish title? Because I could not easily find a "Network Status" page or a "report network problems" page. One would have been able to reassure me that the issue is being dealt with and the other would have let me, (someone that knows a little about IP networks) to provide useful information.

Talking of which: (notice the huge jump between hop 04 and 05.

03. 82.186.96.84.rev.sfr.net        24.0%   146   27.2  57.2  24.6 640.1  88.5
04. 84.96.179.142                   25.5%   146   25.6  72.8  24.4 585.3 100.4
05. 37.244.5.109.rev.sfr.net        26.9%   146  5608. 969.8  26.3 7250. 2008.
06. 106.61.6.109.rev.sfr.net        30.3%   146  5768. 868.6  28.6 7180. 1863.
07. 70.61.6.109.rev.sfr.net         28.3%   146  6026. 866.7  33.2 7364. 1866.
08. 237.29.3.109.rev.sfr.net        26.4%   145  5782. 1018.  34.5 7118. 2045.
09. ix-28-0.tcore1.PVU-Paris.as6453 28.5%   145  5506. 726.2  32.2 7155. 1693.
10. 80.231.154.69                   29.2%   145  5745. 734.4  32.6 6676. 1685.

I'm on a friends ADSL line and this has been happening on and off for at least a week. I'll add more traceroutes each time I remember. I can say that the last time I was here the house was using Darty, (which used someone else's network) and that was much better. SFR seems to be good at mobile but crap at home networks, (from one data point between 2013 and the start of 2014).

UPDATE:  2014-01-16 After reporting the problem, (they seemed to be able to instantly fix it) and mentioning it to a cold-caller trying to sell anti-virus on behalf of SFR the core problem is still showing:

2. 129.144.16.109.rev.sfr.net     31.1%   212   24.4  56.9  22.9 344.7  67.7
 3. 82.186.96.84.rev.sfr.net        28.8%   212   25.8  51.0  22.4 288.1  52.7
 4.142.179.96.84.rev.sfr.net       30.2%   212   43.1  51.9  22.5 359.4  56.7
 5. 37.244.5.109.rev.sfr.net        29.2%   212   28.2 2573.  23.5 6441. 2508.
 6. 106.61.6.109.rev.sfr.net        29.2%   212   28.1 2696.  25.4 6866. 2512.
 7. 70.61.6.109.rev.sfr.net          34.4%   212   35.3 2555.  31.6 6737. 2509.
 8. 237.29.3.109.rev.sfr.net        34.4%   212  137.3 2659.  32.3 6719. 2508.
 9. ix-28-0.tcore1.PVUParis.as6453.net  32.5%   212   85.3 2630.  44.6 6745. 2512.
10. if-12-2.tcore1.PYE-Paris.as6453.net 35.8%   212   38.5 2506.  30.2 6729. 2530.


and the same evening:

 Host                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. box                              4.4%   479    2.3  39.3   0.8 1399. 132.4
 2. 129.144.16.109.rev.sfr.net      28.9%   479   24.6  73.5  22.8 1360. 157.6
 3. 82.186.96.84.rev.sfr.net        26.6%   479   26.1  72.1  22.7 1303. 150.6
 4. 142.179.96.84.rev.sfr.net       25.9%   479   39.9  67.6  22.6 1253. 140.2
 5. 37.244.5.109.rev.sfr.net        32.8%   479  5242. 2126.  23.2 10878 2510.
 6. 106.61.6.109.rev.sfr.net        28.5%   479  5427. 2293.  25.3 11725 2617.
 7. 70.61.6.109.rev.sfr.net         28.9%   479  5129. 2300.  30.3 11147 2569.
 8. 237.29.3.109.rev.sfr.net        29.7%   479  5075. 2242.  31.6 12060 2648.
 9. ix-28-0.tcore1.PVU-Paris.as6453 31.0%   478  5412. 2312.  43.3 11581 2566.
10. if-12-2.tcore1.PYE-Paris.as6453 31.4%   478  4962. 2217.  30.2 13397 2593.

(Feel free to add your own traceroutes as I am still unable to locate where in their website you can report problems to them - OR even find network status.)

The Conclusion:

SFR happened to set one of their 'would you like to buy anti-virus' sales men on us - which didn't go as he had hoped, but was probably the most effective way to inject a complaint into their company. On top of that SFR were informed at each end of the week, (you can call them on 1023 in France or 0033 6 1000 1023 from the UK.)

The first time they were able to almost instantly drop the latency from ~4000ms to 32ms within their backbone. (Daily and sometimes hourly cold-reboots of the router in the house all week), lead to Thursday where the problem was reported again. A very frustrated, (and a little bit angry) tech support bloke rebooted the house router remotely, (killing the crackly phone conversation stone dead); though it did fix the problem - and since then it has been a lot better. Still not perfect but actually useable. So what was the problem? What can we guess. Is their backbone capacity too heavily over subscribed? (My first guess, but this isn't 1998.) No, I'm almost certain that it is entirely down to some complicated rate-limiting withing their network somewhere between hop 4 and 5:

4. 84.96.xxx.xxx   <= no visable problems from users end 
5. 109.5.xxx.xxx   <= 50 times as long for packets to return (if they bother.)




At the time of this problem I was in the habit of starting with a trace to one of google's public caching name servers. The problem here is that SFR seem to have a direct peering with google via an address in 72.14.192.0/18 and probably have different rules for that connection, (after all SFR would just be shooting themselves in the head - as opposed to the other foot - if they slowed down their customers connection to google.)
 

About this blog

Sort of a test blog... until it isn't