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.