JOEBOX-L Archives

Joebox User

JOEBOX-L@LISTS.MAINE.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Garry Peirce <[log in to unmask]>
Reply To:
Joebox User <[log in to unmask]>
Date:
Fri, 12 Nov 2010 12:11:57 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (549 lines)
It is preferable to have RFC1323 support enabled.
It is used to improve TCP transfers across higher speed/lower latency
networks.

The request to change it is a an attempt to try better
understand/identify/resolve the issue.

Most current OSs support it 
Win2000/2003/XP - off by default
WinVista/7/2008 - on by default
OSX - enabled by default

We have verified that client traffic towards IC is passing through the JB
with these options intact. It would appear that the negotiation is being
disrupted elsewhere.

Former site maintained/MSLN content-filtering systems may have been hiding
the issue, by modifying the connection attempts.

Given the fact that numerous reports mention only OSX Snow Leopard having
the issue there may be an OS component to this as well.  We are continuing
to investigate.


> -----Original Message-----
> From: Joebox User [mailto:[log in to unmask]] On Behalf Of Frank
> Pace
> Sent: Friday, November 12, 2010 11:11 AM
> To: [log in to unmask]
> Subject: Re: FW: IC
> 
> 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.

ATOM RSS1 RSS2