LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Tethering Nokia E71 DUN via bluetooth from Slackware 13.37 64bit (http://www.linuxquestions.org/questions/slackware-14/tethering-nokia-e71-dun-via-bluetooth-from-slackware-13-37-64bit-4175434725/)

Pscylo 10-30-2012 04:25 AM

Tethering Nokia E71 DUN via bluetooth from Slackware 13.37 64bit
 
As the title says, I'm trying to get a DUN connection through my phone.

I have them paired and trusted, each can see the other, and using the "send file" option in blueman-manager, I can indeed send files, and using the right click option of "browse device" I can indeed browse the device.

If, however I click on the "setup" option, and select either "Connect to serial port" or "Connect to to DUN", it says "Device added successfully, but failed to connect".

Previously in 12.1 I bound rfcomm0 to the local bluetooth device one the correct channel at boot and had a gprs chat script and a file I called with pppd with the modem commands therein. It doesn't seem to be the method of configuration any more.

My guess is that there is no chat script anywhere, so the phone modem doesn't know what to so, but I can't see anywhere to add that.

Any thought?

Pscylo 10-30-2012 06:48 AM

Well I'll reply to my own post. Still not sorted but sem to be a little further on.

I'm trying using the method I know - ie using pppd.

When I issue:

Quote:

#bash-4.1# pppd call gprs3g
sh: /etc/ppp/peers/gprs3g.on: Permission denied
Script /etc/ppp/peers/gprs3g.on finished (pid 3633), status = 0x7e
Connect script failed

^ this happpens.

That way I'm reading it, it's not even running the script.

Additionally I go from this before issuing the command:

Quote:

bash-4.1# rfcomm
rfcomm0: 00:21:FE:7F:6F:31 channel 4 clean

to this after

Quote:

bash-4.1# rfcomm
rfcomm0: 00:21:FE:7F:6F:31 channel 4 closed

Pscylo 10-30-2012 07:24 AM

A bit further on now - gave the scripts x permissions and they now run. Not sure if that's correct since my scripts didn't have those permissions last time, but it's a moot point anyway since it's trying to connect on channel 3 (not channel 4 that rfcomm0 is bound too).

Still get:

Quote:

bash-4.1# rfcomm
rfcomm0: 00:21:FE:7F:6F:31 channel 4 closed
After the failed command. I presume it's now failing as it's trying to connect on the wrong channel. I'll continue to post on my own thread in case it helps anyone.

Pscylo 10-30-2012 08:34 AM

Channel was a red herring. Problem was the script was wrong - now connects, and can ping out by IP but DNS isn't working.

Grischuna 10-30-2012 09:22 AM

Quote:

Originally Posted by Pscylo (Post 4818132)
Channel was a red herring. Problem was the script was wrong - now connects, and can ping out by IP but DNS isn't working.

Check the resolv.conf. pppd is not using /etc/resolv.conf but /etc/ppp?/??? if I remember well. Faced the same issue the last time I was doing the same.

Cheers

Pscylo 10-30-2012 10:33 AM

Quote:

Originally Posted by Grischuna (Post 4818174)
Check the resolv.conf. pppd is not using /etc/resolv.conf but /etc/ppp?/??? if I remember well. Faced the same issue the last time I was doing the same.

Cheers

Yes, that appears to be the issue. /etc/ppp/resolv.conf correctly reflects the new nameservers, presumably the system is still looking at /etc/resolv.conf

Is there an elegant way of ensuring that /etc/ppp/resolv.conf is used? I've seen various solutions like adding pppup and pppdown scripts that copy /etc/ppp/resolv.conf to /etc/resolv.conf but surely there's a more elegant solution; after all if there weren't why would ppp write to /etc/ppp/resolv.conf if that were not the case.

Pscylo 10-30-2012 11:41 AM

Turns out ip-up and ip-down scripts in /etc/ppp is the correct way. Don't recall having to do it that way before, but hey ho. Any suggestions as to why it's done this way would be grateful any road.

There are some vanilla scripts in /usr/share/doc/ppp-2.4.5/ on this machine - they worked pretty much out of the box for me (just needed to make them executable and amend the first line of the file to #!/bin/sh) and copy across to /etc/ppp. Works fine now.

I'll shall continue to answer my own questions in future in the absence of assistance as I found it helpful to have a written record of what I had done. Hopefully someone may find it useful in future.


All times are GMT -5. The time now is 06:34 AM.