How I Successfully Switched GitHub Accounts on My Local PC After Authentication and 403 Errors

Introduction

Recently, I needed to switch my local Git environment from one Git hosting account to another. My original setup was configured for an older developer account, but I wanted to push code to a repository owned by a different account.

At first, the process seemed straightforward—just update the Git username and email. However, I encountered multiple authentication issues, including:

• Logon failed errors

• Credential Manager conflicts

• GitHub 403 permission errors

• Personal Access Token (PAT) permission problems

This article documents the troubleshooting process and the final solution that worked.

---

Initial Configuration

My local Git configuration was still pointing to my old account:

git config --global user.name
# old_username

git config --global user.email
# old_email@example.com

The target repository was a newly created repository under a different account.

---

Step 1: Update Local Git Identity

I updated the Git username and email to match the new Git hosting account:

git config --global user.name "new_username"
git config --global user.email "new_email@example.com"

Verification:

git config --global user.name
git config --global user.email

This successfully updated the commit author information for future commits.

However, pushing to the remote repository still failed.

---

Step 2: Verify the Remote Repository

I checked the repository remote URL:

git remote -v

Output:

origin https://github.com/new_username/project_repository.git (fetch)
origin https://github.com/new_username/project_repository.git (push)

The remote was already configured correctly.

---

Step 3: Investigate Authentication Failures

Attempting to push resulted in:

Logon failed, use ctrl+c to cancel basic credential prompt.

This suggested that Git was using cached credentials from a previous configuration.

I checked Git's credential configuration:

git config --list --show-origin | findstr credential

Output:

file:"C:\ProgramData\Git\config" credential.helper=manager

The culprit was Git Credential Manager.

---

Step 4: Remove Git Credential Manager

Opening:

C:\ProgramData\Git\config

revealed:

[credential]
    helper = manager

I removed:

[credential]
    helper = manager

and saved the file.

Verification:

git config --list --show-origin | findstr credential

Output:

credential.https://dev.azure.com.usehttppath=true

The Credential Manager entry was gone.

---

Step 5: Push Again

After removing the Credential Manager configuration, Git finally prompted for credentials:

Username for 'https://github.com':

I entered:

new_username

Then:

Password for 'https://new_username@github.com':

I entered a GitHub Personal Access Token (PAT).

Unfortunately, I still received:

remote: Permission denied
fatal: The requested URL returned error: 403

---

Step 6: Discover the Real Problem

The issue was not the repository.

The issue was the token.

Inspecting the token revealed:

Repository access:
This token does not have access to any repositories.

Repository permissions:
This token does not have any repository permissions.

The token could authenticate the account but could not authorize repository actions such as pushing commits.

---

Step 7: Create a Proper Personal Access Token

I generated a new token with repository permissions.

For fine-grained tokens, the important settings were:

Repository access:
All repositories

and

Contents:
Read and Write

Without "Contents: Read and Write," GitHub rejects push operations with a 403 error.

---

Step 8: Push Successfully

After generating a properly configured PAT, I executed:

git push -u origin main

Git prompted for:

Username:
new_username

Password:
<Personal Access Token>

The result:

Counting objects: 22, done.
Compressing objects: 100% (18/18), done.
Writing objects: 100% (22/22), done.

[new branch] main -> main
Branch main set up to track remote branch main from origin.

Success.

The repository was successfully pushed under the new account.

---

Important Lesson: Git Identity vs GitHub Authentication

One of the biggest takeaways from this process is understanding the difference between:

Git Identity

git config --global user.name
git config --global user.email

These values determine:

• Commit author

• Commit email

• How commits appear in Git history

GitHub Authentication

Username + Personal Access Token

These determine:

• Which account is authenticated

• Which repositories can be accessed

• Whether pushes are authorized

Changing the Git identity does not automatically change GitHub authentication.

---

Final Thoughts

Switching GitHub accounts on a local machine can involve more than changing a username and email. Credential managers, cached authentication data, and token permissions can all introduce unexpected issues.

The solution ultimately required:

1. Updating Git identity

2. Verifying the remote repository

3. Removing Git Credential Manager configuration

4. Creating a PAT with correct repository permissions

5. Authenticating using the new account

Once these steps were completed, pushing to the remote repository worked as expected.

Hopefully, this walkthrough helps other developers avoid the same troubleshooting process and better understand the distinction between Git configuration and repository authorization.

Understanding Malware: Features, Analysis, and Mitigation

 Malware (short for malicious software) is any software intentionally designed to cause damage to systems, exfiltrate data, disrupt operations, or gain unauthorized access. For a cybersecurity engineer or professional, understanding how malware works is the foundation of effective malware analysis and defense. Without insight into typical malware behaviors, defensive strategies become guesswork. With proper understanding, however, detection, analysis, and mitigation become far more effective.

---

Typical Features of Malware

While malware comes in many forms (viruses, worms, trojans, ransomware, spyware, rootkits, etc.), most share common features:

1. Persistence Mechanisms

   • Registry modifications, scheduled tasks, startup scripts, or bootkits to survive reboots.

2. Obfuscation and Evasion

   • Code packing, encryption, polymorphism, or anti-VM/anti-debugging checks to avoid detection.

3. Command-and-Control (C2) Communication

   • DNS queries, HTTP/HTTPS requests, or custom protocols to communicate with a remote attacker.

4. Privilege Escalation

   • Exploiting vulnerabilities or misconfigurations to gain higher access rights.

5. Lateral Movement

   • Propagating across networks using exploits, stolen credentials, or file shares.

6. Data Exfiltration

   • Harvesting sensitive files, credentials, keystrokes, or screenshots.

7. Payload Execution

   • Ransomware encrypting files, spyware stealing data, or destructive malware wiping systems.

---

Why Understanding Malware Behavior Matters

A cybersecurity professional’s ability to defend against malware depends on their ability to think like an attacker. Malware analysis—whether static (examining code and binaries) or dynamic (observing malware in a sandbox or lab)—provides critical insights into:

• Indicators of Compromise (IoCs) such as file hashes, registry keys, domains, and IP addresses.

• Tactics, Techniques, and Procedures (TTPs) that map to frameworks like MITRE ATT&CK.

• Detection Opportunities in logs, network traffic, or endpoint activity.

• Weak Points in malware design that defenders can exploit for mitigation.

In short: knowing how malware behaves is the key to stopping it.

---

Case Study: WannaCry Ransomware

One of the most infamous malware outbreaks was the WannaCry ransomware attack in May 2017. It spread rapidly across the globe, exploiting a vulnerability in the Windows SMB protocol (EternalBlue, leaked from NSA tools).

Key Features Demonstrated by WannaCry:

• Exploit and Propagation: Used EternalBlue to spread without user interaction.

• Persistence and Encryption: Encrypted user files and demanded ransom payments in Bitcoin.

• C2 Communication: Contacted hardcoded domains for instructions. Interestingly, a researcher discovered a “kill switch” domain that, when registered, stopped the spread.

Lessons Learned:

• Unpatched systems remain the biggest vulnerability.

• Ransomware can cripple critical infrastructure (hospitals, telecoms, government services).

• Incident response speed and global collaboration are crucial.

WannaCry demonstrated how malware features—exploit delivery, lateral movement, payload execution, and C2—combine to create large-scale impact. It also underscored the value of understanding malware behaviors in order to recognize and stop such attacks quickly.

How to Safely Obtain Malware Samples for Analysis

For malware analysis training and research, it is critical to use legitimate, trusted sources that provide samples in a controlled manner. Never download samples from unverified websites. Below are safe options widely used by researchers:

1. TheZoo (GitHub project)

   • A collection of live and decompiled malware samples, provided for educational and research purposes.

2. MalwareBazaar (by abuse.ch)

   • A community-driven platform for sharing and downloading verified malware samples.

3. VX Underground

   • Large repository of malware samples and related research material.

4. Any.Run Malware Trends

   • Interactive sandbox environment where samples can be downloaded after free registration.

Best Practices When Handling Samples:

• Use a dedicated analysis environment (isolated VMs or air-gapped lab).

• Never run malware on your host OS or on production networks.

• Take snapshots of your VMs before testing.

• Store samples in password-protected archives (common password: infected).

• Always follow your organization’s ethical and legal guidelines when accessing or analyzing samples.

Effective Mitigation Strategies

1. Preventive Controls

• Regular Patching: Keep OS and applications updated to close vulnerabilities.

• Least Privilege: Limit user rights to reduce the impact of compromise.

• Application Whitelisting: Only allow trusted software to run.

2. Detection Controls

• Endpoint Detection and Response (EDR): Monitor for suspicious processes, memory injections, or abnormal behavior.

• Network Monitoring: Watch for unusual DNS lookups, beaconing patterns, or data exfiltration attempts.

• Threat Intelligence: Use IoCs and TTPs from previous incidents to hunt for new infections.

3. Response Controls

• Incident Response Plans: Ensure a structured process for containment, eradication, and recovery.

• Backups: Maintain offline or immutable backups to recover from ransomware.

• Forensics and Analysis: Investigate malware samples to learn and strengthen defenses.

4. User Awareness

• Security Training: Educate staff about phishing, social engineering, and safe browsing.

• Simulated Attacks: Run phishing simulations and red-team exercises.

---

Conclusion

Malware continues to evolve, but its core features remain predictable: persistence, evasion, communication, escalation, and payload delivery. By studying how malware works, cybersecurity professionals gain the knowledge needed to anticipate attacks, detect infections early, and respond effectively.

Successful malware analysis is not about tools alone—it’s about understanding the adversary’s mindset. With this knowledge, organizations can implement strong preventive, detective, and responsive measures to reduce risk and ensure resilience against evolving threats.

Benign C++ Simulator — Source Code and Feature Discussion

Below is a safe, single-file C++ simulator you can include in your lab to emulate common malware network behaviors for testing with INetSim. It is intentionally non-destructive and only performs DNS lookups, HTTP/HTTPS GETs, and printed simulated actions. Build and run only in isolated lab environments.

// safe-fake-malware-simulator.cpp
// Purpose: A *benign* simulator for malware network behavior for lab/testing with INetSim.
// - DOES NOT perform destructive actions, persistence, propagation, or privilege escalation.
// - Only performs harmless DNS lookups and HTTP GET requests to a user-specified host/IP.
// - Use in isolated, offline lab networks only.

// Build: sudo apt update && sudo apt install -y libcurl4-openssl-dev
// Compile: g++ -std=c++17 -O2 -o fake_beacon safe-fake-malware-simulator.cpp -lcurl
// Run (example): ./fake_beacon --target inetsim.local --interval 10 --count 5

#include <iostream>
#include <string>
#include <thread>
#include <chrono>
#include <cstdlib>
#include <vector>
#include <cstring>
#include <netdb.h>
#include <arpa/inet.h>
#include <curl/curl.h>
#include <random>

static size_t write_callback(void* contents, size_t size, size_t nmemb, void* userp) {
    // Discard body (we only want headers/status). This keeps the program non-destructive.
    (void)contents; (void)userp; return size * nmemb;
}

std::vector<std::string> resolve_hostname(const std::string &host) {
    std::vector<std::string> addrs;
    struct addrinfo hints, *res, *p;
    std::memset(&hints, 0, sizeof(hints));
    hints.ai_family = AF_UNSPEC; // IPv4 or IPv6
    hints.ai_socktype = SOCK_STREAM;

    int rv = getaddrinfo(host.c_str(), nullptr, &hints, &res);
    if (rv != 0) {
        std::cerr << "[DNS] getaddrinfo: " << gai_strerror(rv) << "\n";
        return addrs;
    }

    char ipstr[INET6_ADDRSTRLEN];
    for (p = res; p != nullptr; p = p->ai_next) {
        void *addr;
        if (p->ai_family == AF_INET) { // IPv4
            struct sockaddr_in *ipv4 = (struct sockaddr_in *)p->ai_addr;
            addr = &(ipv4->sin_addr);
        } else { // IPv6
            struct sockaddr_in6 *ipv6 = (struct sockaddr_in6 *)p->ai_addr;
            addr = &(ipv6->sin6_addr);
        }
        inet_ntop(p->ai_family, addr, ipstr, sizeof(ipstr));
        addrs.push_back(std::string(ipstr));
    }
    freeaddrinfo(res);
    return addrs;
}

std::string get_random_user_agent() {
    static const std::vector<std::string> user_agents = {
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
        "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko",
        "curl/7.68.0",
        "Python-urllib/3.8",
        "Java/1.8.0_291",
        "Go-http-client/1.1",
        "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15"
    };
    
    static std::random_device rd;
    static std::mt19937 gen(rd());
    std::uniform_int_distribution<> dis(0, user_agents.size() - 1);
    
    return user_agents[dis(gen)];
}

int http_get(const std::string &url, long &http_code, long timeout_sec) {
    CURL *curl = curl_easy_init();
    if (!curl) return -1;
    
    curl_easy_setopt(curl, CURLOPT_URL, url.c_str());
    curl_easy_setopt(curl, CURLOPT_NOBODY, 0L); // fetch body (but our callback discards it)
    curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, write_callback);
    curl_easy_setopt(curl, CURLOPT_TIMEOUT, timeout_sec);
    curl_easy_setopt(curl, CURLOPT_USERAGENT, get_random_user_agent().c_str());
    
    // Follow redirects in a controlled manner
    curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
    curl_easy_setopt(curl, CURLOPT_MAXREDIRS, 3L);
    
    // For lab use only: disable SSL verification (to work with self-signed certs)
    curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L);
    curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L);
    
    CURLcode res = curl_easy_perform(curl);
    if (res != CURLE_OK) {
        std::cerr << "[HTTP] curl error: " << curl_easy_strerror(res) << "\n";
        curl_easy_cleanup(curl);
        return -1;
    }
    
    curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &http_code);
    curl_easy_cleanup(curl);
    return 0;
}

void simulate_icmp_ping(const std::string& target_ip) {
    std::cout << "[ICMP] Simulating ping to " << target_ip << " (no actual packets sent)\n";
    std::cout << "[ICMP] Would send: ping -c 1 " << target_ip << " (simulated only)\n";
}

void simulate_dns_query(const std::string& domain) {
    std::cout << "[DNS-TUNNEL] Simulating DNS query for " << domain << ".sub.example.com\n";
    std::cout << "[DNS-TUNNEL] Would resolve: " << domain << ".sub.example.com (simulated only)\n";
}

void usage(const char *prog) {
    std::cout << "Safe Fake " << prog << " - benign INetSim traffic simulator\n";
    std::cout << "Usage: " << prog << " --target <host-or-ip> [--interval <seconds>] [--count <n>] [--https]\n";
    std::cout << "Example: " << prog << " --target inetsim.local --interval 10 --count 5 --https\n";
    std::cout << "Options:\n";
    std::cout << "  --target    Target hostname or IP address (required)\n";
    std::cout << "  --interval  Seconds between beacons (default: 5)\n";
    std::cout << "  --count     Number of beacons (0 = run forever, default: 0)\n";
    std::cout << "  --https     Use HTTPS instead of HTTP\n";
    std::cout << "  --icmp      Simulate ICMP ping requests\n";
    std::cout << "  --dns-tunnel Simulate DNS tunneling attempts\n";
}

int main(int argc, char** argv) {
    if (argc < 3) {
        usage(argv[0]);
        return 1;
    }

    std::string target;
    int interval = 5; // seconds between beacons
    int count = 0; // 0 = run forever
    bool use_https = false;
    bool simulate_icmp = false;
    bool simulate_dns_tunnel = false;

    for (int i = 1; i < argc; ++i) {
        std::string a = argv[i];
        if (a == "--target" && i + 1 < argc) { target = argv[++i]; }
        else if (a == "--interval" && i + 1 < argc) { interval = std::atoi(argv[++i]); }
        else if (a == "--count" && i + 1 < argc) { count = std::atoi(argv[++i]); }
        else if (a == "--https") { use_https = true; }
        else if (a == "--icmp") { simulate_icmp = true; }
        else if (a == "--dns-tunnel") { simulate_dns_tunnel = true; }
        else { usage(argv[0]); return 1; }
    }

    if (target.empty()) { usage(argv[0]); return 1; }

    std::cout << "[INFO] Starting benign simulator. Target=" << target 
              << " interval=" << interval << "s count=" << count 
              << " HTTPS=" << (use_https ? "yes" : "no") << "\n";
    std::cout << "[WARNING] This tool should only be used in isolated lab environments!\n";

    curl_global_init(CURL_GLOBAL_DEFAULT);

    int iterations = 0;
    while (count == 0 || iterations < count) {
        ++iterations;
        std::cout << "\n[BEACON] Iteration " << iterations << "\n";

        // 1) DNS lookup
        std::cout << "[DNS] Resolving: " << target << "\n";
        auto addrs = resolve_hostname(target);
        if (addrs.empty()) {
            std::cout << "[DNS] No addresses found or resolution failed.\n";
        } else {
            for (const auto &ip : addrs) std::cout << "[DNS] -> " << ip << "\n";
            
            // Use first resolved IP for ICMP simulation
            if (simulate_icmp && !addrs.empty()) {
                simulate_icmp_ping(addrs[0]);
            }
        }

        // 2) HTTP/HTTPS GET to target
        std::string url = target;
        if (url.find("://") == std::string::npos) {
            url = (use_https ? "https://" : "http://") + url + "/";
        }

        long code = 0;
        std::cout << "[HTTP] GET " << url << " (User-Agent: " << get_random_user_agent() << ")\n";
        if (http_get(url, code, 10) == 0) {
            std::cout << "[HTTP] Response code: " << code << "\n";
        } else {
            std::cout << "[HTTP] Request failed.\n";
        }

        // 3) Simulate DNS tunneling if enabled
        if (simulate_dns_tunnel) {
            simulate_dns_query(target);
        }

        // 4) Simulated "beacon" payload (harmless)
        std::cout << "[SIM] Local status: {\"host\":\"simulated-host\", \"uptime\":\"0d0h\", \"note\":\"benign-test\"}\n";

        // Sleep with improved jitter algorithm
        static std::random_device rd;
        static std::mt19937 gen(rd());
        std::uniform_int_distribution<> dis(-interval, interval);
        
        int jitter = dis(gen);
        int sleep_for = std::max(1, interval + jitter);
        std::cout << "[SLEEP] Sleeping " << sleep_for << " seconds (base: " << interval << "s, jitter: " << jitter << "s)...\n";
        std::this_thread::sleep_for(std::chrono::seconds(sleep_for));
    }

    curl_global_cleanup();
    std::cout << "[INFO] Finished. Total iterations: " << iterations << "\n";
    return 0;
}

Overall Purpose

This program is a benign malware network behavior simulator. Its sole purpose is to safely mimic the network traffic patterns of real malware—specifically, the "beaconing" activity to a Command & Control (C2) server—for the purpose of testing security tools like INetSim (a lab service that simulates internet services) in a controlled, isolated environment.

Crucially, it is completely harmless. It does not perform any destructive, persistent, or malicious actions. It only generates network traffic.

Detailed Breakdown by Component

1. The write_callback Function

static size_t write_callback(void* contents, size_t size, size_t nmemb, void* userp) {
    (void)contents; (void)userp; return size * nmemb;
}

• What it does: This function is called by the libcurl library whenever it receives data (the HTML body) from the HTTP request.

• The Key Detail: It discards all the data it receives. The (void)contents; line is a deliberate way to ignore the data, preventing it from being processed or saved to disk. This ensures the program is non-destructive.

2. The resolve_hostname Function

std::vector<std::string> resolve_hostname(const std::string &host) {
    // ... (code uses getaddrinfo) ...
    inet_ntop(p->ai_family, addr, ipstr, sizeof(ipstr));
    addrs.push_back(std::string(ipstr));
    // ...
}

• What it does: This function performs a DNS lookup on the provided hostname (e.g., inetsim.local).

• How it works: It uses the standard getaddrinfo() system call to query the system's DNS resolver. It correctly handles both IPv4 and IPv6 addresses (AF_UNSPEC), converts the binary address to a human-readable string (inet_ntop), and returns a list of all IP addresses associated with the hostname.

• Why it's important: The first step for most malware is to resolve the domain name of its C2 server to an IP address. This simulates that exact behavior.

3. The get_random_user_agent Function

std::string get_random_user_agent() {
    static const std::vector<std::string> user_agents = { /* ... */ };
    // ... (random selection code) ...
    return user_agents[dis(gen)];
}

• What it does: Returns a random string from a predefined list of web browser and tool User-Agents.

• Why it's important: Real malware often randomizes its User-Agent to blend in with normal web traffic and avoid simple detection rules that look for a single, suspicious string. This adds a layer of realism.

4. The http_get Function

int http_get(const std::string &url, long &http_code, long timeout_sec) {
    CURL *curl = curl_easy_init();
    curl_easy_setopt(curl, CURLOPT_URL, url.c_str());
    // ... (other options) ...
    CURLcode res = curl_easy_perform(curl);
    curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &http_code);
}

• What it does: This is the core function that performs an HTTP or HTTPS GET request to the target URL using the libcurl library.

• Key Configuration:

  • CURLOPT_NOBODY, 0L: Fetches the body (but the callback discards it).

  • CURLOPT_FOLLOWLOCATION, 1L: Follows HTTP redirects (like a real browser would).

  • CURLOPT_SSL_VERIFYPEER, 0L: Disables SSL certificate verification. This is critical for lab use where tools like INetSim use self-signed certificates, but it's a major security risk in the real world.

  • CURLOPT_USERAGENT: Uses the random User-Agent from the function above.

• The Goal: It successfully connects to the target web server, completes the HTTP request, and retrieves the response status code (e.g., 200 OK, 404 Not Found). This simulates the malware "checking in" with its C2 server.

5. The main Function (The Orchestrator)

This is where the program's workflow is executed.

Phase 1: Argument Parsing

• It reads command-line arguments like --target, --interval, and --count.

• It sets flags for optional behaviors like --https, --icmp, and --dns-tunnel.

Phase 2: The Main Loop ("Beaconing")
The program enters a loop that runs for the specified number of counts (or forever if count=0). Each loop iteration represents one "beacon" or "check-in."

1. DNS Resolution: It calls resolve_hostname(target) and prints the results. This is the first network call, simulating malware figuring out where to call home.

2. ICMP Simulation (Optional): If the --icmp flag is used, it only prints a message simulating a ping. It does not send any actual ICMP packets. This tests monitoring for network discovery attempts.

3. HTTP Request: It constructs the full URL (adding http:// or https:// if needed) and calls http_get. This is the core beaconing activity, simulating the malware requesting commands from its server.

4. DNS Tunneling Simulation (Optional): If the --dns-tunnel flag is used, it only prints a message about making a DNS query. It does not perform actual DNS tunneling. This tests alerting for suspicious DNS patterns.

5. Status Report: It prints a harmless, fake JSON status message to the console. This simulates the kind of data malware might report back to its operator (system info, uptime).

6. Sleep with Jitter: This is a critical feature.

std::uniform_int_distribution<> dis(-interval, interval);
int jitter = dis(gen);
int sleep_for = std::max(1, interval + jitter);

1. • It doesn't sleep for a fixed time. It adds a random "jitter" (e.g., for --interval 10, it might sleep for 7, 10, or 13 seconds).

   • Why? Real malware uses jitter to avoid being detected by simple timing-based signatures. A regular, metronomic beacon every 10 seconds is easy to spot. An irregular pattern is much stealthier.

Phase 3: Cleanup

• After the loop finishes, it cleans up the libcurl resources and exits.

---

Summary: What the Program Actually Does on the Network

When you run ./fake_beacon --target inetsim.local --interval 10 --count 5, the program will:

1. 5 times, roughly every 10 seconds (with some random variation):

2. Query your DNS server for the IP address(es) of inetsim.local.

3. Open a TCP connection to port 80 (HTTP) on the IP it received from DNS.

4. Send a complete HTTP GET request for the path /, with a random User-Agent header.

5. Read the HTTP response from the server (and immediately discard the content), only noting the status code.

6. Print all of these actions to the console for you to see.

7. Sleep until it's time for the next beacon.

It is a perfect, safe tool for generating traffic that will trigger security monitoring tools looking for: DNS queries to suspicious domains, beaconing HTTP traffic, and irregular network communication patterns—all without any risk to your system or network.