2026年3月23日月曜日

[FreeBSD] Randomly Ether link down/up issue with "route -n monitor"(kernel Netlink enable /sbin/route ,14.x and later, some USB Ether interface)

[Change History]

2025/09/25 change [Reproduce Steps] from Wireguard to "route -n monitor"
2025/09/27 add NOTE 2(why so many ARP, request in this environment), NOTE3 and workaround
2026/03/23 add links to patch for USB network drivers


Reproduce Steps

  1. connect network
  2. start route -n monitor
  3. start iperf -s on other machine
  4. start iperf on target machine
#!/bin/sh
IPERF_SERVER_IP=[IPERF Server IP]
IPERF=/usr/local/bin/iperf
while [ true ]; do
        ${IPERF} -c ${IPERF_SERVER_IP} -e -i 1
        sleep 1
        ${IPERF} -c ${IPERF_SERVER_IP} -u -e -i 1 --isochronous=60:100m,10m --realtime
        sleep 1
done

expected Result

no link down/up on USB Ethernet(ue)

Result

sometime link down/up on USB Ethernet(ue)

/var/log/messages
Sep 25 09:17:48 amd64 kernel: ue0: link state changed to DOWN
Sep 25 09:17:48 amd64 kernel: ue0: link state changed to UP
Sep 25 09:25:13 amd64 kernel: ue0: link state changed to DOWN
Sep 25 09:25:13 amd64 kernel: ue0: link state changed to UP


output from "route -n monitor"
09:17:48.536 PID 2391 add/repl neigh 192.168.10.254 state REACHABLE lladdr 00:a0:de:xx;xx:xx iface ue0
09:17:48.547 PID 2391 add/repl iface iface#3 ue0 admin UP oper UP mtu 1500
09:17:48.547 PID    0 add/repl iface iface#3 ue0 admin UP oper UP mtu 1500
09:17:48.547 PID    0 add/repl iface iface#3 ue0 admin UP oper UP mtu 1500
09:17:48.547 PID    0 add/repl iface iface#3 ue0 admin UP oper UP mtu 1500
09:17:49.537 PID 2391 add/repl neigh 192.168.10.254 state REACHABLE lladdr 00:a0:de:xx;xx:xx iface ue0

[SNIP]
09:25:12.572 PID 2391 add/repl neigh 192.168.10.254 state REACHABLE lladdr 00:a0:de:xx;xx:xx iface ue0
09:25:13.573 PID 2391 add/repl neigh 192.168.10.254 state REACHABLE lladdr 00:a0:de:xx;xx:xx iface ue0
09:25:13.583 PID 2391 add/repl iface iface#3 ue0 admin UP oper UP mtu 1500
09:25:13.583 PID    0 add/repl iface iface#3 ue0 admin UP oper UP mtu 1500
09:25:13.583 PID    0 add/repl iface iface#3 ue0 admin UP oper UP mtu 1500
09:25:13.583 PID    0 add/repl iface iface#3 ue0 admin UP oper UP mtu 1500
09:25:14.867 PID 2391 add/repl neigh 192.168.10.254 state REACHABLE lladdr 00:a0:de:xx;xx:xx iface ue0
09:25:16.777 PID 2391 add/repl neigh 192.168.10.254 state REACHABLE lladdr 00:a0:de:xx;xx:xx iface ue0

[NOTE 1]

"route -n monitor" command is used on WireGuard(/usr/local/bin/wg-quick shell script)

[NOTE 2]

Here's the reason why so many "state REACHABLE" entries (one to two, or even more, per second) are being outputted by "route -n monitor" in this environment.

When the Ricoh ScanSnap application "ScanSnap Home" is running on a PC (192.168.10.198) and the ScanSnap scanner is powered off, the application sends ARP Request commands to search for the scanner. The FreeBSD box on same subnet reacts to these packets, and they are outputted by route -n monitor. (The application continues to send ARP Requests until it's force-closed).

ScanSnap Home-related Packets
tcpdump results:
14:12:00.058366 ARP, Request who-has 192.168.10.250 tell 192.168.10.198, length 50
14:12:00.058413 ARP, Request who-has 192.168.10.251 tell 192.168.10.198, length 50
14:12:00.058426 ARP, Request who-has 192.168.10.252 tell 192.168.10.198, length 50

route -n monitor results from roughly the same time:
14:12:00.512 PID    0 add/repl neigh 192.168.10.198 state REACHABLE lladdr 00:50:b6:nn:nn:nn iface ue0
14:12:00.029 PID    0 add/repl neigh 192.168.10.198 state REACHABLE lladdr 00:50:b6:nn:nn:nn iface ue0
14:12:00.059 PID    0 add/repl neigh 192.168.10.198 state REACHABLE lladdr 00:50:b6:nn:nn:nn iface ue0

Additionally, ARP Requests are also periodically occurring for a NAT server in the route that is currently offline.

Router's Server Search Packets
tcpdump results:
14:17:35.772158 ARP, Request who-has 192.168.10.10 tell 192.168.10.254, length 50
14:17:36.773378 ARP, Request who-has 192.168.10.10 tell 192.168.10.254, length 50
14:17:37.774597 ARP, Request who-has 192.168.10.10 tell 192.168.10.254, length 50

route -n monitor results from roughly the same time:
14:18:06.709 PID    0 add/repl neigh 192.168.10.254 state REACHABLE lladdr 00:a0:de:nn:nn:nn iface ue0
14:18:08.711 PID    0 add/repl neigh 192.168.10.254 state REACHABLE lladdr 00:a0:de:nn:nn:nn iface ue0

[NOTE 3]

The issue (USB Ethernet link down/up) is that when an Ethernet driver without this problem (e.g., awg0) receives an ARP request, and NetLink processes it and reports it to route -n monitor, the affected USB Ethernet adapter (which is linked up and communicating separately) experiences a link down/up phenomenon despite not receiving the ARP packet on USB Ethernet.

Workaround

The root cause seems to be an issue between Netlink and the Ethernet Driver, but I don't have time to investigate it. Therefore, we're currently using the following workaround for FreeBSD-14 and later.

Workaround1 change /sbin/route

don't printout the neigh change
-
-- sbin/route/route_netlink.c.org      2025-09-27 14:26:39.289721000 +0900
+++ sbin/route/route_netlink.c  2025-09-27 14:27:21.644803000 +0900
@@ -753,7 +753,9 @@

        int groups[] = {
                RTNLGRP_LINK,
+#if 0
                RTNLGRP_NEIGH,
+#endif
                RTNLGRP_NEXTHOP,
 #ifdef INET
                RTNLGRP_IPV4_IFADDR,


Workaround2

just kill "route -n monitor" process after staring the Wireguard.


Current status


FreeBSD VersionCPUEthernet Interfaceenable route monitorreproduce?Notes
15.0-ALPHA2
amd64
ue(axe)AX88772
YESYES[NG]
NONO[OK]
ue(axe)AX88178
YESYES[NG]
NONO[OK]
ue(axge) ELECOM EDC-GUC3L-W
YESYES[NG]
NONO[OK]
ue(ure) Lenovo USB-C to LAN)
YESYES[NG]
NONO[OK]
ue(ure) Planex USB-LAN2500R
YESNO[OK]
NO-
ue(cdce)Lenovo USB-C to LAN
YESNO[OK]
NO-
ue(cdce)Planex USB-LAN2500R
YESNO[OK]
NO-
run(Wi-Fi)
YESNO[OK]
NO-
em0(On board)
YESNO[OK]
NO-
15.0-ALPHA3
arm64
ue(axe)AX88772
YES?
NONO[OK]
ue(axe)AX88178
YES?
NO?
ue(axge) ELECOM EDC-GUC3L-W
YES
unstable, packet loss about 37%(maybe other issue)
,even when disable all options(-txcsum -rxcsum)
NO
ue(ure) Lenovo USB-C to LAN)
YESYES[NG]
NONO[OK]
ue(ure) Planex USB-LAN2500R
YESNO[OK]
write-fin failed: No buffer space available
NO-
ue(cdce)Lenovo USB-C to LAN
YESNO[OK]
NO-
ue(cdce)Planex USB-LAN2500R
YESNO[OK]
NO-
run(Wi-Fi)
YESNO[OK]
NO-
Internal IF(On Board)
YESNO[OK]
NO-
14.3-RELEASE
amd64
ue(axe)
YES?
NO?
arm64
ue(axe)AX88772
YESYES[NG]
NONO[OK]
Internal IFYESNO[OK]Oracle cloud
13.5-RELEASE
amd64
ue(axe)AX88772
YESNO[OK]
arm64YESNO[OK]

  • Could changing the order of the interfaces shown by ifconfig from wg0 to ue0 solve the problem?
    • Result: It won't solve it[NG].
  • disable the ifconfig options (eg. -txcsum -rxcsum)
    • Result: It won't solve it[NG].

Enviroment

USB Ethernet
  • axe: 
    • BUFFALO LUA3-U2-ATX AX88772
      <ASIX Elec. Corp. AX88772, rev 2.00/0.01, addr 2> on usbus0
      ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
              options=80008<VLAN_MTU,LINKSTATE>
      miibus1: <MII bus> on axe0
      ukphy0: <Generic IEEE 802.3u media interface> PHY 16 on miibus1
      ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

    • BUFFALO LUA3-U2-AGT AX88178
      <BUFFALO INC. product 0x006e> at usbus1  ue0:flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> 
      miibus1: <MII bus> on axe0
      e1000phy0: <Marvell 88E1111 Gigabit PHY> PHY 24 on miibus1
      e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow

  • axge
    • ELECOM EDC-GUC3L-W AX8179
      axge0: <ASIX Elec. Corp. AX88179, rev 2.10/1.00, addr 2> on usbus7 miibus0: <MII bus> on axge0 rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 3 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
  • ure
    • Lenovo USB-C to LAN RTL8153
      ure0: <Lenovo Lenovo USB-C to LAN, class 0/0, rev 2.10/31.20, addr 2> on usbus7
      miibus0: <MII bus> on ure0
      rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0
      rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
      options=68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    • Planex USB-LAN2500R
      ure0: <Planex USB 10/100/1G/2.5G LAN, class 0/0, rev 2.10/30.00, addr 2> on usbus7
      options=60009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,RXCSUM_IPV6,TXCSUM_IPV6>

  • cdce (setup info FreeBSD Bugzilla 252165)
  • run0: <Ralink 802.11 n WLAN, class 0/0, rev 2.00/1.01, addr 2> on usbus7
    run0: MAC/BBP RT3071 (rev 0x021C), RF RT3022 (MIMO 2T2R), address 4c:xx:xx:xx:xx
amd64 machine
  • Lenovo ThinkPad T400s

arm64 machines

Related articles


FreeBSD Forums:

FreeBSD Bugzilla
投稿者 時刻: 0 件のコメント:

2026年3月15日日曜日

TOTO製　浴室水栓TMG40CRV39Xの開閉ユニット・ 切り替えハンドル部の交換

 TOTO製　浴室水栓TMG40CRV39Xで、水がうまく止まらなくなり、以下の部品を交換して、快適になりました。

TMG40CRV39XはTMG40CRXと同等で、TMG40CRXの部品一覧から必要な部品を交換しました。Web上で同等品の情報が見つからなかったので、blog記載します。

部品データ: URL

購入部品: 

  • TH577 開閉バルブ部
  • THA1-2 切り替えハンドル部

利用した工具:
  • M＆M ウォータープライヤー250mm (ヨドバシカメラ774円)

ウオータープライヤーは近くのDYIショップユニディー若葉台店で一泊1000円で水道修理道具一式を借りれますが、レンタル代より安かったので、購入しました。サイズ的に250mmが適切なのかはよくわからないです。私の操作が悪かったのか、ナット22319Sを閉める時にすこしなめてしまいました。

交換後の状況
  • 「シャワー」↔「閉め」↔「カラン」の切り替えの「閉め」位置は明確になって、早く交換していればと思いました。以前は「閉め」の位置が不明確でよくシャワーから水が垂れていたのですが、垂れなくなりました。
  • 実際はTH577も高いので、THA1-2をまず交換だけして、それでも改善しない場合はTH577の交換に進んでもよかったのかもしれません。
  • しかし、THA1-2には施工説明書は含まれません。TH577とセットで交換するか、またはWeb上のTH577の施工説明書を参考にTHA1-2の作業をするのが良いと思います。(TH577の部品ページの取扱説明書を参照)

投稿者 時刻: 0 件のコメント:

2026年3月4日水曜日

[Tennis]東京都稲城市周辺の硬式テニスのガットを張ってくれるお店情報

 

お店名最寄り駅など購入ガット持ち込みガット最終確認日備考
カムイ若葉台店1,0003,0002018/5店頭に無いガットも注文すれば入手可能な場合あり(Yonexマルチセンサ125を注文しました)
Tennis Support Center京王線仙川など2,860?2026/1
ラケットショップフジ川崎駅・町田駅・立川駅・八王子駅周辺1,3201,3202026/1
持ち込みガットの場合張り上げまで時間がかかるときあり(2-3日)
テニスショップウェイ新百合ヶ丘小田急線新百合ヶ丘1,1002,2002021/12
ウィンザーテニスショップ聖蹟桜ヶ丘京王線聖蹟桜ヶ丘2,0902,3902021/12
Let's Tennis School京王相模原線若葉台1,6202,1602018
Sports Authority京王相模原線多摩センター8642,1602018/6
スポーツデポ ぐりーんうぉーく多摩店京王相模原線京王堀之内
フジスポーツ 本店(武蔵小杉)武蔵小杉9002,0522018/5
ラック 溝ノ口店武蔵溝ノ口
パパステニスクラブ津久井橋本からバス(Google Maps)2,2002021/12
JeyストリングＪＲ横浜線・成瀬駅(Google Maps)2,2002,9702026/1
Tennis fast-out 4th京王相模原線京王堀之内 (Google Maps)1,100
テニスショップ BOUNCER立川・王子1,650
String Dock ONYVA府中(Google Maps)2,5002026/1テニス用具は定価の20%OFF
Facebook Page
即張りについては、前もって電話なりで要相談
TENNIS SHOP NEO京王線調布(Google Maps)2,6203,0002026/1即張りは予約制
ナチュラル持ち込みは3200円
Racket Works KNOT-TENSIONJR横浜線・淵野辺(Google Maps)2,2002,5002026/3ナチュラル持込 +500
税込み
投稿者 時刻: 0 件のコメント:

2026年2月26日木曜日

Release date table of Android OS Developer Preview/Beta

 

Android OS version171615141312111098.187.1-7.1.176
Release Year20262025202420232022202120202019201820172017201620162015
NameCinnamonBunBaklavaVanilla Ice CreamUpside Down CakeTiramisuSnow ConeRed Velvet CakeQuince TartPieOreoOreoNougatNougatMarshmallow
API level3736353433313029282726252423
Developer Preview 1---11/182/162/82/102/182/19---------------------
Developer Preview 2---12/183/213/83/173/173/183/13(Beta1)3/7(DP1)---3/21(DP1)---3/9(DP1)---
Developer Preview 3---------------4/214/234/3(Beta2)------------4/13(DP2)---
Beta12/131/234/114/124/265/185/6(DP4)5/7(Beta3)5/810/255/17(DP2)10/195/18(DP3)5/28(DP)
Beta22/262/135/155/105/116/96/10(Beta1)6/5(Beta4)6/6---------------
------------7/14(Beta3)---------------------7/9(DP2)
Beta3(Platform Stability)3/136/186/76/88/11(Beta4)7/8(Beta2)7/10(Beta5)7/2---6/8(DP3)---6/15(DP4)8/17
Beta 4(Final Beta)?4/177/187/117/139/8(Beta5)8/6(Beta3)8/7(Beta6)7/25---7/24(DP4)---7/18(DP5)---
------8/10(Beta5)------------------------------
Fina release to AOSP and ecosystem26Q26/109/310/48/1510/49/89/38/612/58/2112/58/2210/5
Public Firmware for Pixel26Q26/1010/1510/48/15
():some old Android OSs(before 12) used different timeline name. So in (), Indicate release name.
←→
NovemberFebruary
DecemberMarch
JanuaryApril
FebrauaryMay
MarchJune
AprilJuly
MayAugust
JuneSeptember
AugustOctober
投稿者 時刻: 0 件のコメント:
登録: コメント (Atom)