Unable to down load patches or updates

I have posted this issue in the installation section but received a suggestion that the issue was network related so Í will raise it here

I am unable to install the latest patches/updates because the connection stalls out during the download. Looking at network issues in general I came across the suggestion to turn IPV6 off which I have done and try less than 1500 for the MTU value neither of which appear to make any difference. I have tried Apper, Yast and zypper but all fail in the same way.
At the moment I am booted into a different partition (Linux Mint debian) and there appears to be no problem with the hardware set up as I am currently installing about 50 MB of new software via Synaptic without any apparent issues. I also, in the spirit of enquiry, downloaded a file from an OpenSuse update repository from this partition, again with no apparent problems… Whilst in OpenSuse I ran a TestMy.net Broadband Internet Speed Test test getting a value 823 Kbps down and 274 Kbps up - not very fast but about par for the course at a time when there is higher demand on the ISP

So, it seems to me that there is some issue in the network configuration in OpenSuse producing the problem. but I stand to be corrected as i come at this from common sense rather than any position of expertise.

The installation is OpenSuse 12.3 64bit and the physical network is a fixed wireless tower (WiMax the ISP says) to an antenna and modem to a router and wireless to this box.
Any suggestions would be appreciated as I am running out of low level sorts of things to try! Thanks.

On Mon, 15 Apr 2013 03:06:01 +0000, starcross wrote:

> Any suggestions would be appreciated as I am running out of low level
> sorts of things to try! Thanks.

Let’s start with some higher level stuff instead. It’s always
problematic to start ruling out obscure edge cases when we’ve not started
with the basics.

So let’s start with the following (please post the output from commands/
files in code tags, “#” button in the advanced post editor - if you
don’t, the output will be difficult if not impossible to decypher):

  1. DNS resolution - is it working? What are the contents of your /etc/
    resolv.conf file?

  2. Repository list - what’s the output of “zypper lr -d”?

  3. General connectivity - while in openSUSE, can you browse with a
    browser? Can you ping and use traceroute to get out?

  4. What’s the output of the “route” command?

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On 2013-04-15 05:06, starcross wrote:
>
> I have posted this issue in the installation section but received a
> suggestion that the issue was network related so Í will raise it here
>
> I am unable to install the latest patches/updates because the
> connection stalls out during the download.

Try downloading anything with firefox or another browser. If that has no
issues, then try downloading updates directly with the browser.

Lets find out if you have problems downloading anything, downloading
updates manually, or downloading with the package management tools only.

It could be, for instance, that the mirror that is chosen for the
updates is faulty.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

Hi Carlos,

On 17/04/13 00:10, openSUSE Forums wrote:
>> I am unable to install the latest patches/updates because the
>> connection stalls out during the download.
>
> Try downloading anything with firefox or another browser. If that has no
> issues, then try downloading updates directly with the browser.
>
> Lets find out if you have problems downloading anything, downloading
> updates manually, or downloading with the package management tools only.
>
> It could be, for instance, that the mirror that is chosen for the
> updates is faulty.

Following your excellent suggestions we find

Downloading in general

Using thinkbroadband :: Download Test Files - no apparent problems with files of varying sizes

Using TestMy.net Broadband Internet Speed Test - working better than average today 354 kB/s down (2.4 meg file),46 kB/s up (256 k file)

so Firefox appears to be fine as is the hardware

Downloading OpenSuse files.

I selected a file from the list based on size (5.4 MB) as it seems more likely to hang on larger files and also one that I had not tried from Apper etc. The rationale for the last is that once a file has stalled in Apper revisiting often results in almost no download at all.

The system allocated an in country mirror (Canada)

The download stalled at 88%

I tried again from an in continent mirror (U.S.)

The download stalled at about 5 %

I tried again from a Novell mirror (Europe?)

The download stalled at 88%

All of the mirrors seemed quite slow compared to the non OpenSuse sources. The other issue - mentioned before I think, is that Apper /online update processes will not abort from within the application. I have to resort to KSysGuard to kill the process which otherwise seems to slow down connectivity despite not appearing to be doing anything.

I am considering a fresh install from the DVD (rather not!) as the problem did not seem to be apparent during the initial updates and patches so I wondered if one of those had created the issue.

Thanks, Colin.

On 2013-04-17 23:16, starcross wrote:

> so Firefox appears to be fine as is the hardware

ok…

> Downloading OpenSuse files.
>
> I selected a file from the list based on size (5.4 MB) as it seems more
> likely to hang on larger files and also one that I had not tried from
> Apper etc. The rationale for the last is that once a file has stalled in
> Apper revisiting often results in almost no download at all.

Could be.

> The system allocated an in country mirror (Canada)
>
>
> The download stalled at 88%
>
>
> I tried again from an in continent mirror (U.S.)
>
> The download stalled at about 5 %
>
> I tried again from a Novell mirror (Europe?)
>
> The download stalled at 88%

Weird.

> All of the mirrors seemed quite slow compared to the non OpenSuse
> sources.

I can not think of any explanation for that :frowning:

Any chance your internet provider boycotts opensuse mirrors?

You could, perhaps, copy the link to a terminal, issuing this command:



wget http://link.to.mirror/somefile


and see if it is any better.

The other issue - mentioned before I think, is that Apper
/online update processes will not abort from within the application. I
have to resort to KSysGuard to kill the process which otherwise seems
to slow down connectivity despite not appearing to be doing anything.

Yes, that is an old problem.

I am considering a fresh install from the DVD (rather not!) as the
problem did not seem to be apparent during the initial updates and
patches so I wondered if one of those had created the issue.

Dunno… you could post your list of repositories so we can have a look:


zypper lr --details

Please use code tags for printouts and commands. Advanced editor, ‘#’
button. Posting in Code Tags - A Guide


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

On Wed, 17 Apr 2013 21:16:03 +0000, starcross wrote:

> I am considering a fresh install from the DVD (rather not!) as the
> problem did not seem to be apparent during the initial updates and
> patches so I wondered if one of those had created the issue.

I would doubt it. Do you have experience with network analysis? (I ask
because you mentioned tweaking the MTU). If you do, a sniffer trace with
Wireshark might be useful to you.

If not, you might try capturing a download and put the trace file
somewhere for someone with wireshark analysis skills to look at.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Carlos E. R. wrote:
> You could, perhaps, copy the link to a terminal, issuing this command:
>
>


>
> wget http://link.to.mirror/somefile
>
> 

It would be a useful simple test to post the exact command that you use
as well as the wget output. Then other people can try downloading
exactly the same file from the same mirror to verify whether there is a
problem with the mirror.

wget also has a lot of options to influence how it downloads. If using
it shows that you do have problems, you might want to read through the
man page and try some options to see if they help identify the problem.

Jim,

thanks for this.

I would doubt it. Do you have experience with network analysis? (I ask
because you mentioned tweaking the MTU). If you do, a sniffer trace with
Wireshark might be useful to you.

I’m flattered but no - just an end user! I had a look at Wireshark but it looks like a step too far at the moment.

However it occurred to me overnight to attempt to download the same (failing ) file from within another distribution in a different partition. Interestingly this failed as well although the OS was quite happy to get updates from within its own system.

For what it is worth I have two ways of visually determining network activity - a tracking widget configured as a graph and the transmission led on the wireless adapter (USB type) When the file was not arriving what I saw was nothing on the widget but a certain amount of activity on the adapter. I would guess that this suggests the blockage is occurring at the router level?

I had come across a link (now misplaced!) that suggested download hangs were something to do with the DHCP process using a local rather than remote source.It struck me as being above my head so I moved on but I wonder if there is not something to be at least modified in this area.
Thanks,Colin

On Thu, 18 Apr 2013 16:36:03 +0000, starcross wrote:

> I’m flattered but no - just an end user! I had a look at Wireshark but
> it looks like a step too far at the moment.

It’s probably the best diagnostic tool for this type of problem. It
needs to run as root to capture, but if you start a capture before the
download and stop it afterwards, save it, and then put it somewhere like
dropbox and link to it, I could take a quick peek at it and see if
there’s anything that jumps out at me. (I do have a background in
network analysis, so might see something that stands out).

> However it occurred to me overnight to attempt to download the same
> (failing ) file from within another distribution in a different
> partition. Interestingly this failed as well although the OS was quite
> happy to get updates from within its own system.

That is bizarre.

> For what it is worth I have two ways of visually determining network
> activity - a tracking widget configured as a graph and the transmission
> led on the wireless adapter (USB type) When the file was not arriving
> what I saw was nothing on the widget but a certain amount of activity on
> the adapter. I would guess that this suggests the blockage is occurring
> at the router level?

It’s possible.

> I had come across a link (now misplaced!) that suggested download hangs
> were something to do with the DHCP process using a local rather than
> remote source.It struck me as being above my head so I moved on but I
> wonder if there is not something to be at least modified in this area.
> Thanks,Colin

DHCP is responsible for assigning the network address and DNS servers
(and default route and a few other things), but I doubt this is anything
to do with the problem. There’s some sort of network issue going on.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

[QUOTE=djh-novell;2548725]Carlos E. R. wrote:
> You could, perhaps, copy the link to a terminal, issuing this command:

It would be a useful simple test to post the exact command that you use
as well as the wget output. Then other people can try downloading
exactly the same file from the same mirror to verify whether there is a
problem with the mirror.

colin@linux-87vj:~> wget http://www.muug.mb.ca/pub/opensuse/update/12.3/x86_64/systemd-195-13.14.1.x86_64.rpm
–2013-04-18 11:04:43-- http://www.muug.mb.ca/pub/opensuse/update/12.3/x86_64/systemd-195-13.14.1.x86_64.rpm
Resolving MUUG Home Page (MUUG Home Page)… 130.179.31.46
Connecting to MUUG Home Page (www.muug.mb.ca)|130.179.31.46|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 1233162 (1.2M) [application/x-rpm]
Saving to: `systemd-195-13.14.1.x86_64.rpm.1’

3% > ] 37,445 --.-K/s eta 51m 14s

would be the output, with the eta slowly increasing! As I get the same sort of pattern from different mirrors it seems unlikely to be mirror dependent .As I mentioned elsewhere in this thread I wonder about the router connection.I recognise that I could deal with this at the analysis level by bypassing the router but I am not overly keen on moving all the hardware as I would have to,as I still have to operate this machine remotely with respect to the modem.

Thanks for your assistance,
Colin.

On 2013-04-18 19:26, starcross wrote:

>> colin@linux-87vj:~> wget http://tinyurl.com/blz6pka
>> --2013-04-18 11:04:43-- http://tinyurl.com/blz6pka

Please, we told you to use code tags to post this. The text has been
altered and is not very useful.

Anyway, the problem is not visible there. Wireshark seems more promising.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

Jim,

thanks for the further suggestions. I was a little slow on this as I just discovered that Gmail had decided that some communications from the forum were spam and found this communication lodged there!

[QUOTE=hendersj;2548837]On Thu, 18 Apr 2013 16:36:03 +0000, starcross wrote:

> I’m flattered but no - just an end user! I had a look at Wireshark but
> it looks like a step too far at the moment.

It’s probably the best diagnostic tool for this type of problem. It
needs to run as root to capture, but if you start a capture before the
download and stop it afterwards, save it, and then put it somewhere like
dropbox and link to it, I could take a quick peek at it and see if
there’s anything that jumps out at me. (I do have a background in
network analysis, so might see something that stands out).

OK - in the todo list

Feeling a little frustrated I thought I would try another RPM based distro ( Pclos) to check the issue a little further but on a system using Synaptic for RPM handling
rather than Yast. Unfortunately with the same result - a few files downloaded from their repository and then a stall.I was beginning to doubt my memory by this point so I went back to LMDE to do a little installing from Debian repositories - working normally.

I also tried changing the connection between the router and this box to a power line system rather than wirelss but that made no difference. I also went back to an old router which also made no difference. As a consequence of fiddling with routers I had to reboot the modem also - not that it made any difference either. Finally I reinstalled OpenSuse on different partitions on a ẃhy not’ basis

Googling around I found some fora complaining of similar issues with the Yum package manager which (perhaps) were resolved by changing some time variables to do with retrying connections.It occurs to me now that another (salient ?) difference is that both the OpenSuse and the Pclos are 64 bit systems but LMDE is 32 bit. (This is an old box with and AMD64 X2 4800 cpu)

Iĺl let you know when i have achieved the Wireshark set up.
Colin.

Apologies for this Carlos. I had been depending on emails to alert me to responses and found that Gmail had, apparently randomly,decided to send some into the spam folder but not all.I missed the comment about tags therefore.

[QUOTE=robin_listas;2548930]On 2013-04-18 19:26, starcross wrote:

>> colin@linux-87vj:~> wget http://tinyurl.com/blz6pka
>> --2013-04-18 11:04:43-- http://tinyurl.com/blz6pka

Please, we told you to use code tags to post this. The text has been
altered and is not very useful.

With code tags the wget output was


colin@linux-87vj:~> wget http://www.muug.mb.ca/pub/opensuse/update/12.3/x86_64/systemd-195-13.14.1.x86_64.rpm
--2013-04-18 11:04:43--  http://www.muug.mb.ca/pub/opensuse/update/12.3/x86_64/systemd-195-13.14.1.x86_64.rpm
Resolving MUUG Home Page (http://www.muug.mb.ca) (MUUG Home Page (http://www.muug.mb.ca))... 130.179.31.46
Connecting to MUUG Home Page (http://www.muug.mb.ca) (www.muug.mb.ca)|130.179.31.46|:80... connected.
HTTP request sent, awaiting response... 200 OKLength: 1233162 (1.2M) [application/x-rpm]
Saving to: ‘systemd-195-13.14.1.x86_64.rpm.1' 3% >                                      ] 37,445      --.-K/s  eta 51m 14s 

Colin.

Dealing with the final ‘missed post’.

So let’s start with the following (please post the output from commands/
files in code tags, “#” button in the advanced post editor - if you
don’t, the output will be difficult if not impossible to decypher):

  1. DNS resolution - is it working? What are the contents of your /etc/
    resolv.conf file?
### /etc/resolv.conf file autogenerated by netconfig!
#
# Before you change this file manually, consider to define the
# static DNS configuration using the following variables in the
# /etc/sysconfig/network/config file:
#     NETCONFIG_DNS_STATIC_SEARCHLIST
#     NETCONFIG_DNS_STATIC_SERVERS
#     NETCONFIG_DNS_FORWARDER
# or disable DNS configuration updates via netconfig by setting:
#     NETCONFIG_DNS_POLICY=''
#
# See also the netconfig(8) manual page and other documentation.
#
# Note: Manual change of this file disables netconfig too, but
# may get lost when this file contains comments or empty lines
# only, the netconfig settings are same with settings in this
# file and in case of a "netconfig update -f" call.
#
### Please remove (at least) this line when you modify the file!
nameserver 192.168.1.1

Looks like nothing much there!

  1. Repository list - what’s the output of “zypper lr -d”?
colin@linux-gsie:~$ zypper lr -d
# | Alias                     | Name                               | Enabled | Refresh | Priority | Type   | URI                                                             | Service
--+---------------------------+------------------------------------+---------+---------+----------+--------+-----------------------------------------------------------------+--------
1 | nVidia Graphics Drivers   | nVidia Graphics Drivers            | Yes     | Yes     |   99     | rpm-md | http://download.nvidia.com/opensuse/12.3/                       |        
2 | repo-debug                | openSUSE-12.3-Debug                | No      | Yes     |   99     | NONE   | http://download.opensuse.org/debug/distribution/12.3/repo/oss/  |        
3 | repo-debug-update         | openSUSE-12.3-Update-Debug         | No      | Yes     |   99     | NONE   | http://download.opensuse.org/debug/update/12.3/                 |        
4 | repo-debug-update-non-oss | openSUSE-12.3-Update-Debug-Non-Oss | No      | Yes     |   99     | NONE   | http://download.opensuse.org/debug/update/12.3-non-oss/         |        
5 | repo-non-oss              | openSUSE-12.3-Non-Oss              | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/12.3/repo/non-oss/    |        
6 | repo-oss                  | openSUSE-12.3-Oss                  | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/12.3/repo/oss/        |        
7 | repo-source               | openSUSE-12.3-Source               | No      | Yes     |   99     | NONE   | http://download.opensuse.org/source/distribution/12.3/repo/oss/ |        
8 | repo-update               | openSUSE-12.3-Update               | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/update/12.3/                       |        
9 | repo-update-non-oss       | openSUSE-12.3-Update-Non-Oss       | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/update/12.3-non-oss/               |        


  1. General connectivity - while in openSUSE, can you browse with a
    browser? Can you ping and use traceroute to get out?

Works normally AFAIK. Using www. testmy.net for example gets files and downloads/uploads without a problem.I recently downloaded Pclos as a torrent - slow, took 8 hours - but operated in the background and allowed,for example,viewing YouTube video without disruption.

  1. What’s the output of the “route” command?
linux-gsie:/home/colin # route                                                 
Kernel IP routing table                                                                                                                                                             
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface                                                                                                       
default         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0                                                                                                       
loopback        *               255.0.0.0       U     0      0        0 lo                                                                                                          
link-local      *               255.255.0.0     U     0      0        0 wlan0                                                                                                       
192.168.1.0     *               255.255.255.0   U     0      0        0 wlan0                                                                                                       

Thanks,

Colin

Jim,

I have been going around the houses on this so I am looking for a direction. There is,of course, a catch 22 involved as I need Wireshark in order to find out why I cannot install Wireshark or anything else much. The same is true of dropbox of course but that is easier to get round by installing dropbox elsewhere.

It did occur to me to download a Wireshark .deb and use Alien to convert to an RPM and then copy the result over to openSuse and try to
install. However, my experience of going the other way - RPM to .deb -is that it is a bit hit and miss and may break something (dependency compliance changes maybe?)

The other option would be to try to compile it but I suspect some of the libraries for that process would need to be installed (and I have never compiled anything!)

When I aborted Yast2 as it had stalled I got a (standard I suppose) message about cannot access installation media´ and ´check whether server is available´
A retry gets you back to the same spot. It referred to the Yast2 log for further information. The log is enormous of course and to me at least not very helpful.

On the whole I think the underlying problem is the nature of the fixed wireless ISP since the rate of data flow is very variable and can stop entirely for brief periods.However, again Wireshark might elucidate.

Thanks again,

Colin.

On 2013-04-22 20:06, starcross wrote:
>
> Dealing with the final ‘missed post’.

You are not the only one that lost those mails, I have read.

> 1. DNS resolution - is it working? What are the contents of your
> /etc/resolv.conf file?

> Looks like nothing much there!

It says that you are using the DNS server in your router. It is typical,
it should work.

> 2. Repository list - what’s the output of “zypper lr -d”?

Looks good to me.

I see from your other post that wget stalled while downloading an rpm
file from a repo, but you say that other downloads run fine. I tried
that same download, worked fine, so it is not a mirror problem.

We’ll have to see if you can get something with wireshark.

If you were on a business setup, university, or some institution, I
would consider that the network admin has placed some kind of proxy or
content filter, and that it does not like rpms.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

On 2013-04-23 01:56, starcross wrote:
>
> Jim,
>
> I have been going around the houses on this so I am looking for a
> direction. There is,of course, a catch 22 involved as I need Wireshark
> in order to find out why I cannot install Wireshark or anything else
> much.

Gosh - I forgot. :frowning:

> It did occur to me to download a Wireshark .deb and use Alien to
> convert to an RPM and then copy the result over to openSuse and try to
> install.

I don’t like that…

Didn’t you say that you had a mint setup that could do downloads? You
could download the openSUSE rpm from there. Better.
The problem is to find out all deps in advance.

> A retry gets you back to the same spot. It referred to the Yast2 log
> for further information. The log is enormous of course and to me at
> least not very helpful.

You can search for the package name. There maybe an entry about using
curl or wget for doing the download, and maybe an error msg back from it.

> On the whole I think the underlying problem is the nature of the fixed
> wireless ISP since the rate of data flow is very variable and can stop
> entirely for brief periods.However, again Wireshark might elucidate.

What is that wireless ISP thing, could you elucidate, please?


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

On Mon, 22 Apr 2013 23:56:01 +0000, starcross wrote:

> There is,of course, a catch 22 involved as I need Wireshark in order to
> find out why I cannot install Wireshark or anything else much.

You could also install tcpdump and use it to do the capture - it’s a
small enough package that it should come down OK (it also is probably on
the DVD you installed from).

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Jim,

moving on (slowly)

[QUOTE=hendersj;2550144]On Mon, 22 Apr 2013 23:56:01 +0000, starcross wrote:

> There is,of course, a catch 22 involved as I need Wireshark in order to
> find out why I cannot install Wireshark or anything else much.

You could also install tcpdump and use it to do the capture - it’s a
small enough package that it should come down OK (it also is probably on
the DVD you installed from).

After a certain amount of to and fro, tcpdump and the extra libraries it requested have been installed. It appears to work OK AFAIK.

It is obviously very configurable in terms of how much data, in what form, and from where. I wondered what would be most useful in this respect from your point of view… Is one software download handling process more useful to monitor than the others. And finally at what point would you want the data collected - as soon as it stalls or just before for example.

Thanks,

Colin.

On Wed, 24 Apr 2013 15:26:02 +0000, starcross wrote:

>> It is obviously very configurable in terms of how much data, in what
>> form, and from where. I wondered what would be most useful in this
>> respect from your point of view… Is one software download handling
>> process more useful to monitor than the others. And finally at what
>> point would you want the data collected - as soon as it stalls or just
>> before for example.

Assuming your interface is eth0, the command:

sudo tcpdump -i eth0 -w capture.pcap

(You’ll need to supply the root password)

Will grab what’s needed; start the trace, then try an installation that
you know will hang, and when it’s hung, switch back to the window and
press ctrl+c and put the capture.pcap file somewhere accessible. Let me
know where (you can PM me if you like) and I’ll download it and have a
look at it when I have a few free minutes.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C