Repair Tools

In SimNet's Network Repair category, the network is broken from the start — a route is missing, the DNS server is not running, an IP address is misconfigured. Your job is to act like a network engineer: find the problem, fix it, and get the data flowing again.

It is like taking delivery of a second-hand car and only after starting it discovering that the brake line is severed, the GPS gives wrong directions, and the tire pressure is off. You have to work through each fault one by one.

Route Management — Fixing Lost Packets

When to use it

When pinging a device returns destination unreachable or no reply at all, the router is often missing a route to the target network. The packet reaches the router, the router checks its routing table, finds no entry, and drops the packet — much like a GPS that cannot find the destination.

Commands

View the routing table:

simnet@router1:~$ ip route
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1

If you expect the router to reach the subnet 10.0.1.0/24 but it is not listed, that is the problem.

Add a route:

simnet@router1:~$ ip route add 10.0.1.0/24 dev eth1
Route added: 10.0.1.0/24 dev eth1

This tells the router: "To reach the 10.0.1.0/24 network, send traffic out via the eth1 interface."

You can also forward through another router:

simnet@router1:~$ ip route add 172.16.0.0/24 via 10.0.0.2
Route added: 172.16.0.0/24 via 10.0.0.2

via means "by way of" — packets are first sent to 10.0.0.2, which then forwards them onward.

Diagnostic flow

1. From the PC, ping the target → fails.
2. SSH into the router → run ip route to inspect the routing table.
3. Identify the missing route → add it with ip route add.
4. Return to the PC → ping again to confirm.

How do I know which route to add?

Read the topology. If the server's IP is 10.0.1.3, its subnet is 10.0.1.0/24. Find the router interface (e.g. eth1) that connects to that subnet, and the route is ip route add 10.0.1.0/24 dev eth1.

Related challenges

The template ships no built-in example challenge for Network Repair; downstream forks adopting this template can add one following the quickstart on the Challenge examples home page.

DNS Service Management — Fixing Name Resolution Failures

When to use it

When curl http://flag.simnet.local/flag fails with a DNS-related error (for example Could not resolve host), the DNS server has a problem. Common causes: the DNS service is not running, or the A record (the IP record for the domain) does not exist.

DNS is like the phone book of the network — if the phone book service is closed, knowing your friend's name is not enough to call them.

Commands

Check the DNS service status:

simnet@dns-server:~$ systemctl status dns
● dns.service - DNS Server
   Loaded: loaded
   Active: inactive (dead)

inactive (dead) means the service is not running.

Start the DNS service:

simnet@dns-server:~$ systemctl start dns
● dns.service - DNS Server
   Active: active (running)

Or use the shorthand:

simnet@dns-server:~$ service dns start
Starting DNS server... OK

Stop the service (when you need to restart it):

simnet@dns-server:~$ systemctl stop dns
simnet@dns-server:~$ systemctl start dns

Diagnostic flow

1. From the PC, run nslookup flag.simnet.local → no answer.
2. SSH into the DNS server → run systemctl status dns to check the state.
3. If the service is not running → systemctl start dns to start it.
4. Back on the PC → nslookup again to confirm resolution works.
5. Fetch the flag with curl.

Related challenges

The template ships no built-in example challenge for Network Repair; downstream forks can add their own.

IP Configuration — Fixing Address Errors

When to use it

When a device's IP address is misconfigured — for example, the server is supposed to sit on the 10.0.1.0/24 subnet but its IP is set to 10.0.2.100 — even if every other device's routing is correct, packets that reach that subnet still cannot find the server.

It is like your address is registered wrong: the courier reaches the right neighborhood but cannot find your front door.

Commands

Inspect the current IP configuration:

simnet@server1:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP>
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether aa:bb:cc:00:03:00
    inet 10.0.2.100/24 scope global eth0

If the topology says the server should be on the 10.0.1.0/24 subnet but the output shows 10.0.2.100/24, the IP is wrong.

Change the IP address:

simnet@server1:~$ ip addr set 10.0.1.3/24 dev eth0
IP address updated: eth0 → 10.0.1.3/24

Diagnostic flow

1. Check the topology for the IP each device "should" have.
2. SSH into the suspicious device → run ip addr to inspect the actual settings.
3. If the IP is wrong → fix it with ip addr set.
4. Return to the PC and test connectivity.

Related challenges

The template ships no built-in example challenge for IP configuration errors; downstream forks can add their own.

Service Management — Restarting Faulty Services

When to use it

A server runs a variety of services (HTTP server, DNS server, etc.). If a service crashes or its config file is wrong, even when you can reach the server you still will not get the response you need.

It is like a restaurant whose kitchen has caught fire — the front door is open, customers are seated, the waitstaff is there, but no food comes out.

Commands

Check service status:

simnet@web-server:~$ systemctl status http
● http.service - HTTP Server
   Active: active (running)
   Listening: 0.0.0.0:80

simnet@web-server:~$ systemctl status http
● http.service - HTTP Server
   Active: failed (exit code: 1)

Start / stop / restart the service:

simnet@web-server:~$ systemctl start http     # start
simnet@web-server:~$ systemctl stop http      # stop
simnet@web-server:~$ systemctl start http     # stop then start = restart

Shorthand:

simnet@web-server:~$ service http start
simnet@web-server:~$ service http stop

Inspect the config file:

simnet@web-server:~$ cat /etc/nginx/nginx.conf

If the config points at the wrong directory or listens on the wrong port, the service can be running yet still not work correctly.

Diagnostic flow

1. From the PC, run curl or nslookup → fails.
2. SSH into the server → systemctl status <service> to inspect.
3. If the service is not running → systemctl start <service>.
4. If the service is running but misbehaving → cat the config file to look for problems.
5. After the fix, return to the PC to verify.

Related challenges

The template ships no built-in example challenge for service management; downstream forks can add their own.

Repair Workflow Overview

When facing a broken network, work through the checks in this order:

1. From the PC, ping the target
   ├─ Reachable → problem is probably not in the network layer; check the application service
   └─ Not reachable → keep digging
       │
2. Check the PC's own configuration
   └─ ip addr → is the IP correct?
   └─ ip route → is there a default route?
       │
3. SSH into the router to check
   └─ ip route → is there a route to the target?
   └─ show interfaces → are the interfaces UP?
       │
4. SSH into the target server to check
   └─ ip addr → is the IP correct?
   └─ systemctl status → is the service running?

Working outward from yourself toward the destination is also the standard method in real network operations — confirm you are fine first, then check the path in between, and finally inspect the destination.

Cheat Sheet

Tool	Command	Where to Run It	What It Fixes
View routes	ip route	Router	Confirm the routing table is complete
Add route	ip route add <net> dev <iface>	Router	Restore reachability to a missing subnet
View service	systemctl status <svc>	Server	Confirm whether a service is running
Start service	systemctl start <svc>	Server	Restart a failed service
View IP	ip addr	Any device	Confirm the IP configuration is correct
Change IP	ip addr set <ip>/<mask> dev <iface>	Target device	Correct a wrong IP address
View config	cat <config-file>	Server	Inspect a service's configuration file