Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Question (concise version):

Where in my log files would I find information regarding the networking steps executed between the time I have left the login screen and the time I have landed comfortably at my desktop screen?

$ uname -a
Linux schmo 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux

Question (longer version with more than one clause):

Who, or what daemon, or which scripts are responsible for setting up my network settings at login? I have found that several attempts to modify /etc/network/interfaces either go ignored or end in a non-functioning setup, but that the two-line original loopback version works fine. I want to know where the action is actually happening.

What .conf's and bash scripts should I pepper with echo-and-dump statements, or what environment variables should I be aware of and set, if the current level of feedback in the currently-available log files is not of a resolution high enough to catch the network changes being performed during login?

Motivation (at least one of them):

How would I go about telling my computer to establish a wireless bridge after my wireless network adapter is up and running, which itself seems to occur only after I log in, sometimes completing after I have already clicked on Firefox but before I remember to look for the wifi status icon, argh.

What I've done so far:

  • SUCCESSFULLY added a VM running precise server i686 to my precise desktop i686 using KVM

  • SUCCESSFULLY updated, upgraded, and added to the packages on the VM through the bridge setup suggested at, and following the course of, while ssh'd from my desktop. This implies the bridge was working, if only for one session. My guess is that between the time I set up my /etc/network/interfaces file and the time I no longer had internet access through my VM, the changes I (or KVM, or someone) made to my configuration files had propagated only partially through my system(s) from boot to boot and restart to restart, whatever that means.

  • UNSUCCESSFULLY tried to resurrect VM internet access by adding wlan0 to /etc/network/interfaces in various forms, including installing wpa_supplicant.

  • RECEIVED AN ERROR from wpa_supplicant which I believe I was able to trace back to the fact that wpa services are mysteriously already running each time I restart networking. This led me to the discovery that...

  • AVAHI WILL NOT STAY DEAD due to being respawned by process #1 ; avahi then runs other stuff, and may be responsible for the normally satisfying, but now vexing, behavior of my wireless connection coming alive each time I log in (or not doing so, if I try to modify /etc/network/interfaces).

More details are available; just tell me what you'd like. I am playing a game of Chutes-and-Ladders with the heaps of knowledge I have learned from trying what I have so far, and the vast chasms of ignorance about even basic terms and SOP that keep me from putting things together.

I have looked at this page. Note the part about wireless bridging. I have my reasons for ignoring this caveat for the moment.

share|improve this question

As to the short question (and note the cmd #'s I added, starting from 0):

0) dmesg | grep wlan0

will give timestamps for system events (since your most recent boot) regarding your wireless router. Note that some people's devices may be called 'eth0' or another variant besides 'wlan0', depending on kernel, device management, and other configuration settings beyond this respondent's grasp.

Next, follow the grep chain. When in doubt, look everywhere you can think of. Everywhere I could think of was /etc and /var/log:

  • /etc contains configuration files and scripts that define practically all of your services' behavior, no exaggeration.
  • /var/log is the standard location for these services to dump their outputs for logging, whether in a form easily identifiable to human eyes or not.

NOTE: Recursively grep'ing / can't hurt on current systems with memory, cpu time, and disk space to spare. Familiarize yourself with coordinated bio breaks and ctrl-C, it could take a while. Also look into redirecting output to a file, so you can read it later. DO NOT sudo grep unless you really know what lies beneath those system directories grep denies you. Those system directories quickly become redundant, recursive, overly verbose, non-text, and myriad.

I got copious information from the following greps:

1) grep "wlan0" -R /var/log 2>/dev/null

This grep will spit out all the lines I got from dmesg plus some things dmesg does not show - like calling process names for each timestamp or process id, lines from previous boots, the names of files I didn't even know about like /var/log/udev...

An aside: udev does frickin' everything!

That grep -R is going to need some deconstruction, however. To relate it immediately to the initial grep statement, take any timestamp from dmesg (the numbers in brackets) and try

2) grep "\[ 8529.265562\]" -A 10 /var/log/syslog 2>/dev/null

where you replace my timestamp with whatever timestamp you happen to be interested in. NOTE: To be as noob-unfriendly as possible, the shell-and-regex people require you to add those backslashes to the brackets, i.e. \[ and \], don't simply copy-and-paste. Why? Barriers to entry, that's why. Read up on grep and regular expressions.

The above grep -A should give you the line from dmesg you were expecting (which also got logged in /var/log/syslog with the rest) and its 10 succeeding entries:

$ grep "\[11766.363095\]" /var/log/syslog -A 10 2>/dev/null
Oct 19 08:57:40 mitzvah kernel: [11766.363095] wlan0: authenticate with 12:34:56:78:9a:bc (try 1)
Oct 19 08:57:40 mitzvah kernel: [11766.365183] wlan0: authenticated
Oct 19 08:57:40 mitzvah NetworkManager[1261]: <info> (wlan0): supplicant interface state: authenticating -> associating
Oct 19 08:57:41 mitzvah kernel: [11766.638899] wlan0: associate with 12:34:56:78:9a:bc (try 1)
Oct 19 08:57:41 mitzvah kernel: [11766.641406] wlan0: RX AssocResp from 12:34:56:78:9a:bc (capab=0x411 status=0 aid=2)
Oct 19 08:57:41 mitzvah kernel: [11766.641411] wlan0: associated
Oct 19 08:57:41 mitzvah wpa_supplicant[1866]: Associated with 12:34:56:78:9a:bc
Oct 19 08:57:41 mitzvah kernel: [11766.646978] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Oct 19 08:57:41 mitzvah NetworkManager[1261]: <info> (wlan0): supplicant interface state: associating -> associated
Oct 19 08:57:42 mitzvah NetworkManager[1261]: <info> (wlan0): supplicant interface state: associated -> 4-way handshake
Oct 19 08:57:42 mitzvah wpa_supplicant[1866]: WPA: Key negotiation completed with 12:34:56:78:9a:bc [PTK=CCMP GTK=CCMP]

Hey look! there's wpa_supplicant, in line 6. It's process id was 1866 at the time. And there's another process that sounds network-manager-like, called NetworkManager. That's the culprit I was looking for that keeps waving its magic wand at my network setup.

This is not the end, of course. I googled NetworkManager ; I regrep'ed the log and /etc directories on wpa_client armed with slightly more info. When my network was least well and I could not figure out how NetworkManager knew what it did behind my back, I found solice in the following command:

3) grep wlan0 -R /etc
/etc/udev/rules.d/70-persistent-net.rules:SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="12:34:56:78:9a:bc", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

This /etc/udev/rules.d/70-persistent-net.rules file holds information about my less-than-permanent devices over from session to session, I think. This would be how various services are able to seem like they know what it is you're plugging and unplugging from time to time ; they do know, since somebody's recording it.

All of this, just for info. My main motivation is unsatisfied: I have yet to get my wlan0 up from boot. Here's to hoping.

Linux - Because I like banging my head against walls.
share|improve this answer
Some hopefully cross-fingers useful links for Network Manager: (note out-of-date warning) – Louis Carole Oct 19 '12 at 19:08
Also - to discover that, e.g. /etc/NetworkManager/system-connections contains information pertinent to this topic, you will have to use sudo grep (selectively). Argh. "Look where you're supposed to look." "Where's that?" "Somewhere you're not supposed to look." "Where's that?" – Louis Carole Oct 19 '12 at 19:14
Another maybe-useful link: BUT note that I found this when I googled for info about the IPv4 settings option "Shared to other computers" ; I am shaky about the terminology "ad hoc" - is it synonymous with this IPv4 option in the network manager app? – Louis Carole Oct 19 '12 at 19:32
Here's something on wifi "master" mode, which differs from "managed" and "ad hoc" (but is similar to "wds") in that it allows (or disallows?) the abuse of MAC addresses by the wireless card. I may soon know what that means! – Louis Carole Oct 19 '12 at 21:49
More sideways news: proxy ARP This may be the (only) way to go for my desired setup. – Louis Carole Oct 20 '12 at 3:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.