"Recent posts
#1
Development and Code Review / Re: netflector available as pl...
Last post by Seimus - Today at 09:39:47 AMLooking forward for this plugin.
I have exactly the same problem/use case as you described + as well a problem with Steam play between PC and TV.
This plugin looks like exactly what I would need.
Fingers crossed it will be adopted by FBSD sooner than later!
Regards,
S.
I have exactly the same problem/use case as you described + as well a problem with Steam play between PC and TV.
This plugin looks like exactly what I would need.
Fingers crossed it will be adopted by FBSD sooner than later!
Regards,
S.
#2
26.7 Series / Re: os-upnp plugin not working...
Last post by bamf - Today at 09:28:06 AMSeeing the same hier with translation target ?.
Code Select
nat log quick on pppoe0 inet proto udp from 192.168.100.21 port = 47141 to any keep state label "PCP MAP b939ca8f21f0c995ee240a6e" rtable 0 -> ? port 47141
rdr pass log quick on pppoe0 inet proto tcp from any to any port = 47141 keep state label "PCP MAP 0f926edb0b878a8d23d54b58" rtable 0 -> ? port 47141 #3
26.7 Series / Dpinger uses ULA as source aft...
Last post by netotter - Today at 09:13:48 AMOn 26.7.2_2 DHCP6 interface outage results in dpinger using ULA source address after outage and restored connection. I am not sure if this started with 26.7 but it's the first time I observed this using 26.7. I can also reproduce this by disconnecting the router manually.
Before outage dpinger works as expected and uses GUA as source address for pinging and gets normal responses.
After a longer (don't know the exact time, several minutes to an hour) outage connection is restored but dpinger thinks the connection is down because it does not get replies. The reason is that ping source address is changed to ULA and the router does not accept that and no pinging happens.
Dpinger runs with right GUA source address in the -B parameter:
root@opns1:~ # ps axuww | grep INTERNET_DHCP6
root 51553 0.0 0.1 14716 2812 - Is 07:12 0:00.02 /usr/local/bin/dpinger -f -S -r 0 -i INTERNET_DHCP6 -B 2a0d:a:b:c:d:e:f:2d93 -p /var/run/dpinger_INTERNET_DHCP6.pid -u /var/run/dpinger_INTERNET_DHCP6.sock -s 1s -l 4s -t 60s -d 1 2001:4860:4860::8888
Ping packets have anyway ULA as their source:
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:02:53.428522 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 50428, seq 14719, length 9
07:02:53.429161 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
07:02:54.428627 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 50428, seq 14720, length 9
07:02:54.429308 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
Manually pinging another destination with same GUA as source works:
root@opns1:~ # ping6 -I vlan0.9 -S 2a0d:a:b:c:d:e:f:2d93 2606:4700:4700::1001
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:02:57.844648 IP6 2a0d:a:b:c:d:e:f:2d93 > 2606:4700:4700::1001: ICMP6, echo request, id 6941, seq 0, length 16
07:02:57.877492 IP6 2606:4700:4700::1001 > 2a0d:a:b:c:d:e:f:2d93: ICMP6, echo reply, id 6941, seq 0, length 16
07:02:58.846441 IP6 2a0d:a:b:c:d:e:f:2d93 > 2606:4700:4700::1001: ICMP6, echo request, id 6941, seq 1, length 16
07:02:58.874800 IP6 2606:4700:4700::1001 > 2a0d:a:b:c:d:e:f:2d93: ICMP6, echo reply, id 6941, seq 1, length 16
root@opns1:~ # route -n get -inet6 2001:4860:4860::8888
route to: 2001:4860:4860::8888
destination: 2001:4860:4860::8888
gateway: fe80::bb:ccff:fedd:2e0%vlan0.9
fib: 0
interface: vlan0.9
flags: <UP,GATEWAY,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0
root@opns1:~ # ifconfig vlan0.9
vlan0.9: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: Internet (opt22)
options=4000000<MEXTPG>
ether 00:aa:bb:cc:2d:93
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 vhid 187
inet6 fe80::bb:ccff:fedd:2d93%vlan0.9 prefixlen 64 scopeid 0x1c
inet6 fdfe:a:b:c:d:e:f:2d93 prefixlen 64 autoconf
inet6 2a0d:a:b:c:d:e:f:2d93 prefixlen 64 autoconf pltime 121 vltime 271
groups: vlan
carp: MASTER vhid 187 advbase 1 advskew 1
peer 224.0.0.18 peer6 ff02::12
vlan: 9 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
I have IPv4 static and carp address on the same interface as DHCP6. Does that mess things up? This interface vlan0.9/opt22 is also the secondary IPv6 gateway if that gives any hint where this problem might originate from.
Restarting dpinger does not solve the situation.
root@opns1:~ # pluginctl -s dpinger restart INTERNET_DHCP6
Service `dpinger[INTERNET_DHCP6]' has been restarted.
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:10:25.486875 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 64742, seq 11, length 9
07:10:25.487554 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
07:10:26.486944 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 64742, seq 12, length 9
07:10:26.487636 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
Reconfiguring the interface and restarting dpinger:
root@opns1:~ # configctl interface reconfigure opt22
OK
root@opns1:~ # pluginctl -s dpinger restart INTERNET_DHCP6
Service `dpinger[INTERNET_DHCP6]' has been restarted.
Works and dpinger starts to use correct GUA source address 2a0d:a:b:c:d:e:f:2d93 again.
The only change I can see is the order of inet6 addresses returned by ifconfig and route information for the dpinger destination.
root@opns1:~ # ifconfig vlan0.9
vlan0.9: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: Internet (opt22)
options=4000000<MEXTPG>
ether 00:aa:bb:cc:2d:93
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 vhid 187
inet6 fe80::bb:ccff:fedd:2d93%vlan0.9 prefixlen 64 scopeid 0x1c
inet6 2a0d:a:b:c:d:e:f:2d93 prefixlen 64 autoconf pltime 121 vltime 271
inet6 fdfe:a:b:c:d:e:f:2d93 prefixlen 64 autoconf
groups: vlan
carp: MASTER vhid 187 advbase 1 advskew 1
peer 224.0.0.18 peer6 ff02::12
vlan: 9 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
root@opns1:~ # route -n get -inet6 2001:4860:4860::8888
route to: 2001:4860:4860::8888
destination: ::
mask: ::
gateway: fde7:a:b:c:d:e:f:11 (this is the primary default gw for IPv6)
fib: 0
interface: vlan0.11
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0
Before outage dpinger works as expected and uses GUA as source address for pinging and gets normal responses.
After a longer (don't know the exact time, several minutes to an hour) outage connection is restored but dpinger thinks the connection is down because it does not get replies. The reason is that ping source address is changed to ULA and the router does not accept that and no pinging happens.
Dpinger runs with right GUA source address in the -B parameter:
root@opns1:~ # ps axuww | grep INTERNET_DHCP6
root 51553 0.0 0.1 14716 2812 - Is 07:12 0:00.02 /usr/local/bin/dpinger -f -S -r 0 -i INTERNET_DHCP6 -B 2a0d:a:b:c:d:e:f:2d93 -p /var/run/dpinger_INTERNET_DHCP6.pid -u /var/run/dpinger_INTERNET_DHCP6.sock -s 1s -l 4s -t 60s -d 1 2001:4860:4860::8888
Ping packets have anyway ULA as their source:
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:02:53.428522 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 50428, seq 14719, length 9
07:02:53.429161 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
07:02:54.428627 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 50428, seq 14720, length 9
07:02:54.429308 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
Manually pinging another destination with same GUA as source works:
root@opns1:~ # ping6 -I vlan0.9 -S 2a0d:a:b:c:d:e:f:2d93 2606:4700:4700::1001
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:02:57.844648 IP6 2a0d:a:b:c:d:e:f:2d93 > 2606:4700:4700::1001: ICMP6, echo request, id 6941, seq 0, length 16
07:02:57.877492 IP6 2606:4700:4700::1001 > 2a0d:a:b:c:d:e:f:2d93: ICMP6, echo reply, id 6941, seq 0, length 16
07:02:58.846441 IP6 2a0d:a:b:c:d:e:f:2d93 > 2606:4700:4700::1001: ICMP6, echo request, id 6941, seq 1, length 16
07:02:58.874800 IP6 2606:4700:4700::1001 > 2a0d:a:b:c:d:e:f:2d93: ICMP6, echo reply, id 6941, seq 1, length 16
root@opns1:~ # route -n get -inet6 2001:4860:4860::8888
route to: 2001:4860:4860::8888
destination: 2001:4860:4860::8888
gateway: fe80::bb:ccff:fedd:2e0%vlan0.9
fib: 0
interface: vlan0.9
flags: <UP,GATEWAY,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0
root@opns1:~ # ifconfig vlan0.9
vlan0.9: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: Internet (opt22)
options=4000000<MEXTPG>
ether 00:aa:bb:cc:2d:93
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 vhid 187
inet6 fe80::bb:ccff:fedd:2d93%vlan0.9 prefixlen 64 scopeid 0x1c
inet6 fdfe:a:b:c:d:e:f:2d93 prefixlen 64 autoconf
inet6 2a0d:a:b:c:d:e:f:2d93 prefixlen 64 autoconf pltime 121 vltime 271
groups: vlan
carp: MASTER vhid 187 advbase 1 advskew 1
peer 224.0.0.18 peer6 ff02::12
vlan: 9 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
I have IPv4 static and carp address on the same interface as DHCP6. Does that mess things up? This interface vlan0.9/opt22 is also the secondary IPv6 gateway if that gives any hint where this problem might originate from.
Restarting dpinger does not solve the situation.
root@opns1:~ # pluginctl -s dpinger restart INTERNET_DHCP6
Service `dpinger[INTERNET_DHCP6]' has been restarted.
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:10:25.486875 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 64742, seq 11, length 9
07:10:25.487554 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
07:10:26.486944 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 64742, seq 12, length 9
07:10:26.487636 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
Reconfiguring the interface and restarting dpinger:
root@opns1:~ # configctl interface reconfigure opt22
OK
root@opns1:~ # pluginctl -s dpinger restart INTERNET_DHCP6
Service `dpinger[INTERNET_DHCP6]' has been restarted.
Works and dpinger starts to use correct GUA source address 2a0d:a:b:c:d:e:f:2d93 again.
The only change I can see is the order of inet6 addresses returned by ifconfig and route information for the dpinger destination.
root@opns1:~ # ifconfig vlan0.9
vlan0.9: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: Internet (opt22)
options=4000000<MEXTPG>
ether 00:aa:bb:cc:2d:93
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 vhid 187
inet6 fe80::bb:ccff:fedd:2d93%vlan0.9 prefixlen 64 scopeid 0x1c
inet6 2a0d:a:b:c:d:e:f:2d93 prefixlen 64 autoconf pltime 121 vltime 271
inet6 fdfe:a:b:c:d:e:f:2d93 prefixlen 64 autoconf
groups: vlan
carp: MASTER vhid 187 advbase 1 advskew 1
peer 224.0.0.18 peer6 ff02::12
vlan: 9 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
root@opns1:~ # route -n get -inet6 2001:4860:4860::8888
route to: 2001:4860:4860::8888
destination: ::
mask: ::
gateway: fde7:a:b:c:d:e:f:11 (this is the primary default gw for IPv6)
fib: 0
interface: vlan0.11
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0
#4
Hardware and Performance / Re: Warning about RealTek adap...
Last post by meyergru - Today at 08:28:06 AMThat is perfectly possible, but see #24.
I have to make three corrections to formerly discussed points, though:
1. PCIe actually has its own mechanisms for data-integrity protection between the card and CPU/chipset: LCRC with link-level replay can detect and recover transmission errors, ECRC can provide additional end-to-end error detection, and AER can report PCIe errors.
This means that the observed data corruption may have occurred somewhere outside the portion protected by PCIe's link-level CRC/replay mechanism.
2. The X570S chipset was formerly believed to be different from the X570, yet there is no proof of that. On the contrary, ASRock said it was only fine-tuning that made passive cooling possible. Other manufacturers made claims to this as well.
3. In the meantime, my counter-proof to the PCIe initialisation on warm boots was contradicted - see: https://github.com/torvalds/linux/commit/ae1737e7339b513f8c2fc21b500a0fc215d155c3 and https://bugzilla.kernel.org/show_bug.cgi?id=220770
Maybe this was an implementation fault in either the Windows driver, defective NICs or bad board layout on Asrock's behalf - I cannot tell nor investigate, because I do not have the cards any more. All I can say is that the problems existed and were solved by switching to the other NIC - which also has the advantage of being able to fully use 10 GbE over my 17m CAT5 link, which could not reliably be achieved with either an X550 or X540 before.
On a side note: chalk those inaccuracies up to my discontent about having to investigate such problems for weeks when I just wanted to have more speed on my main workstation.
I have to make three corrections to formerly discussed points, though:
1. PCIe actually has its own mechanisms for data-integrity protection between the card and CPU/chipset: LCRC with link-level replay can detect and recover transmission errors, ECRC can provide additional end-to-end error detection, and AER can report PCIe errors.
This means that the observed data corruption may have occurred somewhere outside the portion protected by PCIe's link-level CRC/replay mechanism.
2. The X570S chipset was formerly believed to be different from the X570, yet there is no proof of that. On the contrary, ASRock said it was only fine-tuning that made passive cooling possible. Other manufacturers made claims to this as well.
3. In the meantime, my counter-proof to the PCIe initialisation on warm boots was contradicted - see: https://github.com/torvalds/linux/commit/ae1737e7339b513f8c2fc21b500a0fc215d155c3 and https://bugzilla.kernel.org/show_bug.cgi?id=220770
Maybe this was an implementation fault in either the Windows driver, defective NICs or bad board layout on Asrock's behalf - I cannot tell nor investigate, because I do not have the cards any more. All I can say is that the problems existed and were solved by switching to the other NIC - which also has the advantage of being able to fully use 10 GbE over my 17m CAT5 link, which could not reliably be achieved with either an X550 or X540 before.
On a side note: chalk those inaccuracies up to my discontent about having to investigate such problems for weeks when I just wanted to have more speed on my main workstation.
#5
26.7 Series / Re: Interfaces: Virtual IPs: S...
Last post by franco - Today at 08:05:44 AM> community/25.1/25.1.3:o interfaces: remove defunct "other" VIP type
To our knowledge it wasn't even creating a VIP, just being selectable in some legacy pages as a single pseudo-alias and we simply did not want to bring this cruft into MVC to ease future maintenance burden.
Cheers,
Franco
To our knowledge it wasn't even creating a VIP, just being selectable in some legacy pages as a single pseudo-alias and we simply did not want to bring this cruft into MVC to ease future maintenance burden.
Cheers,
Franco
#6
26.7 Series / Re: 26.7 upgrade failure - ope...
Last post by franco - Today at 07:59:00 AM> Google told me to "opnsense-update -p -A 26.7"
Which doesn't do anything for you.
Please post the health audit first. OP didn't post it either. Hard to diagnose, but:
> Looks like a partial upgrade with base/kernel on 26.7 and packages still at 26.1.
Still my assumption here.
Cheers,
Franco
Which doesn't do anything for you.
Please post the health audit first. OP didn't post it either. Hard to diagnose, but:
> Looks like a partial upgrade with base/kernel on 26.7 and packages still at 26.1.
Still my assumption here.
Cheers,
Franco
#7
French - Français / OPNsense chez mes clients PME ...
Last post by Souad - Today at 05:41:57 AMSalut à tous, ça fait maintenant plusieurs années que je gère le parc OPNsense d'une douzaine de PME sur Saint-Étienne et la Loire, avec quelques clients aussi sur Lyon.
Du VPN site-à-site, des règles NAT à revoir régulièrement, des migrations de temps en temps. Il y a environ deux mois j'ai terminé une migration chez un cabinet comptable, tout le le VPN site-à-site à remonter proprement entre leurs deux sites, et ça m'a pris un temps fou. Le genre de mission où t'es à fond dessus pendant des jours et où pendant ce temps là tu prospectes zéro. Et c'est là que je me suis dit, bon, à ce rythme je vais jamais développer mon portefeuille toute seule. Voilà. Entre le technique et l'administratif j'ai déjà plus vraiment de créneau pour aller démarcher des nouvelles PME. Du coup je suis passée par pour publier une annonce et voir si je pouvais trouver un agent commercial indépendant qui présente mes prestations OPNsense à des PME que je n'ai pas le temps de démarcher.
J'ai reçu quelques profils en une dizaine de jours, franchement plus vite que ce que j'imaginais. Après je découvre un peu le système, je viens plutôt du monde technique donc gérer une relation avec un commercial terrain c'est nouveau pour moi... Si certains ici ont déjà mis en place ce genre de fonctionnement pour leur activité de conseil, je suis preneuse de retours sur comment vous cadrez les mandats. Merci d'avance pour vos retours
Du VPN site-à-site, des règles NAT à revoir régulièrement, des migrations de temps en temps. Il y a environ deux mois j'ai terminé une migration chez un cabinet comptable, tout le le VPN site-à-site à remonter proprement entre leurs deux sites, et ça m'a pris un temps fou. Le genre de mission où t'es à fond dessus pendant des jours et où pendant ce temps là tu prospectes zéro. Et c'est là que je me suis dit, bon, à ce rythme je vais jamais développer mon portefeuille toute seule. Voilà. Entre le technique et l'administratif j'ai déjà plus vraiment de créneau pour aller démarcher des nouvelles PME. Du coup je suis passée par pour publier une annonce et voir si je pouvais trouver un agent commercial indépendant qui présente mes prestations OPNsense à des PME que je n'ai pas le temps de démarcher.
J'ai reçu quelques profils en une dizaine de jours, franchement plus vite que ce que j'imaginais. Après je découvre un peu le système, je viens plutôt du monde technique donc gérer une relation avec un commercial terrain c'est nouveau pour moi... Si certains ici ont déjà mis en place ce genre de fonctionnement pour leur activité de conseil, je suis preneuse de retours sur comment vous cadrez les mandats. Merci d'avance pour vos retours
#8
Hardware and Performance / Re: Warning about RealTek adap...
Last post by moonman - Today at 01:02:19 AMI have x570 motherboard (AsRock x570 Phantom Gaming 4) with 5950x. I used to have AQC113 (non-C) installed into the bottom PCIe x1 slot and it was working fine at Gen4 speeds. The card itself was x4, but AsRock has those open ended slots where you can actually insert any card in them. I also made sure to get AQC113 and not AQC113C or other variant as that the one wiht PCIe Gen4 support. HWINFO64 confirmed it was Gen4 x1 speeds and iperf3 as well. The only problem was that every time I made my computer go to sleep it would come back with a non-working LAN. I had to reboot (or hibernate) for the card to start working again.
I bought rtl8127 card from amazon and it's working flawlessly in the same slot now. No issues at all.
My point, meyergru, it could be just your particular motherboard and not all x570 motherboards out there.
I bought rtl8127 card from amazon and it's working flawlessly in the same slot now. No issues at all.
My point, meyergru, it could be just your particular motherboard and not all x570 motherboards out there.
#9
26.7 Series / Re: Another 26.7 "Upgrade Fail...
Last post by Patrick M. Hausen - Today at 12:41:46 AMQuote from: cookiemonster on August 16, 2026, 10:42:25 PMWhat makes you think that you need to install the bootloader to the secondary drive?
How are you going to boot from the secondary drive when the primary one fails?
#10
26.7 Series / Re: No install on my new CWWK
Last post by jxxaxxy - Today at 12:26:58 AMYour welcome. I had to do the same thing when upgrading failed due to UFS and I have an n200 mini pc. I wanted to switch over to ZFS anyways so it wasn't that big of a deal. Just not sure why the underlying OS has the issue with UFS after it worked well for so long.
