In this article the reader will learn about some methods of capturing useful debug information.
Do note, that if you have issues, and you are going to use these methods, then we recommend starting a thread in the community, or commenting in an existing thread. If you are going to configure remote logging then please make sure to mention UBNT-MikeD, UBNT-Cody, UBNT-BenBuckley, UBNT-jeff, or UBNT-Brandon.
One of the first things we ask for when debugging is the output of 'cat /var/log/messages` or 'dmesg'. In some cases, however, not all messages can be sent back over SSH session to the user. Another common case is that you are not actually logged in when the issue happens, so you are unable to see the ouput and the messages are lost when the AP reboots. The easiest solution at this point is to use a remote log server.
In addition to capturing information that resulted in a reboot, using a remote server can simplify the process of sharing log files.
For UAP firmware versions 3.7.18 and later:
SSH into the device and execute the following command:
For UAP firmware versions 3.7.17 and earlier:
Start netconsole with the following command:
insmod netconsole netconsole=1234@<IP addr of AP>/eth0,email@example.com/<MAC addr of your router>
NOTE: 1234 is a dummy port number and this number can be anything
NOTE: MAC address should contain colon characters like this XX:XX:XX:XX:XX:XX
If you want netconsole to persist across reboots, do the following:
echo "<netconsole command from above" > /etc/persistent/profile
Even after running the commands to make the remote logger persistent, you must SSH into the AP to initialize it. So for every reboot, you must SSH into the AP after the reboot in order to start logging again.
In order to de-activate netconsole after having made it persistent:
Let Us Know
After enabling netconsole, please let us know so that we can keep an eye open for the logs. We will need to know your public facing IP address that the log messages will be coming from, since this is how the log file is identified on our server.
Since these instructions are now public, we may end up with a lot of logs. Please be courtious and only use this functionality if you are helping us debug something and are in communication with us.
Minimum Supported Firmware Versions
Netconsole is only supported in more recent firmware versions. Please reference the information below to determine the minimum support version.
- Version 3.7.9 supports netconsole for everything but UAP-InWall.
- Version 3.7.10 added support for the UAP-InWall.
Capturing Network Traffic at the AP
Wireshark captures of what is happening in the air are extremely helpful, but sometimes it's necessary to see what the traffic looks like after having been processed by the radio. Capturing that data can be a pain, so hopefully the methods here will help.
Use tcpdump for Capturing Traffic
You can capture traffic on any interface of the AP:
tcpdump -i <iface i.e. br0 or athX> -w /tmp/<descriptivefilename.pcapng>
Where athX correspeonds to an SSID being broadcast by the AP, and can be found by SSH'ing into the AP and executing iwconfig
This method has the notable drawback that the file is being saved on the AP, which will eventually exhaust the memory if left running for too long, and also requires you to go grab the file when you are done (which is annoying at best). You can modify the above command to save the file(s) to the computer from which you are running the ssh session:
ssh <user>@<ip of AP> 'tcpdump -i <iface> src not <ip of computer> and dst not <ip of computer> -w -' > <descriptivefilename.pcapng>
The src not and dst not conditions are important because they stop your file from being saturated with SSH traffic between the computer and AP.
Run this command for as many interfaces as you want to capture traffic from.