[Gllug] wicd manager

Tue Oct 20 12:55:28 UTC 2009

[formatting tidied]

I realised I hadn't sent this after postponding it, and since writing it
we've seen that the problem is clearly at the application/ISP level,
seeing as a traceroute without -n left the local network and also that
hosts were getting resolved - DNS works, which requires working
Internet*.

I've decided it's maybe worth sending as a reference for people.

On Fri, 16 Oct 2009, lucypeters at mail.com wrote:

> On Sun, 18 Oct 2009, Caroline Ford wrote:

> > On Thu, 2009-10-15 at 17:00 -0400, lucypeters at mail.com wrote:

> > > When I use wicd manager 1.5.9 to link up with the wireless router
> > > Airplus xtreme G , it said it has connected to my account and ip
> > > address at 97% WPA but the firefox was unable to update the web
> > > pages.  Do you know how to fix it ?

> > When you type ifconfig in a terminal do you have an IP address?

This is the best advice in this thread so far.  It can often be useful
to use: /sbin/ifconfig

As /sbin isn't always in non root user paths and this'll work on most
UNIX systems.

Also sometimes useful to compare against: /sbin/ifconfig -a
as this will show all interfaces the kernel is aware of beyond ones it's
configured.  To get really complex, there are "ip" commands with
iproute2 tools which go way beyond the normal unix stuff we've used for
years in the unux world, I won't go there.

> Yes , I have an IP address in eth 1 after typing ifconfig in a terminal.

This 95% of the way there.  Getting the kernel to confirm and talk to
your wifi chipset is hard, but it's managed that.  Seeing a signal
strength at this point is still only part of the way though.

It's then also successfully communicated the correct authentication, via
userspace (WPA with wpa_supplicant) or talking to the chipset itself for
basic WEP or no encryption (but with correct ESSID etc), associating and
connecting well enough to act as a working interface on the wifi
network, so that automatic IP configuration took place (DHCP).  To get
here wicd did it's job well.

I'd next suggest:

netstat -nr

Same as route -n on linux, but netstat will be in the path and this
command is portable to other unix systems.  The -r shows the routes, but
the important thing is we're not worrying about DNS yet with -n.

You're expecting to see a 0.0.0.0 as the Destination and something like
192.168.2.1 as your Gateway.  That IP will vary, don't assume it should
be that same IP!  (It could sometimes be a local IP of your destination
with 0.0.0.0 for Gateway if it's a /32 point to point link as with
dial-up over 3G with usb dongle or similar)

You should be able to:

ping -n 192.168.2.1

(substitute for the correct Gateway address)

This is quite likely to work unless there is some mad filtering on your
router.  It's often useful to know the IP of other devices in your home,
maybe a NAS or DLNA server that you can ping.  The existance of a
default gateway is likely with working DHCP but this part can sometimes
go wrong.  If you can ping other devices you know or, or your router if
you know its IP, then you can add this as a default gw and get stuff
working sometimes.

One reason to have a configured network device but no router is if you'd
inadvertently/forgotten that you'd set an IP on your interface and
actually DHCP hadn't worked and your kernel->wifi->network isn't
working.  I've seen this with failed firmware loading in to less
friendly wifi chipsets.  Some diagnostics to try are:
tcpdump eth1
(run as root) this may show a lack of data passing if it just sits
there, if you do see loads of traffic scrolling up the screen that's
good.

By this point if you get a response, you're almost completely there and
the problem is not your wifi connection.

Next up is whether DNS configuration has worked.  Use:

cat /etc/resolv.conf

You should expect to see lines like the following:

nameserver 32.123.45.67
nameserver 192.168.2.1

It's not uncommon for the gateway to be the nameserver.  If you have no
nameserver lines in /etc/resolv.conf then this is a problem and will
stop most normal internet stuff working.  You could try adding your
router's IP.  But normally this file is replaced by your dhcp daemon or
wicd or other stuff talking with the resolvconf package.

You could try something like:

traceroute -n 80.87.128.36
or
traceroute -n 212.58.224.138

These are a server at Positive Internet that people will get SMSed if it
goes down, so are keen to fix it quickly ;) and bbc.co.uk, which (if
it's not changed) is a load balancer leading you to a server which will
redirect you to www.bbc.co.uk a properly DNS load balanced farm.  Both
are IPs unlikely to change that soon.  But it's a good idea to keep a
few IPs like this handy.

If you see more than a couple of hops and it leaves the network, ie you
see network ranges that are definitely not your own laptop that has the
error.

You could also try traceroute or ping to the IPs mentioned in your
/etc/resolv.conf

If you have IPs in this file, you should be able to try something like:

telnet www.google.com 80

If you see something like the following:

damion at pants:~$ telnet www.google.com 80
Trying 209.85.229.106...
Connected to www.google.com (209.85.229.106).
Escape character is '^]'.

This pretty much tells you that your wifi and internet connection are
working.  You have DNS host resolution against www.google.com, tcp
connection on port 80 left you network connecting you to the google
servers.

You /might/ still have some issues, like a very slow response or hanging
pages, these could be caused by network congestion at your ISP level,
possibly wifi interference locally, and sometimes hung connections to
certain sites can be MTU size issues if those sites are blocking some
ICMP packets asking your side to change packet size or fragment etc.

Of course I'd hit a problem similar to that described, which was that
webpages wouldn't work.  All diagnosis led me back at the browser,
which it turns out, had started whilst eth1 wasn't configured and
decided to go offline, which it turns out is a bit of a faff to undo
via the toggle in the 'File...' menu!

Damion

*When I 1st had ADSL installed, DNS worked, but I couldn't pass real
traffic out until I'd authenticated with some captive portal at BT, this
was during an ADSL trial in the late 90s I believe.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug