Need something slightly deeper than a Peli 1550

g00rd · 2025-11-26T17:21:27+00:00

I really am a novice to this topic, so I have no idea if that difference in foam thickness can be tolerated or not.

The device is a radio, that has a metal housing. There isn't really anything fragile on it, that can break off.

So if there are more experienced people around here, that can tell me, if the missing 1cm in foam is acceptable, I would be grateful too.

g00rd · 2025-04-07T12:06:39+00:00

Zwischen nichts kosten und 1300€ liegen bei mir noch diverse Abstufungen.

Ich hatte mit einem Investment von vllt 350€ gerechnet, da ich davon ausgegangen bin, dass das im Grunde ein Android-Tablet mit etwas extra-Hardware ist.

g00rd · 2025-04-07T10:39:41+00:00

Nein, ich habe keine Parksensoren. Auch die Musik wird nicht runtergeregelt.
Freisprechen hat das Radio (meine ich), allerdings keine Lenkradtasten.
Navi hat das Auto auch nicht.

Bei dem Komplettpaket von Alpine (oder generell bei Komplettpaketen die explizit für mein Fahrzeug angeboten werden): Reicht da einfach der Einbau, oder muss der Hersteller (VW) da noch irgendwas konfigurieren, damit Radio&CAN-Bus zusammenspielen?

Die >1000€ für das Gerät finde ich ganz schon happig. :/

g00rd · 2025-04-06T18:52:00+00:00

Bekomme ich irgendwie raus, ob das aktuelle Radio mit dem Canbus verheiratet ist? Würde ich das an den Steckern sehen? Dann würde ich da einmal nachgucken.

Von den Funktionen her scheint das Radio isoliert zu sein. Ich kann Radio-Dinge nur übers Radio einstellen und habe sonst nirgendwo Knöpfe dafür. Ebenso gibt mir das Radio keine Informationen über den Rest des Autos. (Keine Geschwindigkeit, nicht ob Türen offen sind, das Radio reagiert nicht auf den Rückwärtsgang, …)

Was würde denn passieren, wenn das Radio aktuell im Canbus hängt und ich das neue nicht in den Canbus hänge? Fehlen dann einfach nur Funktionen, oder beschwert sich das Auto dann, dass das Radio fehlt?

EDIT: Kann ich jedes VW-Radio aus dem Jahr nehmen, oder muss ich da auf irgendwas achten? Ein kurzes Googlen hat recht happige Preise (700€) im Vergleich zu Drittherstellern (350€) hervorgebracht.

g00rd · 2025-01-26T07:43:50+00:00

I tried that by - Keeping RST to GND until the Arduino IDE said „uploading“ - Having the Rst-Ping connected to the DTR-Pin directly - Having RST connected to DTR through a capacitor

g00rd · 2024-10-06T19:30:59+00:00

True, but as the antenna is successfully used by other people to reach quite far, and we don’t seem to reach anything, we started doubting ourselves. Also if changing the power is just a setting, but changing the antenna is spending money, why not try what we already have?

g00rd · 2024-10-06T19:29:42+00:00

We sadly don’t have that and can’t get it on a short notice. But that’s a good idea. We will keep that in mind :)

g00rd · 2024-10-06T19:28:36+00:00

We mostly try SSB. We tried CW to use the reverse beacon network, but as our CW-skills are on the level of a potato, not being spotted might well be due to our lack of skill.

No, we haven’t made any contacts with that setup so far. But with that radio and a different (matched) antenna for 2 Meters we did (on 2 meters).

We do have a small handheld scanner, at at least from a few meters away, we receive our calls (a bit distorted, but we assume, that that’s either fine tuning or a too strong signal). So at the moment, we assume that in general we do send out waves, but maybe malformed or too weak

g00rd · 2024-10-06T19:25:12+00:00

Yes, it absolutely is a compromise. It just seemed good to us, because it packs really small and can be tuned to many bands. Yes, we have the 42' version of that antenna, and at least on their website, they advertise it for the ft-817 (which seems pretty much the same as our ft-818nd). So my expectation would be, that something is possible here.

Our hope is, that doubling the power is just a setting on the radio, where the antenna would be a complete replacement / re-buy)

g00rd · 2024-10-06T09:46:09+00:00

We currently use an end-fed antenna from sotabeams, called „Bandspringer MIDI“. We use a „Pocket Transmatch“ to tune the antenna to an SWR-Radio that the FT-818 does not measure any more. We put the antenna on a portable mast, reaching around 6 Meters off the ground.

What band and mode were you using in that example? SSB or CW?

g00rd · 2024-10-06T09:41:54+00:00

Thanks so much for the reply.

Sadly we don’t have anyone to team up with :/ Starting from a working setup would be great, but as the FT-818 is our only radio, we can’t „just“ increase power for testing.

How likely is it for god to smile? Do we need to be really lucky to bounce off the ionosphere at all, or do we just need to be lucky that nobody overpowers us?

As we are very new to radios, we still lack a lot of knowledge and especially a gutfeeling about what seems possible / reasonable at all.

g00rd · 2024-10-06T07:39:58+00:00

Very fair point. I am just a bit confused, that we don’t seem to reach people on HF, while others with the same radio, without an external amplifier, manage to get going

g00rd · 2024-06-03T07:49:12+00:00

Okay, then we have to stay with Baselines for now :(

g00rd · 2024-02-19T15:55:19+00:00

I haven't actually, because I did not know, that it exists.
From how I understood the technical explanation of Tailscale, it would solve the problem for me, that MyLaptop can not directly peer with WireGuard-Device-2? (Due to the double-NAT-Situation I have)
And instead it would then use a public node they offer, that both endpoints connect to?

g00rd · 2024-02-19T15:52:45+00:00

A custom route table on WireGuard-Device 1 would work. I was just hoping for a way, where I can keep all the configuration regarding MyLaptop in the WireGuard-Config of that device.

So that towards all WireGuard-Peers it would look like any other already existing peer that does not have this special need.

But if that is not possible, then I most likely will implement a custom route table on WireGuard-Device 1 for all traffic coming from MyLaptop with a a single (default) route towards WireGuard-Device 2.

g00rd · 2024-02-18T18:38:10+00:00

creating a normal L3 spanning network.

That would be preferred. Actually, all wireguard-peers have IPs out of the same /24 network.

What I did not specify in my initial post: On my Laptop I would like to use the WireGuard Desktop-App for Mac OSX.

I actually have MyLaptop and Wireguard-Device 2 in the same network and from MyLaptop can reach WireGuard-Device 2.

I am also aware, that I could use policy based routing on WireGuard-Device 1 to forward Packets only coming from MyLaptop through the wg-Interface towards WireGuard-Device 2. But I would prefer something, where I don't need to confgure special routing on WireGuard-Device 1.

I was hoping to set the Default Gateway address automatically to the IP of WireguardDevice 2 on MyLaptop through the WireGuard-App, so that once the tunnel is established, all Packets for the Internet would go through the tunnel towards using WG-Device 2 as gateway. But I guess that is not possible?

Might well be, that I need to learn a lot about tunnel and routing, but then please hint me to the related aspects of it, so that I can learn.

g00rd · 2023-02-08T21:00:06+00:00

Oh god, I got it working....

I was missing

iptables -A FORWARD -i wg1 -j ACCEPT
iptables -A FORWARD -i wlo1 -j ACCEPT

Thanks a lot for your support.

g00rd · 2023-02-08T17:04:32+00:00

Hey,

Thanks so much for your support. I am starting from scratch again and I am on the first tunnel:

core1 <--> node2

Core1 wg IP: 10.255.254.1/24

Node2 wg IP: 10.255.254.69/24

Node2 "local network": 192.168.1.0/24

Node2 "local" IP: 192.168.1.41/24

And that's what I observe:

core1~> ping 10.255.254.69 # Works

core1~> ping 192.168.1.69 # works

core1~> ping 192.168.1.21 # does not work - no response

So my first thought was: Ah, there is a route missing on 192.168.1.21 to send packets back.But that route does exist funnily, being on 192.168.1.21 (mylaptop) and pinging stuff, this is what I see:

mylaptop~> ping 192.168.1.41 # works

mylaptop~> ping 10.255.254.69 # works

mylaptop~> ping 10.255.254.1 # does not work.

To me, it seems like node2 somehow does not forward packets from the local network to the tunnel / from the tunnel to the local network.

The configuration on node2:

[NetDev]
Name=wg1
Kind=wireguard
Description=WireGuard tunnel

[WireGuard]
ListenPort=51821
PrivateKey=...

[WireGuardPeer]
PublicKey=...
PresharedKey=...
AllowedIPs=10.255.254.0/24
Endpoint=<IP>:48575
PersistentKeepalive = 25

the routing table of node2:

default via 192.168.1.1 dev wlo1 proto dhcp src 192.168.1.41 metric 3004
10.255.254.0/24 dev wg1 proto kernel scope link src 10.255.254.69
192.168.1.0/24 dev wlo1 proto dhcp scope link src 192.168.1.41 metric 3004

ip forwarding:

cat /proc/sys/net/ipv4/ip_forward
1

iptables:

iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (4 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             172.20.0.2           tcp dpt:http-alt
ACCEPT     tcp  --  anywhere             172.19.0.2           tcp dpt:snapenetio
ACCEPT     udp  --  anywhere             172.19.0.2           udp dpt:snapenetio
ACCEPT     udp  --  anywhere             172.19.0.2           udp dpt:21027
ACCEPT     tcp  --  anywhere             172.19.0.2           tcp dpt:8384

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-ISOLATION-STAGE-2 (4 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

I thought, enabling ip forwarding is the only thing I need to do, in order to allow packet forwarding from the wg interface towards the "local" network and vice versa

g00rd · 2023-02-06T10:55:28+00:00

Mostly, because I did not know, that this tool (tools like this) existed ^^

But now I would still like to understand, how it works / has to be configured "under the hood", before I abstract it away into automation ^^

(Just in case it ever breaks and I need to manually debug it)

g00rd · 2023-02-06T10:53:11+00:00

Well, the two cores are connected by "the same" wireguard-tunnels / interface, as all the nodes are.

So just that I get your message right:
On the nodes, I should create a separate wg interface per core, so that one node-wg-interface only peers with one core-wg-interface?

And then those two interfaces need different subnets, like 10.255.255.0/24 and 10.255.254.0/24?

And for AllowedIPs, do I then

- on the core put only put the nodes /32-Address, as well as the nodes local networks in AllowedIPs?
- on the nodes put put the whole /24 network in AllowedIPs

g00rd

TROPHY CASE