Arch LinuxでWiFi接続不可

 article  Comments Off on Arch LinuxでWiFi接続不可
Feb 112020
 

Arch Linuxで突如WiFiに接続できなくなりまして、ジャーナルを見ていたら以下のようなログが。

[   25.669989] ------------[ cut here ]------------
[   25.670056] WARNING: CPU: 4 PID: 1026 at net/wireless/nl80211.c:7035 nl80211_get_reg_do+0x228/0x290 [cfg80211]
[   25.670059] Modules linked in: sd_mod snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal joydev intel_powerclamp mousedev coretemp kvm_intel uvcvideo videobuf2_vmalloc elan_i2c videobuf2_memops kvm vide
obuf2_v4l2 i915 iTCO_wdt btusb iTCO_vendor_support iwlmvm videobuf2_common snd_hda_intel btrtl btbcm mei_hdcp intel_rapl_msr irqbypass crct10dif_pclmul crc32_pclmul videodev btintel snd_intel_dspcfg mac80211 bluetooth wmi_bmof mc snd_hda_
codec ghash_clmulni_intel intel_wmi_thunderbolt uas usb_storage aesni_intel libarc4 scsi_mod ecdh_generic crypto_simd ecc cryptd i2c_algo_bit snd_hda_core iwlwifi nls_iso8859_1 glue_helper nls_cp437 snd_hwdep intel_cstate vfat drm_kms_hel
per fat snd_pcm intel_uncore intel_rapl_perf psmouse input_leds cfg80211 pcspkr e1000e drm i2c_i801 snd_timer intel_gtt agpgart mei_me thunderbolt nxp_nci_i2c intel_xhci_usb_role_switch syscopyarea mei intel_lpss_pci processor_thermal_dev
ice nxp_nci roles sysfillrect intel_lpss nci
[   25.670124]  intel_rapl_common sysimgblt idma64 ucsi_acpi fb_sys_fops intel_pch_thermal intel_soc_dts_iosf typec_ucsi typec tpm_crb nfc wmi thinkpad_acpi nvram ledtrig_audio rfkill snd tpm_tis tpm_tis_core int3403_thermal battery sound
core int340x_thermal_zone ac tpm int3400_thermal evdev acpi_thermal_rel rng_core mac_hid pkcs8_key_parser crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 serio_raw atkbd libps2 xhci_pci crc32c_intel xhci_hcd i8042 se
rio
[   25.670170] CPU: 4 PID: 1026 Comm: wpa_supplicant Tainted: G        W         5.5.2-arch1-1 #1
[   25.670172] Hardware name: LENOVO 20L7CTO1WW/20L7CTO1WW, BIOS N22ET60W (1.37 ) 11/25/2019
[   25.670214] RIP: 0010:nl80211_get_reg_do+0x228/0x290 [cfg80211]
[   25.670219] Code: 89 ef c7 44 24 0c 01 00 00 00 e8 d3 d2 91 c5 85 c0 74 cc e9 ff fe ff ff 48 89 ef 48 89 04 24 e8 4e 3e be c5 48 8b 04 24 eb 89 <0f> 0b 48 89 ef e8 3e 3e be c5 b8 ea ff ff ff e9 75 ff ff ff b8 97
[   25.670222] RSP: 0018:ffffa63480ebba60 EFLAGS: 00010202
[   25.670226] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
[   25.670228] RDX: ffff8ecc14168008 RSI: 0000000000000000 RDI: ffff8ecc14168300
[   25.670230] RBP: ffff8ecc126c8400 R08: 0000000000000004 R09: ffff8ecc1219c014
[   25.670232] R10: 000000000000001e R11: ffffa63480ebbb20 R12: ffffa63480ebbb20
[   25.670234] R13: ffff8ecc1219c014 R14: 0000000000000000 R15: ffff8ecc14168300
[   25.670238] FS:  00007fd9d44f97c0(0000) GS:ffff8ecc1a700000(0000) knlGS:0000000000000000
[   25.670240] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   25.670243] CR2: 000055b3aed81018 CR3: 0000000630858001 CR4: 00000000003606e0
[   25.670245] Call Trace:
[   25.670267]  genl_rcv_msg+0x1d2/0x480
[   25.670276]  ? __alloc_skb+0x87/0x1d0
[   25.670282]  ? kmalloc_large_node+0x84/0x90
[   25.670289]  ? genl_family_rcv_msg_attrs_parse+0x100/0x100
[   25.670293]  netlink_rcv_skb+0x75/0x140
[   25.670299]  genl_rcv+0x24/0x40
[   25.670304]  netlink_unicast+0x199/0x240
[   25.670309]  netlink_sendmsg+0x243/0x480
[   25.670316]  sock_sendmsg+0x5e/0x60
[   25.670321]  ____sys_sendmsg+0x21b/0x290
[   25.670326]  ? copy_msghdr_from_user+0xe1/0x160
[   25.670333]  ___sys_sendmsg+0x9e/0xe0
[   25.670346]  __sys_sendmsg+0x81/0xd0
[   25.670357]  do_syscall_64+0x4e/0x150
[   25.670365]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   25.670370] RIP: 0033:0x7fd9d485f7b7
[   25.670374] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
[   25.670377] RSP: 002b:00007ffc2b9fa148 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[   25.670380] RAX: ffffffffffffffda RBX: 000055b3aed4d620 RCX: 00007fd9d485f7b7
[   25.670382] RDX: 0000000000000000 RSI: 00007ffc2b9fa180 RDI: 0000000000000004
[   25.670385] RBP: 000055b3aed4d530 R08: 0000000000000004 R09: 000055b3aed4a010
[   25.670387] R10: 00007ffc2b9fa254 R11: 0000000000000246 R12: 000055b3aed7c9d0
[   25.670389] R13: 00007ffc2b9fa180 R14: 00007ffc2b9fa254 R15: 000055b3aed7e130
[   25.670397] ---[ end trace a3d3dd4cae3c209a ]---

wpa_supplicant起動時に発生しているようで、ものは試しにとiwdを使ってみましたが、同じようにエラーになります。いろいろ調べた結果 FS#65041 – Unable to associate with WiFi wireless network with kernel 5.4.7-arch1-1 と同じ症状のようで、rfkillでwlanをunblockedにしたら接続できるようになりました。

$ sudo rfkill unblock wlan

ちなみにrfkillコマンドはutil-linuxパッケージで提供されているのですが、こちらのパッケージではrfkill unblock用のsystemdサービスも用意されていて、以下のとおり有効化することで毎回起動時にunblockされるようになります。

$ sudo systemctl enable rfkill-unblock@wlan.service

Fibocom L-850GLのUSBモデム化その後(2)

 article  Comments Off on Fibocom L-850GLのUSBモデム化その後(2)
Dec 152019
 

何がきっかけかわかりませんがモバイル接続できるようになりました!
IIJmioの タイプDデータ専用SIMです。開発者に感謝!
https://github.com/abrasive/xmm7360

$ mmcli -L
    /org/freedesktop/ModemManager1/Modem/2 [Fibocom Wireless Inc.] L850-GL
$ mmcli -m 2
  -----------------------------
  General  |         dbus path: /org/freedesktop/ModemManager1/Modem/2
           |         device id: adde8d2a200ae40256de3f06bf7f000d71d71f2b
  -----------------------------
  Hardware |      manufacturer: Fibocom Wireless Inc.
           |             model: L850-GL
           | firmware revision: 18500.5001.08.02.24.09
           |      h/w revision: V1.0.4
           |         supported: gsm-umts, lte
           |           current: gsm-umts, lte
           |      equipment id: XXXXXXXXXXXXXXX
  -----------------------------
  System   |            device: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-6
           |           drivers: cdc_mbim
           |            plugin: Fibocom
           |      primary port: cdc-wdm0
           |             ports: cdc-wdm0 (mbim), wwan0 (net)
  -----------------------------
  Numbers  |               own: XXXXXXXXXXX
  -----------------------------
  Status   |    unlock retries: sim-pin2 (3)
           |             state: connected
           |       power state: on
           |       access tech: hsdpa
           |    signal quality: 41% (cached)
  -----------------------------
  Modes    |         supported: allowed: 3g, 4g; preferred: none
           |           current: allowed: 3g, 4g; preferred: none
  -----------------------------
  IP       |         supported: ipv4, ipv6, ipv4v6
  -----------------------------
  3GPP     |              imei: XXXXXXXXXXXXXXX
           |     enabled locks: fixed-dialing
           |       operator id: 44010
           |     operator name: NTT DOCOMO
           |      registration: home
           |               pco: 
           |                    0: (complete) '272280000D04CAE80202000D04CAE80203802110030100108106CAE802028306CAE80203'

  -----------------------------
  SIM      |         dbus path: /org/freedesktop/ModemManager1/SIM/2
  -----------------------------
  Bearer   |         dbus path: /org/freedesktop/ModemManager1/Bearer/1
$ 

ThinkPad T480sのLTEモジュール(Fibocom L-850GL)をUSBモデムとして認識させる

 article  Comments Off on ThinkPad T480sのLTEモジュール(Fibocom L-850GL)をUSBモデムとして認識させる
Oct 222019
 

ThinkPad X1やT480sにはLTEモジュールとしてFibocom L850-GLが搭載できます。こちらWindowsでは問題なく使えるのですがLinuxでは使えません。

Fibocomのサイトに掲載されている仕様ではLinuxもサポートされているように書かれているのですが、これはUSBモードの場合のみのようでLinuxで認識されるPCIeインターフェースの状態では利用できないようです。
Solved: WWAN Fibocom L850-GL and Linux support – Lenovo Communityなどでも語られています。

使える方法がないものかいろいろ散策しておりましたら、「Linux drivers for XMM 7360 LTE #7」の情報を見つけまして、この中のコメントにPCIeからUSBモードにする処理を作成したとの情報を発見。
Tools for the Fibocom L850-GL / Intel XMM7360 LTE modem
ちょっと人柱覚悟でArch Linuxにて試してみましたので覚書です。

ちなみにモデムとしては認識されるようになったもののMobile Network接続はまだうまくできておりません。

まずacpi_callカーネルモジュールをインストールします。

$ sudo pacman -S acpi_call

次に先ほど紹介したgitリポジトリーをcloneします。

$ git clone https://github.com/abrasive/xmm7360.git

変更前にPCIとUSBのデバイスを見てみると、LTEモジュールはPCIで認識されていることがわかります。

$ lspci | grep -i modem
02:00.0 Wireless controller [0d40]: Intel Corporation XMM7360 LTE Advanced Modem (rev 01) $ lsusb | grep -i modem $

先ほどのGitHubからcloneしたxmm2usbを実行してみます。

$ cd xmm7360
$ sudo ./xmm2usb
Found XMM7360 modem at 0000:02:00.0 (_SB_.PCI0.RP04.PXSX) Parent port is at 0000:00:1c.3
Disabling PCIe link… Resetting modem…
OK!
$

PCIリンクを無効にしたとのメッセージ。再びlspciとlsusb実行してみます。

$ lspci | grep -i modem
02:00.0 Wireless controller [0d40]: Intel Corporation XMM7360 LTE Advanced Modem (rev ff)
$ lsusb | grep -i modem
Bus 001 Device 006: ID 8087:095a Intel Corp. MODEM + 2 CDC-ACM + 3 CDC-NCM + SS
$

USBにモデムが出現するようになりました。PCIにも出現していますが、(rev ff)となっています。

続けてGitHubのページにあるように、MBIM(Mobile Broadband Interfaceモード?)へのスイッチを実行します。

$ sudo screen /dev/ttyACM0
AT+GTUSBMODE?
AT+GTUSBMODE=7
AT+CFUN=15
$

そうするとlsusbでの出力が以下に変わりました。

$ lsusb | grep -i fibocom
Bus 001 Device 006: ID 2cb7:0007 Fibocom Wireless Inc. L850-GL

dmesgをみてもUSBモデムと認識されているようです。

[  162.799214] usb 1-6: new high-speed USB device number 5 using xhci_hcd
[  162.940604] usb 1-6: New USB device found, idVendor=8087, idProduct=07f5, bcdDevice= 0.00
[  162.940612] usb 1-6: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  169.651754] usb 1-6: USB disconnect, device number 5
[  175.462630] usb 1-6: new high-speed USB device number 6 using xhci_hcd
[  175.620153] usb 1-6: New USB device found, idVendor=2cb7, idProduct=0007, bcdDevice= 3.33
[  175.620162] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  175.620167] usb 1-6: Product: L850-GL
[  175.620172] usb 1-6: Manufacturer: Fibocom Wireless Inc.
[  175.620176] usb 1-6: SerialNumber: 004999010640000
[  175.738001] cdc_acm 1-6:1.2: ttyACM0: USB ACM device
[  175.738980] cdc_acm 1-6:1.4: ttyACM1: USB ACM device
[  175.739743] cdc_acm 1-6:1.6: ttyACM2: USB ACM device
[  175.740493] usbcore: registered new interface driver cdc_acm
[  175.740494] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[  175.742909] usbcore: registered new interface driver cdc_ncm
[  175.744812] usbcore: registered new interface driver cdc_wdm
[  175.793275] cdc_mbim 1-6:1.0: setting rx_max = 16384
[  175.794443] cdc_mbim 1-6:1.0: cdc-wdm0: USB WDM device
[  175.794574] cdc_mbim 1-6:1.0 wwan0: register 'cdc_mbim' at usb-0000:00:14.0-6, CDC MBIM, a2:a6:4d:05:3f:91
[  175.794616] usbcore: registered new interface driver cdc_mbim

ちなみに冒頭でも述べましたようにMobile Network接続には至っておりません。またPC再起動後は毎回xmm2usbコマンドの実行が必要です。

NetworkManager で resolv.conf の nameserver を設定

 article  Comments Off on NetworkManager で resolv.conf の nameserver を設定
Jul 142018
 

RHEL7/CentOS7系では、resolv.conf の設定は 通常 NetworkManager によっておこなわれます。
通常は ifcfg-* に記述された DNS の値もしくは DHCP サーバーから渡された DNS になると思います。

NetworkManager の設定で、更新後の nameserver を指定するようにしてみます。
こんな感じになります。

$ sudo vi /etc/NetworkManaer/conf.d/dns.conf
$ cat /etc/NetworkManaer/conf.d/dns.conf
[main]
dns=default

[global-dns]
searches=example.test

[global-dns-domain-*]
servers=127.0.0.1, 192.168.110.71

そうすると、NetworkManager 再起動後の resolv.conf 設定は以下になります。

$ cat /etc/resolv.conf
# Generated by NetworkManager
search example.test
nameserver 127.0.0.1
nameserver 192.168.110.71

Windows 10でWi-Fiのプロファイル名を変更する

 article  Comments Off on Windows 10でWi-Fiのプロファイル名を変更する
Feb 072018
 

WindowsでのWi-Fi接続プロファイル名はデフォルトでSSID名になるのでいつも変更するようにしています。
Windows 7の頃は右クリックでリネームのような操作ができたものの、Windows 10では同様の操作がおこなえませんでした。

レジストリを漁って直接変更も考えましたが、netshコマンドでプロファイルを再作成してみます。
プロファイル構成をエクスポート、削除、変更したプロファイル名の構成ファイルで再作成、という段取りになります。

エクスポートします。

>netsh wlan export profile name="旧プロファイル名"

インターフェイス プロファイル "旧プロファイル名" がファイル ".\ワイヤレス ネットワーク接続-旧プロファイル名.xml" に保存されました。

プロファイルを一旦削除します。

>netsh wlan delete profile name="旧プロファイル名"
プロファイル "旧プロファイル名" がインターフェイス "ワイヤレス ネットワーク接続" から削除されます。

エクスポートされた構成ファイルをコピーしてプロファイル名を変更します。

>copy "ワイヤレス ネットワーク接続-旧プロファイル名.xml" "ワイヤレス ネットワーク接続-新プロファイル名.xml"
>notepad "ワイヤレス ネットワーク接続-新プロファイル名.xml"

私のケースでは3行目に記載されていました。

<?xml version="1.0"?>
<WLANProfile xmlns="http://www.microsoft.com/networking/WLAN/profile/v1">
	<name>旧プロファイル名</name>
	<SSIDConfig>
		<SSID>
~ 中略 ~
</WLANProfile>

変更した構成ファイルでプロファイルを作成します。

>netsh wlan add profile filename="ワイヤレス ネットワーク接続-新プロファイル名.xml"
プロファイル "新プロファイル名" がインターフェイス "ワイヤレス ネットワーク接続" に追加されます。

以上で完了です。

ちなみに上記手順での変更後のプロファイル名は、レジストリキー \HKLM\SOFTWARE\Microsoft\WcmSvc の CMPOL 記録されていましたが、こちらを直接変更してプロファイル名を変更できるかは定かではありません。

WinNAT定義の強制削除

 article  Comments Off on WinNAT定義の強制削除
Apr 222017
 

Hyver-V仮想マシン用に設定していたWinNATが動作しなくなりました。

PS C:\WINDOWS\system32> Get-NetNat


Name                             : MyNATnetwork
ExternalIPInterfaceAddressPrefix :
InternalIPInterfaceAddressPrefix : 192.168.0.0/24
IcmpQueryTimeout                 : 30
TcpEstablishedConnectionTimeout  : 1800
TcpTransientConnectionTimeout    : 120
TcpFilteringBehavior             : AddressDependentFiltering
UdpFilteringBehavior             : AddressDependentFiltering
UdpIdleSessionTimeout            : 120
UdpInboundRefresh                : False
Store                            : Local
Active                           : False



PS C:\WINDOWS\system32> 

最後のActive:Falseになっているのが怪しいのですが、Trueにしようと思ってもSet-NetNatコマンドレットにはそのようなオプションはありません。
作り直そうと思っても、削除時にエラーになってしまいます。

PS C:\WINDOWS\system32> Get-NetNat|Remove-NetNat

確認
この操作を実行しますか?
対象 MyNATnetwork の PolicyStore Local に対して操作 Delete を実行しています
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): Y
Remove-NetNat : 要求された操作がサポートされていません。
発生場所 行:1 文字:12
+ Get-NetNat|Remove-NetNat
+            ~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (MSFT_NetNat (In...yNATnetwork;0"):root/StandardCimv2/MSFT_NetNat) [Remove-NetNat]、CimException
    + FullyQualifiedErrorId : Windows System Error 50,Remove-NetNat

PS C:\WINDOWS\system32> 

なんとも方法がわからず途方に暮れていたら以下の記事に同じような事象がありました。
Set up a Hyper-V Virtual Switch using a NAT Network | Thomas Maurer
ちょっとコメントがつぶれていますが、以下のレジストリキーを削除したとのこと。
HKLM\System\CurrentControlSet\Control\NSI\{eb004a20-…..7759bc}\6\

今のままでは他に情報もないので、以下のキーをバックアップして削除してみたところ、Get-NetNatでエントリーが出現しなくなりました。
HKLM\SYSTEM\CurrentControlSet\Control\Nsi\{eb004a20-9b1a-11d4-9123-0050047759bc}\6

PS C:\WINDOWS\system32> Get-NetNat

うーん、これで大丈夫なのかわかりませんが、とりあえずNew-NetNatでの再作成は成功したので暫く経過観察します。

PS C:\WINDOWS\system32> New-NetNat -Name MyNATnetwork -InternalIPInterfaceAddressPrefix 192.168.0.0/24


Name                             : MyNATnetwork
ExternalIPInterfaceAddressPrefix :
InternalIPInterfaceAddressPrefix : 192.168.0.0/24
IcmpQueryTimeout                 : 30
TcpEstablishedConnectionTimeout  : 1800
TcpTransientConnectionTimeout    : 120
TcpFilteringBehavior             : AddressDependentFiltering
UdpFilteringBehavior             : AddressDependentFiltering
UdpIdleSessionTimeout            : 120
UdpInboundRefresh                : False
Store                            : Local
Active                           : True



PS C:\WINDOWS\system32>

ちゃんとActive:Trueになってるし。

プロバイダがIPv6対応したのでDebianに設定

 article  Comments Off on プロバイダがIPv6対応したのでDebianに設定
Apr 132017
 

プロバイダがIPv6サービス提供を開始したので、フレッツ光とプロバイダにそれぞれ申し込んでみました。

フレッツ光でIPv6オプションを申し込んだ直後はNTT東日本のIPv6アドレスが割り当てられます。

gmtx24@debian:~$ ip -6 addr show dev eth0
2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
    inet6 2408:***:****:****:****:****:****:****/64 scope global mngtmpaddr dynamic 
       valid_lft 2591524sec preferred_lft 604324sec
    inet6 2001:c90:****:****:****:****:****:****/64 scope global deprecated mngtmpaddr dynamic 
       valid_lft 2584978sec preferred_lft 0sec
    inet6 fe80::a2b3:ccff:fee9:5cd7/64 scope link 
       valid_lft forever preferred_lft forever
gmtx24@debian:~$ 

次にプロバイダにIPv6オプションを申し込んだ後は、プロバイダ所有のプレフィックスアドレス(伏せてます)に変わりました。

gmtx24@debian:~$ ip -6 addr show dev eth0
2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
    inet6 ****:****:****:****:****:****:****:****/64 scope global mngtmpaddr dynamic
       valid_lft 2591508sec preferred_lft 604308sec
    inet6 fe80::a2b3:ccff:fee9:5cd7/64 scope link
       valid_lft forever preferred_lft forever
gmtx24@debian:~$ 

ルーティングも同様に、NTT東日本からプロバイダに変わります。
フレッツ光のIPv6開通後

gmtx24@debian:~$ ip -6 route show
2001:c90:****:****::/64 dev eth0 proto kernel metric 256  expires 2581221sec pref medium
2408:***:****:****::/64 dev eth0 proto kernel metric 256  expires 2591184sec pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
default via fe80::30ff:fe0c:204d dev eth0 proto ra metric 1024  expires 1755sec hoplimit 64 pref medium
gmtx24@debian:~$ 

プロバイダのIPv6開通後

gmtx24@debian:~$ ip -6 route show
****:****:****::/64 dev eth0 proto kernel metric 256  expires 2591575sec pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
default via fe80::30ff:fe0c:204d dev eth0 proto ra metric 1024  expires 1375sec hoplimit 64 pref medium
gmtx24@debian:~$ 

このままだとMACアドレスベースで生成されたIPv6アドレスが設定されますので、IPv6プライバシー拡張を使ってランダム生成のアドレスにしたい場合は、/etc/network/interfacesに以下の設定をおこないます。

iface eth0 inet6 auto
    privext 2

確認はsysctlコマンドでnet.ipv6.conf.eth0.use_tempaddr=2になっているか、もしくはIPv6 test – IPv6/4 connectivity and speed testに接続してSLAAC noになっているかで確認しました。もちろんIPv6アドレスがMACアドレスベースになっていないことでも確認できます。

※参考
IPv6 プライバシー拡張

NetXMSお試し(1)

 article  Comments Off on NetXMSお試し(1)
Jan 062014
 

NetXMSという監視ツールを見つけまして試しに入れてみました。
スクリーンショットを見る限り洗練されていそうなのと、監視サーバーをWindowsで稼働させらるのも魅力的です。
OpenNMSもWindowsで稼働させることができますが、あちらはSNMPベースの監視が基本でエージェント監視方式ではありません。

タイトルに(1)と謳っていますが続編を書くかは未定です。

Debian用にはバイナリーパッケージが提供されていますので、そちらを利用します。
エージェントおよびサーバーは1台にまとめて稼働させます。

パッケージインストール

aptでインストールできるようsources.listを用意します。

# cat /etc/apt/sources.list.d/netxms.list
# NetXMS
deb http://www.netxms.org/apt squeeze main

エージェント用パッケージ、サーバー用パッケージを一式インストールします。

# apt-get update
# apt-get install netxms-base netxms-server netxms-agent

設定

エージェント用設定ファイルを用意します。

# cat /etc/nxagentd.conf
Servers = 127.0.0.1
ControlServers = 127.0.0.1
MasterServers = 127.0.0.1
LogFile = /var/log/netxms/nxagentd.log
FileStore = /var/lib/netxms/nxagentd

サーバー用設定ファイルを用意します。

# cat /etc/netxmsd.conf
DBDriver = sqlite.ddr
DBName   = /var/lib/netxms/sqlite.db
LogFile  = /var/log/netxms/netxmsd.log

ディレクトリおよびデータベース作成

ディレクトリを作成します。

# mkdir -p /var/log/netxms
# mkdir -p /var/lib/netxms/nxagentd

DBをSQLiteで作成します。

# nxdbmgr init /usr/share/netxms/sql/dbinit_sqlite.sql
# nxdbmgr check

起動

エージェントを起動します。

# systemctl start nxagentd.service

サーバーを起動します。

# systemctl start netxmsd.service

監視コンソールの起動

監視コンソールはWebアプリケーションで稼働するものとEclipseベースで稼働するものの2種類あります。
今回は手早くEclipseベースものをダウンロードページから入手して起動させます。Windows版の場合、圧縮ファイルを展開するとnxmc.exeというバイナリーがありますのでそちらを実行します。
起動するとサーバー名や認証方式を聞かれますので、
Server: netxmsdが起動しているサーバー(4701/tcpを使用します)
Login: admin
Authentication: Password
Password: netxms
を指定するとNetXMSサーバーに接続されます。

開始直後は監視項目はほとんど設定されていません。
Zabbixのように監視テンプレートが予め提供されているわけでもないようですので、ここから個々の監視項目を設定する必要がありそうです(テンプレート化は可能)。

Window XPのRRAS設定(Filter&NAT)

 article  Comments Off on Window XPのRRAS設定(Filter&NAT)
Apr 202011
 

Windows XPで動かすcoLinuxをNATで使いたいのですが、Windows Firewall/Internet Connection Sharing (ICS)ではNATで使用できる内部ネットワークアドレスに制限があります(192.168.0.0/24固定)。
Routing and Remote Access(RRAS)でもNATはできるのですが、ICSのFirewallと共存することはできません。

結局、NATとパケットフィルタリング両方にRRASを使うようにしているので、そちらの設定メモです。

ICSのサービスを止めてRRASサービスを有効にします。

C:\>net stop sharedaccess
C:\>net start remoteaccess

netshのrouting ipコンテキストでフィルタを設定します。

C:\>netsh
netsh>routing ip
netsh routing ip>set filter "Cable" input drop
OK

netsh routing ip>add filter "Cable" input 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 tcp-est 0 0
OK

netsh routing ip>add filter "Cable" input 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp 53 0
OK

netsh routing ip>add filter "Cable" input 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp 123 0
OK

netsh routing ip>add filter "Cable" input 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 icmp any any
OK

netsh routing ip>

設定したフィルタの確認。

netsh routing ip>show filter "Cable"

インターフェイス Cable のフィルタ情報
------------------------------------------------------------------

フラグメント チェックは 無効 です。

フィルタの種類        : INPUT
既定の操作            : DROP

    Src Addr       Src Mask         Dst Addr       Dst Mask      Proto  Src Port  Dst Port
------------------------------------------------------------------------------------------
        0.0.0.0         0.0.0.0         0.0.0.0         0.0.0.0 TCP-EST       0       0
        0.0.0.0         0.0.0.0         0.0.0.0         0.0.0.0    UDP      53       0
        0.0.0.0         0.0.0.0         0.0.0.0         0.0.0.0    UDP     123       0
        0.0.0.0         0.0.0.0         0.0.0.0         0.0.0.0   ICMP       0       0
出力フィルタが構成されていません。
デマンド ダイヤル フィルタが構成されていません。

netsh routing ip>

続いてNAT設定。coLinuxでインストールしたTapインターフェースをPrivate、Cableインターフェースをfullに設定します。

netsh routing ip>nat
netsh routing ip nat>install

netsh routing ip nat>add interface "Cable" full

netsh routing ip nat>add interface "Tap" private

netsh routing ip nat>

NAT設定内容の確認。

netsh routing ip nat>show interface

NAT Cable の構成
---------------------------
モード            : アドレスおよびポートの変換


NAT Tap の構成
---------------------------
モード            : プライベート インターフェイス


netsh routing ip nat>

最後にDNS Proxyを設定して終了。

netsh routing ip nat>dnsproxy
netsh routing ip dnsproxy>install
netsh routing ip dnsproxy>exit


C:\>

PPP Adapterに対するRRASのフィルタはデフォルトDROPらしい

 article  Comments Off on PPP Adapterに対するRRASのフィルタはデフォルトDROPらしい
Apr 102011
 

私はWindows XPのFirewall機能に、標準的なICS(Windows Firewall/Internet Connection Sharing (ICS))ではなくRRAS(Routing and Remote Access)を使っています。
ICSではNATで利用するIPアドレスに制限がある(192.168.0.0/24固定)ことや、RRASのほうがルーター等N/W機器の一般的なフィルタに近い感覚で設定できることが理由です(個々のプログラムレベルでの通信許可はできなくなるので、ウィルスやマルウェア対策面では不安が残りますが)。

で、RRASでは「ローカルエリア接続」等の各N/Wインターフェースに対してデフォルトポリシーを許可ルールを設定しますが、PPP Adapterに関してはこちらに一覧が出現しません。

C:\>netsh routing ip show filter
Input           Output          Demand-dial     Frag. Check     Interface
---------       ----------      -------------   --------------  ----------------
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            ループバック
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            内部
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            VMnet8
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            VMnet1
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            Cable
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            WiFi
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            Tap


C:\>

※普段はInputをDROPにしてますが、テストのためFORWARDに変更しています

デフォルトはFORWARDなのかDROPなのか、リモートからnmapで確認してみました。結論からいうとRRASサービスを有効にしただけでPPP Adapterに対してはDROPの動作になるようです。

RRAS停止状態(net stop remoteaccess)

debian1:~# nmap 183.72.42.159

Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-10 01:35 JST
Nmap scan report for u542159.xgsfmg18.imtp.tachikawa.mopera.net (183.72.42.159)
Host is up (0.15s latency).
Not shown: 988 closed ports
PORT      STATE    SERVICE
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
161/tcp   filtered snmp
445/tcp   filtered microsoft-ds
902/tcp   open     iss-realsecure
912/tcp   open     unknown
2049/tcp  filtered nfs
2869/tcp  open     unknown
8222/tcp  open     unknown
8333/tcp  open     unknown
12345/tcp filtered netbus
31038/tcp open     unknown

Nmap done: 1 IP address (1 host up) scanned in 10.16 seconds
debian1:~#

RRAS開始状態(net start remoteaccess)

debian1:~# nmap 183.72.42.159

Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-10 01:37 JST
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 3.08 seconds
debian1:~#