WiMAX HOME 02をジャンク500円で手に入れたのでドコモSIMで使った(楽天モバイルは不可


秋葉原でUQ WiMAX HOME 02が本体のみ(電源無し) 500円で売っていた

裏面を見てみると製造年2020年7月、8月、12月などいろいろタイプがあった

電源は12V1.5Aなのだが、極性統一 EIAJ #4 というタイプのコネクタとなっている。

買った時はバッファローWiFiの12Vが使えるだろう、と軽く考えてたのですが駄目でした。

別途、5.5mm/2.1mmから極性統一#4(5.5mm/3.3mm センターピンあり)に変換するコネクタを調達しました。

変換コネクタが届くまでとりあえず手元にあった極性統一#4の12V 0.7Aのアダプタを使って起動テスト

nanoSIMをスロットに入れて電源ON

特に問題なくルータの管理画面にアクセスできたが、ドコモSIMで電波を掴むにはAPN設定以外にも設定が必要だった

[ネットワーク設定]-[基本設定]にある「通信モード」を「ハイスピードプラスエリアモード」に変更する必要がありました。

IIJmio SIMでAPNを設定する場合、[ネットワーク設定]-[プロファイル設定]にある「プロファイルリスト」で「no setup」となっているものを「選択」してから設定します。

このとき、IIJmioのページには「認証タイプ PAPまたはCHAP」と書いてあるのですが、HOME 02では「PAP」と設定しなければつながりませんでした。

また、設定後、5分ぐらい待たないと接続状態とならないようです。


2023/05/11追記

楽天モバイルSIMを入れて設定を試みたところ、ユーザ名とパスワードを未設定、ということはできませんでした。

ただ、適当な値を入れても大丈夫らしいので、設定してみたのですが、接続出来ず

よくよく使用できる電波仕様を確認してみると楽天モバイルが使用しているバンド3(LTE 1.7GHz)は非対応でした。

2023/05/12追記: 楽天モバイルでのau回線利用が拡大されるっぽいですが、au基地局側で設定されている場合のみ使えるって感じなので、基本的には使えないと思っておいた方がいいでしょう

https://twitter.com/Rakuten_Mobile/status/1656902083705176064

Sierra Wireless EM7330 のfirmwareまわりのメモ


ジャンク屋で買ったLTEカード EM7330 、firmwareについて気にしていなかったのですが、あったようなのでメモ

EM7330に関するサポートページ

ただ、ユーザ登録が必須っぽい?

・Firmware
AirPrime EM73xx/MC73xx FW Package Build 4837

EM7330は一番下に「Docomo」という列があって「SWI9X15C_05.05.65.00」となっていた。

・Firmware アップデート用ツール
Module Firmware Download Tool (FDT – command line tool for Windows)

・Windows用ドライバ
Windows Drivers for EM/MC Series Modules (Build 5087)

Windows Updateで持ってくるので気にしていなかったのですが、Windows用ドライバが配布されていました。

富士通サイトには 「Sierra Wireless EM7330 WWAN Driver + Firmware Updater」 があり、SWI9X30C_05.05.63.00 になる

閉鎖環境内でアラートメールの送信ができるだけのためのメールサーバ設定(AlmaLinux8/RHEL8/Oracle Linux8)


閉鎖環境で機器初期セットアップを行う際に、アラートメールの送信先を指定する必要があったりする。

その時に、メール送信テストが行えるような簡易的なLinuxサーバを作るためのメモ書きです。

なお、メールの送信先は「root@adosakana.local」としておいて、Linuxユーザのroot宛にメールが届くような設定です。

メールを読むときは /var/mail/root に届くのを直接見るか、mail/mailx/muttコマンドなどで見る想定です。

(1) AlmaLinux / RHEL / Oracle Linux 8の最小インストールを実施

(2) アップデート

「dnf update -y」でパッケージを最新に

(3) SMTPで使用するポート開け

「firewall-cmd –add-service smtp –permanent」で追加

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
# firewall-cmd --add-service smtp --permanent
success
# firewall-cmd --reload
success
# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: cockpit dhcpv6-client smtp ssh
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
#

(4) postfixのインストール

「dnf install postfix」でpostfixをインストール

(5) postfixの設定ファイルを編集

まず、テストに使うメールアドレスのドメイン名を「mydomain=~」で定義(myhostname 定義はそのまま使った)

# The mydomain parameter specifies the local internet domain name.
# The default is to use $myhostname minus the first component.
# $mydomain is used as a default value for many other configuration
# parameters.
#
#mydomain = domain.tld
mydomain = adosakana.local

メール送信者にドメイン名指定がない場合に、mydomainで設定した内容を適用するために「myorigin = $mydomain」

# SENDING MAIL
#
# The myorigin parameter specifies the domain that locally-posted
# mail appears to come from. The default is to append $myhostname,
# which is fine for small sites.  If you run a domain with multiple
# machines, you should (1) change this to $mydomain and (2) set up
# a domain-wide alias database that aliases each user to
# user@that.users.mailhost.
#
# For the sake of consistency between sender and recipient addresses,
# myorigin also specifies the default domain name that is appended
# to recipient addresses that have no @domain part.
#
#myorigin = $myhostname
myorigin = $mydomain

どのNICからきたSMTP要求でも受付させるための「inet_interfaces = all」を定義

# RECEIVING MAIL

# The inet_interfaces parameter specifies the network interface
# addresses that this mail system receives mail on.  By default,
# the software claims all active interfaces on the machine. The
# parameter also controls delivery of mail to user@[ip.address].
#
# See also the proxy_interfaces parameter, for network addresses that
# are forwarded to us via a proxy or network address translator.
#
# Note: you need to stop/start Postfix when this parameter changes.
#
inet_interfaces = all
#inet_interfaces = $myhostname
#inet_interfaces = $myhostname, localhost
#inet_interfaces = localhost

受信するメールを決めるために「mydestination =~」を指定。とりあえず全部受け取るような感じの設定にする

# Specify a list of host or domain names, /file/name or type:table
# patterns, separated by commas and/or whitespace. A /file/name
# pattern is replaced by its contents; a type:table is matched when
# a name matches a lookup key (the right-hand side is ignored).
# Continue long lines by starting the next line with whitespace.
#
# See also below, section "REJECTING MAIL FOR UNKNOWN LOCAL USERS".
#
#mydestination = $myhostname, localhost.$mydomain, localhost
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
#mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
#       mail.$mydomain, www.$mydomain, ftp.$mydomain

メール送信側のSSLプロトコル対応が古い場合を考慮して「smtpd_tls_security_level=none」と暗号化の要求レベルをなしにしておく

# Announce STARTTLS support to remote SMTP clients, but do not require that
# clients use TLS encryption (opportunistic TLS inbound).
#
#smtpd_tls_security_level = may
smtpd_tls_security_level = none

なお、「lost connection after STARTTLS from unknown」という形でSMTP接続を拒否される場合は、おそらく標準値の「smtpd_tls_security_level = may」で設定している場合。(TLS1.2以降を必須、とかそんな感じ)

(6) postfixを起動

「systemctl enable postfix」でOS起動時にpostfixも起動するように設定し、

「systemctl start postfix」でいますぐpostfixを起動させている

# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; disabled; vendor pr>
   Active: inactive (dead)
# systemctl enable postfix
Created symlink /etc/systemd/system/multi-user.target.wants/postfix.service → /usr/lib/systemd/system/postfix.service.
# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor pre>
   Active: inactive (dead)
# systemctl start postfix
#


おまけ: mutt コマンドでメールを送信しようとしたけど、送れない

とあるプロダクトのアラートメールの送信手法がmuttコマンドを利用していた。

「smtpd_tls_security_level = may」設定のpostfixにメールを送ると「lost connection after STARTTLS from unknown」で送れていなかった。

postfix側ではなく、mutt側で対策取れるかを確認したところ /etc/Muttrc.local などの muttの設定ファイル内で「set ssl_starttls = no」と設定して、STARTTLSの使用を取りやめることでメール送信に成功するようになった。

RHEL8.5サーバから mutt コマンドでメール送信する場合、SSL関連の設定を調べると以下の様なものがある

set ssl_verify_host = no
set ssl_verify_dates = no
set ssl_starttls = yes
set ssl_use_tlsv1_3 = yes
set ssl_use_tlsv1_2 = yes
set ssl_use_tlsv1_1 = yes
set ssl_use_tlsv1 = no
set ssl_use_sslv3 = no
set ssl_use_sslv2 = no

ただ、RHEL8.5で試してみたところ「ssl_use_sslv2」というオプションは存在していなかった。

# echo "test mail"  | mutt -F ~/testmuttrc -s "test mail title" 受信者 -d 10
レベル 10 でデバッグ中。
/root/testmuttrc 中の 14 行目でエラー: ssl_use_sslv2 は不明な変数
source: /root/testmuttrc 中でエラー
#

また、opensslコマンドのs_clientでSSLv2 SSLv3の接続ができるかを試験してみたところ、オプション自体が廃止されていた。

# openssl s_client -connect 172.17.44.50:25 -servername 172.17.44.50 -ssl3
s_client: Option unknown option -ssl3
s_client: Use -help for summary.
# openssl s_client -connect 172.17.44.50:25 -servername 172.17.44.50 -ssl2
s_client: Option unknown option -ssl2
s_client: Use -help for summary.
#

Prolific社のUSBシリアルチップPL2303シリーズのWindows10/Windows11非対応問題


USBシリアルアダプタに以前はよく使われていたProlific社のPL2303シリーズ。

ある時期から偽物チップが登場して、上手く動く/動かない、という話になったことにキレたProlific社が古いチップをまとめてEOS(End of Support)したので、EOS以後にリリースしたWindows10以降で使えなくなった、なんてことがあった。

この互換性問題もあってか信頼性を求めるとFTDI社FT232シリーズ、安さを追求するとWCH社のCH340シリーズなど他社のUSBシリアルが採用されがちになってる。

で・・・このEOSに関するProlific社の公式表明としては、2012年2月に、PL-2303HX, PL-2303Xシリーズを廃盤として、PL-2303TAを後継とするアナウンスを出している。これの影響でPL-2303HXA,PL-2303XAおよびそれより古いPL2303シリーズがWindows8以降で使えなくなった。

このため該当するチップを使っているUSBシリアルをWindows10にさすと、以下のような表示となって使えない。(PL2303HXA PHASED OUT SINCE 2012, PLEASE CONTACT YOUR SUPPLIER. )

で・・・Press Releaseを見ると、2019年12月にその後継とされたPL-2303TA含めて、PL2303HXD, PL2303RA,PL2303EA, PL2303SAがEOSとなっていた。

この時点では特に問題なかったのだが、どうやらWindows11ではこのPL-2303TA採用チップなどが「PL2303TA DO NOT SUPPORT WINDOWS 11 OR LATER, PLEASE CONTACT YOUR SUPPLIER.」として使えなくなっているらしい。

Windows 10用のドライバを持ってきて強制的に適用すれば使用できるようにはなるらしいですが、Windows Update経由のドライバ更新があったりすると使えなくなったりしそうなので、あまりお薦めできなそうです。


2023/01/28追記

ツクモに行ったら ainex ADV119 v2 が500円で売ってた

メーカページを見てみると「ADV-119 ○ ドライバは従来よりウェブに公開しているもので対応します。」と書いてある。

ということはWindows 11の標準ドライバでは対応しないやつなんだな、と思い買ってみると、予想通り以下の表示

で、メーカページからリンクがはれている「PL2303 Windows Driver Download USB to UART RS232 Serial」から「Windows 10 RS3 or higher」と書かれてる方をダウンロードして「PL2303_DCHU_Win10_20H1_19H1_5_v3.8.36.2_20210315_ML_Driver」のドライバを適用すると、下記の表示となり、使用できるようになりました

2023/11/14追記

上記のProlificサイトにアクセスできない場合はMicrosoft Updateカタログで「VID_067B PID_2303 3.8.36.2」で検索して出てきた「Prolific – Ports – 3.8.36.2」のやつを使うといけるかもしれない。

FortiGate環境で”This Connection is Invalid. SSL certificate expired.”を食らった


会社からアクセスしてみたようとしたら「This Connection is Invalid. SSL certificate expired.」というエラーがでてアクセスできなかった。

最初、サーバ側の問題なのかと思って調査を開始したところletsencrypt.orgにアクセスした場合にも同じエラーが・・・

さすがにこれはおかしいな、とスマホからLTE回線で確認してみたらどちらもアクセス可能。

これは???と思ってよくよくエラー内容を見直してみる…

FortiNetのアイコンじゃん

というわけで対処方法がFortiNetのページにありました「Fortinet and Expiring Let’s Encrypt Certificates

上記記載の内容を下記に引用する。

Workaround 1 – Prevent fallback to the expired Root CA

With the removal of the expired IdenTrust DST Root CA X3 in Certificate Bundle version 1.28, it is possible to prevent fallback to the expired root CA by blocking FortiGate access to apps.identrust.com, resulting in the correct root CA being used. This can be achieved by using either DNS blackholing or via an FQDN policy to block access to apps.identrust.com.

This will force the FortiGate device to rebuild the certificate chain and find the ISRC Root X1 Root CA Cert in the local certificate in the store.

config system dns-database
    edit "1"
        set domain "identrust.com"
        config dns-entry
            edit 1
                set hostname "apps"
                set ip 127.0.0.1
            next
        end
    next
end

Workaround 2 – Accept the expired certificates

For third-party sites outside of your control, customers can turn off this certificate expiration validation using the following CLI as a temporary workaround:

config firewall ssl-ssh-profile
  edit "certificate-inspection"
    config https
      set expired-server-cert allow 
      set untrusted-server-cert allow
end

FortiGateのコマンドで、期限切れとなっている証明書の取り扱い手法を変える、というものになっている。

今後のFortiGateの新firmwareで、もうちょっとスマートな回避方法の提供を計画しているとのこと。

今回の問題について、該当環境の管理者に確認したところworkaround2の手法で対処した、とのこと。