Reply
Thread Tools
Posts: 42 | Thanked: 11 times | Joined on Nov 2009 @ Denmark
#161
The /etc/resolv.conf contains "nameserver 127.0.0.1" both after an boot up (with wifi disabled) and after using wifi - so it permanently contains "nameserver 127.0.0.1".

I dont even know what "vpnc" is so I dont think that it is installed :-)
 
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#162
Originally Posted by fatalsaint View Post
The problem with manually changing resolv.conf is most DHCP software will overwrite that when you connect via DHCP. I don't know specifically what the N900 does or has.. but I'd be wary of that.

I think the real problem isn't the resolv.conf's... but that script file discussed before. I believe that fires off whatever tool or utility that then creates the appropriate resolv.conf file for you.
No. The DHCP software actually use DNS masquerading server which uses multiple resolve.conf files which are defined in /etc/dnsmasq.conf

During wlan setup the udhcpc just runs some script during getting DHCP from wlan and writes a received "nameserver .... blah-blah-blah" info not to /etc/resolv.conf but to one of that files (/tmp/resolv.conf.wlan0 I think).

Next, then application asks about www.cnn.com it comes to 127.0.0.1:51 and asks dnsmasq server which does all work in acordance with bunch of files (from it's /etc/dnsmasq.conf).

Works fine. Now vpnc - it creates Yet-Another-IPV4-interface and should trigger somehow dnsmasq to it (it has it's own place - /var/run/resolv.conf or so). Moreover, it actually should disable the current /etc/resolv.conf because now host is on VPN and it should stop asking outside DNS daemons. For that reason it replaces /etc/resolv.conf with "nameserver 127.0.0.1" and copy old one to /etc/vpnc/resolv.conf-backup - don't forget, it is a generic package, not only Maemo. After disconnection it restores (actually both files have the same content).

And it also forwards now packets to VPN fixing a default routing. To do it vpnc package changes /etc/uhdcpc/libicd-network-ipv4 script - it is ran after each IPV4 connection setup - and put some stuff to it (see juaalo code).

Problems:

1) DNS - because /etc/vpnc/vpnc-script doesn't recognize correctly Maemo 5 (it checks the file /etc/osso-...-version) it executes the generic version and that version suffers from some race condition and because of that the copy-restore loop of resolv.conf may fail. So, /etc/resolv.conf is empty after that. It still works, but DNS problems because some applications do a BROADCAST request and some just can't do any.

2) routing - after upgrade from PR1.0.1 to PR1.1 via OTA the file /etc/uhdcpc/libicd-network-ipv4 is found to be changed and dpkg doesn't touch it... and PR1.1 has a different way to establish routing during connecting to WLAN and that file should have new content. That way doesn't work, old way doesn't too ... wifi connection problems.

Last edited by egoshin; 2010-01-15 at 21:26.
 

The Following User Says Thank You to egoshin For This Useful Post:
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#163
Originally Posted by Ulrik View Post
The /etc/resolv.conf contains "nameserver 127.0.0.1" both after an boot up (with wifi disabled) and after using wifi - so it permanently contains "nameserver 127.0.0.1".

I dont even know what "vpnc" is so I dont think that it is installed :-)
You have some different problem, so - please describe it again.
 
Posts: 42 | Thanked: 11 times | Joined on Nov 2009 @ Denmark
#164
I can connect to my router via WIFI and my N900 gets an IP address. No problems there. But when I open the web browser I can't (i repeat, I can't) look up any web addresses. So the problem is a DNS problem.

The /etc/resolv.conf contains "127.0.0.1".

I have not installed "vpnc" or something else.

Just upgraded a brand new N900 to PR1.1 and thats it.
 
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#165
Originally Posted by Ulrik View Post
I can connect to my router via WIFI and my N900 gets an IP address. No problems there. But when I open the web browser I can't (i repeat, I can't) look up any web addresses. So the problem is a DNS problem.

The /etc/resolv.conf contains "127.0.0.1".

I have not installed "vpnc" or something else.

Just upgraded a brand new N900 to PR1.1 and thats it.
Can you run as root (you need install package "rootsh") after you connect to wifi:

udhcpc -i wlan0

and post an output ?
 
rebhana's Avatar
Posts: 579 | Thanked: 471 times | Joined on Jan 2010 @ Austria
#166
Originally Posted by egoshin View Post
Problems:

1) DNS - because /etc/vpnc/vpnc-script doesn't recognize correctly Maemo 5 (it checks the file /etc/osso-...-version) it executes the generic version and that version suffers from some race condition and because of that the copy-restore loop of resolv.conf may fail. So, /etc/resolv.conf is empty after that. It still works, but DNS problems because some applications do a BROADCAST request and some just can't do any.

2) routing - after upgrade from PR1.0.1 to PR1.1 via OTA the file /etc/uhdcpc/libicd-network-ipv4 is found to be changed and dpkg doesn't touch it... and PR1.1 has a different way to establish routing during connecting to WLAN and that file should have new content. That way doesn't work, old way doesn't too ... wifi connection problems.
It doesn't really fit in this thread, but since you raised the issue: vpnc worked out of the box for me, despite the above issues. After reading your description, I thought I should clean up issue 1), and I
modified the /etc/vpnc/vpnc-script so that it would no longer use the generic behavior, but the maemo one, by changing
Code:
elif [ -e /etc/osso-af-init ]; then                                        
        MODIFYRESOLVCONF=modify_resolvconf_maemo                           
        RESTORERESOLVCONF=restore_resolvconf_maemo
I also did
Code:
echo "nameserver 127.0.0.1" > /etc/resolv.conf
echo "nameserver 127.0.0.1" > /etc/vpnc/resolv.conf-backup
to have everything in order, following your previous suggestions. But after a VPN session, it now no longer returned to the state it was in before, i.e. I lost my WLAN connection despite having seemingly correct resolv.conf files (instead of emptied ones). Don't understand...

Last edited by rebhana; 2010-01-15 at 22:28.
 
Posts: 24 | Thanked: 3 times | Joined on Jan 2010
#167
After:
dpkg -i --force-confnew /var/cache/apt/archives/libicd-network-ipv4*

*reboot*

Ping google.com still returns (1.0.0.0)

But I can still browse via Web Browser.

Apps like update manager etc, terminal, weather etc, CAN'T access internet.
 
Posts: 24 | Thanked: 3 times | Joined on Jan 2010
#168
Originally Posted by egoshin View Post
Can you run as root (you need install package "rootsh") after you connect to wifi:

udhcpc -i wlan0

and post an output ?
Sending discover...
Lease failed:
zeroconf: address selected is 169.254.173.8
zeroconf: state is Active/Announce, Link-local address 169.254.173.8
bogus packet, option fields too long: Read past the packet length when getting option 0x1 (308 >= 308)

and there are many of the above error with different options quoted instead of 0x1

then

/etc/udhcpc/default.script: exec: line 7: /etc/udhcpc/default.zeroconf: not found

then starts:

sending discover...

etc
 
Posts: 42 | Thanked: 11 times | Joined on Nov 2009 @ Denmark
#169
Originally Posted by egoshin View Post
Can you run as root (you need install package "rootsh") after you connect to wifi:

udhcpc -i wlan0

and post an output ?
udhcpc (v0.9.9-pre) started
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Lease failed:
zeroconf: address selected is 169.254.26.91
zeroconf: state is Active/Announce, Link-local address 169.254.26.91
bogus packet, option fields too long: Read past the packet length when getting option 0x1 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x2 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x3 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x4 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x5 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x6 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x7 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x8 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x9 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0xc (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0xd (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0xf (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x10 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x11 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x17 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x1a (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x1c (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x28 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x29 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x2a (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x2c (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x32 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x33 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x35 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x36 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x38 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x42 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x43 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0xfc (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x34 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x1 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x2 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x3 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x4 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x5 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x6 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x7 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x8 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x9 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0xc (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0xd (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0xf (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x10 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x11 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x17 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x1a (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x1c (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x28 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x29 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x2a (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x2c (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x32 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x33 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x35 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x36 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x38 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x42 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0x43 (308 >= 308)
bogus packet, option fields too long: Read past the packet length when getting option 0xfc (308 >= 308)
/etc/udhcpc/default.script: exec: line 7: /etc/udhcpc/default.zeroconf: not found

I have no idea what to make of that ???

By setting primary and secondary DNS for my AP/router on the N900, I can access the Internet - look up web pages. But that is only a fix for my own AP. I don't wan't to do that on every WIFI I connect to
 
Posts: 71 | Thanked: 88 times | Joined on Dec 2009
#170
Originally Posted by egoshin View Post
Can you write a little more details? File /etc/dnsmasq doesn't exist but it should be /etc/dnsmasq.conf and you may find file /etc/dnsmasq.conf.dpkg-dist

Just double check before next steps...
I wrote that in a hurry but to reiterate everyone who has a DNS issue should follow the steps that DaveQB explained in detail so they can rule out missing/wrongly configured files:
http://talk.maemo.org/showpost.php?p...6&postcount=56


The basic premise i am seeing from this forum, if not covered already, is that if you have any files with *.dpkg-dist then it means the update has not upgraded the associated file, thus the settings in that file may not match changes in the rest of the system.
 
Reply


 
Forum Jump


All times are GMT. The time now is 16:23.