From Camera to Ethernet: A Journey into Networking

This article is a journal of an interesting network troubleshooting journey, starting from a seemingly simple request: connect an industrial camera to a laptop. It led me from one frustration to another "Aha!" moment, and ultimately, to exploring many core networking concepts.

Part 1: The First Failure - PoE#

I had a problem: get image data from an industrial camera to my laptop. I noticed the camera used an RJ45 cable—a standard Ethernet cord.

A very natural idea: plug the camera directly into the laptop's Ethernet port.

But... nothing happened. No signal, no blinking lights, nothing. The strange thing was, when this camera was connected to a small PC cluster provided by the manufacturer, it streamed just fine.

After fiddling around for a bit, I realized the problem: PoE (Power over Ethernet).

What is PoE?#

PoE is a technology that allows Ethernet cables to transmit both data and electrical power over the same cable. Industrial cameras (and many devices like IP cameras, Access Points) often use PoE to avoid needing an extra power cord.

• The Problem: Laptops and standard PCs do not supply power through their Ethernet ports.
• The (Manufacturer's) Solution: That small PC cluster almost certainly had built-in PoE.
• My Frustration: The switch I had just bought (TL-SG1016D) was an excellent unmanaged switch, but it did not support PoE. I had bought the wrong one. I should have bought the TL-SG1016PE version (the "P" usually indicates PoE).

While waiting to order a PoE Injector, I decided to do a "side quest" to test my network setup.

Part 2: Side Quest - SSH over Ethernet#

The Wi-Fi in my room is sometimes very weak, severely interrupting SSH sessions from my laptop (Ubuntu) to my PC (Ubuntu).

Why not just use the PC? I'm used to the dev environment on my laptop, and this helps me get accustomed to developing on a server—an important skill in the cloud age.

I thought: why not connect the two machines via Ethernet? It would definitely be faster, and more importantly... it would work even if the internet was down!

Test 1: Laptop $\rightarrow$ PC (Directly) I used an RJ45 cable to connect the two machines directly. And again... nothing. No signal. ¹

Test 2: Laptop $\rightarrow$ Switch $\rightarrow$ PC I used my TL-SG1016D switch as an intermediary. This time, the link lights on the switch and both machines lit up!

Checking on both machines:

# Laptop
$ ip a
enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
       link/ether 60:18:95:56:8e:ff brd ff:ff:ff:ff:ff:ff
 
# PC
$ ip a
enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
       link/ether d8:43:ae:c7:d6:76 brd ff:ff:ff:ff:ff:ff

Both network cards were UP,LOWER_UP (meaning the physical link was good). But I couldn't ping or ssh.

The "Aha!" Moment: A Switch is Not a Router#

This was when I realized a fundamental concept:

• Switch (Unmanaged - Layer 2): My switch operates at Layer 2 (Data Link) of the OSI model. It only cares about MAC addresses. It forwards data frames based on MAC, like a smart mail carrier within a single building.
• Communication (Layer 3): To ssh or ping, computers need to talk to each other using IP addresses (Layer 3 - Network).
• The Problem: My devices didn't have IP addresses on this network! They were waiting for someone to assign them an IP.

Most of us are used to "plug and play" because the Router at home (or at work) has an integrated service called a DHCP Server, which automatically assigns IPs to every device. My "dumb" switch didn't have that capability.

Solution: Assign Static IPs. I decided to create a local network 10.0.0.0/24 (a private IP range).

# On Laptop
sudo ip addr add 10.0.0.1/24 dev enp2s0
sudo ip link set enp2s0 up
 
# On PC
sudo ip addr add 10.0.0.2/24 dev enp3s0
sudo ip link set enp3s0 up

And...

# On Laptop
$ ssh my-user@10.0.0.2
Welcome to Ubuntu ...

Success! I turned off Wi-Fi on both machines, and the SSH session was still perfectly smooth.

Part 3: Back to the Camera (Consumer Version)#

While waiting for the PoE injector, I grabbed a consumer IP camera (Tapo) to test. My goal was to set up an internal RTSP stream: both secure (not going through the company's cloud) and fast.

I plugged the camera into the switch. And a new problem began:

• I already had a 10.0.0.0/24 network (with my laptop at 10.0.0.1).
• But the camera had no interface for me to assign a static IP. It was designed to "plug and play"—meaning, it expected a DHCP Server.

At this point, my network consisted of the Laptop (10.0.0.1) and the Camera (no IP), both plugged into the switch. How could I know what the camera was doing?

The Investigation Phase: Listening to the Network#

arp-scan I tried an ARP scan to see if there were any devices on the network. ARP (Address Resolution Protocol) is the protocol that maps IPs (Layer 3) to MACs (Layer 2).

$ sudo arp-scan --interface=enp2s0 --localnet
...
Ending arp-scan 1.10.0: 256 hosts scanned in 1.842 seconds. 0 responded

Nothing. This makes sense: the camera didn't have an IP yet, so it couldn't respond to an ARP packet "asking who has IP...".

tcpdump This is where I could listen for the camera's "cry for help." I ran tcpdump to capture all packets on the enp2s0 port.

$ sudo tcpdump -i enp2s0 -n
...
11:32:31.913390 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 8c:90:2d:13:ba:e6, length 285

There it is! A fantastic discovery.

Anatomy of a DHCPDISCOVER Packet#

Let's break down this "cry for help" packet:

• 11:32:31.913390: The timestamp.
• IP 0.0.0.0.68: Source. The camera doesn't have an IP, so it uses 0.0.0.0. Port 68 is the DHCP client port.
• > 255.255.255.255.67: Destination. This is the Broadcast address. The camera is "shouting" to everyone on the network: "IS ANYONE A DHCP SERVER?" Port 67 is the DHCP server port.
• Request from 8c:90:2d:13:ba:e6: This packet was sent from this MAC address. I checked the bottom of the camera, and it was a perfect match!

This is a DHCPDISCOVER packet, the first step of the 4-step DORA process.

Part 4: The Solution - Laptop Becomes DHCP Server#

If the camera needs a DHCP Server, well... I'll become a DHCP Server. My laptop (Ubuntu) is perfectly capable of doing this.

I installed isc-dhcp-server and configured the /etc/dhcp/dhcpd.conf file. I didn't just want to give it a random IP; I wanted to pin the camera to a fixed IP.

# /etc/dhcp/dhcpd.conf
default-lease-time 600;
max-lease-time 7200;
authoritative;
 
# My internal network
subnet 10.0.0.0 netmask 255.255.255.0 {
  # Assign IPs in this range
  range 10.0.0.10 10.0.0.20;
  # Gateway (is my laptop)
  option routers 10.0.0.1;
}
 
# This is the important part: DHCP Reservation
# I'm pinning the camera's MAC address
# to a fixed IP I want it to have
host tapo_cam {
  hardware ethernet 8c:90:2d:13:ba:e6;
  fixed-address 10.0.0.50;
}

After starting the service, I checked the log (journalctl -u isc-dhcp-server -f):

Nov 08 11:37:28 midori dhcpd[12418]: DHCPDISCOVER from 8c:90:2d:13:ba:e6 via enp2s0
Nov 08 11:37:29 midori dhcpd[12418]: DHCPOFFER on 10.0.0.50 to 8c:90:2d:13:ba:e6 via enp2s0
Nov 08 11:37:29 midori dhcpd[12418]: DHCPREQUEST for 10.0.0.50 (10.0.0.1) from 8c:90:2d:13:ba:e6 via enp2s0
Nov 08 11:37:29 midori dhcpd[12418]: DHCPACK on 10.0.0.50 to 8c:90:2d:13:ba:e6 via enp2s0

The DORA Process, Perfected#

This log shows the 4-step process exactly:

• Discover: The camera (8c:90:2d:13:ba:e6) shouts (DHCPDISCOVER).
• Offer: My laptop (dhcpd) replies: "I have IP 10.0.0.50 for you" (DHCPOFFER).
• Request: The camera confirms: "Great, I'll take IP 10.0.0.50" (DHCPREQUEST).
• Acknowledge: The laptop finalizes: "Ok, IP 10.0.0.50 is yours" (DHCPACK).

And the result:

# On Laptop
$ ping 10.0.0.50
PING 10.0.0.50 (10.0.0.50) 56(84) bytes of data.
64 bytes from 10.0.0.50: icmp_seq=1 ttl=64 time=1.56 ms

I did it! The camera has an IP, and I can watch the stream via: rtsp://<user>:<pass>@10.0.0.50:554/stream

Conclusion#

From a seemingly simple failure with PoE, I went on a journey from static IPs, differentiating Switches/Routers, analyzing tcpdump packets, and finally, building my own DHCP server with a static reservation.

This journey reminded me that understanding the layers of a network isn't just abstract theory; it's the most powerful troubleshooting tool you have.

Now... I'm just not sure if that industrial camera will be as "polite" as this one in waiting for DHCP. But that's a story for the day my PoE Injector arrives.