I am successfully able to capture with this command line.
C:\Program Files\Wireshark\wireshark.exe -i 4 -k -b duration:3600 -w c:\capture.pcap
I have tried this method and it pops the Wireshark command line help window.
C:\Program Files\Wireshark\wireshark.exe -i 4 -k -b duration:3600 -w -f 10.0.0.1 and 10.0.0.2 and 10.0.0.3 c:\capture.pcap
I have also tried this way.
C:\Program Files\Wireshark\wireshark.exe -i 4 -k -b duration:3600 -w -f host 10.0.0.1 and 10.0.0.2 and 10.0.0.3 c:\capture.pcap
Neither one of the above work. they both get the same error. I know it is something simple, however I do not know Wireshark well enough.
Thanks.
You have a few problems:
The filename (c:\capture.pcap) must immediately follow the -w flag.
The filter must be "quoted" if it contains spaces.
You must specify the "host" keyword before each address.
The logical operation you want is almost certainly "or", not "and"
Given the above, try:
C:\Program Files\Wireshark\wireshark.exe -i 4 -k -b duration:3600 -w c:\capture.pcap -f "host 10.0.0.1 or host 10.0.0.2 or host 10.0.0.3"
Related
I understood docker's -t as a kind of virtual terminal that seems to access the terminal through /dev/pts. So, if I do echo "hello, tty" > /dev/pts/1 , I see that it is output to the connected terminal. Since the -i option is STDIN, the container understands it as an option to receive text as input. So, who does the input go to when only the -i option is applied?
Below is the result of the command given only the -i option.
~ $ docker exec -i mysql-container bash
tty
not a tty
ls
bin
boot
dev
docker-entrypoint-initdb.d
entrypoint.sh
etc
home
lib
lib64
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var
I didn't give the -t option, so I was expecting no results back. But it exactly missed my expectations. Why is it running like this?
The difference is subtle, but when you only use -i, you communicate with it using stdin and stdout. But there's no terminal in the container.
When you use -it you attach a terminal and that lets you do 'terminal stuff'. For instance, with -it
you get a prompt
you can send programs to the background with stuff like tail -f /dev/null &
ctrl-c works as expected
etc
The difference is hard to spot, because with -i you usually take stdin from a terminal on the host and send stdout to the a terminal on the host.
Usually, when you want to run commands interactively, you'll use -it. A scenario where you might use only -i is when you pipe the commands into the container. Something like this
echo -e 'tty\nls' | docker exec -i mysql-container bash
which will run the tty and ls commands and give you the output.
I want to capture MQTT packets on the SSH Linux-based remote server using Wireshark from my home. I can capture data go out through the Internet, such as when I use this command line mosquitto_pub -h test.mosquitto.org -t topic -m "Hello", I can see the packets in Wireshark. But, When I publish data in localhost, such as using this command mosquitto_pub -d -h localhost -t hello/world -m "75" I can't see any packets in Wireshark. I want to make a client/server in the same remote server.
I use this command to open Wireshark:
sudo ssh user#x.x.x.x tcpdump -U -s0 -w - | wireshark -k -i -
I know only a basic thing in Wireshark, so please how I solve this?
You didn't specify the interface that tcpdump should capture on. Try adding the -i lo option, as in:
sudo ssh user#x.x.x.x tcpdump -i lo -U -s0 -w - | wireshark -k -i -
My HAproxy container exits every time i try to run it .
I have tried to run it without --d to see why it exited and I get the following output:
$ sudo docker run --name=hapr -p 80:80 -v /haproxy/:/usr/local/etc/haproxy/ haproxy
I get this output:
HA-Proxy version 2.1.4 2020/04/02 - https://haproxy.org/ Status: stable branch - will stop receiving fixes around Q1 2021. Known bugs: http://www.haproxy.org/bugs/bugs-2.1.4.html Usage : haproxy [-f <cfgfile|cfgdir>]* [ -vdVD ] [ -n <maxconn> ] [ -N <maxpconn> [ -p <pidfile> ] [ -m <max megs> ] [ -C <dir> ] [-- <cfgfile>* -v displays version ; -vv shows known build options. -d enters debug mode ; -db only disables background mode. -dM[<byte>] poisons memory with <byte> (defaults to 0x50) -V enters verbose mode (disables quiet mode) -D goes daemon ; -C changes to <dir> before loading files. -W master-worker mode. -q quiet mode : don't display messages -c check mode : only check config files and exit -n sets the maximum total # of connections (uses ulimit -n) -m limits the usable amount of memory (in MB) -N sets the default, per-proxy maximum # of connections (0) -L set local peer name (default to hostname) -p writes pids of all children to this file -de disables epoll() usage even when available -dp disables poll() usage even when available -dS disables splice usage (broken on old kernels) -dG disables getaddrinfo() usage -dR disables SO_REUSEPORT usage -dr ignores server address resolution failures -dV disables SSL verify on servers side -sf/-st [pid ]* finishes/terminates old pids. -x <unix_socket> get listening sockets from a unix socket -S <bind>[,<bind options>...] new master CLI
If I list the container I get the following message:
$ docker container ls -a
Exited (1) 3 minutes ago
I have fixed my problem , If someone get same problem .
So just you should have the full path in your command .
instaed of
$ sudo docker run --name=hapr -p 80:80 -v /haproxy/:/usr/local/etc/haproxy/ haproxy
use
$ sudo docker run --name=hapr -p 80:80 -v /home/ubuntu/haproxy/:/usr/local/etc/haproxy/ haproxy
also you should have haproxy.cfg allready in your host .
If you check the official HAproxy page on DockerHub you could see that you need to have the haproxy.cfg in to the path /haproxy/. If not, HAproxy can not start.
Note that your host's /path/to/etc/haproxy folder should be populated with a file named haproxy.cfg. If this configuration file refers to any other files within that folder then you should ensure that they also exist (e.g. template files such as 400.http, 404.http, and so forth).
There is the official HAproxy documentation about the haproxy.cfg.
To continue, you need to stop and delete the current container:
$ docker stop CONTAINER
$ docker rm CONTAINER
And created again.
I have a CentOS server with two static IP address (192.168.3.100 and 192.168.3.101) on same NIC and two containers running on it with port mapping as below. The containers use the same default 'bridge' network of docker
192.168.3.100:80->80/tcp container1
192.168.3.101:80->80/tcp container2
From the host, I can execute curl 192.168.3.100 or curl 192.168.3.101 and works fine. From the host/containers I can execute curl 172.17.0.2 or curl 172.17.0.3 and works fine.
But I cannot execute curl 192.168.3.100 or curl 192.168.3.101 from neither of these containers. Ends up with error No route to host. I can ping it though.
What am I missing here? I want to try to avoid using a 192 docker network as I do not want to tie up the address space with one machine. Using docker 1.12.6
Output for iptables reject rules iptables -S | grep -i reject
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
Thanks for your input
If you are able to ping and not able to curl and you get no route to host then it mostly means that your packets are getting rejected through firewall.
Check the iptables using sudo iptables -S or sudo iptables -L -n. If you see a REJECT or REJECT using icmp rule than thats the problem.
If you are not worried about iptables and are ok to clear it. Stop the docker service and run the below
$ iptables -F
$ iptables -X
$ iptables -t nat -F
$ iptables -t nat -X
$ iptables -t mangle -F
$ iptables -t mangle -X
This will clear all the tables. Then start the docker service and run the container again
I read some docker docs and I do not understand what it might mean to
attach a tty
attach std-in and std-out
for these purposes, I see that -i and -t flags are use.
What does this process mean?
stdin, stdout, and ttys are related concepts. stdin and stdout are the input and output streams of a process. A pseudo terminal (also known as a tty or a pts) connects a user's "terminal" with the stdin and stdout stream, commonly (but not necessarily) through a shell such as bash. I use quotes around "terminal" since we really don't use a terminal in the same sense today.
In the case of docker, you'll often use -t and -i together when you run processes in interactive mode, such as when starting a bash shell. In the case of the shell you want to be able to issue commands and read the output.
The code docker uses to attach stdout/stdin has all the dirty details.
We can see what is happening under the hood by using the lsof command. For a demonstration we can create a simple docker container from a Debian image that just runs sleep:
docker run -d --name tty-test debian /bin/bash -c "sleep 1000"
This will start the sleep command in a new container (note that we did not use -i or -t).
Next we "login" into our container though the exec command and start a bash:
docker exec -it tty-test /bin/bash
A plain debian image will not have lsof installed so we need to install it:
apt update && apt install -y lsof
Next we run lsof:
lsof
If run without any options, lsof will print open files for all running processes. You should see three processes in its output (sleep, bash, and lsof itself).
Here are the relevant lines are those that show the file descriptors (FD column) 0 to 2.
Note how the sleep process, which we started without the -t option has three FIFO pipes for stdin,stdout and stderr:
sleep 1 root 0r FIFO 0,10 0t0 8226490 pipe
sleep 1 root 1w FIFO 0,10 0t0 8226491 pipe
sleep 1 root 2w FIFO 0,10 0t0 8226492 pipe
While the bash process has an actual device attached to stdin, stdout and stderr:
bash 7 root 0u CHR 136,15 0t0 18 /dev/pts/15
bash 7 root 1u CHR 136,15 0t0 18 /dev/pts/15
bash 7 root 2u CHR 136,15 0t0 18 /dev/pts/15
Lets create another container with the -t option:
docker run -d -t --name tty-test2 debian /bin/bash -c "sleep 1000"
After installing lsof again (see above) we get a different output from lsof for the sleep process:
sleep 1 root 0u CHR 136,15 0t0 18 /15
sleep 1 root 1u CHR 136,15 0t0 18 /15
sleep 1 root 2u CHR 136,15 0t0 18 /15
Note how the type column has changed to CHR and the name column shows /15.
Finally, when we omit the -t option from the exec command and like this:
docker exec -it tty-test /bin/bash
then we can notice two things. First, we do not get a shell prompt from the bash now, but we can still type commands and see their output. When we run lsof we see that the bash process now also has pipes rather then a tty attached to stdin, stdout, and stderr
bash 379 root 0r FIFO 0,10 0t0 8263037 pipe
bash 379 root 1w FIFO 0,10 0t0 8263038 pipe
bash 379 root 2w FIFO 0,10 0t0 8263039 pipe
It means you can log in to your container using TTY, ie terminal. It's as if you've got a Linux machine in front of you and you're logging into it. If you have a container that's not running SSH server or telnet, this is your only mode of getting into the command line prompt.
As for why -i and -t are different arguments I'm not sure about, I can't imagine a scenario where you want to connect using TTY and don't want the stdin/stdout option or vice versa.
Option -i -t is useful for interacting with certain interactive process's like bash shell running inside the container.
consider the below command
PS C:\Users\nssh> docker run -it ubuntu /bin/bash
root#c7537bbf2941:/# ls
bin boot dev etc home lib lib32 lib64
When we run this command, docker will start the ubuntu container with bash shell running inside.
The -i flag tells docker that anything we type should be sent to bash process's stdin. ls command typed above is sent to bash.
The -t flag tells docker that this will be an interactive session and the stdin will be a tty.
For a typical SSH like experience, -t and -i must be used together.
The only reason to leave out -t is if the stdin is a pipe (and not a tty like above). Specifying -t is forbidden when the client is receiving its standard input from a pipe, as in:
PS C:\Users\nssh> echo test | docker run -it ubuntu cat
the input device is not a TTY. If you are using mintty, try prefixing the command with 'winpty'
Leave out the -t flag if stdin is a pipe.
PS C:\Users\nssh> echo test | docker run -i ubuntu cat
test
Simply put it allows us to attach and detach from the containers terminal. To attach we use the docker attach command and to detach we use the CTRL+P & CTRL+Q command.