I have tcpdump on one device and i know IP of another device.
How can I get packages, which devices using for communication?
Now I use something like tcpdump -i <network_interface> -s 0 -w <file> But i need to catch initial packages too.
Tcpdump can't start with nonexistent network interface.
Is it possible to catch all packages sended from (and to) device with known IP?
As this is Linux, if the problem is that network interfaces may appear after you've started capturing, try capturing on the "any" device:
tcpdump -i any -s 0 -w <file> host 10.1.1.1
which will capture on all interfaces, including ones that appear after tcpdump starts.
I'm not sure I follow you, but if what you want is to ammend the command you are using so as to capture traffic to and from a device with a known IP, you just need to add the corresponding expression at the end, following pcap-filter guidelines.
In your case, and assuming you want all traffic to and from 10.1.1.1:
tcpdump -i <network_interface> -s 0 -w <file> host 10.1.1.1
tcpdump will capture only traffic that is evaluated as TRUE for the expression. pcap-filter will allow you to set protocols, source and destination IP addresses and tcp or udp ports or portranges, Ethernet MAC addresses, packet lengths and a myriad other things.
See http://www.tcpdump.org/tcpdump_man.html for general tcpdump usage, and http://www.tcpdump.org/manpages/pcap-filter.7.txt for all pcap-filter possibilities.
Related
After properly building OVMF x64 with EDK2, the command:
qemu-system-x86_64 -s -pflash run-ovmf/bios.bin -net none
provides the following message
WARNING: Image format was not specified for 'run-ovmf/bios.bin' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
This makes no sense to me as using qemu's -help command states "-pflash file use 'file' as a parallel flash image" where there is no parameter for a file format.
My OS is Windows WSL Ubuntu 22.04.1 LTS (GNU/Linux 5.15.79.1-microsoft-standard-WSL2 x86_64)
Qemu does still run, however I would like to run the VM without any write restrictions.
The '-pflash' option is (like -hda and -cdrom) a legacy "convenience" option which only allows you to specify a filename and nothing else. In order to specify other sub-options like the image format type, you need to switch to use a "long-form" option, which is typically some combination of -drive and -device. In this specific case, I think you probably want:
-drive if=pflash,file=bios.bin,format=raw
Chrome has a really awesome feature that allows you to open the dev tools from another browser or window. It works by starting chrome with this flag:
--remote-debugging-port=9222
Then from another window/browser you can go to http://localhost:9222 and open dev tools for any running tab in Chrome. For security reasons Chrome will not allow access from another machine by IP, lets say http://192.168.1.2:9222.
However there is an additional flag that indicates it opens this ability, here is what Chrome has to say for it:
--remote-debugging-address
Use the given address instead of the default loopback for accepting
remote debugging connections. Should be used together with
--remote-debugging-port. Note that the remote debugging protocol does not perform any authentication, so exposing it too widely can be a
security risk.
Either it's not working or I have no idea how to format it. I have tried the following:
--remote-debugging-port=9222 --remote-debugging-address=http://192.168.1.2:9222
--remote-debugging-port=9222 --remote-debugging-address=http://192.168.1.2
--remote-debugging-port=9222 --remote-debugging-address=192.168.1.2:9222
--remote-debugging-port=9222 --remote-debugging-address=192.168.1.3 //maybe thinking its supposed to be the IP of the remote machine
The target machine a Mac
it turned out, that the option "--remote-debugging-address" can only be used for the headless mode ("--headless") and is intended to be used for tests when the browser runs in a docker container and not for remote debugging.
The parameter of "remote-debugging-address" must be the numeric ip-adress of a local network interface of the machine where you start Chrome with "--remote-debugging-address".
When using any non-local ip-address you will get the following errors:
[0526/132024.480654:ERROR:socket_posix.cc(137)] bind() returned an error, errno=49: Can't assign requested address
[0526/132024.480766:ERROR:devtools_http_handler.cc(226)] Cannot start http server for devtools. Stop devtools.
On my Mac I can start the Chrome Canary version from today using this command line (the current stable version just crashes with "--headless"):
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --remote-debugging-port=9222 --remote-debugging-address=192.168.1.20 --headless
In another shell you can see, that this address is used to listen on the socket:
netstat -a -n | grep 9222
tcp4 0 0 192.168.1.20.9222 *.* LISTEN
Without "--headless" the output will look like this:
tcp4 0 0 127.0.0.1.9222 *.* LISTEN
Michael
--remote-debugging-address is semantically different from chromedriver's --whitelisted-ips
The remote debugging address must specify the address to bind to. So what you want in there is your machine's IP address not the address you will be connecting from. Try binding to all interfaces with --remote-debugging-address=0.0.0.0
Try create a HTTP-proxy in your target machine.
httpProxy
.createServer({
target: wsurl,
ws: true,
localAddress: host
})
.listen(port);
works for me.
I keep getting this error on my marathon dashboard
Framework with ID 'a5a96e8c-c3f2-4591-8eb3-43f8dc902585-0001' does not exist on slave with ID '9959ba51-f6f7-448f-99d2-289767f12179-S2'.
The path to make this error occur is to click "Sandbox" next to a task on the main marathon dashboard.
The path looks something like this
http://mesos.dev.internal/#/slaves/9959ba51-f6f7-448f-99d2-289767f12179-S2/frameworks/a5a96e8c-c3f2-4591-8eb3-43f8dc902585-0001/executors/rabbitmq.6316bf0a-d089-11e5-b895-fa163e196ca3/browse
However, if I go to the slave through the slave panel, and click the framework from there, I am able to access the sandbox. The link in this case looks like the following
http://mesos.dev.internal/#/slaves/9959ba51-f6f7-448f-99d2-289767f12179-S2/browse?path=%2Ftmp%2Fmesos%2Fslaves%2Fc223b6b1-cef8-4599-8cea-b402bf20afc5-S0%2Fframeworks%2F20160108-205802-16842879-5050-1210-0001%2Fexecutors%2Frabbitmq.91b8bbf6-ceba-11e5-8047-0242ffdabb3e%2Fruns%2Fc66eb4d5-ea6d-451d-982f-6a0d29b25441
Any ideas on what I have misconfigured?
Mesos Web UI does not proxy logs through mesos-master (although it would be nice). Basically you need to be able to resolve slave's name from your browser (computer) and port 5051 needs to be open for you:
$ nc -z -w5 mesos.dev.internal 5051; echo $?
0 # port is open
It's not a good idea to leave Mesos ports open for public, so either you can:
connect via VPN
whitelist your public IP on all slaves
use CLI instead of Web UI
Using CLI is quite easy, once you set master's URI. You can install it:
pip install mesos.cli mesos.interface
Then you can list all tasks using mesos ps, or fetch stdout:
mesos tail -f rabbitmq.6316bf0a-d089-11e5-b895-fa163e196ca3
and stderr:
mesos tail -f rabbitmq.6316bf0a-d089-11e5-b895-fa163e196ca3 stderr
Note that the mesos-cli is no longer developed, similar features and much more you should be able to do with Mesosphere's DCOS CLI
I'm running tcpdump on Mac OS and I've noticed it saves files in PCAP-NG format (the first 4 bytes are 0A 0D 0D 0A). Is there a way to force it to use the old PCAP instead?
Software version:
tcpdump version 4.3.0 -- Apple version 56
libpcap version 1.3.0 - Apple version 41
ps.
I'm not sure is that related to TCPDump or libpcap.
The tcpdump man page on Mavericks says:
-i Listen on interface.
If the -D flag is supported, an interface number as printed by
that flag can be used as the interface argument.
On Darwin systems version 13 or later, when the interface is
unspecified, tcpdump will use a pseudo interface to capture
packets on a set of interfaces determined by the kernel
(excludes by default loopback and tunnel interfaces).
Alternatively, to capture on more than one interface at a time,
one may use "pktap" as the interface parameter followed by an
optional list of comma separated interface names to include.
For example, to capture on the loopback and en0 interface:
tcpdump -i pktap,lo0,en0
An interface argument of "all" or "pktap,all" can be used to
capture packets from all interfaces, including loopback and tun-
nel interfaces.
A pktap pseudo interface provides for packet metadata using the
default PKTAP data link type and files are written in the Pcap-
ng file format. The RAW data link type must be used to force to
use the legacy pcap-savefile(5) file format with a ptkap pseudo
interface. Note that captures on a ptkap pseudo interface will
not be done in promiscuous mode.
An interface argument of "iptap" can be used to capture packets
from at the IP layer. This capture packets as they are passed
to the input and output routines of the IPv4 and IPv6 protocol
handlers of the networking stack. Note that captures will not
be done in promiscuous mode.
so you need to specify an interface on which to capture.
Note that versions of OS X dating back to Lion, newer versions of FreeBSD/NetBSD/DragonFly BSD, and newer versions of many Linux distributions include libpcap 1.1.1 or later, which means that programs using libpcap to read capture files can read many pcap-ng files. Wireshark has also been able to read them for several releases.
There is also an app, CocoaPacketAnalyzer, which reads pcap files, but not pcap-NG files. There is a web page, https://pcapng.com, that will convert a small pcap-NG file to the older format. However, if you are capturing password or web server interactions, or generally care about security, beware about posting packet captures on the internet!
My ultimate goal is to do telnet to a router and interact with it. The following expect script does not help me at all. The router does not have any user id or pasword. it is automatic login.
Expect file code.
set iptotelnet "10.x.x.x"
spawn telnet $iptotelnet
sleep 10
expect ">" #this is because initially the prompt will be >
sleep 10
send "enable\r" # this should change the prompt from > to #
sleep 10
expect "#"
sleep 10
interact
sleep 10
exit
However, I get the following error.
send: spawn id exp4 not open
while executing
send "enable\r".
This is not just with telnet, i get the same error with any other command also.
please help me.
Your script has no major issues with it, not that would cause spawn to fail like that. (The comments you have would cause problems, but are trivially fixable by using ;# instead of #.) Therefore your problem lies elsewhere (well, with very high probability).
I see that you are trying to control telnet with Expect on Windows. Alas, telnet is a special case that can't be controlled this way — Expect on Windows uses the system debugging facilities to intercept terminal output, but this doesn't work for executables that have special system permissions set, and telnet is one of the programs for which this is true — so you need another approach. The simplest is to get plink.exe (which is really PuTTY for terminals/automation) and to use that (in “telnet” mode) instead of telnet.
Probably you can't use # comments in send command line.
Try same but without comment in send string.
It happens to me too. And it has been resolved.
I try to automatically telnet a server in the Cygwin on Windows.
But the Microsoft telnet installed in Windows won't work in a Cygwin shell
If you got the response below, this is the source of your problems type:
$ which telnet
/cygdrive/c/WINDOWS/system32/telnet
There are two solutions:
1. For Cygwin x86, just simply install the package "inetutil" which includes telnet command.
2. For Cygwin x86_64, currently(2013-09-09) the "inetutil" hasn't been port to 64bit, so I use the plink.exe which is part of PuTTy instead