OIT Network Systems

Remote Access: Known Bugs

NOTE WELL: As announced January 24 2007 by OIT through a variety of media, OIT Remote Access Services this service will be discontinued on July 1 2007. A copy of the text of the announcement is available in the OIT KnowledgeBase. As a result, the information in this document is historic.

This document lists the known bugs for the Remote Access Services.


Bugs Present on All Services

  1. Apple Remote Access version 3.x (and later) clients running AppleTalk are not visible to other AppleTalk devices on the network via AppleTalk NBP. E.g. the Chooser of a Macintosh directly-attached to the campus network will not display services running on the ARA dialin client. As a result, an AppleShare File Server or print spooler running on an ARA dial-in client is not accessible to an on-campus Mac. Will be fixed in the future. (Bug ID CSCdj82550)

    As far as we know, this does not affect services available to dial-in ARA clients, so it is not expected to have any impact. (I.e. AppleTalk services on-campus are visible in the Chooser of the dial-in client. Only the reverse direction is affected.)


Bugs Specific to Charged PPP/SLIP/Async Service (806-1000)

  1. Some older client modems that are able to successfully negotiate a connection to the Non-Charged Services Modems (and the old Charged Service, before March 1998) may fail to negotiate a connection to the current service's modems, which are newer than the modems used by the other services.

    Normally, this isn't actually a bug in the Remote Access service. You may often resolve the problem by upgrading the firmware in your modem. Check with your modem's vendor to learn what firmware upgrades are available for your modem; many modern modems are software-upgradable.

  2. If a V.90 (or K56Flex) client modem cannot connect at all or experiences severe problems, a workaround is to reconfigure the client modem so it does not attempt to negotiate V.90 (or K56Flex), but instead attempts a slower protocol (e.g. V.34bis); consult your modem's reference documentation to learn how to accomplish this.

    This is actually a bug in the client modem, rather than the Remote Access service; the client modem should detect when V.90 (or K56Flex) is infeasible, and automatically fallback to a slower protocol. The workaround avoids letting client modem attempt a higher speed connection.

  3. Our experience with V.90 and K56Flex indicates that sometimes they do not connect as reliably as V.34bis when operating over marginal phone lines.

    Both V.90 and K56Flex protocols require extremely clean phone lines, no more than one analog-to-digital connection along the entire path, and a limited distance (e.g. about three miles) between your modem and the point at which the data is converted from analog to digital format (e.g. at the phone company's central office). Phone lines that sound perfectly clean and work well for V.34bis connections may nonetheless be inadequate to the higher demands of V.90 and K56Flex.

    While V.90 and K56Flex modems should be able to detect when a phone line cannot support the faster protocols (and instead fall back to use V.34bis), in some circumstances these modems may erroneously choose to use V.90 or K56Flex. This too-aggressive behavior can lead to more connection failures, or unreliable connections.

    If you encounter this difficulty, you can work around it by reconfiguring your modem so it does not attempt to negotiate V.90 or K56Flex, but instead attempts to negotiate V.34bis (a maximum speed of 33,600 bits per second). Consult your modem's documentation to learn the appropriate command to add to your modem's initialization string.

  4. Some USR WinModems have difficulty connecting. The server vendor is working on this; there is no timeframe for a fix. (Bug ID CSCdm12286)

  5. Xircom modems using the latest Lucent firmware have difficulties connecting with V.90; the modems usually fall back and connect with V.34 at 28,800 bps. The server vendor is working on this; there is no timeframe for a fix. (Bug ID CSCdm00076)

  6. Lucent-based LT-Win modem version 5.28 internal to Toshiba Tecra 8000 laptop computers will not connect with V.90; the modem always falls back and connect with V.34 at 28,800 bps to 31,200 bps. The server vendor is working on this; there is no timeframe for a fix. (Bug ID CSCdk91889)

  7. Some TDK-DF2814 modems may fail to connect. A workaround is to reconfigure the modem to limit its speed to 31,200 bps or lower. (Bug ID CSCdk18063)

  8. Some vendor Winmodems running version 5.75 firmware will not successfully perform V.90 modem training, but will perform V.34 modem training. A workaround is to downgrade the Winmodem to version 5.70 or 5.28 firmware. (Bug ID CSCdr24044)


Bugs Specific to Charged Low-Speed PPP/SLIP/Async Service (258-0043)

(none at this time)

Bugs Specific to Non-Charged PPP/SLIP/Async Service (258-0430)

(none at this time)


A service of OIT Network Systems
The Office of Information Technology,
Princeton University
Last Update: July 2 2007