Hi All,
My setup is: TX2 with J140 Auvidea carrier board. Installed JetPack 3.2.1 enabled config#1.
I have created a java program that can listen in on the ethernet adapters on the board. I run the java process with sudo rights, but I keep getting an error where I can’t see any NIC’s on the board. If I run TcpDump as sudo I’m able to get access to the NIC’s.
Is there a specific setting in the os where I need to set to allow java processes to access libpcap or what?
Which rights does the sudo user have. I use ubuntu now.
Thanks.
I haven’t tried this, but from what I can tell you can add your user name to the “netdev” group:
sudo usermod -a -G netdev <user>
Thanks a million. I will see if that will make it work.
Thanks linuxdev,
That did not do the trick:
ubuntu@tegra-ubuntu:~/test/libpcap-nativ-tester$ id
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),20(dialout),27(sudo),29(audio),44(video),109(netdev)
ubuntu@tegra-ubuntu:~/test/libpcap-nativ-tester$ java -cp build/libs/libpcap_tester-1.0-SNAPSHOT-all.jar Main
14:16:44.605 [main] INFO NativeMappings - Pcap4J successfully loaded a native pcap library: libpcap version 1.7.4
14:16:44.615 [main] INFO Main - No NIF was found.
ubuntu@tegra-ubuntu:~/test/libpcap-nativ-tester$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:04:4b:a7:ee:bd
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:43
eth1 Link encap:Ethernet HWaddr 00:a0:c9:00:00:00
inet addr:172.16.60.150 Bcast:172.16.60.255 Mask:255.255.255.0
inet6 addr: fe80::ac25:cd55:ab00:b481/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15228 errors:0 dropped:0 overruns:0 frame:0
TX packets:8649 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1451302 (1.4 MB) TX bytes:1423283 (1.4 MB)
Memory:50100000-501fffff
eth2 Link encap:Ethernet HWaddr 5c:f7:e6:8b:a1:79
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0:avahi Link encap:Ethernet HWaddr 00:04:4b:a7:ee:bd
inet addr:169.254.10.249 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
Interrupt:43
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:703 errors:0 dropped:0 overruns:0 frame:0
TX packets:703 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:144371 (144.3 KB) TX bytes:144371 (144.3 KB)
wlan0 Link encap:Ethernet HWaddr 00:04:4b:a7:ee:bb
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ubuntu@tegra-ubuntu:~/test/libpcap-nativ-tester$ sudo java -cp build/libs/libpcap_tester-1.0-SNAPSHOT-all.jar Main
14:17:12.860 [main] INFO NativeMappings - Pcap4J successfully loaded a native pcap library: libpcap version 1.7.4
14:17:13.362 [main] INFO Main - No NIF was found.
I just don’t get it…
I have created this small app(java) : Kasper Aaquist Johansen / libpcap-nativ-tester · GitLab
“sudo” turns a user into root, so everything from the sudo command on has root access. In Java it can be hard to figure out what is going on because it isn’t a simple chain of one library or resource talking to another…Java has its own way of doing things and I’m not very good with that.
Of your eth# interfaces it looks like only eth1 has an address. This might not matter for what you’re doing, but the others won’t work for normal IP traffic until they get an address.
If libpcap is capturing traffic it might be that there is no way to grant permission to other users and sudo might be mandatory. I don’t know enough about using libpcap to say, but needless to say sniffing network traffic requires security to allow it.
There are some additional packages and features surrounding security which might also be interfering (in which case they could be configured to allow your user, but that’s a difficult topic). One is “AppArmor”, the other is “SElinux”. I think SElinux is not enforcing by default, but AppArmor might be. Don’t know…you’ll need to look at those to see what they are doing. Someone who knows more about your specific goals might be able to give a better answer.
Thanks. I tried to setup AppArmor, and in the end I just uninstalled it. That did not solve my problem. I must say that I read that I needed to rebuild kernel with flags set to disable. I have not done that since I don’t know if that is something we need to do to disable it on the TX2 JetPack 3.2.1 ver.
But I have narrowed it down to be all native c libraries. I can’t access from Java code. I have not tried this before, so I’m afraid it is a kernel setting or something like that.
Is there anyway to setup a vanilla Ubuntu 16.04 on the TX2. So we don’t get all the desktop, openoffice and other stuff that we don’t need.
All we need is the CUDA drivers, libpcap-dev and java. ;-)
Ps. the SELinux was not enabled in JetPack v.3.2.1
In the end you might be doing something requiring root access, but I don’t know…a mailing list for libpcap might be able to provide an exact answer.
The sample rootfs is indeed already just a plain vanilla Ubuntu file system. The “apply_binaries.sh” step (if you do manual flash…which JetPack does automatically if you use JetPack) adds drivers and device tree and so on which is specific to the Jetson. Even so, what it adds is unrelated to most of what you are asking about removing.
If you do a manual install it goes something like this (abbreviated):
- unpack driver package
- go to rootfs and unpack sample rootfs with sudo
- go back to the Linux_for_Tegra directory and with sudo run apply_binaries.sh
- flash
Except for changes to “/boot” actual flash will then use the rootfs directory exactly as it is. If you were to remove a package for libreoffice from the rootfs, then that package would never get installed. The problem is that I don’t know how to tell you to uninstall libreoffice with dpkg tools from the rootfs directory on the host PC, so it this isn’t a practical answer.
What people can do is set up the Jetson the way they want it, and then clone…the clone can be used for flashing instead of rootfs subdirectory when you use the “-r” option to “re-use” the rootfs (you’d place a copy of the clone as “bootloader/system.img” and the clone would become the new rootfs).
Keep the Xorg X server. You need this as an ABI to access the GPU driver (and don’t change the Xorg version…this would change the ABI the GPU driver is bound to). The X server isn’t what gives you the desktop environment, that’s lightdm and login manager and all those desktop applications being told to start…X runs only one program and normally that is a window manager. Take away the window manager and it won’t be a desktop anymore. Take away Xorg, and it also won’t do CUDA from then on. X is the glue you need for many CUDA GPU operations.
When you flash or clone you get both a “.img” and “.img.raw” file…the raw image can be loopback mounted and edited, or used for flash (this is agnostic of whether system.img.raw was generated from a flash or from a clone). The “.img” file is a “sparse” (compressed) file and can only be used for flash…you can’t edit this or view its content. I throw away my sparse file, and although the raw file takes significantly longer to flash, naming it as “system.img” and putting it in “bootloader/” (with “-r” reuse option) works perfectly as a root partition to flash. The raw image can be loopback mounted and updated by rsync from another Jetson at any time you want, e.g., after a package update on a reference Jetson. When the clone is from a Jetson which has had libreoffice and other packages removed any flash using this will also have libreoffice or other packages removed.
Hint: If you use “sha1sum -c /etc/nv_tegra_release” after package changes or updates and all shows “ok”, then your clone should be ok. Check this after any package update as well as before any clone.
linuxdev,
Again thanks a million for your fast reply.
I have now solved the problem. The Java app I was running did not “throw” the right error. Therefore I had not seen that the libjna-java, was missing. The only reason I found out it was missing, was because I created a new Java app the used the JNA bindings to access libpcap in a different way.
So what is needed to fix my problem, is to install libjna-java on the board. When that is done you need to link the ‘.so’ file in ‘/usr/lib/aarch64…/jni/libjnidispatch.so’ with ‘ln -s’ to ‘/usr/lib/jvm/default-java/jre/lib/aarch64/libjnidispatch.so’
That did the trick. I was able to make it work.