Garmin Index S2 Scale and Encryption

Berend De Schouwer

A deep dive on firmware bugs that prevent Garmin Index S2 scales from connecting to encrypted Wifi networks. I describe some of the problems, a solution of sorts if you’re a network administrator, and a guess as to the root cause. I do not, in this article, reverse engineer the firmware.

Problem Description

Garmin Index S2 scales are notorious for not connecting reliable to a number of Wifi Networks. For example, read Garmin Forums Quite often the scale won’t connect, or will connect and not sync, and it’s display is not clear, and not well documented to find the fault.

For other frustrations, you can read my previous blog post Garmin Index Scale Firmware Problems

Official requirements

The official requirements are:

• 2.4 GHz (no 5.0 or 6.0)
• 802.11 ac, b, g or n (no 802.1x)
• Channels 1-11 only
• No hidden SSIDs
• Security: Unencrypted, WPA and WPA2
• Passwords must be at least 8 characters

Some of these requirements are simply due to the age and power of the embedded controller. It was never going to support 5.0 GHz, for instance.

What we (customers) want

Compliant Wifi

• Encrypted, at least WPA2
• Channels 1-13

A Wifi access point can typically be configured for a specific channel, or for all channels. No Wifi access points allow you to specify a channel range.

If you are outside the US, this means:

• Exactly one channel, or
• Channels 1-13.

So you are reduced to running one channel. Luckily the scale does actually connect on channels 1-13. It’s doubtful the chip would be certified in the countries it’s sold, if it doesn’t. So we will ignore the first problem.

What worked yesterday, to work today

The scale frequently gets stuck, and the usual support response is to reset the scale.

Resetting the scale is difficult

• It requires tapping a button on the bottom, and simultaneously viewing the top display.
• Testing requires putting significant weight on top of the scale, but your finger is still tapping the bottom.

Resetting the scale is unnecessary

Frequently the scale is actually still working. The problem is that the display isn’t communicating to you, the user, what’s happening.

Quite often it’s busy, and you should simply wait. It does this by flashing an hourglass —- ⌛ —- and then switching the display off. To the average user, this looks like the scale fails to switch on.

The correct thing to do is wait 5 minutes.

Updating Garmin Documentation.

Lets first update the documentation. Lets create a useful Wifi manual for the Garmin Index S2 Wifi connection status.

There are three icons:

• Wifi 🛜
• Sync 🔁
• Done ✅

Wifi connecting 🛜

While 🛜 blinks, the scale is connecting to Wifi. If it stops blinking, it has connected to Wifi, and your WPA2 password works.

As soon as this happens, you no longer need to reset your scale.

Data Syncing 🔁

While data is syncing, 🔁 is animating. At this point, the scale is talking over the network to Garmin servers.

Under certain conditions this can take a long time, and the display will switch off. It will still be syncing in the background, though.

Note: If the display switches off in this state, it’s power-saving the display. It has not switched off. If you power on the scale, you will see an hourglass ⌛. Wait 5 minutes. Be patient.

Done ✅

It’s done.

Actual Syncing Problems

If the data never syncs, read on.

If the data never syncs, you may have:

• Firewall issues (not if you didn’t have them yesterday)
• ISP issues (ping connect.garmin.com)
• Hit a firmware or controller bug (the rest of this blog post)

Note: At this point the Wifi is connected. The scale found your Wifi, your SSID, and has negotiated encryption.

Firewall Issues

This is simple.

If you don’t know what a firewall is, you didn’t break it.

If you haven’t modified your router settings —- if your ISP allows it —- you didn’t break it.

If you have edited your firewall, roll back, try again.

ISP Issues

Do the normal tests. Connect to any other site and check that Garmin is up.

If these work, your ISP is probably not down.

Scale Sync Network Activity

How does the scale sync with Garmin Connect? I’m glad you asked.

In order, the scale uses the following protocols.

1. DHCP
2. DNS
3. NTP
4. HTTP
5. HTTPS

These steps are fairly normal and expected. What is so unexpected is that step 5 fails when all the other steps work, and how it fails.

DHCP

This is how the scale gets an IP, and part of the Wifi negotiation. It’s fairly standard.

The most notable is that the client identifier is GarminIntern and the host name is WINC-00-00.

DNS

It then does a DNS lookup, to do an NTP sync. It looks up two machines:

• time.google.com
• time.garmin.com

This is notable because time.garmin.com does not exist.

The scale will do more DNS lookups as we go along. They tend to work fine.

NTP

The scale syncs it’s clock. This, again, is normal. It’s necessary because it will later use HTTPS, and that requires a valid clock.

time.garmin.com doesn’t exist, but it doesn’t stop the clock from syncing. The scale also does normal NTP on time.google.com and another NTP call on clock.garmin.com on port 4123.

HTTP

The scale proceeds to send POST /OBN/OBNServlet to gold.garmin.com. This seems to be mainly to get a Cloudflare response, for example CF-RAY.

This doesn’t usually fail, but the errors start here. The reason it doesn’t fail outright is that it will retry, and eventually a retry will work before the clock runs out.

HTTPS

Now the scale starts sending data to:

• services.garmin.com
• api.gcs.garmin.com
• connectapi.garmin.com
• omt.garmin.com

At this point the errors accumulate, and eventually the clock does run out. The errors slow down the connection to the point where the scale fails to send it’s data inside the 5 minute timeout.

Accumulated Problems

So what exactly fails? Once data flows, the scale fails to acknowledge the server’s TCP ACK packets about 80% of the time. If too many packets are missed, the server closes the connection, and the scale tries again. Once the scale retries too many times, it gives up.

Since this happens ±80% of the time, and multiple connections are made, the scale fails very often. Every now and then it works.

Problem Details

TCP 101

TCP was created to transfer data without having the application worry about reliability. Data gets chopped up, usually in ±1500 bytes¹². If it needs to get chopped up further, the OS gets notified.

TCP also takes care of putting the data back together again. This can be more difficult than just Packet 1 + Packet 2.

• Packet 2 can arrive before Packet 1
• Packet 2 can get lost, requiring retransmission

Let’s look at this in a bit more detail. Let’s say the scale wants to send 5000 bytes of data. It gets chopped up into 1500 bytes.

As you can see, the acknowledgements tell the scale how much data the server has received, and from where to continue.³⁴

TCP 102

Of course, you can’t just start sending data. You have to tell the server you want to send data, and the server must accept, so it goes something like:

• Handshake
  • SYN client → server
  • SYN/ACK server → client
  • ACK client → server
• Data, as above.
  • ACK client → server
  • ACK server → client
  • …
• Stop⁵
  • FIN/ACK client → server
  • FIN/ACK server → client
  • ACK client → server

What is Observed

The scale starts sending data, but the server’s packets aren’t received. The scale then eventually resends packets. Something like:

Note: The time increases exponentially, as the server asks for more data. If this happens too often, the scale times out, and no data is sent.⁶

This means the scale doesn’t receive the ACK packets from the server.

What Else is Dropped?

At the start, nothing. DHCP, DNS and NTP all work. Once the scale starts using HTTP (over TCP), packet drops start. This is usually about 15 seconds after the scale connects to the Wifi network.

However, once the packet drops start, other packets are dropped to.

Ping

ICMP packets to check if the scale is up.

ARP

Ethernet packets to match an IP to a MAC addressees.

ARP being dropped is very interesting. When ARP goes, everything stops until ARP is answered. This would indicate that Wifi encryption updates might get dropped too.

TCP 201

The retransmitted acknowledgements need not come from the actual server, although they look like they do. They can and often do come from a router or firewall in the middle as a performance optimization.

Workarounds that Don’t Work

Different Wifi

I am in the lucky position to try multiple Wifi routers, so I did. I tried 3 different ones.

All Alone

Because I tried multiple routers, the scale was the only device on the network. There was no traffic congestion, and no competition.

This did not help.

Different Encryption on Wifi

Encrypted Wifi can be WPA or WPA2⁷, and support different authentication methods and encryption standards. WPA uses TKIP, WPA2 uses CCMP. Nope, this did not help.

Note: Different router hardware might not let you set some protocols, since it may be handled in the Wifi network hardware.

Quality of Service

Boost Garmin IP networks. Boost the scale. Boost empty ACKs and retransmitted ACKs. Nope.

Different Channel on Wifi

The Garmin Index S2 Scale officially only supports channels 1-11. Since I’m not in the US, Wifi equipment usually uses channels 1-13, and uses different frequency blocks.

Note: To get certified for sale in non-US countries (like the EU), the scale would be tested by the local regulator, and must pass local wireless regulations. Therefore I do not believe the official documentation —- the scale would be illegal for sale.

However, I did try hard coding channels 1, 6, 11, and different country regulations on the Wifi router. This did not make a difference.

Different Garmin

The various Garmin services resolve to multiple IP addresses. This is likely for load balancing.

Modify the DNS on the router to supply specific ones. This didn’t help.

Note: This might not make as much of a difference as you think, since they are behind Cloudflare, and the CDN will intercept and reroute these connections.

Computer Captcha

Since it’s behind Cloudflare, the scale might be hitting Cloudflare’s captcha protection. Maybe HTTP and HTTPS don’t work unless the scale can prove it’s human.

Network dumps prove this is not what’s happening. They do reveal Garmin’s ID and other Cloudflare details, that I will not post in this blog.

Adjusting the MTU

A common problem in network stacks is that they don’t notice when the MTU needs adjusting. This can and does happen when the transport changes, for example when it changes from Wifi to Cable.

Yes, I did try adjusting this, both larger and smaller.

And I did check for DNF and Fragmentation Needed.

Hardcode ARP

This is easy, and it removes some network packets from the equation. It does not fix the problem, though.

Workarounds that Work

No Encryption on Wifi

This works perfectly, but it’s not acceptable in my household.

No encryption does result in no retransmissions, though.

Hack the RTO

The retransmissions are also called TCP RTO (retransmission timeout). We can reduce this, and increase the number of RTO packets that the router sends, to greatly increase our chances of sending a retransmission at the moment the scale is listening again.

This does work, but it requires two things:

1. A custom kernel
2. Enable custom kernel
3. A proxy

Custom Kernel

We need a custom kernel because we’re going to move these values out of the TCP specification. Since this network isn’t used for anything else, let’s do it.

There are a number of queries on mailing lists for this. However, there aren’t a great many final solutions. As I said, it’s outside spec.

I’m including a diff here, in case other people want it. This

• Increases the number of retries, so it doesn’t stop before the scale times out.
• Decreases the highest timeout value, so we will retry much quicker.
• Sets every connection to thin, meaning that the timeouts increase linearly instead of exponentially.

This diff is for Linux 6.12, and should work on Debian Stable.

diff --git a/include/net/tcp.h b/include/net/tcp.h
index b3917af30..cce7a5350 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -90,14 +90,14 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
 #define TCP_URG_NOTYET 0x0200
 #define TCP_URG_READ   0x0400

-#define TCP_RETR1  3   /*
+#define TCP_RETR1  8   /*
                 * This is how many retries it does before it
                 * tries to figure out if the gateway is
                 * down. Minimal RFC value is 3; it corresponds
                 * to ~3sec-8min depending on RTO.
                 */

-#define TCP_RETR2  15  /*
+#define TCP_RETR2  30  /*
                 * This should take at least
                 * 90 minutes to time out.
                 * RFC1122 says that the limit is 100 sec.
@@ -138,8 +138,8 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
 #define TCP_DELACK_MIN 4U
 #define TCP_ATO_MIN    4U
 #endif
-#define TCP_RTO_MAX    ((unsigned)(120*HZ))
-#define TCP_RTO_MIN    ((unsigned)(HZ/5))
+#define TCP_RTO_MAX    ((unsigned)(5*HZ))
+#define TCP_RTO_MIN    ((unsigned)(HZ/10))
 #define TCP_TIMEOUT_MIN    (2U) /* Min timeout for TCP timers in jiffies */

 #define TCP_TIMEOUT_MIN_US (2*USEC_PER_MSEC) /* Min TCP timeout in microsecs */
@@ -226,7 +226,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
 #define TCP_NAGLE_PUSH     4   /* Cork is overridden for already queued data */

 /* TCP thin-stream limits */
-#define TCP_THIN_LINEAR_RETRIES 6       /* After 6 linear retries, do exp. backoff */
+#define TCP_THIN_LINEAR_RETRIES 60      /* After 6 linear retries, do exp. backoff */

 /* TCP initial congestion window as per rfc6928 */
 #define TCP_INIT_CWND      10
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index b65cd417b..e5656e919 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -639,7 +639,7 @@ void tcp_retransmit_timer(struct sock *sk)
     */
    if (sk->sk_state == TCP_ESTABLISHED &&
        (tp->thin_lto || READ_ONCE(net->ipv4.sysctl_tcp_thin_linear_timeouts)) &&
-       tcp_stream_is_thin(tp) &&
+       //tcp_stream_is_thin(tp) &&
        icsk->icsk_retransmits <= TCP_THIN_LINEAR_RETRIES) {
        icsk->icsk_backoff = 0;
        icsk->icsk_rto = clamp(__tcp_set_rto(tp),

Enable custom kernel

To get the full effect, you may need to enable thin streams on some Linux distributions.

echo 1 > /proc/sys/net/ipv4/tcp_thin_linear_timeouts

Add it to /etc/sysctl.conf or it’s subdirectories

Proxy

We only control TCP RTO on local sockets and some NAT-ed connections, so we need to setup a proxy. I tried this first with HTTP, using Squid, and it worked. However I also needed to do HTTPS, and then encryption certificates make it hard work.

However, I’m not looking inside the packets. I don’t need to decrypt them, just forward them. I’m just interested in modifying TCP RTO, so I can treat HTTPS like any other TCP Socket.

The easiest way to do this is with a systemd socket or xinetd redirect and NAT. You will need one per Garmin IP address.

Example xinetd config:

service garmin-gold_garmin_com
{
    type = UNLISTED
    socket_type = stream
    protocol = tcp
    wait = no
    user = nobody
    bind = 0.0.0.0
    port = 3129
    only_from = **my_network**
    redirect = gold.garmin.com 80
}

and a nat rule:

table inet filter {
    chain prerouting {
        type nat hook prerouting priority -100;
        policy accept        
        ip saddr **scaleip**
            ip daddr { gold.garmin.com } tcp dport { 80 }
            dnat to 10.43.0.1:3129
    }
}

Probable Cause

This only happens when the network is encrypted. The scale is not recording the server’s data, and the scale is also not sending errors back.

This could happen if:

• the controller is too slow to decrypt
• the firmware decides the packets are corrupt
• an interrupt goes missing
• not enough RAM, hence forced to drop

Which exactly it is is unknown, and where you draw the line between controller and firmware can be a grey area. For example, in most computers, the network card will perform some calculations on the packets instead of the OS. This is called hardware off-loading, but in practice it happens in firmware.

DSLR webcam and pipewire"">DSLR webcam and pipewire

Berend De Schouwer

tl;dr

It used to be possible to use a DSLR as a webcam, or in OBS, on Linux, and with the move to pipewire this broke.

Here’s the code to make it work again:

gst-launch-1.0 \
     clockselect \
     v4l2src \
     device=/dev/video0 \
     ! queue ! videoconvert \
     ! pipewiresink mode=provide stream-properties="properties,media.class=Video/Source,media.role=Camera" \
     client-name=DSLR

background

On Linux, you can use your DSLR as a webcam, and have any application use it. What you need is: * gphoto2 * ffmpeg * v4l2loopback (kernel module)

The recipe can be slightly different based on camera functionality like frame rate and resolution, but it basically follows

gphoto2 --set-config liveviewsize=2 \
        --stdout --capture-movie \
        | ffmpeg -i - \
                 -re \
                 -vcodec rawvideo \
                 -pix_fmt yuv420p \
                 -threads 2 \
                 -f v4l2 /dev/video0

Most DSLRs are supported.

With the move to pipewire, another step is needed. This blog post describes that step.

You may need to change:

liveviewsize=2

Different cameras will have different options

-re

-re should make ffmpeg match the native framerate, which may save CPU cycles

clock bug

The output of the gst command should have an advancing clock. If the clock remains stuck on 00:00:00, you will need to add clockselect to the gst-launch command at the top.

This is related to Pipewire Regressin 4389

when

Right now, December 2024. Firefox, OBS and Chrome are moving to pipewire. The move has happened in some distributions, and is in the process in others.

firefox

Look in about:config for media.webrtc.camera.allow-pipewire

chrome

Look in chrome://flags for Pipewire Camera Support

who

pipewire aims to improve the handling of audio and video on Linux, and it’s pretty good at that.

You’ll need version 1.2.6 or later for this to work. Look for libpw-v4l2.so.

what

A DSLR camera, attached via USB, that you used to use using gphoto2 and v4l2loopback

where

wpctl status

Look for a section like:

Video
 ├─ Devices:
 │      56. ...
 │  
 ├─ Sinks:
 │  
 ├─ Sources:
 │  *   64. USB2.0 FHD UVC WebCam (V4L2)       
 │      93. DSLR

You want your DSLR to show up under Sources.

You can then get more information using pw-cli info 93

why

Update to pipewire. It really is better.

how

After running gphoto2 the way you normally do, run the command at the top. You can name your DSLR something else if you like.

Test it using wpctl status and pw-cli info

ifunky xz

Berend De Schouwer

xz and openssh

There was a briefly successful attempt to add a backdoor to /usr/bin/sshd on Linux.

There are a lot of discussions of how, when, what and why already on the Internet. I’ll include a few links below.

Most posts fall in one of two camps:

• brief description
• detailed description, starting with a .m4 file.

This post instead will try to turn this into a story. What are the attacker’s goals, and how can they best be achieved?

Hopefully this different perspective will make it understandable to a different audience, which will help prevent this in the future.

goals

The attackers goal is to add a backdoor to some software that is both commonly installed, and has privileged access.

Some criteria for a good back door:

• The door is hidden
• The door can be used unoticed
• The door has a lock, so others can’t use it
• Because it’s open source, the door plans are hidden too.

location of the plans

The obvious location is OpenSSH. However, that project is very well run. That means hiding the plans becomes difficult.

Well, where else can we hide it? Let’s look:

$ ldd /usr/sbin/sshd

/lib64/ld-linux-x86-64.so.2
libcrypt.so.1 => /lib64/libcrypt.so.1
libaudit.so.1 => /lib64/libaudit.so.1
libpam.so.0 => /lib64/libpam.so.0
...
liblzma.so.5 => /lib64/glibc-hwcaps/x86-64-v3/liblzma.so.1.2.3
libzstd.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libzstd.so.4.5.6
...

It turned out that liblzma, from xz utils is a good choice. On a different day, or a different project, one of the others could have worked.

chapter 1: place the door

front door

If we modify liblzma, how does that open a door in /usr/sbin/sshd?

For that, we need ifunc(). This behaves a little like $LD_PRELOAD, in that we can override functions. It has advantages for the attack:

• It’s less well known. Most setuid binaries filter $LD_PRELOAD
• It’s better hidden.

Let’s give a quick ifunc() example:

int add_numbers_fast(int x, int y) {
    return x + y; /* add */
}

int add_numbers_slow(int x, int y) {
    return x + y; /* add */
}

int add_numbers(int x, int y)
    __attribute__((ifunc ("resolve_add_numbers")));

static void *resolve_add_numbers(void)
{
    if (1)
        return add_numbers_fast;
    else
        return add_numbers_slow;
}

Compile with

gcc -fPIC -shared add_numbers.c  -o add_numbers.so

This has two implementations of add_numbers(), and based on some criteria — like CPU — we pick one.

This is fairly common for performance-critical functions. This is also true for some encryption functions in OpenSSH.

We would then use it with

#include <stddef.h>
#include <stdio.h>

extern int add_numbers(int x, int y);

int main(int argc, char *argv[]) {
    int x, y;
    x = y = 3;
    printf("add_numbers(%d, %d) = %d\n",
           x, y,
           add_numbers(x, y));
    return 0;
}

Output:

add_numbers(3, 3) = 6

backdoor

Suppose the library includes another implementation, like so:

extern int add_numbers(int x, int y);

int add_numbers_fake(int x, int y) {
    return x * y; /* multiply instead! */
}

int add_numbers(int x, int y)
    __attribute__((ifunc ("resolve_add_numbers")));

static void *resolve_add_numbers(void)
{
    return add_numbers_fake;
}

Now we can get modified the output:

add_numbers(3, 3) = 9

a note on compiling

To compile the examples¹, it’s best to split compilation and linking, like

gcc -fPIC -shared add_numbers.c -o add_numbers.so
gcc -fPIC -shared add_numbers_backdoor.c -o add_numbers_backdoor.so
gcc -c ifunc_example.c -o ifunc_example.o
ld /usr/lib64/crti.o /usr/lib64/crtn.o /usr/lib64/crt1.o \
    -lc ifunc_example.o \
    add_numbers_backdoor.so add_numbers.so \
    -dynamic-linker /lib64/ld-linux-x86-64.so.2 \
    -o ifunc_example

Then you can swap implementations by swapping the order of add_numbers.so and add_numbers_backdoor.so

chapter 2: hiding the door

Now that we have something to include, we need to hide it. We cannot add random function names to xz utils: it will get noticed.

A number of systems do automatic checks, like:

$ file *
add_numbers_backdoor.c:  C source, ASCII text
add_numbers_backdoor.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=6883795af4a391d0f9cb256aea233498a37ba668, with debug_info, not stripped
add_numbers.o:           ELF 64-bit LSB relocatable, x86-64, version 1 (GNU/Linux), not stripped
ifunc_example.o:         ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

Adding a binary blob that matches an ELF object will be suspicious.

What we can do is add the file encrypted. In xz this is easy, because it includes binary test data.

A very simple encryption scheme, that shifts a -> b, b -> c, d -> e, …

# encrypt
echo 'hello world' | tr '[a-z]' '[b-z]a'
ifmmp xpsme

To decrypt

# decrypt
echo ifmmp xpsme | tr '[a-z]' 'z[a-y]'
hello world

Now we simply need to decrypt it before compiling.² We can add the following to either the .m4 file or Makefile. Our choice.

cat myfile | tr '[a-z]' 'z[a-y]' > myfile.c
gcc myfile.c

chapter 3: hiding the use

Now that we can include some code in OpenSSH, where is the best place to put it?

• before login, so we’re still root
• before sandboxing³, so we have full access
• after encryption started, so the commands are encrypted

This is why the exploit overrides RSA_public_decrypt.

links

Links to the actual files, and diagnosis of the actual files:

• original openwall announcement
• faq

finger webfinger

Berend De Schouwer

Finger and Webfinger

Finger and Webfinger answer the same question: “what information is available about this user?”

This blog was written because both were harder to get going than necessary.

Webfinger

Webfinger does something similar. Query my mastodon handle, @berend@emptybox.deschouwer.co.za, and you should get something like

{
    "aliases": [
        "https://emptybox.deschouwer.co.za/nextcloud/index.php/index.php/apps/social/@berend",
        "https://emptybox.deschouwer.co.za/nextcloud/index.php/u/berend"
    ],
    "links": [
        {
            "href": "https://emptybox.deschouwer.co.za/nextcloud/index.php/u/berend",
            "rel": "http://webfinger.net/rel/profile-page",
            "type": "text/html"
        }
    ],
    "subject": "berend@emptybox.deschouwer.co.za"
}

It’s a good API to find more information about a specific user.

Finger

Finger is old. It’s from 1991, 5 years before http.

You can see it in action by running

finger berend@berend.deschouwer.co.za

The original finger server was horribly insecure. This server is not running that.

Webfinger Back

The Webfinger backend is provided by the Social app on Nextcloud.

I’m going to document some of the pitfalls here, since:

• An installation step isn’t documented
• Some of the error reporting is misleading.
• All of the official help is “configure your webserver/proxy”, even when the answer isn’t that.
• google-ing this doesn’t help, since everything redirects you back to webserver configuration help.

Configure your webserver

Once, for Nextcloud

Yes, you do need to configure your webserver.

Under your nextcloud instance, when logged in as admin, navigate to security.

If Nextcloud Admin Security Check complains with a similar message

Your web server is not configured correctly to resolve “/.well-known/caldav”. More information can be found on our documentation. Your web server is not configured correctly to resolve “/.well-known/carddav”. More information can be found on our documentation.

You need to fix your webserver or proxy. Follow Google. The solutions are complete.

Configuring Nextcloud

Twice, for the Social App in Nextcloud

Nope, you don’t need to do it twice.

If the Social App complains with a similar message

.well-known/webfinger isn’t properly set up!

Social needs the .well-known automatic discovery to be properly set up. If Nextcloud is not installed in the root of the domain, it is often the case that Nextcloud can’t configure this automatically

The problem is not your webserver. It’s the Social App

Configuring the App (the missing installation step)

You will need the CLI occ from Nextcloud.

You may have used it to perform backups or upgrades. It’s in the webroot, and you will usually run it something like:

sudo -u www /var/www/nextcloud/occ backup

First, look at the config. Run:

cd /var/www/nextcloud/
sudo -u www occ config:list

Look for the Social app.

"social": {
     "address": "https:\/\/emptybox.deschouwer.co.za\/",
     "enabled": "yes",
     "url": "https:\/\/emptybox.deschouwer.co.za\/nextcloud\/index.php\/apps\/social\/",
     "social_url": "https:\/\/emptybox.deschouwer.co.za\/nextcloud\/index.php\/index.php\/apps\/social\/",
     "cloud_url": "https:\/\/emptybox.deschouwer.co.za\/nextcloud\/"
},

Ensure that these values are OK. If they are not, run

sudo -u www php ./occ config:app:set --value https://emptybox.deschouwer.co.za/overthere social url

Three, misleading errors

Webfinger not supported

Now you get to try:

http --follow 'https://emptybox.deschouwer.co.za/.well-known/webfinger?resource=acct%3Aberend'

If you get 404 and

{
    "message": "webfinger not supported"
}

Don’t panic! It doesn’t mean webfinger isn’t supported, it means the account specified isn’t a valid account.

You didn’t specify a domain. Add a domain.

Webfinger is empty and 404

http --follow 'https://emptybox.deschouwer.co.za/.well-known/webfinger?resource=acct%3Aberend%40example.com'

If you get 404 and

""

Dont panic! It means that the specified acocunt (berend@example.com) is not on this server.

Your Nextcloud instance isn’t example.com, so you should specify an account you are authoritive for.

Finger Back

The backend for 1991 finger is a simple script that serves my whoami page.

Since the actual finger servers are insecure, I decided to re-implement it again. Since that means even more insecure, I simplified everything.

systemd to the rescue

This is the reason for writing this section. systemd can really help us locking it down.

[Unit]
Description=Finger Per-Connection Server

[Service]
ExecStart=/usr/.../.py # Keep some things secret
StandardInput=socket
# Send errors to the logs, instead of to the caller
StandardError=journal
SyslogIdentifier=finger
# Don't run as root
DynamicUser=yes
# Don't read /tmp, /dev, /home
PrivateTmp=true
PrivateDevices=true
ProtectHome=true
# Restrict for DoS
MemoryMax=100M
Nice=19
IOSchedulingClass=best-effort
IOSchedulingPriority=7
CPUQuota=50%
IOWeight=25
# Restrict OS calls
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
ProtectSystem=strict
RestrictSUIDSGID=true
MemoryDenyWriteExecute=true
# Don't load calls that are frequently used by exploits
InaccessiblePaths=/usr/bin/at
InaccessiblePaths=/usr/bin/bash
InaccessiblePaths=/usr/bin/sh
InaccessiblePaths=/usr/bin/wget
InaccessiblePaths=/usr/bin/curl
InaccessiblePaths=/usr/bin/ssh
InaccessiblePaths=/usr/bin/scp
InaccessiblePaths=/usr/bin/perl

User

The first level of security, is do not run as root.

No public directories

No public /tmp or any such directory. If you do hack it, your in a sandbox.

Limited Access

Then we lock it down a bit for DoS reasons. We run it low priority, with limited RAM, so you don’t take down the entire machine.

Too many details

Then we lock up some other processes. Some of these are for example purposes.

It’s really, really nice that systemd allows us to lock it down like this.

Multiple users? Nope

The original finger backend allows you to query any user that exists, and changes the output based on whether they are logged in.

Not for me. I give you the same answer, no matter what.

Redirects? Nope

You could query users on another server. Connecting to example.com, you could ask it about joe@smith.com. Not on my server.

Memory Leaks? Nope

You could send very large user names. On my server, you get 512 bytes, then I disconnect.

Since we don’t care about the data, we discard it.

discard = os.read(0, 512)

DoS? Nope

You can’t keep the finger socket open for very long. If it doesn’t receive data very soon, it will disconnect.

def timeout(signum, frame):
    raise Exception("Timed out")

signal.signal(signal.SIGALRM, timeout)
signal.alarm(3)

DDoS? Yep

DDoS is always a “yep”.

More details

I’d give you more details, but here aren’t. We timeout after 3 seconds, we read a maximum of 512 bytes of data, and we always give the exact same response.

why rust won’t let you borrow twice

Berend De Schouwer

What Question Am I Answering?

A question came up in a coding class, about why in Rust there’s a borrow, and there’s a an error when borrowing.

You may have seen it like (copied from the rust book):

error[E0499]: cannot borrow `s` as mutable more than once at a time
 --> src/main.rs:5:14
  |
4 |     let r1 = &mut s;
  |              ------ first mutable borrow occurs here
5 |     let r2 = &mut s;
  |              ^^^^^^ second mutable borrow occurs here
6 |
7 |     println!("{}, {}", r1, r2);
  |                        -- first borrow later used here

For more information about this error, try `rustc --explain E0499`.
error: could not compile `ownership` due to previous error

The Rust book does explain what borrow is, and the theory behind why it’s allowed and not allowed.

I’m showing the risks practical example.

How Am I Answering It?

With as little computer theory as possible.

• No assembler
• No diagrams
• No multiple languages
• short, simple examples
• No theory until after the bug is shown

Caveat

The answer is in C. It’s in C because Rust won’t let me break borrow, not even in an unsafe {} block.

It’s all in plain C, though. No assembler, and no C++. As straightforward C as I can make it, specifically to allow for plain examples. As few as possible shortcuts are taken.

I’m not trying to write a C-programmer’s C code. I’m trying to write an example that shows the problem, for non-C programmers.

It should not be difficult to follow coming from Rust.

Inspiration

The inspiration comes from the C max() function, which is actually a macro.

That is great for explaining the differences between functions and macros, and it’s great for explaining pass-by-code instead of value or reference.

It’s also great for explaining surprises.

First Examples

First, we give example code for pass-by-value and pass-by-reference. Pass-by-reference is also called borrow in Rust. The examples are simple, and we do not yet discuss the difference.

For now, it’s simply about C syntax.

#include <stdio.h>

int double_by_value(int x) {
    x = x * 2;
    return x;
}

int double_by_reference(int *x) {
    *x = *x * 2;
    return *x;
}

int main() {
    int x;
    x = 5;
    printf("double_by_value(x) = %d\n", double_by_value(x));
    /* double_by_value(x) = 10 */
    x = 5;
    printf("double_by_reference(x) = %d\n", double_by_reference(&x));
    /* double_by_reference(x) = 10 */
    return 0;
}

The code is almost identical. You can see the syntax difference, but no functional difference yet.

The logic is the same, the input is the same, and the output is the same.

Extra variables

Let’s make it a tiny bit more challenging, and add a second variable.

#include <stdio.h>

int add_by_value(int x, int y) {
    x = x + y;
    return x;
}

int add_by_reference(int *x, int *y) {
    *x = *x + *y;
    return *x;
}

int main() {
    int x, y;

    x = y = 5;
    printf("add_by_value(x, y) = %d\n", add_by_value(x, y));
    /* add_by_value(x, y) = 10 */
    x = y = 5;
    printf("add_by_reference(x, y) = %d\n", add_by_reference(&x, &y));
    /* add_by_reference(x, y) = 10 */
    return 0;
}

The logic is the same, the input is the same, and the output is the same.

Put it together

Add the two and we get…

#include <stdio.h>

/* Previous example code here */

int add_and_double_by_value(int x, int y) {
    x = double_by_value(x);
    y = double_by_value(y);
    x = x + y;
    return x;
}

int add_and_double_by_reference(int *x, int *y) {
    *x = double_by_reference(x);
    *y = double_by_reference(y);
    *x = *x + *y;
    return *x;
}

int main() {
    int x, y;

    x = y = 5;
    printf("add_and_double_by_value(x, y) = %d\n", add_and_double_by_value(x, y));
    /* add_and_double_by_value(x, y) = 20 */
    x = y = 5;
    printf("add_and_double_by_reference(x, y) = %d\n", add_and_double_by_reference(&x, &y));
    /* add_and_double_by_reference(x, y) = 20 */
    return 0;
}

No surprised yet. Both examples print the same, correct answer.

The logic is the same, the input is the same, and the output is the same.

Surprise

Now let’s make it simpler…

#include <stdio.h>

/* Previous example code here */

int main() {
    int x;
    x = 5;
    printf("add_and_double_by_value(x, x) = %d\n", add_and_double_by_value(x, x));
    /* add_and_double_by_value(x, x) = 20 */
    x = 5;
    printf("add_and_double_by_reference(x, x) = %d\n", add_and_double_by_reference(&x, &x));
    /* add_and_double_by_reference(x, x) = 40 */
    return 0;
}

The logic is the same, the input is the same, but the output is different.

Why is it 40?

Double borrow

So what happened? Why did removing a variable, y, result in the “wrong” answer?

Pass by value copies the value, and passes the value, not the variable. The original is never modified.

Pass by reference (or borrow), passes a reference, not a copy. The original is modified.

Look at

int add_and_double_by_reference(int *x, int *y) {
    *x = double_by_reference(x);
    *y = double_by_reference(y);
    *x = *x + *y;
    return *x;
}

When x is doubled, at *x = double_by_reference(x);, and *x is also *y, y is also doubled. X is now 10, as expected, but y is also 10.

Then y is doubled. And since *y is _also *x, x is doubled again. Now both variables are 20.

Tada!

This is (one of the reasons) why Rust won’t let you borrow the same variable twice.

What do you do instead?

Borrow once, or .clone() /* copy */.

Bonus time

So why have pass by reference or borrow at all?

1. It’s faster, when the data is large.
2. It’s faster for streamed data.
3. It’s not possible in assembler pass complicated variables by value. Manual copies must be made, and the language you use might not implement implicit copies.

Extra Points

For extra points, do the same with threads.

garmin connect doesn’t connect firmware to users

Berend De Schouwer

4-Way handshake failed for ifindex: 3, reason: 15
KEY_SEQ not returned in GET_KEY reply

rust async on single vs. multi-core machines

Berend De Schouwer

    debug!("This runs");
    Err("This does not run!")
}

task::spawn(tty_to_websocket());
task::spawn(websocket_ty_tty());
try_join!(tty_to_websocket, websocket_to_tty);

fn error() -> Result<> {
    let number: int = 2;
    Err("error");
}

unsafe { let rust_fd = std::os::from_raw_fd(c_fd); }

This function consumes ownership of the specified file
descriptor. The returned object will take responsibility
for closing it when the object goes out of scope.

mem::forget(rust_fd);

try_join!(tty_to_websocket, websocket_to_tty);
close(c_fd);

let buffer = reader.buffer();
drop(buffer);