Unable to resolve names while DUN tethered. [Solved]

[Neelix]

I hadn't used BT tethering for a while, as I haven't had a reason to. I just fired it up for the first time in a while using PowerGod's BTDUN PND. (which established a connection with pppd)

Now everything goes swimmingly right up to the point where I try to browse - then it fails to resolve any server names.

I have no other active network connections.

I can ping to IP addresses just fine.

The the pndrun.out file shows that a Primary DNS server is being received from the provider. (in this case 203.20.33.72) No Secondary server is listed.


$cat /var/volatile/run/resolv.conf
returns


nameserver 203.20.33.72

$nslookup www.google.com

takes a while, then returns


;; connection timed out; no servers could be reached

nslookup www.google.com 203.20.33.72

returns 4 IPs for www.google.com as expected.

My netbook when tethered to the same phone also works ok.

rebooting did not resolve the issue


Obviously there is an issue on the pandora itself where DNS requests aren't being sent to the right server when connected via pppd but I can't for the life of me figure out why.

thoughts?

-- Neelix

 

[PowerGod]

I can't reproduce the issue... but I'm thinking that the only parameter BTDUN asks to the Phone is the channel, the other comunication parameters are arbitrary, maybe your phone can have problems with those values ? The comunication to and from the pandora can result slower or messy in that case... it's just a guess...


What phone do you use ?

 

[Neelix]

It's a Nokia N97 Mini, and I'm running SuperZaxxon 1.52 with all the latest updates.

The thing is that as far as I can tell, that part of things is working ok. The connection is established as per normal. It stays established until I disconnect it. I just can't make use of it properly without name resolution.

The one thing that does puzzle me is only receiving a Primary DNS when it used to show both primary, and secondary. I suspect that's due to a change on my service providers side (they've been doing network migration) but either way the same connection works just fine under ubuntu on the netbook, so it can't be an issue on the provider's end.

- Neelix

 

[mcobit]

Can you give it a dns manually?

 

[Neelix]

I could try, but I have no idea how to do that with a pppd based connection. It doesn't show up in network manager. Any suggestions?

- Neelix

 

[PowerGod]

In the script used by BTDUN there's a command to ask automatically the DNS to the server, maybe one can also put directly the dns there... I need to do some research... if it's the case I can add an option to specify manually the addresses to use

 

[EvilDragon]

You can always put the nameserver manually into /etc/resolv.conf

nameserver xxx.xxx.xxx.xxx

All the other tools simply do the same thing

 

[Galaxis]

Right - I noticed BTDUN doesn't seem to update resolv.conf, too. I just created a matching file to copy over the one generated by Network Manager.

Usually, pppd gets nameserver information when logging in... Didn't have a look at the BTDUN code, but in theory, enabling usepeerdns in pppd and then just copying /etc/ppp/resolv.conf to /etc/resolv.conf after login should work?

(Although I guess there's more fancy methods nowadays like notifying Network Manager of the new DNS servers over whatever mechanism that has been created for something like that...)

 

[Neelix]

ok, well manually copying /var/volatile/run/resolv.conf over the top of /etc/resolve.conf after connection does seem to get it working.

That solution may be kind of difficult to implement in BTDUN though as it calls pppd in the foreground, so the script is essentially suspended from the time the connection is established to the time it is disconnected. (it uses this fact to do set up and clean up all in the same script) I have confirmed that BTDUN does indeed pass the usepeerdns option to pppd.

The odd thing about all this to my mind is that pppd used to do this itself, (or it had a working alternative solution) so I don't understand what changed. The only thing I can think of is that pppd is waiting for a Secondary DNS which isn't coming (for whatever reason) so without it the DNS code never activates.

hrm...

usepeerdns
Ask the peer for up to 2 DNS server addresses. The addresses
supplied by the peer (if any) are passed to the /etc/ppp/ip-up
script in the environment variables DNS1 and DNS2, and the envi‐
ronment variable USEPEERDNS will be set to 1. In addition, pppd
will create an /etc/ppp/resolv.conf file containing one or two
nameserver lines with the address(es) supplied by the peer.
 

I don't know if if-up is being actioned but It doesn't seem to be creating any of those variables and it doesn't create /etc/ppp/resolv.conf (which I think is where the issue is)
I've also noticed that network manager wasn't able to complete a connection via USB tethering, though it appeared to connnect and then give up at the last moment. I now wonder if its the same issue.

I wonder if it could be due to a mis-configuration at the service providers end. Perhaps ubuntu's version of Network Manager has been patched to work around such a problem?

- Neelix

 

[PowerGod]

I just monitored my /etc/resolv.conf

It was empty with just a "# Generated by Network Manager" line

Started BTDUN and selected the phone

resolv.conf has now 2 "nameserver+address" lines

there must be indeed something that pppd doesn't like about your connection...

Anyway I can think a way to monitor pppd with another bash if it can help with issues like this, anyway I don't like very much the idea to modify NAND things directly ... I will add also the possibility to specify addresses by hand, and will wait for news about the problem

 

[Neelix]

Ok, well I found that my phone uses a different access point name than what I had been using so I decided to use that instead. This gives me a connection with which is supplying 2 DNS servers, but the problem persists.

So I added debug to options passed to pppd by the peer file in appdata.

This adds a lot more information about what pppd is doing to the pndrun.out file.

With this I was able to confirm that /etc/ppp/ip-up is in fact being executed.

It in turn calls /etc/ppp/ip-up.d/*

This folder contains a script called 08setupdns.

This script attempts to run /sbin/resolvconf if it exists, (it doesn't on my system)

failing that it makes sure that /var/run/resolv.conf is a symlink that points to /var/run/ppp/resolv.conf and makes it one if it isn't.

I'm thinking something has gone screwy with my system now. Could you tell me if /sbin/resolvconf exists on your nand? If not, could you show me the contents of your /etc/ppp/ip-up.d/08setupdns script?

- Neelix

 

[PowerGod]

#!/bin/sh
ACTUALCONF=/var/run/resolv.conf
PPPCONF=/var/run/ppp/resolv.conf
if [ -x /sbin/resolvconf ] ; then
cat $PPPCONF | resolvconf -a $PPP_IFACE
elif [ -f $PPPCONF ] ; then
if [ -f $ACTUALCONF ] ; then
if [ ! -h $ACTUALCONF -o ! "`readlink $ACTUALCONF 2>&1`" = "$PPPCONF" ] ; then
mv $ACTUALCONF $ACTUALCONF.ppporig
fi
fi

ln -sf $PPPCONF $ACTUALCONF
fi


I don't have /sbin/resolvconf ... there must be something else that move those values

 

[Neelix]

What version of SuperZaxxon are you running? (and if running 1.52, have you run the OS upgrade script)

I just plugged my SD card into my other pandora which is still running beta 5a, and that has identical ip-up scripts but etc/resolv.conf gets updated successfully on that.

So that leaves me wondering what mechanism normally copies this data to etc/resolve.conf and how do I fix it...

I'm also wondering if its time to reflash the unit.

- Neelix

 

[mcobit]

Might also be some permission issue.


Maybe the resolv.conf gets oberwritten with the osupgrade and isn't writeable anymore?


What is its current owner and what permissions does it have?

 

[Neelix]

I don't quite see how... pppd won't run except as root anyway, so all the relevant work should be being done as root with full permissions.

- Neelix

 

[PowerGod]

I have SZ 1.52 fully updated with the script.

try to see if you have something missing:

$ sudo fuser -m -v /etc/resolv.conf

                     USER        PID ACCESS COMMAND
/etc/resolv.conf:    haldaemon   1670 ....m hald
                     root       1769 ..c.. pndevmapperd
                     root       1795 F.... pndnotifyd
                     root       1821 F.... X
                     powergod   1832 F.... bash
                     powergod   1862 F.... sh
                     powergod   1876 F.... xfce4-session
                     powergod   1884 F.... xfwm4
                     powergod   1885 F.... xfsettingsd
                     powergod   1886 F.... xfce4-panel
                     powergod   1887 F.... xfdesktop
                     powergod   1891 F.... xfce4-settings-
                     powergod   1894 F.... xfce4-menu-plug
                     powergod   1910 F.... xfce4-brightnes
                     powergod   1911 F.... xfce4-mixer-plu
                     powergod   1912 F.... xfce4-battery-p
                     powergod   1913 F.... orageclock
                     powergod   1915 F.... configbutton
                     powergod   1919 F.... bluetooth-apple
                     powergod   1923 F.... nm-applet
                     powergod   2009 F.... Terminal
                     powergod   2358 F.... pnd_run.sh
                     powergod   2473 F.... firefox.sh
                     powergod   2476 F.... firefox
                     powergod   2520 F.... pnd_run.sh
                     powergod   2633 F.... wrswitch
                     powergod   2637 F.... gksudo
                     root       2639 F.... bash
                     root       2728 F...m pppd

 

[Galaxis]

Argh. On a freshly installed SZ 1.52, /etc/resolv.conf is a symlink to /var/run/resolv.conf - and the logic in 08setupdns can only work as long as that is the case.

I'm pretty shure that before I reinstalled the system a couple of days ago, my /etc/resolv.conf was a real file. No idea how or when that happened.

So I guess the first thing to check when BTDUN doesn't seem to update the nameservers is if the symlink to /var/run/resolv.conf still exists.

 

[PowerGod]

:lol:   I did't even noticed... I was still asking myself what app was writing in there

 

[Neelix]

Mine shows considerably more processes actually, but very few show access as F....
pppd has access set as .r.e.

...

WIN!

Thank you Galaxis!  

For the record the winning combination in this situation is: 

sudo cp -f /etc/resolv.conf /var/run/resolv.conf
sudo ln -sf /var/run/resolv.conf /etc/resolv.conf

This doesn't solve the problem I mentioned with USB tethering mind you,  but I'm happy to have BT tethering working again.

- Neelix