Get support

Classify the problem

Place the problem in one category before contacting support: checkout, destination configuration, verification, stream arrival, packet loss, packet size, address change, renewal, or expiration. Do not combine unrelated symptoms into one report when they occurred at different times or destinations.

Support contact is ${CONTACT_EMAIL}. The product publishes no guaranteed response time, support schedule, escalation policy, telephone channel, or service-level agreement. Send a compact evidence set by email.

Never include a wallet secret, private key, recovery phrase, host password, or active verification token. Support can investigate delivery using the destination ID, public pair, timestamps, and network observations.

Record the destination facts

1. Copy the destination ID from the dashboard.
2. Copy the displayed destination IP.
3. Copy the displayed UDP port.
4. Copy the displayed service state.
5. Copy the displayed expiration time when present.
6. Record the current UTC time with date -u +'%Y-%m-%dT%H:%M:%SZ'.

No exact dashboard labels or timestamp format are published. Copy the visible values associated with the affected destination and label them in your message.

Every verification and stream datagram originates from ${SOURCE_IP}. Include whether the receiving network currently permits ${SOURCE_IP}/32 over UDP to the destination port.

Confirm the receiver binding

Replace 9000 with the affected port and run:

sudo ss -ulnp | grep ':9000 '

Save the complete matching line. An empty result indicates that this textual filter found no visible UDP listener. It does not inspect a container or network namespace you did not enter. Identify the namespace in the support report when the receiver runs in one.

Record the receiver process name, version or build identifier, bind address, restart time, and packet counter. The product does not prescribe a receiver implementation, so support cannot infer these values from the destination ID.

Observe the network path

Run a bounded capture after replacing 9000:

sudo tcpdump -n -i any -vv -c 20 'src host 203.23.178.228 and udp dst port 9000'

Record whether the command captured packets, the first and last displayed timestamps, and the packet lengths. Do not email binary shred payloads unless support requests a specific bounded sample and you have approved that disclosure.

When verification fails, start capture before asking for another challenge. Each request emits one verification datagram. Report whether tcpdump saw it and whether the application's printed payload had SHREDCAST-VERIFY as its prefix.

When stream delivery fails after verification, keep the same capture filter. If tcpdump sees traffic but the application does not, focus on the host firewall, socket binding, namespace, receive buffer, and process. If tcpdump sees nothing, focus on the registered pair, upstream firewall, route, NAT mapping, and destination state.

Collect host UDP counters

Run the host's UDP statistics command before and after a defined observation interval. On Linux with net-tools installed, use:

netstat -su

Include the UDP packet-receive and receive-error lines. State the interval in UTC. Available tools and counter names vary with the operating system, which the product leaves open.

Do not send an isolated cumulative counter without a baseline. A large lifetime total does not show that drops occurred during the incident. Capture before and after values around the same interval used for application counters.

Inspect every firewall layer

List the active rule that permits source ${SOURCE_IP}/32, protocol UDP, and the destination port. Identify whether the rule belongs to iptables, nftables, ufw, an AWS security group, a GCP firewall, a network ACL, or another device.

Do not send the entire firewall configuration if it contains unrelated infrastructure details. Extract the matching rule and its counter when available. State whether a cloud rule and host rule both exist.

For NAT, provide the public IP and port, internal IP and port, protocol, and mapping type. Do not replace a sensitive internal network diagram with vague wording; provide the specific mapping needed to trace this destination.

Build the support message

1. Set the subject to the problem category and destination ID.
2. State the observed symptom in one sentence.
3. State the expected behavior in one sentence.
4. Provide the UTC start and end time.
5. Provide the destination IP and UDP port.
6. Provide the dashboard state.
7. Provide the receiver binding output.
8. Provide the tcpdump result.
9. Provide the UDP counter delta.
10. Provide the matching firewall rule.
11. Provide the NAT mapping when applicable.
12. Send the message to ${CONTACT_EMAIL}.

Use a symptom such as verification challenge absent from tcpdump instead of service broken. Use a measured result such as 0 matching datagrams from 14:05:00Z to 14:06:00Z instead of no packets for a while.

Preserve the failing state when safe

Avoid changing the destination repeatedly while collecting evidence. Each destination permits three address changes per day and each change requires re-verification. Record the current state before changing it.

Do not disable all firewall controls as a diagnostic. Add or inspect the narrow ${SOURCE_IP} UDP rule. A broad public rule can introduce unrelated traffic and obscure packet counters.

Do not restart every network component at once. A coordinated restart destroys evidence about where packets stopped. Change one customer-controlled layer at a time after recording its prior state.

Report commercial issues separately

For a payment or renewal problem, provide the destination ID, asset used, transaction signature when available, payment time, and dashboard result. Payment uses USDC or SOL on Solana. Do not send wallet secrets. Confirmation requirements, refund behavior, and payment investigation times are not currently specified.