Which error message? If you don’t have adguard enabled the boxine urls shouldn’t be blocked in your home network.
What is your DNS resolver?
That’s the same.
You can ignored that / increase (or decrease?) the logs level in Teddycloud.
As @marco79cgn posted, either use the TC patch or use the alturl patch (and define local entries in your DNS resolver).
Thank you very much for your feedback,
@marco79cgn @chuckf
I have made some changes and new questions have arisen.
I am now using the altUrl.tc.fritz.box patch and have renamed Teddycloud-Host to tc.
Adguard Home
I would like to continue using Adguard Home in the future. It was only deactivated for testing.
So my understanding is that it is the DNS resolver 192.168.178.21
I have therefore activated Adguard Home and added prod.revvox, rntl.revvox and tc.fritz.box to the DNS rewrites
Update stack teddycloud (without DNS 1.1.1.1)
No connection can be established due to DNS resolution, here is the log:
Also tested: Manual adding of the DNS server also leads to no result, no firewall, IP address 192.168.178.22 is not on blacklist, ping works
Terminal:
Okay, let’s get some structure in that:
What is the setup in your router? What DNS resolver is provided on your network?
Is it? What do you have configured in your router?
Well you need to see it that way: With the cc3200 and the bootloader there is no need to rewrite prod.de.tbs.toys and rtnl.bxcl.de (I’ll refer to them as the boxine urls) network wide. All your machines will not care about them with the exception of your teddycloud instance and the toniebox.
Make sure the boxine URLs are not on any blacklist in your adguard instance (or whitelist them). This will enable the teddycloud to communicate with them in case you are using passthrough. You can leave the custom DNS entry in the docker compose, however this still indicates they are blocked on your network and you don’t know why / where.
The toniebox wants to communicate to the boxine urls but we do not want that. Thanks to the possiblity to apply patches, we will just redirect all traffic to the boxine cloud to our teddycloud.
Choose either patch altUrl.305 or altUrl.tc.fritzbox, not both!
The patch will the rewrite prod.de.tbs.toys to prod.revvox and rtnl.bxcl.de to rtnl.revvox or both to tc.fritz.box. If you look at the patches directly, you will see that only one can be applied.
And then you go ahead and redirect tc.fritz.box or the revvox urls to your teddycloud instance.
Hopefully this will clear it up.
Go to your router and check what DNS Server is broadcasted to your devices or use a machine in your network and see if you can solve prod.de.tbs.toys, rtnl.bxcl.de and whatever method you chose for the rewrite (either!) the .revvox urls or tc.fritz.box
It looks to me like you got a little bit confused and configured more than you needed to / mixed it up.
Can you show your ngCfg.json? Are you using OWF2 as default and which patches are applied?
Edit: bottom line is I think you blocked / rewrote too much. api.revvox.de should be recheable. You probably blocked it somewhere, perform a DNS lookup for that URL. (E.g. nslookup api.revvox.de)
//EDIT: @chuckf and me answered at the same time 
Still here’s my 2 cents:
OK, so you changed at least four things at the same time which makes it quite difficult to understand and debug. Furthermore you mixed different things from the instructions into a Cocktail.
Perfect, this (and only this!) is what I wrote in my last comment. After this step, everything should have been working without problems. Have you tested it and can you verify it? Would be important to know that everything works before(!) doing the Adguard/Network/Macvlan things.
Why have you implemented those 3 DNS rewrites? Since you are using the fritzbox patch, you don’t need to bother with dns anymore. You just have to make sure that tc.fritz.box resolves to your Teddycloud and this is independent from Adguard! Be aware: it has to be the Teddycloud(!), not your Teddycloud host anymore! Because after you added macvlan, your Teddycloud gets a different ip address than your Teddycloud Docker host! This also means that you have to adapt your network settings in the Fritzbox GUI!
Your macvlan configuration is as basic as it can be. First question: is macvlan necessaray at all in your case? Is port 443 on your docker host already occupied? If not, I would not use it at all. If yes, than I would at least define a dedicated ip address so that you don’t have to inspect it afterwards. In my case it looks like this for example:
version: '3'
services:
teddycloud:
container_name: teddycloud
hostname: teddycloud
image: ghcr.io/toniebox-reverse-engineering/teddycloud:latest
networks:
my_macvlan:
ipv4_address: 192.168.178.13
... (etc.)
####### Network - macvlan #######
networks:
my_macvlan:
driver: macvlan
driver_opts:
parent: wlan0
ipam:
config:
- subnet: 192.168.178.0/24
gateway: 192.168.178.1
ip_range: 192.168.178.12/30
So as you can see, I explicitely set the ipv4 address for the teddycloud container in the upper part (*.13 in my case). And I also reduced the possible ip addresses which macvlan can use to two (.12/.13) by using ip_range: 192.168.178.12/30. You have to make sure that those ip addresses are outside the range of your DHCP server so that they never get assigned automatically to other clients. Here’s a very detailed HowTo wich explains it.
When you activate AdGuard, make sure that prod.de.tbs.toys, rtnl.bxcl.de and api.revvox.de are not blocked. I’d put them on the Allow-List (with higher priority than any blocklist).
You can test if DNS on your Teddycloud instance is working at all by running these commands on your Docker host:
docker exec -i teddycloud bash -c "curl -svo /dev/null api.revvox.de"
docker exec -i teddycloud bash -c "curl -svo /dev/null prod.de.tbs.toys:443"
docker exec -i teddycloud bash -c "curl -svo /dev/null rtnl.bxcl.de:443"
Concerning the DNS of your Teddycloud: you can either set it manually in the docker-compose.yaml (a public one or your Adguard Home DNS) or you can leave it blank which means that the DNS of your Gateway (Fritzbox) will be used. If this is already set to your Adguard, then you’re fine. But honestly, there’s no need to use an Ad-/Contentblocker inside the Teddycloud container. This leads most probably to more problems than it resolves.
Hello everyone,
You have read me completely correctly. In the stress of doing everything right and getting it to run on my own, I made changes at every turn and have now lost track. I have read your comments and partly understood and tested them.
Port 443
AdGuard Home was also using port 443, so I re-edited the stack and it now looks like this. Is this correct?
AdGuard Home now uses port 5053 (TCP) and port 443 (UDP).
Teddycloud uses port 443 (TCP).
AGuard Home
Adguard is active and does not block boxine urls.
Boxine urls rewrite removed
FritzBox
Local DNS server 192.168.178.21
Portainer:
nextcloud_default → TC reachable, Boxine red, 192.168.178.21:8888/web
nextcloud-creation → not accessible via browser
I would take care of the two patches altUrl.305 and altUrl.tc.fritzbox as soon as Teddycloud is running properly? So Boxine and Teddycloud are green?
ngCfg.sjon
@marco79cgn
altUrl.tc.fritz.box did not work before my changes.
Error code ant. That’s why I kept looking.
DNS-Server:
pi@raspberrypi:~ $ docker exec -i teddycloud bash -c “curl -svo /dev/null prod.de.tbs.toys:443”
pi@raspberrypi:~ $ docker exec -i teddycloud bash -c “echo nameserver 8.8.8.8 > /etc/resolv.conf”
pi@raspberrypi:~ $ docker exec -i teddycloud bash -c “curl -svo /dev/null prod.de.tbs.toys:443”
// Boxine green until Docker restart (but is that correct?), Box (Codeword:Ant, altUrl.tc.fritzbox)
Apparently my local DNS server is not resolving Tedyycloud correctly. I am about to set it up again on another Raspi 3B. What do you think?
Thanks again!!!
Teddycloud runs on .22 and adguard on .21 so there should be no conflicts with the ports. Portainer could interfere with adguard, however you could use 9443 for portainer instead of 443 for example.
What do you mean by that?
It’s likely a DNS issue.
So for me to recap the state of things:
If you use 1.1.1.1 as a DNS resolver in your teddycloud stack, this should enable you to reach everything. You need to verify this.
Marco gave the answer but at a quick glance
seems correct.
Just for my understanding: When using 1.1.1.1 in teddycloud stack everything is working, i.e. teddycloud is running without any error messages?
I think you misconfigured adguard somewhere.
For DNS queries port 53 is used afaik.
My recommended course of action:
apt install dnsutils (optional, could stick to the provided curl commands).#!/bin/bash
adguardip=1.2.3.4
# check connectivity
nslookup api.revvox.de $adguardip
nslookup prod.de.tbs.toys $adguardip
nslookup rtnl.bxcl.de $adguardip
#check rewrites, comment out the ones you are not using
nslookup prod.revvox $adguardip
nslookup rtnl.revvox $adguardip
nslookup tc.fritz.box $adguardip
Great manual so far. I went with a completely different solution for connecting debug port though: while I don have any resistors nor expensive pin connectors, I have a 3d printer and some acupuncture needles (they are used to clean printer nozzles sometimes). So I printed a positioning aid and used the needles as connectors. Here is the link to the model (also includes the photo of the setup): Toniebox CC3200 debug adapter positioning aid by Jorx | Download free STL model | Printables.com
Hello,
First of all, thank you very much for the guide.
Unfortunately, I still couldn’t do it alone. I’m at the step:
Read, patch & write the certificate/firmware
I use a clamp.
The pins were checked several times. Unfortunately no connection
I just noticed that my board lights up RED when I connect my adapter. Only with the battery does the circuit board initially light up red and green. After the readout command with reset, the green lamp goes off and then on again with each attempt.
What my command line spits out:
Blockquote
$ cc3200tool -p COM9 --reset dtr read_flash backup.bin
2025-01-01 11:32:48,480 – Connecting to target…
2025-01-01 11:32:50,798 – timed out while waiting for ack
Do you have an idea what it could be?
can you post an image of your setup?`
The pcb must be connected to power.
@Greyson MINGW64 ~
$ cc3200tool -p COM9 --reset dtr read_all_files ExtractedFromBox/ read_flash backup.bin
2025-01-01 13:18:40,158 – Connecting to target…
2025-01-01 13:18:42,466 – timed out while waiting for ack
2025-01-01 13:18:44,680 – timed out while waiting for ack
2025-01-01 13:18:46,895 – timed out while waiting for ack
2025-01-01 13:18:49,105 – timed out while waiting for ack
2025-01-01 13:18:51,325 – timed out while waiting for ack
2025-01-01 13:18:51,328 – Could not connect to target: Did not get ACK on break condition
cc3200tool -p COM9 --reset=dtr read_flash backup.bin
You missed the = between --reset and dtr
okay. then it might work without also, i did it yesterday with a “=”
is the yellow and orange cable the same?
Is The sd Card still in Place? Iirc the light was Green when i did it yesterday.
Is the Box working fine if you reassemble it now?
i copied this are you sure it is the RTS Pin? Cause in the Picture above it is called the RST PIN. OR do i have to connect the RTS on my UART to GND?
Most likely it is a typo. Will fix that later.
I had flashed the SD Card. Because i was stupid. But i flashed it again to FAT32 and it worked.
I have now just 1 Directory in my SD card.
Content/00000000
Content/00000001
Content/450E230E
but no other trashcan like in this video
