Skip to main content

LAN Sharing

How hali turns your local network into a model distribution superhighway.

The idea​

Every machine on your LAN that runs hali acts as both a consumer and a provider. Models downloaded on one machine are automatically seeded to every other machine. The first person downloads from HuggingFace. Everyone else downloads from them at LAN speed.

No configuration. No NFS mounts. No USB drive handoff. It just works.

How LAN sharing works​

Quick LAN check​

Is it working?

# See what your machine is seeding
hali daemon status

The LAN AVAILABLE section shows models discovered from peers:

LAN AVAILABLE                               PEERS     INFOHASH
------------------------------------------  -----     --------
mistral:7b:instruct:q4_k_m                 1         a3f9c21b4d67…
llama:8b:instruct:q5_k_m                   2         f8c41dc0a13b…

The PEERS column tells you how many machines on the LAN have each model. If you see entries here, LAN sharing is working.

Setup requirements​

LAN sharing needs:

  1. The daemon running — hali daemon start or hali service install
  2. UDP multicast reachable — on 239.192.42.1:4269
  3. All machines on the same L2 network — multicast doesn't cross routers by default
  4. Firewall allowing UDP 4269 — inbound and outbound

That's it. If all four conditions are met, LAN sharing happens automatically.

HMAC authentication (optional)​

By default, LAN announcements are unsigned — any machine on the LAN can announce models. For environments where you want authenticated announcements:

# Enable HMAC auth
hali config set lan.hmac_enabled true

# All machines must use the same shared secret
hali config set lan.hmac_shared_secret <64-char-hex-key>

# Restart
hali service restart

The daemon auto-generates lan.secret (32 random bytes) at <DataDir>/lan.secret on first run. For authenticated mode, distribute this file to all machines (or set a manual hex key).

Announcements are signed with HMAC-SHA256. Packets with missing, wrong, or replayed signatures are silently dropped. A rogue machine on your network cannot inject fake model announcements.

Network diagnostics​

Check what the daemon sees​

hali network status
Mode: internet

Capabilities:
- LSD: enabled
- DHT: enabled
- PEX: enabled
- Trackers: enabled
- Public peers: enabled

Diagnostics:
- Public reachability: unknown
- Incoming peers: unavailable
- DHT connectivity: healthy

See recent LAN announcements​

hali network seen
MODEL ID                             NODE       AGE
---------------------------------    --------   ----
mistral:7b:instruct:q4_k_m          a3f29b...  12s
llama:8b:instruct:q5_k_m            f8c41d...  45s

Each entry represents a machine on your LAN that's seeding a model. The AGE column tells you how recently it was announced (announcements expire after a few minutes).

Pull directly from LAN​

Skip HuggingFace entirely and download from a LAN peer:

hali network pull

This opens an interactive picker of currently-announced models. Or specify one:

hali network pull mistral:7b:instruct:q4_k_m

If no LAN peer has it, the command fails — no internet fallback.

LAN architecture details​

Discovery: two-phase​

Phase 1 — the multicast channel tells you what models exist and their infohashes. This is the "gossip" layer.

Phase 2 — BitTorrent's Local Service Discovery (LSD) finds the actual IP address and port of the peer seeding that infohash. This is the "dial" layer.

Announcement fallback​

If UDP multicast fails (blocked by router policy, virtual interface issues, etc.), the daemon falls back to directed subnet broadcast on UDP 4269. This sends the announcement to every host on the subnet individually rather than using a multicast group.

If both multicast and broadcast fail, LAN mode degrades silently. Downloads fall back to HuggingFace HTTP.

Multi-interface awareness​

hali automatically sends multicast announcements across all usable IPv4 LAN interfaces. On Windows, this avoids the common problem where multicast goes to a virtual adapter (VPN, Hyper-V) instead of the physical LAN/Wi-Fi adapter.

Jitter​

Announcements are sent every 25–40 seconds with a random offset. This prevents all machines from announcing simultaneously and creating a packet storm.

Troubleshooting LAN​

"I know another machine has the model but I don't see it"​

  1. Confirm the sender has seeding entries:

    hali daemon status   # Look for "seeding" in the SEEDING section

  2. Check HMAC settings match (if using authenticated mode):

    hali config show | grep lan

  3. Verify the firewall allows UDP 4269:

    # Linux
    sudo ufw status | grep 4269
    # or
    sudo firewall-cmd --list-ports

    # Windows
    Get-NetFirewallRule | Where-Object { $_.LocalPort -eq 4269 }

  4. Check that packets are actually arriving:

    # Linux
    sudo tcpdump -ni any udp port 4269

    # Windows (requires Wireshark or pktmon)
    pktmon start --etw -p 0

  5. Verify L2 connectivity — both machines must be on the same broadcast domain. Routers and VLANs typically block multicast.

  6. Check the daemon isn't in LAN-only mode on the sender (rare — hali config show | grep daemon_listen_addr)

If packets don't arrive, the issue is in your network infrastructure (router, switch, AP), not in hali.

"I see the model but downloads are slow"​

LAN downloads use BitTorrent's wire protocol over TCP. Speed is limited by:

  • The sender's max_upload_mbps setting
  • Network congestion on the LAN
  • Wi-Fi bandwidth (wired LAN is recommended for large models)

Check and adjust:

hali config set max_upload_mbps 0    # Unlimited upload
hali config set max_download_mbps 0  # Unlimited download
hali service restart

Multi-machine example​

Three machines in an office lab:

Machine A: Downloads "llama:8b:instruct:q5_k_m" from HuggingFace → 45 minutes
Machine B: hali pull llama:8b → LAN peer found → downloads from A → 3 minutes
Machine C: hali pull llama:8b → LAN peers found → downloads from A and B → 2 minutes

Total internet bandwidth used: one download. Total time saved: hours. Configuration required: none.