[#]: author: (Molly de Blanc https://opensource.com/users/mollydb)
How GNOME uses Git
======
The GNOME project's decision to centralize on GitLab is creating
benefits across the community—even beyond the developers.
![red panda][1]
“What’s your GitLab?” is one of the first questions I was asked on my first day working for the [GNOME Foundation][2]—the nonprofit that supports GNOME projects, including the [desktop environment][3], [GTK][4], and[GStreamer][5]. The person was referring to my username on [GNOME’s GitLab instance][6]. In my time with GNOME, I’ve been asked for my GitLab a lot.
We use GitLab for basically everything. In a typical day, I get several issues and reference bug reports, and I occasionally need to modify a file. I don’t do this in the capacity of being a developer or a sysadmin. I’m involved with the Engagement and Inclusion & Diversity (I&D) teams. I write newsletters for Friends of GNOME and interview contributors to the project. I work on sponsorships for GNOME events. I don’t write code, and I use GitLab every day.
The GNOME project has been managed a lot of ways over the past two decades. Different parts of the project used different systems to track changes to code, collaborate, and share information both as a project and as a social space. However, the project made the decision that it needed to become more integrated and it took about a year from conception to completion.
There were a number of reasons GNOME wanted to switch to a single tool for use across the community. External projects touch GNOME, and providing them an easier way to interact with resources was important for the project, both to support the community and to grow the ecosystem. We also wanted to better track metrics for GNOME—the number of contributors, the type and number of contributions, and the developmental progress of different parts of the project.
When it came time to pick a collaboration tool, we considered what we needed. One of the most important requirements was that it must be hosted by the GNOME community; being hosted by a third party didn’t feel like an option, so that discounted services like GitHub and Atlassian. And, of course, it had to be free software. It quickly became obvious that the only real contender was GitLab. We wanted to make sure contribution would be easy. GitLab has features like single sign-on, which allows people to use GitHub, Google, GitLab.com, and GNOME accounts.
We agreed that GitLab was the way to go, and we began to migrate from many tools to a single tool. GNOME board member [Carlos Soriano][7] led the charge. With lots of support from GitLab and the GNOME community, we completed the process in May 2018.
There was a lot of hope that moving to GitLab would help grow the community and make contributing easier. Because GNOME previously used so many different tools, including Bugzilla and CGit, it’s hard to quantitatively measure how the switch has impacted the number of contributions. We can more clearly track some statistics though, such as the nearly 10,000 issues closed and 7,085 merge requests merged between June and November 2018. People feel that the community has grown and become more welcoming and that contribution is, in fact, easier.
People come to free software from all sorts of different starting points, and it’s important to try to even out the playing field by providing better resources and extra support for people who need them. Git, as a tool, is widely used, and more people are coming to participate in free software with those skills ready to go. Self-hosting GitLab provides the perfect opportunity to combine the familiarity of Git with the feature-rich, user-friendly environment provided by GitLab.
It’s been a little over a year, and the change is really noticeable. Continuous integration (CI) has been a huge benefit for development, and it has been completely integrated into nearly every part of GNOME. Teams that aren’t doing code development have also switched to using the GitLab ecosystem for their work. Whether it’s using issue tracking to manage assigned tasks or version control to share and manage assets, even teams like Engagement and I&D have taken up using GitLab.
It can be hard for a community, even one developing free software, to adapt to a new technology or tool. It is especially hard in a case like GNOME, a project that [recently turned 22][8]. After more than two decades of building a project like GNOME, with so many parts used by so many people and organizations, the migration was an endeavor that was only possible thanks to the hard work of the GNOME community and generous assistance from GitLab.
I find a lot of convenience in working for a project that uses Git for version control. It’s a system that feels comfortable and is familiar—it’s a tool that is consistent across workplaces and hobby projects. As a new member of the GNOME community, it was great to be able to jump in and just use GitLab. As a community builder, it’s inspiring to see the results: more associated projects coming on board and entering the ecosystem; new contributors and community members making their first contributions to the project; and increased ability to measure the work we’re doing to know it’s effective and successful.
It’s great that so many teams doing completely different things (such as what they’re working on and what skills they’re using) agree to centralize on any tool—especially one that is considered a standard across open source. As a contributor to GNOME, I really appreciate that we’re using GitLab.
Get started with this open source to-do list manager
======
Todo is a powerful way to keep track of your task list. Learn how to use
it in the seventh in our series on 20 ways to be more productive with
open source in 2020.
![Team checklist][1]
Last year, I brought you 19 days of new (to you) productivity tools for 2019. This year, I'm taking a different approach: building an environment that will allow you to be more productive in the new year, using tools you may or may not already be using.
### Track your tasks with todo
Tasks and to-do lists are very near and dear to my heart. I'm a big fan of productivity (so much so that I do a [podcast][2] about it) and try all sorts of different applications. I've even [given presentations][3] and [written articles][4] about them. So it only makes sense that, when I talk about being productive, task and to-do list tools are certain to come up.
![Getting fancy with Todo.txt][5]
In all honesty, for being simple, cross-platform, and easily synchronized, you cannot go wrong with [todo.txt][6]. It is one of the two to-do list and task management apps that I keep coming back to over and over again (the other is [Org mode][7]). And what keeps me coming back is that it is simple, portable, understandable, and has many great add-ons that don't break it if one machine has them and the others don't. And since it is a Bash shell script, I have never found a system that cannot support it.
#### Set up todo.txt
First things first, you need to install the base shell script and copy the default configuration file to the **~/.todo** directory:
Next, set up the configuration file. I like to uncomment the color settings at this point, but the only thing that must be set up right away is the **TODO_DIR** variable:
```
`export TODO_DIR="$HOME/.todo"`
```
#### Add to-do's
To add your first to-do item, simply type **todo.sh add <NewTodo>**, and it will be added. This will also create three files in **$HOME/.todo/**: todo.txt, done.txt, and reports.txt.
After adding a few items, run **todo.sh ls** to see your to-do list.
![Basic todo.txt list][8]
#### Manage your tasks
You can improve it a little by prioritizing the items. To add a priority to an item, run **todo.sh pri # A**. The number is the number of the task on the list, and the letter "A" is the priority. You can set the priority as anything from A to Z since that's how it will get sorted.
To complete a task, run **todo.sh do #** to mark the item done and move the item to done.txt. Running **todo.sh report** will write a count of done and not done items to reports.txt.
The file format used for all three files is well documented, so you can make changes with your text editor of choice. The basic format of todo.txt is:
```
`(Priority) YYYY-MM-DD Task`
```
The date indicates the due date of a task, if one is set. When editing the file manually, just put an "x" in front of the task to mark it as done. Running **todo.sh archive** will move these items to done.txt, and you can work in that text file and archive the done items when you have time.
#### Set up recurring tasks
I have a lot of recurring tasks that I need to schedule every day/week/month.
![Recurring tasks with the ice_recur add-on][9]
This is where todo.txt's flexibility comes in. By using [add-ons][10] in **~/.todo.actions.d/**, you can add commands and extend the functionality of the base todo.sh. The add-ons are basically scripts that implement specific commands. For recurring tasks, the plugin [ice_recur][11] should fit the bill. By following the instructions on the page, you can set up tasks to recur in a very flexible manner.
![Todour on MacOS][12]
There are a lot of add-ons in the directory, including syncing to some cloud services. There are also links to desktop and mobile apps, so you can keep your to-do list with you on the go.
I've only scratched the surface of todo's functionality, so take some time to dig in and see how powerful this tool is! It really helps me keep on task every day.
Use Wireshark at the Linux command line with TShark
======
Learning to analyze network packets is a powerful skill.
![Multi-colored and directional network computer cables][1]
Most of the time when we connect to the internet, we don't think about the network protocols at work underneath that make it all possible. Right now, while you are reading this article, numerous packets are being exchanged by your computer and traveling across the internet.
To understand these protocols, you need a tool that can capture and help you analyze these packets. [Wireshark][2] is a popular open source graphical user interface (GUI) tool for analyzing packets. However, it also provides a powerful command-line utility called [TShark][3] for people who prefer to work on the Linux command line.
To try the examples in this article, you need to be connected to the internet. For any changes to TShark's command-line options or flags, please refer to the appropriate man pages and online [documentation][4]. Also, I am using Fedora for these examples.
```
[gaurav@testbox ~]$ cat /etc/fedora-release
Fedora release 30 (Thirty)
[gaurav@testbox ~]$
```
### Check your installation
First, ensure the required packages are installed:
```
[gaurav@testbox ~]$ rpm -qa | grep -i wireshark
wireshark-cli-3.0.1-1.fc30.x86_64
[gaurav@testbox ~]$
```
If the Wireshark package is installed, check whether the TShark utility is installed and, if so, which version:
```
[gaurav@testbox ~]$ tshark -v
TShark (Wireshark) 3.0.1 (23f278e2)
Built using gcc 9.0.1 20190312 (Red Hat 9.0.1-0.10).
[gaurav@testbox ~]$
```
If you are logged in as a regular, non-root user, you need sudo rights to use the TShark utility. Root users can skip sudo and directly run the **tshark** command.
### Find network devices available to TShark
Before TShark can analyze packets, it needs to capture those packets. Network packets are processed via a network interface card (NIC) on servers, workstations, or desktops or a WiFi card on laptops. Begin by identifying the NIC or WiFi card used to connect to the internet.
To identify what network devices are available to TShark, run the following command. My laptop (which I am using for these examples) shows:
```
[gaurav@testbox ~]$ sudo tshark -D
Running as user "root" and group "root". This could be dangerous.
1\. wlp61s0
2\. lo (Loopback)
3\. any
4\. virbr0
5\. enp0s31f6
6\. bluetooth-monitor
7\. nflog
8\. nfqueue
[gaurav@testbox ~]$
```
I am using my WiFi card to connect to my home router for accessing the internet. You can use the **ifconfig -a** command to view all network interfaces on a system. If the **ifconfig** command is not installed, you can use the newer **ip addr show** command instead. One of the interfaces should have an IP address assigned to it. For a specific interface, you can use **ifconfig <interface-name>**, for example:
```
`ifconfig wlp61s0`
```
### Capture some packets
Now that you know which interface is being used to connect to the internet, you can start capturing some packets using it. The **-i** option can be used to capture packets on this specific interface. You'll see a bunch of output that shows the network packets being transmitted via the interface, but you can stop it with the **Ctrl+C** command:
```
[gaurav@testbox ~]$ sudo tshark -i wlp61s0
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlp61s0'
1 0.000000000 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xa02b AAAA fedoraproject.org
2 0.000128115 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xcc47 A fedoraproject.org
3 0.000316195 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xe29d A fedoraproject.org
4 0.000616019 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xac7c AAAA fedoraproject.org
5 0.007963200 192.168.1.1 → 192.168.1.9 DNS 93 Standard query response 0xcc47 A fedoraproject.org A 185.141.165.254
6 0.009171815 192.168.1.1 → 192.168.1.9 DNS 93 Standard query response 0xe29d A fedoraproject.org A 185.141.165.254
7 0.011075350 192.168.1.1 → 192.168.1.9 DNS 322 Standard query response 0xa02b AAAA fedoraproject.org AAAA 2610:28:3090:3001:dead:beef:cafe:fed3 AAAA 2605:bc80:3010:600:dead:beef:cafe:fed9 AAAA 2604:1580:fe00:0:dead:beef:cafe:fed1 NS ns04.fedoraproject.org NS ns05.fedoraproject.org NS ns02.fedoraproject.org A 152.19.134.139 AAAA 2610:28:3090:3001:dead:beef:cafe:fed5 A 209.132.181.17 A 85.236.55.10 AAAA 2001:4178:2:1269:dead:beef:cafe:fed5
8 0.012458151 192.168.1.1 → 192.168.1.9 DNS 322 Standard query response 0xac7c AAAA fedoraproject.org AAAA 2605:bc80:3010:600:dead:beef:cafe:fed9 AAAA 2610:28:3090:3001:dead:beef:cafe:fed3 AAAA 2604:1580:fe00:0:dead:beef:cafe:fed1 NS ns05.fedoraproject.org NS ns02.fedoraproject.org NS ns04.fedoraproject.org A 152.19.134.139 AAAA 2610:28:3090:3001:dead:beef:cafe:fed5 A 209.132.181.17 A 85.236.55.10 AAAA 2001:4178:2:1269:dead:beef:cafe:fed5
^C8 packets captured
[gaurav@testbox ~]$
```
Look at the first two packets above; they are denoted by numbers at the beginning of the line:
```
1 0.000000000 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xa02b AAAA fedoraproject.org
2 0.000128115 192.168.1.9 → 192.168.1.1 DNS 77 Standard query 0xcc47 A fedoraproject.org
```
These lines include two IP addresses on either side of an arrow—these are the hosts that are exchanging the packet. The arrow's direction indicates which direction the packet is going. Therefore, **192.168.1.9 → 192.168.1.1** means the packet originated at host **192.168.1.9**, which is my laptop, and is headed for destination **192.168.1.1**, which is my home router. After the destination IP address, you see **DNS**, which is just the Domain Name System protocol, followed by a DNS query. More about that later.
You can limit the number of packets captured and displayed on the screen using the **-c** (count) option. The following example shows 10 packets being captured. Notice the protocols—you saw DNS above, and here there are other protocols like NTP and TCP:
```
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 -c 10
Running as user "root" and group "root". This could be dangerous.
The DNS protocol converts the hostname to an IP address and the IP address to a hostname. There are dedicated DNS (or name) servers, which you can query with either a hostname or an IP address. The example below uses the **nslookup** command to query the name servers to resolve a hostname to an IP address. Before you proceed, ensure the **bind-utils** package is installed:
```
[gaurav@testbox ~]$ rpm -qa | grep -i bind-utils
bind-utils-9.11.5-13.P4.fc30.x86_64
[gaurav@testbox ~]$
```
In order to query your name server, you need to find out which one your machine is talking to. You can find that information in the **/etc/resolv.conf** file. In my case, the name server is pointed to **1.1.1.1**, which is a public DNS service provided by Cloudflare:
```
[gaurav@testbox ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 1.1.1.1
[gaurav@testbox ~]$
```
Hostnames like Opensource.com are easy for humans to understand, but machines use IP addresses to connect to other machines over a network or the internet. For your computer to connect to opensource.com, it needs to find the site's IP address; you can find it with the command:
```
`nslookup opensource.com`
```
If **nslookup** is not available on your machine, you canuse the **dig** command instead:
```
`dig opensource.com`
```
But—_before you hit Enter_—open another terminal and type the following command to tell TShark to capture any traffic that goes to your name server (e.g., 1.1.1.1):
```
`sudo tshark -i wlp61s0 host 1.1.1.1`
```
Keep that terminal running and return to the other one, then run **nslookup** (or **dig**). When the command completes, it gives Opensource.com's IP address, which is 54.204.39.132. Here is **nslookup**'s output:
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlp61s0'
2 1.798275687 192.168.1.9 → 1.1.1.1 DNS 74 Standard query 0xcda0 A opensource.com
3 1.827143443 1.1.1.1 → 192.168.1.9 DNS 90 Standard query response 0xcda0 A opensource.com A 54.204.39.132
^C packets captured
[gaurav@testbox ~]$
```
The packet below originated from my laptop **192.168.1.9** and is headed for destination **1.1.1.1**. The packet is for the DNS protocol, and it's querying (Standard query) the name server for Opensource.com:
```
`2 1.798275687 192.168.1.9 → 1.1.1.1 DNS 74 Standard query 0xcda0 A opensource.com`
```
The packet below is a reply coming from my name server **1.1.1.1** to my machine **192.168.1.9**. Again, it's DNS, but now it's a response for the query (Standard query response) for Opensource.com's IP address:
```
`3 1.827143443 1.1.1.1 → 192.168.1.9 DNS 90 Standard query response 0xcda0 A opensource.com A 54.204.39.132`
```
If you know beforehand what protocol you are looking for, you can add it to the **tshark** command. The following example is looking only for UDP packets, but it captured DNS packets. This is because DNS packets use the UDP protocol underneath:
```
[gaurav@testbox ~]$ sudo tshark -i wlp61s0 udp
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlp61s0'
1 0.000000000 192.168.1.9 → 1.1.1.1 DNS 89 Standard query 0xcc6d A location.services.mozilla.com
2 0.000068640 192.168.1.9 → 1.1.1.1 DNS 89 Standard query 0x6484 AAAA location.services.mozilla.com
3 0.032616053 1.1.1.1 → 192.168.1.9 DNS 189 Standard query response 0xcc6d A location.services.mozilla.com CNAME locprod1-elb-eu-west-1.prod.mozaws.net A 52.215.71.87 A 54.72.168.141 A 34.253.23.107
4 0.108203529 1.1.1.1 → 192.168.1.9 DNS 241 Standard query response 0x6484 AAAA location.services.mozilla.com CNAME locprod1-elb-eu-west-1.prod.mozaws.net SOA ns-1260.awsdns-29.org
5 1.268489014 192.168.1.9 → 1.1.1.1 DNS 69 Standard query 0x74be A testbox
6 1.302652455 1.1.1.1 → 192.168.1.9 DNS 144 Standard query response 0x74be No such name A testbox SOA a.root-servers.net
7 6.268558254 192.168.1.9 → 1.1.1.1 DNS 79 Standard query 0xc47a A cups.pnq.redhat.com
8 6.268618039 192.168.1.9 → 1.1.1.1 DNS 79 Standard query 0xb08b AAAA cups.pnq.redhat.com
9 6.664992312 1.1.1.1 → 192.168.1.9 DNS 143 Standard query response 0xb08b AAAA cups.pnq.redhat.com SOA a1-68.akam.net
10 6.665088305 1.1.1.1 → 192.168.1.9 DNS 143 Standard query response 0xc47a A cups.pnq.redhat.com SOA a1-68.akam.net
^C10 packets captured
[gaurav@testbox ~]$
```
The **ping** command is often used to check if a machine is up or accessible over a network. You can run the **ping** command against Opensource.com's IP address to see if the server is up and running.
Before you do that, start a packet capture so you can analyze the packet later. Open a terminal and run the following command, which will keep running and looking for packets that are originating in or destined for IP address 54.204.39.132:
```
`sudo tshark -i wlp61s0 host 54.204.39.132`
```
In another terminal, run the following **ping** command. The **-c** is for count, so **-c 2** means it should send only two packets to the given host:
```
`ping -c 2 54.204.39.132`
```
From the terminal where you ran the **ping** command, you can see two packets were sent and two were received. It also says that there was 0% packet loss, which suggests that the destination 54.204.39.132 responded to the **ping** requests:
```
[gaurav@testbox ~]$ ping -c 2 54.204.39.132
PING 54.204.39.132 (54.204.39.132) 56(84) bytes of data.
64 bytes from 54.204.39.132: icmp_seq=1 ttl=43 time=357 ms
64 bytes from 54.204.39.132: icmp_seq=2 ttl=43 time=278 ms
\--- 54.204.39.132 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1ms
rtt min/avg/max/mdev = 278.045/317.410/356.776/39.369 ms
[gaurav@testbox ~]$
```
Move back to the terminal where TShark is running. It shows four packets: the requests in the **ping** command (**-c 2**) and two replies, hence a total of four packets:
```
Packet 1 - request (1st request)
Packet 2 - reply (to Packet 1)
Packet 3 - request (2nd request)
Packet 4 - reply (to Packet 3)
```
The output shows that it is using the [ICMP][5] protocol. **Ping** works over ICMP to complete its tasks:
Network packets are sent in binary format, so if you want to see how they look on the network, you can dump the packet's hexadecimal format by simply adding an **-x** to the **tshark** command, and you will see the hexadecimal output. The following output shows a **ping** request sent by running the command **ping -c 1 54.204.39.132**:
Seeing output on the screen is OK, but often you need to save data to a fileto use it later. Use the **ping** command but add **-w** to tell TShark to dump the output to a file. For example, the following saves the output to file named **nlog.pcap** within the **/tmp** directory:
Now run the **ping** command again from another terminal, but this time with a count of five packets:
```
`ping -c 5 54.204.39.132`
```
The TShark terminal shows that 10 packets were captured. Why 10? Because you asked **ping** to send five requests, and you got five replies, hence 10 packets. Use **Ctrl+C** to stop the packet capture:
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlp61s0'
10 ^C
[gaurav@testbox ~]$
```
TShark saved the output to the file **/tmp/nlog.pcap**:
```
[gaurav@testbox ~]$ ls -l /tmp/nlog.pcap
-rw-------. 1 root root 1692 Nov 2 21:10 /tmp/nlog.pcap
[gaurav@testbox ~]$
```
The **file** command shows the file type is a **pcapng** capture file, so you can't just open the file using an editor like Vim and start reading; all you'll see is a bunch of garbage characters:
```
[gaurav@testbox ~]$ sudo file /tmp/nlog.pcap
/tmp/nlog.pcap: pcapng capture file - version 1.0
[gaurav@testbox ~]$
```
Since TShark wrote the data to the file, it can read it back from the file as well using the **-r** option followed by the filename. The following shows all 10 packets (five requests and five replies):
```
[gaurav@testbox ~]$ sudo tshark -r /tmp/nlog.pcap
Running as user "root" and group "root". This could be dangerous.
A [TCP handshake][6] is done before establishing a connection over a network. The examples above just queried a name server or tried to determine whether a machine is reachable via a**ping** command, neither of which requires establishing a connection with the host. Try to fetch [www.opensource.com][7] via the **wget** command.
Before you run **wget**, run the following command in another terminal to capture packets. I have deliberately kept the count to three since the handshake involves initial packets:
```
`sudo tshark -i wlp61s0 -c 3 host 54.204.39.132`
```
Next, run the**wget**command to download the index file:
You can view the three packets below. The first packet sends a **SYN** request from my laptop to the Opensource.com server. The second packet is the Opensource.com server replying with a **SYN, ACK** flag set. Finally, the third packet is my laptop sending an **ACK** request to acknowledge receiving the second packet. This is called a TCP handshake. After this handshake, both nodes (i.e., my laptop and the Opensource.com server) can exchange data.
If you exclude **-c 3**, it will capture all packets, and you will see a similar ritual to close a connection. Only this time, my laptop sent a **FIN, ACK** packet to Opensource.com (in packet 1 below), followed by a **FIN, ACK** from Opensource.com to my laptop (in packet 2 below), and finally an **ACK** packet sent by my laptop to the Opensource.com server. This concludes the network connection that was established earlier, and any future connections will have to set up a TCP handshake again.
These days, most websites are accessed over HTTPS instead of HTTP. This ensures the data passed between the two nodes is encrypted on the wire as it passes through the internet. To ensure data is encrypted, a [TLS handshake][9] method, which is similar to the TCP handshake, happens.
Fire another **wget** command, but this time it captures 11 packets from the beginning:
The TCP handshake concludes in the first three packets, and the fourth to the ninth have various packets that have TLS strings, which follow a similar handshake ritual to set up a secure, encrypted connection between the two hosts:
10 0.940858609 192.168.1.9 → 54.204.39.132 TLSv1.2 240 Application Data
11 1.228530079 54.204.39.132 → 192.168.1.9 TLSv1.2 754 Application Data
11 packets captured
[gaurav@testbox ~]$
```
Because HTTPS works on port 443 by default, you can use it as a filter in TShark to capture traffic going to that specific port:
```
`sudo tshark -i wlp61s0 host 54.204.39.132 and port 443`
```
Timestamps are essential when you need to analyze packets offline to reconstruct events from the past, e.g., for debugging. Adding a **-t ad** flag to TShark will add timestamps to the beginning of each packet capture:
```
[gaurav@testbox ~]$ sudo tshark -n -i wlp61s0 -t ad
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlp61s0'
1 2019-11-02 21:43:58.344158174 25:c9:8e:3f:38:3a → 48:89:e7:a0:33:db ARP 42 Who has 192.168.1.9? Tell 192.168.1.1
2 2019-11-02 21:43:58.344194844 48:89:e7:a0:33:db → 25:c9:8e:3f:38:3a ARP 42 192.168.1.9 is at 48:89:e7:a0:33:db
3 2019-11-02 21:44:00.223393961 192.168.1.9 → 1.1.1.1 DNS 79 Standard query 0x00fb A cups.pnq.redhat.com
4 2019-11-02 21:44:00.223460961 192.168.1.9 → 1.1.1.1 DNS 79 Standard query 0x1814 AAAA cups.pnq.redhat.com
5 2019-11-02 21:44:00.266325914 1.1.1.1 → 192.168.1.9 DNS 143 Standard query response 0x00fb A cups.pnq.redhat.com SOA a1-68.akam.net
6 2019-11-02 21:44:00.269102767 1.1.1.1 → 192.168.1.9 DNS 143 Standard query response 0x1814 AAAA cups.pnq.redhat.com SOA a1-68.akam.net
^C6 packets captured
[gaurav@testbox ~]$
```
### View an entire packet
So far, you have seen several examples of packets and ways to interpret them but not an entire packet. Here's how to use **ping** and the **nslookup** utility to dump an entire packet:
```
[gaurav@testbox ~]$ ping -c 1 54.204.39.132
PING 54.204.39.132 (54.204.39.132) 56(84) bytes of data.
64 bytes from 54.204.39.132: icmp_seq=1 ttl=43 time=357 ms
\--- 54.204.39.132 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 356.961/356.961/356.961/0.000 ms
[gaurav@testbox ~]$
```
In another window, run the following command and then the **ping** command above. Notice the additional **-V** flag—it is used to dump the entire packet information on the screen. The output is divided into various sections, starting with Frames, then moving to Ethernet, then to Internet Protocol, and so on.
Once you are comfortable with these basics of packet capturing and analysis, you can utilize TShark's various capture and display filters when working on more advanced use cases. Refer to the online documentation for more information on these filters.
[12]: https://opensource.com/sites/default/files/uploads/productivity_7-4.png (Todour on MacOS)
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Xingyu Wang