I want to see statistics for each protocol (TCP/UDP) on my Linux Yocto. I try use netstat -s command (http://www.thegeekstuff.com/2010/03/netstat-command-examples/).
But i receive error netstat:invalid option -- 's'. It is because BusyBox's netstat version doesn't contain the -s option.
Is it possible to install "normal" netstat?
I try to install nettools (which includes netstat) using opkg install, but package manager can't find it.
I also try to compile and install net-tools source from here - https://sourceforge.net/projects/net-tools/, but i receive error during installation.
Maybee i can download package from here: rpmfind.net ?
Is it possible to see statistic without using netstat? (i need information, which command netstat -s returns)
(Example of netstat -s output:
udp:
71208 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
0 with no checksum
832 dropped due to no socket
16 broadcast/multicast datagrams dropped due to no socket
1971 dropped due to full socket buffers
0 not for hashed pcb
68389 delivered
137685 datagrams output
)
the last netstat release is super old. you should build it straight out of git instead (don't worry, we try to keep it sane at all times). use the "Download Snapshot" link in the online git browser.
that said, have you seen the iproute2 project ? it includes tools like nstat and generally preferred over net-tools when it comes to scripting.
Related
installed TigerVNC on Centos 8.3 and tried to run it with vncserver Command but it is giving me this message "vncserver has been replaced by a systemd unit."
I have also followed the instruction from this file /usr/share/doc/tigervnc/HOWTO.md and created a vnc session. the session is accessible only on loopback ip of the machine.
Result of : netstat -tulpn Command:
tcp 0 0 127.0.0.1:5905 0.0.0.0:* LISTEN 2645/Xvnc
tcp6 0 0 ::1:5905 :::* LISTEN 2645/Xvnc
how can i change loopback ip of vnc session to machine ip.
Minhaj:
I ran into this today. TigerVNC has been changed with the version 8.x Fedora kernel. I dug a bit & found it is related to "an upstream decision." What this means in simple English is that the project team made a design decision. I personally agree with the design changes since it brings greater control and security to VCN than previous versions. This is not to suggest the actual VNC protocol is SSL enabled. You should still employ best practices like using firewalld to prevent access to VCN ports and using SSH tunneling to get to the console, etc.
To get started, you'll need to do a bit of simple configuration work as described in /usr/share/doc/tigervnc/HOWTO.md. Start by reading the instructions in the file.
All tasks must be run with root priv, so use the sudo utility for all of them.
TASK 1: At the simplest level, begin by opening the file /etc/tigervnc/vncserver.users
Create an entry for each user that will use the service. For example:
:1=hwojteczko
:2=esong
Note the digit preceding each user name. This is the VNC console number that will be assigned to each user. Save the file.
TASK 2: Inspect the /usr/share/xsessions file to confirm the type of desktop installed on the system. The default desktop is gnome, but there are others, so be mindful of this.
TASK 3: Next, you'll need to modify the Xvnc options file. Fortunately, there are some commented entries already left in place, which can be removed. Open the file /etc/tigervnc/vncserver-config-defaults, remove the comments as shown below, but also add the desktop to the session config within the stanza. This will not likely be there, so it is easy to miss this step. See example below:
securitytypes=vncauth,tlsvnc
desktop=sandbox
geometry=2000x1200
localhost
alwaysshared
session=gnome
TASK 4: As the user, set a VNC password using vncpasswd . This will be similar to what you are accustomed to with previous versions of TigerVNC, but it WILL NOT start TigerVNC.
IMPORTANT: For the next task, you must make sure that you, or the user, is not logged into a desktop session. For those like me who develop code on Linux, this is an easy way to get tripped up. This is not a concern if you are accessing a remote server.
TASK 5: Start the VNC Service for the correct user session. See below:
systemctl start vncserver#:1
You'll see there is no output to speak of. Use sysctl and check the status. It is best to wait about 10-15 seconds before doing so to ensure the startup does not fail.
systemctl status vncserver#:1
TASK 6: Now, you can check to see that port 5901 is open with nmap, as in:
nmap -PN localhost
Which should report something like:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
631/tcp open ipp
5901/tcp open vnc-1
now you can ssh to the host and tunnel VNC traffic securely, such as:
ssh hwojteczko#172.16.129.5 -N -L localhost:5901:localhost:5901
TASK 7: When you are done, don't forget to shutdown TigerVCN using systemctl, as in:
systemctl stop vncserver#:1
Happy coding......
h
Trying to upload a code to arduino, but whether in the Arduino IDE or Arduino Create, both return this erro while uploading. Running on Linux Tara(mint 19 cinnamon).
./opt/arduino-builder/arduino-builder -compile -core-api-version 10611 -hardware opt/arduino-builder/hardware -hardware ./opt/cores -tools opt/arduino-builder/tools -tools ./opt/tools -built-in-libraries opt/libraries/latest -logger humantags -fqbn arduino:avr:mega:cpu=atmega2560 -build-cache /tmp -build-path /tmp/716441957/build -verbose -libraries /tmp/716441957/custom -libraries /tmp/716441957/pinned /tmp/716441957/sketch_oct8a
Sketch uses 8280 bytes (3%) of program storage space. Maximum is 253952 bytes.
Global variables use 443 bytes (5%) of dynamic memory, leaving 7749 bytes for local variables. Maximum is 8192 bytes.
Programming with: Serial
Flashing with command:/home/jesus/.arduino-create/arduino/avrdude/6.3.0-arduino9/bin/avrdude -C/home/jesus/.arduino-create/arduino/avrdude/6.3.0-arduino9/etc/avrdude.conf -q -q -patmega2560 -cwiring -P/dev/ttyACM0 -b115200 -D -Uflash:w:/tmp/arduino-create-agent734074237/sketch_oct8a.hex:i
avrdude: ser_open(): can't open device "/dev/ttyACM0": Permission denied
ioctl("TIOCMGET"): Inappropriate ioctl for device
ioctl("TIOCMGET"): Inappropriate ioctl for device
1#
First, check the port in your IDE. In Arduino tools->port
If the port is hidden or you can not move the cursor over this then run this commands in your terminal.If everything ok then skips this and follow the second part.
sudo apt-get install librxtx-java -y
sudo usermod -aG dialout $USER
sudo apt-get install gnome-system-tools
2#
After this again check the first method. If it is not working then run this commands
ls -l /dev/ttyACM*
sudo usermod -a -G dialout <username>
You probably have another program running which is already using this port.
You should close most other programs like putty or another serial monitor app.
Otherwise, try to reconnect the Arduino to the PC.
I know that these ideas below come from using a Teensy, but they may help you.
Sometimes there are the ACM* ports listed in the Arduino IDE. Try looking at the ser ports. I know when I am running my Teensy, sometimes I have them switched and need to select the correct one.
Also, from my experience with the Teensy, you might need to add a udev rule to allow permissions to access the port from non-root user. Here is the link that shows the udev file.
There is no direct way to solve this issue. In addition to it, you are not using an IDE. I will list the things you need to check, I am sure this will solve your problem.
I am not good at Linux environment so I will refer to applications names as window, you go the corresponding application in Linux.
Go to linux device manager and see for your arduino board. It should have proper naming like "arduino uno at port 3", then use the correct port in your command. If this name does not come properly then it means Driver is not available in your machine. So, go to step2.
Find the driver online and install it in your system, I am not sure about the support of linux with arduino, once it is done please repeat step1.
So, I conclude in short that you do not have the proper driver (which is strongly believe) or pointing the wrong port. I am not an expert with the udev rules, but it is definitely an issue you can experience with these kinds of micro-controllers.
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Working with Ubuntu 18.04 Server LTS. I am trying to find a way to check the DNS IP(s) that is actually being used when set via DHCP. The resolv.conf only will point to 127.0.0.53 now. /etc/systemd/network folder is empty. The NSLOOKUP output also always references the internal 127.0.0.53 IP. Seems all the old tricks aren't working.
The Ubuntu documentation is not updated yet as it still looks like the help for 16.04 referencing eth0, ifup and ifdown which are all deprecated on 18: https://help.ubuntu.com/lts/serverguide/network-configuration.html
I've tried setting a static adapter setup with Netplan via a custom .yaml. The settings work fine but I can't seem to find the DNS IP that I set anywhere. I expect it will be consistent between DHCP and static settings but I'm not sure where to look now.
I would settle for either a C library call or a bash CLI method at this point. Does anyone have a way to check this on 18.04 Server?
I found the following showed my the DNS servers by adapter towards the end of the output:
systemd-resolve --status
It contains a list under 'DNS Servers' organized by Link. I think this has changed from previous versions with Ubuntu. It will take a little text parsing work but this gives me what I'm after.
Another way is:
cat /run/systemd/resolve/resolv.conf
That file is dynamically generated by systemd-resolved, but contains the actual DNS servers instead of 127.0.0.53.
In fact, if you want make that the default for /etc/resolv.conf, you simply create symlink for it. (/etc/resolv.conf is a symlink that points to /run/systemd/resolve/stub-resolv.conf by default):
sudo mv /etc/resolv.conf /etc/resolv.conf.orig
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
Sample /run/systemd/resolve/resolv.conf :
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 10.1.2.3
search host.domain.com
For more info:
http://manpages.ubuntu.com/manpages/bionic/man8/systemd-resolved.service.8.html
You can also use:
nmcli dev show eth0
Replace eth0 with your network interface to see how it was configured. If you got the DNS address over DHCP, you should see it here.
I'm running ubuntu 22.04.
sudo nmcli dev show <interface> didn't have any dns listings, but sudo resolvectl status <interface> showed me the current dns server.
I am suprised at this too. I am running Ubuntu 16.04 LTS and see something similar.
If you issue a
dig www.google.ca +trace | grep 'Received'
The first host in the response is the one doing the lookups for your server.
$ dig www.google.ca +trace | grep 'Received'
;; Received 525 bytes from 127.0.1.1#53(127.0.1.1) in 19 ms
;; Received 42 bytes from 199.7.91.13#53(d.root-servers.net) in 32 ms
This means that this box is doing it's own dns lookups directly to the root servers and following the path recursively to get my dns lookups.
Found the issue is that dnsmasq is enabled. To disable it do as follows.
edit the NetworkManager.conf file
sudo gedit /etc/NetworkManager/NetworkManager.conf
comment out the dnsmasq line
#dns=dnsmasq
restart the network-manager service
sudo /etc/init.d/network-manager restart
then verify that it is using the dns-server assigned via dhcp
$ dig www.google.ca +trace | grep 'Received'
;; Received 525 bytes from 192.168.30.1#53(192.168.30.1) in 18 ms
;; Received 42 bytes from 198.41.0.4#53(a.root-servers.net) in 32 ms
I want to obtain information about the account balance of a SIM card I have installed in a mobile broadband modem in my computer. For my mobile network operator, this works using the USSD code 100#.
I found that gammu can send that USSD code using gammu getussd '100#'. In response, gammu shows me this USSD menu:
Press Ctrl+C to break...
USSD received
Status : Action needed
Service reply : "Reply with your option:
1.Account Balance
2.Buy a Data Plan
3.Top Up Now
No response in specified timeout. Probably phone not connected.
How can select an option from that menu (like, 1)?
It seems to me that ModemManager (and its command line client interface mmcli) is currently the most sophisticated, highest-quality solution for interacting with USSD and USSD menus under Linux.
Installation (under Debian / Ubuntu Linux):
sudo apt-get install modemmanager modem-manager-gui
Usage (following the manpage):
Listing your modems: mmcli -L. This will show a modem device path like /org/freedesktop/ModemManager1/Modem/12 and you can use the number at its end to specify the modem to use after the -m option in the following commands.
Showing attributes of your modem: mmcli -m 12.
Enabling the modem (needed before using it for USSD): mmcli -m 12 -e
Starting a USSD session. For example, for Ncell this command shows the main USSD menu: mmcli -m 12 --3gpp-ussd-initiate="*100#"
Responding to a USSD menu. After the session is started, you may use a command like this to respond, here using option 1: mmcli -m 12 --3gpp-ussd-respond="1"
Canceling the USSD session on the given modem: mmcli -m 12 --3gpp-ussd-cancel.
Obtaining the status of all USSD sessions (of all available modems): mmcli --3gpp-ussd-status.
With most hardware, this should work properly and immediately as described.
(With my hardware however, I could not use mmcli so far due to a bug. All USSD related commands in mmcli would reply error: modem not unlocked yet, and mmcli -m 12 | grep " lock" would show that the sim-pin2 lock is enabled. But it is not (means I could not get past this by disabling the lock). And even if it would be enabled, that lock would not limit USSD usage (it's rather just meant for limiting outgoing calls to certain numbers). So, I'll have to remove this overzealous test condition from here, compile it myself and test again … .)
The Linux command line tool gsm-ussd has support for USSD sessions that will allow you to answer to USSD menus. For detailed installation and configuration instructions see here. The version 0.4 Debian package offered there for installation is the latest dev branch version.
However, the support for this is not yet stable [source]. At least for me, it does not work. With different hardware and / or mobile network operators, you might have more luck.
The way it is meant to be used is like this (using Ncell as example):
$ gsm-ussd -m /dev/ttyUSB1 "*100#"
USSD session open, to cancel use "gsm-ussd -c".
1 Account
2 Services operations
3 Offices information
4 How to call Call Center
5 Change password
Note:
Back:* Top:#
To reply and select an option, you would send something like:
$ gsm-ussd -m /dev/ttyUSB1 "1"
To end the session and return back to normal single-command USSD mode, you would execute gsm-ussd -c. More complete documentation is here.
I found that I can successfully navigate USSD menus with AT commands directly. Given my system's issues with the otherwise preferable mmcli solution (see my other answer for details), this is so far the only working solution to navigate USSD for me.
How to get this to work:
(1) Install an AT terminal. I chose atinout to communicate with the modem via AT commands. You can also use any other AT terminal software like putty, minicom etc.. To install atinout:
sudo apt-get install ruby-ronn;
git clone git://git.code.sf.net/p/atinout/code atinout;
cd atinout;
make;
sudo checkinstall make install;
(2) If you use ModemManager (which is the default under Ubuntu Linux), you might have to disable it first to allow atinout to access your modem:
sudo stop modemmanager;
(3) Now, to receive and reply to an USSD menu, you would use a command like this:
atinout - /dev/ttyUSB1 - < <(echo "AT+CUSD=1,\"100#\",15") && sleep 4 && \
atinout - /dev/ttyUSB1 - < <(echo "AT") && \
\
atinout - /dev/ttyUSB1 - < <(echo "AT+CUSD=1,\"1\",15") && sleep 4 && \
atinout - /dev/ttyUSB1 - < <(echo "AT");
This assumes your modem is at /dev/ttyUSB1 and the code to receive the USSD menu is 100#. Adapt to your situation.
Explanation: The command sends 100# to the network to receive the USSD menu, and then 1 to choose the first option. Spreading one USSD menu session over multiple atinout calls like this does not break the session if you don't exceed the timeouts (which are usually >20s).
Troubleshooting: If the above all-in-one command does not work, try executing the individual parts manually, repeating those that fail. If something fails repeatedly ("resource busy" etc.), your modem might be in a strange state. Reset it, or just let the computer go through a suspend / resume cycle.
It's currently not possible with Gammu command line, but you can use simple Python script using python-gammu: https://github.com/gammu/python-gammu/blob/master/examples/service_numbers.py
The answer from the link below worked great for me.
You can add the modemmanager PPA and update your apt. There's a bug mentioned in the link for some usb modems, but that has been fixed with the update
sudo add-apt-repository ppa:aleksander-m/modemmanager-xenial<br>
sudo apt-get update
Then follow this: https://stackoverflow.com/a/31864567/6161579
Thanks #tanius
I am debugging an SNMP trap problem using tshark (TShark 1.6.6) on a Linux platform. (The target platform does not support the wireshark GUI.) OIDs in PDUs are shown in numerical format even though I have MIBs installed in /usr/share/snmp/mibs with a link to that in /usr/local/share/mibs. I tried -V. There doesn't appear to be a tshark verbose or debugging option except for some memory debugging options. I have checked the man page and find nothing on SNMP or MIBs. I tried strace and I found a file /usr/share/wireshark/oid file but when I put the MIB directory there, I get a flex error, and a google search for what this mysterious file means turns up nothing. I can copy and paste the OIDs into an snmptranslate command and it correctly translates them. I tried creating a ~/.wireshark directory with smi_modules and smi_paths ("/usr/share/snmp/mibs"). I did a tshark -G currentprefs to see if there was a relevant preference but there isn't. I have googled this issue but I get way too much chaff to make any progress. I checked unix.stackexchange.com, superuser.com, and this site. I verified that people ask wireshark questions on this site (10,000 of them) to make sure it was on topic.
Example invocation:
tshark -R "snmp && ip.dst==<nms_ip>" -i eth0
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
4.675952 <agent_ip> -> <nms_ip> SNMP 115 sNMPv2-Trap 1.3.6.1.2.1.1.3.0 1.3.6.1.6.3.1.1.4.1.0
Contents of ~/.wireshark/preferences:
name_resolve: mtC
name_resolve_load_smi_modules: TRUE
snmp.display_oid: TRUE
snmp.desegment: TRUE
snmp.var_in_tree: TRUE
How do I get the OIDs to be displayed in symbolic format, e.g. sysUpTimeInstance and snmpTrapOID.0?
I found the information Resolving SNMP OID in snmpbulkwalk and tshark useful.
Adding my MIBs to ~/.wireshark/smi_modules (via wireshark name resolution preferences), and ensuring the MIBs were located in the correct location
(on a mac I used dtrace to trace which files 'tshark' was accessing and located the path as /usr/share/snmp/mibs)