Hodžův blog

Or: How iSCSI Schooled Me Again

I’ve never really liked iSCSI. It’s always felt like the network equivalent of a floppy disk – just with more ways for things to break. And today, I was reminded why.

From one of my Linux machines (Debian 12, of course), I needed to connect to an iSCSI LUN on a Synology NAS. Being the security-paranoid person that I am, I enabled CHAP authentication. And just to be extra safe, I also enabled mutual CHAP. Because trust is good, but verification over TCP port 3260 is better.

And then… this happened:

# sudo iscsiadm -m node -T iqn.2000-01.com.synology:synology.Target-1.abcdefghijk -p xxx.xxx.xxx.xxx --login
Logging in to [iface: default, target: iqn.2000-01.com.synology:synology.Target-1.abcdefghijk, portal: xxx.xxx.xxx.xxx,3260]
iscsiadm: Could not login to [iface: default, target: iqn.2000-01.com.synology:synology.Target-1.abcdefghijk, portal: xxx.xxx.xxx.xxx,3260].
iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
iscsiadm: Could not log into all portals
Continue Reading »

After quite a long time, I recently had to set up an SMS gateway on a virtual server for a customer again. Historically, I used Siemens/Cinterion MC35i modems for this purpose, but aside from their bulky size, I disliked the fact that they required external power.

Over time, I transitioned to using Huawei E3131 USB modems instead. These are small USB “sticks” that generally just need to be plugged into a USB port, and they work right away. I’ve deployed dozens of these devices without a single issue. Unfortunately, they’ve become nearly impossible to find these days — even second-hand.

While researching alternatives, I found that many e-shops are currently clearing out Huawei E3531 modems in bulk. Although these devices are outdated for internet access, they’re still perfectly suitable for sending SMS messages. What’s more, their price is ridiculously low — as little as 199 CZK (including VAT) per piece on some websites.

Naturally, I ordered a bunch of them. Once they arrived, I plugged one into a VMware-based environment for testing — only to be met with immediate disappointment: VMware didn’t recognize the USB modem.

So I began investigating.
Continue Reading »

A friend asked me to help him fix the non-working WiFi on his Minix Neo Z83-4 2.0 running LibreELEC.

After connecting via SSH, I discovered that neither the lsusb nor lspci commands detected the WiFi card. So, I checked the output of the dmesg command and found the following messages:

[ 9.943902] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 9.944187] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.MINIX-Z83-4.bin failed with error -2
[ 9.944870] usbcore: registered new interface driver brcmfmac
[ 10.005339] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.txt failed with error -2

I then checked the /lib/firmware/brcm directory on the device, but the files brcmfmac43455-sdio.MINIX-Z83-4.bin and brcmfmac43455-sdio.txt were missing. However, I found a file named brcmfmac43455-sdio.MINIX-NEO Z83-4.txt.

So, I tried renaming it to the required name and restarted the system. After rebooting, I discovered that everything had reverted to its original state. Upon further investigation in the LibreELEC documentation, I learned that the /lib directory is part of a SquashFS filesystem, which resets to its default state after every reboot. Any modifications must be made in the /storage directory instead.

To fix this, I created a firmware directory inside /storage/.config/, placed the correctly named file there, and rebooted the system. After that, everything started working.

Long story short:
# mkdir -p /storage/.config/firmware/brcm
# cp /lib/firmware/brcm/brcmfmac43455-sdio.MINIX-NEO\ Z83-4.txt /storage/.config/firmware/brcm/brcmfmac43455-sdio.txt
# reboot


Translated humorously into Czech as Funkce zrušení nemohla zkontrolovat zrušení, protože server pro zrušení byl offline.
If the issue is with the certification authority, the following registry modification will help you. In HKLM\System\CCS\Services\SSTPSvc\Parameters create a new DWORD (32-bit) named NoCertRevocationCheck with a value of 1.The provided solution should be implemented only for the necessary period!

From PowerShell, run the following commands as administrator:
Set-ItemProperty -Path “HKCU:\Software\Teamviewer” -Name ‘UIVersion’ -Value 2 -Type DWORD –Force
Stop-Process -Name "TeamViewer*" -Force
Start-Sleep 5
cd "C:\Program Files\TeamViewer"
.\TeamViewer.exe

After installing the October update (KB5018410), customers started reporting to us that they were unable to send mail from Outlook using SMTP TLS (port 587). The email client only displays the error message: 0x800CCC1A and postfix writes in the log:

Oct 16 18:21:39 mail postfix/submission/smtpd[719912]: connect from my.private.ip.[xxx.xxx.xxx.xxx]
Oct 16 18:21:39 mail postfix/submission/smtpd[719912]: SSL_accept error from my.private.ip[xxx.xxx.xxx.xxx]: lost connection
Oct 16 18:21:39 mail postfix/submission/smtpd[719912]: lost connection after STARTTLS from my.private.ip[xxx.xxx.xxx.xxx]
Oct 16 18:21:39 mail postfix/submission/smtpd[719912]: disconnect from my.private.ip[xxx.xxx.xxx.xxx] ehlo=1 starttls=0/1 commands=1/2

The following facts are interesting:
1. There is no problem with the IMAP protocol
2. On other servers with the same configuration and the same version of the libraries, everything works without a problem
3. Regeneration of the certificate (I use Let’s Encrypt) did not solve the problem, but with a certificate from another server, everything works again without a problem

At first I waited for a solution from Microsoft, which traditionally did not come. In the end, it was enough to slightly modify the Postfix configuration file (add the tls_ssl_options option for submission in master.cf) to temporarily solve the problem.

submission inet n - n - - smtpd
...
-o tls_ssl_options=NO_TICKET
...

Don’t forget to restart postfix after editing the configuration file.

With Greenbone Enterprise TRIAL, as well as Greenbone Community Edition (GCE), I ran into a problem where I could not log into the web interface after several tests. I just get a message:

The Greenbone Vulnerability Manager service is not responding. This could be due to system maintenance. Please try again later, check the system status, or contact your system administrator.

In order to get any information from the running system at all, it is necessary to become the root user. I achieved this as follows:

Open the Shell via the Support Menu and in the shell enter the following commands:

gos-state-manager set superuser enabled
gos-state-manager set superuserpassword y0ur-fuck1ng-c0mpleX-superus3r-p@ssw0rd
gos-state-manager save

Now you can log in directly in the console as the root user (for SSH it would probably be necessary to modify the configuration file /etc/ssh/sshd-config).

After a short investigation, I discovered that the GVMD service (systemctl status gvmd) is not running. This service cannot be started because the PostgreSQL database is not running either (systemctl status postgresql) and PostgreSQL cannot be started because it is always killed by the OOM killer (read from dmesg).

The free command showed that there was 4GB of RAM in the system, but this did not match my VMware setup, which is set to 16GB. Likewise, the number of cores in VMware was 8, while Linux only had 2.

It occurred to me that system resources could be limited directly by the kernel using the GRUB bootloader. Therefore, I looked into the file /etc/default/grub and I really found some limitations here:

GRUB_CMDLINE_LINUX = "$GRUB_CMDLINE_LINUX maxcpus=2"
GRUB_CMDLINE_LINUX = "$GRUB_CMDLINE_LINUX mem=5G"

So I commented out the mentioned lines, applied the changes to the system (update-grub) and restarted the machine. Now the machine has 8 cores and 16GB of RAM (as configured in VMware) and all services are running…

racadm racreset soft

Download and install Intel® Memory and Storage Tool CLI Solidigm™ Storage Tool CLI (SST)

[root@vmware:~] /opt/solidigm/sst/sst load -ssd 0
WARNING! You have selected to update the drives firmware!
Proceed with the update? (Y|N): y
Checking for firmware update...
- Intel SSD DC P4600 Series PHLE729000X14P0KGN -
Status : The selected drive contains current firmware as of this tool release.

[root@vmware:~] /opt/solidigm/sst/sst show -ssd 0
- 0 Intel SSD DC P4600 Series PHLE729000X14P0KGN -
Bootloader : 0136
Capacity : 3.64 TB (4,000,787,030,016 bytes)
DevicePath : nvmeMgmt-nvmhba0
DeviceStatus : Healthy
Firmware : QDV101D1
FirmwareUpdateAvailable : The selected drive contains current firmware as of this tool release.
Index : 0
MaximumLBA : 7814037167
ModelNumber : INTEL SSDPEDKE040T7
NamespaceId : 1
PercentOverProvisioned : 100.00
ProductFamily : Intel SSD DC P4600 Series
SMARTEnabled : True
SectorDataSize : 512
SerialNumber : PHLE729000X14P0KGN

May 29 02:06:55 pve1 pvestatd[1931]: authkey rotation error: cfs-lock 'authkey' error: got lock request timeout
May 29 02:06:55 pve1 pvestatd[1931]: status update time (9.120 seconds)
May 29 02:06:56 pve1 pve-ha-lrm[2050]: unable to write lrm status file - unable to delete old temp file: Input/output error

Fix the cluster filesystem:
# systemctl stop pve-cluster
# rm -f /var/lib/pve-cluster/.pmxcfs.lockfile
# systemctl start pve-cluster