JpCapWriter crashes JVM - crash

When I try to use JpCap Writer to save packets to a file, it causes JVM to crash.
Code:
captor=JpcapCaptor.openDevice(interfaceList[interfaceNumber], 65535, true, 20);
captor.setFilter("ip and tcp",true);
JpcapWriter writer=JpcapWriter.openDumpFile(captor,"write.txt");
for(int i=0;i<10;i++){
Packet packet=captor.getPacket();
writer.writePacket(packet);
}
writer.close();
Crash info:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f283105953a, pid=3060, tid=139810797537024
#
# JRE version: 6.0_24-b24
# Java VM: OpenJDK 64-Bit Server VM (20.0-b12 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.11.4
# Distribution: Ubuntu 12.04 LTS, package 6b24-1.11.4-1ubuntu0.12.04.1
# Problematic frame:
# v ~BufferBlob::jni_fast_GetLongField
#
# An error report file with more information is saved as:
# /root/workspace/Sniff/hs_err_pid3060.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Any idea how to solve it? Or any other alternative way to save packets in TCPDump format?

I saw your comment on my question. I had this same problem and it was caused when I tried to close the writer after it had already been closed. You might be closing it unknowingly. Check your code, and also see what effect removing writer.close(); has for you.
If you don't need to manipulate the packets, I would recommend using Wireshark. It makes it very easy to capture packets as TCPDumps and add capture filters.

Related

Python on M1 MBP trying to connect to USB devices - NoBackendError: No backend available

I am trying to connect with Python to my USB devices.
The final result should be a connection to my Blood Pressure Monitor but I am failing already to connect to ANY device.
My simple code - which I found here - is bellow. The Product- and Vendor ID I got from Apple Menu > About this Mac > System Information
import usb.core
import usb.util
# find our device
dev = usb.core.find(idVendor=0x0781, idProduct=0x55a4)
# was it found?
if dev is None:
raise ValueError('Device not found')
# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()
# get an endpoint instance
cfg = dev.get_active_configuration()
intf = cfg[(0,0)]
ep = usb.util.find_descriptor(
intf,
# match the first OUT endpoint
custom_match = \
lambda e: \
usb.util.endpoint_direction(e.bEndpointAddress) == \
usb.util.ENDPOINT_OUT)
assert ep is not None
# write the data
ep.write('test')
But I get always NoBackendError: No backend available from dev = usb.core.find(idVendor=0x0781, idProduct=0x55a4)
For the connection I installed pyusb in my Python env and with Homebrew libusb on my mac.
I have no clue how to get a connection or even a simple list via iteration with all my connected Product- and Vendor IDs.
This error is to be expected if pyusb cannot find the dynamic libraries of libusb.
Installing libusb with Homebrew is not sufficient. Homebrew puts the relevant files in /opt/homebrew/Cellar/libusb/1.0.24/lib and creates symbolic links in /opt/homebrew/lib. But pyusb is not aware of these paths.
You have two main options:
Add /opt/homebrew/lib to the environment variable DYLD_LIBRARY_PATH. For a permanent setup, add it to ~/.zshenv:
export DYLD_LIBRARY_PATH="/opt/homebrew/lib:$DYLD_LIBRARY_PATH"
Create a symbolic link in your home directory. This takes advantage of the fact that ~/lib is a default fallback path for libraries:
ln -s /opt/homebrew/lib ~/lib

How to automate CentOS7 minimal kickstart installation using OEMDRV volume?

I'm trying to automate the installation process of CentOS7 minimal in VirtualBox. Kickstart file is the solution. I find putting ks.cfg file into OEMDRV.vhdm disk and mounting it to VM memory the easiest way to give the VM access to the configuration file.
Anaconda reads ks.cfg file, as it pointed out mistake in spelling, but once the file is properly written the VM runs an error, same happens if the ks.cfg file is empty:
The I/O cache encountered an error while updating data in medium "ahci-
0-1" (rc=VERR_ACCESS_DENIED). Make sure there is enough free space on the
disk and that the disk is working properly. Operation can be resumed
afterwards.
The host is Windows 10, below is my ks.cfg file. The file is taken of already existing centOS7 minimal VM.
#version=DEVEL
# System authorization information
auth --enableshadow --passalgo=sha512
# Use CDROM installation media
cdrom
# Use cmdline/text/graphical install
graphical
# Run the Setup Agent on first boot
firstboot --enable
ignoredisk --only-use=sda
# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
# System language
lang en_US.UTF-8
# Network information
network --bootproto=dhcp --device=enp0s3 --ipv6=auto --activate
network --hostname=localhost.localdomain
# Root password #working on --isctrypted rootpw
rootpw --iscrypted $6$6eqrvzKwp2ST4PMi$VUqUy8G/AsbaZK9XbtqlQcSIZjZ7QQk5yFqe5h/91YwM3GI3PjxEASc062EFPgGjvsmMxcLuKvx8d69KLplYJ1
# System services
services --disabled="chronyd"
# System timezone
timezone Europe/Warsaw --isUtc --nontp
# User
user --groups=wheel --name=secutest --password=$6$Ct923BcyZG.13TR2$jEUcu5tlvncoejaWa9eof.5GL1oU3wLVe0zEWLDrpKY6oXJhGeV4CRvoiYfFeC1IpkPeaXc1z912E3HdvOS/t/ --iscrypted --gecos="secutest"
# System bootloader configuration
bootloader --append=" crashkernel=auto" --location=mbr --boot-drive=sda
%packages
#^minimal
#core
kexec-tools
%end
%addon com_redhat_kdump --enable --reserve-mb='auto'
%end
%anaconda
pwpolicy root --minlen=6 --minquality=1 --notstrict --nochanges --notempty
pwpolicy user --minlen=6 --minquality=1 --notstrict --nochanges --emptyok
pwpolicy luks --minlen=6 --minquality=1 --notstrict --nochanges --notempty
%end
reboot
The solution is to use OEMDRV.iso, ISO disk type. Next OEMDRV disk has to be mounted to VM's SATA controller.
This command creates OEMDV.iso file with volume labeled 'OEMDRV' out of folder, which is exactly what we need.
$ mkisofs -V OEMDRV -o OEMDRV.iso path/to/directory

Can we single step QEMU using libvert

I am developing a peripheral hardware and want to use QEMU to test it.
The plan is to run the device driver in QEMU and use libvert (or something else?) to interface the VM with a python based simulation model of the peripheral.
I aware that QEMU can be single stepped via GDB, but I am looking at a python approach to do the following.
Wait for a write to a specific memory location.
Suspend QEMU
Run some background task in the host.
Run QEMU for N Cycles.
Write to a memory location
Continue
Is this possible with libvert or any other toolkit?
I needed to do something similar, and came across two approaches:
Run Python in GDB, using a python script of the commands
Use a Python API to GDB like pygdbmi
The latter ended up being more flexible, so I'll explain those steps here.
Configure qemu with debugging information:
./configure --enable-debug
Build qemu and invoke it halted, with debug hooks:
make
sudo make install
qemu-system-x86_64 -S -s
Now, use a Python script to attach to and interact with qemu via pygdbmi(instructions here):
from pygdbmi.gdbcontroller import GdbController
from pprint import pprint
# Start gdb process
gdbmi = GdbController()
print(gdbmi.get_subprocess_cmd()) # print actual command run as subprocess
gdbmi.write('target remote localhost:1234'); # attach to QEMU GDB socket
pprint(response)
response = gdbmi.write('-break-insert main') # machine interface (MI) commands start with a '-'
response = gdbmi.write('break main') # normal gdb commands work too, but the return value is slightly different
response = gdbmi.write('-exec-run')
response = gdbmi.write('run')
response = gdbmi.write('-exec-next', timeout_sec=0.1) # the wait time can be modified from the default of 1 second
response = gdbmi.write('next')
response = gdbmi.write('next', raise_error_on_timeout=False)
response = gdbmi.write('next', raise_error_on_timeout=True, timeout_sec=0.01)
response = gdbmi.write('-exec-continue')
response = gdbmi.send_signal_to_gdb('SIGKILL') # name of signal is okay
response = gdbmi.send_signal_to_gdb(2) # value of signal is okay too
response = gdbmi.interrupt_gdb() # sends SIGINT to gdb
response = gdbmi.write('si 20') # step 20 instructions
response = gdbmi.write('continue')
response = gdbmi.exit()
If you have trouble with kernel symbols, you might also need to issue a command 'file myKernel' to load the symbol table from that file, assuming it was compiled with debugging information.
For reference, the '-s' command adds GDB hooks at localhost:1234. So the first command you issue must direct gdb to look there:
gdbmi.write('target remote localhost:1234');

Openshift for Play: The remote end hung up unexpectedly

I am trying to launch a play project in openshift. The first phase which was nearly 15% of the project was successfully completed and uploaded. So, I guess the initial configuration was okay. Now, after I completed nearly the rest of the project, then when I am trying to push the project using ssh, everytime after a certain time the remote server hangs up with the following message.
remote: [info] Done packaging.
remote: model contains 69 documentable templates
Connection to blogofprime-thatsqt.rhcloud.com closed by remote host.
fatal: The remote end hung up unexpectedly
error: error in sideband demultiplexer
To ssh://5455ef32e0b8cd379e000293#blogofprime-thatsqt.rhcloud.com/~/git/blogofprime.git/
+ 557ec12...4034b71 HEAD -> master (forced update)
Every-time after a certain step remote server hangs up.
My openshift.conf file:
# This is the main configuration file for the application.
# ~~~~~
include "application"
# Secret key
# ~~~~~
# The secret key is used to secure cryptographics functions.
# If you deploy your application to several instances be sure to use the same key!
application.secret="V0sLX<RAciXw_>7^O8y=I4BRW/M4#vhVhF=H44`lMfgAV2hs^Pp?tsfroKt1J3eX"
# The application languages
# ~~~~~
application.langs="en"
# Database configuration
# ~~~~~
# You can declare as many datasources as you want.
# By convention, the default datasource is named `default`
#
db.default.driver=com.mysql.jdbc.Driver
db.default.url="jdbc:mysql://"${OPENSHIFT_MYSQL_DB_HOST}":"${OPENSHIFT_MYSQL_DB_PORT}"/"${OPENSHIFT_APP_NAME}
db.default.user=${OPENSHIFT_MYSQL_DB_USERNAME}
db.default.password=${OPENSHIFT_MYSQL_DB_PASSWORD}
# Evolutions
# ~~~~~
# You can disable evolutions if needed
# evolutionplugin=disabled
# Ebean configuration
# ~~~~~
# You can declare as many Ebean servers as you want.
# By convention, the default server is named `default`
#
ebean.default="models.*"
# Logger
# ~~~~~
# You can also configure logback (http://logback.qos.ch/), by providing a logger.xml file in the conf directory .
# Root logger:
logger.root=ERROR
# Logger used by the framework:
logger.play=INFO
# Logger provided to your application:
logger.application=DEBUG
My build.sbt file:
name := "thatsqt"
version := "1.0-SNAPSHOT"
scalaVersion := "2.11.2" // or "2.10.4"
libraryDependencies ++= Seq(
// Select Play modules
jdbc, // The JDBC connection pool and the play.api.db API
//anorm, // Scala RDBMS Library
javaJdbc, // Java database API
javaEbean, // Java Ebean plugin
javaJpa, // Java JPA plugin
filters, // A set of built-in filters
javaCore, // The core Java API
// WebJars pull in client-side web librarie
"org.webjars" %% "webjars-play" % "2.3.0",
"com.typesafe.play" %% "play-slick" % "0.8.0",
// Add your own project dependencies in the form:
// "group" % "artifact" % "version"
"mysql" % "mysql-connector-java" % "5.1.27"
)
fork in Test := false
lazy val root = (project in file(".")).enablePlugins(PlayJava)
EclipseKeys.withSource := true
Platform:
I am using Mac OS X and typesafe activator for play framework.
What I tried:
I tried to unset TMOUT in both server and client. At this point I am not very sure whether this is a timeout problem or something else.
My project Link: https://github.com/magurmach/PlayOpenshiftThatsQt
How can I solve this problem?
If the problem started occurring recently, it may be caused by exceeded quota.
It's very common to run out of space using 1GB small gears.
Try using rhc app-tidy rhc command:
rhc app-tidy <app>
Does your project include large binary files? This can cause git to take up a lot of RAM server-side, and a small Openshift gear will kill things that take too much RAM. The solution is to ssh into your Openshift box (using "rhc ssh" or equivalent) and tell the server-side git to limit its RAM use:
cd git/*.git
git config pack.windowMemory "25m"
git config pack.packSizeLimit "25m"
git config pack.threads "1"
and why they didn't do that by default I have no idea.
Also, next time you want to put large binary files into your project, you don't have to check them into the git repository (which will take up space tracking their entire history): you could just instruct your app to download them from another server as needed (the second server needs only the ability to host static files).

No debugging data in vmlinux when running crash to analyze kernel panic

I'm trying to analyze a Linux kernel panic on openSUSE 11.3 using kdump and the crash utility. The system is successfully creating the vmcore file, but when I go to analyze it, crash complains about the lack of symbols.
# crash -s vmlinux-2.6.34-12-desktop.gz vmcore
crash: vmlinux-2.6.34-12-desktop.gz: no debugging data available
crash: vmlinux-2.6.34-12-desktop.debug: debuginfo file not found
crash: either install the appropriate kernel debuginfo package, or
copy vmlinux-2.6.34-12-desktop.debug to this machine
The system is running a stock desktop kernel
# uname -r
2.6.34-12-desktop
and has the kernel-devel and kernel-desktop-devel packages installed. Does some other package have the debug symbols (similar to Red Hat's kernel-debuginfo rpm) or is there another approach / kernel I should be using?
The symbols for openSUSE are named similarly to Red Hat and variants (CentOS, Fedora, ...) but live in a different repository. For this example, the vmlinux symbols are in the kernel-desktop-devel-debuginfo package, but practically, you'd probably also want to grab the kernel-desktop-debuginfo for the module symbols.
Load the "kernel-debug-devel" package for your kernel.