Teddycloud CC3200 newbie guide

Toniebox Hardware CC3200 (V1, V2)
82 
root@jenke:/home/jenke/toniebox1# /root/.local/bin/cc3200tool -p /dev/ttyUSB0 --reset dtr read_flash backup.bin
2024-12-10 14:35:57,072 -- Connecting to target...
2024-12-10 14:35:59,429 -- timed out while waiting for ack
2024-12-10 14:35:59,682 -- Connected, reading version...
2024-12-10 14:35:59,695 -- connected to target
2024-12-10 14:35:59,695 -- Version: CC3x00VersionInfo((0, 4, 1, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0))
2024-12-10 14:35:59,696 -- This is a CC3200 device
2024-12-10 14:35:59,696 -- Switching to NWP bootloader...
2024-12-10 14:35:59,711 -- Switching UART to APPS...
2024-12-10 14:35:59,727 -- Resetting communications ...
2024-12-10 14:36:00,991 -- Uploading rbtl3100s.dll...
2024-12-10 14:36:00,991 -- Reading rbtl3100s.dll from file /root/.local/share/pipx/venvs/cc3200tool/lib/python3.12/site-packages/cc3200tool/dll/rbtl3100s.dll
2024-12-10 14:36:00,992 -- Getting storage list...
2024-12-10 14:36:01,727 -- APPS version: CC3x00VersionInfo((0, 4, 0, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0))
2024-12-10 14:36:01,727 -- Getting storage list...
2024-12-10 14:36:01,743 -- Getting storage info...
2024-12-10 14:36:01,759 -- storage #2 info bytes: 0x10, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0
2024-12-10 14:36:01,759 -- Setting raw read size to maximum: 4194304
2024-12-10 14:36:01,759 -- Reading raw storage #2 start 0x0, size 0x400000...
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
2024-12-10 14:37:07,884 -- Verify flash dump with second reading...
2024-12-10 14:37:07,884 -- Getting storage list...
2024-12-10 14:37:07,894 -- Getting storage info...
2024-12-10 14:37:07,910 -- storage #2 info bytes: 0x10, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0
2024-12-10 14:37:07,910 -- Setting raw read size to maximum: 4194304
2024-12-10 14:37:07,910 -- Reading raw storage #2 start 0x0, size 0x400000...
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
2024-12-10 14:38:13,188 -- Flash verified, reading equal!
2024-12-10 14:38:13,188 -- All commands done, bye.
83

@Jorg_Agatz

And ExtractedFromBox is still empty? Just to make sure, where are you looking for that folder?

# here?
/root/.local/bin/cc3200tool/ExtractedFromBox

Although I suspect you would have seen a different error message you can try the following in order to rule out permission issues, although it looks like you’re logged in as root anyway

/root/.local/bin/cc3200tool -p /dev/ttyUSB0 --reset dtr read_all_files /home/jenke/toniebox1/ExtractedFromBox/

If that still comes up empty, you can try to extract the certs file by file:

/root/.local/bin/cc3200tool -p /dev/ttyUSB0 --reset dtr read_file /cert/ca.der ExtractedFromBox/cert/ca.der  
# repeat for /cert/private.der and /cert/client.der

Can you verify your backup.bin is not 0 kb?

84

ok, the Export from the Certs, are Working, but i cant read all files,

i have restart the Box and istallt WLAN and check vor Updates, all is working nomaly, but i cant read all files, it look like the bin is OK, but i Dont know

85

No filenames can happen and isn’t a problem at all.

86

Thanks!

@Jorg_Agatz shot me a PM, I advised him to dump all files listed under Firmware layout | Toniebox Hacking manually then. According to the know problems page this was the correct advice :slight_smile:

I haven’t had to restore from backup yet, I assume even if you don’t have dumped all files, the backup.bin is sufficient? Would like to learn about that.

@0xbadbee Thanks for the edit! Was about to delete that part again :wink: At least my assumption that the changelog didn’t look like 1.2.4 would have introduced that problem was correct.

off-topic: Is the forum awefully slow for you guys too?

87

Yes, just write the backup bin, writing all files back can result in a non booting box. Bot writing the flash after that should fix that.
Usually it is enough to write the mcuimg.bin (original bootloader from the backup) to the box to revert everything.

88

Hello everyone,

I have been trying for days to install Teddycloud successfully, but I get to the same point again and would be very happy if you could look over my settings.

Toniebox

  • CC3200 version
  • C2 Patch
  • altCa.305
  • Displayed in Fritz.Box
  • Code name: Ant

Teddycloud

  • Adguard Home off
  • Portainer 192.168.178.21
  • Macvlan TC 192. 168.178.22/web
  • No firewall
  • DNS resolution 1.1.1.1 (otherwise I get error messages)
  • Boxine green
  • Teddycloud green

The log looks good to me. When I click on the Teddycloud menu, the following message appears directly: WARN |platform_linux.c:0292:socketReceive| buffer does not contain null terminator

Log:
comment: removed from the links .de and https (so that I can post it here)

89

You need a second patch so that your Toniebox can resolve your Teddycloud (DNS/Host). Use the altUrl.tc.fritz.box patch as well and then rename your Teddycloud host/machine in the Fritzbox GUI to tc.

fritz-tc
fritz-tc2170×1768 268 KB

90

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).

91

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:

92

Okay, let’s get some structure in that:

  1. There should be no problem if adguard is not running because if you are using a default dns resolver rtnl.bxcl.de and prod.de.tbs.toys should not be blocked. From your original post it seems they are not accessible because you need to manually provide a different dns resolver.

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.

tonieboyguide(1)
tonieboyguide(1)701×481 48.1 KB

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)

93

//EDIT: @chuckf and me answered at the same time :slight_smile: 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.

94

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

  • altUrl.tc.fritzbox
  • OWF2

@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”

  • Could not resolve host: prod.de.tbs.toys
  • Closing connection
    pi@raspberrypi:~ $ nslookup prod.de.tbs.toys 192.168.178.21
    // resolves correctly via port 443, server responds with HTTP 400 Bad Request

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!!!

95

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:

  1. 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.

  2. 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:

  1. Backup your adguard configuration
  2. Manually save the settings you already did somewhere (like your adlists)
  3. Remove any adguard entries from your fritbox, revert back to your default dns server or specify 1.1.1.1 or 8.8.8.8 or whatever server you want to use.
  4. You may need to restart your router so it broadcasts the new dns server to all your devices
  5. Use the tc patch
  6. Verify teddycloud and your box are working correctly now, they should even without specifying a name server in the docker compose for teddycloud.
  7. reinstall a clean instace of adguard, revert all changes you made regardind ports beforehand
  8. Install apt install dnsutils (optional, could stick to the provided curl commands).
  9. Save a little script and run it after you made changes to your configuration in adguard .
#!/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
  1. Use the saved information from 2) to slowly setup adguard again. Do a change at a time, verify it didn’t break anything
  2. If you feel confident that adguard does run correctly you can create the rewrites for the boxine urls, replace the tc patch with the alturl patch and deploy your adguard server as your dns server. keep in mind that you also need to configure it in ipv4 settings, the one obvious entry as preferred dns server is not enough in a fritzbox. see here