I had my configuration working for a long time.. right after I upgraded coreutils/openrc it stop working with out any error at all.. basically everything works I even get and IP from verizon but ppp fails to create the ppp0 device... I use a custom script: #!/bin/sh # # start-bt-modem: Start "dial-up networking" via Bluetooth with a Treo 700p. # Paul Walmsley <paul@booyaka.com> 20071219 # # For this script to work, you must already have paired your computer and # the phone, and the computer should appear in the "trusted devices list" # on your Treo. # # You'll need to change the PHONE_BT_ADDR variable to match your phone's # Bluetooth address. To find this, set your Treo's Bluetooth visibility # to "Temporary" and run 'hcitool scan' on your Linux box. # PHONE_BT_ADDR=00:07:E0:82:D3:04 # hciconfig hci0 down hciconfig hci0 up /etc/init.d/bluetooth restart ############################# # # Items you are unlikely to need to change # # Bluetooth interface device name - run 'hciconfig' to find this BT_IF=hci0 # # Set this to 'nolog' if you want pppd to be quiet on startup. PPPD_QUIET='debug' # # Change this line if your RFCOMM devices show up in some nonstandard # directory. RFCOMM_DEVPATH=/dev # # Change this line if you are already using rfcomm7 RFCOMM_DEV=rfcomm7 # ############################## # hciconfig $BT_IF auth encrypt secure # # Find what channel the DUN service is hiding on today. This hops around # for some reason on the Treo. # CHANNEL=`sdptool search --bdaddr $PHONE_BT_ADDR DUN | egrep Channel | cut -d: -f2` if [ -z $CHANNEL ]; then echo Could not find dial-up networking service on $PHONE_BT_ADDR. exit 254 fi # # Bind a local RFCOMM device to that channel - releasing the existing # binding if it's already present. # if [ -c $RFCOMM_DEVPATH/$RFCOMM_DEV ]; then rfcomm -i $BT_IF release $RFCOMM_DEV fi rfcomm -i $BT_IF bind $RFCOMM_DEV $PHONE_BT_ADDR $CHANNEL # # Start the PPP connection. # pppd $RFCOMM_DEVPATH/$RFCOMM_DEV 921600 connect '/usr/sbin/chat -s -v "" "AT&F0E0V1S0=0" OK ATD#777 CONNECT' $PPPD_QUIET updetach crtscts noipdefault novj lcp-echo-failure 0 nobs dcomp novjccomp nopcomp noaccomp noauth user USERNAME modem usepeerdns defaultroute connect-delay 5000 Reproducible: Always Steps to Reproduce: 1.I run the script above 2.I get the dhcp info from verizon 3. nothing happens on my laptop. Actual Results: nothing at all Expected Results: connet to the Internet using my phone. EVDO. nobody was able to help me in the forums or lists.. since this is something people does not use everyday... so I need one of the developers related to this upgrade to check into this...
I don't use ppp, so am of zero help here.
(In reply to comment #1) > I don't use ppp, so am of zero help here. > yes, that is exactly the issue, not many people uses ppp to be able to help me out. is there a place were it mentions exacly what have changed? not only the upgrade howto that we have on the website.. maybe I can fix this myself if I have the proper information.
I don't see the connection between bluetooth init script and openrc. Anyway, do you have the pppd _debug_ log?
rek2-laptop ~ # ./start-bt-modem * Shutting down Bluetooth ... [ ok ] * Starting Bluetooth ... * Starting hcid ... [ ok ] * Starting rfcomm ... [ ok ] Created /dev/ppp device node send (AT&F0E0V1S0=0^M) expect (OK) ^M OK -- got it send (ATD#777^M) expect (CONNECT) ^M ^M CONNECT -- got it Serial connection established. using channel 1 Using interface ppp0 Connect: ppp0 <--> /dev/rfcomm7 sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x4c67130f>] rcvd [LCP ConfReq id=0x1f <mru 1500> <asyncmap 0x0> <magic 0xf060e383> <pcomp> <accomp>] sent [LCP ConfRej id=0x1f <pcomp> <accomp>] rcvd [LCP ConfNak id=0x1 <pcomp> <accomp>] sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4c67130f>] rcvd [LCP ConfReq id=0x20 <mru 1500> <asyncmap 0x0> <magic 0xf060e383>] sent [LCP ConfAck id=0x20 <mru 1500> <asyncmap 0x0> <magic 0xf060e383>] rcvd [LCP ConfNak id=0x2 <pcomp> <accomp>] sent [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0x4c67130f>] rcvd [LCP ConfNak id=0x3 <pcomp> <accomp>] sent [LCP ConfReq id=0x4 <asyncmap 0x0> <magic 0x4c67130f>] rcvd [LCP ConfNak id=0x4 <pcomp> <accomp>] sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x4c67130f>] rcvd [LCP ConfAck id=0x5 <asyncmap 0x0> <magic 0x4c67130f>] sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>] sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] rcvd [LCP DiscReq id=0x21 magic=0xf060e383] rcvd [IPCP ConfReq id=0x9 <addr 66.174.20.4>] sent [IPCP ConfAck id=0x9 <addr 66.174.20.4>] rcvd [LCP ProtRej id=0x22 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00] Protocol-Reject for 'Compression Control Protocol' (0x80fd) received rcvd [IPCP ConfNak id=0x1 <addr 70.198.71.219> <ms-dns1 66.174.95.44> <ms-dns3 66.174.92.14>] sent [IPCP ConfReq id=0x2 <addr 70.198.71.219> <ms-dns1 66.174.95.44> <ms-dns3 66.174.92.14>] rcvd [IPCP ConfAck id=0x2 <addr 70.198.71.219> <ms-dns1 66.174.95.44> <ms-dns3 66.174.92.14>] not replacing existing default route to wlan0 [192.168.1.1] local IP address 70.198.71.219 remote IP address 66.174.20.4 primary DNS address 66.174.95.44 secondary DNS address 66.174.92.14 ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
(In reply to comment #3) > I don't see the connection between bluetooth init script and openrc. Anyway, do > you have the pppd _debug_ log? > Here below in another post is it.. I don't really know straight forward the connection.. after some people in the forum started to report issues with the interfaces.. in my case everything works till I am supposed to get ppp0 up.
(In reply to comment #4) > not replacing existing default route to wlan0 [192.168.1.1] There you go... pppd will not replace a default route with the same metric as the "defaultmetric" parameter (man pppd). Either remove the default route from the wlan0 config or set its metric to something greater than the one set on ppp interface. Closed as INVALID.
no no no, that happen because I was at home using wifi at the time I run the script to copy and paste it here.. it does not work even with all my interfaces down.. any idea on that?
So it succeeds in setting your default route but still doesn't work? Does your /etc/resolv.conf have the right nameservers in it? Can you ping the default gateway?
(In reply to comment #8) > So it succeeds in setting your default route but still doesn't work? Does your > /etc/resolv.conf have the right nameservers in it? Can you ping the default > gateway? > Hello. no of course not.. like I say in the output I get all the right information.. is just the interface and routes are not getting in.. nothing.. nothing on /etc/resolv.conf, nothing on routes and no ppp0 up.. and everything was literaly working fine right before the update... I know because I use this for work and I am 24/7 on call and I use my tethering all the time.. It has to be somethign related to the way ppp brings up ppp0 and gentoo new net config..?
Then udev is probably to blame. Use udevmonitor to see what is happening behind the scenes.
here is the output of the dev monitor: I notes a pan0 ??? should for now on ppp0 be pan0? udevmonitor will print the received events for: UDEV the event which udev sends out after rule processing UEVENT the kernel uevent UEVENT[1208950646.363595] remove /devices/virtual/net/pan0 (net) UDEV [1208950646.365486] remove /devices/virtual/net/pan0 (net) UEVENT[1208950646.518547] add /devices/virtual/net/pan0 (net) UDEV [1208950646.520881] add /devices/virtual/net/pan0 (net) UEVENT[1208950646.603699] add /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304 (bluetooth) UDEV [1208950646.605328] add /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304 (bluetooth) UEVENT[1208950650.577091] remove /devices/virtual/tty/rfcomm7 (tty) UDEV [1208950650.578045] remove /devices/virtual/tty/rfcomm7 (tty) UEVENT[1208950650.578374] add /devices/virtual/tty/rfcomm7 (tty) UDEV [1208950650.579149] add /devices/virtual/tty/rfcomm7 (tty) UEVENT[1208950650.616059] move /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304/tty/rfcomm7 (tty) UDEV [1208950650.616729] move /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304/tty/rfcomm7 (tty) UEVENT[1208950660.002974] add /devices/virtual/net/ppp0 (net) UDEV [1208950660.005380] add /devices/virtual/net/ppp0 (net) UEVENT[1208950665.383720] remove /devices/virtual/net/ppp0 (net) UDEV [1208950665.385424] remove /devices/virtual/net/ppp0 (net) UEVENT[1208950665.445809] move /devices/virtual/tty/rfcomm7 (tty) UDEV [1208950665.446252] move /devices/virtual/tty/rfcomm7 (tty) UEVENT[1208950665.643273] remove /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304 (bluetooth) UDEV [1208950665.643965] remove /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304 (bluetooth)
(In reply to comment #11) > here is the output of the dev monitor: I notes a pan0 ??? should for now on > ppp0 be pan0? > > udevmonitor will print the received events for: > UDEV the event which udev sends out after rule processing > UEVENT the kernel uevent > > UEVENT[1208950646.363595] remove /devices/virtual/net/pan0 (net) > UDEV [1208950646.365486] remove /devices/virtual/net/pan0 (net) > UEVENT[1208950646.518547] add /devices/virtual/net/pan0 (net) > UDEV [1208950646.520881] add /devices/virtual/net/pan0 (net) > UEVENT[1208950646.603699] add > /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304 > (bluetooth) > UDEV [1208950646.605328] add > /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304 > (bluetooth) > UEVENT[1208950650.577091] remove /devices/virtual/tty/rfcomm7 (tty) > UDEV [1208950650.578045] remove /devices/virtual/tty/rfcomm7 (tty) > UEVENT[1208950650.578374] add /devices/virtual/tty/rfcomm7 (tty) > UDEV [1208950650.579149] add /devices/virtual/tty/rfcomm7 (tty) > UEVENT[1208950650.616059] move > /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304/tty/rfcomm7 > (tty) > UDEV [1208950650.616729] move > /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304/tty/rfcomm7 > (tty) > UEVENT[1208950660.002974] add /devices/virtual/net/ppp0 (net) > UDEV [1208950660.005380] add /devices/virtual/net/ppp0 (net) > UEVENT[1208950665.383720] remove /devices/virtual/net/ppp0 (net) > UDEV [1208950665.385424] remove /devices/virtual/net/ppp0 (net) > UEVENT[1208950665.445809] move /devices/virtual/tty/rfcomm7 (tty) > UDEV [1208950665.446252] move /devices/virtual/tty/rfcomm7 (tty) > UEVENT[1208950665.643273] remove > /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304 > (bluetooth) > UDEV [1208950665.643965] remove > /devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.1/7-1.1:1.0/hci0/acl0007E082D304 > (bluetooth) > hmm actually I just remember pan0 is the bluetooth device. so hope someone can see something wrong on this udev output..
Offtopic: your modem supports Bluetooth PAN profile. If I were you, I'd use that instead. When I just run pppd (no parameters, just run pppd), this is what I get from udev: UEVENT[1208980609.999112] add /module/slhc (module) UEVENT[1208980610.009479] add /module/ppp_generic (module) UEVENT[1208980610.009594] add /class/ppp/ppp (ppp) UDEV [1208980610.017557] add /module/slhc (module) UDEV [1208980610.017663] add /module/ppp_generic (module) UDEV [1208980610.018382] add /class/ppp/ppp (ppp) UEVENT[1208980610.055056] add /module/crc_ccitt (module) UDEV [1208980610.055352] add /module/crc_ccitt (module) UEVENT[1208980610.065721] add /module/ppp_async (module) UEVENT[1208980610.065929] add /class/net/ppp0 (net) UDEV [1208980610.067291] add /module/ppp_async (module) UDEV [1208980610.105459] add /class/net/ppp0 (net) I'm no udev specialist, but /devices/virtual/net/ppp0 looks strange to me.
I'm having issues as well, where pppd that is spun off /etc/conf.d/net's chat script is being parsed incorrectly: /var/log/messages: Apr 23 13:08:50 lapadon chat[7748]: abort on (BUSY) Apr 23 13:08:50 lapadon chat[7748]: abort on (ERROR) Apr 23 13:08:50 lapadon chat[7748]: abort on (NO ANSWER) Apr 23 13:08:50 lapadon chat[7748]: abort on (NO CARRIER) Apr 23 13:08:50 lapadon chat[7748]: abort on (NO DIALTONE) Apr 23 13:08:50 lapadon chat[7748]: abort on (Invalid Login) Apr 23 13:08:50 lapadon chat[7748]: abort on (Login Incorrect) Apr 23 13:08:50 lapadon chat[7748]: timeout set to 5 seconds Apr 23 13:08:50 lapadon chat[7748]: send (ATZ^M) Apr 23 13:08:50 lapadon chat[7748]: expect (OK) Apr 23 13:08:50 lapadon chat[7748]: ATZ^M^M Apr 23 13:08:50 lapadon chat[7748]: OK Apr 23 13:08:50 lapadon chat[7748]: -- got it Apr 23 13:08:50 lapadon chat[7748]: send (AT+CGDCONT=1,IP,wap.cingular,,0,0^M) Apr 23 13:08:50 lapadon chat[7748]: expect (OK) Apr 23 13:08:50 lapadon chat[7748]: ^M Apr 23 13:08:50 lapadon chat[7748]: AT+CGDCONT=1,IP,wap.cingular,,0,0^M^M Apr 23 13:08:50 lapadon chat[7748]: ERROR Apr 23 13:08:50 lapadon chat[7748]: -- failed Apr 23 13:08:50 lapadon chat[7748]: Failed (ERROR) /etc/conf.d/net chat_ppp0=" ABORT BUSY ABORT ERROR ABORT 'NO ANSWER' ABORT 'NO CARRIER' ABORT 'NO DIALTONE' ABORT 'Invalid Login' ABORT 'Login Incorrect' TIMEOUT 5 '' ATZ OK 'AT+CGDCONT=1,"IP","wap.cingular","",0,0' OK 'ATDT\T' TIMEOUT 60 CONNECT '' TIMEOUT 5 ~-- '' "
(In reply to comment #14) > I'm having issues as well, where pppd that is spun off /etc/conf.d/net's chat > script is being parsed incorrectly: > > /var/log/messages: > > Apr 23 13:08:50 lapadon chat[7748]: abort on (BUSY) > Apr 23 13:08:50 lapadon chat[7748]: abort on (ERROR) > Apr 23 13:08:50 lapadon chat[7748]: abort on (NO ANSWER) > Apr 23 13:08:50 lapadon chat[7748]: abort on (NO CARRIER) > Apr 23 13:08:50 lapadon chat[7748]: abort on (NO DIALTONE) > Apr 23 13:08:50 lapadon chat[7748]: abort on (Invalid Login) > Apr 23 13:08:50 lapadon chat[7748]: abort on (Login Incorrect) > Apr 23 13:08:50 lapadon chat[7748]: timeout set to 5 seconds > Apr 23 13:08:50 lapadon chat[7748]: send (ATZ^M) > Apr 23 13:08:50 lapadon chat[7748]: expect (OK) > Apr 23 13:08:50 lapadon chat[7748]: ATZ^M^M > Apr 23 13:08:50 lapadon chat[7748]: OK > Apr 23 13:08:50 lapadon chat[7748]: -- got it > Apr 23 13:08:50 lapadon chat[7748]: send (AT+CGDCONT=1,IP,wap.cingular,,0,0^M) > Apr 23 13:08:50 lapadon chat[7748]: expect (OK) > Apr 23 13:08:50 lapadon chat[7748]: ^M > Apr 23 13:08:50 lapadon chat[7748]: AT+CGDCONT=1,IP,wap.cingular,,0,0^M^M > Apr 23 13:08:50 lapadon chat[7748]: ERROR > Apr 23 13:08:50 lapadon chat[7748]: -- failed > Apr 23 13:08:50 lapadon chat[7748]: Failed (ERROR) > > /etc/conf.d/net > > chat_ppp0=" > ABORT BUSY > ABORT ERROR > ABORT 'NO ANSWER' > ABORT 'NO CARRIER' > ABORT 'NO DIALTONE' > ABORT 'Invalid Login' > ABORT 'Login Incorrect' > TIMEOUT 5 > '' ATZ > OK 'AT+CGDCONT=1,"IP","wap.cingular","",0,0' > OK 'ATDT\T' > TIMEOUT 60 > CONNECT '' > TIMEOUT 5 > ~-- '' > " > Don't use double quotes (") inside chat_ppp0. I've found that it doesn't parse correctly even if it starts with a comment # and then double quotes inside the comment in any parameter. The documentation is pretty screwed up now. Seems like you can't have comments or double quotes inside commands in /etc/conf.d/net but I the documentation doesn't reflect this.
(In reply to comment #15) > (In reply to comment #14) > > I'm having issues as well, where pppd that is spun off /etc/conf.d/net's chat > > script is being parsed incorrectly: > > > > /var/log/messages: > > > > Apr 23 13:08:50 lapadon chat[7748]: abort on (BUSY) > > Apr 23 13:08:50 lapadon chat[7748]: abort on (ERROR) > > Apr 23 13:08:50 lapadon chat[7748]: abort on (NO ANSWER) > > Apr 23 13:08:50 lapadon chat[7748]: abort on (NO CARRIER) > > Apr 23 13:08:50 lapadon chat[7748]: abort on (NO DIALTONE) > > Apr 23 13:08:50 lapadon chat[7748]: abort on (Invalid Login) > > Apr 23 13:08:50 lapadon chat[7748]: abort on (Login Incorrect) > > Apr 23 13:08:50 lapadon chat[7748]: timeout set to 5 seconds > > Apr 23 13:08:50 lapadon chat[7748]: send (ATZ^M) > > Apr 23 13:08:50 lapadon chat[7748]: expect (OK) > > Apr 23 13:08:50 lapadon chat[7748]: ATZ^M^M > > Apr 23 13:08:50 lapadon chat[7748]: OK > > Apr 23 13:08:50 lapadon chat[7748]: -- got it > > Apr 23 13:08:50 lapadon chat[7748]: send (AT+CGDCONT=1,IP,wap.cingular,,0,0^M) > > Apr 23 13:08:50 lapadon chat[7748]: expect (OK) > > Apr 23 13:08:50 lapadon chat[7748]: ^M > > Apr 23 13:08:50 lapadon chat[7748]: AT+CGDCONT=1,IP,wap.cingular,,0,0^M^M > > Apr 23 13:08:50 lapadon chat[7748]: ERROR > > Apr 23 13:08:50 lapadon chat[7748]: -- failed > > Apr 23 13:08:50 lapadon chat[7748]: Failed (ERROR) > > > > /etc/conf.d/net > > > > chat_ppp0=" > > ABORT BUSY > > ABORT ERROR > > ABORT 'NO ANSWER' > > ABORT 'NO CARRIER' > > ABORT 'NO DIALTONE' > > ABORT 'Invalid Login' > > ABORT 'Login Incorrect' > > TIMEOUT 5 > > '' ATZ > > OK 'AT+CGDCONT=1,"IP","wap.cingular","",0,0' > > OK 'ATDT\T' > > TIMEOUT 60 > > CONNECT '' > > TIMEOUT 5 > > ~-- '' > > " > > > > Don't use double quotes (") inside chat_ppp0. I've found that it doesn't parse > correctly even if it starts with a comment # and then double quotes inside the > comment in any parameter. The documentation is pretty screwed up now. Seems > like you can't have comments or double quotes inside commands in > /etc/conf.d/net but I the documentation doesn't reflect this. > So I think it's fair to say that openRC is more or less not compatible with ppp connections in /etc/conf.d/net since most require the use of an APN.
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > I'm having issues as well, where pppd that is spun off /etc/conf.d/net's chat > > > script is being parsed incorrectly: > > > > > > /var/log/messages: > > > > > > Apr 23 13:08:50 lapadon chat[7748]: abort on (BUSY) > > > Apr 23 13:08:50 lapadon chat[7748]: abort on (ERROR) > > > Apr 23 13:08:50 lapadon chat[7748]: abort on (NO ANSWER) > > > Apr 23 13:08:50 lapadon chat[7748]: abort on (NO CARRIER) > > > Apr 23 13:08:50 lapadon chat[7748]: abort on (NO DIALTONE) > > > Apr 23 13:08:50 lapadon chat[7748]: abort on (Invalid Login) > > > Apr 23 13:08:50 lapadon chat[7748]: abort on (Login Incorrect) > > > Apr 23 13:08:50 lapadon chat[7748]: timeout set to 5 seconds > > > Apr 23 13:08:50 lapadon chat[7748]: send (ATZ^M) > > > Apr 23 13:08:50 lapadon chat[7748]: expect (OK) > > > Apr 23 13:08:50 lapadon chat[7748]: ATZ^M^M > > > Apr 23 13:08:50 lapadon chat[7748]: OK > > > Apr 23 13:08:50 lapadon chat[7748]: -- got it > > > Apr 23 13:08:50 lapadon chat[7748]: send (AT+CGDCONT=1,IP,wap.cingular,,0,0^M) > > > Apr 23 13:08:50 lapadon chat[7748]: expect (OK) > > > Apr 23 13:08:50 lapadon chat[7748]: ^M > > > Apr 23 13:08:50 lapadon chat[7748]: AT+CGDCONT=1,IP,wap.cingular,,0,0^M^M > > > Apr 23 13:08:50 lapadon chat[7748]: ERROR > > > Apr 23 13:08:50 lapadon chat[7748]: -- failed > > > Apr 23 13:08:50 lapadon chat[7748]: Failed (ERROR) > > > > > > /etc/conf.d/net > > > > > > chat_ppp0=" > > > ABORT BUSY > > > ABORT ERROR > > > ABORT 'NO ANSWER' > > > ABORT 'NO CARRIER' > > > ABORT 'NO DIALTONE' > > > ABORT 'Invalid Login' > > > ABORT 'Login Incorrect' > > > TIMEOUT 5 > > > '' ATZ > > > OK 'AT+CGDCONT=1,"IP","wap.cingular","",0,0' > > > OK 'ATDT\T' > > > TIMEOUT 60 > > > CONNECT '' > > > TIMEOUT 5 > > > ~-- '' > > > " > > > > > > > Don't use double quotes (") inside chat_ppp0. I've found that it doesn't parse > > correctly even if it starts with a comment # and then double quotes inside the > > comment in any parameter. The documentation is pretty screwed up now. Seems > > like you can't have comments or double quotes inside commands in > > /etc/conf.d/net but I the documentation doesn't reflect this. > > > > So I think it's fair to say that openRC is more or less not compatible with ppp > connections in /etc/conf.d/net since most require the use of an APN. > Did you try escaping double quotes with backslashes to see if that might work in chat_ppp0? " -> \" Did you also try leaving them out to see if that works as well?
> > > > So I think it's fair to say that openRC is more or less not compatible with ppp > connections in /etc/conf.d/net since most require the use of an APN. > what about my case? I am running a script. :-(
I have a similar problem, I'm using a dsl with pppoe over the eth0 interface, it just does not connect anymore. The modem is hanging off after the authentication. Updetach helps but the init-script says the interface is not under control. The thing, which seems different between the two is that under the original baselayot ppd-start script the authentication information seemed to be sent 2 times in 3 seconds interval, here the script dies almost immediatly. I don't see great difference between the two scripts, maybe it is a timing problem?
I have PPPoE running with openrc/pppd. You have to remove the "password_ppp0" option from /etc/conf.d/net. Instead, put "<username> * <password>" in /etc/ppp/(chap|pap)_secrets. Working config: rc_need_ppp0="net.eth1" config_ppp0=( "ppp" ) mtu_ppp0="1492" mru_ppp0="1492" link_ppp0="eth1" plugins_ppp0=( "rp-pppoe" ) pppd_ppp0="ktune defaultroute lcp-echo-interval 5 lcp-echo-failure 3 idle 100000" username_ppp0="<username>"
hmpf. remove the brackets (). I c&p the wron part... ;-= rc_need_ppp0="net.eth1" config_ppp0="ppp" mtu_ppp0="1492" mru_ppp0="1492" link_ppp0="eth1" plugins_ppp0="rp-pppoe" pppd_ppp0="ktune defaultroute lcp-echo-interval 5 lcp-echo-failure 3 idle 100000" username_ppp0="<username>"
(In reply to comment #21) > hmpf. remove the brackets (). I c&p the wron part... ;-= > > rc_need_ppp0="net.eth1" > config_ppp0="ppp" > mtu_ppp0="1492" > mru_ppp0="1492" > link_ppp0="eth1" > plugins_ppp0="rp-pppoe" > pppd_ppp0="ktune defaultroute lcp-echo-interval 5 lcp-echo-failure 3 idle > 100000" > username_ppp0="<username>" > Is the ppp interface only working for pppoe and not ppp dial up? If it is working for ppp dial-up, what needs to be changed or set in the config to get it to work in baselayout-2? My password has always been set in /etc/ppp/pap|chap-secrets as well.
(In reply to comment #22) > (In reply to comment #21) > > hmpf. remove the brackets (). I c&p the wron part... ;-= > > > > rc_need_ppp0="net.eth1" > > config_ppp0="ppp" > > mtu_ppp0="1492" > > mru_ppp0="1492" > > link_ppp0="eth1" > > plugins_ppp0="rp-pppoe" > > pppd_ppp0="ktune defaultroute lcp-echo-interval 5 lcp-echo-failure 3 idle > > 100000" > > username_ppp0="<username>" > > > > > Is the ppp interface only working for pppoe and not ppp dial up? If it is > working for ppp dial-up, what needs to be changed or set in the config to get > it to work in baselayout-2? My password has always been set in > /etc/ppp/pap|chap-secrets as well. > no I am using dial up from a script(is above) and stop working after the upgrade.. so I am not even touching /etc/conf.d/net and not working.. I need my laptop and this since I am on call 24/7 out of the office if I get a urgent matter and I can't tether with my phone to fix things I will be screw.. if I can't get this working today, I will have not option (and it will hurt) to remove gentoo and install another distro with out openRC and report on the verizon forums that if you thether with the phone don't use Gentoo in the mean time since is broken so others dont have the same pain I have. I hope someone that understands PPP comes and check, as well as a openRC expert and maybe between the both of them they can figure out what changed in the upgrade to openRC
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #21) > > > hmpf. remove the brackets (). I c&p the wron part... ;-= > > > > > > rc_need_ppp0="net.eth1" > > > config_ppp0="ppp" > > > mtu_ppp0="1492" > > > mru_ppp0="1492" > > > link_ppp0="eth1" > > > plugins_ppp0="rp-pppoe" > > > pppd_ppp0="ktune defaultroute lcp-echo-interval 5 lcp-echo-failure 3 idle > > > 100000" > > > username_ppp0="<username>" > > > > > > > > > Is the ppp interface only working for pppoe and not ppp dial up? If it is > > working for ppp dial-up, what needs to be changed or set in the config to get > > it to work in baselayout-2? My password has always been set in > > /etc/ppp/pap|chap-secrets as well. > > > > no I am using dial up from a script(is above) and stop working after the > upgrade.. so I am not even touching /etc/conf.d/net and not working.. > I need my laptop and this since I am on call 24/7 out of the office if I get a > urgent matter and I can't tether with my phone to fix things I will be screw.. > if I can't get this working today, I will have not option (and it will hurt) to > remove gentoo and install another distro with out openRC and report on the > verizon forums that if you thether with the phone don't use Gentoo in the mean > time since is broken so others dont have the same pain I have. > I hope someone that understands PPP comes and check, as well as a openRC expert > and maybe between the both of them they can figure out what changed in the > upgrade to openRC > I'm frustrated as well but you can't blame the entire gentoo distro just because you decided to use a package that is still in test (~arch openrc & baselayout-2). I have a workaround in the mean time if you do not use kernel 2.6.25. You should install kppp and dial up through that program. Dial-up still works using that program on kernels < 2.6.25.
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #21) > > > hmpf. remove the brackets (). I c&p the wron part... ;-= > > > > > > rc_need_ppp0="net.eth1" > > > config_ppp0="ppp" > > > mtu_ppp0="1492" > > > mru_ppp0="1492" > > > link_ppp0="eth1" > > > plugins_ppp0="rp-pppoe" > > > pppd_ppp0="ktune defaultroute lcp-echo-interval 5 lcp-echo-failure 3 idle > > > 100000" > > > username_ppp0="<username>" > > > > > > > > > Is the ppp interface only working for pppoe and not ppp dial up? If it is > > working for ppp dial-up, what needs to be changed or set in the config to get > > it to work in baselayout-2? My password has always been set in > > /etc/ppp/pap|chap-secrets as well. > > > > no I am using dial up from a script(is above) and stop working after the > upgrade.. so I am not even touching /etc/conf.d/net and not working.. > I need my laptop and this since I am on call 24/7 out of the office if I get a > urgent matter and I can't tether with my phone to fix things I will be screw.. > if I can't get this working today, I will have not option (and it will hurt) to > remove gentoo and install another distro with out openRC and report on the > verizon forums that if you thether with the phone don't use Gentoo in the mean > time since is broken so others dont have the same pain I have. > I hope someone that understands PPP comes and check, as well as a openRC expert > and maybe between the both of them they can figure out what changed in the > upgrade to openRC > you could always downgrade too... it wont be that hard...
What does netplug and openRC have in common? I notes that this was recently installed as well I think at the same time and the man page says: #!/bin/sh # Copyright 1999-2004 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # # Gentoo-specific netplug script # # This file gets called by netplug when it wants to bring an interface # up or down. # will this affect my script trying to bring up ppp0? I notes that in the netplug.cfg it only lists eth* I try adding ppp* but no luck..
> > you could always downgrade too... it wont be that hard... > I though about that of course but since this is a minor issue since is only happening to a couple people if that, it will take a long time before getting considered serious and in the mean time I will not be able to upgrade my gentoo laptop thing that I like to do all the time.. and if I do since everything is going to be build around/for openrc I may end up breaking even more things..
I just find out that I am at least getting the domains writen to resolv.conf the issue is that instead of writing them on /etc/resol.conf is writing it inside /etc/ppp #$#@$# so /etc/ppp/resolv.conf why is this? is ppp running in something similar top chroot? in any case my interface does never come up.. I try to query the interface right when ppp says is working on it, and no luck the system does not even know what it is. ifconfig ppp0 ppp0: error fetching interface information: Device not found I run that while Serial connection established. using channel 4 Using interface ppp0 Connect: ppp0 <--> /dev/rfcomm7
(In reply to comment #20) > I have PPPoE running with openrc/pppd. You have to remove the "password_ppp0" > option from /etc/conf.d/net. Instead, put "<username> * <password>" in > /etc/ppp/(chap|pap)_secrets. thanks, this worked for me.
(In reply to comment #28) > I just find out that I am at least getting the domains writen to resolv.conf > the issue is that instead of writing them on /etc/resol.conf is writing it > inside /etc/ppp #$#@$# > so /etc/ppp/resolv.conf > why is this? is ppp running in something similar top chroot? in any case my > interface does never come up.. I try to query the interface right when ppp says > is working on it, and no luck the system does not even know what it is. > > ifconfig ppp0 > ppp0: error fetching interface information: Device not found > > I run that while > Serial connection established. > using channel 4 > Using interface ppp0 > Connect: ppp0 <--> /dev/rfcomm7 > I booted the live cd of the new Kubuntu HardyHaron and works perfect... so is for sure openrc screwing us.
> I booted the live cd of the new Kubuntu HardyHaron and > works perfect... so is for sure openrc screwing us. I can't believe there is not ppp expert or specially openrc expert.. I am guessing that if a distro decides to move radically to a new system for booting someone will be an expert on it.. I never had issues with Gentoo but this last year they are arriving like crazy, very bad decision are been taken, not sure what is going on back there, but I wish the original developers that made gentoo a success the first years were back, I can talk about all my user group here in Boston feels the same way, I guess we are only sticking with gentoo for what it was not for what it is.. can someone at least make a downgrade howto and put it on the main site for the people who does not whant to use openrc into is not buggy. thanks. and sorry for my fustration.
I have a Novatel U720 broadband wireless card on Sprint that was working fine until I upgraded to baselayout-2 and openrc. After an entire evening of hacking I finally solved my problem in two ways. First, I found that /lib/rc/net/pppd.sh used a function called _get_array() which is in /etc/init.d/net.lo. This bit of ugliness was Roy's attempt to placate those who wanted to support bash arrays (many threads around on this one). This was the source of all my problems. The problem is that _get_array() is not happy with absolutely anything but a very simple list. Over several tries I found out that comments (#) were bad as was any attempt to escape double quotes (ie. both " and \" didn't work. And to make things more difficult the _get_array() function is used in pppd_pppX and chat_pppX. (Note, I say pppX but this would be ppp0, or ppp1, etc... in reality.) SOLUTION 1: I was about to give up when I realized that the pppd.sh script would call an options.pppX in /etc/ppp. This is the same type of file you'd drop in /etc/ppp/peers and allows you to use connect scripts like you would if configuring by hand (or wvdial, etc...). To get this to work: 1. Comment out or remove all of pppd_pppX in /etc/conf.d/net 2. Comment out or remove all of chat_pppX in /etc/conf.d/net 3. Make sure you have link_pppX="/dev/XYZ" in /etc/conf.d/net. This should be your device (mine is /dev/ttyUSB0). 4. Create /etc/ppp/options.pppX. Mine is snip'd below. this shouldn't have the device in it. Also you need to create your connect and disconnect scripts. Mine are /etc/ppp/peers/sprint-connect and sprint-disconnect and those contain all the ATDT connect chat strings. ---SNIP--- 921600 # faster than this has no effect, and actually can be detrimental defaultroute # use cellular network for default route usepeerdns # use the DNS servers from the remote network #nodetach # keep pppd in the foreground #debug crtscts # hardware flow control lock # lock the serial port noauth # don't expect the modem to authenticate itself local # don't use Carrier Detect or Data Terminal Ready persist # Redial if connection lost user ppp holdoff 5 # Reconnect after 5s on connection loss lcp-echo-failure 4 # prevent timeouts lcp-echo-interval 65535 # prevent timeouts connect "/usr/sbin/chat -v -f /etc/ppp/peers/sprint-connect" disconnect "/usr/sbin/chat -v -f /etc/ppp/peers/sprint-disconnect" ---SNIP--- SOLUTION 2: After getting solution 1 working I began to feel a bit more sane and tried to do things the Gentoo way in /etc/conf.d/net. Nothing actually wrong with the previous method, but... Below find a snip of the final /etc/conf.d/net that worked. (Don't forget to rename options.pppX from solution 1 to something else). ---SNIP--- pppd_ppp0=" 921600 defaultroute usepeerdns crtscts lock noauth local persist holdoff 5 lcp-echo-failure 4 lcp-echo-interval 65535 " chat_ppp0=" TIMEOUT 10 ABORT 'BUSY' ABORT 'NO ANSWER' ABORT 'ERROR' '' ATZ OK 'ATE0V1' OK 'AT+CSQ' OK 'ATDT#777' CONNECT '' " ---SNIP--- The keys to the above are: 1. Absolutely no comments (#) in pppd_pppX or chat_pppX. No comments in separate lines. No comments after the value. 2. Tabs and spaces at the beginning of values seem to make _NO_ difference in pppd_pppX. Tabs and spaces _DO_ seem to make a difference in chat_pppX. From an above post I have no idea how to put the line: OK 'AT+CGDCONT=1,"IP","wap.cingular","",0,0' into the "new" format. Hope this helps someone. I'll try to take a closer look at _get_array(). Something's fishy.
I decided to take some advice from Sean Lynn and I messed with my config some more. I had removed all the comments inside pppd_ppp0 but did not remove the comment inside chat_ppp0. After I removed that, voila! It started working again. Someone (Roy Marples?) really needs to update the documentation for net.example. Here's my config: config_ppp0="ppp" link_ppp0="/dev/ttyS2" username_ppp0="foo@bar.com" pppd_ppp0=" 921600 defaultroute crtscts demand idle 60 lock lcp-echo-failure 4 lcp-echo-interval 65535 " chat_ppp0=" ABORT BUSY ABORT ERROR ABORT 'NO ANSWER' ABORT 'NO CARRIER' ABORT 'NO DIALTONE' ABORT 'Invalid Login' ABORT 'Login incorrect' TIMEOUT 5 '' ATZ OK AT OK 'ATDT\T' TIMEOUT 60 CONNECT '' TIMEOUT 5 ~-- '' " Also in /etc/ppp/chap|pap-secrets, the format remains the same before openrc. I specify as the file states: username server password
Double escaping of " is needed: OK 'AT+CGDCONT=1,\\\"IP\\\",\\\"wap.cingular\\\",\\\"\\\",0,0' It is working for me.
I've been getting authentication failures with my PPTP connection since upgrading. It seems the password isn't getting fed through properly. If I don't set a password with password_ppp0 and specify it in pppd_ppp0 instead with "password foobar" then it works.
(In reply to comment #30) > (In reply to comment #28) > > I just find out that I am at least getting the domains writen to resolv.conf > > the issue is that instead of writing them on /etc/resol.conf is writing it > > inside /etc/ppp #$#@$# > > so /etc/ppp/resolv.conf > > why is this? is ppp running in something similar top chroot? in any case my > > interface does never come up.. I try to query the interface right when ppp says > > is working on it, and no luck the system does not even know what it is. > > > > ifconfig ppp0 > > ppp0: error fetching interface information: Device not found > > > > I run that while > > Serial connection established. > > using channel 4 > > Using interface ppp0 > > Connect: ppp0 <--> /dev/rfcomm7 > > > > > I booted the live cd of the new Kubuntu HardyHaron and > works perfect... so is for sure openrc screwing us. > This seems to be unrelated to the option passing problem also discussed on this bug. When the ppp interface comes (when not backgrounded, ie using 'updetach') up the net.* script segfaults when calling _exists on line 481. If that line is commented out the script completes but somewhere destroys the ppp interface. All very strange. I'll keep digging. I'm considering adding a bluetooth (DUN) 'plugin' so a bdaddr is passed in link_ppp* and a dynamic rfcomm link created like in the OP script. Thoughts? I'm also looking into implenting DUN in the gnome bluetooth manager and getting ppp support into the NetworkManager Gentoo backend.
Created attachment 158345 [details, diff] Fake bluetooth plugin support This patch handles the passing of a fake bluetooth plugin in plugins_ppp*. link_ppp* is the bluetooth address for the device. Additonally, hci_ppp* and rfcomm_ppp* can be used to specify hci and rfcomm devices respecively. If they are unset, then hci0 is used by default and rfcomm<N + 7; where N is derived from the interface pppN>.
Hi, well a couple months have pass after I submited this bug, it was very critical for my work so I ended up with Debian on my laptop since I need this feature *a lot*. I am wondering how is the status of this? I see a path, have the patch hit the tree? will my script(the one I posted here below, first post) will work now how it did before and it does not on debian? let me know please, if it will work I can finally come back to gentoo in my laptop. thanks.
Hi! I also have this bug (pppd working for years, then some update broke it, now it all seems to work like before, but no connections is actually made, I always get "Temporary failure in domains name resolution".) Has there been a solution to this problem?
Created attachment 173915 [details, diff] Fake bluetooth plugin support I failed to declare the bluetooth variable as local in the first patch which caused it to fail in the non-bluetooth case. I guess nobody tried it! :( This is a fixed and fully tested version.
Roy, do you have any feedback for us?
Critical & Blocker are for boot failures.
(In reply to comment #41) > Roy, do you have any feedback for us? Only that ppp is one of the few modules I can't directly support as I've never gotten a PPPoE client to work on my Gentoo box, using the net module or not. At this point I'm tempted just to kick the ppp module out of OpenRC as 1) it's broken 2) I don't know why it's broken 3) No-one has stepped up to fix it 4) I don't use PPP myself, so no inclination to fix it. Yes, I'm sure someone can point me to a PPP guide somewhere, but I can just as easily point the same person to a shell scripting guide. After re-reading the comments here it sounds like PPP may actually be working and the issue lies elsewhere.
The password problem I was having has gone now. I don't know if this has had any affect on the rest of this. I have also successfully used this stuff to connect using GPRS via Bluetooth since then. Having said that, I could only get it to work on one of my two machines. This is the config I used if it's any use to anyone else. # ppp0 ########################### link_ppp0="/dev/ttyACM0" phone_number_ppp0="*99#" pppd_ppp0=" defaultroute usepeerdns " chat_ppp0=" ABORT BUSY ABORT ERROR ABORT 'NO ANSWER' ABORT 'NO CARRIER' ABORT 'NO DIALTONE' ABORT 'Invalid Login' ABORT 'Login incorrect' TIMEOUT 5 '' ATZ OK AT\\\\s+CGDCONT\\\\s=1,'IP','orangeinternet' OK 'ATDT\T' TIMEOUT 60 CONNECT '' TIMEOUT 5 ~-- '' " ################################## preup() { if [[ "${IFACE}" == "ppp0" ]]; then rfcomm bind rfcomm0 00:12:D2:E0:9D:E7 fi } postdown() { if [[ "${IFACE}" == "ppp0" ]]; then rfcomm release rfcomm0 fi } Roy, please don't dump the pppd stuff, I use it daily and it works fine for me.
roy: Not tethering, but here's my functioning PPPoE config bits: 1. In /etc/ppp/chap-secrets AND /etc/ppp/pap-secrets: "username@domain * password" 2. config_eth0='null' # (or any addresses to talk directly to the Modem) link_ppp0="eth0" plugins_ppp0="pppoe" # Required plugin for PPPoE username_ppp0='username@domain' rc_need_ppp0="net.eth0" config_ppp0='ppp' mtu_ppp0=1480 mru_ppp0=1480 dns_servers_ppp0="XX.XX.XX.XX" pppd_ppp0=" noktune noaccomp nobsdcomp noccp nodeflate nopcomp nopredictor1 novj novjccomp ipcp-accept-local ipcp-accept-remote noipdefault noauth updetach defaultroute lcp-echo-interval 5 lcp-echo-failure 3 idle 100000 debug"
My 2 cents: I guess setting chat_pppX without having bash array support is error prone, especially when you want to send strings like 'AT+CGDCONT=1,"IP","wap.cingular","",0,0'. In the baselayout-1 version it was a lot easier, but now probably it would be better to use chat scripts for that.
I found it works okay as long as you remember to use single quotes instead of double and escape spaces with \\\\s. Not obvious but not too difficult either.
(In reply to comment #47) > I found it works okay as long as you remember to use single quotes instead of > double and escape spaces with \\\\s. Not obvious but not too difficult either. > I don't think it's all that hard. You just have to remember to escape double quotes. It just needs to be documented. chat_ppp1=" ABORT 'NO DIALTONE' ABORT 'NO ANSWER' ABORT 'NO CARRIER' ABORT DELAYED '' AT OK ATZ OK 'AT+CGDCONT=2,\\\"IP\\\",\\\"ISP.CINGULAR\\\"' OK ATD*99# CONNECT '' "
I have openrc-0.4.3-r1 and found, that chat script rules in /etc/conf.d/net is non-obvious! After some investigation i can run my ppp connection via openrc (wvdial works out-of-box): Look at my cfg carefully: chat_ppp0=( 'ABORT' 'BUSY' 'ABORT' 'ERROR' 'ABORT' '"NO ANSWER"' 'ABORT' '"NO CARRIER"' 'ABORT' '"NO DIALTONE"' 'ABORT' '"Invalid Login"' 'ABORT' '"Login incorrect"' 'TIMEOUT' '5' '""' 'ATZ' 'OK' '"ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0"' 'OK' '"AT+CGDCONT=1,IP,internet.mts.ru"' 'OK' '"ATDT\T"' 'TIMEOUT' '60' 'CONNECT' '""' 'TIMEOUT' '5' ) At first, you MUST doublequote any string with spaces: 'ABORT' '"NO DIALTONE"' At second, if don't expect answer from command or don't provide second argument, doublequote empty string: '""' 'ATZ' 'CONNECT' '""' At third, my connection string 'OK' '"AT+CGDCONT=1,IP,internet.mts.ru"' work well without doublequoting IP and APN Without the 1st and the 2nd rule generated chat script will not work. I'll be glad, if this info can help anybody. I'll be glad, if mainteners will fix net.example
> Without the 1st and the 2nd rule generated chat script will not work The secret is simple. rc pppd script makes chat script from content of chat_ppp0 as command line argument sequence. So, shell interprets all whitespace sequences as argument delimeter and somnthig like 'ABORT' 'NO ANSWER' 'ABORT' 'BUSY' will become on chat language ABORT NO ANSWER ABORT BUSY
You don't HAVE to quote them. You can escape the spaces with \\\\s instead, which I find less confusing. This isn't entirely OpenRC's fault though. It merely calls "chat" and that is the source of half the confusion. See the chat man page.
Sorry, i miss you old comment about escaping whitespaces. Quoting vs escaping arguments for shell depends on nature of arguments. On my taste "NO ANSWER" is more readable, than NO\\\sANSWER Sure, in long time terms escaping is true way. But i can't agree with you about OpenRC's nonguilty. chat_ppp0 =(...) is NOT chat script, this is instruction for rc script and this instruction consits of one or more "expect-send" pairs of strings. Exactly /lib/rc/net/pppd.sh MUST escape this pairs properly. Anyway, comments in net.example or pppd.sh must be fixed.
Huh, 50 comments. Last activity almost a year ago. Multiple comments say that documentation should be fixed but there are no patches? Should this bug be closed now?
This was closed due to lack of information. If it is still an issue with latest openrc, please feel free to re-open.
