Files

Deploy to Phoenix / deploy (push) Has been cancelled

Details

docs: Ledger Live integration, contract deploy learnings, NEXT_STEPS updates

- ADD_CHAIN138_TO_LEDGER_LIVE: Ledger form done; public code review repo bis-innovations/LedgerLive; init/push commands
- CONTRACT_DEPLOYMENT_RUNBOOK: Chain 138 gas price 1 gwei, 36-addr check, TransactionMirror workaround
- CONTRACT_*: AddressMapper, MirrorManager deployed 2026-02-12; 36-address on-chain check
- NEXT_STEPS_FOR_YOU: Ledger done; steps completable now (no LAN); run-completable-tasks-from-anywhere
- MASTER_INDEX, OPERATOR_OPTIONAL, SMART_CONTRACTS_INVENTORY_SIMPLE: updates
- LEDGER_BLOCKCHAIN_INTEGRATION_COMPLETE: bis-innovations/LedgerLive reference

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-02-12 15:46:57 -08:00

2.9 KiB

Raw Permalink Blame History

IDS/IPS and Long-Lived WebSocket RPC Connections

Last Updated: 2026-01-31
Document Version: 1.0
Status: Active Documentation

Purpose: Sanity-check impact of IDS/IPS on long-lived WebSocket connections to Chain 138 RPC (wss://rpc-ws-pub.d-bis.org, wss://ws.rpc.d-bis.org, wss://ws.rpc2.d-bis.org, wss://wss.defi-oracle.io).

1. What to allow

Item	Recommendation
Protocol	WebSocket over TLS (WSS) on port 443
Hostnames	`rpc-ws-pub.d-bis.org`, `ws.rpc.d-bis.org`, `ws.rpc2.d-bis.org`, `wss.defi-oracle.io` (and HTTP equivalents for upgrade)
Traffic	JSON-RPC over WebSocket (text frames); same as HTTP RPC payloads
Connection lifetime	Long-lived (minutes to hours). Wallets and nodes may hold WS open for subscriptions (e.g. newHeads, logs).
Direction	Client → 76.53.10.36:443 (then to 192.168.11.167 → 192.168.11.221:8546)

2. Typical IDS/IPS considerations

Risk	Mitigation
TLS inspection	If you decrypt TLS to 76.53.10.36, ensure WebSocket upgrade (HTTP/1.1 101 Switching Protocols) and binary/text frames are not dropped or delayed. Some IDS break WS if they buffer or reassemble incorrectly.
Session timeouts	Do not set short idle timeouts (e.g. 60s) on 443 to the RPC hostnames; WS may be idle between subscription events. 300s+ or no timeout for established WS is safer.
Rate limiting	Per-IP or per-URL rate limits should allow at least multiple connections and frames per second; WS can have bursty traffic (blocks, logs).
Signatures	JSON-RPC methods (eth_subscribe, eth_unsubscribe, eth_chainId, etc.) are normal. Avoid blocking on "JSON-RPC" or "eth_" in TLS payloads if signatures are too broad.

3. What to avoid

Blocking WebSocket upgrade (e.g. Upgrade: websocket, Connection: Upgrade) on 443.
Aggressive TCP RST on long idle connections that are actually live WS.
Deep inspection that buffers or modifies WS frames and breaks the JSON-RPC stream.

4. Quick sanity check

From a host that can reach the RPC, open a WebSocket to wss://rpc-ws-pub.d-bis.org and send eth_chainId; expect 0x8a.
Leave the connection open for 5–10 minutes; send another request. If the second request fails or the connection drops, check IDS/IPS timeouts and TLS/WS handling.
Run: pnpm run verify:ws-chain138 (or node scripts/verify-ws-rpc-chain138.mjs). From LAN use NPM_HOST=192.168.11.167 pnpm run verify:ws-chain138 to hit NPMplus directly.

5. Summary

Allow: WSS to rpc-ws-pub.d-bis.org, ws.rpc.d-bis.org, ws.rpc2.d-bis.org, and wss.defi-oracle.io on 443, long-lived.
Don’t: Short idle timeouts, blocking WebSocket upgrades, or deep inspection that breaks WS frames.
Validate: Use scripts/verify-ws-rpc-chain138.mjs and manual long-lived WS test.

2.9 KiB Raw Permalink Blame History Unescape Escape