Difficulties connecting to DUN using PPP plugin

Bug #770259 reported by Colin Leroy-Mira on 2011-04-25
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Blueman
New
Undecided
Unassigned

Bug Description

Hi,

I've had difficulties setting up Blueman to connect via DUN with PPP. The first problem was that pppd died instantly:
Apr 25 13:00:39 marv blueman-mechanism: Starting blueman-mechanism
Apr 25 13:00:39 marv blueman-mechanism: --> ATZ
Apr 25 13:00:39 marv blueman-mechanism: <-- ['ATZ', 'OK']
Apr 25 13:00:39 marv blueman-mechanism: --> ATE0
Apr 25 13:00:39 marv blueman-mechanism: <-- ['ATE0', 'OK']
Apr 25 13:00:39 marv blueman-mechanism: --> AT+GCAP
Apr 25 13:00:39 marv blueman-mechanism: <-- ['+GCAP: +CGSM,+DS,+W', 'OK']
Apr 25 13:00:39 marv blueman-mechanism: --> AT+CGDCONT=1, "IP","internetdebitel"
Apr 25 13:00:39 marv blueman-mechanism: <-- ['OK']
Apr 25 13:00:39 marv blueman-mechanism: --> ATD*99#
Apr 25 13:00:41 marv blueman-mechanism: <-- ['CONNECT', '~\xff}#\xc0!}!} } }2}#}$\xc0#}!}$}%\xdc}"}&} }*} } g}%~']
Apr 25 13:00:41 marv blueman-mechanism: Starting pppd
Apr 25 13:00:41 marv pppd[2908]: pppd 2.4.5 started by root, uid 0
Apr 25 13:00:41 marv pppd[2908]: Using interface ppp0
Apr 25 13:00:41 marv pppd[2908]: Connect: ppp0 <--> /dev/rfcomm0
Apr 25 13:00:41 marv blueman-mechanism: Using interface ppp0
Apr 25 13:00:41 marv pppd[2908]: PAP authentication succeeded
Apr 25 13:00:41 marv blueman-mechanism: Connect: ppp0 <--> /dev/rfcomm0
Apr 25 13:00:41 marv blueman-mechanism: PAP authentication succeeded
Apr 25 13:00:41 marv pppd[2908]: not replacing existing default route via 192.168.1.4
Apr 25 13:00:41 marv pppd[2908]: local IP address 10.189.85.116
Apr 25 13:00:41 marv pppd[2908]: remote IP address 10.6.6.6
Apr 25 13:00:41 marv pppd[2908]: primary DNS address 172.20.2.39
Apr 25 13:00:41 marv blueman-mechanism: not replacing existing default route via 192.168.1.4
Apr 25 13:00:41 marv pppd[2908]: secondary DNS address 172.20.2.10
Apr 25 13:00:41 marv blueman-mechanism: local IP address 10.189.85.116
Apr 25 13:00:41 marv blueman-mechanism: remote IP address 10.6.6.6
Apr 25 13:00:41 marv blueman-mechanism: primary DNS address 172.20.2.39
Apr 25 13:00:41 marv blueman-mechanism: secondary DNS address 172.20.2.10
Apr 25 13:00:41 marv pppd[2911]: Hangup (SIGHUP)
Apr 25 13:00:41 marv pppd[2911]: Modem hangup
Apr 25 13:00:41 marv pppd[2911]: Connect time 0.0 minutes.
Apr 25 13:00:41 marv pppd[2911]: Sent 0 bytes, received 0 bytes.

After investigating, it looks like Debian bug #598551:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598551

I've then removed /usr/lib/python2.7/dist-packages/blueman/main/PPPConnection.pyc and started hacking on /usr/lib/python2.7/dist-packages/blueman/main/PPPConnection.py, replacing "updetach" with "nodetach" (and hacking check_pppd() so that it emits the "connected" signal even with a non-exited pppd).

Now Blueman was able to connect ppp0 successfully and I had an IP and very slow name resolution, but no connectivity: impossible to ping or go to a simple URL like http://google.com.

I've looked at the pppd options on my Nokia N810, where connecting via DUN works, and after a bit of dichotomy, found that adding "crtscts" fixed it for me.

Colin Leroy-Mira (colin-colino) wrote :

This is the patch I've done to PPPConnection.py to make it work for me.

Colin Leroy-Mira (colin-colino) wrote :

By the way, this is on Natty beta, up-to-date, with blueman 1.21-4.1build1.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers