VERY slow System Update

stephenw10

Mmm, not that then. It would fail to get that file with fetch too. I assume that firewall doesn't actually have IPv6 connectivity at all?

What happens if you run pkg-static -d up-date ?
It complete that in a few seconds. Does it stall anywhere?

Steve

Sergei_Shablovsky

@stephenw10 said in VERY slow System Update:

Mmm, not that then. It would fail to get that file with fetch too. I assume that firewall doesn't actually have IPv6 connectivity at all?

What happens if you run pkg-static -d up-date ?

pkg-static -d update

[2.6.0-DEVELOPMENT][gamma-fw-dev.local.lan]/root: pkg-static -d update
DBG(1)[52270]> pkg initialized
Updating pfSense-core repository catalogue...
DBG(1)[52270]> PkgRepo: verifying update for pfSense-core
DBG(1)[52270]> Pkgrepo, begin update of '/root/var/db/pkg/repo-pfSense-core.sqlite'
DBG(1)[52270]> Request to fetch pkg+https://packages-beta.netgate.com/packages/pfSense_master_amd64-core/meta.conf
DBG(1)[52270]> opening libfetch fetcher
DBG(1)[52270]> Fetch > libfetch: connecting
DBG(1)[52270]> Fetch: fetching from: https://files00.netgate.com/packages/pfSense_master_amd64-core/meta.conf with opts "i"
DBG(1)[52270]> Fetch: fetcher chosen: https
DBG(1)[52270]> Request to fetch pkg+https://packages-beta.netgate.com/packages/pfSense_master_amd64-core/packagesite.pkg
DBG(1)[52270]> opening libfetch fetcher
DBG(1)[52270]> Fetch > libfetch: connecting
DBG(1)[52270]> Fetch: fetching from: https://files00.netgate.com/packages/pfSense_master_amd64-core/packagesite.pkg with opts "i"
DBG(1)[52270]> Fetch: fetcher chosen: https
DBG(1)[52270]> Request to fetch pkg+https://packages-beta.netgate.com/packages/pfSense_master_amd64-core/packagesite.txz
DBG(1)[52270]> opening libfetch fetcher
DBG(1)[52270]> Fetch > libfetch: connecting
DBG(1)[52270]> Fetch: fetching from: https://files00.netgate.com/packages/pfSense_master_amd64-core/packagesite.txz with opts "i"
DBG(1)[52270]> Fetch: fetcher chosen: https
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
DBG(1)[52270]> PkgRepo: verifying update for pfSense
DBG(1)[52270]> Pkgrepo, begin update of '/root/var/db/pkg/repo-pfSense.sqlite'
DBG(1)[52270]> Request to fetch pkg+https://packages-beta.netgate.com/packages/pfSense_master_amd64-pfSense_devel/meta.conf
DBG(1)[52270]> opening libfetch fetcher
DBG(1)[52270]> Fetch > libfetch: connecting
DBG(1)[52270]> Fetch: fetching from: https://files01.netgate.com/packages/pfSense_master_amd64-pfSense_devel/meta.conf with opts "i"
DBG(1)[52270]> Fetch: fetcher chosen: https
DBG(1)[52270]> Request to fetch pkg+https://packages-beta.netgate.com/packages/pfSense_master_amd64-pfSense_devel/packagesite.pkg
DBG(1)[52270]> opening libfetch fetcher
DBG(1)[52270]> Fetch > libfetch: connecting
DBG(1)[52270]> Fetch: fetching from: https://files01.netgate.com/packages/pfSense_master_amd64-pfSense_devel/packagesite.pkg with opts "i"
DBG(1)[52270]> Fetch: fetcher chosen: https
DBG(1)[52270]> Request to fetch pkg+https://packages-beta.netgate.com/packages/pfSense_master_amd64-pfSense_devel/packagesite.txz
DBG(1)[52270]> opening libfetch fetcher
DBG(1)[52270]> Fetch > libfetch: connecting
DBG(1)[52270]> Fetch: fetching from: https://files01.netgate.com/packages/pfSense_master_amd64-pfSense_devel/packagesite.txz with opts "i"
DBG(1)[52270]> Fetch: fetcher chosen: https
pfSense repository is up to date.
All repositories are up to date.

It complete that in a few seconds. Does it stall anywhere?

No stall.
But no few sec
approx 12sec to complete

Thank You for help.

Sergei_Shablovsky

@stephenw10

iperf3 from the pfSense itself also good
(it was downloading some updates from office lan, so 67-75 Mbits/sec is ok in this case)

[2.6.0-DEVELOPMENT][root@gamma-fw-dev.local.lan]/root: iperf3 -c iperf.scottlinux.com
Connecting to host iperf.scottlinux.com, port 5201
[  5] local AAA.BBB.CCC.DDD port 17173 connected to 45.33.39.39 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   348 KBytes  2.85 Mbits/sec    0    122 KBytes
[  5]   1.00-2.00   sec  4.75 MBytes  39.9 Mbits/sec    0   3.00 MBytes
[  5]   2.00-3.00   sec  8.46 MBytes  71.0 Mbits/sec    0   3.00 MBytes
[  5]   3.00-4.00   sec  8.59 MBytes  72.1 Mbits/sec    0   3.00 MBytes
[  5]   4.00-5.00   sec  8.51 MBytes  71.4 Mbits/sec    0   3.00 MBytes
[  5]   5.00-6.00   sec  8.29 MBytes  69.5 Mbits/sec    0   3.00 MBytes
[  5]   6.00-7.00   sec  8.33 MBytes  69.9 Mbits/sec    0   3.00 MBytes
[  5]   7.00-8.00   sec  8.42 MBytes  70.7 Mbits/sec    0   3.00 MBytes
[  5]   8.00-9.00   sec  8.59 MBytes  72.1 Mbits/sec    0   3.00 MBytes
[  5]   9.00-10.00  sec  8.24 MBytes  69.1 Mbits/sec    0   3.00 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  72.5 MBytes  60.8 Mbits/sec    0             sender
[  5]   0.00-10.20  sec  72.5 MBytes  59.7 Mbits/sec                  receiver

iperf Done.

stephenw10

So, to confirm, you do not have a routable IPv6 IP on that firewall?

Just to be sure try running:

fetch -4 -o /dev/null https://files00.netgate.com/packages/pfSense_master_amd64-core/All/pfSense-kernel-debug-pfSense-2.6.0.a.20211008.0500.pkg

Compare that with:

fetch -6 -o /dev/null https://files00.netgate.com/packages/pfSense_master_amd64-core/All/pfSense-kernel-debug-pfSense-2.6.0.a.20211008.0500.pkg

The issue I hit yesterday was a local setting I had forgotten about.
As far as I know there are no issues with the repo.

Steve

Sergei_Shablovsky

@stephenw10 said in VERY slow System Update:

So, to confirm, you do not have a routable IPv6 IP on that firewall?

Just to be sure try running:
fetch -4 -o /dev/null https://files00.netgate.com/packages/pfSense_master_amd64-core/All/pfSense-kernel-debug-pfSense-2.6.0.a.20211008.0500.pkg

[2.6.0-DEVELOPMENT][root@gamma-fw-dev.local.lan]/root: fetch -4 -o /dev/null https://files00.netgate.com/packages/pfSense_master_amd64-core/All/pfSense-kernel-debug-pfSense-2.6.0.a.20211008.0500.pkg
/dev/null                                       0% of   86 MB 6851  Bps 03h35m

Compare that with:
fetch -6 -o /dev/null https://files00.netgate.com/packages/pfSense_master_amd64-core/All/pfSense-kernel-debug-pfSense-2.6.0.a.20211008.0500.pkg
The issue I hit yesterday was a local setting I had forgotten about.
As far as I know there are no issues with the repo.

[2.6.0-DEVELOPMENT][root@gamma-fw-dev.local.lan]/root: fetch -6 -o /dev/null https://files00.netgate.com/packages/pfSense_master_amd64-core/All/pfSense-kernel-debug-pfSense-2.6.0.a.20211008.0500.pkg
fetch: https://files00.netgate.com/packages/pfSense_master_amd64-core/All/pfSense-kernel-debug-pfSense-2.6.0.a.20211008.0500.pkg: No route to host

Sergei_Shablovsky

@stephenw10 said in VERY slow System Update:

The issue I hit yesterday was a local setting I had forgotten about.
As far as I know there are no issues with the repo.

More that sure the repo are OK

stephenw10

Hmm, so something specifically to that host from where you are.

MTU problem?

You see the same in files00 and files01?

Sergei_Shablovsky

@stephenw10 said in VERY slow System Update:

Hmm, so something specifically to that host from where you are.

MTU problem?

I do not make any modification in NIC settings.

You see the same in files00 and files01?

Yes, the same

stephenw10

@sergei_shablovsky said in VERY slow System Update:

I do not make any modification in NIC settings.

That doesn't mean something didn't change in the route though.

What do you see in a packet capture of the traffic? A lot of fragmentation perhaps?

Sergei_Shablovsky

@stephenw10 said in VERY slow System Update:

Hmm, so something specifically to that host from where you are.

To this pfSense we have 2 WAN with static IPs from local ISP.

MTU problem?

I was a little play with this: 1500, 1350 - not solving my problem.

Sergei_Shablovsky

@stephenw10 said in VERY slow System Update:

@sergei_shablovsky said in VERY slow System Update:

I do not make any modification in NIC settings.

That doesn't mean something didn't change in the route though.

What do you see in a packet capture of the traffic? A lot of fragmentation perhaps?

But if fragmentation or something miss-working on a TCP level, iperf also could be affected. But iperf working as many days before - the same measurement.

Please point me with sample what You mean about “measuring level of fragmentation by packet capturing”.

Thank You for help. This issue slowly make me sad...

stephenw10

Indeed iperf would also be affected if it was going over the same route but that's unlikely. We ca say whatever part of the route that is shared does not have a problem.

Run a pcap for traffic to/from the update server. Look for fragmentation.

Steve

Sergei_Shablovsky

@stephenw10 said in VERY slow System Update:

Indeed iperf would also be affected if it was going over the same route but that's unlikely. We ca say whatever part of the route that is shared does not have a problem.

Run a pcap for traffic to/from the update server. Look for fragmentation.

Thank You, Steve for suggestions!

No fragmentation, checked at the first step.

BTW, when doing “pkg upgrade” from command line on local console, after downloading first packet the output from pkg looks like stopped. No, system working and no freeze, all other LANs working...

I even trying to “pkg unlock -a”, but this also no impact on situation...

stephenw10

So it sends and then never receives a reply? And doesn't just timeout?

That sounds more like something broken in the pkg system locally.

Steve

Sergei_Shablovsky

@stephenw10 said in VERY slow System Update:

So it sends and then never receives a reply? And doesn't just timeout?

Thank You for patience with this case, Steve.

Not looks like this.

When come into local shell, trying to make manually

pkg upgrade

after depositories checks, the packet downloading process starting, even first .pkg in Queue downloaded fast (at 70-90Mb/s), but after this first .pkg (or just from start of Queue), the download speed on screen indicated as

16,4kB/s 01:43:17ETA

(this is for pfSense-kernel-pfSense-2.6.0.a.20211029.0500.pkg fetching for example)
and on a big .pkg size connection closed, may be from the NetGate updates server side

Let me remind, any other downloads or third party .pkg downloaded on full available bandwidth, I test this more than triple-twice.

That sounds more like something broken in the pkg system locally.

I also thinking about this, so try to pkg unlock -a, purging pkg cache....
But still unsuccessfully...

[UPDATE]
Today I have a little bit more time to make some experiments. And found that the SLOW speed only for 2nd, 3rd, and down the list .pkg files, but FIRST FILE ALWAYS DOWNLOADING AT FULL AVAILABLE BANDWITH. (i.e. from 24 to 80MB/s).q

stephenw10

Hmm, that really looks like a routing issue or an IPv6 issue. But I believe we already ruled that out?

Do you have a VPN or some other tunnel you could try to route that traffic across as a test?

Steve

Sergei_Shablovsky

@stephenw10
Today I have a little bit more time to make some experiments. And found that the SLOW speed only for 2nd, 3rd, and down the list .pkg files, but FIRST FILE ALWAYS DOWNLOADING AT FULL AVAILABLE BANDWITH. (i.e. from 24 to 80MB/s).

Sergei_Shablovsky

@stephenw10 said in VERY slow System Update:

Hmm, that really looks like a routing issue or an IPv6 issue. But I believe we already ruled that out?

The routing - is the first that I thinking on. But if something wrong with routing **why this not impact on any other traffic from/to any other destination/source.

Do you have a VPN or some other tunnel you could try to route that traffic across as a test?

I'm a little bit stupid today, could You be so please to write in details what exactly you mean and how doing that? Thx a lot!!!

stephenw10

If there is something specifically in the route that traffic is taking that throttling it then routing if over a VPN will likely change that route and might allow full speed repeatedly. It would at least prove the routing issue theory.

I have an OpenVPN tunnel setup to an instance in GCP for that purpose. But almost anywhere would change the route to test it.

Steve

Sergei_Shablovsky

@stephenw10 said in VERY slow System Update:

If there is something specifically in the route that traffic is taking that throttling it then routing if over a VPN will likely change that route and might allow full speed repeatedly. It would at least prove the routing issue theory.

I have an OpenVPN tunnel setup to an instance in GCP for that purpose. But almost anywhere would change the route to test it.

Thank You for all help here, Stephen!

Task SOLVED, due the source of this sow pfSense update was in speed/control settings for NIC's interface: need to be changed from 100TX full-duplex to 100TX (mean 100TX half-duplex).
After this speed of update come from fixed 16,4k to 1,5-2,5M.

I do not know why *the exactly pfSense updates are so slow and no other netflow affected”, but anyway, this certain issue closed and finding the source of problem come to another level, please see Errors In, but no Errors Out and No Collisions on both WAN.