How does GRE interface route packet to remote endpoint

I have the following topology which I configured to run a GRE tunnel between my Desktop and the wireless router.

On the PC:

ip link add l2gre0 type gretap remote 192.168.0.103 local 192.168.0.10

On the Router:

ip link add l2gre0 type gretap remote 192.168.0.10 local 192.168.0.103

My client obtained an IP address of 10.10.10.102 from the DHCP server on PC. I try to ping the gateway IP 10.10.10.1 from my client. The ping succeeds.

What I want to understand is how the software routes this Ping packet across from lan0 to l2gre0 (both under bridge br0) and then crossing over to eth0 over the wire to enp3s0 (on the PC).

I took packet captures on lan0 and I could see that capture showed an ethernet frame. Then I took packet capture on l2gre0 (on Wireless router). I could see the same frame as seen in lan0. which means br0 repeated the frame from lan0 to l2gre0.

If I take packet capture on eth0 interface, GRE encapsulation has already happened, which means between l2gre0 and eth0 the software stack attached to l2gre0 might have encapsulated the frame. But l2gre0 has only the idea about remote 192.168.0.10 and local 192.168.0.103 endpoints, so how did it decide that this packet (dest IP: 10.10.10.1) need to be encapsulated ?

Routes on the Wireless router:

/ # ip r
default via 192.168.0.10 dev eth0
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.32.107
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.103

But l2gre0 has only the idea about remote 192.168.0.10 and local 192.168.0.103 endpoints, so how did it decide that this packet (dest IP: 10.10.10.1) need to be encapsulated ?

It didn't. The endpoints you're talking about are tunnel source address (192.168.0.103) and tunnel destination address (192.168.0.10). These are addresses that are used by kernel to send and receive encapsulated payload, they do not participate in kernel routing as such.

What exactly happens here is that your kernel IP stack routes packets destined to 10.10.10.1 out of your GRE tunnel just because it is a directly connected IP interface l2gre0 with this address assigned as it's remote peer tunnel remote address. Likewise your l2gre0 interface has tunnel local address, these are addresses assigned to the tunnel interface itself, think of them as "names for the local and remote side inside the tunnel", you can get them with ip a l on most modern distributions.

Whatever gets routed into the GRE tunnel by the kernel gets encapsulated and sent to the tunnel destination address, the interface doesn't check what payload it was given (just like any other interface doesn't) and send that out for the remote side to deal with it.