https://bugzilla.novell.com/show_bug.cgi?id=413093 Cyril Hrubis changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chrubis@novell.com AssignedTo|bnc-team-screening@forge.provo.novell.com |aj@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=413093 User alpha096@virginbroadband.com.au added comment https://bugzilla.novell.com/show_bug.cgi?id=413093#c2 Scott Couston changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alpha096@virginbroadband.com.au --- Comment #2 from Scott Couston 2008-08-05 19:39:08 MDT --- The issue is confided to only the /OpenOffice.org:/.....source file. 1 Either this directory is on another server with insufficient bandwidth or performance and/or 2. The source files have been corrupted in a possible abend where rollback has not occurred un-successfully. 3. None of the above. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=413093 User alpha096@virginbroadband.com.au added comment https://bugzilla.novell.com/show_bug.cgi?id=413093#c4 Scott Couston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|alpha096@virginbroadband.com.au | --- Comment #4 from Scott Couston 2008-08-06 08:52:56 MDT --- I will try to answer all your question I understand. 1 The one constant is that I can download and install any community repository, either the exception of openoffice as above with ever having even a retry. I would also like to preface the below information as hopefully a constructive relationship, I would never presume to be able to manage a huge amount of Client PC or offer substantial ISP functionality. Some of my idea may have merit. - I hope so The requested file repository location originates from the server withing each screen capture and is defained as. http:///download.opensuse.orgrepository/repositories/OpenOffice.org:/STABLE/... I am there for not using a mirror unless your download server mounts the directory /repositories/OpenOffice.org:/STABLE/openSUSE_10.3/ on another low perforation/bandwidth server AND/OR the original files are corrupt in some way that a Verepair may indicate if run on that volume containing the directory /repositories/OpenOffice.org:/STABLE/openSUSE_10.3/ My other thoughts are that if the /repositories/OpenOffice.org:/STABLE/openSUSE_10.3/ files reside on a server with totally insufficient cache room and is running on border Manager without sufficient cache available size. One other fial though you may like to consider is to DECREASE the retry value. Often when comms are over significant distandance and the packet retry interval to to short. This creates a problem where the ack does not arrive back at the server in the set time, due to distance, and there-try could is increased to solve this issue. By doing this you create a larger problem as for example 1st pack sent and noack in defined time set so retry 1 is sent. Meanwhile the ach arrives from the first packet and the client is only satisfiedof an intact packet, however by this time the server sebds another retry and the game start all over again at an exponential level. With distace comms is is better to set a longer time frame for ack, and to re-set the re-try back to defaul or even increase its value. You can understand how a huge amount of bandwidth is chewed up by (SPX) equivalent protocol control as its fill of re-tries and untimely configured acks for the comms distance traffic can left without user intervention the total bandwidth consumed by all file redundancy messages in the force a huge delays. If No acks/or late acks arrive it is too late and all redundancy checkes and measures are activated. Ever increasing re-tries that follows an exponesial rise in the (SPX) part of TCP/IP .By both decreasing the time before packet re-try is sent, and then possibly lower the retry factor time abd amount we often solve log distance comms lines. The established time difference betweeen London and Australia is almost 4 second in delay and that sole reason iw why noust non IP traffic is sent by SNA/T or Transparent SNA you can lokup a little later if you are interested. Yes I am located in the 3rd largest city of Australia, where all comms are digital and all cells have been on a 3G network for over 12 months county wide. ALL other updates that commence with the http://download.*........never fail or even ask for a re-try and nothing has changed in any LAN settings for many weeks. If it s not broke dont fit it ;-) If the trouble some is on a seperate volume, could you run a vrepair just out of interest and check the amount of disk space allocated to Boarder Manager. and check all the set options to to with RX/TX are set the same if multiple netware servers are used. If all above is true take a look at the set parameter before ack is received and what time is placed on this parameter and then check the packet re-try is not anything but default. If again the directory does reside on a different server, check that sever has sufficient cache memory and check the hot fix logs to see if the HDD is not slowly falling apart,but above all check the HDD in all download servers are ALL the SAME SCSI high performance devices and you are using the same SCSI controller cards. Other default set values may need adjustment purely as be are aprox 4 seconds in delay of data traffic which make totally encapsulated comms like x25 difficult to manage. We use most all external comms as SNA/T via our satellite - remember we are along way away and just a big island. Kind Regards Scott -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=413093 User alpha096@virginbroadband.com.au added comment https://bugzilla.novell.com/show_bug.cgi?id=413093#c6 Scott Couston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Scott Couston 2008-08-09 01:19:54 MDT --- Issue Resolved by Reporter For other future possible reference:- My ALG [(APPLICATION LAYER GATEWAYS) (ALL 8 OF THEM)] is filtering all my HTTP/FTP/VOIP traffic, however is was not instructed to filter out any file type or content. I exempted all file types I.E *.RPM from having their packets monitored by any ALG and this permitted no disruption of regular packet flow and resolved the RX/TX issues completely. It is unknown why exempting the ALG's for ANY filtering action that resolved this issue. The properties of all downloaded file types packets contents was not filtered out - for example an ALG is instructed to filter out Active X, and there is NO Active X component of the downloaded file type packets. It appeared that just having ALG's monitoring all HTTP/FTP/VOIP packets contained within the traffic caused enough delay in comms...I.E ACK/NO-ACK/RETRY, that was sufficient grounds to disrupt the normal sync of RX/TX of packets to cause errors seen in images. I could not resolve in my own mind why I appeared to be the only one on the planet having these issues so I continued to hunt for possibilities my end at a comms level. The ALG's have never caused an issue with any other traffic that did not contain any element they were instructed to filter out or DROP OR REJECT the packet session ID. If that were true then my comms that are NATed 3 times should have caused an issue for ALL traffic - but this is NOT nor ever WILL be the case. I could take this up with my Hardware comms IDS manufacturer..but I think I will just leave it as solved for all of us. If anyone should require further information on what all this jargon means please contact me privately. Bug Closed as FIXED with deliberate intent by reporter! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=413093 User alpha096@virginbroadband.com.au added comment https://bugzilla.novell.com/show_bug.cgi?id=413093#c8 --- Comment #8 from Scott Couston 2008-08-25 16:56:00 MDT --- Reference information: Comms traffic to AU is always an issue despite the protocol. Remember we are a huge island with one what out and one way in. With huge distance we are 3 seconds in delay from UK/Europe/US - that plays havoc with most all protocols which have the NO ACK/Retry extended by 3 seconds. SNA traffic had the greatest challenge and we use a variant of SNA called SNA/T - Transparent SNA - where there is an ACK/NO ACK packet delayed by 3 seconds on traffic that exits/enters the country but remain unretarded within the country and is encapsulated with one single packet/data stream. I dont know how we carry TCP traffic, however it is most definitely converted to either X.25 or SNA for carriage ex/in Australia. People spend their life just on comms issues - however its very boring and VTAM is painful. It is not unusual for us to have issues from time to time. It is also interesting that traffic between me and the download server required an exemption when all other continuous download traffic does not requiring one - There is probably some reason why your traffic required exemptions only but the last thing I want to do is put a data scope on my line end and examine the traffic - The exemption works and thats the end for me ;-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.