I tried the band-aid on a few macbooks and noticed much better
performance. Before I make this persistent, is there a downside to turning
rfc1323 off?
Joebox User <[log in to unmask]> writes:
>Not sure why this did not show up on this list... reposting..
>
>-----Original Message-----
>From: ACTEM:Assoc. of Computer Technology Educators of Maine
>[mailto:[log in to unmask]] On Behalf Of Garry Peirce
>Sent: Wednesday, November 10, 2010 9:39 AM
>To: [log in to unmask]
>Subject: Re: IC
>
>Re: the GoogleApps issue, this was a result of Google lacking a reverse
>DNS
>entry for a host that they supplied our network with in concert with
>parental controls. Should Google change what they supply us and forget to
>include an reverse DNS entry, the issue will immediately return - it is
>not
>a permanent fix (the issue is parental controls REQUIRING to be able to
>reverse resolve destination addresses).
>
>
>
>Therefore, this issue is also relevant to any other HTTPS connections.
>GoogleApps just happens to be one a large population goes to and was
>quickly
>noticed. Note that reverse DNS entries are NOT required to be created.
>
>
>
>As a number have stated, the IC issue is seen when parental controls is
>off.
>So although we have a similar behavior, the cause is not the same.
>
>It would never work to have IC answer with a different address as the
>client
>would not have an open socket for it and the JB FW (depending on
>settings)
>would block it as well (as would any other FW blocking non-established
>connections).
>
>
>
>The single trace I saw was very telling. Every time the client attempted
>to
>open a connection, there were 7 successive attempts followed by a 8th that
>succeeded albeit ~10 seconds later. The difference is that the 8th does
>not
>attempt window size scaling nor timestamping options.
>
>At the site I checked, the JB is not dropping these 'lost' requests.
>
>
>
>I'd be curious if someone might try setting this (non-persistent) band-aid
>on a host to see if it makes a difference.
>
>sudo sysctl -w net.inet.tcp.rfc1323=0
>
>
>
>I've also not heard if users that work well when off-MSLN are resolving IC
>servers as different addresses - ?
>
>
>
>From: Joebox User [mailto:[log in to unmask]] On Behalf Of Jef H.
>HamLin
>Sent: Wednesday, November 10, 2010 8:48 AM
>To: [log in to unmask]
>Subject: Re: IC
>
>
>
>It may well be that the Joebox doesn't care, but something does and it is
>likely that it is the way that Snow Leopard handles DNS requests. Snow
>Leopard is very picky about https and DNS (earlier "Google Apps" episodes
>this summer and fall). It could be that it has nothing to do with Joebox
>and more to do with how MSLN handles DNS communications. IC has two IP
>addresses and uses https to communicate. My guess would be that somehow
>requests go out on one address and are answered on the other and Snow
>Leopard does not appreciate the humor in this. This may be compounded by
>the way in which either the Joebox or MSLN (or the combination of the two)
>handles DNS requests. Clues and guesses at this point.
>
>
>
>H
>
>
>
>From: Joebox User [mailto:[log in to unmask]] On Behalf Of Garry
>Peirce
>Sent: Tuesday, November 09, 2010 5:04 PM
>To: [log in to unmask]
>Subject: Re: IC
>
>
>
>The joebox does not care (or even know) what client OS is being used. It
>simply passes/filters packets.
>
>Once major difference among client OSs is TCP stacks.
>
>
>
>When off-MSLN are you resolving IC to the same IP address?
>
>
>
>In a capture I looked (from a site through MSLN) at there was a
>distinct/repeating pattern showing a lack of response from IC servers
>(from
>the client perspective) in setting up new connections. This process was
>requiring about 10 seconds for each new connection (as well a small
>window)
>to initiate which would certainly delay things.
>
>
>
>Not being an IC user, is there a dummy account of some sort we could make
>use of to directly investigate this issue?
>
>
>
>
>
>From: Joebox User [mailto:[log in to unmask]] On Behalf Of Jef H.
>HamLin
>Sent: Tuesday, November 09, 2010 3:31 PM
>To: [log in to unmask]
>Subject: Re: IC
>
>
>
>I noticed in one of the threads below it was stated that we have been
>unable
>to confirm Snow Leopard on non-MLTI machines. I can confirm this. It is
>NOT exclusively an MLTI issue. I have several teachers and administrators
>with brand-spank-me new MacBooks and MacBook Pros running Snow Leopard who
>are crawling to and from IC. It is a Mac/Snow Leopard issue behind the
>Joebox. I don't know about other firewalls, but I do know that some(but
>not
>all) home networks seem to fine. I have also turned off filtering (still
>going through the Joebox) for a specific user with Snow Leopard and that
>seems to have no impact. Hope this helps.
>
>H
>
>
>
>From: Joebox User [mailto:[log in to unmask]] On Behalf Of Chuck
>McLaughlin
>Sent: Tuesday, November 09, 2010 2:01 PM
>To: [log in to unmask]
>Subject: Re: IC
>
>
>
>Hello,
>
>Please excuse me as I paste in my parts of this same conversation from the
>ACTEMLIST. I have attacked it from filtering, DNS, hosts files, and now
>firewall. At my site it seems to be "Snow Leopard" traffic confusion
>through the Joebox/new circuit -it is slow -but it does resolve if you can
>wait. We have 1 to 1 grades 5-12 for 800+ laptops. Browsing speed is
>great
>except for IC. As you will see in the prior threads pasted below our
>problem appears to only exist in Snow Leopard connections -but not many
>other OS computers connect to IC concurrently. The 600+ MLTI units
>dominate
>the network.
>
>Chuck
>
>
>
>Charles L. McLaughlin, MA Ed Leadership, PK1, A+
>
>Technology Director
>
>MSAD#55
>
>137 South Hiram Road
>
>Hiram, Maine 04041
>
>[log in to unmask]
>
>
>
>----- Original Message -----
>
>
>
>Hello,
>
>Possibly as part of the wind/rain storm outages we fried our SonicWall so
>we
>had to setup the Joebox to run as firewall/filter for the short term and
>we
>still have the Lag issue. The Xp, Tiger, and Leopard units seem fine (but
>we do not have many concurrent connections from those OS's). Snow Leopard
>still crawls back and forth to IC (again we are hosted remotely). For our
>location we can cross the double firewall off the list as possibly causing
>the issue.
>
>Chuck
>
>
>
>Charles L. McLaughlin, MA Ed Leadership, PK1, A+
>
>Technology Director
>
>MSAD#55
>
>137 South Hiram Road
>
>Hiram, Maine 04041
>
>[log in to unmask]
>
>
>
>"ACTEM:Assoc. of Computer Technology Educators of Maine"
><[log in to unmask]> on November 4, 2010 at 1:19 PM -0500 wrote:
>
>Hello List,
>
>
>
>We need your help!
>
>
>
>One of my sites -MSAD#55 Sacopee Valley HS, MS and South Hiram Elementary
>
>school share a new single 100MB connection through a Joebox. We have
>
>excruciating lag using Infinite Campus when we access our IC Hosted server
>
>with, "my guess"-- 10 or more "SNOW LEOPARD" machines. If just a few
>
>people are on it is slow but useable. XP, Leopard and Tiger are all fine
>
>but the 600+ MLTI machines and a handful of purchased Snow Leopard Macs
>
>are dreadful. I have tried editing the local host files to the one IC IP
>
>then the other and then both, MSLN and I opened all traffic through the
>
>firewall to the two addresses (all but removed the firewall). rerouting
>
>all resolution to one IP then the other, adjusted MTU settings on
>
>ethernet/wifi connections, you name it... "SNOW LEOPARD" is our curse
>
>right now. RSU38 has brought this issue to Apple, I have brought it to
>
>MSLN and IC Support with no resolutions to be found. The only thing we
>
>all know is that the problem seems to be in "SNOW LEOPARD" only... and
>
>this OS works great on "everything else" in my district. IF we do not get
>
>a fix soon I will pitch this year's image for MLTI MS and HS staff and
>
>reimage with a version of last year's image so that we can use plain
>
>Leopard for IC access. My key IC users are already resigned to using
>
>windows terminal sessions on their macs (but we do not have the capacity
>
>to provide all staff Microsoft terminal session access).
>
>
>
>This issue is delaying any hope of progressing with gradebook use or
>
>opening the IC portal. Class by class attendance is really annoying the
>
>HS staff not to mention grading. I agree that it sounds like a DNS
>
>handling issue where Snow Leopard is hanging/confused while talking back
>
>to the IC server. I saw on this list where one district had an increase
>
>in performance by using internal DNS for snow leopard to resolve their
>
>internal server. ...But to the IC hosted site through the MSLN connection
>
>-any ideas? Please, ANY suggestions are welcome -on or off list!
>
>
>
>Thanks!!
>
>
>
>Chuck
>
>
>
>Charles L. McLaughlin, MA Ed Leadership, PK1, A+
>
>Technology Director
>
>MSAD#55
>
>137 South Hiram Road
>
>Hiram, Maine 04041
>
>[log in to unmask]
>
>
>
>"ACTEM:Assoc. of Computer Technology Educators of Maine"
>
><[log in to unmask]> on October 19, 2010 at 10:33 AM -0400 wrote:
>
>>>>> "Peter R. Small, Sr." <[log in to unmask]> wrote:
>
>>> Is any other school system still experiencing slowness using Infinite
>
>>Campus?
>
>>
>
>>Sites which do not have a local server have reported random "slowness"
>
>>with little consistency even within a building. We are currently
>
>>investigating it along two paths.
>
>>
>
>>1) Is it an MLTI issue? Most reports have been from people using MLTI
>
>>MacBooks, because most teachers have them. We have yet to hear a solid,
>
>>irrefutable report that the issue occurs outside the MLTI environment.
>
>>
>
>>2) Is it internet traffic/routing? Inconsistent reports of slowness even
>
>>within the same timeframe within the same building tend to indicate the
>
>>cause may be an "internet traffic jam". maine.infinitecampus.org resolves
>
>>to two geographically distinct IP addresses, 207.225.137.100 and
>
>>72.21.235.100. The one to which you are routed, and how you are routed,
>
>>is determined by the load balancing algorithms of MSLN and whoever you
>
>>are passed along to down the pipe. We have set up records in out local
>
>>DNS, "Campus1.rsu1.org" and "Campus2.rsu1.org" which point to those
>
>>distinct IPs. The trick will be to find willing teachers who, when they
>
>>experience slowness, will log out of Campus and log back in with
>
>>"Campus1.rsu1.org", and if still experiencing slowness log back out and
>
>>in with "Campus2.rsu1.org". If we can determine any kind of consistency
>
>>as to which route tends to be the problem we can ask MSLN to do some
>
>>investigation and potentially find a solution.
>
>
>
>Charles L. McLaughlin, MA Ed Leadership, PK1, A+
>
>Technology Director
>
>MSAD#55
>
>137 South Hiram Road
>
>Hiram, Maine 04041
>
>[log in to unmask]
>
>
>
>****************************************************************************
>**********
>
>MSAD#55 Confidentiality Notice: The information contained in this message
>
>(including any attachments) may contain privileged and/or confidential
>
>information protected from disclosure by the Family Educational Rights and
>
>Privacy Act (FERPA). It is intended solely for the use of the addressee.
>
>Any disclosure of the document is strictly prohibited outside the scope of
>
>the service for which you are receiving the information. If you have
>
>received this communication in error, please notify sender immediately and
>
>delete the material from any computer.
>
>
>
>****************************************************************************
>**********
>
>MSAD#55 Confidentiality Notice: The information contained in this message
>(including any attachments) may contain privileged and/or confidential
>information protected from disclosure by the Family Educational Rights and
>Privacy Act (FERPA). It is intended solely for the use of the addressee.
>Any
>disclosure of the document is strictly prohibited outside the scope of the
>service for which you are receiving the information. If you have received
>this communication in error, please notify sender immediately and delete
>the
>material from any computer.
Frank Pace
MSAD/RSU 35
Technology Dept.
|
