Cross-compiling a custom Net-SNMP agent

Building the default agents in Net-SNMP is quite easy if you’re using tools such as Buildroot, and even when building directly from the sources is not a problem. However, is not that easy if you want to cross-build a custom agent inside Net-SNMP.

This procedure worked for me, but keep in mind that it was not a clean procedure since it involves modifying the generated Makefiles, so every time that you ./configure you will loose your changes.

First, let’s export common environment variables that make our life easier:


Package: net-snmp-


Instead of using the –with-cflags and –with-ldflags, you can define the CFLAGS and LDFLAGS:

The custom agent must be located inside the agent/mibgroup directory. In this case, create the directory agent/mibgroup/my_mib and write here the agent sources:

If these agent source use only libc it wouldn’t be an issue. But they use other libraries such as Glib2, SQLite3 and libxml2, thus we have to include these libraries by using the –with-cflags and –with-ldflags options or the CFLAGS and LDFLAGS environment variables.

However, when building, the linker didn’t find the GLib2, sqlite3 and libmlx2 shared libraries even though I specified the paths as above…
I got this kind of errors:

For solving this issue in a dirty but fast way, modify the files agent/Makefile and apps/Makefile. Set the LDFLAGS variable to the following value:

In this way you can quickly build your custom SNMP agent inside Net-SNMP.

Missing requirements when building with Buildroot

Buildroot is a quite useful tool when working with small-to-medium embedded systems. It helps you to create the toolchain, the rootfs and, of course, building the kernel and hundreds of packages normally found in standard Linux distributions.

For using Buildroot you need several mandatory and optional requirements in your host machine. They’re listed in the Buildroot manual. However, there are some sub-requirements that aren’t mentioned since they belong to a global requirement. For example the package Thread/ is a Perl module that belongs to the global requirement Perl.

The lack of one of these packages can cause building errors that can confuse new users since it could not be clear if it’s an issue with the package that it’s been built or if it’s an issue with the host machine that is missing something.

Normally, when you see an error like the following, you can be sure that there is a missing Perl module in your host machine:

In this example, Buildroot fails to build the ALSA lib since it requires the Perl module Thread/ that is missing.
You can easily install it, assuming that you already installed the CPAN module, by typing:

This kind of issues can also be present with other requirements, such as Python that can be installed with the pip utility.

Generally speaking, when you see a message like this one, there’s a good chance that the problem is a missing requirement:

Communicating to a serial interface of an embedded Linux device using kermit

I have used kermit for connecting to serial interfaces for several years and it has always worked as expected. Even for sending a kernel image to U-Boot using the zmodem protocol (yes, it took ages, but there was no Ethernet) has worked quite well.

Recently, a friend that is new to embedded Linux ask me how to connect to a serial interface, so this is a small and simple guide on how to do it.

Just as an intro, a summary of what is kermit taken from the Fedora repo:

C-Kermit is a combined serial and network communication software package offering a consistent, medium-independent, cross-platform approach to connection establishment, terminal sessions, file transfer and management, character-set translation, and automation of communication tasks.

If you have Fedora, CentOS, SuSE or other rpm based distribution

If you have Debian, Mint, Ubuntu or other deb based distribution

Create the configuration file .kermrc in your home directory. These parameters are normally right for most systems. I’ve used it for SH4 and ARM based devices:

The most important parameters here are the line parameter that indicates the serial device and the speed parameters that is it’s baud rate. If you have an USB-to-serial interface converter your device will be /dev/ttyUSBx where x is normally 0, but it depends on how may USB-to-serial converters you have. The same happens if you have a normal serial cable, except that your device will be named /dev/ttySx, where x is normally 0.

Add your user to the dialout group in the /etc/group file

Logout and login again. This is needed since the group to which a user belongs are assigned when the user logs in.

Open a shell and execute kermit. The output should be something like this:

By default, kermit searches the file .kermrc in your home directory. If you have several kermit config files (may be because you have several boards configured differently), you can specify it:

kermit /home/paguilar/.custom_kermrc

If there are problems like the wrong serial interface, you may see a message like this one:

You can also have this problem if there is a lock file. This error happens if you try to access the serial interface whilst another process is already using it. It can also happen if you kill a previous kermit session when it was connected to the serial interface.
In these cases you have to remove the lock file and execute kermit again.

Assuming that everything went right and you happily used a busybox shell or similar you can disconnect from kermit by typing Ctrl-\ + q

Just to be clear, the escape control sequence is Ctrl and backslash at the same time, then you enter the desired character.
For example, if you are in your board’s shell, for connecting to the kermit shell just type Ctrl-\ + c, then enter connect to go back to your board’s shell.

That’s it.