I have some Vxworks embedded os and I want to check the netstat.
This is what I tried:
-> inetstatShow
And the output is:
C interp: unknown symbol name 'inetstatShow'.
How can I have netstat command in this?
inetstatShow is provided by netShow library - you need to be sure that your OS configuration includes netShow, or you can dynamically load it using ld.
The lkup function can be used to list symbols that are available to the shell. Try lkup "Show" to list all symbols that include the sub-string "Show" for example.
VxWorks supports netstat command.
-> netstat "-n -a" /* state of sockets */
-> netstat "-n -r" /* routing table */
Related
I am using pySerial and I am running this command using CMD to list available COM ports and displays a COM port number when found:
python -m serial.tools.list_ports
I know that the command line will import the serial module when I use the python -m flag and I can access the objects inside it so it should show the output. However, the same command however does not work when run using the IDLE shell:
import serial
print(serial.tools.list_ports_common)
This returns an error AttributeError: module 'serial' has no attribute 'tools'
Why is it not working at IDLE?
You need to import it first:
from serial.tools import list_ports
list_ports.main() # Same result as python -m serial.tools.list_ports
You can check out the source here
You can simply try connecting to each possible port (COM0...COM255). Then add the ports with successful connections to a list. Here is my example:
import serial
def connectedCOMports ():
allPorts = [] #list of all possible COM ports
for i in range(256):
allPorts.append("COM" + str(i))
ports = [] #a list of COM ports with devices connected
for port in allPorts:
try:
s = serial.Serial(port) #attempt to connect to the device
s.close()
ports.append(port) #if it can connect, add it the the list
except:
pass #if it can't connect, don't add it to the list
return(ports)
print(connectedCOMports())
When I ran this program, it printed ['COM7'] to the console. This represents the ESP32 microcontroller that I connected to my USB port.
I "borrowed" the LPINFOX REXX program from this url: [http://www.longpelaexpertise.com/toolsLPinfoX.php]
When I run it "directly" (EX 'hlq.EXEC(LPINFOX)') it runs fine:
------------------------------------------------------
LPInfo: Information for z/OS ssssssss as of 18 Mar 2021
------------------------------------------------------
z/OS version: 02.04
Sysplex name: LOCAL
JES: JES2 z/OS 2.4 (Node nnnn)
Security Software: RACF
CEC: 3907-Z02 (IBM Z z14 ZR1)
CEC Serial: ssssss
CEC Capacity mmmm MSU
LPAR name: llll
LPAR Capacity mmm`enter code here` MSU
Not running under a z/VM image
But, if I insert the call into another exec, I get a RC -2 from the address LINKPGM call:
------------------------------------------------------
LPInfo: Information for z/OS ssssssss as of 18 Mar 2021
------------------------------------------------------
z/OS version: 02.04
Sysplex name: LOCAL
JES: JES2 z/OS 2.4 (Node N1)
Security Software: RACF
79 - Address Linkpgm 'IWMQVS QVS_Out'
+++ RC(-2) +++
CEC: -
CEC Serial:
LPAR name:
Not running under a z/VM image
I'm sure this has to do with the second level of REXX program running, but what can I do about the error (besides queueing up the EXecution of the second REXX)? I'm also stumped on where this RC is documented...my Google search for "REXX ADDRESS RC -2" comes up short.
Thanks,
Scott
PS(1), per answer from #phunsoft:
Interesting. I didn't copy the code to my other REXX. I invoked LPINFOX from within another rexx: I have a hlq.LOGIN.EXEC that has a "EX 'hlq.LPINFOX.EXEC" statement within it. When I reduce the first exec to "TEST1" (follows), it fails the same way:
/* REXX */
"EXECUTIL TS"
"EX 'FAGEN.LPINFOX.EXEC'"
exit 0
When I run TEST1, this is the output from the EXECUTIL from around the IWMQVS call:
When I run LPINFOX.EXEC directly from the command line, the output is the same, except the address LINKPGM IWMQVS works fine:
I can only surmise that there is some environmental difference when I run the exec "standalone" vs. when I run the exec from another exec.
PS(2), per question about replacing IWMQVS with IEFBR14 from phunsoft:
Changing the program to IEFBR14 doesn't change the result, RC=-2.
LINKPGM is a TSO/E REXX host command environment, so you need to search in the TSO/E REXX Reference. From that book:
Additionally, for the LINKMVS, ATTCHMVS, LINKPGM, and ATTCHPGM
environments, the return code set in RC may be -2, which indicates that processing
of the variables was not successful. Variable processing may have been
unsuccessful because the host command environment could not:
o Perform variable substitution before linking to or attaching the program
o Update the variables after the program completed
Difficult to say what th problem is without seeing the code.
You may want to use REXX's trace feature to debug. Do you run this REXX from TSO/E foreground? If so, you might run TSO EXECUTIL TS just before you start that REXX. It will then run as if trace ?i wa specified as the fist line of the code.
I've had look at the LPINFOX EXEC and saw that variable QVS_Out is set as follows just before linking to IWMQVS:
QVS_Outlen = 500 /* Output area length */
QVS_Outlenx = Right(x2c(d2x(QVS_Outlen)),4,d2c(0))
/* Get length as fullword */
QVS_Out = QVS_Outlenx || Copies('00'X,QVS_Outlen-4)
Did you do this also when you copied the call to your other REXX?
I'm using cdb with the sosex extension. Everything seems to be working fine except that I am unable to get any !mbp breakpoints to to resolve and !mu/!muf don't show source info.
Got going with the following commands:
.lines
sxe ld:clrjit
g
.loadby sos clr
.cordll -ve -u -l
.load c:\blah\sosex.dll
sxe ld:myassembly.dll
ld myassembly
!mbm myassembly!myfunction
g
It then hits the function I'm interested in and breaks. However !mu doesn't show any source info, only IL and native.
I verified that the symbols, including source lines info, were loaded by doing:
? `myassembly!c:\blah\whatevs.cs:20`
which prints out a correct offset.
SOSEX version is the latest from stevestechspot. Running against .NET Framework 4.7.3. cdb and sosex both x64.
Source file locations on the machine match those in the PDB file.
UPDATE
Having the same problem with SOS. IP2MD doesn't show the source line.
I debugged through sos.dll, and it correctly translated the native address to an IL address and passed the resulting IL address to a function in dbgeng, DebugClient::GetLineByOffset(). However this returned E_FAIL, which from the disassembly it appears hardcoded to do.
So it looks like SOS relies on something that is no longer implemented in the debugger engine to get the source line from the IL offset.
Reported: https://developercommunity.visualstudio.com/content/problem/414350/sos-debugger-extension-for-windbg-cant-find-source.html
Was told to report it as a WDK issue - raised here:
https://social.msdn.microsoft.com/Forums/en-US/2f9d4bbe-8322-4e8d-883a-e40d19f21209/sos-debugger-extension-for-windbg-cant-find-source-lines?forum=wdk
In a device driver source in the Linux tree, I saw dev_dbg(...) and dev_err(...), where do I find the logged message?
One reference suggest to add #define DEBUG . The other reference involves dynamic debug and debugfs, and I got lost.
dev_dbg() expands to dynamic_dev_dbg(), dev_printk(), or no-op depending on the compilation flags.
#if defined(CONFIG_DYNAMIC_DEBUG)
#define dev_dbg(dev, format, ...) \
do { \
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
} while (0)
#elif defined(DEBUG)
#define dev_dbg(dev, format, arg...) \
dev_printk(KERN_DEBUG, dev, format, ##arg)
#else
#define dev_dbg(dev, format, arg...) \
({ \
if (0) \
dev_printk(KERN_DEBUG, dev, format, ##arg); \
})
#endif
dynamic_dev_dbg() and dev_printk() call dev_printk_emit() which calls vprintk_emit().
This very same function is called in a normal mode when you just do a printk(). Just note here, that the rest functions like dev_err() will end up in the same function.
Thus, obviously, the buffer is all the same, i.e. kernel intrenal buffer.
The logged message at the end is printed to
Current console if kernel loglevel value (can be changed via kernel command line or via procfs) is high enough for certain message, here KERN_DEBUG.
Internal buffer which can be read by running dmesg command.
Note, data in 2 is kept as long as there still room in the buffer. Since it's limited and circular, newer data preempts old one.
Additional information how to enable Dynamic Debug.
First of all, be sure you have CONFIG_DYNAMIC_DEBUG=y in the kernel configuration.
Assume we would like to enable all debug prints in the built-in module with name 8250. To achieve that we simple add to the kernel command line the following 8250.dyndbg=+p.
If the same driver is compiled as loadable module we may either add options 8250 dyndbg to the modprobe configuration or to the shell command line when do it manually, like modprobe 8250 dyndbg.
More details are described in the Dynamic Debug documentation.
The "How certain debug prints are automatically enabled in linux kernel?" raises the question why some debug prints are automatically enabled and how DEBUG affects that when CONFIG_DYNAMIC_DEBUG=y. The answer is lying in the dynamic_debug.h and since it's used during compilation the _DPRINTK_FLAGS_DEFAULT defines the certain message appearence.
#if defined DEBUG
#define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
#else
#define _DPRINTK_FLAGS_DEFAULT 0
#endif
you can find dev_err(...) in kernel messages. As the name implies, dev_err(...) messages are error messages, so they will definitely be printed if the execution comes to that point. dev_dbg(...) are debug messages which are more generously used in the kernel driver code and they are not printed by default. So everything you have read about dynamic_debugging comes into play with dev_dbg(...).
There are several pre-conditions to have dynamic debugging working, below 1. and 2. are general preconditions for dynamic debugging. 3. and later are for your particular driver/module/subsystem and can be .
Dynamic debugging support has to be in your kernel config CONFIG_DYNAMIC_DEBUG=y. You may check if it is the case zgrep DYNAMIC_DEBUG /proc/config.gz
debugfs has to be mounted. You can check with sudo mount | grep debugfs and if not existing, you can mount with sudo mount -t debugfs /sys/kernel/debug
refer to dynamic_debugging and enable the particular file/function/line you are interested
Hi I want to make the snort 2.9.4 run on the mips-linux based devices, so I cross compile the snort and all the supportive packages.
I use the option --disable-static-daq when I configure snort because I dont want to utilize all the daq modes. What i need is just the afpacket mode.
When the cross compiling is OK, i move daq_afpacket.so, libsfbpf.so.0.0.1, libdaq.so.2.0.0, libdnet.1.0.1, libpcre.so.0.0.1, libpcap.so.1 to the target device's /usr/lib directory. And the binary snort is moved into target device's /bin directory.
Then i run the snort like this:
/bin/snort -vde --daq afpacket --daq-dir /usr/lib
The output shows:
Running in packet dump mode
--== Initializing Snort ==--
Initializing Output Plugins!
/usr/lib/daq_afpacket.so: dlopen: File not found
segmentation fault
If I run snort like this:
# /bin/snort -vde --daq afpacket
Running in packet dump mode
== Initializing Snort =
Initializing Output Plugins!
ERROR: Can't find afpacket DAQ!
Fatal Error, Quitting..
Do you know what i miss here?
let me answer it myself:
the daq_afpacket.so is depent on the libsfbpf.so.0, which is a symbol link to the so libsfbpf.so.0.0.1. Then i have to copy the libsfbpf.so.0.0.1 into /usr/lib and create the symobl link to it.
after that, snort can be started like:
/bin/snort -vde --daq afpacket --daq-dir /usr/lib --daq-var buffer_size_mb=2 -i eth0 &