Re: 2 questions about dialup pppd use
Bill Unruh writes: At a guess, your NTP time sync is causing a large jump because your clock is off by a large amount. pppd uses the gettimeofday() function to compute CONNECT_TIME, and the value returned by that function is UTC -- meaning that NTP will _change_ the value out from under pppd, leading to incorrect calculation. IF that is the case, you would expect the time to be negative, although 71582784 min is 254 seconds short of 2^32, so yours is probably the correct explanation. It depends on which direction the clock was corrected. It could have been either fast or slow before ntpdate was done. Note that ntpdate is a really really terrible way of setting the time. Instead use say chrony, which was designed for the up and down of a modem connection. Run chronyd which will gradually slew the clock to the correct time without introducing discontinuities into the time ( which is bad for file creation times and modification times as well, and cause havoc withsome programs). Good suggestion, though I think ntpdate is necessary if you expect to run xntpd -- NTP itself won't sync up unless the clock is close to right. -- James Carlson [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ppp in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Client requesting its authentication
[EMAIL PROTECTED] writes: You'd do it with refuse-pap refuse-chap refuse-mschap refuse-mschap-v2. Sorry, I made the question in a wrong manner. I don't want to tell the peer what authentication to do if necessary, but I want to tell it that I want to authenticate myself (and with EAP), else I won't connect. Is there a way? That's exactly the question I answered -- for the client aka authenticatee case. If the peer (authenticator, server) proposes some other method, pppd will refuse and suggest EAP instead. I also noted that you don't need to configure this at all, because this is already the default for pppd: if the peer requests something we can't do (because it's not configured), we'll suggest something we can do. For the server (authenticator) case, you use the require-* options to tune the behavior. And as in the client case, there's really no need to do this, as offering the best usable algorithm first is what pppd does by default. -- James Carlson [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ppp in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Client requesting its authentication
[EMAIL PROTECTED] writes: Instead, one side should request it, and the EAP method *itself* provides mutual authentication. Ok. The server must request it. But if the server doesn't request authentication? The client will connect to an untrusted server. We don't want this to happen. If it doesn't request it, then, clearly, it doesn't support it or want to demand it of its peers. If your local policy rules are such that you won't talk to someone who doesn't initiate authentication, then I think the best answer is just to disconnect. Is logged between a windows box (client) set to do eap-tls and the pppd server. The server don't want to authenticate the client, but the client want eap authentication for itself and finally close the negotiation. Wacky. ;-} If it wants EAP authentication, why on Earth didn't it just ask for EAP authentication directly? What's the point of this little dance? Because the server must ask. OK ... but it still seems rather pointless to me. That said, I see the point now, and, no, there's no option that currently does that. You'll need to add one or, better yet, make pppd just do that by default when EAP TLS client side is configured. -- James Carlson [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ppp in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blowfish encryption
Christopher Fowler writes: The only problem with ssh is that it is one protocol. There are many protocols that travel across the ppp link. Some fo them not encryted and can not be encrypted. I stopped using telnet a long time ago. Also with these devices there are protocols that are routed across that link we have no control over so doing encryption inside of ppp would cover all the bases. As I mentioned, if it's really a PPP issue (not clear that it is, as the threat model isn't clear), then ECP is likely to be the right answer. If it's an IP issue (are you worried about non-IP protocols?), then I'd certainly recommend the use of IPsec. It defends against things that ssh (and, for that matter, SSL/TLS) cannot, works whether or not you use PPP, works on an end-to-end basis, and doesn't require changing everyone's implementations. -- James Carlson [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ppp in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CHAP Auth issue at CentOS-6.8
On 09/13/2016 09:25 AM, Sekar D wrote: > Hi James, > > Thanks for helping me. > > Yes. It happens only when I bring up DSL line before 2 minutes. The > same DSL lines are working fine without any issue at CentOS-5.11. I > could see the issue only at CentOS-6.8. So I would like to know that I > need to configure more to avoid these issues. One other thing you might consider doing, now that we know that this is a PPPoE connection: try running wireshark and capturing traffic from a failed connection, a long delay, and then a successful one. At a guess, PPPoE is the problem. I suspect the logs will show PADT messages coming from your system (which may or may not be malformed), along with either no response from the peer, or retransmitted messages from the peer that are being ignored by your system. My current hypothesis is that PPPoE is keeping the previous connection up too long, and the peer doesn't like seeing you log in more than once at a time. I don't believe anything is going wrong with PPP itself. -- James Carlson 42.703N 71.076W <carls...@workingcode.com> -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CHAP Auth issue at CentOS-6.8
On 09/13/2016 09:25 AM, Sekar D wrote: > Yes. It happens only when I bring up DSL line before 2 minutes. The > same DSL lines are working fine without any issue at CentOS-5.11. I > could see the issue only at CentOS-6.8. So I would like to know that I > need to configure more to avoid these issues. I don't think there's anything you can do. The peer is refusing your request. I think it's game over at that point. There's nothing obviously wrong on your end, at least in what's revealed in this short debug log. I suggest calling the provider's technical support line. You'll need their help in finding out why your connection request is being refused. If you can't do that, or if they can't help, then you'll need to find a new provider. > Sep 13 15:16:15 Linux pppoe[9426]: PADS: Service-Name: '' > Sep 13 15:16:15 Linux pppoe[9426]: PPP session is 11525 (0x2d05) PPPoE is in use. That helps a bit. It would help to know if there's anything different about a successful connection. Could it be that it just takes a *very* long time for this provider to tear down a previous connection? Could there be a bug in PPPoE rather than in pppd itself? (Note that PPPoE is just a transport; it's completely distinct from PPP.) > Sep 13 15:16:16 Linux pppd[9425]: sent [LCP ConfReq id=0x1 > ] > Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP ConfReq id=0x4c > ] > Sep 13 15:16:16 Linux pppd[9425]: sent [LCP ConfAck id=0x4c > ] > Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP ConfAck id=0x1 > ] That looks like a perfectly reasonable LCP negotiation, with the peer asking for CHAP authentication. > Sep 13 15:16:16 Linux pppd[9425]: sent [LCP EchoReq id=0x0 magic=0x539b3bc6] > Sep 13 15:16:16 Linux pppd[9425]: rcvd [CHAP Challenge id=0x1 > <24a06e14743d399c933b61865730ea63>, name = "BSLYO656"] > Sep 13 15:16:16 Linux pppd[9425]: sent [CHAP Response id=0x1 > <502b6f4ee944310f014e0033e9b5438b>, name = "fti/hbufbty"] > Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP EchoRep id=0x0 magic=0x22bf9b51] They challenge and you respond. No problem there. > Sep 13 15:16:16 Linux pppd[9425]: rcvd [CHAP Failure id=0x1 "CHAP > authentication failure, unit 509"] The peer refuses your request, and gives a pretty bogus error message to boot. What the heck does "unit 509" mean? It's certainly not any kind of standard PPP error message. If anybody knows, it would have to be the technical support people at your provider. > Sep 13 15:16:16 Linux pppd[9425]: CHAP authentication failed: CHAP > authentication failure, unit 509 > Sep 13 15:16:16 Linux pppd[9425]: CHAP authentication failed > Sep 13 15:16:16 Linux pppd[9425]: sent [LCP TermReq id=0x2 "Failed to > authenticate ourselves to peer"] Due to the authentication failure, we shut things down. This is all normal. > /var/run/pppoe-adsl-0.pid.pppoe -I eth1.101 -T 0 -U -m 1412 , pid > 9426 This part is sort of interesting. Why "-U"? I'm far from an expert in Roaring Penguin's PPPoE client, but I think that would imply that you have multiple simultaneous PPPoE sessions running. Does your provider even allow that? -- James Carlson 42.703N 71.076W <carls...@workingcode.com> -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CHAP Auth issue at CentOS-6.8
On 09/13/2016 08:33 AM, Sekar D wrote: > I did not see kind of issue on CentOS-5.11 . Please let me know if I > need to change any config parameters. It's a little hard to tell. What are your current configuration parameters? Have you tried running pppd with debugging enabled? It would help to have a trace of the connection in order to diagnose the failure mode. The starting point is the pppd "debug" option, but if you're controlling this connection with ifup/ifdown scripts, you'll have to look at your system configuration to find out what pppd options are in use for that link. One possible answer, if all else fails, would be to run this while the link is in the process of establishing: ps -fp `pgrep -d, pppd` | cat (Yes, the "cat" is important; it tricks ps into printing the whole line.) What kind of connection is this? That is, what's the underlying serial link? Is it a physical wire on a serial port? Is it a USB serial port? Is it ISDN? Is it PPPoE or PPTP or L2TP? Is it something else? At a guess, the problem is on the remote end. Typically, a user's PPP connection is set up to be a "client" -- that is, to reply to authentication requests from the peer and not to request authentication from the peer. This means that the remote system you're talking to asked for your CHAP credentials, your system supplied them, and the remote system denied your access based on those credentials. If that only happens "sometimes" or is dependent on timing, then it sounds like the remote system has some kind of usage restriction. -- James Carlson 42.703N 71.076W <carls...@workingcode.com> -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem: How to force(?) pcomp and accomp
On 10/01/16 11:38, Manish Kambdur wrote: > I didn't see any compile time options to disable address and and > pcomp support from pppd, but to me it seems like that's what has > happened in OpenWRT version of pppd. Yes, it does seem like the OpenWRT version is behaving that way. Assuming you can't find those options present in /etc/ppp/options or some other file related to normal pppd configuration, I think it'd be reasonable to assume that the version of pppd used in OpenWRT has been modified, and you should ask the maintainers of that software for help. If this is a reasonably modern version of pppd, you should be able to use the "dump" option to print out all of the options and the places where those options are set. This would hardly be the first time some distributor has modified pppd for their distribution. A quick google search on "openwrt patches pppd" turns up things like this: https://dev.openwrt.org/ticket/10095 I don't see changes for accomp/pcomp in their patch list, but it does seem like they do make some changes before redistributing. > I tried reading up about ppp and pppd, but I couldn't resolve this > problem. Any help will be appreciated. Wish I could offer more, but I think you've correctly diagnosed the problem. For what it's worth, I think the peer you're talking to is garbage. At a minimum, any reasonable implementation of PPP should accept the defaults, which means that dropping the link just because your end doesn't want to do ACFC and PFC is pure nonsense. How could any competent implementation fail to operate without header compression? How much do you trust that peer if they can't get the basics of PPP right? -- James Carlson 42.703N 71.076W <carls...@workingcode.com> -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Starting dhcpcd terminates the established PPPoE connection
On 12/29/16 06:35, Sven Kirmess wrote: > Hi James, > > Thanks for looking into this. > > On Wed, Dec 28, 2016 at 6:20 PM, James Carlson <carls...@workingcode.com> > wrote: > >> It's remotely possible that the disconnection is unrelated to DHCP and >> that it's just coincidence. That's why I suggested posting more of the >> logs. But I think it's just a very remote possibility. > > I've added the log files to dropbox. I've rebooted the system at 01:39 > and at 01:59. > > <https://www.dropbox.com/s/k6s70fzl7ee4o42/daemon.txt?dl=0> > <https://www.dropbox.com/s/1h6mqvcxvstvf4y/debug.txt?dl=0> > <https://www.dropbox.com/s/msg66lt19f95772/kern.txt?dl=0> > <https://www.dropbox.com/s/lnm6aw5fzskq0d4/ppp.txt?dl=0> > <https://www.dropbox.com/s/qxcx7wm4yj7qhr5/syslog.txt?dl=0> I don't see much that's special going on there. I still think the problem is on the peer's side, not yours. Does /libexec/dhcpcd-run-hooks do anything crazy, such as pkill? -- James Carlson 42.703N 71.076W <carls...@workingcode.com> -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Session 152 terminated -- received PADT from peer
On 07/18/17 07:42, Sekar D wrote: > Please let me know if someone can help here. Probably not, but I'll give a try. >> I am getting the following error messages through PPP connection >> without any manual intervention. >> >> Session 152 terminated -- received PADT from peer PADT is the PPPoE termination message. It means that your peer has decided to close the session. It could do so for any of a wide number of reasons, and this doesn't seem to indicate any details. For example, your peer: - may be rebooting or administratively disabled - may have a session time limit that's enforced by shutdown - may have a bug that causes the session to crash - may have detected some configuration problem - may have some other internal limitation It's really not clear without getting information from the peer. You might possibly try getting a tcpdump (or wireshark) trace on the Ethernet interface over which PPPoE is being run, and that might help reveal the events surrounding the connection closure. >> PADT: Generic-Error: RP-PPPoE: Child pppd process terminated >> Sent PADT >> Modem hangup >> Exit >> Connection terminated. >> ADSL connection lost; attempting re-connection Looks like all is working as expected following a disconnect by the peer. >> Please let me know if any configuration needs to be added. >> >> /etc/ppp/pppoe-server-options >> # PPP options for the PPPoE server >> # LIC: GPL >> require-chap >> login >> lcp-echo-interval 10 >> lcp-echo-failure 2 Are you really running a PPPoE server? I had expected that you were running a client. What exactly are you doing with PPPoE? In general, if you're trying to connect to your ISP, then at least "require-chap" and "login" are wholly inappropriate. They demand that your peer identify itself to you -- which ISPs almost never do -- and weirdly ask to use both CHAP and local authentication, a combination that's _fundamentally_ impossible because CHAP doesn't reveal the passphrase on the wire. Whoever set up those options was probably pretty confused. If you can do so, I suggest running with "debug" and "updetach" options, and forwarding the complete trace output to the list. If there's a problem with pppd configuration (as opposed to PPPoE or some other issue), that should help reveal what's going on at the PPP level. -- James Carlson 42.703N 71.076W <carls...@workingcode.com> -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to know when a link is established or destroyed?
On 10/22/18 06:28, Morel Bérenger wrote: > I am using pppd to have network access through GPRS/3G/4G on systems I > do not have physical access to. > > Since I want the system to be up almost always, I am trying to manage > my daemons through runit (daemontools), which works by keeping child > process foreground and restart it when it dies for a reason or another, > eventually logging whatever came on stdout. Please post the pppd options you're using today. I'm going to guess that you're using at least "nodetach". Anything else? (See the man page for sources of options; /etc/ppp/options is the main one.) Please post debug traces, or a link to them; particularly those you feel highlight problems that you're seeing. It's almost impossible to determine the source of problems without traces. There are multiple ways to get a trace. The simplest is to use the "debug" option, and get the log messages via syslog. Use "logfile /path/to/some/file" if you can't use syslog for some reason. (Note: don't use kdebug unless there are kernel-level problems. This doesn't sound like a kernel-level problem.) The usual way to set up an always-on connection with pppd is NOT via some external utility, but by using the built-in restart capability in pppd. You can use use the external utility if you want, but I think it'll be harder to manage. To use the built-in restart, set "persist maxfail 0" as options. If you insist on using an external utility to do this, you will probably want something like "maxfail 1" or "maxfail 2" instead. If the peer you're talking to is willing, I recommend using the lcp-echo-interval and lcp-echo-failure options with any sort of link that needs to be reliable. These options (when usable -- the peer may balk, if the peer is poorly implemented) allow PPP to detect when the point-to-point link has lost connectivity, and will shut down (and retry, if "persist" is enabled or if some sort of external restart utility is used). Note that most GPRS implementations, at least the ones I've seen, are horror shows, and that stems, at least in part, from execrable "standards" set for their use of Internet protocols. Your mileage may vary. > I can run pppd in that way, but I have no idea about how to know if the > connection is really established or not, and on some systems manual > reboot is sometimes needed, because it seems that pppd only tries 3 or > 4 times to restore connection when link is cut, and if not it just > stays alive doing nothing. The connection is up for IPv4 traffic when the optional executable script (or program) /etc/ppp/ip-up is invoked. It's down when /etc/ppp/ip-down is invoked. You should also see the IFF_UP flag on the interface change state; a routing socket might be good for monitoring that. Having the PPP link up and having LCP+auth+IPCP negotiated (and thus the local IP interface marked IFF_UP) does *NOT*, of course, guarantee that you have a path to "the Internet" (or whatever wider network you believe you're connecting to). It merely means that an IP path has been established to the peer -- PPP is point-to-point, of course. Whether that peer is capable and willing to transport IP traffic for you is a completely separate matter. If your "failures" involve losing IP routing while the PPP link is up, then that may just be par for the course. You'll need some other monitoring system to tell you when or if that happens. There's nothing that PPP can possibly do to help with that; it's only a link layer protocol. > So, I think either I missed the options needed to do what I need, or > there is a tool to manage pppd that I don't know, or it is not > implemented at all. > > If if is not implemented at all, is it intended? Would it be fine if I > submit a patch doing this? Submitting patches is fine, but if you do so, please indicate precisely what the patch does and (if possible) why the existing features don't fulfill your needs. It's often very hard to review changes out of the blue that don't appear to solve problems. -- James Carlson 42.703N 71.076W
Re: How to know when a link is established or destroyed?
On 11/13/18 07:08, Morel Bérenger wrote: >> The simplest is to use the "debug" option, and get the log messages >> via syslog. Use "logfile /path/to/some/file" if you can't use syslog >> for some reason. (Note: don't use kdebug unless there are >> kernel-level problems. This doesn't sound like a kernel-level >> problem.) > > Are logs sent to a file exactly the same as those sent to syslog? Yes, if you use the "logfile /path/to/some/file" option. Missing from the logs you sent is the "debug" option, so the information you've provided is *very* sketchy and not very useful. However, I do have some questions about it. During the first 197.7 minute-long session, did you successfully connect? Did you get actual IP service on the initial try? I don't know whether you have a completely failing connection (which would point towards one set of problems) or a connection that merely fails on retry (which points to a different set of problems). If you kill off pppd, wait a few seconds, and then start it again, will you get another successful session at the start? Is it only having trouble during a post-failure retry (i.e., during 'persist')? Based on the following messages, I can make at least one somewhat educated guess. Nov 7 15:15:13 79-vnf-180918 pppd[1161]: Remote message: Greetings!! Nov 7 15:15:13 79-vnf-180918 pppd[1161]: PAP authentication succeeded Nov 7 15:15:13 79-vnf-180918 pppd[1161]: Hangup (SIGHUP) Nov 7 15:15:13 79-vnf-180918 pppd[1161]: Modem hangup Nov 7 15:15:13 79-vnf-180918 pppd[1161]: Connection terminated. As I said in my previous message, GPRS is really quite horrible. One of the horrible aspects of it is that it deliberately *lies* to the peer during the PPP authentication phase. If you pass bad credentials (either via one of the PPP authentication protocols or via some 'hidden' channel, such as your subscriber ID / telephone number), a GPRS server will send back a fake "success" message. The actual authentication work in GPRS is (inexplicably) delayed until the PPP Network phase. This means that an authentication failure perversely manifests as IPCP negotiation failure. Instead of getting a good address to use, you get a garbage address that doesn't work, or no address at all, and the system just waits for you to hang up in frustration with no outward indication of the real problem. So, at a glance, and without the strength of seeing the actual pppd "debug" messages I originally requested, the summary informational messages above *may* tend to indicate that your user name or password are not valid, or that something about your local configuration isn't right with respect to credentials, or the account that you're using to connect to this GPRS server is itself not authorized, or that you're violating some policy rule that the GPRS provider has in place (e.g., maximum number of connected minutes per day or minimum time between successive connection attempts or some such rule). When I was PPPEXT chair, I argued with the GPRS people until I was blue in the face. It did no good, of course. I'm sorry you're one of the victims here. -- James Carlson 42.703N 71.076W
Re: [PATCH 4/9] pppd: include time.h before using time_t
On 10/04/19 10:29, Kurt Van Dijck wrote: > I don't know a system where (a) or (b) are valid. My point is that such > system could could exist, so I learned not to inspect the header files > looking for a type, but inspect man-pages or specifications when looking > for a type, and so time_t is defined in time.h. I didn't just go trolling a grepping for time_t. sys/time.h is pretty well-established in UNIX, and I think you're punting when you point to ANSI C alone as the authority here. As for documentation, how does SUSv2 seem? https://pubs.opengroup.org/onlinepubs/7908799/xsh/systime.h.html > Now that I know that that file is used as include for kernel code, I'd > rather include time.h in the userspace c-files. My point is that include/net/ isn't strictly userspace. If you feel the need, then go ahead and include in user level files. This just isn't one of those. If you must do this in ppp_def.h, then it needs to be guarded against *all* of the systems where including a top-level header file inside a kernel module is the wrong thing to do, not just "ifndef SOLARIS". Do you know which systems those are? I can tell you that Solaris/Illumos is at least one such system, but I can't tell you that it's *all* of them. I think this include is out of place here. -- James Carlson 42.703N 71.076W
Re: [PATCH] time.h: include header before using time_t
On 10/04/19 13:40, Kurt Van Dijck wrote: > I think you confirm 4x what I said, but I probably expressed myself > badly, so "show me code!", I created this patch. > It (1) works for me and (2) does not mix userspace headers in kernel > space anywhere. > Would this work for you? That seems ok, in as much as it compiles on Solaris. But I'm still a little confused about your apparent opposition to at the point where time_t is actually used. is part of the UNIX standards. It's documented to define time_t (among other things). It's on-point for a header file that may be used in kernel context. What's the concern? -- James Carlson 42.703N 71.076W
Re: [PATCH] time.h: include header before using time_t
On 10/04/19 14:33, Kurt Van Dijck wrote: > On vr, 04 okt 2019 13:52:11 -0400, James Carlson wrote: > headers under sys/ are, AFAIK, not delivered by the kernel, but by the > toolchain. sys/time.h may have less issues than time.h, it has the same > disease. I've never heard of this problem. I'm afraid I don't know what you're referring to. I've never heard of a compiler (or other tool chain component) that delivers files to /usr/include/sys. That'd be somewhat surprising to me, but I guess it's a wide world out there. As the name says, the stuff under sys/ is part of the _system_. On UNIX, the standard parts of it are described in the Single UNIX Standard, maintained by The Open Group. That's the documentation pointer I provided previously. Are there systems where system header files aren't installed by default? Sure. That's somewhat commonplace. But on such a machine you can't compile things (including pppd) until you install the (presumably optional) header files. If you look closely, you'll see that pppd/main.c already includes and it's not guarded by any conditional compilation because it's a *STANDARD HEADER FILE*. If there were problems of some sort with this include file, I'd expect they'd have surfaced by now. -- James Carlson 42.703N 71.076W
