Re: Linux dialup to Netscape.net?
From: Charles Tryon (chucktryon_at_yahoo.com)
Date: 08/22/05
- Next message: Bill Marcum: "Re: cant nfs mount problem"
- Previous message: KDoc: "Dangers of Linux writing to NTFS ....??"
- Next in thread: Moe Trin: "Re: Linux dialup to Netscape.net?"
- Reply: Moe Trin: "Re: Linux dialup to Netscape.net?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 22 Aug 2005 01:48:16 GMT
Moe,
First of all, thanks for all your answers. This is sort of a
"background task" for me, so I haven't been checking back on a regular
basis, and don't have a lot of time to try things.
Moe Trin wrote:
> In the Usenet newsgroup comp.os.linux.misc, in article
> <bntJe.2811$rI6.1820@twister.nyroc.rr.com>, Charles Tryon wrote:
>
>
>>>http://axion.physics.ubc.ca/ppp-linux.html
>>>http://www.theory.physics.ubc.ca/ppp-linux.html
>>
>> I'll try to take a look at these.
>
>
> That should be the same page in two places. It's a guide to seeing what
> it takes to get connected. Despite all of the helper tools and some of
> their bizarre ideas, connecting usually only means a dial script to
> dial the modem, and letting pppd handle EVERYTHING else.
>
>
>>>Can you show the segment of the ppp log
>
>
>>I'm not exactly sure which log you mean.
>
>
> See the web page above.
>
>
>>The following is the output from the "eznet" program as it tries to connect:
>
>
> OK I see a minor problem - no timestamps. For some reason, you are also
> trying to set the MRU - rarely needed.
>
>
>>Modem hangup
>>Connection terminated.
>
>
> No error code or message - not enough details.
>
>
>>Using the wudial program, this is what I get from Netscape:
>>------------------------------------
>>CONNECT 9600/ARQ/V32/LAPM/V42BIS
>>--> Carrier detected. Waiting for prompt.
>
>
> The idiot who wrote the program thinks this is the 1980s. Read his blurb
> on "Stupid Mode" in the wvdial man page, and set it. That also looks as if
> you are not setting the modem port speed - 9600 BPS is ssslllooooowwww!!!
> Most modern modems want the port at 115200.
>
>
>>Level 3 Comm nas10.roc1 UQKT2
>>Username:/login:/Login:
>
>
> OK, level3.com - is that Rochester? I don't recognize the terminal server,
> but it's the standard problem. Something you did triggered the text mode
> on the server
I believe that's trying to dial into the Netscape service. The examples
further down were dialing in to Rochester Roadrunner, which was working
fine when I used "eznet", but not "wudial". I have not yet had time to
try "stupid mode" on wudial yet.
>>--> Looks like a login prompt.
>>--> Sending: nsSomebody@netscape.net
>>nsSomebody@netscape.net
>>Password:
>>--> Looks like a password prompt.
>>--> Sending: (password)
>>Access Denied
>
>
> but it's not configured to accept logins. Not strange, as virtually no one
> is using that mechanism, and hasn't been since 1996. The klown who created
> the WvDial application is just a little slow to get the word - heck it's
> only been nine years.
>
>
>>Username:/login:/Login:
>
>
> and you're now screwed. Hang up the phone, and try again with Stupid Mode
> turned on.
>
>
>>--> Don't know what to do! Starting pppd and hoping for the best.
>
>
> which is what it should have done in the first place.
>
>
>>--> pppd: ATM1L1
>>--> pppd: ATM1L1
>>--> pppd: ATM1L1
>>--> pppd: ATM1L1
>
>
> WTF is that? Why would pppd be sending Hayes Modem commands to set the
> speaker on until 'CONNECT' and the volume to 'Low'???
>
>
>>Unfortunately, I'm not at all adept at setting up ppp chat scripts, so
>>I'm stuck with trying to use all the tools others have built on top of
>>ppp. Of course, tools are great when they work, but you're sort of up a
>>creek if they don't.....
>
>
> Can you use an editing tool? The scripts I supplied should work with
> suitable changes (phone number, username, etc.).
Yes, I'm old enough I remember how to use vi. ;-) The scripts, as
you wrote them (substituting in obvious things like user/pwd) have not
worked yet, but I'm still fiddling. (Funny thing -- I've been doing
networking for years, but haven't had to fuss with dialups or ppp in
such a long time, all the tools have changed, and I have forgotten how
to do things. Last tool I used was "cu" with a 2400 baud modem. Not
much of that experience transfers over. :-/)
>
>>This is the eznet config file for my RR connection:
>>------------------------------------
>>1 debug yes
>>1 expect0 ogin:
>>1 password something
>>1 user somebody@rochester.rr.com
>
>
> That's MOST unusual
>
>
>>1 reply0 aolnet/ent.somebody@rochester.rr.com
>>1 service RR
>
>
> No idea what that might be for.
>
>
>>Notice the "reply0". This is not normally there, but I found a
>>reference to the "aolnet" response somewhere through Google, and when I
>>added this in, it worked fine.
>
>
> I don't see it being used in this log
>
>
>>sent [LCP ConfReq id=0x1 <mru 552> <asyncmap 0x0> <magic 0x8f61df25>
>><pcomp> <accomp>]
>>rcvd [LCP ConfNak id=0x1 <mru 1500>]
>
>
> You said Hello, and wanted to use small packets. The peer says no to
> the small packet idea. I don't see where you are declaring that, but you
> normally have no need to set the MRU. With some firewalls, this condition
> will also break connectivity.
>
>
>>sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x8f61df25> <pcomp> <accomp>]
>>rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <magic 0x8f61df25> <pcomp> <accomp>]
>
>
> You try again without the short packet, and the peer approves.
>
>
>>rcvd [LCP ConfReq id=0x2 <asyncmap 0xa0000> <auth chap MD5> <magic
>>0x8495ed02> <pcomp> <accomp>]
>
>
> The peer says Hello, and wants you to authenticate using CHAP MD5. Minor
> possible problem - they want an async map of 0xa0000 (masks XON/XOFF), which
> is often the sign of a b0rken or misconfigured peer. After they challenge
> and you reply, you see
>
>
>>rcvd [CHAP Success id=0x1 ""]
>>CHAP authentication succeeded
>
>
> You're good to go.
>
>
>>sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
>
>
>>rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
>>rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
>
>
> The peer doesn't do data compression, but handles the negotiations cleanly.
> No problem.
>
>
>>not replacing existing default route to eth0 [192.168.1.1]
>
>
> Old problem - you told your install program that the way to the Internet\
> is to send packets to 192.168.1.1 on the Ethernet interface. pppd will not
> replace this route, so the ppp link is nearly useless. 1. If you have a
> route to the world through the Ethernet, why use dialin. 2. If you DON'T
> have a route to the world through the Ethernet, edit /etc/sysconfig/network
> and delete the GATEWAY variables. 3. If this is a test setup "(testing a
> dialin link while you actually have cable or DSL or similar), don't use the
> defaultroute option, but edit /etc/ppp/ip-up.local to add the route, and
> /etc/ppp/ip-down.local to remove it afterwards. Messy, but can be made to
> work. You will also need the 'noauth' option to pppd, as this default route
> screws up authentication - that _may_ be the real problem you are having.
Interesting point. Yes, I am trying to test the ppp route. I
thought I had brought down the eth0 connection, but I might have
forgotten when I did that test. I was more concerned in establishing
the interface (ppp0) than in worrying about how to actually get the
packets routed to it after it was up.
>
>> Unfortunately, in the case of Netscape.net, this does the low level
>>modem sync, but then fails the authentication, and simply drops the line
>>after a few seconds. (BTW - what's the difference between pap-secrets
>>and chap-secrets?)
>
>
> Without the logs, it's hard to say. As noted, having a pre-existing default
> route does cause authentication problems. The pap-secrets file is used by the
> PAP protocol (RFC1334 - the original authentication scheme that passes
> username and password as clear text to the peer), while chap-secrets is
> used by the CHAP (Challenge Handshake Authentication Protocol that uses
> an encrypted user/password exchange - there are several, varying in the
> encryption algorithm used).
>
>
>>Yea, that sounds like it's my problem. I tried the "dumb" script, just
>>giving the dialup script, and that doesn't authenticate. I'm grabbing
>>at straws here, but it sounds like Netscape may need more than the
>>default DUN emulation.
>
>
> If they do, it should show in the logs. I thought the reason netscape.net
> used a proprietary program was so they could steal bandwidth and bombard
> the user with advertisements while on line.
Ugh. I don't think so, but I wouldn't be surprised if they were
sneaking that in. That might be how they charge lower prices.
"Enhanced User Experience." Yea, THAT'S the ticket!
>
>
>>Thanks for your response though!
>
>
> I saw that you also posted in comp.os.linux.networking - that's actually
> a more appropriate group for this problem, although the web page author
> (Bill Unruh) reads both (and more). The advantage of the other group is
> that there are several people that follow it besides me who handle ppp
> questions.
I have moved my reply to that group.
>
> Old guy
- Next message: Bill Marcum: "Re: cant nfs mount problem"
- Previous message: KDoc: "Dangers of Linux writing to NTFS ....??"
- Next in thread: Moe Trin: "Re: Linux dialup to Netscape.net?"
- Reply: Moe Trin: "Re: Linux dialup to Netscape.net?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
