3

Using WSL2, and a raw sockets implementation, I cannot seem to send any packets. I cannot include all the code as it is a big driver, but I will try include the relevant parts below. I don't think there is anything wrong with the socket code, but maybe my socket configuration or something.

In tcpdump I can see my packets being sent, but they do not show in up Wireshark on the vEthernet(WSL) interface, or the PCs Ethernet interface that is the only internet connection.

The socket is created with:

    int sock = socket(AF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL));

The send function uses the code below. sa.sll_ifindex is set to the index of the eth0 AF_PACKET network interface (6 in my case). sa.sll_addr is set to the MAC address of the same interface. The packet data is constructed by lwIP IP stack. sendto always succeeds, returning the full number of bytes sent.

    memset(&sa, 0, sizeof(sa));
    sa.sll_family = AF_PACKET;
    sa.sll_halen = netif->hwaddr_len;
    for (unsigned i = 0; i < netif->hwaddr_len; i++)
    {
        sa.sll_addr[i] = netif->hwaddr[i];
    }
    sa.sll_ifindex = ctx->HostInterfaceIndex;
    sa.sll_protocol = htons(ETH_P_IP);
    ssize_t sent = sendto(ctx->RawSockHandle, buf, p->tot_len, 0, (struct sockaddr *)&sa, sizeof(sa));

When application code is sending a DNS query, I see the following in netcap:

14:01:01.101480 IP 172.17.44.146.10924 > dns.google.domain: 55249+ A? test.site.io. (35)
14:01:01.452154 IP 172.17.44.146.10924 > dns.google.domain: 55249+ A? test.site.io. (35)
14:01:02.452560 IP 172.17.44.146.10924 > dns.google.domain: 55249+ A? test.site.io. (35)
14:01:04.452146 IP 172.17.44.146.10924 > dns.google.domain: 55249+ A? test.site.io. (35)
14:01:07.452520 IP 172.17.44.146.10924 > one.one.one.one.domain: 55249+ A? test.site.io. (35)
14:01:08.452721 IP 172.17.44.146.10924 > one.one.one.one.domain: 55249+ A? test.site.io. (35)
14:01:09.452102 IP 172.17.44.146.10924 > one.one.one.one.domain: 55249+ A? test.site.io. (35)
14:01:11.452584 IP 172.17.44.146.10924 > one.one.one.one.domain: 55249+ A? test.site.io. (35)

So, it appears my packets are making it into the WSL eth0 interface, but not making it any further.

Any suggestions on what I can do to diagnose this. I can paste additional code if needed, just ask. I tried to keep it simple.

Improve this question
4
  • I think I may have just spotted my problem. The destination address I am sending to is that of the eth0 interface. I think it is meant to be the actual destination MAC address of the remote. But, how would I know the remote address on WSL? Commented Feb 8, 2022 at 1:13
  • Well, how would you do it on a native linux install? Did you try (e.g.) getaddrinfo, etc. to get the IP (not MAC) address of google.com (e.g. 142.251.35.164)? You may want to start with AF_INET first, to verify things and then graduate to AF_PACKET when the simpler/regular connect is working. Commented Feb 8, 2022 at 1:55
  • 1
    "But, how would I know the remote address on WSL". You can't know the remote MAC. That's not how packets are routed. You need to get the MAC of the next hop. Which is usually a router. That information is obtained from ARP (Address Resolution Protocol). Commented Feb 8, 2022 at 2:03
  • Thanks for your feedback. There appear to be methods using netlink sockets that allow finding the MAC address of the default route but I haven't got that far yet. stackoverflow.com/questions/70610396/… For now I am trying to go down another layer and read the Ethernet packets and have lwIP do ARP. But I think that would still be no good as doesn't DHCP usually provide the IP address of the default gateway? Commented Feb 8, 2022 at 2:32

1 Answer 1

Reset to default
1

Following this how-to I connected the virtual switch to the external, real, LAN switch and then raw Ethernet packets sent to the LAN's MAC from WSL2 Linux side appear in Windows side Wireshark.

Virtual Switch configuration form:

Virtual Switch configuration form

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

I had the same issue, but this did not work for me. Packets show in WSL2 tcpdump, but do not leave WSL for Windows or the physical adapter. Later WSL has the NetworkMode=mirrorred option which I think means you dont need to do this. But that still does not allow packets out.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.