Yes, I’m not sure how to progress this either. I guess it would not hurt to remove ppp and try installing a ppp package for another openSUSE version to test against.
Does anyone know the last OpenSuSE release that had working dial-up? I know 13.1 works.
Get another version from here openSUSE Software If we can demonstrate that an earlier version works with Leap, then a bug report can be submitted.
The link brings up the 1-click installation, which I cannot use on a different system. If I know what version works I can look for it in RPMfind.
That is unlikely. It has been gone for some time and there was no one willing to provide the necessary support to keep it alive.
Bad news. That means those of use with only dial-up internet connection are excluded from further SuSE use.
I removed kppp with rpm -e --nodeps so as not to remove its dependencies. I then installed the kppp from 13.1, but the result was the same. There is a newer kppp in my DVD repository - 15.08.3-3.1 - so I installed it. I got an KDE error report when I tried to start it: could not access /usr/lib64/libkdeinit5_kppp and /usr/lib64/libkdeinit5_kppp.so. These files were not in usr/lib64, so I installed plasma5-opensuse from the repository, and that broke my system. I see from other forums there are all sorts of problems with plasma5, so I’ll stop at this point. Maybe in a few months Leap will be stable enough to try again. Thank you for the time and effort you have put into trying to help.
No, the idea was not to replace kppp at all - only the ppp package.
I see from other forums there are all sorts of problems with plasma5, so I’ll stop at this point. Maybe in a few months Leap will be stable enough to try again. Thank you for the time and effort you have put into trying to help.
Unfortunately, that was a self-inflicted mistake. Nothing to do with any problems that Leap may or may not have. Never mind, we’ll still be here when you’re ready to give it another go.
I mispoke/mistyped. I removed ppp (with --nodeps) and replaced it with ppp2.4.7-20.7.1 (of 13.1). This made no difference. I then installed the updated kppp, again no difference, then updated all relevant files to current. So: kppp 15.08.3-3.1, ppp 2.4.7-5.1, and wvdial 1.61-9.3 are my current configuration. At this point, after monkeying with permissions, qtwvdialer detects my modem and writes the /etc/wvdial.conf file after giving group write permission. Since ksysguard reports pppd is running when invoked by qtwvdialer/wvdial, it seems to me that all the pieces are there, but are disconnected owing to ownership and permission incompatibilities.
Unfortunately, that was a self-inflicted mistake. Nothing to do with any problems that Leap may or may not have. Never mind, we’ll still be here when you’re ready to give it another go.
When the updated kppp error indicated the need for kde5, I attempted to provide it. I have removed plasma5-opensuse and now have a more or less working installation, at the moment at least, and the latest kppp runs, although still not connecting. I would appreciate hearing from the developers if they have all but given up on dial-up support. If so, I need to look elsewhere.
It has been a <very> long time since I’ve had to dialup an Internet connection, but even then many, many years ago I remember that wvdial was a good dialer choice.
The current documentation describes wvdial as largely automated and suggests it’s possibly beyond an individual User to troubleshoot because its internal heuristics are so complex, but offers to look into any problems you might have. wvdial claims that it will work for practically all connections but might have a problem with ISPs which set up in some odd way. This appears to be your case because you describe a successful initial connection, but it fails at the next step, presumably negotiating your session. At least for wvdial, this suggests the problem is not your installation and configuration of wvdial but how wvdial interacts with your ISP. This also suggests the problem may not be easily solved using another dialer.
Recommend you look specifically at the section “Testing it for the First Time.” It describes how to create a dialup record and log. You can post that result here in this thread on the chance someone here might be able to interpret the results, but your main source of help should be the wvdial Developers themselves.
Post the results on Github. This is easy if you haven’t used Github before, just sign up (It’s free) so you have your own github pages and repos. While logged in, you can then create a new “Issue” at the project link above, and either paste your log into the post or if it’s very long my personal practice is to publish the log to pastebin or in your own repo and then link to that with your published issue. That makes it easy to post your Issue as a clear, brief summary separate from the detailed log.
I recommend the above to get max eyeballs on your issue, but you’ll notice that the man pages for wvdialconf also says you can send to their mail list at wvdial-list@lists.nit.ca
I’m sending this reply from my 13.1 install on the same system as Leap. I installed qtwvdialer and dialed in using it. So there is no problem with my ISP. I continue to suspect permission and ownership are the problems; I had to start qtwvdialer in a root terminal. For laughs, I’ll try this in Leap too.
Anybody know what file(s) are created or configured by 13.1’s YAST2 modem module? I have 13.1 on the same system as Leap, so maybe I can copy them and get qinternet to run.
I copied the appropriate /etc/~ files from my working 13.1 install, but with the same results. Ksysguard shows that smppd and pppd are running, but with no CPU load, so evidently the problem is no communication between the daemon(s) and the ISP. I greatly appreciate your assistance to date, but at this point I think it is not worth the effort to accomplish with my limited abilities what the developers have given up on. My limited talents make a Linux’s administration tools particularly important to me. I started with SuSE 6.1 and Caldera Open Linux since these distributions provided all the configuration tools in proprietary programs. I am still running Libranet 3.0, a Debian with an excellent administration utility and compatibility with WordPerfect8.X, my prefered word processor. I can handle e-mail with it but its web browsers are failing owing to antiquated Java support.
Well, as I suggested in the other thread you started, you should collect some debugging output (as described there as a minimum), and create a bug report. The developers can only assist when such a bug report exists.
The debug report shows that wvdial (as root) has started pppd. However, it times out because no application - konqueror, Firefox, Thunderbird, etc. - can connect with it.
leon@linux-0i6x:~> sudo journalctl -f
root’s password:
– Logs begin at Mon 2015-12-14 16:57:30 EST. –
Jan 02 14:01:00 linux-0i6x pppd[1889]: Connect time 5.0 minutes.
Jan 02 14:01:00 linux-0i6x pppd[1889]: Sent 97 bytes, received 89 bytes.
Jan 02 14:01:01 linux-0i6x pppd[1889]: Connection terminated.
Jan 02 14:01:01 linux-0i6x avahi-daemon[595]: Withdrawing workstation service for ppp0.
Jan 02 14:01:01 linux-0i6x pppd[1889]: Exit.
Jan 02 14:02:05 linux-0i6x kernel: perf interrupt took too long (2523 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
Jan 02 14:04:13 linux-0i6x su[1826]: pam_unix(su-l:session): session closed for user root
Jan 02 14:04:13 linux-0i6x sudo[1817]: pam_unix(sudo:session): session closed for user root
Jan 02 14:04:45 linux-0i6x sudo[2327]: leon : TTY=pts/0 ; PWD=/home/leon ; USER=root ; COMMAND=/usr/bin/journalctl -f
Jan 02 14:04:45 linux-0i6x sudo[2327]: pam_unix(sudo:session): session opened for user root by leon(uid=0)
Jan 02 14:04:57 linux-0i6x su[2331]: (to root) leon on pts/1
Jan 02 14:04:57 linux-0i6x su[2331]: pam_unix(su-l:session): session opened for user root by leon(uid=1000)
Jan 02 14:05:30 linux-0i6x pppd[2394]: Plugin passwordfd.so loaded.
Jan 02 14:05:30 linux-0i6x pppd[2394]: pppd 2.4.7 started by leon, uid 0
Jan 02 14:05:30 linux-0i6x pppd[2394]: Using interface ppp0
Jan 02 14:05:30 linux-0i6x pppd[2394]: Connect: ppp0 <–> /dev/ttyS0
Jan 02 14:05:30 linux-0i6x pppd[2394]: CHAP authentication succeeded:
Jan 02 14:05:30 linux-0i6x pppd[2394]: CHAP authentication succeeded
Jan 02 14:05:31 linux-0i6x pppd[2394]: local IP address 12.76.232.189file:///home/leon/Documents/ifcfg-modem0-13.1.txtfile:///home/leon/Documents/ifcfg-mofile:///home/leon/Documents/ifcfg-mofile:///home/leon/Documents/ifcfg-modem0-13.1.txtdem0-13.1.txtdem0-13.1.txt
Jan 02 14:05:31 linux-0i6x pppd[2394]: remote IP address 199.70.164.71file:///home/leon/Documents/ifcfg-modem0-13.1.txt
Jan 02 14:05:31 linux-0i6x pppd[2394]: primary DNS address 207.69.188.187
Jan 02 14:05:31 linux-0i6x pppd[2394]: secondary DNS address 207.69.188.186
Jan 02 14:10:31 linux-0i6x pppd[2394]: Terminating connection due to lack of activity.
Jan 02 14:10:31 linux-0i6x pppd[2394]: Connect time 5.0 minutes.
Jan 02 14:10:31 linux-0i6x pppd[2394]: Sent 0 bytes, received 0 bytes.
Jan 02 14:10:31 linux-0i6x pppd[2394]: Connection terminated.leon@linux-0i6x:~> sudo journalctl -f
root’s password:
– Logs begin at Mon 2015-12-14 16:57:30 EST. –
Jan 02 14:01:00 linux-0i6x pppd[1889]: Connect time 5.0 minutes.
Jan 02 14:01:00 linux-0i6x pppd[1889]: Sent 97 bytes, received 89 bytes.
Jan 02 14:01:01 linux-0i6x pppd[1889]: Connection terminated.
Jan 02 14:01:01 linux-0i6x avahi-daemon[595]: Withdrawing workstation service for ppp0.
Jan 02 14:01:01 linux-0i6x pppd[1889]: Exit.
Jan 02 14:02:05 linux-0i6x kernel: perf interrupt took too long (2523 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
Jan 02 14:04:13 linux-0i6x su[1826]: pam_unix(su-l:session): session closed for user root
Jan 02 14:04:13 linux-0i6x sudo[1817]: pam_unix(sudo:session): session closed for user root
Jan 02 14:04:45 linux-0i6x sudo[2327]: leon : TTY=pts/0 ; PWD=/home/leon ; USER=root ; COMMAND=/usr/bin/journalctl -f
Jan 02 14:04:45 linux-0i6x sudo[2327]: pam_unix(sudo:session): session opened for user root by leon(uid=0)
Jan 02 14:04:57 linux-0i6x su[2331]: (to root) leon on pts/1
Jan 02 14:04:57 linux-0i6x su[2331]: pam_unix(su-l:session): session opened for user root by leon(uid=1000)
Jan 02 14:05:30 linux-0i6x pppd[2394]: Plugin passwordfd.so loaded.
Jan 02 14:05:30 linux-0i6x pppd[2394]: pppd 2.4.7 started by leon, uid 0
Jan 02 14:05:30 linux-0i6x pppd[2394]: Using interface ppp0
Jan 02 14:05:30 linux-0i6x pppd[2394]: Connect: ppp0 <–> /dev/ttyS0
Jan 02 14:05:30 linux-0i6x pppd[2394]: CHAP authentication succeeded:
Jan 02 14:05:30 linux-0i6x pppd[2394]: CHAP authentication succeeded
Jan 02 14:05:31 linux-0i6x pppd[2394]: local IP address 12.76.232.189file:///home/leon/Documents/ifcfg-modem0-13.1.txtfile:///home/leon/Documents/ifcfg-mofile:///home/leon/Documents/ifcfg-mofile:///home/leon/Documents/ifcfg-modem0-13.1.txtdem0-13.1.txtdem0-13.1.txt
Jan 02 14:05:31 linux-0i6x pppd[2394]: remote IP address 199.70.164.71file:///home/leon/Documents/ifcfg-modem0-13.1.txt
Jan 02 14:05:31 linux-0i6x pppd[2394]: primary DNS address 207.69.188.187
Jan 02 14:05:31 linux-0i6x pppd[2394]: secondary DNS address 207.69.188.186
Jan 02 14:10:31 linux-0i6x pppd[2394]: Terminating connection due to lack of activity.
Jan 02 14:10:31 linux-0i6x pppd[2394]: Connect time 5.0 minutes.
Jan 02 14:10:31 linux-0i6x pppd[2394]: Sent 0 bytes, received 0 bytes.
Jan 02 14:10:31 linux-0i6x pppd[2394]: Connection terminated.
Jan 02 14:10:31 linux-0i6x avahi-daemon[595]: Withdrawing workstation service for ppp0.
Jan 02 14:10:31 linux-0i6x pppd[2394]: Exit.
Jan 02 14:10:31 linux-0i6x avahi-daemon[595]: Withdrawing workstation service for ppp0.
Jan 02 14:10:31 linux-0i6x pppd[2394]: Exit.
Well the journal log for pppd looks okay right up until it disconnects (due to the idle time set in /etc/ppp/opitons). I don’t understand why you say you can’t ‘connect’ with TB etc. Do you mean you can’t successfully browse?
The log shows that you have a local address 12.76.232.189 and DNS addresses are provided for name resolution. Check that you have a valid default route when the PPP connection is active.
ip route
Can you ping the remote IP address (or any public internet address) successfully?
ping 199.70.164.71
ping 8.8.8.8
If you can ping successfully, then move on to checking for valid nameserver assignments in /etc/resolv.conf
Firefox starts normally. When I click a link to e.g. this forum, I get a notice of failure to connect. This is the same with any browser or e-mail client I start.
The log shows that you have a local address 12.76.232.189 and DNS addresses are provided for name resolution. Check that you have a valid default route when the PPP connection is active.
ip route
Output: default dev ppp0 scope link 199.70.164.71 dev ppp0 proto kernel scope link src 12.76.232.244 For comparison, the same output when running wvdial with SuSE13.1: default dev ppp0 scope link 12.70.0.0/8 dev lo scope link 199.70.164.71 dev ppp0 proto kernel scope link src 12.76.233.69
Can you ping the remote IP address (or any public internet address) successfully?
ping 199.70.164.71
Output: ping 199.70.164.71 (199.70.164.71) 56 (84) bytes of data SuSE 13.1 gives the same report.
ping 8.8.8.8
If you can ping successfully, then move on to checking for valid nameserver assignments in /etc/resolv.conf
grep -i name /etc/resolv.conf
ping 8.8.8.8 yields no response with either Leap or 13.1.
Output from “ip route”: default dev ppp0 scope link 199.70.164.71 dev ppp0 proto kernel scope link src 12.76.232.244 For comparison, the same output when running wvdial with SuSE13.1: default dev ppp0 scope link 12.70.0.0/8 dev lo scope link 199.70.164.71 dev ppp0 proto kernel scope link src 12.76.233.69 Output from “ping”: ping 199.70.164.71 (199.70.164.71) 56 (84) bytes of data SuSE 13.1 gives the same report. Output from “ping 8.8.8.8”: yields no response with either Leap or 13.1. I don’t understand why you can’t read my previous response; it displays clearly in my browser (Firefox.)