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
----- 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
"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
"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
**************************************************************************************
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.