home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 11103 < prev    next >
Encoding:
Internet Message Format  |  1992-07-24  |  2.7 KB
  1. Xref: sparky comp.dcom.modems:11103 comp.protocols.ppp:688
  2. Newsgroups: comp.dcom.modems,comp.protocols.ppp
  3. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!mstar!mstar!bob
  4. From: bob@MorningStar.Com (Bob Sutterfield)
  5. Subject: older UDS modems' problems with PPP fixed
  6. Message-ID: <BOB.92Jul24134340@volitans.MorningStar.Com>
  7. Sender: news@MorningStar.Com
  8. Nntp-Posting-Host: volitans.morningstar.com
  9. Organization: Morning Star Technologies
  10. Date: Fri, 24 Jul 1992 17:43:47 GMT
  11. Lines: 39
  12.  
  13. In March, I reported to our ppp-users mailing list, and (I think) on
  14. comp.dcom.modems, that our customers had seen problems using PPP
  15. across UDS V.3224 and V.3224 modems when their MNP was enabled.  There
  16. seemed to be a pattern-specific data-mangling bug in the modems' ROM
  17. MNP implementation, that only emerged when confronted with the
  18. sequence that comprised the opening octets of an incoming PPP LCP
  19. Configure-Request packet.  This will happen with any PPP
  20. implementation, not just our company's product.  We began recommending
  21. that users disable those modems' MNP4/MNP5 functions for PPP traffic.
  22.  
  23. Someone noticed my message and passed it along to the spouse of a
  24. colleague's second cousin's housekeeper's bowling buddy's... who works
  25. at UDS.  Frankly, I was pleasantly surprised to get a call from Marty
  26. Weaver at UDS, who took the problem seriously and worked hard to
  27. reproduce it.  Then he managed to persuade the UDS hierarchy that it
  28. was worth investing the engineering time to fix their older-model
  29. modems, even though the problem had only been reported with this one
  30. application (PPP), and only third-hand, and only by someone who didn't
  31. even own a UDS modem (me).
  32.  
  33. They recently sent along the following note, indicating that it was to
  34. be redistributed to anyone who might be affected:
  35.  
  36.    "An incompatibility has recently been discovered when a UDS V.3225
  37.    modem running MNP is used in a specific asynchronous application.
  38.    Changing async character format after a call has been established
  39.    will result in incorrect data characters being received. This will
  40.    occur when a call is established by AT dialing at 7E1 (7 data, even
  41.    parity, 1 stop) and then changing to 8N1 once the modems have gone
  42.    "ON LINE."  This incompatibility exists only when MNP is enabled
  43.    and only on V.3225 modems with firmware versions prior to 2.08.08.
  44.    When equipped with 2.08.08 the modem can be enabled to pass the
  45.    parity bit unchanged by setting S72, bit 5 (decimal 32). UDS
  46.    Motorola will provide an upgrade to 2.08.08 for users with this
  47.    particular application. For further information contact UDS
  48.    Technical Support at 1-800-221-4380."
  49.  
  50. Kudos to UDS for their prompt attention and thorough resolution to
  51. this problem!
  52.