# TinyCore Wi-Fi Recovery and Network Bring-Up

## Overview

TinyCore Linux is deliberately small, but its small userland can still handle
surprisingly practical network recovery tasks.

One particularly useful combination is:

```text
BusyBox
+
udhcpc
+
USB tethering
```

This can provide a temporary network connection even when the machine's own
wireless hardware is not working.

This makes it possible to obtain a required driver or package using nothing
more than:

```text
TinyCore machine
+
Android phone
+
USB cable
```

The procedure described below has been tested across multiple TinyCore-based
environments and is particularly useful on older hardware where the installed
wireless driver does not match the adapter.

---

# Part I: Recovering Wi-Fi with the `wl` Driver

## 1. Inspect the Currently Loaded Wireless Modules

Start by checking the 802.11-related modules:

```bash
lsmod | grep 80211
```

A problematic Broadcom configuration may show modules such as:

```text
mac80211
b43
cfg80211
```

Additional Broadcom support modules may also be present, depending on the
hardware and kernel.

Before replacing the driver, identify what is actually loaded:

```bash
lsmod | grep -E 'b43|ssb|bcma|brcmsmac|brcmfmac|wl|mac80211|cfg80211'
```

This is preferable to unloading modules blindly.

---

## 2. Remove the Conflicting Driver

If the installed adapter is intended to use the proprietary Broadcom `wl`
driver, unload the conflicting modules first:

```bash
sudo modprobe -r b43 mac80211 cfg80211
```

If the kernel reports that a module is still in use, inspect the dependency
chain with:

```bash
lsmod
```

and remove dependent modules only when appropriate.

The important point is that `wl` should not be competing with another driver
for the same hardware.

---

## 3. Load `wl`

The `wl` package must already be available locally.

In TinyCore this can be loaded through AppBrowser, for example using the
local-loading mechanism.

Once the module is available:

```bash
sudo modprobe wl
```

Verify that it loaded:

```bash
lsmod | grep wl
```

A successful result should contain:

```text
wl
```

---

## 4. Check the Network Interface

Inspect the available interfaces:

```bash
ifconfig -a
```

and:

```bash
ip link
```

For wireless hardware, also try:

```bash
iwconfig
```

Depending on the driver and the TinyCore environment, the interface may appear
as:

```text
eth1
```

rather than the more familiar:

```text
wlan0
```

For example:

```text
eth1   IEEE 802.11  ESSID:off/any  Mode:Managed
```

The interface name should always be confirmed on the actual machine rather
than assumed.

---

## 5. Bring the Interface Up

If the interface exists but is down:

```bash
sudo ifconfig eth1 up
```

or:

```bash
sudo ip link set eth1 up
```

Check again:

```bash
ip link
```

At this stage the kernel should have a working network interface.

The interface still needs to associate with an access point and obtain an IP
address before normal network access is available.

---

# Part II: Preventing the Old Driver from Returning

If `wl` works correctly, the older Broadcom modules can be blacklisted.

Create the modprobe configuration directory if necessary:

```bash
sudo mkdir -p /etc/modprobe.d
```

Create the blacklist:

```bash
cat <<EOF | sudo tee /etc/modprobe.d/blacklist.conf
blacklist b43
blacklist ssb
blacklist bcma
blacklist brcmsmac
blacklist brcmfmac
EOF
```

This prevents the listed drivers from being automatically loaded when the
system initializes.

The exact modules required depend on the Broadcom chipset, so the blacklist
should be treated as hardware-specific rather than a universal TinyCore
configuration.

---

# Part III: Load `wl` Automatically

To load `wl` during TinyCore startup:

```bash
echo "wl" | sudo tee /etc/sysconfig/modules
```

This places the module in TinyCore's startup module configuration.

Because TinyCore uses its own persistence mechanism, simply changing `/etc` is
not enough.

The configuration must also be included in the backup.

---

## 6. Add the Configuration to TinyCore Persistence

Add the relevant directories to `/opt/.filetool.lst`:

```bash
echo "/etc/modprobe.d" | sudo tee -a /opt/.filetool.lst
echo "/etc/sysconfig/modules" | sudo tee -a /opt/.filetool.lst
```

Then create a backup:

```bash
filetool.sh -b
```

This preserves the configuration across TinyCore reboots.

Without this step, a perfectly working configuration can disappear the next
time the machine starts.

That is one of the defining characteristics of TinyCore: **runtime changes
and persistent changes are two different things.**

---

# Part IV: The Emergency Network Path

## Android USB Tethering + TinyCore

This is one of the most useful tricks when working with very old hardware.

Suppose the machine has:

```text
TinyCore
+
no working Wi-Fi
+
no Ethernet
```

but an Android phone is available.

Enable **USB tethering** on the Android phone and connect it to the TinyCore
machine with a USB cable.

Linux may expose the phone connection as:

```text
usb0
```

TinyCore's BusyBox networking tools can then obtain an address using:

```bash
udhcpc -i usb0
```

This is remarkably small infrastructure for what it accomplishes.

The path becomes:

```text
Android phone
     
      USB tethering
     
   usb0
     
     
 TinyCore
     
      udhcpc
          
          
       Internet
```

No wireless driver is required on the TinyCore machine.

No Wi-Fi configuration is required.

No desktop environment is required.

---

## Why This Matters

This creates a useful recovery loop:

```text
TinyCore
   
    USB tethering
   
Android phone
   
   
Internet
   
   
download driver/package
   
   
TinyCore
   
    load driver
```

A phone can therefore act as a temporary network adapter for a machine whose
own network hardware is unavailable.

This is particularly valuable on old computers where the correct wireless
driver may not be included in the TinyCore image.

If the only hardware available is:

```text
old computer
+
Android phone
+
USB cable
```

the phone can provide just enough networking to bootstrap the rest of the
system.

---

# Part V: WPA Supplicant

Once the wireless interface itself works, the next layer is wireless
authentication.

The following minimal configuration is suitable for TinyCore, TazPup, SliTaz,
and similar lightweight Unix/Linux environments using `wpa_supplicant`.

Create:

```bash
sudo nano /etc/wpa_supplicant.conf
```

Add:

```text
network={
    ssid="Network_Name"
    psk="Network_Password"
}
```

For a hidden network, the configuration may additionally contain:

```text
scan_ssid=1
```

A priority can also be assigned:

```text
priority=1
```

For example:

```text
network={
    ssid="Network_Name"
    psk="Network_Password"
    scan_ssid=1
    priority=1
```

---

## Restart the Wireless Interface

Bring the interface down and back up:

```bash
sudo ifconfig wlan0 down
sudo ifconfig wlan0 up
```

If the driver exposes the interface under another name, replace `wlan0`
accordingly.

For example, some older drivers may expose:

```text
eth1
```

instead.

Always verify with:

```bash
ip link
```

before choosing the interface name.

---

## Start `wpa_supplicant`

Run:

```bash
sudo wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf
```

The options mean:

```text
-B     run in the background
-i     select the wireless interface
-c     specify the configuration file
```

If the interface is `eth1`, for example:

```bash
sudo wpa_supplicant -B -i eth1 -c /etc/wpa_supplicant.conf
```

---

# Part VI: Obtain an IP Address

Once authentication has completed, request an address through DHCP:

```bash
sudo udhcpc -i wlan0
```

If `dhclient` is available, it may also be used:

```bash
sudo dhclient wlan0
```

On very small distributions, `udhcpc` is often the more realistic choice
because it is part of BusyBox.

Check the resulting configuration:

```bash
ifconfig wlan0
```

or:

```bash
ip addr show wlan0
```

---

# Part VII: Test the Connection

First test raw IP connectivity:

```bash
ping -c 3 8.8.8.8
```

Then test DNS:

```bash
ping -c 3 google.com
```

These two tests distinguish between:

```text
network connectivity
```

and:

```text
DNS resolution
```

If the IP address works but the hostname does not, the wireless connection
itself is probably functional and the remaining problem is DNS configuration.

---

# Part VIII: Persistence

TinyCore is designed around a small, largely immutable base system.

Therefore, once the configuration works, remember to save it.

Depending on what was changed, relevant paths may include:

```text
/etc/modprobe.d
/etc/sysconfig/modules
/etc/wpa_supplicant.conf
```

Add required paths to:

```text
/opt/.filetool.lst
```

and save the backup:

```bash
filetool.sh -b
```

The exact persistence requirements depend on the TinyCore version and the
components being configured.

---

# Complete Recovery Chain

The whole process can be viewed as several independent layers:

```text
                    NETWORK RECOVERY
                           
             
                                        
        USB tethering                 Wi-Fi
                                        
          usb0                     wireless driver
                                        
        udhcpc                    wl / other driver
                                        
         temporary                  interface
         Internet                      
                                 wpa_supplicant
                                        
                                      DHCP
                                        
             
                            
                         network
```

This separation is useful when troubleshooting.

First establish that the **kernel sees the hardware**.

Then establish that the **network interface exists**.

Then establish **wireless association**.

Then obtain an **IP address**.

Finally test **routing and DNS**.

Do not treat all of these as one problem.

---

# Practical Recovery Scenario

A typical old-hardware recovery session might therefore look like this:

```text
Old x86 machine
      
       TinyCore boots
      
       Wi-Fi driver missing
      
       Android phone connected by USB
      
       USB tethering enabled
      
       udhcpc -i usb0
      
       temporary Internet access
      
       required driver/package obtained
      
       wl loaded
      
       wireless interface appears
      
       wpa_supplicant
      
       udhcpc
      
       native Wi-Fi restored
```

This is a good example of why tiny Unix environments remain useful on obsolete
hardware.

The system does not need a large graphical network manager.

It needs a kernel, a driver, a few small utilities, and a path to the network.

And when the machine's own networking is broken, **the phone in your pocket can
temporarily become the missing network adapter.**