# Cannot upgrade packages on 10.3 update



## Oldrancher (May 22, 2017)

Yesterday, I set out to upgrade my FreeBSD 10.3 system.  I was able to complete the basic update and do a subversion update of /usr/ports.  

To make what is a very long story short, `pkg` will not download anything from
http://pkg.FreeBSD.org/FreeBSD:10:amd64/quarterly/All/.

Here is an attempt to install `firefox`

```
# pkg install firefox
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 32 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
        cups-client-2.0.3_2
        cups-image-2.0.3_2

New packages to be INSTALLED:
        firefox: 53.0.3,1
        trousers: 0.3.14_1
        tpm-emulator: 0.7.4_1
        libunistring: 0.9.7
        gtk2: 2.24.29_3
        cups: 2.2.2_1
        webp: 0.5.2_1
        giflib: 5.1.4
        libav: 11.8
        libvdpau: 1.1.1
        libva: 1.7.3
        opencv2-core: 2.4.13.1_1
        opencv2: 2.4.13.1_6
        vo-aacenc: 0.1.3_1
        x265: 2.3
        ghostscript9-agpl-base: 9.16_5

Installed packages to be UPGRADED:
        gnutls: 3.3.17.1 -> 3.5.9
        nettle: 2.7.1 -> 3.3
        ghostscript9-base: 9.06_11 -> 9.06_13
        gtk3: 3.16.7_2 -> 3.18.8_4
        gnupg: 2.1.8 -> 2.1.21
        texlive-base: 20150521_6 -> 20150521_15
        libgd: 2.1.0_7,1 -> 2.2.4,1
        libvpx: 1.5.0 -> 1.6.1_1
        ffmpeg: 2.8.6,1 -> 3.2.4_7,1
        libgphoto2: 2.5.9 -> 2.5.12
        glib-networking: 2.44.0 -> 2.46.1_1
        hunspell: 1.3.3 -> 1.6.1
        libx264: 0.144.2533_1 -> 0.148.2728_1

Installed packages to be DOWNGRADED:
        vte3: 0.48.3 -> 0.42.4_2

Number of packages to be removed: 2
Number of packages to be installed: 16
Number of packages to be upgraded: 13
Number of packages to be downgraded: 1

The process will require 308 MiB more space.
54 MiB to be downloaded.

Proceed with this action? [y/N]: y
pkg: http://pkg.FreeBSD.org/FreeBSD:10:amd64/quarterly/All/gtk3-3.18.8_4.txz: Operation timed out
#
```

I have tried building ports, but too much is broken with basic needs, and I cannot install the needed packages, either.  

Hank


----------



## tingo (May 22, 2017)

Then you have a connectivity issue. can you ping pkg.freebsd.org?


----------



## Oldrancher (May 22, 2017)

tingo said:


> Then you have a connectivity issue. can you ping pkg.freebsd.org?


Yes, I can ping the site.  Actually, I have connected to it, gone to the http://pkg.freebsd.org/FreeBSD:10:amd64/quarterly/All/ directory, found the gtk3-3.18.8_4.txz and downloaded it.  I put it in the FreeBSD /var/cache/pkg directory, but that doesn't satisfy the requirement.
The other files in that directory are symbolic links to files with a checksum in the name, but the download is the filename alone.  

I am using a Solaris system that is another node on the same network as the FreeBSD system to do this administration.  However, I see nothing  wrong in the
FreeBSD installation configuration and routing tables, and can download from other sites.  

If there is a way to do a workaround download, I need to know what it is.


----------



## tingo (May 22, 2017)

Since your post mentions the Solaris machine, and I'm unclear on what you answered: can you ping pkg.freebsd.org from the FreeBSD machine that you are  trying to run the pkg command from?
I still think your FreeBSD machine has a connectivity issue.


----------



## Oldrancher (May 23, 2017)

tingo said:


> Since your post mentions the Solaris machine, and I'm unclear on what you answered: can you ping pkg.freebsd.org from the FreeBSD machine that you are  trying to run the pkg command from?
> I still think your FreeBSD machine has a connectivity issue.



To be specific, all of my connectivity tests have been from the FreeBSD system I am trying to upgrade.  That includes ping.

```
# ping pkg.freebsd.org
PING pkgmir.geo.freebsd.org (149.20.1.201): 56 data bytes
64 bytes from 149.20.1.201: icmp_seq=0 ttl=54 time=47.237 ms
64 bytes from 149.20.1.201: icmp_seq=1 ttl=54 time=57.386 ms
64 bytes from 149.20.1.201: icmp_seq=2 ttl=54 time=43.750 ms
64 bytes from 149.20.1.201: icmp_seq=3 ttl=54 time=40.747 ms
64 bytes from 149.20.1.201: icmp_seq=4 ttl=54 time=42.057 ms
64 bytes from 149.20.1.201: icmp_seq=5 ttl=54 time=46.259 ms
64 bytes from 149.20.1.201: icmp_seq=6 ttl=54 time=40.670 ms
64 bytes from 149.20.1.201: icmp_seq=7 ttl=54 time=42.059 ms
64 bytes from 149.20.1.201: icmp_seq=8 ttl=54 time=38.046 ms
64 bytes from 149.20.1.201: icmp_seq=9 ttl=54 time=40.734 ms
64 bytes from 149.20.1.201: icmp_seq=10 ttl=54 time=44.094 ms
^C
--- pkgmir.geo.freebsd.org ping statistics ---
11 packets transmitted, 11 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 38.046/43.913/57.386/4.955 ms
#
```


----------



## SirDice (May 23, 2017)

Does `fetch http://pkg.FreeBSD.org/FreeBSD:10:amd64/quarterly/All/gtk3-3.18.8_4.txz` work?

Is there perhaps a (transparent) proxy in between?


----------



## Oldrancher (May 23, 2017)

SirDice said:


> Does `fetch http://[FILE]pkg.FreeBSD.org[/FILE]/FreeBSD:10:amd64/quarterly/All/gtk3-3.18.8_4.txz` work?
> 
> Is there perhaps a (transparent) proxy in between?



There shouldn't be.  The topology here is pretty simple.  Both the Solaris and FreeBSD machines connect through a Fortigate 30D firewall to my upstream feed through a radio link.
All IP's are static, and I do not have wifi.  I programmed the FG 30D over a year ago, and was able to install packages on the FreeBSD box afterward (May '16).  I also `ssh`
outside my system, and have gotten no checksum squawks over the past year.

I also noted that (recently) I was able to download fresh distfile files and pkg files, and the only block seems to be when trying to download from pkg.FreeBSD.org


----------



## SirDice (May 23, 2017)

It could be the Fortigate, some models have IPS features. That could be triggering on a false positive. 


Oldrancher said:


> I programmed the FG 30D over a year ago, and was able to install packages on the FreeBSD box afterward (May '16).


Are you able to check its logs? Perhaps there's something automatic being triggered. Won't hurt to look, even if it's only to rule it out as a possible cause.


----------



## Oldrancher (May 25, 2017)

SirDice said:


> It could be the Fortigate, some models have IPS features. That could be triggering on a false positive.



"Some models have IPS features."  ???!!!  Fortinet firewalls are tops for IPS features, when run with the UTM (Universal Threat Management) subscription.
Two years ago I went through a real siege of script kiddie probes to my systems, denial of service, etc., so that Fortigate (which was a replacement for a failing unit) is programmed to the hilt.   And, quite by coincidence, Fedex delivered a Fortigate 60D with UTM this afternoon, which will replace an old FG-60, which is long since EOL, though it's better than most consumer units, even without UTM.

For a quick test on the FreeBSD box, I switched over to the old FG-60 route to the outside, and it appears that I can download without blocking.  I am going to investigate whether the firewall or upstream of the IP is doing the blocking.


----------



## tingo (May 25, 2017)

Wild guess: the subscription service (who is crazy enough to run a service on his / her firewall that is outside of your control? That's just asking for a denial-of-service to happen) has downloaded and installed new rules, which now is responsible for blocking your pkg downloads.


----------



## Oldrancher (May 25, 2017)

tingo said:


> Wild guess: the subscription service (who is crazy enough to run a service on his / her firewall that is outside of your control? That's just asking for a denial-of-service to happen) has downloaded and installed new rules, which now is responsible for blocking your pkg downloads.



I'd have to ask: just what are you trying to contribute here?   Sir Dice has suggested I consider the Fortigate's IPS as a possible cause of my inability to download packages.
I am putting a plan in place to pinpoint the problem.  My initial post was to determine whether the pkg.freebsd.org was up or down, before trying to troubleshoot further.

While I consider any detailed discussion of Fortinet products here to be wildly off topic, let me be specific that I have used Fortigate firewalls since 2005, and recommend them highly to those who can benefit from a top-quality security product.  Also let me specific that what firewall is programmed to block, both intrinsically and through the UTM service, is both visible to the user and can be switched off under user control.  If I run through a sequence of tests that identifies a false positive block, I can bring that up with Fortinet support.   

Right now, any idea that the FG-30D and/or UTM are responsible for the problems I've had is strictly hypothetical, and will remain so until proven.  That is a low priority task at the moment.
As to site security and configuration, I have responsibilties not only for my site, but others as well.  Crazy?  As the French say, "Folle comme un renard."  I don't work alone on security management.


----------

