The world did not fall apart at the leap second...Jul 1 01:59:59 greenblatt kernel: [5562265.176016] Clock: inserting leap second 23:59:60 UTCJul 1 01:37:53 ritchie ntpd: local_clock: ntp_loopfilter.c line 688: kernel reports positive leap second warning state Jul 1 01:59:59 ritchie kernel: [5807507.207473] Clock: inserting leap second 23:59:60 UTC Jul 1 02:13:11 ritchie ntpd: local_clock: ntp_loopfilter.c line 688: kernel reports leap second has occured
I thought I heard short exchanges with locators and callsigns when I made the last recording of an SO-50 pass. But since this is all NATO spelling it wasn't completely clear to me which was what. So I asked on the Amsat-bb mailing list about the typical SO-50 exchange and got an elaborate explanation:
So I would answer with: callsign de Pappa Delta Four Kilo Hotel, Five Nine in Juliet Oscar Two Two November Charlie
- Europe: callsign / signal report (normally 59) / 6-character grid locator.
- In other parts of the world like North America and Australia, signal reports are not normally given.
- The 6-character grid locator is useful in Europe, where we in North America usually just go with 4-character grid locators.
- In Australia, call signs and general descriptions of your signals (loud/clear, for example) are all that they exchanged. No 59, no grid locator.
Previous there was just an announcement:associd=0 status=0119 leap_none, sync_pps, 1 event, leap_armedBut the current state is that it's less than 24 hours until the leap second:ntpq -nc readvar associd=0 status=4619 leap_add_sec, sync_ntp, 1 event, leap_armed, version="ntpd email@example.com Mon Apr 13 13:41:30 UTC 2015 (1)", processor="x86_64", system="Linux/3.2.0-80-generic", leap=01, stratum=2, precision=-20, rootdelay=21.302, rootdisp=962.377, refid=18.104.22.168, reftime=d93ccb6a.5bf9c564 Tue, Jun 30 2015 10:01:46.359, clock=d93ccb70.10208b70 Tue, Jun 30 2015 10:01:52.062, peer=21283, tc=6, mintc=3, offset=-23.354, frequency=7.280, sys_jitter=0.205, clk_jitter=8.257, clk_wander=0.087, tai=35, leapsec=201507010000,
Uit recente e-mail van de bibliotheek utrecht:de Bibliotheek Utrecht heeft u een e-mail gestuurd met als onderwerp ‘Goed nieuws: Bibliotheek op de Neude’.Nee hoor, ik lees mijn e-mail niet met een browser, die zijn daar niet voor. Dat ik de tekstversie zie komt door
Dat u de inhoud van deze e-mail niet direct kunt lezen komt wellicht door de instellingen van uw browser.alternative_order text/plain text/htmlin mijn .muttrc.
This evening I had a nice pass of SO-50, maximum elevation 83 degrees, southwest to northeast so I decided to give it a try. I heard two callsigns distinctly and tried replying to them but they didn't hear me or didn't reply. I recorded the pass again with the line-in on my mp3 player. Using the simple earphones from my mp3 player gave me reasonable audio. The cable between the radio and the splitter was giving some issues again: I still had intermittent audio levels when the cable moved. Update: And I edited the audio file I recorded: took of the first noise until the first voices showed up in the audio. I may have cut off too much as I can't find the German callsign anymore that I was quite sure I heard.
This weekend there was another digimode contest active in the digital mode part of the 20 meter amateur band. So I decided to play along for a bit when I had time. The main results are that I made contacts with a new country (Estonia) and a new US state (Florida). I entered the log just now and the result page says:Your log is ACCEPTED with the following data: Callsign: PD4KH
Category: SINGLE_OP 20M LP
Number of QSOs: 29
: Regularly during QSO's I think 'this deserves a real QSO card'. New countries, new modes, amateurs that clearly like cards like myself or other reasons. But printing/cutting/writing my cards is something I do in batches. I used to make a note in the QSO log entry note field about this, and I had to search the logs for any notes that looked like 'will send card'.
Recently I discovered CQRLOG has the ctrl-W shortcut key which will set SB (will send via buro) or SMB (will send to qsl manager via buro) depending on whether the 'qsl via' is set.
This means the searching of the log later is quite simple: I can set a search filter in CQRLOG for SB or SMB records, write the cards and change them to the status 'Buro'.
There are also options to automate the printing of labels for QSO cards which could be a help for my unreadable handwriting ;)
The weather is finally getting better and some people really would like me to demonstrate satellite QSO's. So I need to get active again and make those contacts. One thing I wanted to improve was the recording of contacts. When I use the FT-857 radio with computer control I can record everything but I need lots of wires and equipment. I also want to record in a more 'lightweight' setup, with a handheld radio (or two for full duplex). So I dug up an older 3.5mm headphone splitter and used my iRiver ifp-795 in line-in recording mode to record the incoming audio while hearing it at the same time via headphones. Today I tested recording the audio from the Wouxun KG-UVD1P. Someone on repeater PI3UTR was nice enough to keep it busy. I had a reasonable recording, it had distortion. Next test is on a pass of the SO-50 satellite. Update: I had a low pass (about 30 degrees elevation maximum) and I noticed the cable between the radio (2.5mm mono) and the splitter (3.5mm stereo) was giving an intermittant contact so I resoldered it. Understandig the callsigns in the audio was still a problem, I had to turn up the volume quite high which led to a distorted recording. And when I leave the iRiver ifp-795 in line-in recording mode it does not shut down after some minutes of inactivity. I have to shut it down by hand or switch to mp3 player mode.
: 17 years ago l0pht tried to tell the world it was building an insecure network and connecting everything to it.
We didn't listen enough.
: I have had more than one interference problem with PSK31 on 20 meters (the same 14.070 MHz) due to signal leaks from VGA cables. I was hoping switching to DVI would make things better but your video makes me wonder... Thanks for sharing!
At work I reviewed something about TLS security I wrote in May 2014 and noticed I had to make some serious adjustments for the May 2015 state. SSLv3 is no longer accepted, SHA1 is no longer an accepted hashing algorithm and other changes. This week on the home server greenblatt I had two different impacts from the latest OpenSSL update: SSL communications with the Fritz!Box was failing and SSL in sendmail was failing, both due to the latest insights into the security of the Diffie-Hellman key exchange. These insights are very very new: in April I did a course in the Certified Information Systems Security Professional (CISSP) common body of knowledge and I learned the default Diffie-Hellman parameters were safe. Now we learn to generate them for each individual system at the same strength as the private key. Knowledge of cryptographic quality ages fast at the moment.
I'm not sure it is related to the recent OpenSSL upgrades but yesterday outgoing mail was suddenly all stuck with the error message:Jun 19 16:02:30 ritchie sendmail: STARTTLS=client: 6381:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3449: Jun 19 16:02:30 ritchie sendmail: ruleset=tls_server, arg1=SOFTWARE, relay=postbox.idefix.net, reject=403 4.7.0 TLS handshake.I couldn't find a definitive reason, but I did notice these in the logs of sendmail on the home server:Jun 19 20:59:27 greenblatt sendmail: STARTTLS=client: 4747:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3338: Jun 19 23:09:24 greenblatt sm-mta: STARTTLS=server, error: cannot read DH parameters(/etc/mail/tls/sendmail-common.prm): error:0906D06C:PEM routines:PEM_read_bio:no start lineI did notice /etc/mail/tls/sendmail-common.prm was 0 bytes large on the server which could be a source of the problem. This is the Diffie-Hellman parameter file used by the submission client. I regenerated this file to a 2048 bit Diffie-Hellman dhparam file. Mail is flowing again, but I'm not sure this was the cause of the problem. The first errors were from:Jun 15 13:00:52 greenblatt sendmail: STARTTLS=client: 26472:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3338: Jun 15 13:00:52 greenblatt sendmail: ruleset=tls_server, arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0 TLS handshake.And that was right after an openssl update. Why it took until 19 June for the mailflow to stop completely is strange to me. Update: The only thing I can think of is that sendmail wasn't restarted after OpenSSL was updated. I checked the same update today on another system and the update of OpenSSL does not set triggers to restart ssl-using daemons.
The latest OpenSSL updates cause me a new problem:Connecting to fritz.koos.koffie.dot (fritz.koos.koffie.dot)|192.168.178.1|:49443... connected. OpenSSL: error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small Unable to establish SSL connection.Which means the script to fetch the dsl status from the fritzbox can't connect until I find out how to convince wget how to negotiate a non-standard cipher set. Or switch to curl. Getting the right answers with curl isn't working out either. I can get the SSL working and do a POST to the right URL but the 'best' thing I get back is:<errorCode>502</errorCode> <errorDescription>XML error</errorDescription>Update: The solution was to keep using wget but disable(!) SSL, using the non-SSL port for upnp. The command now is:wget --user=$FRITZUSER --password=$FRITZPASS --post-file=linkstatusrequest.xml \ --header="Content-Type: text/xml" \ --header="SOAPAction: \"urn:dslforum-org:service:WANCommonInterfaceConfig:1#GetCommonLinkProperties\"" \ http://192.168.178.1:49000/upnp/control/wancommonifconfig1 -O linkstatusanswer.xmlAnd now the data is available again and the graph is updated. So the recent upgrade in OpenSSL which disabled less secure Diffie-Hellman key negotiation results in having to disable all encryption on the connection with the fritzbox. A security update on the fritzbox may solve this.
: DKARS (Dutch Kingdom Amateur Radio Society) organized a new contest, The Dutch Kingdom Contest. PA3FYM participated on the location of PA7FA who has enough space available for some nice beverage antennas. Together they made a video of the contesting setup and the activity during the contest.
Reading the changelogs for Ubuntu upgrades is good, since I noticed:Get:1 Changelog for apache2.2-bin (http://changelogs.ubuntu.com/changelogs/pool/ main/a/apache2/apache2_2.2.22-1ubuntu1.9/changelog) [152 kB] apache2 (2.2.22-1ubuntu1.9) precise-security; urgency=medium * SECURITY IMPROVEMENT: add support for ECC keys and ECDH ciphers (LP: #1197884) - debian/patches/ecc_support.patch: add support to modules/ssl/mod_ssl.c, modules/ssl/ssl_engine_init.c, modules/ssl/ssl_engine_kernel.c, modules/ssl/ssl_private.h, modules/ssl/ssl_toolkit_compat.h, modules/ssl/ssl_util.c, * SECURITY IMPROVEMENT: add TLSv1.x options to SSLProtocol (LP: #1400473) - debian/patches/tls_options.patch: allow specifying later TLSv1.x options in modules/ssl/mod_ssl.c, modules/ssl/ssl_engine_config.c, modules/ssl/ssl_engine_init.c, modules/ssl/ssl_engine_kernel.c, modules/ssl/ssl_private.h. * SECURITY IMPROVEMENT: improve ephemeral key handling, including allowing DH parameters to be loaded from SSLCertificateFile and disabling EXPORT ciphers. - debian/patches/ephemeral_key_handling.patch: numerous improvements to modules/ssl/mod_ssl.c, modules/ssl/ssl_engine_config.c, modules/ssl/ssl_engine_dh.c, modules/ssl/ssl_engine_init.c, modules/ssl/ssl_engine_kernel.c, modules/ssl/ssl_private.h, modules/ssl/ssl_util_ssl.c, modules/ssl/ssl_util_ssl.h.It took a bit of digging in Bug #1197884 “apache2.2 SSL has no forward-secrecy: need ECDHE k...” : Bugs : apache2 package : Ubuntu but the decision was made to backport ECDHE handling to mod_ssl in the Apache 2.2.22 package in Ubuntu 12.04 LTS. To be able to use this all you need to generate your own dhparams with:# openssl dhparam -out dhparam.pem 2048Where the keysize here (2048 bits) needs to be the same as for the private key. The resulting dhparams in PEM format need to be pasted to the SSLCertificateFile so it ends up looking like:-----BEGIN CERTIFICATE----- .. -----END CERTIFICATE----- -----BEGIN DH PARAMETERS----- .. -----END DH PARAMETERS-----This is actually an upgrade and not an update, but as the discussion in the bugreport shows the choice was made to improve overal security in light of recent revelations about the probable capabilities of NSA/GCHQ, better explained in The Logjam (and Another) Vulnerability against Diffie-Hellman Key Exchange - Schneier on Security.
Slight adjustment of my highest distance in a PSK31 contact: 7179 kilometer to KP4DQC in Puerto Rico.
: I have seen the movie Wargames quite a number of times so I immediately notice one of the keyholes for the missile launch has a tag 'GENTLY' above it. So even THAT detail in the movie is correct.
And if I ever visit that area, I have something to go see...
http://history.nd.gov/historicsites/minutemanmissile/ and in WarGames. Both have a tag 'GENTLY' right above the launch key. This shows again that WarGames completely nailed the launch sequence to the last detail.: Ok, I couldn't resist looking for the right frame in the video from
Bericht van de ING:Read the rest of Controle over je geld ongewenst?In Mijn ING bent u gebruiker (geweest) van FiNBOX voor uw financiële post en betalingen. Omdat steeds minder ING-klanten gebruikmaken van FiNBOX, hebben wij besloten om per 1 januari 2016 te stoppen met deze dienst. Natuurlijk vinden wij dit erg jammer. Dit betekent dat u vanaf deze datum geen FiNBOX-documenten meer kunt ontvangen, betalen of inzien. Alternatieve mogelijkheden Steeds meer bedrijven bieden u mogelijkheden om financiële post digitaal te ontvangen, zoals in "Mijn-omgevingen" of via e-mail. Ook rekeningen kunnen vaak steeds makkelijker worden betaald met bijvoorbeeld iDEAL of per incasso. Bedrijven informeren u verder U hoeft bedrijven niet zelf op de hoogte te brengen. Dat hebben wij al voor u gedaan. De bedrijven waar u FiNBOX-documenten van krijgt, informeren u in de loop van dit jaar verder over hoe u voortaan uw financiële post ontvangt. Uw FiNBOX-documenten bewaren Wilt u FiNBOX-documenten bewaren voor uw eigen administratie? Geen probleem. Tot 1 januari 2016 kunt u uw documenten gewoon nog uitprinten of opslaan op uw computer, usb-stick of Cloud-opslagdienst.Wat begon als 'digitale nota' was een goed systeem om nog wat controle te houden op hoeveel geld er naar wie de deur uit ging (wat niet kan met incasso) en ook wanneer dat zou gaan gebeuren (wat niet kan met ideal betaling). Tegelijkertijd kwamen de bijbehorende documenten ook goed beschikbaar (al maakte digitale nota / finbox daar te weinig reclame voor). De laatste jaren had ik de beschikking gemeentebelastingen keurig als PDF in finbox nadat de gemeente Utrecht was gestart met digitale nota voor de gemeentebelastingen. Alleen leken banken en bedrijven het niet echt te willen, er werd nooit reclame voor gemaakt. Toen we nog kabeltelevisie hadden van Ziggo moesten we daar met veel moeite uittrekken dat het ook via digitale nota betaald kon worden, en duurde het nog wat maanden voordat de toeslag voor het betalen met acceptgiro verdween van de digitale nota. En vervolgens beweerde Ziggo begin dit jaar dat de aanmelding bij FinBOX niet helemaal correct was en dat ze er dus helaas mee moesten stoppen maar toen waren we toch al bezig Ziggo op te zeggen dus dat was gewoon een extra reden.
For the joint experiment in amateur satellites last Saturday I added a second monitor to the PC so I could watch the gqrx waterfall and the fldigi waterfall at the same time. And on Sunday I noticed some weird new interference around 14.070 MHz which made decoding the PSK31 signals a lot harder. The new VGA cable near the radio was a suspect and indeed after removing it completely the problem went away again. So if I want a working dual-screen setup, I'll have to find better video cables. Maybe DVI gives less interference. It was nice to have fldigi running PSK31 on one screen and do other things on the other screen. The upside was that with the current versions of Linux video driver I had to do zero fiddling to make the setup work dual-screen.
: Together with Jan van Gils PE0SAT I did an experiment with the new PSAT satellite: transmit at rising power levels and decode the PSK31 signals from the downlink to see what power level on HF is needed for a clear signal. The current conclusion is that a readable signal came out with a 20 watt uplink.
December last year I noticed IPv6 at the Surfnet office breaking in interesting ways. Recently I was invited to come over and test it again, news was that the problem I was seeing should be fixed now. I accepted that invitation and Yesterday I was at the new office and tested it. And indeed it now works good, I received a stable IPv6 assignment and I was able to keep long-running IPv6 sessions to multiple systems at home. The technical reasons behind it are 'interesting' but the good news is that the eduroamers network now has stable IPv6.