[Solved] Codeword Eule all the time

Well the good things first: I’m a professional SOP8-Clamper now with an 98% hit rate :wink:

Unfortunately, teddycloud can’t find my toniebox and the box itself says Eule after freshness check. The first flash was with the original teddycloud installation ca.der, after getting Eule I tried 5 more times with gencerts.sh. Now I still get Eule and I don’t think, generating another cert will do the trick.

My Setup:

  • Raspi 3 running Pi-Hole and Teddycloud on Linux raspberrypi 6.6.51+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux
  • Every step was made through that machine (dumping, switching certs, flashing through pico with serprog)
  • Teddycloud Docker Compose file has all ports made available and contains dns 1.1.1.1; no other changes
  • Pi Hole has Boxine URLs both whitelisted and Local-DNSed to the Pi
  • Router distributes Pi Hole as DNS; Pings from other machines to both boxine domains lead to teddycloud IP
  • ca.der Files were triple checked (even downloaded the freshly flashed rom again to extract it; all md5sums match; checked cert contents and ROM content and /var/lib/docker/volumes/teddycloud_certs/_data/server/ca.der match 100%)

When starting the Toniebox or doing freshness checks (and every now and then without interaction), the logs state as following:

INFO |server.c:0959:server_init| 1 open HTTPS API connections
INFO |server.c:0959:server_init| 0 open HTTPS API connections

So connection appears to be fine. The question is: am I somehow creating crappy certs all the time that just don’t work? Or am I statistically the unluckiest cert-generator and a 7th attempt could lead to success?

Does anybody know, if the log I posted indicates a working cert or is it just showing a connection attempt?

I’m getting really frustrated at this point and every time I see an owl I feel pain. So any help is highly appreciated!

As a start, could you please run the following two commands on your docker host. Each command is one line. Please post the output

  1. docker exec -it teddycloud bash
  2. curl -s "https://gist.githubusercontent.com/marco79cgn/9709b218fec5608a3ed6b2892d600aed/raw/3dee4d5a7f4939c6fc6adaf33b0302fefe7b0b82/check-tc-certificates.sh" > /tmp/check-certs.sh && chmod +x /tmp/check-certs.sh && /tmp/check-certs.sh
2 Likes

This should be a cert problem. The cc3235 is a bit picky. Please use the gencert.sh to create the certs. Be sure you are really using the certs from the gencerts.sh within teddyCloud. Have you cross checked which certs teddyCloud is sending via https?

Suspicous… Where do the lower three lines point to?

Yes, the serial number of teddy CA matches, but I noticed that firefox shows “B8:0B:3D:07:1 …” as public key modulus and the openssl prompt on the box shows “00:B8:0B:3D:07:1 …” (the same but with a leading 00:). Is this just a display issue or may this be the cause?

No worries, it just means that you don‘t have a dedicated subfolder for your box id. This is fine as long as you only have one box. I would create it anyway as this removes some error logs on each teddycloud start and who knows, maybe there is a problem with the fallback.

Just to be sure: can you show the command you used for patching the firmware?

I copypasted the one from your newbie guide:
cc3200tool -if backupCC3235.bin -of cc3235-flash.customca.bin -d cc32xx write_file /home/pi/toniebox/certs/server/ca.der /cert/ca.der

As already stated, I compared any md5 I could get and all match up (newly generated cert vs. cert I extracted from the customca BEFORE flashing AND vs. the cert I extracted from a fresh dump of the flashed ROM vs. cert in teddycloud). So I would say I’m 100% sure the certs match as far as I understand the structure.

Is there another way to check if a cert is suitable for use? As far as I understand from the forum, no one had to create this many certs to get it working. Could it somehow depent on the machine? Should I try running ubuntu from an USB and generate the certs there or would that be “Arbeitsbeschaffungsmaßnahme”?

And wouldn’t it be possible to get a cert that has been proven to work with a cc3235 model? I mean of course, sharing certs is kind of sketchy and no sane IT-guy would recommend (I’m an insane economist btw), but the associated risk is marginal, I suppose?

And this certificate is really the same one (of the three) that your teddycloud is using? Did you copy it there or is this the output path of gencert? Because Teddycloud uses your certs in
/var/lib/docker/volumes/teddycloud_certs/_data/server/

Sorry for being picky, I just want to make sure.

And are you sure you also copied the other two certs from your latest generation into teddyclouds server cert folder? Those are actually the important ones from the server perspective. The ca.der is „just“ needed for the box.

Yes, that’s all clear to me now after the initial confusion… Get certs from flash put them in /client, generate server certs, copy to /server and replace ca.der in flash/cert and reflash… I followed your newbie guide so every file went to the right destination.

The flashed ca.der is 100% the same as in /server/ca.der as I dumped it again after flashing and checked its integrity.

Should I hammer gencert.sh now until it works?

OMG, I was in the “Owl” club the whole afternoon as well and then discovered an obviously critical bug in Teddycloud: it seems that - at least with CC3235 boxes - one can’t use dedicated client certs for the box-id. If this “overwrite” is active in the settings, no box connection is possible (Codeword: Eule). Even though the content is completely identical.

Here’s what happened:

I screwed my Raspberry Pi with teddycloud this morning trying to install RaspAP (Access Point software). It killed my ssh agent and network interfaces and I couldn’t manage to get it to work again (locked out). So I copied all Teddycloud volumes directly from the sd card to another machine (backup) with scp. After that, I set up the Pi from scratch, completely deleting the sd card, installing the same bookworm lite OS, then Docker, then teddycloud. After the first teddycloud start I stopped the container and then copied back all volumes from my previous installation. Everything seemed to work fine with the certificates etc., log files looked perfect.

BUT: my Toniebox couldn’t connect anymore! Always “Codeword: Owl”! I tried a lot of things without luck (changing IP address of Pi, use WiFi instead of Ethernet, compared certificates etc.). I could still see the Toniebox icon in the GUI (from the former installation/backup/config) but it was shown as offline. So I went to its settings and disabled the “overwrite” of the cert dir and for all three client files. Restart teddycloud et voila: everything works like a charm again!

So there seems to be a bug when using the individual box certs! When I set up my Toniebox with teddycloud for the first time (8 weeks ago), I didn’t use these overwrites but used the default/fallback certs. I think I changed it inbetween when I switched to the develop tag - just to get rid of the exceptions in the log because that’s how I even noticed that these dedicated subfolders exist in the first place.

What I noticed: in the broken state, from time to time the box was shown online in the GUI for a very very short time (see screenshot). But it never worked, neither with new/unsynced Teddycloud nor Boxine content (Codeword: Owl). And it went back “offline” very shortly after that.

There’s also a small bug in the GUI. When you change a box setting, save it and then change any other setting, it won’t work and there is an error message. You have to refresh the site. But that’s really a minor thing.

I finally got it working!!!

What you described in your latest reply was not suitable for me at all, since I couldn’t access the shown “overwrite” options at all, as my teddycloud had never shown any toniebox before…

So I did another deep dive into the certificate universum and unfortunately I have to say, that the cc3235 newbie howto was my problem! You should probably add some lines:

In your howto after generating certs with gencerts.sh it says:

As I had nothing left to loose, I just also copied teddy-cert.pem and teddy-key.pem to /var/lib/docker/volumes/teddycloud_certs/_data/server/ and restarted the cloud. The box was detected instantly and the logs showed the error, that there were no certs in the mac-specific subdir of /client for the first time (because the box was detected for the first time…). I got rid of this quickly with the overwrite thing you described.

I’m not sure if this was super specific for me or if your howto needs an important update. I’m not even sure, if the second flash (the first one with gencerts.sh generated certs) would have been sufficient, if I had replaced the teddy-cert and teddy-key in the first time. But anyway, it works now and I’m super happy.

Many thanks to you all, especially @marco79cgn and @0xbadbee for your extensive help during the last week! I’m super glad this community is so friendly and supportive!

Best
Fuzzipelz

First of all: congrats! :slight_smile:

And yes, Sorry, my bad! I somehow mixed server and client when all I wanted to say is that you can ignore the generated client certificates from gencert, as you need the three from your Toniebox. :frowning:

I just updated the Guide and replaced it with one single copy command to make sure all files inside the server folder will be copied to the Teddycloud volume:

docker cp ~/toniebox/certs/server/ teddycloud:/teddycloud/certs/server

I also added the needed faketime installation. At the time of writing this Guide, I was completely new in this Forum and couln’t edit my posting after some hours. But now it worked.

That is known, one reason for the delayed release of 0.6.3

Still a bug with the solution wrote later?