Carsten Grzemba writes: > I experience the same problem. Is this yet another USB-based GSM/3GPP connection? If so, then contact the driver-discuss group. There seems to be something wrong with serial USB ports that causes hangs on the transmit side. Many people have seen it.
See CR 6719062. > Here me output of netstat -in: > [EMAIL PROTECTED]:~# netstat -ni > Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue > lo0 8232 127.0.0.0 127.0.0.1 392 0 392 0 0 0 > sppp0 1500 10.6.6.6 172.22.23.231 1819 0 1540 0 0 0 > > Output of kstat sppp\*: This shows nothing wrong with PPP. > Jul 24 15:41:49 notebookcg2 pppd[920]: [ID 702911 daemon.debug] rcvd [LCP > ConfRej id=0xac <magic 0xdc9c8a05> <pcomp> <accomp>] That's a little worrisome. A peer that rejects the LCP Magic-Number option is a very poor implementation. There's no rational reason to reject that option. > Jul 24 15:41:49 notebookcg2 pppd[920]: [ID 702911 daemon.debug] rcvd [LCP > ConfReq id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>] > Jul 24 15:41:49 notebookcg2 pppd[920]: [ID 702911 daemon.debug] adjusted > requested asyncmap from 0 to a0000 > Jul 24 15:41:49 notebookcg2 pppd[920]: [ID 702911 daemon.info] possibly > broken peer detected; restarting LCP It looks like your peer wants asyncmap 0xa0000. Add that to your configuration. > Jul 24 15:41:52 notebookcg2 pppd[920]: [ID 702911 daemon.debug] rcvd [LCP > ProtRej id=0x0 80 fd 01 33 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] The peer doesn't support CCP. May as well have "noccp" here. > Jul 24 15:41:54 notebookcg2 pppd[920]: [ID 702911 daemon.debug] rcvd [IPCP > ConfRej id=0xbe <compress VJ 0f 01>] And "novj". I don't see anything wrong with PPP or networking here. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
