When I run the "wireshark" in ubuntu 20.04. I got the error message and can't execute wireshark successfully. I ALWAYS GOT THIS ERROR

qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

I do the searching I found many solutions. BUT that didn't work for me. I have installed every application they mentioned.

However, I noticed the most important information which leads to wireshark can't find the xcb liberary.

In the ubuntu 20.04, I have installed xcb liberary already. BUT some how wireshark can't find it in the path "/usr/bin/platform"

I add link from /usr/bin/platforms/ to /usr/lib/x86_64-linux-gnu to resolve this issue.

sudo ln -s /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/ /usr/bin/platforms

Maybe it works for you as well

tables:
==================
1)a table is something that allows you to process packets in specific ways
2)default table is the "filter" table,these "tables" have "chains" attached to them
    |
    |+filter table: default table, decide whether packet should allowed to its dest.
    |    
    |+mangle table: alter packet headers in various ways,such as changing TTL values.
    |    
    |+nat table: allows you to route packets to different hosts on NAT (Network Address         |         Translation) networks by changing the source and destination addresses of         |         packet
    |     
    |+ raw table:allows you to work with packets before the kernel starts tracking its state    

 
chains:
=============
1)chains allow you to "inspect traffic at various points",
    such as when they just arrive on the network interface
    or just before they’re handed over to a process.

Automatic Variables

Suppose you are writing a pattern rule to compile a ‘.c’ file into a ‘.o’ file: how do you write the ‘cc’ command so that it operates on the right source file name? You cannot write the name in the recipe, because the name is different each time the implicit rule is applied.

What you do is use a special feature of make, the automatic variables. These variables have values computed afresh for each rule that is executed, based on the target and prerequisites of the rule. In this example, you would use ‘$@’ for the object file name and ‘$<’ for the source file name.

It’s very important that you recognize the limited scope in which automatic variable values are available: they only have values within the recipe. In particular, you cannot use them anywhere within the target list of a rule; they have no value there and will expand to the empty string. Also, they cannot be accessed directly within the prerequisite list of a rule. A common mistake is attempting to use $@ within the prerequisites list; this will not work. However, there is a special feature of GNU make, secondary expansion (see Secondary Expansion), which will allow automatic variable values to be used in prerequisite lists.

Here is a table of automatic variables:

 

$@

The file name of the target of the rule. If the target is an archive member, then ‘$@’ is the name of the archive file. In a pattern rule that has multiple targets (see Introduction to Pattern Rules), ‘$@’ is the name of whichever target caused the rule’s recipe to be run.

$%

The target member name, when the target is an archive member. See Using make to Update Archive Files. For example, if the target is foo.a(bar.o) then ‘$%’ is bar.o and ‘$@’ is foo.a. ‘$%’ is empty when the target is not an archive member.

$<

The name of the first prerequisite. If the target got its recipe from an implicit rule, this will be the first prerequisite added by the implicit rule (see Using Implicit Rules).

$?

The names of all the prerequisites that are newer than the target, with spaces between them. If the target does not exist, all prerequisites will be included. For prerequisites which are archive members, only the named member is used (see Using make to Update Archive Files).

‘$?’ is useful even in explicit rules when you wish to operate on only the prerequisites that have changed. For example, suppose that an archive named lib is supposed to contain copies of several object files. This rule copies just the changed object files into the archive:

lib: foo.o bar.o lose.o win.o
        ar r lib $?

$^

The names of all the prerequisites, with spaces between them. For prerequisites which are archive members, only the named member is used (see Using make to Update Archive Files). A target has only one prerequisite on each other file it depends on, no matter how many times each file is listed as a prerequisite. So if you list a prerequisite more than once for a target, the value of $^ contains just one copy of the name. This list does not contain any of the order-only prerequisites; for those see the ‘$|’ variable, below.

$+

This is like ‘$^’, but prerequisites listed more than once are duplicated in the order they were listed in the makefile. This is primarily useful for use in linking commands where it is meaningful to repeat library file names in a particular order.

$|

The names of all the order-only prerequisites, with spaces between them.

$*

The stem with which an implicit rule matches (see How Patterns Match). If the target is dir/a.foo.b and the target pattern is a.%.b then the stem is dir/foo. The stem is useful for constructing names of related files.

In a static pattern rule, the stem is part of the file name that matched the ‘%’ in the target pattern.

In an explicit rule, there is no stem; so ‘$*’ cannot be determined in that way. Instead, if the target name ends with a recognized suffix (see Old-Fashioned Suffix Rules), ‘$*’ is set to the target name minus the suffix. For example, if the target name is ‘foo.c’, then ‘$*’ is set to ‘foo’, since ‘.c’ is a suffix. GNU make does this bizarre thing only for compatibility with other implementations of make. You should generally avoid using ‘$*’ except in implicit rules or static pattern rules.

If the target name in an explicit rule does not end with a recognized suffix, ‘$*’ is set to the empty string for that rule.

Of the variables listed above, four have values that are single file names, and three have values that are lists of file names. These seven have variants that get just the file’s directory name or just the file name within the directory. The variant variables’ names are formed by appending ‘D’ or ‘F’, respectively. The functions dir and notdir can be used to obtain a similar effect (see Functions for File Names). Note, however, that the ‘D’ variants all omit the trailing slash which always appears in the output of the dir function. Here is a table of the variants:

if you are suffer the problem

sudo apt-get install teams

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 teams : Depends: libgtk-3-0 (>= 3.19.12) but 3.18.9-1ubuntu3.3 is to be installed
E: Unable to correct problems, you have held broken packages.

I downgraded to use this to resolve

sudo apt install teams=1.3.00.30857

error: dereferencing pointer to incomplete type 'RSA {aka struct rsa_st}' if (BN_num_bits(key->e) > 64) ^~ scripts/Makefile.host:134: recipe for target 'tools/lib/rsa/rsa-sign.o' failed

Solution: http://git.lede-project.org/70b104f  please fix by this patch.

diff --git a/tools/mkimage/patches/210-openssl-1.1.x-compat.patch b/tools/mkimage/patches/210-openssl-1.1.x-compat.patch
new file mode 100644 (file)
index 0000000..fa7c99f
--- /dev/null
+++ b/tools/mkimage/patches/210-openssl-1.1.x-compat.patch
@@ -0,0 +1,97 @@
+--- a/lib/rsa/rsa-sign.c
++++ b/lib/rsa/rsa-sign.c
+@@ -15,10 +15,25 @@
+ #include <openssl/ssl.h>
+ #include <openssl/evp.h>
+
+-#if OPENSSL_VERSION_NUMBER >= 0x10000000L
++#if OPENSSL_VERSION_NUMBER < 0x10000000L
++#define HAVE_ERR_REMOVE_STATE

the librt.so.1 share liberary missing after update or remove some ubuntu application, the below is a way to rescuse ubuntu boot up failure issue.

1.Boot from installation medium(live cd)

2.Mount your problematic Ubuntu root filesystem with file manager by clicking on the drive icon in the Devices section

If unsure which partition to mount then check it with Disks (gnome-disks) utility and mount it from here:

4. go to download the missing liberaries by here (debian packet searchig website) or http://http.us.debian.org/debian/pool/main/g/glibc/

#mkdir ~/tmp; cd ~/tmp
#wget http://http.us.debian.org/debian/pool/main/g/glibc/libc6_2.31-13+deb11u3_i386.deb    or
#wget http://http.us.debian.org/debian/pool/main/g/glibc/libc6_2.31-13+deb11u5_i386.deb
#wget http://ftp.us.debian.org/debian/pool/main/g/glibc/libc6_2.31-13+deb11u3_amd64.deb  or
#wget http://http.us.debian.org/debian/pool/main/g/glibc/libc6_2.31-13+deb11u5_amd64.deb
#dpkg -x libc6_2.31-13+deb11u3_amd64.deb /media/to/your/topdir of problemic rootfs/

Check that above operation do not have errors and then reboot.

https://www.shellcheck.net/

Example1

/ {
    #address-cells = <0x1>; //在 root node下使用1个u32来代表address, root node use 1 u32 to present address. 
    #size-cells = <0x0>; // 在root node下使用0个u32来代表size, root node have 0 to present address length.
    ...
    ...
    memory {        // memory device
        ...
        reg = <0x90000000>;
            // 0x90000000是存取memory的address // 0x90000000 is a u32 address, no address length 
        ...
    };
    ...
    ...
}

Example2

/ {
    #address-cells = <0x1>; //在root node下使用1个u32来代表address。// address format is one u32 
    #size-cells = <0x1>; //在root node下使用1个u32来代表size。 // the address is one u32 length.
    ...
    ...
    memory { // memory device
        ...
        reg = <0x90000000 0x800000>;
            // 0x90000000 是存取 memory 的 address //0x90000000
            // 0x800000 是 memory 的 size。
        ...
    };
    ...
    ...
}

Example3

/ {
    #address-cells = <0x2>; // 在root node下使用2个u32来代表address。
    #size-cells = <0x1>; // 在root node下使用1个u32来代表size。
    ...
    ...
    memory { // memory device
        ...
        reg = <0x90000000 00000000 0x800000>;
            // 0x90000000 00000000 是存取memory的address
            // 0x800000 是memory的size。
        ...
    };
    ...
    ...
}

Example4

/ {
    #address-cells = <0x2>; // 在root node下使用2个u32来代表address。
    #size-cells = <0x2>; // 在root node下使用2个u32来代表size。
    ...
    ...
    memory { // memory device
        ...
        reg = <0x90000000 00000000 0x800000 00000000>;
            // 0x90000000 00000000 是存取memory的address
            // 0x800000 00000000 是memory的size。
        ...
    };
    ...
    ...
}
reference：https://www.cnblogs.com/youchihwang/p/7050846.html

https://www.booleanworld.com/depth-guide-iptables-linux-firewall/

a very good doc for understanding iptables.

he Linux kernel comes with a packet filtering framework named netfilter. It allows you to allow, drop and modify traffic leaving in and out of a system. A tool, iptables builds upon this functionality to provide a powerful firewall, which you can configure by adding rules. In addition, other programs such as fail2ban also use iptables to block attackers.

In this article, we’re going to take a look at how iptables works. We’re also going to look at a few examples, which will help you write your own rules.

How does iptables work?

iptables is just a command-line interface to the packet filtering functionality in netfilter. However, to keep this article simple, we won’t make a distinction between iptables and netfilter in this article, and simply refer to the entire thing as “iptables”.

The packet filtering mechanism provided by iptables is organized into three different kinds of structures: tables, chains and targets. Simply put, a table is something that allows you to process packets in specific ways. The default table is the filter table, although there are other tables too.

Again, these tables have chains attached to them. These chains allow you to inspect traffic at various points, such as when they just arrive on the network interface or just before they’re handed over to a process. You can add rules to them match specific packets — such as TCP packets going to port 80 — and associate it with a target. A target decides the fate of a packet, such as allowing or rejecting it.

When a packet arrives (or leaves, depending on the chain), iptables matches it against rules in these chains one-by-one. When it finds a match, it jumps onto the target and performs the action associated with it. If it doesn’t find a match with any of the rules, it simply does what the default policy of the chain tells it to. The default policy is also a target. By default, all chains have a default policy of allowing packets.

Now, we’re going to take a deeper look into each of these structures.

Tables

As we’ve mentioned previously, tables allow you to do very specific things with packets. On a modern Linux distributions, there are four tables:

• The filter table: This is the default and perhaps the most widely used table. It is used to make decisions about whether a packet should be allowed to reach its destination.

• The mangle table: This table allows you to alter packet headers in various ways, such as changing TTL values.

• The nat table: This table allows you to route packets to different hosts on NAT (Network Address Translation) networks by changing the source and destination addresses of packets. It is often used to allow access to services that can’t be accessed directly, because they’re on a NAT network.

• The raw table: iptables is a stateful firewall, which means that packets are inspected with respect to their “state”. (For example, a packet could be part of a new connection, or it could be part of an existing connection.) The raw table allows you to work with packets before the kernel starts tracking its state. In addition, you can also exempt certain packets from the state-tracking machinery.

In addition, some kernels also have a security table. It is used by SELinux to implement policies based on SELinux security contexts.