I’m trying to get a basic setup of two nodes where one has a linux machine on the LAN running a mumble server and the other has an android phone on the LAN with a mumble client. (Or really just trying to get a ping through)
So far I have not been able to get any device on one LAN to talk to any other device on the other LAN.
Iperfspeed between the two Nodes is good.
I am able to hit both nodes IPs with ping from any device on either LAN. But when I traceroute from one LAN to the next the packets stop at the second node.
Settings are default excluding the addition of iperfspeed, enabling the AP, and disabling WAN access.
I also don’t seem to be able to hit anything at all via their .local.mesh address but DNS can be a future problem.
My understanding from the documentation was that direct LAN mode would of allowed for open access from LAN to LAN.
I've tried various android phones and laptops on both networks, pinging and tracerouting all the way.
During troubleshooting I also added the linux machine to the DHCP Address Reservations, it now shows up on both Node mesh status screens as available (but is still only accessible from the LAN it is on). I also tried changing the Mesh RF settings to be the same IP up to the last number (I've since reset to default).
Any advice on this issue would be appreciated.
- Brandon, KI5FBW
You are here
Getting Started With Two Mikrotik hAP AC Lite Nodes
Wed, 06/19/2019 - 15:44
#1
Getting Started With Two Mikrotik hAP AC Lite Nodes
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
"but is still only accessible from the LAN it is on". If I understand correctly, two devices plugged into the LAN of the same node can talk with one another (ruling out Firewall settings on the linux LAN device)? Sometimes linux devices don't respond, because their firewall is locked down.
Joe AE6XE
I went ahead and added some accept all connections rules on the mumble port to make sure that wouldn't cause issues.
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:64738
ACCEPT tcp -- anywhere anywhere tcp dpt:64738 flags:FIN,SYN,RST,ACK/SYN
- Brandon, KI5FBW
Attached
Yes, I tried to rule out as many issues as I could. I started with both devices on my standard home LAN. Then moved them to a single node’s LAN. Everything worked as expected both times.
- Brandon, KI5FBW
Joe AE6XE
Do we expect traffic to only be routed if there is a working DNS or with reserved DHCP? I can't even connect to ki5fbw-mobileX.local.mesh from devices on the node's LAN (though localnode.local.mesh works). I have to use their IPs.
- Brandon, KI5FBW
Can you do a "nslookup beaglebone" on all nodes and devices to resolve the IP address? Does this work on all devices? (BTW, I'm sure you already known, risk of hostname conflict on larger networks, recommend doing "<callsign>-beaglebone" format.)
There is a "tcpdump" package that can be installed on the mesh nodes from the Administration screen -- connect to internet on hap ac lite port 1 for the package to be downloaded. To monitor traffic on its LAN (see what is coming in or going out): "tcpdump -i br-lan" Check to see that your traffic is going in the LAN of one node and coming out the LAN of the other node -- is routing correctly? To see the traffic on the 2GHz link, "tcpdump -i wlan1-1". Did it come across the link? This will help isolate the exact failure point -- on mesh nodes or at end devices.
Joe AE6XE
Ok, I'm glad I'm not just totally missing some obvious problem.
Apologies for the wild post, debugging all evening and just trying to record information
tcpdump running on both interfaces on both nodes.
everyone seems to be able to sucessfully nslookup, except a macbook I tried which timed out and said it couldn't find a server (despite dns looking correct in it's interface config).
But then on the android, I turn around and try to ping beaglebone and it says it can resolve the ip and it doesn't even try to hit the node.
hmm, seeing stuff online suggesting android has a weird fallback to google dns if it can't get IPv6-only dns to work. Can IPv6 be disabled? forcing a fallback perhaps.
OSLR humming along just fine it seems on the wlan.
From mobile1 wlan:
From mobile2 wlan:
when trying to do traceroute on the beaglebone to android. The android does not respond. Node2 sees the request.
tried pinging on the beaglebone to android. The android does not respond. Node2 sees the request.
when trying to do traceroute on mobile2 to beaglebone
seems to work
when trying to ping on mobile2 to beaglebone
I had to reset mobile1 to get it to work
when trying ping on android to beaglebone (can't use beaglebone, ip used)
is the only thing that comes up, nothing over wlan or the other node.
android traceroute doesn't showup at all
It seems like maybe the android doesn't want to use the node for DNS outside of nslookup.
android seems to be causing most of the problems.
switching android to the same lan
pinging beaglebone now works without issue
mumble of course still works
so still no luck on the basic mumble setup (I'm noticing android does not even try to find the servers though, I see no traffic go out when I try and force a connection).
overall these are good tools for me to keep troubleshooting with, I'll have to work on it more tomorrow. Maybe try to use something else instead of android, if I can get the macbook to do anything usefull or just get my windows PC involved.
- Brandon, KI5FBW
Joe AE6XE
Yes I turned off cell data.
I'm about to start working on a normal laptop. Though my macbook initiall was causing DNS issues as well.
If I ping the beaglebone (with the dns name) from the windows PC the packet makes it's way over to the beaglebone but then the beaglebone asks this
22:59:19.035731 ARP, Request who-has 10.180.129.114 tell beaglebone, length 50
And never gets a response.
Going in the other direction the beaglebone asks the same thing but never gets a response.
This is ifconfig
eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 10.179.170.75 netmask 255.255.255.248 broadcast 10.179.170.79
inet6 fe80::564a:16ff:fef4:48f6 prefixlen 64 scopeid 0x20<link>
ether 54:4a:16:f4:48:f6 txqueuelen 1000 (Ethernet)
RX packets 192 bytes 22124 (21.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 696 bytes 57233 (55.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 55
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 350 bytes 32896 (32.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 350 bytes 32896 (32.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.7.2 netmask 255.255.255.252 broadcast 192.168.7.3
inet6 fe80::564a:16ff:fef4:48f8 prefixlen 64 scopeid 0x20<link>
ether 54:4a:16:f4:48:f8 txqueuelen 1000 (Ethernet)
RX packets 17272 bytes 1502607 (1.4 MiB)
RX errors 0 dropped 10 overruns 0 frame 0
TX packets 1388 bytes 290544 (283.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.6.2 netmask 255.255.255.252 broadcast 192.168.6.3
ether 54:4a:16:f4:48:fb txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
getting this on the localnode
04:28:38.131405 ARP, Request who-has KI5FBW-Mobile2.local.mesh tell beaglebone.local.mesh, length 28
with no response from the node
I can't even ping the local node using dns
ping gives this on localnode and there is no response
05:29:29.587399 ARP, Request who-has KI5FBW-Mobile1.local.mesh tell beaglebone.local.mesh, length 28
this happens during a nslookup
05:29:58.086822 IP beaglebone.local.mesh.46059 > localnode.local.mesh.domain: 21563+ A? ki5fbw-mobile1.local.mesh. (43)
and it gets the ip correctly
I attached my settings screen. That is the only configuration I have done for either.
That was the problem. I guess Android and Mac start to behave off-nomially when there is no default route. Even if DHCP sets the DNS address.
I guess I read that configuration item as an easy way to prevent any potential legal issues with sending encrypted data over the mesh. Even when I'm hooked into WAN (which I generally am using for configuration access)
Thanks to both of you for the assistance.
- Brandon, KI5FBW