I am using kppp-3.5.8 to dial up with kernel 2.6.25-r1 (gentoo-sources) which auto pulled the working config from 2.6.24-r3 (gentoo-sources) when I compiled it. kppp is no longer dialing out with kernel 2.6.25. I have confirmed this by booting back into 2.6.24-r3 and dialing out with kppp. I am guessing that this is a problem with ppp since kppp gets a dial tone, dials out, says it has made the connection and then times out saying there is a problem with pppd. After it requests to restart pppd with debug, it outputs a log of what happens. I will attach that log. Reproducible: Always Steps to Reproduce: 1. Boot into 2.6.25-r1 gentoo sources 2. Connect to ISP with kppp Actual Results: pppd fails to create interface and times out. Expected Results: pppd creates ppp0 interface. emerge --info: Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r3 x86_64) ================================================================= System uname: 2.6.24-gentoo-r3 x86_64 AMD Opteron(tm) Processor 144 Timestamp of tree: Fri, 25 Apr 2008 15:15:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r9, 2.5.1-r5 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.2 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.mirrors.easynews.com/linux/gentoo/ http://mirror.phy.olemiss.edu/mirror/gentoo http://mirror.espri.arizona.edu/gentoo/" LANG="en_US.utf8" LC_ALL="en_US.utf8" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/voip /usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acl acpi alsa amd64 apache2 async audiofile avi bcmath berkdb bzip2 calendar caps cddb cjk clamav cli cracklib crypt ctype cups curl curlwrappers dbus dga dio directfb dri dts dvb dvd dvdread emu-linux-x86 encode exif fbcon ffmpeg flac fortran ftp gd gdbm gif gmp gnutls gpm gtk gtk2 hash iconv id3 ieee1394 imagemagick imlib innodb ipv6 isdnlog ithreads java javascript jpeg jpeg2k json kde lcms ldap ldap-sasl libcaca live logrotate lzo mad matroska mcal mhash midi mime mjpeg mmx mmxext mng mp3 mp4 mpeg mplayer msession mssql mudflap mysql mysqli ncurses network nls nptl nptlonly nsplugin nvidia offensive ogg openal opengl openmp osc oss pam pcntl pcre pdf pdo pear perl png posix pppd pvr python qt qt3 qt4 quicktime readline reflection samba sasl sdl seamonkey session simplexml snmp soap sockets spell spl sqlite sse sse2 ssl suhosin svg syslog tcpd theora threads tidy tiff tokenizer transcode truetype unicode urandom usb utempter v4l v4l2 vcd vorbis wddx wxwindows x264 xforms xine xml xml2 xorg xpm xprint xv xvid xvmc zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia nv vesa fbdev v4l" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 150959 [details] log of kppp using pppd to try to bring up ppp0
Judging after the log you attached, I would say that dialer program didn't made the connection. Use baselayout ppp support and see if it fails in the same way.
(In reply to comment #2) > Judging after the log you attached, I would say that dialer program didn't made > the connection. Use baselayout ppp support and see if it fails in the same way. > Dialing out with baselayout-2/openrc is broken right now apparently. kppp dials out with kernel 2.6.24-r3 under baselayout-2/openrc but it does not dial out with kernel 2.6.25-r1. So why would it work on 2.6.24 and not 2.6.25?
Ok so I just did some testing and I finally figured out what the correct syntax for getting baselayout-2/openrc to dial out. So yes dial up is working with 2.6.25-r1 using baselayout-2. Now it's looking like the problem lies with kppp and not pppd. I have not changed the settings. When I reboot to 2.6.24, it works fine. Here's the sequence (in 2.6.25-r1) when dialing out with kppp: KPPP Login Script Debug Window: ATZ OK ATM1L1 OK ATDT5551234 CONNECT 24000 V42bis Status says: Starting pppd... KPPP Log window pops up: May 19 21:06:08 gandalf pppd[3877]: pppd 2.4.4 started by mschultz, uid 1000 May 19 21:06:08 gandalf pppd[3877]: Using interface ppp0 May 19 21:06:08 gandalf pppd[3877]: Connect: ppp0 <--> /dev/ttyS2 May 19 21:06:38 gandalf pppd[3877]: Terminating on signal 15 May 19 21:06:44 gandalf pppd[3877]: Connection terminated. May 19 21:06:44 gandalf pppd[3877]: Modem hangup May 19 21:06:44 gandalf pppd[3877]: Exit.
So the result is still the same. The modem dials out, makes the connection (hear the noise) but the connection isn't established and the ip address doesn't get set: May 19 21:29:11 gandalf pppd[4742]: pppd 2.4.4 started by mschultz, uid 1000 May 19 21:29:11 gandalf pppd[4742]: using channel 6 May 19 21:29:11 gandalf pppd[4742]: Using interface ppp0 May 19 21:29:11 gandalf pppd[4742]: Connect: ppp0 <--> /dev/ttyS2 May 19 21:29:11 gandalf pppd[4742]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c627ab5> <pcomp> <accomp>] May 19 21:29:14 gandalf pppd[4742]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c627ab5> <pcomp> <accomp>] May 19 21:29:17 gandalf pppd[4742]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c627ab5> <pcomp> <accomp>] May 19 21:29:20 gandalf pppd[4742]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c627ab5> <pcomp> <accomp>] May 19 21:29:23 gandalf pppd[4742]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c627ab5> <pcomp> <accomp>] May 19 21:29:26 gandalf pppd[4742]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c627ab5> <pcomp> <accomp>] May 19 21:29:29 gandalf pppd[4742]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c627ab5> <pcomp> <accomp>] May 19 21:29:32 gandalf pppd[4742]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c627ab5> <pcomp> <accomp>] May 19 21:29:35 gandalf pppd[4742]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c627ab5> <pcomp> <accomp>] May 19 21:29:38 gandalf pppd[4742]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c627ab5> <pcomp> <accomp>] May 19 21:29:41 gandalf pppd[4742]: Terminating on signal 15 May 19 21:29:41 gandalf pppd[4742]: sent [LCP TermReq id=0x2 "User request"] May 19 21:29:44 gandalf pppd[4742]: sent [LCP TermReq id=0x3 "User request"] May 19 21:29:47 gandalf pppd[4742]: Connection terminated. May 19 21:29:47 gandalf pppd[4742]: Modem hangup May 19 21:29:47 gandalf pppd[4742]: Exit.
Well, maybe the peer doesn't understand PPP. Try to connect with minicom and post here what you see after "CONNECT 24000 V42bis". You should see some gibberish beginning with ~.
(In reply to comment #6) > Well, maybe the peer doesn't understand PPP. Not sure what you mean here. > > Try to connect with minicom and post here what you see after "CONNECT 24000 > V42bis". You should see some gibberish beginning with ~. > I just installed minicom but I'm not familiar with how it works. Do you know what I need to type to get it to connect?
In your case, you will have to type: ATZ ATM1L1 ATDT5551234
Welcome to minicom 2.2 OPTIONS: I18n Compiled on May 20 2008, 14:48:07. Port /dev/ttyS2 Press CTRL-A Z for help on special keys OK AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 OK ATZ OK ATM1L1 OK ATDT5551234 CONNECT 24000 V42bis UQKT2 ** Welcome to hou4-dial1.popsite.net ** Login: username@dialup4less.com Password: Entering PPP Mode. IP address is 66.217.209.165 MTU is 1500.
(In reply to comment #9) > Welcome to minicom 2.2 > > OPTIONS: I18n > Compiled on May 20 2008, 14:48:07. > Port /dev/ttyS2 > > Press CTRL-A Z for help on special keys > > OK > AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 > OK > ATZ > OK > ATM1L1 > OK > ATDT5551234 > CONNECT 24000 V42bis > > > > > > > > > > > > > > > > > > > > > > > > > > UQKT2 ** Welcome to hou4-dial1.popsite.net ** > > > Login: username@dialup4less.com > Password: > Entering PPP Mode. > IP address is 66.217.209.165 > MTU is 1500. > Sorry, that was a successful test using 2.6.24-r3. Now here's a test with 2.6.25-r1. It doesn't do anything after CONNECT 24000 V42bis. It just hangs there: Welcome to minicom 2.2 OPTIONS: I18n Compiled on May 20 2008, 14:48:07. Port /dev/ttyS2 Press CTRL-A Z for help on special keys OK AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 OK ATZ OK ATM1L1 OK ATDT5551234 CONNECT 24000 V42bis
Your dialup provider don't use PPP authentication, instead it uses the old fashion terminal authentication. For that you have to use the dialer program capabilities (kppp use autodetection for that, it looks for strings like "login"). Anyway, it has nothing to do with ppp, at best it has something to do with serial driver. Try to hit enter several times in minicom and see if you receive the login prompt.
(In reply to comment #11) > Your dialup provider don't use PPP authentication, instead it uses the old > fashion terminal authentication. For that you have to use the dialer program > capabilities (kppp use autodetection for that, it looks for strings like > "login"). Anyway, it has nothing to do with ppp, at best it has something to do > with serial driver. > > Try to hit enter several times in minicom and see if you receive the login > prompt. > Ok I updated the subject again to better reflect what the problem is. What is baselayout using in pppd to allow it to dial up while the other programs fail? Also I tried to dial up again with minicom and this time I hit enter several times. After a little while, it showed this text on the next line: NO CARRIER Since this is looking like a kernel bug in the serial driver, are you going to notify the kernel developers or should I submit this bug on their bugzilla?
Created attachment 154363 [details] Successful connection using baselayout & pppd on 2.6.25-r4 Just for more information, I'm including a log of a successful connection using 2.6.25-r4, baselayout-2 and pppd.
Baselayout use chat program for starting the serial connection. The chat script is responsible to configure the modem and also authenticate local user to the peer when terminal authentication is used. However, chat is a dumb program and it will do only exactly what its script is instructing it to do. In your case (ppp_connect.txt), chat wasn't the program that authenticated you. pppd did that by using PAP so it seems your provider supports PPP authentication after all. I'm a little confused about your report. First you told me you cannot start a dialup connection when you are using kernel 2.6.25 and now you say it is possible to start it, although the logs aren't exactly showing that it works. At least there is some proof that pppd communicated with the peer up to a certain point. Please add "debug" to pppd_ppp0 and post the logs again. Also, don't forget to add "modem crtscts".
> I'm a little confused about your report. First you told me you cannot start a > dialup connection when you are using kernel 2.6.25 and now you say it is > possible to start it, although the logs aren't exactly showing that it works. Initially I didn't have it working due to new configuration (absence of bash arrays?) but I figured it out and got it working through baselayout-2. I was using kppp for a while because I didn't have dialing in baselayout-2 working. Once I upgraded to kernel 2.6.25, kppp stopped working (it still doesn't work) but baselayout-2 dial up seems to work fine. > > Please add "debug" to pppd_ppp0 and post the logs again. Also, don't forget to > add "modem crtscts". > I have crtscts set in both baselayout-2 and kppp. Here's the log of kppp failing to dial up (with debug on): May 27 09:18:31 gandalf pppd[770]: pppd 2.4.4 started by mschultz, uid 1000 May 27 09:18:31 gandalf pppd[770]: using channel 48 May 27 09:18:31 gandalf pppd[770]: Using interface ppp0 May 27 09:18:31 gandalf pppd[770]: Connect: ppp0 <--> /dev/ttyS2 May 27 09:18:31 gandalf pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x641121d5> <pcomp> <accomp>] May 27 09:18:34 gandalf pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x641121d5> <pcomp> <accomp>] May 27 09:18:37 gandalf pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x641121d5> <pcomp> <accomp>] May 27 09:18:40 gandalf pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x641121d5> <pcomp> <accomp>] May 27 09:18:43 gandalf pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x641121d5> <pcomp> <accomp>] May 27 09:18:46 gandalf pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x641121d5> <pcomp> <accomp>] May 27 09:18:49 gandalf pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x641121d5> <pcomp> <accomp>] May 27 09:18:52 gandalf pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x641121d5> <pcomp> <accomp>] May 27 09:18:55 gandalf pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x641121d5> <pcomp> <accomp>] May 27 09:18:58 gandalf pppd[770]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x641121d5> <pcomp> <accomp>] May 27 09:19:01 gandalf pppd[770]: Terminating on signal 15 May 27 09:19:01 gandalf pppd[770]: sent [LCP TermReq id=0x2 "User request"] May 27 09:19:04 gandalf pppd[770]: sent [LCP TermReq id=0x3 "User request"] May 27 09:19:07 gandalf pppd[770]: Connection terminated. May 27 09:19:07 gandalf pppd[770]: Modem hangup May 27 09:19:07 gandalf pppd[770]: Exit.
Created attachment 154471 [details] Debug of successful ppp connection using baselayout-2
Offtopic: your connection doesn't use any kind of compression. Peer don't want to accept anything else but lsz, algorithm is not supported by pppd. What I find particularly strange is the big pause between connection establishment and the first PPP frame you receive (9 secs!?!). Please run the exact same baselayout setup using the kernel 2.6.24 and see if it behaves the same. Those empty chat log lines are also very strange. Looks like as if the peer has sent a bunch of 0x0 chars right after connection establishment.
(In reply to comment #17) > Offtopic: your connection doesn't use any kind of compression. Peer don't want > to accept anything else but lsz, algorithm is not supported by pppd. Damn it. It's bad enough that it never connects at more than 24kbps on a v90 modem but compression isn't supported either? Argh! A quick google search doesn't seem to yield any ISPs in the US that support linux and MPPE, BSD or Deflate. Any ideas as to why linux supports a bunch of compression protocols no ISP seems to support? Maybe I should bother the kernel developers and beg for LZS compression support. I'm curious. How do you determine whether a compression protocol is supported or not? > What I find particularly strange is the big pause between connection > establishment and the first PPP frame you receive (9 secs!?!). Please run the > exact same baselayout setup using the kernel 2.6.24 and see if it behaves the > same. I will attach the ppp connection with debug on under 2.6.24-r3. > Those empty chat log lines are also very strange. Looks like as if the peer has > sent a bunch of 0x0 chars right after connection establishment. You are correct on that. I don't know why they send a bunch of 0x0 characters.
Created attachment 154901 [details] Successful connection with ppp and baselayout-2 under 2.6.24-r3
(In reply to comment #18) > Damn it. It's bad enough that it never connects at more than 24kbps on a v90 > modem but compression isn't supported either? Argh! A quick google search > doesn't seem to yield any ISPs in the US that support linux and MPPE, BSD or > Deflate. Any ideas as to why linux supports a bunch of compression protocols > no ISP seems to support? Maybe I should bother the kernel developers and beg > for LZS compression support. In /usr/share/doc/ppp-*/README chapter "Compression methods" you will see why LZS is not supported. > I'm curious. How do you determine whether a > compression protocol is supported or not? PPP use negociation between peers to establish the link parameters. Basically one peer propose a set of parameters (ConfReq) and the other will do the following: - another ConfReq - some parameters needs to be modified - ConfAck - accept and acknowledge a set of parameters - ConfRej - reject all or a subset of parameters - ConfNack - take note of the parameters rejection Conclusion: There is no difference between PPP session made using kernel 2.6.24 compared with the one that used kernel 2.6.25, except that you used a different user ID. Therefore, there is nothing wrong in kernel or pppd. I can only conclude that kppp connection timeout is too short to pass that 9 seconds of silence. All you have to do is to configure the login script in kppp to wait for the "UQKT2 ..." string before starting pppd. Closed as INVALID.
> Conclusion: > There is no difference between PPP session made using kernel 2.6.24 compared > with the one that used kernel 2.6.25, except that you used a different user ID. > Therefore, there is nothing wrong in kernel or pppd. > I can only conclude that kppp connection timeout is too short to pass that 9 > seconds of silence. All you have to do is to configure the login script in kppp > to wait for the "UQKT2 ..." string before starting pppd. > > Closed as INVALID. > I'm not following here. I do not change any kppp settings between 2.6.24 or 2.6.25 but it dials out fine with 2.6.24 but not with 2.6.25? Are you sure something hasn't changed in the kernel recently which caused kppp to break?
(In reply to comment #21) > > Conclusion: > > There is no difference between PPP session made using kernel 2.6.24 compared > > with the one that used kernel 2.6.25, except that you used a different user ID. > > Therefore, there is nothing wrong in kernel or pppd. > > I can only conclude that kppp connection timeout is too short to pass that 9 > > seconds of silence. All you have to do is to configure the login script in kppp > > to wait for the "UQKT2 ..." string before starting pppd. > > > > Closed as INVALID. > > > > I'm not following here. I do not change any kppp settings between 2.6.24 or > 2.6.25 but it dials out fine with 2.6.24 but not with 2.6.25? Are you sure > something hasn't changed in the kernel recently which caused kppp to break? > In addition, why is minicom failing under the same circumstances on 2.6.25 but not on 2.6.24?
Perhaps you can see better as to what's going on if you attempt to connect to it yourself. The ISP is dialup4less.com and the number I'm dialing is 9364639503 (US Number - add 1 in the beginning for long distance)
I failed to find any evidence of malfunction, but if you see different minicom behaviour between 2 sessions that runs on different kernels and have same settings, I suggest you post it here. Re-assigned to kernel team.
Created attachment 155311 [details] Minicom connect log Top displays 2.6.25 and bottom 2.6.24. The difference is on 2.6.25, the last thing to display is CONNECT and it freezes after that. Booting into 2.6.24 with the same settings proceeds after CONNECT and properly prompts for the login as shown here.
Can you reproduce this on the latest development kernel, currently 2.6.26-rc8?
(In reply to comment #26) > Can you reproduce this on the latest development kernel, currently 2.6.26-rc8? > Yes this indeed looks like a bug with kernel 2.6.25. I just tested with vanilla 2.6.26-rc8 and it looks like it has been fixed. minicom dials correctly with 2.6.24 and 2.6.26 but not with 2.6.25. Looks like gentoo-sources 2.6.25 needs to be patched to fix the serial driver bug.
which driver are we talking about?
(In reply to comment #28) > which driver are we talking about? > Are there multiple serial port drivers? All I know is minicom and kppp try to initiate a serial connection and they both fail on 2.6.25 while baselayout ppp successfully dials out.
Can you test with the recently released gentoo-sources-2.6.25-r9. It includes the latest 2.6.25.17 patch and I want to see if it was addressed there.
