Some problems with the configuration of java using jNetPcap to sniff network packets under linux

Preface

For the configuration and use of java using jNetPcap to sniff network packets under windows, and some introduction, see the previous article:  java uses jNetPcap to sniff network packets under windows .

In addition, I also use version 1.4 under linux. If you are still worried about 1.4 and don't know where the problem is, you can read on.

Configuration steps

1. Add jnetpcap.jar to the project dependency library. It is not clear where the dependent libraries  are configured and used under windows that use jNetPcap to sniff network packets in java .

2. Add libjnetpcap.so to java.library.path, according to the actual situation of the system environment (it is recommended to put it directly under /usr/lib).

3. Install libpcap library

It is troublesome to install libpcap offline, you need to install it in sequence: m4, bison, flex, libpca.

There are a lot of tutorial materials about the installation of libpcap on the Internet, I found one, you can refer to it if necessary: The installation of libpcap under Linux , it is very clear

If you find it troublesome to download, I have downloaded the latest versions of these packages and put them on Baidu's network disk. Here is the address:

Link: https://pan.baidu.com/s/1SETEnzsh9W2XICEqaNOiOg 
Extraction code: b1xo

After the installation is complete, you can test it.

 Configure and use under windows using jNetPcap to sniff network packets in java . Here I have written test code. After editing, you can directly open vim and compile with commands such as javac -classpath and execute commands such as java -cp. However, in this case, you need to specify The location of the jar package of jnetpcap that is well dependent. Or use spring boot to directly type an executable jar package and type the dependencies in. The method is not important.

The key is to talk about some problems with configuring libpcap.

Possible problems

The following is the focus of this article.

The dynamic link library could not be found. This is generally the problem.

A lot of times it makes people headless.

First of all, make sure that the location of libjnetpcap.so is no problem. You can print the value of the java.library.path variable and see the configuration and usage instructions under windows for java using jNetPcap to sniff network packets . Make sure it is in these directories.

If libjnetpcap.so is ok, it is very likely that there is a problem with the library that libjnetpcap.so depends on, that is, there is a problem with the installed libpcap, but this error message does not tell you where there is a problem. First, check the directory where libpcap is installed. No problem, I used centos to do the test. Generally, after installation, the library file is in this directory: /usr/local/lib, you can check or configure the directory of the dynamic link library:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

But this is only temporary, you can modify the configuration file /etc/ld.so.conf and set it to permanent:

sudo vim /etc/ld.so.conf

as follows:

Join this directory, and then execute the command:

sudo ldconfig

If there is still a problem of dependent libraries, it is probably because libjnetpcap.so can't find which library, check which library file is missing, there is an ldd command to see, as follows:

If you can’t find any library file, the above => is empty, for example, if libpcap.so is not found, it will display libpcap.so =>

In short, if you see which one is missing, just find a way to fill it up, reinstall it, change the name, create a soft link, etc., as long as you can provide the dependent dynamic link library.

Finally , this location is in the code written in the  configuration and use of windows that uses jNetPcap to sniff network packets in java .

 This 64 is the length of the captured message. If no filter is set, non-zero will be ignored under certain conditions or operating systems. For example, it was ignored on windows before, and 64 does not matter. When testing on centos, It took effect, so there is a need to increase the value of this parameter. According to the official comment, 65535 theory should be possible.

 

 

 

 

 

Guess you like

Origin blog.csdn.net/x763795151/article/details/106591783