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.