Closed jwilbur-godaddy closed 2 years ago
Here are logs from my coworker using Mac OS:
2022-05-23T16:57:48.047256Z INFO start-command: app:
version: "0.6.4"
sha: "8b282b2f1d52abb127ccfb7eca1d04f4344af4df"
built: "Wed, 11 May 2022 23:31:41 +0000"
profile: "release"
os: "macos"
family: "unix"
arch: "x86_64"
endian: "little"
cores: 16
pointer-width: "64"
debug: false
in codespace: "false"
2022-05-23T16:57:48.047393Z INFO start-command: start command:
--dns: "true"
--gui: "true"
--repo: "github/gh-net"
--trace: "info"
--location: "local"
--telemetry: "true"
2022-05-23T16:57:49.958419Z INFO local: run_local is_dns: "true"
2022-05-23T16:57:49.958472Z INFO local: codespace-name: "dnguyen1-godaddy-gdcorp-im-account-billing-pjpppw4pwcrv9g"
2022-05-23T16:57:49.961431Z INFO client: suitable network interfaces: ["lo0", "en0", "utun2"]
2022-05-23T16:57:49.961661Z INFO client: starting 3 network interface jobs
2022-05-23T16:57:49.961810Z INFO network: copy queue to stream job started
2022-05-23T16:57:49.962367Z INFO stream: connected "lo0"
2022-05-23T16:57:49.962464Z INFO network: connected "en0"
2022-05-23T16:57:49.962456Z INFO network: connected "lo0"
2022-05-23T16:57:49.962549Z INFO stream: connected "en0"
2022-05-23T16:57:49.962756Z INFO network: connected "utun2"
2022-05-23T16:57:49.962765Z INFO stream: connected "utun2"
2022-05-23T16:57:52.966516Z INFO stream: copy stream to queue job started
2022-05-23T16:58:53.295229Z ERROR stream: error: [Os { code: 65, kind: HostUnreachable, message: "No route to host" }]
2022-05-23T16:58:55.314072Z WARN stream: Cannot send IpPacket to the interface queue for NetworkInterface { name: "en0", description: "", index: 6, mac: Some(3c:22:fb:1a:1f:d1), ips: [V4(Ipv4Network { addr: 10.0.0.129, prefix: 24 })], flags: 34915 }, Closed(FromStreamPacket { packet:
@jwilbur-godaddy I never tested it under WSL but definitely want to make it work. Mind starting the extension with trace
tracing level [sudo] gh net start --trace trace
, repro the issue and send me the logs? The logs might contain personal data, so please DM them over to legomushroom@github.com if you have concerns attaching the logs here. Thanks! π
@jwilbur-godaddy just a note:
NAT
rules are created dynamically when a request is routed. Hence the list will be empty until you will try to make a request, e.g. wget -d hrweb -4
or similar.wget -d hrweb
which quickly downloads the page and closes underlying TCP connection, you might not notice the NAT list change at all(gui has a rendering delay of 1s for perf reasons).@jwilbur-godaddy I have a potential fix for this on the legomushroom/gh-net repo, mind trying it out?
gh extension remove net
gh extension install legomushroom/gh-net
sudo gh net -V # should print `gh net 0.6.7`
Then use the extension as before, but please add the --trace trace
argument so it would have additional debugging details in case it still has some issues.
Thanks! π
The fixed mentioned is released in 0.8.3 π Please give it a try βΊοΈ
@jwilbur-godaddy did 0.8.3 fix your issues regarding using gh net
in WSL2? I have a similar issue in WSL2 where my DNS seems to be working, but my NAT stays empty.
I cannot use wget / ping from my Codespace to a local address, thus it seems it is not just the NAT panel which doesn't render, but the whole NAT functionality does not seem to be working.
Any debugging / logs I can provide for this? @legomushroom
I never actually confirmed that it worked. When I got back from paternity leave, I tried again, but GitHub codespaces itself wasn't working. I couldn't connect to them over SSH. I don't think it was the fault of this extension. What I can say is that it seems like I got further along. It seems like this issue would be fixed for me if I could get Codespaces to work in the first place. Thank you!
@legomushroom I'm trying to connect from WSL and am also getting nothing listed in the left NAT panel
2023-10-15T19:02:24.356084Z INFO start-command: app:
version: "0.12.4"
sha: "0514431be26c0fa4a541a134be39178844d19ecc"
built: "Thu, 15 Sep 2022 21:03:46 +0000"
profile: "release"
os: "linux"
family: "unix"
arch: "x86_64"
endian: "little"
cores: 16
pointer-width: "64"
debug: false
in-codespace: "false"
2023-10-15T19:02:24.356208Z INFO start-command: start command:
--dns: "true"
--gui: "true"
--repo: "github/gh-net"
--trace: "info"
--trace-dest: None
--location: "local"
--telemetry: "true"
--codespace: None
2023-10-15T19:02:26.136263Z INFO local: codespace-name: "xxxxxxxx"
2023-10-15T19:02:26.139405Z INFO client: target network interfaces:
lo:
name: "lo"
description: ""
ips: [V4(Ipv4Network { addr: 127.0.0.1, prefix: 8 }), V6(Ipv6Network { addr: ::1, prefix: 128 })]
mac: Some(00:00:00:00:00:00)
up: true
loopback: true
point-to-point: false
default gateway: false
eth0:
name: "eth0"
description: ""
ips: [V4(Ipv4Network { addr: xxxxxx, prefix: 20 }), V6(Ipv6Network { addr: xxxxxx, prefix: 64 })]
mac: Some(00:xxxxxx)
up: true
loopback: false
point-to-point: false
default gateway: true
2023-10-15T19:02:26.139611Z INFO client: starting 2 network interface jobs
2023-10-15T19:02:26.139994Z INFO stream: connected "lo"
2023-10-15T19:02:26.140310Z INFO stream: connected "eth0"
2023-10-15T19:02:26.140793Z INFO network: copy queue to stream job started
2023-10-15T19:02:26.140811Z INFO stream: copy stream to queue job started
2023-10-15T19:02:26.183524Z INFO network: connected ""
2023-10-15T19:02:26.184946Z INFO network: connected ""
...
2023-10-15T19:02:35.382335Z INFO resovle-job: no records, adding NXDOMAIN responses
Describe the bug
In the TUI, it appears that
gh net
manages to resolve DNS names, but it fails to make any of them routable. I see no NAT rules appear in my WSL 2 environment. My team also tried this on Mac OS and got NAT rules to appear, but still, no traffic was routable. I stoppedsshd
from codespaces and ransudo /usr/sbin/sshd -dD
to get debugging logs, which can be seen below:The logs seemed to hang on the line starting with "Starting session."
Here are the logs on the client side:
Reproduce steps
gh net start
.Expected behavior
I want to be able to reach a host on my local network from Codespaces.
Desktop (please complete the following information):
Logs Please attach logs to created issue. The best way for getting logs is to use VSCode client: connect to a Codespace and run
> Codespaces: Export Logs
command in command palette. Please note a logs file name shown in the UI. logs.zip