I had been getting online rather quickly and easily with my SL-6000L for the past month or two. But, when I tried to go online the other day, I kept getting messages in my pppd log kept saying "Failed to authenticate ourselves to peer," over and over and over again. I wondered whether my ISP had done something to block my account or reset my logon password to a previous one. I tried calling them and could not get through.
Opera had crashed during my last session online, and I did notice that there was no listing for /dev/shm when I did the "df" command. But, the files in /etc/ppp/peers did not seem to have been corrupted.
Then I remembered that I could check the question about my ISP by moving my dialup modem to my Collie, and seeing whether my Collie could get online. Sure enough, I got online immediately, no connectivity issues at all. "Hmmm," I wondered, "I wonder why?"
So, saved copies of my pppd log again, in case it might have some clues as to what went wrong, and I looked through my configuration files in /home/zaurus/Applications/Network/modules and in /etc/ppp/peers.
For those who do not already know this, the files in /home/zaurus/Applications/Network/modules contain the settings created and used by the Qtopia and Sharp's GUI interface and tools, which then create the configuration files used by the kernel when getting online, which are the files in /etc/ppp/peers.
What I did not mention above is that, while I normally make sure I am online before opening up Opera, on this occasion I had opened up Opera before my modem's negotiations with my ISP had completed. I have been avoiding doing this, because of my experiences on my sl5500 using Sharp's ROM 2.38, where Opera can totally destroy one's ability to get online easily if it gets opened up during pppd or chat negotiations.
And, as it turned out, Opera was the culprit in this case on my sl6000 as well. It seems that if I try to go online using the network GUI which pops up when I open Opera, or if I open up Opera while dialup negotiations are in process, my Tosa's network configuration files get overwritten and my ability to get online are destroyed. The precise mechanism is different on the two Zauruses, and solutions are somewhat different as well.
On the Collie, it just becomes harder to get online using dialup, requiring steps I have discussed in many other webpages and posts. On my Tosa, it becomes impossible until I correct the settings in my configuration files.
So, what happened, and what did I do to correct the dialup problem on my sl6000? If this discussion gets too complex or confusing for you because you are not adept at this sort of thing, then please be sure to read the final paragraph below, where I make simple recommendations for people who do not want to edit the configuration files.
There were two simple things that were changed in my configuration files in /etc/ppp/peers. A working file for using a 56k CF Dialup Modem card on the Tosa looks like the following:
noipdefault
57600
connect '/usr/sbin/chat -r /tmp/chat.log -s -v ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT "BUSY" "" "AT&F&C1&D2&K3&S0E0" OK "ATDT1170,,,2345672" CONNECT'
crtscts
lock
modem
user "sdjf@somewhere.net"
defaultroute
connect-delay 1000
remotename DIALUP1217056835
But, when I could not use dialup to get online, the file looked like the following:
noipdefault
115200
connect '/usr/sbin/chat -r /tmp/chat.log -s -v -t 60 ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT "BUSY" "" "AT&F&C1&D2&K3&S0E0" OK "ATDT1170,,,2345672" CONNECT'
crtscts
lock
modem
user "sdjf@somewhere.net"
defaultroute
connect-delay 1000
remotename DIALUP1217056835
Note the change in Baud rate on the second line to 115200, which should have been 57600. And also notice the addition of the "-t 60" parameter on the third line. Once I changed the baud rate back to 57600 and removed the "-t 60" from the third line, my Tosa's ability to get back online was restored. The "-t" parameter sets a parameter for timing out, and I would guess that 60 was too low, that the chat process needed more time to complete. Since removing the parameter, which is not present in any of the chat configuration files on my Collie worked on the sl6000, I did not have to figure out what the correct setting would have been. That setting might be fine for wireless, but it just does not work for a slow dialup connection.
Now, be forewarned that if you edit the kernel ppp configuration files directly instead of using the GUI or Internet Wizard to correct the problem, your revised settings will disappear if you open up the Wizard at all, unless you also correct the files in /home/zaurus/Applications/Network/modules. I have found on both my Collie and Tosa, that if I open the Wizard GUI, even if I do so just to examine information in it, the GUI overwrites my hand edited /etc/ppp/peers files with the settings shown for all connections in the Wizard.
So, be sure to keep backup copies in a different directory or in a system backup if you think you might want to use the GUI to create alternate network options. If you need to retrieve them off a system backup, you can extract just the single files you need instead of having to restore your system to the backup, by following the instructions I have written in my post How to Extract a Single File from Sharp's Backup.
The first time I had this unexpected difficulty getting online with my Tosa, I also edited the files in /home/zaurus/Applications/Network/modules and, in the frenzy, did not keep track of which changes there may also have been necessary steps to restoring my connectivity. But I am posting what I recall in case it might help someone else.
When I examined the contents of /home/zaurus/Applications/Network/modules, I had discovered a number of suspicious entries, and also that my primary and secondary dns entries had either disappeared or were wrong.
What are primary and secondary dns addresses? They are addresses that appear as numbers that can speed up the process of getting online if you know the right ones to use for your ISP (which should be available from their customer service). Without these dns addresses, I find dialup pppd negotiations tend to fail because they timeout. In the /home/zaurus/Applications/Network/modules files, the entries look like:
dns1 = 63.89.1.250
dns2 = 63.89.1.262
The other changes I noticed occurring in the Applications configuration file were that the following correct lines:
speed = 57600
usepeerdns = 1
had been changed to the following:
speed = 115200
usepeerdns = 0
I found that the following line which was in the original file had been removed:
PluginRevision = $Revision: 1.13.8.1 $
And I found that the following lines were added, seeming to indicate that the system erroneously expected to be sending information via DHCP when I was using PPD:
BOOTP = n
DHCP = y
devconfig = modem
devtype = Common Modem Card
So, if you don't want to correct the entries using the Wizard, I would remove the above four lines, correct the other settings I mentioned above, and also would consider adding the following information that had been removed from the failing Applications config file, and is present in my working Applications configuration files. It should be placed right after the line starting with "Name = " in the [Info] section:
PluginRevision = $Revision: 1.13.8.1 $
If the above discussion is way above your head, then I recommend just opening up the Wizard and going through every screen and option and setting extremely carefully, and resetting them to what you want. Make a system backup once you know the settings are working. And, don't ever open up your browser while your Zaurus is in the process of trying to get online, nor ever go online via dialup by using the popup which appears when you open your browser, so your settings will not get corrupted.
If the above does not work and you do not know how to work with the command line, then read my linux newbie and console tutorial pages. And don't forget you can get help from the Zaurus community at http://www.oesf.org/forum
Note that most of the following pages focus on my experiences with dialup on Sharp ROM 2.38 on the sl5500. The first three discuss the effects of Qtopia and of Opera browser on connectivity, and while the examples are dialup on an sl5500, many principles apply to other models and ROMs.
Qtopia on the Zaurus
Opera and My Modem
Modem problem may be Qtopia issue
Please also note that while the focus is on the sl5500 on the next pages, I have added comments for later ROMs to the writeups, based on my experiences with Sharp ROM 1.12 on my sl6000L.
How to Disconnect When Network GUI Does Not Work
Reset CF Device or Modem
How to Halt Respawning of ttyS0
The following blog post talks about solving difficulties getting online due to using unreliable DNS servers:
sl6000l: More Corrupt Network Settings
And the following is a summary of what to check when having problems getting online, summarizing the recommendations of my other blog posts about Dialup Networking Settings:
sl6000l: Dialup Settings Checklist