This evening another two new countries in my amateur radio log: Lebanon and Gibraltar. First OD5ZF from Lebanon and 4 minutes later ZB3M from Gibraltar. That makes three pairs in two months. These two were both in FT8 mode on the 40 meter band. FT8 is very good at fast contacts at low received signal levels.
On 8 and 9 February last week I attended the Surf Security and Privacy conference. SURFcert, the incident response team of SURF, had its own 'side event' within this conference, an escape room. Since the members of SURFcert like to visit escape rooms themselves, the idea was to build our own escape room. A simple one as teams of 2 or 3 people had to solve it within 15 minutes. The best scores were indeed just over 5 minutes so it was doable.Read the rest of I learned event-based programming recentlyThe theme of this escape room was the trip Snowden made: from the US to Hongkong to Moscow. Each location had a puzzle and like Snowden the only thing you could take to the next location was knowledge. In this case a 4-digit code to open a lock. Someone else in the SURFcert team did most of the hardware work and I decided to dive into some programming to support this effort. The escape room needed a countdown clock that could only be stopped by the right code. So I installed a Raspberry Pi with a raspbian desktop and found out how to set up the autorun on the Pi so my program would be started at startup when the user 'pi' logs in automatically. This was done by starting it from ~/.config/lxsession/LXDE-pi/autorun. The program I wrote had three inputs:
The escape room clock
For the barcodes I used an usb barcode scanner I have lying around. It behaves like a usb keyboard so scanning a barcode will cause the code to be entered as keystrokes with an enter key at the end, But all programming I do is sequential. This is different, I needed to write an event-based program. It needs to react to time events, enter events and needs to check the state of gpio bits on time events. And on certain events it needs to change the global state (reset, running, stopped). The last time I did any event-based programming was an irc-bot written in Perl 4. So with a lot of google searches, copypasting bits of code, searching a lot for which input bits would be default high and go low when connected to earth and a lot of trying I wrote a program. It uses WxPerl to have a graphical interface and use events. I'm not saying its a good program, but it did the job. Notable things:
- A reset switch connected to GPIO pin 11 and ground
- A start button connected to GPIO pin 03 and ground
- Entering the right barcode to stop the time. In the end this was the barcode of a real Russian bottle of vodka, so my program needed vodka as input
- The OnInit function sets up everything: a window with minimal decorations, tries to set it full-screen, a text box that will show the time and starts at 15:00 as static text. A handler for time events that will be called 10 times per second. And an input box and a handler for when the enter key is pressed.
- The onTimer function that looks at global state and decides which inputs are valid in that state and handles them
- The onenter function that calculates a sha256 hash of the input line and checks which inputs can change the global state. The hash was to make sure that someone who could have a look at the source still had no idea what the commands were to control it all via keyboard. And no keyboard was connected anyway. The input for a shutdown is the barcode from one of the loyalty cards I carry around.
Two new countries in the PE4KH log: Oman and India. Oman was Friday afternoon when I was home early and decided to turn the dial over the 40 meter band to make some phone contacts and heard A41CK call. Who took my call on the second try! India was late Friday evening. The call VU2NKS showed up in FT8 and it had a direct pile-up (lots of people answering). But with some persistance from my side and good operating skills from the other side the contact was made. And this weekend was the Russian Worldwide PSK Contest so I participated Saturday afternoon / evening and a bit Sunday right before 12:00 UTC. I managed to start Saturday 12:00 UTC sharp calling CQ. Which worked at that time for getting contacts. I chose the 40 meter band category because I expected most radio time this weekend would be after sunset. In the end I made 64 contacts. Not a very high score, but I had times were several contacts happened in short succession so I am improving in digimode contesting.Read the rest of Two new countries in the log and I participated in the Russian worldwide PSK contest 2018Band QSOs Dupes Points Mults 160 0 0 0 0 80 0 0 0 0 40 64 0 388 28 20 0 0 0 0 15 0 0 0 0 10 0 0 0 0 ====================================== Total 64 0 388 28 Claimed score is 10864 points
After the end of January I decided to plot the number of contacts again. January is a busy month with two contests for me but I did not make a lot of contacts outside of those contests this year. I added contacts from holidays and the PE4KH/P activities to the total count. Some more work on the plot script, I think bars look better than a line graph. But you could spend hours in gnuplot making the plot just right... The new script:set output "qslcount.png" set terminal png size 640,300 fontscale 0.7 set timefmt "%Y-%m" set xlabel "Month" set ylabel "Number of contacts" set xdata time set style fill solid set xtics format "%b %Y" set xtics rotate set grid set boxwidth 0.75 relative set autoscale xfixmin set autoscale xfixmax plot "dataset-qsocount" using 1:2 title "Contacts/Month" with boxesUpdate: And indeed the change in x autoscale was one bit more 'just right'. The first graph was in February 2017: Rising number of amateur radio contacts.
: Applying robot logic to the term 'wingman'
In the sshd logging today:sshd: Invalid user <!-- from 126.96.36.199But the logging is parsed via software that doesn't trust input either, so the rest is in the report too. Including more attempts from that IPv4 address.
Iedere maand verschijnt er een Electron van 50 jaar geleden op Electron 50 jaar geleden en daar kijk ik graag even in, om het 'nieuws' op amateurradio gebied van 50 jaar geleden te zien. In die van Februari 1958 viel me een stukje op onder het kopje "Televisie" met:Voor onze lezers is het wellicht interresant, te weten dat Philips op Maandag het normale TV-programma relayeert in band V: beelddraaggolf 772,25 MHz, geluidsdraaggolf 777,75 MHz. Amateurexperimenten in deze band zijn van veel belang, want ondanks de ontvangstmoeilijkheden, die er nog zijn, kon het toch wel eens dé TV-band van de toekomst blijken te zijn. Een voordeel van deze band is natuurlijk in de eerste plaats het grote aantal beschikbare kanalen - de band loopt van 610-960 MHz! -. De commerciële televisie, die in ons land ook nog eens op gang hoopt te komen, vlast natuurlijk op een aantal kanalen in die band. Een ander voordeel is, dat de antennes zo klein kunnen zijn, hetgeen het stedenschoon ten goede zal komen.Ondertussen is analoge TV opgekomen in de UHF band en weer gestaakt. Opvallend is voor mij ook dat de genoemde draaggolf frequenties niet uitgekomen zijn op latere UHF kanalen. De afstand van 5 MHz tussen de audio en video draaggolf klopt wel met de analoge TV op UHF standaarden van later. Commerciële TV via de analoge etherkanalen is er nooit gekomen, dat is heel lang tegen gehouden en later via kabel/satelliet opgekomen en pas bij de digitalisering kwam er ruimte voor digitale TV via de ether. Het deel van de UHF band gereserveerd voor TV-kanalen is ook gekrompen, ondertussen zijn we aan het werken naar een einde bij 700 MHz. Mooi om zo'n voorspelling te zien en te vergelijken met de huidige realiteit.
Normally being active on certain HF bands causes one-time VDSL disconnects but what I have currently done seems to have triggered something else. After the connection dropped it refuses to come back at the moment. The entire session looks like:22:49:28.466922 PPPoE PADI [Service-Name] 22:49:28.490394 PPPoE PADO [AC-Name "dr12.d12"] [Service-Name] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] [EOL] 22:49:28.490603 PPPoE PADR [Service-Name] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] 22:49:28.517063 PPPoE PADS [ses 0x40c] [Service-Name] [AC-Name "dr12.d12"] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] [EOL] 22:49:28.575266 PPPoE [ses 0x40c] LCP, Conf-Request (0x01), id 72, length 16 22:49:28.575776 PPPoE [ses 0x40c] LCP, Conf-Request (0x01), id 99, length 22 22:49:28.575798 PPPoE [ses 0x40c] LCP, Conf-Reject (0x04), id 72, length 10 22:49:28.589161 PPPoE [ses 0x40c] LCP, Conf-Ack (0x02), id 99, length 22 22:49:28.589164 PPPoE [ses 0x40c] LCP, Conf-Request (0x01), id 73, length 12 22:49:28.589666 PPPoE [ses 0x40c] LCP, Conf-Ack (0x02), id 73, length 12 22:49:28.589682 PPPoE [ses 0x40c] LCP, Echo-Request (0x09), id 0, length 10 22:49:28.589693 PPPoE [ses 0x40c] CCP, Conf-Request (0x01), id 89, length 17 22:49:28.589702 PPPoE [ses 0x40c] IPCP, Conf-Request (0x01), id 89, length 18 22:49:28.589711 PPPoE [ses 0x40c] IP6CP, Conf-Request (0x01), id 89, length 16 22:49:28.603265 PPPoE [ses 0x40c] LCP, Echo-Reply (0x0a), id 0, length 10 22:49:28.603267 PPPoE [ses 0x40c] LCP, Term-Request (0x05), id 74, length 6 22:49:28.604033 PPPoE [ses 0x40c] LCP, Term-Ack (0x06), id 74, length 6 22:49:31.623454 PPPoE PADT [ses 0x40c] [Generic-Error "RP-PPPoE: System call error: Input/output error"] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83]So in the end the router at my ISP decides to terminate the connection. On the connection failing I decided to change the configuration to use the kernel mode pppoe driver but after this started showing I reverted that change. Which made no difference, the connection is still not coming up. Update: I went looking at other changes I made to enable the pppoe server test and reverting the /etc/ppp/pap-secrets file to its original format fixed the problem. I guess I somehow started to authenticate the remote end. And changing from user-mode pppoe to kernel-mode pppoe does lower the MTU to 1492, so that test is also finished. Back to user-mode pppoe.
The new homeserver will have to run the same pppoe client setup as the current server. But I want to get the whole setup tested before the migration to minimize disruption. Since I'm not going to get a free extra vdsl line and vdsl modem to test with and the complicated part is in the pppoe and ppp client part I decided to use a test vlan and set up a pppoe-server and ppp server on that vlan. The pppoe server part is started with# pppoe-server -I eth0.99 -C kzdoos -L 172.16.19.1 -R 172.16.21.19And it's indeed available from the client:# pppoe-discovery -I eth2 Access-Concentrator: kzdoos Got a cookie: 84 39 c6 51 13 fe 32 00 2c 06 2a b4 38 0e 30 87 46 7b 00 00 -------------------------------------------------- AC-Ethernet-Address: 00:1f:c6:59:76:f6So that part works. Next is to get an actual ppp session working over it. The server part was a bit of work as I want to get the whole configuration including password checks. Server configuration in /etc/ppp/pppoe-server-options on the server system:require-pap lcp-echo-interval 10 lcp-echo-failure 2 hide-password noipx ipv6 ,And the client configuration in /etc/ppp/peers/dray-vdsl:user testkees password topsecret +pap noauth noipdefault ipv6 , ipv6cp-use-persistent defaultroute persist maxfail 0 noproxyarp ipparam xs4all lcp-echo-interval 10 lcp-echo-failure 6 pty "pppoe -I eth2"Lots of options to make the setup exactly the same as the current. It took a lot of tries before password authentication was working. I could not get the client-side password in /etc/ppp/pap-secrets to work, but as show above the password in the ppp configuration did work. And the setup in /etc/network/interfaces on the client just the same as the known configuration:iface pppdray inet ppp provider dray-vdslAnd it works!# ifup pppdray Plugin rp-pppoe.so loaded. # ifconfig ppp0 ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1492 inet 172.16.21.45 netmask 255.255.255.255 destination 172.16.19.1 inet6 fe80::5254:ff:fe3c:2014 prefixlen 10 scopeid 0x20<link> ppp txqueuelen 3 (Point-to-Point Protocol) RX packets 9 bytes 252 (252.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9 bytes 202 (202.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 # ping -c 3 172.16.19.1 PING 172.16.19.1 (172.16.19.1) 56(84) bytes of data. 64 bytes from 172.16.19.1: icmp_seq=1 ttl=64 time=0.721 ms 64 bytes from 172.16.19.1: icmp_seq=2 ttl=64 time=0.436 ms 64 bytes from 172.16.19.1: icmp_seq=3 ttl=64 time=0.449 ms --- 172.16.19.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2029ms rtt min/avg/max/mdev = 0.436/0.535/0.721/0.132 msThe mtu is not yet what I want, but the session is alive.
I was setting up a linux based firewall on a busy ntp server and to make sure everything worked as designed I added the usual:iptables -A INPUT -j ACCEPT --protocol all -m state --state ESTABLISHED,RELATEDAnd after less than half an hour the system log started filling withnf_conntrack: table full, dropping packet nf_conntrack: table full, dropping packet nf_conntrack: table full, dropping packet nf_conntrack: table full, dropping packetIt is indeed a busy server. The solution is to exclude all the ntp traffic from the stateful firewall. Which means I have to allow all kinds of ntp traffic (outgoing and incoming) by itself. The specific ruleset:iptables -t raw -A PREROUTING --protocol udp --dport 123 -j NOTRACK iptables -t raw -A OUTPUT --protocol udp --sport 123 -j NOTRACK iptables -A INPUT -j ACCEPT --protocol udp --destination-port 123I also made sure the rules for the ntp traffic are the first rules. Traffic at this server is somewhat over 1000 ntp request per second. So the counters of the NOTRACK rules go fast.# iptables -t raw -L -v Chain PREROUTING (policy ACCEPT 1652K packets, 126M bytes) pkts bytes target prot opt in out source destination 9635K 732M CT udp -- any any anywhere anywhere udp dpt:ntp NOTRACK 1650K 125M CT udp -- any any anywhere anywhere udp dpt:ntp NOTRACK Chain OUTPUT (policy ACCEPT 1522K packets, 117M bytes) pkts bytes target prot opt in out source destination 9029K 686M CT udp -- any any anywhere anywhere udp spt:ntp NOTRACK 1520K 116M CT udp -- any any anywhere anywhere udp spt:ntp NOTRACKBut no packets are dropped, which is good as this server is supposed to be under a constant DDoS.
: And they are back! New episodes showing up.