Recently I completed a leadership course with my local Education and Training Board. To be honest, there wasn’t anything really new in it that I hadn’t come across in other training or books over the years. But it did provide a timely opportunity to think more deliberately about the causes of conflict and the approaches to resolution, useful preparation for giving a better answer to that question.

So, when we see conflict arising, how do we deal with it? The answer, as usual, is – it depends. But as a broad guideline, the first step is to figure out the cause.

The textbook taxonomy is Christopher Moore’s Circle of Conflict, which identifies Relationship, Data, Structural, Value and Interest as the main conflict types. The course I attended broke this down slightly differently, in a way that matches my experience more closely:

• Poor communication
• Clashes in personalities or working styles
• Competing needs or interests
• Different values
• Ambiguity in the workplace
• Performance issues

Looking back on the conflicts I’ve dealt with, they fit more naturally into those categories than into Moore’s original five. Performance issues and poor communication, for instance, both deserve their own category in modern workplaces.

As a manager dealing with conflict, your role is mostly that of a mediator. Imposing solutions rarely works; it may resolve the immediate situation but tends to store up bigger problems for later.

My approach depends on the severity and the situation, but broadly:

• I meet with people individually to understand their perspective first. What’s actually causing the conflict for them?, how do they feel?, what do they want?
• then bring both parties together to facilitate a calm exchange of views. Sometimes we may set some simple ground rules – don’t interrupt, don’t criticise the person rather than the behaviour
• From there it’s about exploring possible solutions and aiming for an outcome both sides can live with. Sometimes this involves finding a compromise or trade off, sometimes it involves setting boundaries, it’s about finding something that both people are happy with.

When working through conflict with people, and indeed when you find yourself in one, it’s worth being mindful of the different approaches people take. Most people don’t like conflict, so avoidance is often the default. Sometimes that’s fine: if the matter is trivial or genuinely doesn’t need immediate attention, letting it pass isn’t always wrong. But if we avoid dealing with conflict, we risk it growing into something harder to address later.

The main conflict styles taught in leadership courses trace back to the Thomas-Kilmann Conflict Mode Instrument (1974), which identifies five approaches:

• Avoid – sidestep the issue entirely
• Accommodate – give ground to preserve the relationship
• Compete – assert your position regardless of the other party
• Compromise – both sides give something to get something
• Collaborate – work together toward a genuine win-win

There are situations where all five are valid. As a mediator, your job is partly to recognise which mode the parties are operating in and adjust accordingly. You can’t force people to change their style, but you can create conditions where they engage more productively. As a general principle, the goal should be to move toward compromise or collaboration wherever possible.

So how do I answer the interview question now, without disappearing into conflict theory? I say that the cause and the right response depend on the type of conflict, its severity, and the people involved. Then I give a specific example where I facilitated a resolution, one where both parties came out with something they could accept. If pushed, I have a couple of more difficult scenarios ready too.

It’s not a perfect answer. But it’s one I can give without waffling.

When I got the MUD running, I noticed something odd: I could only connect using the system hostname or its IP address. Connections to localhost, 127.0.0.1, or even the host’s IPv6 address all failed:

$  telnet 192.168.0.76 6715
Trying 192.168.0.76...
Connected to 192.168.0.76.
Escape character is '^]'.
                A B E R M U D 
                
Game Time Elapsed: 6 minutes, 52 seconds

By what name shall I call you? ^]
telnet> q
Connection closed.
$ telnet localhost 6715
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
$ 

$  telnet 192.168.0.76 6715
Trying 192.168.0.76...
Connected to 192.168.0.76.
Escape character is '^]'.
                A B E R M U D 
                
Game Time Elapsed: 6 minutes, 52 seconds

By what name shall I call you? ^]
telnet> q
Connection closed.
$ telnet localhost 6715
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
$ 

So it works, but seems not to be accepting connections on all interfaces.

Check what we’re actually listening on

First stop netstat (or ss):

$ netstat -lntp|grep 6715
tcp        0      0 192.168.0.76:6715       0.0.0.0:*               LISTEN      1312388/../bin/aber 
$ ss -lntp|grep 6715
LISTEN 0      5       192.168.0.76:6715       0.0.0.0:*    users:(("aberd",pid=1312388,fd=0))           
$ 

$ netstat -lntp|grep 6715
tcp        0      0 192.168.0.76:6715       0.0.0.0:*               LISTEN      1312388/../bin/aber 
$ ss -lntp|grep 6715
LISTEN 0      5       192.168.0.76:6715       0.0.0.0:*    users:(("aberd",pid=1312388,fd=0))           
$ 

• 192.168.0.76:6715 – the local address and port we’re bound to
• 0.0.0.0:* – any remote address and port

So the process is bound specifically to 192.168.0.76. It won’t accept connections addressed to 127.0.0.1 or ::1. We’ll accept connections _from_ anywhere, but only if they connect to 192.168.0.76

Confirming with strace

A quick strace confirms what’s happening – we’re binding specifically to 192.168.0.76

$ strace ../bin/aberd -f 2>&1|grep bind
bind(4, {sa_family=AF_INET, sin_port=htons(6715), sin_addr=inet_addr("192.168.0.76")}, 16) = 0

$ strace ../bin/aberd -f 2>&1|grep bind
bind(4, {sa_family=AF_INET, sin_port=htons(6715), sin_addr=inet_addr("192.168.0.76")}, 16) = 0

The Simple fix – just bind to all interfaces

A quick grep for ‘bind’ & ‘listen’ in the code points us to s_socket.c. This has the standard socket operations you’d expect for sockets.

int make_service(short unsigned int port,
		 char               *my_hostname,
		 int                my_hostnamelen,
		 struct hostent     **hp,
		 struct sockaddr_in *sin)
{
  int s, i;
  struct hostent *h;

  if (gethostname(my_hostname,my_hostnamelen) < 0) {
    return -1; /* Error in hostname? */
  }
  if ((*hp = h = gethostbyname(my_hostname)) == NULL) {
    return -2; /* Error in gethostbyname */
  }
  bzero(sin,sizeof(struct sockaddr_in));
  sin->sin_family = AF_INET;
  sin->sin_port = htons(port);
  bcopy(h->h_addr_list[0],&(sin->sin_addr),h->h_length);

  if ((s = socket(AF_INET,SOCK_STREAM,0)) < 0) {
    return -3; /* Error in socket call */
  }

  /* Bug fix for hanging sockets. Socket options need to be set before
   * the bind takes place or they dont do ANY good.
   */
  i = 2;
  if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &i, sizeof(i)) == -1) {
	  progerror("setsockopt(reuseaddr)");
  }

  if (bind(s,(struct sockaddr *)sin,sizeof(*sin)) < 0) {
    close(s);
    return -4; /* Error in bind. */
  }
  if (listen(s,5) != 0) {
    close(s);
    return -5; /* Error in listen */
  }

int make_service(short unsigned int port,
		 char               *my_hostname,
		 int                my_hostnamelen,
		 struct hostent     **hp,
		 struct sockaddr_in *sin)
{
  int s, i;
  struct hostent *h;

  if (gethostname(my_hostname,my_hostnamelen) < 0) {
    return -1; /* Error in hostname? */
  }
  if ((*hp = h = gethostbyname(my_hostname)) == NULL) {
    return -2; /* Error in gethostbyname */
  }
  bzero(sin,sizeof(struct sockaddr_in));
  sin->sin_family = AF_INET;
  sin->sin_port = htons(port);
  bcopy(h->h_addr_list[0],&(sin->sin_addr),h->h_length);

  if ((s = socket(AF_INET,SOCK_STREAM,0)) < 0) {
    return -3; /* Error in socket call */
  }

  /* Bug fix for hanging sockets. Socket options need to be set before
   * the bind takes place or they dont do ANY good.
   */
  i = 2;
  if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &i, sizeof(i)) == -1) {
	  progerror("setsockopt(reuseaddr)");
  }

  if (bind(s,(struct sockaddr *)sin,sizeof(*sin)) < 0) {
    close(s);
    return -4; /* Error in bind. */
  }
  if (listen(s,5) != 0) {
    close(s);
    return -5; /* Error in listen */
  }

We call socket(2), then bind(2) to it and finally listen(2). The simplest fix here would be to simply listen on all interfaces, and that was my first fix here – just add this before we bind()

sin->sin_addr.s_addr = htonl(INADDR_ANY);

sin->sin_addr.s_addr = htonl(INADDR_ANY);

strace now shows we’re listening everywhere:

$ strace ../bin/aberd -f 2>&1 | grep bind
bind(4, {sa_family=AF_INET, sin_port=htons(6715), sin_addr=inet_addr("0.0.0.0")}, 16) = 0

$ strace ../bin/aberd -f 2>&1 | grep bind
bind(4, {sa_family=AF_INET, sin_port=htons(6715), sin_addr=inet_addr("0.0.0.0")}, 16) = 0

After that chage we can connect via localhost, the hosts IP, hostname etc.

Why Was It Written This Way?

INADDR_ANY was around when this was written so why did MUDs want to bind to a specific hostname? I guess it was simply a different era and different ‘patterns’ were used. These days it seems logical to bind to all interfaces and implement restrictions with iptables. Back then perhaps it was more like listen on the interface that this system is known as.

You might have had a system called sionnach and that would be the hostname and assigned to a particular interface. But another interface might be assigned say sionnach-private so we wouldn’t listen on that, just the interface that corresponded to the hostname.

Time to modernise

The above code uses bcopy() which I don’t recall seeing before. Even my copy of Stevens(1993) uses memcpy. So this could could do with an update from these depreciated calls. Also it’s not accepting connections on IPv6 addresses.

A bit of reading later and the standard approach to this seems to be to use a duak-stack socket. It basically does:

• try IPv6 first
• allow it to accept IPv4 connections (IPV6_V6ONLY = 0)
• fall back to IPv4 if needed

and while we’re at it we can get rid of my_hostent and s_in which are unused.

Updated function:

int make_service(short unsigned int port, char *my_hostname, size_t my_hostnamelen)
{
  int s, i;
  struct sockaddr_in6 sin6;
  int ipv6_only = 0; /* 0 = allow both IPv4 and IPv6 (dual-stack) */

  if (gethostname(my_hostname, my_hostnamelen) < 0) {
    return -1; /* Error in hostname? */
  }

  /* Try to create an IPv6 socket that also accepts IPv4 connections (dual-stack) */
  memset(&sin6, 0, sizeof(sin6));
  sin6.sin6_family = AF_INET6;
  sin6.sin6_port = htons(port);
  sin6.sin6_addr = in6addr_any; /* Bind to all interfaces */

  if ((s = socket(AF_INET6, SOCK_STREAM, 0)) < 0) {
    /* IPv6 not available, fall back to IPv4 */
    struct sockaddr_in sin4;
    memset(&sin4, 0, sizeof(sin4));
    sin4.sin_family = AF_INET;
    sin4.sin_port = htons(port);
    sin4.sin_addr.s_addr = htonl(INADDR_ANY);

    if ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
      return -3; /* Error in socket call */
    }

    /* Original SO_REUSEADDR code */
    i = 1;
    if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &i, sizeof(i)) == -1) {
      progerror("setsockopt(SO_REUSEADDR, v4)");
    }

    if (bind(s, (struct sockaddr *)&sin4, sizeof(sin4)) < 0) {
      close(s);
      return -4; /* Error in bind. */
    }
  } else {
    /* IPv6 socket created - set up dual-stack to also accept IPv4 */

    /* Original SO_REUSEADDR code */
    i = 1;
    if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &i, sizeof(i)) == -1) {
      progerror("setsockopt(SO_REUSEADDR, v6)");
    }

    /* Explicitly set IPV6_V6ONLY to 0 to allow both IPv4 and IPv6 connections */
    if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &ipv6_only, sizeof(ipv6_only)) == -1) {
        /* If this fails, we can still bind but it will be IPv6 only, so just continue */
    }

    if (bind(s, (struct sockaddr *)&sin6, sizeof(sin6)) < 0) {
      close(s);
      return -4; /* Error in bind. */
    }
  }

  if (listen(s, 5) != 0) {
    close(s);
    return -5; /* Error in listen */
  }

  return s;
}

int make_service(short unsigned int port, char *my_hostname, size_t my_hostnamelen)
{
  int s, i;
  struct sockaddr_in6 sin6;
  int ipv6_only = 0; /* 0 = allow both IPv4 and IPv6 (dual-stack) */

  if (gethostname(my_hostname, my_hostnamelen) < 0) {
    return -1; /* Error in hostname? */
  }

  /* Try to create an IPv6 socket that also accepts IPv4 connections (dual-stack) */
  memset(&sin6, 0, sizeof(sin6));
  sin6.sin6_family = AF_INET6;
  sin6.sin6_port = htons(port);
  sin6.sin6_addr = in6addr_any; /* Bind to all interfaces */

  if ((s = socket(AF_INET6, SOCK_STREAM, 0)) < 0) {
    /* IPv6 not available, fall back to IPv4 */
    struct sockaddr_in sin4;
    memset(&sin4, 0, sizeof(sin4));
    sin4.sin_family = AF_INET;
    sin4.sin_port = htons(port);
    sin4.sin_addr.s_addr = htonl(INADDR_ANY);

    if ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
      return -3; /* Error in socket call */
    }

    /* Original SO_REUSEADDR code */
    i = 1;
    if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &i, sizeof(i)) == -1) {
      progerror("setsockopt(SO_REUSEADDR, v4)");
    }

    if (bind(s, (struct sockaddr *)&sin4, sizeof(sin4)) < 0) {
      close(s);
      return -4; /* Error in bind. */
    }
  } else {
    /* IPv6 socket created - set up dual-stack to also accept IPv4 */

    /* Original SO_REUSEADDR code */
    i = 1;
    if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &i, sizeof(i)) == -1) {
      progerror("setsockopt(SO_REUSEADDR, v6)");
    }

    /* Explicitly set IPV6_V6ONLY to 0 to allow both IPv4 and IPv6 connections */
    if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &ipv6_only, sizeof(ipv6_only)) == -1) {
        /* If this fails, we can still bind but it will be IPv6 only, so just continue */
    }

    if (bind(s, (struct sockaddr *)&sin6, sizeof(sin6)) < 0) {
      close(s);
      return -4; /* Error in bind. */
    }
  }

  if (listen(s, 5) != 0) {
    close(s);
    return -5; /* Error in listen */
  }

  return s;
}

That’s my first proper dive into IPv6. A couple of hours of RFCs, compiler errors, and man pages later… 🙂 Beej’s Guide to Network Programming was the best resource I found for this https://beej.us/guide/bgnet/html/#jumping-from-ipv4-to-ipv6 but https://www.rfc-editor.org/rfc/rfc3493.html is also worth a scan

The full changeset is at https://github.com/albertw/dirt/commit/7fcf310e4588b7eb1212161cefb2a5ef4767c5e4

I think this is portable, but if anyone runs into a problem on non-linux post an issue on github please!

As a refresher this is what gdb showed us as the problem:

Program received signal SIGSEGV, Segmentation fault.
check_send_msg (plx=plx@entry=111, a=a@entry=-13872, t=t@entry=0x7fffffffd1f0 "The Thief has gone west.\n") at sendsys.c:172
172 if (test_rcv(plx,b->mode,b->min,b->max,b->x1,b->x2)) return t;
(gdb)

Program received signal SIGSEGV, Segmentation fault.
check_send_msg (plx=plx@entry=111, a=a@entry=-13872, t=t@entry=0x7fffffffd1f0 "The Thief has gone west.\n") at sendsys.c:172
172 if (test_rcv(plx,b->mode,b->min,b->max,b->x1,b->x2)) return t;
(gdb)

I said that the address didn’t look right, and that’s probably one of the most frustrating things about learning this kind of debugging.

I have sat down many times with experienced engineers to work through crash dumps, and at some point they inevitably say that “something looks wrong.” That comes from experience, and it’s difficult to explain to someone unfamiliar with the code why it looks wrong.

So here’s how we can dig down and see exactly what the problem was caused by.

This is also often where you find yourself looking up assembly instructions and registers. Unless you’re doing this regularly, you forget it, the goal is to have some idea of what to look for, rather than retaining detailed knowledge of x86 assembly.

Looking at the instruction that caused the segfault

On x64, we can look at the instruction pointer to see exactly what line of assembly the CPU is currently executing:

(gdb) x/i $rip
=> 0x426e72 : cmp %edi,0xc(%rsi)
(gdb)

(gdb) x/i $rip
=> 0x426e72 : cmp %edi,0xc(%rsi)
(gdb)

This is comparing %edi with 0xc(%rsi), specifically, the value in the register %edi with the value at the memory address stored in %rsi + 12 (0xc in hex).

This corresponds to part of the C call

test_rcv(plx,b->mode,b->min,b->max,b->x1,b->x2)

test_rcv(plx,b->mode,b->min,b->max,b->x1,b->x2)

A quick note on registers

On x64, when we call a function, arguments are passed in registers:

You can dump all registers with:

(gdb) info registers
...
rsi 0xffffffffffffc9d0 -13872
rdi 0x6f 111
...

(gdb) info registers
...
rsi 0xffffffffffffc9d0 -13872
rdi 0x6f 111
...

Register sizes

On a 64-bit system, rdi is a 64-bit register. The instruction above uses edi, which is the lower 32 bits.

In this case, they contain the same value:

(gdb) print $rdi
$5 = 111
(gdb) print $edi
$6 = 111

(gdb) print $rdi
$5 = 111
(gdb) print $edi
$6 = 111

GDB already told us that the first argument (plx) is 111, so this lines up.

Mapping back to the C code

The second argument is a:

(gdb) list
167
168 char *check_send_msg(int plx, int a, char *t)
169 {
170 struct _send_msg_box *b = (struct _send_msg_box *)a;
171
172 if (test_rcv(plx,b->mode,b->min,b->max,b->x1,b->x2)) return t;
173 return NULL;
174 }

(gdb) list
167
168 char *check_send_msg(int plx, int a, char *t)
169 {
170 struct _send_msg_box *b = (struct _send_msg_box *)a;
171
172 if (test_rcv(plx,b->mode,b->min,b->max,b->x1,b->x2)) return t;
173 return NULL;
174 }

The assembly is comparing that 111 with the contents of the address at rsi + 12.

Why +12?

Let’s look at the struct:

(gdb) ptype struct _send_msg_box
type = struct _send_msg_box {
    int mode;
    int min;
    int max;
    int x1;
    int x2;
}

(gdb) ptype struct _send_msg_box
type = struct _send_msg_box {
    int mode;
    int min;
    int max;
    int x1;
    int x2;
}

It’s just five integers:

• mode → offset 0
• min → offset 4
• max → offset 8
• x1 → offset 12
• x2 → offset 16

So rsi + 12 corresponds to b->x1.

The compiler has generated assembly that accesses that field first.

The real problem

However, we don’t actually need to go that far to find the issue.

Just look at rsi:

gdb) print $rsi
$9 = -13872
(gdb) print/x $rsi
$10 = 0xffffffffffffc9d0
(gdb) x/x $rsi
0xffffffffffffc9d0:	Cannot access memory at address 0xffffffffffffc9d0

gdb) print $rsi
$9 = -13872
(gdb) print/x $rsi
$10 = 0xffffffffffffc9d0
(gdb) x/x $rsi
0xffffffffffffc9d0:	Cannot access memory at address 0xffffffffffffc9d0

We know this is supposed to be a memory address, when we try to examine it we get told we can’t access it.

At that point, we can go back through the code and see how that value ended up there.

Conclusion

Do you need to know all of this? Not really.

With practice, you do get a feel for what looks wrong. In reality, you’d probably only need to go as far as I did in the last blog post where we got the ‘Cannot access memory at address’ message. But it’s handy to know how to poke around a bit more.

Connected to port 6715 on sionnach.
Segmentation fault (core dumped)

Connected to port 6715 on sionnach.
Segmentation fault (core dumped)

Good start.

1. Run it under GDB

First step: run the server under GDB so we can see where it crashes.

gdb --args ../bin/aberd -f

gdb --args ../bin/aberd -f

The –args lets us pass arguments (-f keeps the MUD in the foreground).

Then:

(gdb) run

(gdb) run

Pretty quickly we hit:

Program received signal SIGSEGV, Segmentation fault.
check_send_msg (plx=111, a=-13872, t="The Thief has gone west.\n") at sendsys.c:172

Program received signal SIGSEGV, Segmentation fault.
check_send_msg (plx=111, a=-13872, t="The Thief has gone west.\n") at sendsys.c:172

I didn’t even need to connect this time, the NPC movement message alone triggered the crash!

2. Get the backtrace

First thing to do it get a backtrace:

(gdb) bt
#0  check_send_msg (plx=plx@entry=111, a=a@entry=-13872, t=t@entry=0x7fffffffd1f0 "The Thief has gone west.\n") at sendsys.c:172
#1  0x0000000000427318 in send_g_msg (destination=destination@entry=-613, func=func@entry=0x426e6b <check_send_msg>, arg=arg@entry=-13872, text=text@entry=0x7fffffffd1f0 "The Thief has gone west.\n")
    at sendsys.c:151
#2  0x0000000000427426 in send_msg (destination=-613, mode=mode@entry=0, min=<optimized out>, max=max@entry=100000, x1=x1@entry=111, x2=x2@entry=-32766, format=0x437c0b "%s has gone %s.\n") at sendsys.c:205
#3  0x000000000041a2ea in movemob (x=x@entry=111) at mobile.c:739
#4  0x000000000041a482 in consid_move (mon=mon@entry=111) at mobile.c:647
#5  0x000000000041a5af in move_mobiles () at mobile.c:527
#6  0x0000000000428462 in on_timer () at timing.c:538
#7  0x000000000041745a in main_loop (m_socket=m_socket@entry=0) at main.c:544
#8  0x0000000000418312 in xmain (fd=<optimized out>) at main.c:172
#9  main (argc=<optimized out>, argv=<optimized out>, ep=<optimized out>) at main.c:90
(gdb)

(gdb) bt
#0  check_send_msg (plx=plx@entry=111, a=a@entry=-13872, t=t@entry=0x7fffffffd1f0 "The Thief has gone west.\n") at sendsys.c:172
#1  0x0000000000427318 in send_g_msg (destination=destination@entry=-613, func=func@entry=0x426e6b <check_send_msg>, arg=arg@entry=-13872, text=text@entry=0x7fffffffd1f0 "The Thief has gone west.\n")
    at sendsys.c:151
#2  0x0000000000427426 in send_msg (destination=-613, mode=mode@entry=0, min=<optimized out>, max=max@entry=100000, x1=x1@entry=111, x2=x2@entry=-32766, format=0x437c0b "%s has gone %s.\n") at sendsys.c:205
#3  0x000000000041a2ea in movemob (x=x@entry=111) at mobile.c:739
#4  0x000000000041a482 in consid_move (mon=mon@entry=111) at mobile.c:647
#5  0x000000000041a5af in move_mobiles () at mobile.c:527
#6  0x0000000000428462 in on_timer () at timing.c:538
#7  0x000000000041745a in main_loop (m_socket=m_socket@entry=0) at main.c:544
#8  0x0000000000418312 in xmain (fd=<optimized out>) at main.c:172
#9  main (argc=<optimized out>, argv=<optimized out>, ep=<optimized out>) at main.c:90
(gdb)

How we can see that the flow of the program. We have a main loop and within that we move mobiles (NPCs) around and when they move a message gets printed.

3. Look at the crashing function

gdb can display code inline (list) but I prefer to use a separate terminal. So lets look at check_send_msg

struct _send_msg_box {
  int mode;
  int min;
  int max;
  int x1;
  int x2;
};

char *check_send_msg(int plx, int a, char *t)
{
  struct _send_msg_box *b = (struct _send_msg_box *)a;
  
  if (test_rcv(plx,b->mode,b->min,b->max,b->x1,b->x2)) return t;
  return NULL;
}

struct _send_msg_box {
  int mode;
  int min;
  int max;
  int x1;
  int x2;
};

char *check_send_msg(int plx, int a, char *t)
{
  struct _send_msg_box *b = (struct _send_msg_box *)a;
  
  if (test_rcv(plx,b->mode,b->min,b->max,b->x1,b->x2)) return t;
  return NULL;
}

We segfault just on that test_rcv line.

4. Inspect variables in GDB

What I typically do at this point is just print the arguments and see if something jumps out. We could look at the instruction pointer and see exactly where were crashing if we needed to, perhaps in another post.

(gdb) print plx
$3 = 111
(gdb) print b
$4 = (struct _send_msg_box *) 0xffffffffffffc9d0
(gdb) print b->mode
Cannot access memory at address 0xffffffffffffc9d0
(gdb) print b->min
Cannot access memory at address 0xffffffffffffc9d4
(gdb) print b->x2
Cannot access memory at address 0xffffffffffffc9e0
(gdb) 

(gdb) print plx
$3 = 111
(gdb) print b
$4 = (struct _send_msg_box *) 0xffffffffffffc9d0
(gdb) print b->mode
Cannot access memory at address 0xffffffffffffc9d0
(gdb) print b->min
Cannot access memory at address 0xffffffffffffc9d4
(gdb) print b->x2
Cannot access memory at address 0xffffffffffffc9e0
(gdb) 

plx is probably fine, but those memory addresses look wrong, that’s an invalid memory address.

5. Where did b come from?

Back tot he code and we see :

struct _send_msg_box *b = (struct _send_msg_box *)a;

struct _send_msg_box *b = (struct _send_msg_box *)a;

b is just a reinterpreted as a pointer. so if a is a valid address b should be valid.

(gdb) print a
$5 = -13872
(gdb)

(gdb) print a
$5 = -13872
(gdb)

oh. Looking at the function declaration we see :

char *check_send_msg(int plx, int a, char *t)

char *check_send_msg(int plx, int a, char *t)

a is an integer. If it’s supposed to be a memory address it shouldn’t be an integer. You would get away with that on a 32 bit system but not modern 64 bit hardware. So it’s likely that somewhere we had a proper memory address but chopped it to an int somewhere.

6. Follow the value backwards

stepping back to where we call send_g_msg we see that we also have an address of -13872

(gdb) frame 1
#1  0x0000000000427318 in send_g_msg (destination=destination@entry=-613, func=func@entry=0x426e6b <check_send_msg>, arg=arg@entry=-13872, text=text@entry=0x7fffffffd1f0 "The Thief has gone west.\n")
    at sendsys.c:151
151		  (t = (func == NULL ? text : func(p, arg, text))) != NULL &&
(gdb) print arg
$8 = -13872
(gdb) 

(gdb) frame 1
#1  0x0000000000427318 in send_g_msg (destination=destination@entry=-613, func=func@entry=0x426e6b <check_send_msg>, arg=arg@entry=-13872, text=text@entry=0x7fffffffd1f0 "The Thief has gone west.\n")
    at sendsys.c:151
151		  (t = (func == NULL ? text : func(p, arg, text))) != NULL &&
(gdb) print arg
$8 = -13872
(gdb) 

and the function declaration says int again:

void send_g_msg(int destination,                        /* Where to send to */
                char *func(int plx, int arg, char *t),  /* Test function */
                int arg,                             /* Argument to test */
                char *text)                          /* Text to send */
{ 

void send_g_msg(int destination,                        /* Where to send to */
                char *func(int plx, int arg, char *t),  /* Test function */
                int arg,                             /* Argument to test */
                char *text)                          /* Text to send */
{ 

So lets step back again to send_msg:

(gdb) frame 2
#2  0x0000000000427426 in send_msg (destination=-613, mode=mode@entry=0, min=<optimized out>, max=max@entry=100000, x1=x1@entry=111, x2=x2@entry=-32766, format=0x437c0b "%s has gone %s.\n") at sendsys.c:205
205	  send_g_msg(destination,check_send_msg,(int)&b,bf);
(gdb) print b
$9 = {mode = 0, min = 0, max = 100000, x1 = 111, x2 = -32766}
(gdb) print (int)&b
$10 = -13872
(gdb) print &b
$11 = (struct _send_msg_box *) 0x7fffffffc9d0

(gdb) frame 2
#2  0x0000000000427426 in send_msg (destination=-613, mode=mode@entry=0, min=<optimized out>, max=max@entry=100000, x1=x1@entry=111, x2=x2@entry=-32766, format=0x437c0b "%s has gone %s.\n") at sendsys.c:205
205	  send_g_msg(destination,check_send_msg,(int)&b,bf);
(gdb) print b
$9 = {mode = 0, min = 0, max = 100000, x1 = 111, x2 = -32766}
(gdb) print (int)&b
$10 = -13872
(gdb) print &b
$11 = (struct _send_msg_box *) 0x7fffffffc9d0

7. Root cause

We took a valid pointer:

0x7fffffffc9d0

and did this:

(int)&b

On a 64-bit system:

• pointers = 64 bits
• int = 32 bits

So we truncate the pointer, keeping only the low 32 bits:

0x7fffffffc9d0 -> 0x0000c9d0 -> -13872

Later, it gets cast back to a pointer:

(struct _send_msg_box *)a

Which becomes:

0xffffffffffffc9d0   

Then we dereference it:

b->mode

Segmentation fault

8. The Fix

The correct solution is to use a type that can safely hold a pointer. After a bit of reading I found that the correct way to do this is with intptr_t:

#include <stdint.h>
intptr_t arg;

#include <stdint.h>
intptr_t arg;

Update the function signatures:

char *check_send_msg(int plx, intptr_t a, char *t)
{
  struct _send_msg_box *b = (struct _send_msg_box *)a;
  ...
}

char *check_send_msg(int plx, intptr_t a, char *t)
{
  struct _send_msg_box *b = (struct _send_msg_box *)a;
  ...
}

void send_g_msg(..., intptr_t arg, ...)

void send_g_msg(..., intptr_t arg, ...)

And call it like:

send_g_msg(destination, check_send_msg, (intptr_t)&b, bf);

send_g_msg(destination, check_send_msg, (intptr_t)&b, bf);

My changeset for this is at https://github.com/albertw/dirt/commit/94ec62c63e144920a04ca2e7e4290e04d0ee0319

9. Verify the fix

We can just run the mud and see that it doesn’t segfault, but a little better is to run it in gdb, set a breakpoint, and inspect that we have the right values now:

gdb) break check_send_msg<br>Breakpoint 1 at 0x426e6b: file sendsys.c, line 170.
(gdb) run
.
.
.
Breakpoint 1, check_send_msg (plx=plx@entry=111, a=a@entry=140737488341456, t=t@entry=0x7fffffffd1f0 "The Thief has gone west.\n") at sendsys.c:170<br>170 {<br>
(gdb) p a
$1 = 140737488341456
(gdb) p/x a
$2 = 0x7fffffffc9d0
(gdb) p *(struct _send_msg_box *)a<br>$3 = {mode = 0, min = 0, max = 100000, x1 = 114, x2 = -32766}

gdb) break check_send_msg<br>Breakpoint 1 at 0x426e6b: file sendsys.c, line 170.
(gdb) run
.
.
.
Breakpoint 1, check_send_msg (plx=plx@entry=111, a=a@entry=140737488341456, t=t@entry=0x7fffffffd1f0 "The Thief has gone west.\n") at sendsys.c:170<br>170 {<br>
(gdb) p a
$1 = 140737488341456
(gdb) p/x a
$2 = 0x7fffffffc9d0
(gdb) p *(struct _send_msg_box *)a<br>$3 = {mode = 0, min = 0, max = 100000, x1 = 114, x2 = -32766}

This is a classic example of why legacy C code that ‘worked fine’ on 32-bit systems can fail in subtle ways on modern architectures, and why types matter more than they seem.

One of the most beloved of these for my uni group was Northern Lights, hosted originally at the Computer Society of Luleå University of Technology in Sweden (alber.ludd.luth.se 6715!). It later moved under the care of its founder, Anna “Vitastjern” Eklund. Sadly, a catastrophic server failure a few years ago destroyed the world and its source code. As Anna wrote in a recent facebook message:

I’m sorry, the source code is not available due to the catastrophic failure of the server. Furthermore I promised the authors of quite a few NL‑specific zones to never give them out, so I am against people reverse engineering them without the authors’ consent.

If you get hold of the base dirt3 source code that NL and other MUDs were built on, please have fun with it, but make it your own work and place.

NL existed for 31+ years. Let it rest now.

For many of us, NL was a formative part of early online life. And for me, it also brought back memories of Eiru, a MUD based on the same codebase that I ran in UCD Netsoc in the late ’90s. That world, too, has long since vanished.

But the story doesn’t end there.

A few weeks ago, I got in touch with Amy Antonucci via Facebook. She was still in touch with Alf Salte, the original author of the Dirt MUD engine, itself descended from AberMUD (a rabbit hole for another day). Alf still had the original Dirt source code and gave permission for it to be made public again.

So after more than 30 years, the code that seeded Northern Lights, Eiru, and countless other MUDs is available on github.

This codebase hasn’t been touched since 1994, so getting it running again has been… educational. Let’s just say I’ve become reacquainted with gdb. I’ll write more about those adventures in future posts.

For now, though, I’m happy to share that the Dirt MUD engine, complete with zone files, is on GitHub: https://github.com/albertw/dirt

If you’re interested in retro gaming, game history, or just want to poke around a piece of online‑gaming archaeology, have a look. Bug reports, fixes, and pull requests are very welcome. And if anyone out there has old patches, zone files, or stories from the Dirt lineage, I’d love to include them.

So how did it go? In a couple of weeks of part-time work, I built and deployed a functional MVP to production: www.armaria.club (app.armaria.club). Here are my key takeaways. These aren’t universal rules, just what worked well for me while developing a real application with AI assistance. I’m also very aware that with the current pace of AI assisted tools this will probably be out of date before I post it! 🙂

I’m late to this party – AI-assisted coding has been evolving rapidly over the past few years. But what I’m noticing is that many senior engineers are only starting to engage deeply with AI assistance recently. If that trend is representative across the industry, it means many architects, designers, QA engineers, and software leads are only beginning their AI journey. And we’re only beginning to see the impact of AI across the software development lifecycle.

I’ve experimented with ChatGPT and Claude before on programming tasks and learning exercises, but this was my first time building a production application with AI assistance. I chose Django because it’s a framework I used extensively at Oracle and know well. I assumed I’d be better positioned to review Claude’s design decisions and code changes if I deeply understood the framework. My expectation is that AI assistance works best with greenfield or well-understood codebases – I haven’t yet tried using it extensively with mature legacy code.

I used Claude via a z.ai subscription https://z.ai/subscribe?ic=HI1H8NMTBC (referral link)

1. Refine the Idea (Write a PRD)

This might seem old-school, but step away from the laptop, grab a coffee, and write down what your app needs to do. Create an initial Product Requirements Document (PRD). Ask yourself:

• What problem are you trying to solve?
• Who are the target users?
• What are the core concepts within the app?
• What are the goals?
• What’s the core functionality needed for version 1?
• What’s out of scope now but planned for the future?
• What are your security requirements?
• What are your technical constraints?
• Do you have any guiding principles?

Share this with your AI—it becomes your source of truth for requirements and informs your technical instructions (your claude.md file).

2. Plan (Use Claude’s Planning Features)

Use Claude to discuss and develop a plan for each feature. I found it helpful to:

• Use multiple models as independent reviewers. This reduces blind spots and often surfaces alternative architectural approaches.
• Discuss ideas with ChatGPT first to formulate detailed prompts for Claude.
• Use this exploration phase to clarify what you actually want to achieve.

I found ‘arguing’ with Claude useful here. Explain why you are taking this approach. What alternative approaches could we take? What could go wrong? What if a user did X?

AI output is non-deterministic. Saving prompts, architecture decisions, and generated code history becomes critical for reproducibility and traceability.

3. Break Down Implementation

Once you know what you want to accomplish, have Claude break it down into implementation steps that you can understand and review. This is crucial—you need to be able to verify each step makes sense before code is written.

As with the broader planning stage, ask Claude why it’s suggesting particular approaches.

4. Small, Frequent Commits

Once you’re happy with the plan and steps, commit each step rather than waiting to commit a massive changeset. This is for your benefit so you can understand the changes.

I had cases where a seemingly small change – like adding additional flags to a user model – resulted in Claude suggesting a total model rewrite. You can spot these overreaches when working with small changesets and roll back easily. But you need to actually look at the diff.

I use git and a private repo on GitHub. Give meaningful commit messages. I didn’t use branches but might in future.

5. Test-Driven Development

I fell into the old trap of writing tests after finding bugs. Tell Claude (in your claude.md) to create tests before implementing plan stages. The tests won’t be perfect initially and will need fixing, but you’ll quickly build up a bank of regression tests.

You don’t need to implement Selenium or Playwright initially—regular unit and integration tests within your framework will do just fine.

For Django, start with model tests, then view/API tests. Ensure you have the key data and paths covered, full coverage and complex tests can come later.

Also, you may need to remind your AI assistant to run the tests from time to time!

6. Protect Your Tests

When implementing a new feature, tell Claude not to “fix” existing tests during development. Claude will happily change a failing test to match its latest hallucination if you let it! Treat test changes as a red flag, you want to understand why a change is being made before accepting it.

7. Use Your App

This sounds obvious, but actually use your application as outlined in your PRD. You’ll find many things that need tweaking, and it’s much easier to iterate during the implementation phase than to do big changes later.

Test on different browsers and devices. Have someone else try it. Make a list of bugs/features and iterate through them.

What I Wish I’d Known

The claude.md File Is Critical

Create a claude.md file at the start with:

• Your tech stack and versions
• Coding standards and preferences
• What NOT to do (this is as important as what to do)
• Testing requirements
• Common patterns you want followed

Update it as you learn what works and what doesn’t.

Know When to Step In

AI is a tool, not a replacement for engineering judgment. In particular, step in when:

• The solution seems overly complex
• Security-sensitive code is being written
• The AI keeps going in circles on a problem

Sometimes the fastest path is to write it yourself and move on.

Deploy Often

Don’t wait for perfection. I deployed to production in a couple of days with basic functionality. This:

• Forced me to set up proper CI/CD early (which deserves its own future blog post)
• Revealed deployment issues immediately
• Gave me a real environment to test in
• Provided motivation to keep iterating.

Common Pitfalls I Encountered

• Over-engineering: Claude loves to suggest complex or enterprise patterns for simple problems. AI models are rarely short on confidence – but they are not always correct. Push back. 
• Inconsistent styling: Without clear direction, Claude will use different patterns across files. Your claude.md should enforce consistency. I originally told Claude not to use Django signals. Later, I approved one legitimate use case. Claude immediately generalised that decision and started proposing signals everywhere. AI models are extremely quick to promote exceptions into rules unless you restate your constraints.
• Security assumptions: Don’t assume Claude knows your security requirements or best practices, be explicit about authentication, authorization, data validation, especially if building a multi-tenant system.
• Documentation drift: Claude-generated docstrings can become outdated quickly. Similarly, any documentation you ask Claude to write can quickly become dated.

Am I Still in the “Old Engineering Mindset”?

Am I still in the old engineering mindset, or even – shudder – waterfall development? Yes, to some extent, but I think this oversight is still necessary and proportionate.

Of course, this is all iterative. Whatever functionality you implement in a sprint may cause you to adjust future work. But I think this level of oversight over the AI assistant is appropriate.

It also helps future you. I’ve certainly discovered code I wrote 10+ years ago still running in production that I had to re-understand! The practices above will make that easier – whether it’s future me or a future AI trying to make sense of it. My colleagues at Oracle will remember my frequent code review reminders to think about how “future you” will read today’s changes.

Closing thoughts

AI assistance amplifies both good and bad practices. If you have strong software engineering fundamentals – testing, version control, incremental development, clear requirements – AI will accelerate your work. If you skip the basics, AI will help you build a mess faster.

Experienced engineers entering AI-assisted development now have an advantage: we know what good software and process looks like. The challenge is teaching the AI our standards and staying disciplined about engineering practices even when the AI can generate code faster than we can review it.

The future isn’t “AI replaces developers” – it’s “developers who effectively collaborate with AI replace those who don’t.”

On a personal note, I’m now the Quartermaster for our Scout Group so will be using this tool to solve our actual inventory and maintenance needs. Get in touch and give it a try if you think it might help your group or club!

Check out www.dalkeyscouts.ie and https://www.facebook.com/17thDalkey for more!

The most obvious difference is in the scale. 1:50000 gives you 1km in 2cm, whereas 1:25000 is double that at a kilometer for 4cm. But what does EastWest do with the extra space and is it a useful use of space? Here’s a comparison of the two maps on a mountain in Mayo, both are dated 2015.

The contour lines are a good place to start with the similarities. They are almost identical as both maps use 10m differences with a thicker line every 50 and a change of base colour every 100.The lines are thinner on the OS map so you get the same number of lines, but the steep ground to the left of the 311 spot height is more pronounced on the OS map due to the scale.

But as you would expect the EastWest map does have more detail. We have names of specific points, locations of ‘intermittent streams’, cliffs explicitly marked, marshes and upland grazing indicated. The OS map does include spot heights but they aren’t really that useful. The spelling and lanuguage on the maps also differ; this may be down to the gaealtacht dialect or one using more local names for features; I’m not sure but I suspect EastWest have done more local research into placenames.

Taking a look at an town square kilometer we see similar differences:

The EastWest Map can indicate smaller roads better and includes field boundaries along with more detail in general.

Which is better? I’ve always found the 1:50000 adequate for navigation, even on courses where I have to navigate by map and compass. Though the additional scale and information in the 1:25000 is nice. The scale wouldn’t be enough to push me either way.

The next point to consider is coverage. The EastWest map is two sided with a map on each side. In the case of the Nephin maps that gives one side from mulranny up to ballycroy, and the other face from Ballycroy up to Bangor Erris with a decent overlap.

The OS maps on the other hand are divided up strictly along latitude and longitude and to cover the same area you need 4 maps! In some areas this works ok, you get most of Wicklow in Sheet 56 for example, but doesnt for the Wild Nephin National Park. The OS do cover more useful areas in their 1:25000 series but I don’t see one of those available for this national park yet. So which map will suit best depends on where you want to go; in the case of Wicklow you’ll need to get a couple of East west maps…

Lastly there’s the waterproofing. The OS maps come in either paper or fully laminated. The fully waterproof versions have never failed me, and they have been stuffed in bags, pockets, and been out in all weather. The East West maps however are printed on plastic and while this does give them some waterproofing they do not survive the abuse of being stuffed into pockets and bags. The EW web page does mention ‘fully encapsulated’ maps for some areas.

So when choosing a map which should you buy? It depends… Firstl figure out the are that you need a map or maps for obviously, then:

1. If you will be hiking or wild camping get a fully waterproof map. It’ll last longer and take more abuse.
2. If you can get fully waterproof maps from both then see how many maps you need. At up to €25 each you don’t want to have to buy too many of them!
3. Decide if the scale matters to you. This is related to point 2, but to me is an additional bonus rather than a requirement.

For me then the next time I need a map I’d have no problem buying the fully waterproof maps from either EastWest mapping or the Ordnance Survey. What I buy will come down to the area covered. For Wicklow I think I’ll stick to the OS sheet 56 laminated edition, but for an extended trip in the Nephin Wilderness I’d get a fully waterproof EastWest mapping map if they have one available.

1. Go to Kerry International Dark Sky Reserve
2. Wander outside at night and take a photo with your camera.

This is a 30second exposure with my regular camera resting on a kitchen towel at the back door of the holiday home.

Sure, you can spend lots on filters and cameras and tracking mounts, and stack images and use noise reduciton in software etc. etc. But you really can’t beat a really dark sky.

And don’t believe that it’s all about cold dark winter nights either! This was at the end of july and the temperature outside was about 15 degrees!

(Fortuitous satellite btw, not a meteor!)

Slieve Car along with Nephin Beg (activated for the first time only a few weeks ago by Shane G6WBS) are the two main summits in the Wild Nephin national park, an area that now comprises 11,000 hectares of blanket bog. The summits rise sharply from the bog and tower over 500m above the rest of the landscape.

Since the establishment of Ballycroy National Park in 1998 a lot of work has gone into making this remote landscape more accessible for visitors while still conserving it’s pristine dark skies, active blanket bog systems, and right flora and fauna. The area now has several marked trails, shelters and dark sky sites as part of the ‘Mayo Dark Sky Park’.

Yet Slieve Carr still manages to retain it’s remoteness. From the west a bóithrin off the N59 will give you access to the Bangor trail which you can follow to Tomashiffin Mountain and then approach Carr from the South. This is a 14km trip one way and was the route I was planning on taking a couple of years ago and doing the route over a couple of days, wild camping in the National Park. Covid ended that plan but I had some time on a family trip to try and make a quick day trip to the summit. A 28k round trip through a bog was too far, and a quick look at the map shows the North approach is mired by wet bogs with no apparent paths through them. If I was going to attempt this I would need to cheat as much as I could on the Eastern approach.

The east of the range is mainly covered in conifer forest, which does thankfully have some tracks running through it connecting  the North East of the park, Altnabrocky bothy and Brogan Carroll Bothy with the road to Newport at Letterkeen. A quick check with some local guides confirmed that biking along these was possible and would take some time off my journey.

So on Wednesday morning I got a lift to the park entrance near the farm at Altnabrocky Lodge. At the gate I was met with the expected covid warnings, along with ‘do not enter’ construction notices. I took these warning to be for the farm rather than the forest tracks, and ignored them, hopping on my bike and heading the 7km for the Altnabrocky shelter. At the shelter there is a steep track up another 1.5km or so to ‘the steps’ which gives you access from the forest to the mountain. From here your first task is to climb the knoll in front of you; it’s only 100m ascent but the lush grass, heather and moss makes it difficult. Walkers from other parts of the country may be familiar with seeing well-worn tracks into the mountains with obvious paths – there are none here, you find your own way. From that knoll you have a choice, you can head west, and south of the lake to ascend Corr na Binne, or take the route I choose to head northwest and take the spur north of Coire and nGarru lake. On paper this looks the less steep option, but there were times where I had to put the hiking poles away and climb up on all fours such was the steepness. The climb is worthwhile however as the views across the lakes to Nephin Beg are spectacular. After that the ascent to the main ridge and North to the summit felt easy! The summit itself is rocky with a large cairn, said to be the burial mound of Daithí a 5^th century King of Connaught. The view from the summit is commanding. With the exception of Nehphin in the distance, Carr dominates the landscape and you feel yourself towering above the blanket bog below with the mountains of Achill island visible in the Atlantic and the summits of Donegal in the North. From the steps I’d travelled about 3.5k with about 500m elevation.

But it was time to get the radio out and I quickly set up the arrow antenna and connected it to my FT-65 handheld. Almost immediately I was chatting to Dermot EI7IX, with the best 2m DX being with Patsy EI9CUB 170km away in Cavan. Next up was Dave EI5IMB in Bundoran, and as I was starting to set up for HF I heard Padraic EI9JA in nearby Westport to get the 4 required QSO’s for the activation. For HF I used my trusty FT817 and linked dipole on 40m and 20m SSB. The bands seemed quiet but I got reports of strong QRM on both bands from European stations. 40m yielded 7 QSOs with the short skip getting mainly UK stations. 20m was better for DX getting over 1600km to stations in Sweden, but I didn’t quite manage to finish my QSO with a Bulgarian station which would have added another 1000km to the DX range.

However I did manage a summit-to-summit contact with Daniel, HB9IIO, who was on the summit of Mont Pèlerin near Lusanne in Switzerland.

At the sumit I met Ged from Terra Firma Ireland who was leading a small group up to Slieve Carr also. Ged and Georgia from Terra Firma Ireland had given me some really useful advice when planning this adventure so it was good to see him again on the summit.

I spent over an hour on the summit, but after eating the bligatory sandwiches and having a couple of mugs of tea it was time to descend. The uphill work was done, but the longest part of the journey lay ahead.

I followed the same route back to ‘the steps’. The steep ascents on the spur that caused me problems on the way up caused my knees plenty of problems on the way down too. By the time I reached Coire na nGaru I was out of water so made a detour to the lake to relax and filter some more to keep me going. Back at ‘the steps’ I was sorry that I’d abandoned the bike in a ditch near the shelter, so another 1.6km walk beckoned. But it was mostly downhill so it wasn’t long before I was back at my bike and on my way. This time, on Ged’s advice, I headed south towards the Leterkeen Bothy, and most importantly it’s car park where I could be picked up. It was a long tiring cycle, but as Ged had promised it was mostly downhill. That 10k cycle added another hour and I was shattered when I got to the bothy.

All in all it was a 26km route. Far longer than I’m used to for activations but despite the soreness in my legs a couple of days later, it was worth it and I’m glad I got to mark Slieve Carr off the list of unactivated summits!

If you are thinking of tackling Slieve Carr my route is probably the quickest and shortest route. But do check with local guides, and for this I can thoroughly recommend Terra Firma Ireland, who can give you up to date local advice on access as well as arrange transport and bespoke guided hikes and adventures to meet your needs.