Setting up a 802.11s mesh network for mobile devices to communicate with a wired server
I'm in the process of developing an android app that maintains a device's connectivity to a linux-based WiFi mesh network, and periodically sends status information (GPS, battery life, etc.) to a known server somewhere on the mesh. I'm pretty new to *nix in general so this project has been a massive learning curve, and I think when it comes to networking I'm in pretty far over my head. I'm running into some problems getting update packets traffic to consistently find their way back to the server, and hoping someone will be able to point me in the right direction.
Each one of the mesh nodes is a small linux computer with three network interfaces:
ap0
The WiFi access-point interface managed by hostapd
. IP address is set to 192.168.0.1
, with connected mobile phones being auto-assigned an IP on the same subnet via dhcpd
.
mesh0
The WiFi 802.11s mesh interface connecting the mesh nodes together. Each one is a member of the 10.0.0.0
network.
eth0
Standard ethernet port, assigned IP 192.168.1.101
. Only one of the mesh nodes will use this interface, which will connect to a network containing the server machine (192.168.1.1
).
Just for clarity, here's a mock-up of the network's structure:
So far all I've been able to achieve is getting the nodes to ping each other. The wireless devices can't see outside of their own network (the access point subnet), nor is anything other than the ethernet-connected node able to ping the server. The script setting all this up looks like this (largely cobbled together from google searches):
ifconfig wlan0 down
iw dev wlan0 del
iw phy phy0 interface add ap0 type managed
ip link set dev ap0 address 60:60:60:60:60:01 #this is different for each unit
ifconfig mesh0 up
ifconfig mesh0 10.0.0.1
ifconfig ap0 192.168.0.1 up
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o mesh0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i mesh0 -o eth0 -j ACCEPT
networking wifi iptables routing ethernet
add a comment |
I'm in the process of developing an android app that maintains a device's connectivity to a linux-based WiFi mesh network, and periodically sends status information (GPS, battery life, etc.) to a known server somewhere on the mesh. I'm pretty new to *nix in general so this project has been a massive learning curve, and I think when it comes to networking I'm in pretty far over my head. I'm running into some problems getting update packets traffic to consistently find their way back to the server, and hoping someone will be able to point me in the right direction.
Each one of the mesh nodes is a small linux computer with three network interfaces:
ap0
The WiFi access-point interface managed by hostapd
. IP address is set to 192.168.0.1
, with connected mobile phones being auto-assigned an IP on the same subnet via dhcpd
.
mesh0
The WiFi 802.11s mesh interface connecting the mesh nodes together. Each one is a member of the 10.0.0.0
network.
eth0
Standard ethernet port, assigned IP 192.168.1.101
. Only one of the mesh nodes will use this interface, which will connect to a network containing the server machine (192.168.1.1
).
Just for clarity, here's a mock-up of the network's structure:
So far all I've been able to achieve is getting the nodes to ping each other. The wireless devices can't see outside of their own network (the access point subnet), nor is anything other than the ethernet-connected node able to ping the server. The script setting all this up looks like this (largely cobbled together from google searches):
ifconfig wlan0 down
iw dev wlan0 del
iw phy phy0 interface add ap0 type managed
ip link set dev ap0 address 60:60:60:60:60:01 #this is different for each unit
ifconfig mesh0 up
ifconfig mesh0 10.0.0.1
ifconfig ap0 192.168.0.1 up
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o mesh0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i mesh0 -o eth0 -j ACCEPT
networking wifi iptables routing ethernet
add a comment |
I'm in the process of developing an android app that maintains a device's connectivity to a linux-based WiFi mesh network, and periodically sends status information (GPS, battery life, etc.) to a known server somewhere on the mesh. I'm pretty new to *nix in general so this project has been a massive learning curve, and I think when it comes to networking I'm in pretty far over my head. I'm running into some problems getting update packets traffic to consistently find their way back to the server, and hoping someone will be able to point me in the right direction.
Each one of the mesh nodes is a small linux computer with three network interfaces:
ap0
The WiFi access-point interface managed by hostapd
. IP address is set to 192.168.0.1
, with connected mobile phones being auto-assigned an IP on the same subnet via dhcpd
.
mesh0
The WiFi 802.11s mesh interface connecting the mesh nodes together. Each one is a member of the 10.0.0.0
network.
eth0
Standard ethernet port, assigned IP 192.168.1.101
. Only one of the mesh nodes will use this interface, which will connect to a network containing the server machine (192.168.1.1
).
Just for clarity, here's a mock-up of the network's structure:
So far all I've been able to achieve is getting the nodes to ping each other. The wireless devices can't see outside of their own network (the access point subnet), nor is anything other than the ethernet-connected node able to ping the server. The script setting all this up looks like this (largely cobbled together from google searches):
ifconfig wlan0 down
iw dev wlan0 del
iw phy phy0 interface add ap0 type managed
ip link set dev ap0 address 60:60:60:60:60:01 #this is different for each unit
ifconfig mesh0 up
ifconfig mesh0 10.0.0.1
ifconfig ap0 192.168.0.1 up
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o mesh0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i mesh0 -o eth0 -j ACCEPT
networking wifi iptables routing ethernet
I'm in the process of developing an android app that maintains a device's connectivity to a linux-based WiFi mesh network, and periodically sends status information (GPS, battery life, etc.) to a known server somewhere on the mesh. I'm pretty new to *nix in general so this project has been a massive learning curve, and I think when it comes to networking I'm in pretty far over my head. I'm running into some problems getting update packets traffic to consistently find their way back to the server, and hoping someone will be able to point me in the right direction.
Each one of the mesh nodes is a small linux computer with three network interfaces:
ap0
The WiFi access-point interface managed by hostapd
. IP address is set to 192.168.0.1
, with connected mobile phones being auto-assigned an IP on the same subnet via dhcpd
.
mesh0
The WiFi 802.11s mesh interface connecting the mesh nodes together. Each one is a member of the 10.0.0.0
network.
eth0
Standard ethernet port, assigned IP 192.168.1.101
. Only one of the mesh nodes will use this interface, which will connect to a network containing the server machine (192.168.1.1
).
Just for clarity, here's a mock-up of the network's structure:
So far all I've been able to achieve is getting the nodes to ping each other. The wireless devices can't see outside of their own network (the access point subnet), nor is anything other than the ethernet-connected node able to ping the server. The script setting all this up looks like this (largely cobbled together from google searches):
ifconfig wlan0 down
iw dev wlan0 del
iw phy phy0 interface add ap0 type managed
ip link set dev ap0 address 60:60:60:60:60:01 #this is different for each unit
ifconfig mesh0 up
ifconfig mesh0 10.0.0.1
ifconfig ap0 192.168.0.1 up
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o mesh0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i mesh0 -o eth0 -j ACCEPT
networking wifi iptables routing ethernet
networking wifi iptables routing ethernet
edited Jan 27 at 0:17
Rui F Ribeiro
39.9k1479134
39.9k1479134
asked Oct 29 '14 at 4:42
Mark GillardMark Gillard
163
163
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
802.11s allows all the devices on the "mesh" to see each other at the "layer 2" level... in a wired network, it's the same as if they were all physically plugged into the same network switch. They can all "ping" each other, so long as they are all using the same IP address range etc.
What you have at this point is two unrelated and un-attached networks, one that uses 10.x.x.x
and the second that uses 192.168.x.x
.
In trying to connect these, you need all the 10.x
devices to be told what their "gateway" address is (ie where they send packets that they don't themselves know the actual destination for )... In this case they want their gateway to be 10.0.0.1
. AND you need a static route on the "gateway" box that causes it to know which network interface these packets should "go out". You'll probably also found you need a static route for the other subnet going "out" the other interface as well. Because of the fact that you've got MASQ and RELATED both enabled, you shouldn't have too much trouble with the "return traffic" once the outgoing traffic is working.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f164746%2fsetting-up-a-802-11s-mesh-network-for-mobile-devices-to-communicate-with-a-wired%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
802.11s allows all the devices on the "mesh" to see each other at the "layer 2" level... in a wired network, it's the same as if they were all physically plugged into the same network switch. They can all "ping" each other, so long as they are all using the same IP address range etc.
What you have at this point is two unrelated and un-attached networks, one that uses 10.x.x.x
and the second that uses 192.168.x.x
.
In trying to connect these, you need all the 10.x
devices to be told what their "gateway" address is (ie where they send packets that they don't themselves know the actual destination for )... In this case they want their gateway to be 10.0.0.1
. AND you need a static route on the "gateway" box that causes it to know which network interface these packets should "go out". You'll probably also found you need a static route for the other subnet going "out" the other interface as well. Because of the fact that you've got MASQ and RELATED both enabled, you shouldn't have too much trouble with the "return traffic" once the outgoing traffic is working.
add a comment |
802.11s allows all the devices on the "mesh" to see each other at the "layer 2" level... in a wired network, it's the same as if they were all physically plugged into the same network switch. They can all "ping" each other, so long as they are all using the same IP address range etc.
What you have at this point is two unrelated and un-attached networks, one that uses 10.x.x.x
and the second that uses 192.168.x.x
.
In trying to connect these, you need all the 10.x
devices to be told what their "gateway" address is (ie where they send packets that they don't themselves know the actual destination for )... In this case they want their gateway to be 10.0.0.1
. AND you need a static route on the "gateway" box that causes it to know which network interface these packets should "go out". You'll probably also found you need a static route for the other subnet going "out" the other interface as well. Because of the fact that you've got MASQ and RELATED both enabled, you shouldn't have too much trouble with the "return traffic" once the outgoing traffic is working.
add a comment |
802.11s allows all the devices on the "mesh" to see each other at the "layer 2" level... in a wired network, it's the same as if they were all physically plugged into the same network switch. They can all "ping" each other, so long as they are all using the same IP address range etc.
What you have at this point is two unrelated and un-attached networks, one that uses 10.x.x.x
and the second that uses 192.168.x.x
.
In trying to connect these, you need all the 10.x
devices to be told what their "gateway" address is (ie where they send packets that they don't themselves know the actual destination for )... In this case they want their gateway to be 10.0.0.1
. AND you need a static route on the "gateway" box that causes it to know which network interface these packets should "go out". You'll probably also found you need a static route for the other subnet going "out" the other interface as well. Because of the fact that you've got MASQ and RELATED both enabled, you shouldn't have too much trouble with the "return traffic" once the outgoing traffic is working.
802.11s allows all the devices on the "mesh" to see each other at the "layer 2" level... in a wired network, it's the same as if they were all physically plugged into the same network switch. They can all "ping" each other, so long as they are all using the same IP address range etc.
What you have at this point is two unrelated and un-attached networks, one that uses 10.x.x.x
and the second that uses 192.168.x.x
.
In trying to connect these, you need all the 10.x
devices to be told what their "gateway" address is (ie where they send packets that they don't themselves know the actual destination for )... In this case they want their gateway to be 10.0.0.1
. AND you need a static route on the "gateway" box that causes it to know which network interface these packets should "go out". You'll probably also found you need a static route for the other subnet going "out" the other interface as well. Because of the fact that you've got MASQ and RELATED both enabled, you shouldn't have too much trouble with the "return traffic" once the outgoing traffic is working.
edited Sep 6 '16 at 17:40
Tomasz
9,51652965
9,51652965
answered Sep 6 '16 at 16:16
davidbuzzdavidbuzz
111
111
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f164746%2fsetting-up-a-802-11s-mesh-network-for-mobile-devices-to-communicate-with-a-wired%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown