[Gllug] wicd manager

[Caroline Ford]

She said that the traceroute she sent wasn't when using the wifi (and  
therefore wasn't useful).

When she tried the traceroute using her wifi only she got a DNS error.

She had said previously that she had an IP address for eth1 but we  
havn't checked whether that was with the Ethernet cable connected and  
hence whether that could be the Ethernet.

The thread got sidelined by a rant on Virgin Media which seems  
unconnected to the topic.

Caroline

Sent from a mobile device.

On 20 Oct 2009, at 13:55, damion.yates at gmail.com wrote:

> [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
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug