Hello Greg
With the following routes I can ping fine from the mobile phone, please see
below. But when I try to start a SSH session, it never success.
netbsd-raspaZeroW# route -n show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 44.27.132.76 UGS - - - wg0
44.27.132.76 wg0 UHl - - - wg0
44.27.132.76/32 44.27.132.76 U - - - wg0
44.27.227.1 192.168.1.1 UGHS - - - bwfm0
127/8 127.0.0.1 UGRS - - 33176 lo0
127.0.0.1 lo0 UHl - - 33176 lo0
192.168.1/24 link#2 UC - - - bwfm0
192.168.1.230 link#2 UHl - - - lo0
192.168.1.203 d8:3a:dd:99:78:45 UHL - - - bwfm0
192.168.1.1 60:8d:26:32:34:23 UHL - - - bwfm0
192.168.1.51 20:28:bc:eb:8d:ae UHL - - - bwfm0
23:19:10.181755 IP 90.167.219.193 > 44.27.132.76: ICMP echo request, id 25199,
seq 1, length 64
23:19:10.181941 IP 44.27.132.76 > 90.167.219.193: ICMP echo reply, id 25199,
seq 1, length 64
23:19:13.699283 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [S], seq 3379571502, win 65535, options [mss 1410,sackOK,TS val 845496656 ecr
0,nop,wscale 10], length 0
23:19:13.699422 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [S.], seq 1838093467, ack 3379571503, win 32768, options [mss 1460,nop,wscale
3,sackOK,TS val 1 ecr 845496656], length 0
23:19:13.869650 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [.], ack 1,
win 86, options [nop,nop,TS val 845496833 ecr 1], length 0
23:19:13.870218 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [P.], seq
1:23, ack 1, win 86, options [nop,nop,TS val 845496837 ecr 1], length 22
23:19:14.062777 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [.], ack 23,
win 4194, options [nop,nop,TS val 2 ecr 845496837], length 0
23:19:14.142755 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [P.], seq
1:64, ack 23, win 4194, options [nop,nop,TS val 2 ecr 845496837], length 63
23:19:14.309616 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [.], ack 64,
win 86, options [nop,nop,TS val 845497277 ecr 2], length 0
23:19:14.309778 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [P.], seq 64:1184, ack 23, win 4197, options [nop,nop,TS val 2 ecr 845497277], length
1120
23:19:14.317253 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [P.], seq
1421:1591, ack 64, win 86, options [nop,nop,TS val 845497281 ecr 2], length 170
23:19:14.317375 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [.], ack 23, win 4197, options [nop,nop,TS val 2 ecr 845497277,nop,nop,sack 1
{1421:1591}], length 0
23:19:14.522748 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [.], ack 1184,
win 89, options [nop,nop,TS val 845497496 ecr 2], length 0
^C
32 packets captured
32 packets received by filter
0 packets dropped by kernel
netbsd-raspaZeroW#
ssh server on the RPi negociates but it never ends. AI suggests that UDP packets inside the tunnel are corrupted because (perhaps) a flaky bwfm
driver, but how knows, many times it says wrong things...
(Also the interface needs to be "resurrected" as before, but it is another
story)
We are far better than before but I does not work yet.
Regards.
Ramiro.
El 30/1/26 a las 16:25, Greg Troxel escribió:
Ramiro Aceves <[email protected]> writes:
El 28/1/26 a las 1:19, Greg Troxel escribió:
Ramiro Aceves <[email protected]> writes:
I am using this two commands to monitor interfaces in the RPi ZeroW:
tcpdump icmp -i wg0 ---> to monitor the wireguard interface
tcpdump icmp -i bwfm0 ---> to monitor the WIFI link to the home router.
Don't use filters, or filter out stuff you dno't want to see. The
wireguard packets surely are some UDP port or similar and encrypted, so
icmp will not match.
Thanks for answering. The problem is that because of by my lack of
understanding about networking I do not know what to monitor ;-) I
knew that ping uses ICMP packets so I wanted to see them alone and
discarded everything. I saw that bwmf0 tcmpdump out put was with high
traffic and was lost watching so many lines of (for me) cryptic
messages ;-) >
That's why I suggested, or meant to suggest, writing to a file, so that
you can go over it later and filter out what you know doesn't matter.
Generally when debugging it's important to avoid excluding things that
you don't expect that might matter.
raspaZeroW# ping -c 1 44.27.132.76
you are pinging your own address? That should stay local.
Yes, I am pinging my 44 net assigned address from the RPiZero. Should
it correspond to:?
44.27.132.76 wg0 UHl - - - wg0
44.27.132.76/32 44.27.132.76 U - - - wg0
I think it should stay local. For example, if I ping my (inner) side of
a gif tunnel, the RTT is 340 us, clearly local.
But I haven't set up wireguard, and I haven't read the driver.
I believe that pings from outside reach the RPI through the tunnel in
wg0 but the ICMP reply try to go via the default route 192.168.1.1. I
do not know, perhaps I am saying silly things.
I think you are correct, and the problem is that your tunnel setup does
not really make sense.
root@freebsd-nuc8i7:/home/ramiro # netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
0.0.0.0/1 link#3 US wg0
default 192.168.1.1 UGS em0
44.27.132.76 link#2 UH lo0
44.27.227.1 192.168.1.1 UGHS em0
127.0.0.1 link#2 UH lo0
128.0.0.0/1 link#3 US wg0
192.168.1.0/24 link#1 U em0
192.168.1.200 link#2 UHS lo0
Here, in addition to what you have in NetBSD, there are a pair of
half-default routes that route all traffic into the tunnel, or at least
that's what I think is going on. Often when doing "VPN" what's what
people want.
The intended usage for this setup would be setting up a lighttpd WEB
server in the RPiZeroW that would be accessible from the hole
internet.
So you really do want all outgoing packets -- except for the wrapped
packets -- to go via wg.
The next question is what prefix is supposed to be reachable via wg?
I do not understand, sorry.
I meant whether the tunnel is supposed to let you connect to the entire
internet, or just the (remaining part of) net 44.
Back when I used net 44, it was over-the-air only, and there were not
gateways to the internet, on purpose, for rules compliance. Now it
seems to be normal internet for ham community.
