Summary: | sys-kernel/gentoo-sources-2.6.25-r4 serial driver doesn't work | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthew Schultz <mattsch> |
Component: | New packages | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | major | CC: | net-dialup |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | linux-2.6.25-regression | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 218127 | ||
Attachments: |
log of kppp using pppd to try to bring up ppp0
Successful connection using baselayout & pppd on 2.6.25-r4 Debug of successful ppp connection using baselayout-2 Successful connection with ppp and baselayout-2 under 2.6.24-r3 Minicom connect log |
Description
Matthew Schultz
2008-04-25 17:49:12 UTC
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. |