Trouble with LiveCapture argument - Pyshark - python-3.x

I'm following a wireshark course that requires me to write a simple pyshark script. The problem is the lecturer uses a Linux VM and the network name is given through ifconfig i.e eth0.
Since I'm operating on Windows, and unfamiliar with pyshark, I'm wondering what suffices for the network name while writing this argument. I can't seem to pinpoint specifically how my network adapter is referred to with the 'eth' naming convention. Would something simply like the index number i.e 3 suffice?
I've tried variations of eth to 'guess' the right network. Proof is in running the script and seeing it print the results. Otherwise its been a guessing game. So far nothing is printing out after running my script which i use as validation for not getting my adapter value right. (There is only one active network adapter on my pc).
Would appreciate someone with knowledge of pyshark arguments chiming in. This is the script:
import pyshark
capture = pyshark.LiveCapture(interface= 'eth3')
for packet in capture.sniff_continuously(packet_count=5):
try:
print('Source = ' + packet['ip'].src)
print('Destination =' + packet['ip'].dst)
except:
if LiveCapture == 0:
print ("No Packets on this interface")
print("~Fin~")
exit()

I found that using the last name of my adapter i.e Ethernet, worked. Seems like pyshark recognizes the interface based on the name ascribed to it by you or your system. For example: Network Connections -> Ethernet.
Or through ipconfig on command line -> Ethernet Adapter Ethernet

Related

Receiving "NO CARRIER" error while tring to execute AT cmd "AT$QCRMCALL=1,1"

I am using linux 20.04 to build an image for the IMX8QXP, the image is based on kernel SUMO 4.14.98.
I am using one of the SIMCOM7600E.
I starts to dial up via NIC by using below command :
AT+CREG = 1
+CREG=1,1
return OK
AT+CGREG = 1
+CGREG=1,1
return OK
AT$QCRMCALL=1,1
return No CARRIER
I cant seem to fix the problem or figure out what is wrong. Please help me trouble shoot the problem!!
My guess would be:
The module can be registered in network, but the selected network mode may be unsuitable for data transmission (e.g. voice calls only or other). Check the preferred mode by using AT+CNMP?. The return value of 2 indicates auto.
Make sure that you have data plan available. Also remove PIN lock on the SIM card
Check if the signal quality is decent: try AT+CSQ. Its return value will be in format ,. RSSI stands for Received Signal Strength Indicator and BER for Bit Error Rate. RSSI value ranges can be in between 0 (minimum, =< -113dBm) to 31 (maximum, >= -51 dBm).
Look for more information about the operator: AT+COPS? and the network mode: AT+CPSI?
Based on the information obtained in previous steps, use an appropriate antenna or adjust its location if necessary
Don't forget about the stable power supply
If you didn't have much success with AT$QCRMCALL=1,1, try changing the USB PID of the module to 9011 (for using the modules as a RNDIS modem): AT+CUSBPIDSWITCH=9011,1,1 (the default PID is 9001)
I would flash a new firmware only as a last resort. Usually this is not necessary
Reference:
SIM7600 AT Commands manual v3.0

How to discover a device quickly with BlueZero?

I have an Ubuntu PC that I want to connect to an advertising microcontroller (nrf52840) using python.
They connect just fine when the PC has already discovered the microcontroller using a command line tool like bluetoothctl. The issue is when the devices are interacting for the first time.
According to the Bluezero docs it seems like nearby_discovery() is just the function for the job. The issue is unless I set the timeout to be absurdly long, like ~45 seconds, the Central cannot be created because it hasn't been discovered.
The steps I'm taking now:
from bluezero import adapter, central
dongles = adapter.list_adapters()
dongle = adapter.Adapter(dongles[0])
dongle.nearby_discovery(timeout=45)
myCentral = central.Central(adapter_addr=dongle.address, device_addr="AA:BB:CC:DD:EE:FF")
Is there a more reliable way to discover/connect to new devices?
For what it's worth, bluetoothctl scan on seems to discover devices almost immediately.
The solution turned out to be unrelated to bluezero. I'm using JTAG to grab the MAC address and that function resets the CPU on the board, meaning that it took around 30 seconds to reboot and start advertising again. Thank you for the responses
There shouldn't be any significant time difference between Bluezero and bluetoothctl to discover a device as they are making the same API calls to bluetoothd.
Once a device is in the known list in BlueZ, then because BlueZ ignores "duplicates", it doesn't report a device very frequently in the scan results.
This is what leads to most scripts I've seen not using the nearby_discovery() because once your device is in the known list, you can connect to it without discovery.
In bluetoothctl you can type devices to get the list. In Bluezero there is not a tidy option to do this (Just not something I have thought of providing previously). If you wanted to do a test to see if the device you want to connect to is already in the list then below is my initial thought:
from bluezero import dbus_tools
def known_devices():
"""Get a list of devices Bluez already knows about"""
device_list = []
mng_objs = dbus_tools.get_managed_objects()
for path in mng_objs:
address = mng_objs[path].get('org.bluez.Device1', {}).get('Address')
if address:
device_list.append(str(address))
return device_list
def is_known_device(mac_addr):
"""Is the given Bluetooth address already a known device"""
found_devices = known_devices()
return mac_addr in found_devices
print(f'Device list: {known_devices()}')
look_list = ['DC:DB:16:6B:8C:5F', 'DC:DB:16:6B:8C:xx']
for look_up in look_list:
print(f'{look_up} is known? {is_known_device(look_up)}')
In my testing I got the following output:
Device list: ['DC:DB:16:6B:8C:5F', 'DE:82:35:E7:43:BE']
DC:DB:16:6B:8C:5F is known? True
DC:DB:16:6B:8C:xx is known? False

Why can't I read in a freshly opened TTY in Raspbian

I have a small issue with my code, running in Python 3. I'm trying to fool Raspbian, in order to make it believe a tty is an external device.
However, I can't read a single word I wrote previously with os.write(slave, text.encode()), using something like os.read(slave, 512).
I open the tty as follow master, slave = os.openpty()
I think I'm missing a parameter or something, but I can't find out what.
I tried accessing the tty in another terminal, with a cat <, with a subprocess, but the program still block when it has to read.
Please explain what is the problem.
Regards.
I think your mistake here is that you are trying to read the slave. If you read the master instead you should get your output.
Quote from: http://www.rkoucha.fr/tech_corner/pty_pdip.html
A pseudo-terminal is a pair of character mode devices also called pty. One is master and the other is slave and they are connected with a bidirectional channel. Any data written on the slave side is forwarded to the output of the master side. Conversely, any data written on the master side is forwarded to the output of the slave side as depicted in figure 2.
RPI

Can I intercept network packets with a raw socket (not only sniff)?

This is my first time using raw sockets (yes, I need to use them as I must modify a field inside a network header) and all the documentation or tutorials I read describe a solution to sniff packets but that is not exactly what I need. I need to create a script which intercepts the packet, process it and sends it further to the destination, i.e. the packets should not reach the destination unless my script decides to.
In order to learn, I created a small prototype which detects pings and just prints "PING". I would expect ping not to work as I intercept the packets and I don't include the logic to send them to its destination. However ping is working (again, it seems as it is just sniffing/mirroring packets). My goal is that the ping packets are "trapped" in my script and I don't know how to do that. This is what I do in my current python script (I avoid writing how I do the decode for simplicity)
sock = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.ntohs(0x0003))
sock.bind((eth0, 0))
packet = sock.recvfrom(65565)
decode_eth(packet)
decode_ip(packet)
if (ipheader.ip_proto == 1):
print("\nPING")
Can somebody explain how can I achieve my goal or point me to the right documentation?
Your description seems to be different from what your title suggest. My understanding is that you want to receive, modify and possibly drop incoming network packets. And this is to be done on Linux. In that case I suggest you use a netfilter prerouting hook, which will make things a lot simpler (and likely more stable). Netfilter is well documented, a nice overview including information related to your requirements can be seen here. The important function to use is nf_register_hook(), read the answer to this question to get an idea of how to set things up.
I suppose that your Linux box is configured as a router (not a bridge). The packet will pass through your Linux because you have enabled IP Forwarding. So there are two solution:
Solution 1:
Disable IP Forwarding and then receive the packet from one interface and do the appropriate task (forwarding to another interface or dropping it).
Solution 2:
Use NetFilterQueue.
Install it on your Linux box (Debian/Ubuntu in my example):
apt-get install build-essential python-dev libnetfilter-queue-dev
Use iptables to send packets coming from input interface (eth0 in my example):
iptables -I INPUT -i eth0 -j NFQUEUE --queue-num 1
Run this script to handle packets forwarded to the Queue No.1 :
from netfilterqueue import NetfilterQueue
def print_and_accept(pkt):
print pkt
pkt.accept()
nfqueue = NetfilterQueue()
nfqueue.bind(1, print_and_accept)
try:
nfqueue.run()
except KeyboardInterrupt:
print
Note that pkt.drop() cause dropping the packet. Also you should accept/drop every packet.

Serial port routing in Linux

After reading about serial ports, virtual serial ports and such, I need a little advice to see if this is even possible. I've set up two serial ports on a Linux machine (running Ubuntu). I'd like to route the two serial ports together. Is this even possible?
The two serial ports are automatically started through the /etc/init/ttyXXX.conf getty scripts. I'd like it so that when the first serial port receives a character, it outputs that character straight away to the second serial port, and also the vice versa.
Any easy way to do this through a program or bash scripts?
The idea is that both serial ports should be able to access the linux machine with commands. However, it would be nice to be able to see the outputs of the commands regardless of which port you are attached to. For example, if port 1, logged on as root, sends "echo testing", I'd like for port 2 to see the output, but also able to see that port 1 sent the command.
Thanks
A small Perl script like this might do what you're hoping, though I'm not quite sure what you're asking, so please comment if it's not working the way you'd hope. I've only got it going one way because I think they'd just keep sending the same character back and forth if it were two way. You might also need to change the port paths near the top to whatever yours are.
Just save it as serial.pl or similar, make it executable and run it.
#!/usr/bin/perl
use strict;
use warnings;
use Device::SerialPort;
my $port1_path = '/dev/tty1';
my $port2_path = '/dev/tty2';
my $port1 = Device::SerialPort->new($port1_path);
$port1->databits(8);
$port1->baudrate(19200);
$port1->parity("none");
$port1->stopbits(1);
my $port2 = Device::SerialPort->new($port2_path);
$port2->databits(8);
$port2->baudrate(19200);
$port2->parity("none");
$port2->stopbits(1);
while ($in = $port1->input) {
$port2->write($in);
}
It is possible to connect two serial ports between each other, with a crossover cable (so that the input of one port is connected to the output of the other port).
Assuming that you ports are correctly configured (drivers installed and loaded) and that your crossover cable is connected between your ports, you can type the following commands in two terminals:
Terminal 1: listen in the output port
$ tail -f /dev/ttyXXX
Terminal 2: write to the input port
$ echo "Hello!" > /dev/ttyYYY
If the two ports are correctly connected, the message "Hello!" will be displayed in terminal 1.
The hardest part is often to know which hardware port correspond to which device file.
If you just wanted to connect the two serial ports, you could use
socat /dev/ttyS0,raw,echo=0,crnl /dev/ttyS1,raw,echo=0,crnl
(see http://technostuff.blogspot.com/2008/10/some-useful-socat-commands.html)
But, since you want to interact with the command interpreter, I think you'll need to write a Perl script that
Opens both serial ports
Uses select to wait until one of the ports has some input for you
Pass that input to the shell
Write the output of the shell command back to both serial ports

Resources