re: ip address & phone number allocation
Cody Cooper
I know that on the Robin-Mesh project they convert the MAC address of the hardware into the IP address used on the network.
Maybe you guys should do that? It would save you all from manually having to set an IP & phone number for each device.
I've modified the code a little, so that it would provide a phone number as well.
See here for the page & code: http://www.codycooper.co.nz/mac2ip.html
Cody Cooper
Student & Website Designer
eMail: co...@codycooper.co.nz
Web: www.codycooper.co.nz
Phone: (06) 328-8707
Mobile: 027-853-9159
This email and attachments: may be confidential; may be protected by
privilege and copyright; if received in error may not be used, copied, or
kept; are not guaranteed to be virus-free; and do not designate an
information system.
Steve Song
Very neat, and I think it works very well for OpenMesh. The downside
is that having unique but random IP addresses means that we wouldn't
be able to take advantage of David Rowe's inspired hack of being able
to dial the last octet of the IP address to call another Mesh Potato.
Power-up the MP, dial 2663 to set the IP address and in a few minutes
you can have a simple phone network where you can dial 1 through 254
for phone extensions. This makes for an amazingly powerful demo as I
can vouch for having just spent two days doing this over and over
again at MakreFaire Afrika in Nairobi. Nairobi, by the way, is where
it's happening. What an amazing experience.
The other thing is that our plan is for MP networks that use the VTE
server to have their IP and phone settings provisioned as part of the
being recognised by the VTE server. Antoine's Afrimesh code
effectively does this now but won't be turned on until we get some of
Alberto's time (in the next couple of months) to integrate A2Billing
more closely with Afrimesh.
Cheers... Steve
> --
> You received this message because you are subscribed to the Google Groups
> "village-telco-dev" group.
> To post to this group, send email to village-...@googlegroups.com.
> To unsubscribe from this group, send email to
> village-telco-...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/village-telco-dev?hl=en.
>
--
Steve Song
Telecommunications Fellow, Shuttleworth Foundation
email: steve...@shuttleworthfoundation.org
work: +27 21 970 1220
mobile: +27 83 482 2088
skype: steve_l_song
blog: http://manypossibilities.net
twitter: stevesong
Paul Gardner-Stephen
On Aug 29, 10:16 am, Cody Cooper <c...@codycooper.co.nz> wrote:
> Hi all,
>
> I know that on the Robin-Mesh project they convert the MAC address of the
> hardware into the IP address used on the network.
> Maybe you guys should do that? It would save you all from manually having to
> set an IP & phone number for each device.
We should certainly consider such solutions, especially for IP
allocation.
It would certainly be nice to have something that can automatically
allocate IP addresses.
We could also consider using the 240.0.0.0/4 experimental IP range for
mesh addresses to make this task a little easier and more scalable.
> I've modified the code a little, so that it would provide a phone number as
> well.
> See here for the page & code:http://www.codycooper.co.nz/mac2ip.html
Serval's Distributed Numbering Architecture.
Having said that, there is always more than one way to skin a cat, and
solutions are not mutually exclusive.
Paul.
> Cody Cooper
> Student & Website Designer
>
Steve Song
On 29 August 2010 14:49, Paul Gardner-Stephen
<paul.gardn...@gmail.com> wrote:
[snip]
> Having said that, there is always more than one way to skin a cat, and
> solutions are not mutually exclusive.
Seconded! The OpenMesh-style, DNA, and VTE approaches are all valid.
What works for you is what counts.
Cheers... Steve
McTim
HI Steve,
Are you still in NBO? I am back now, but had to miss MakerFaire! ;-(
If you are available, would love to meet you for a coffee or lunch!
rgds,
McTim
David Carman
<paul.gardn...@gmail.com> wrote:
> We could also consider using the 240.0.0.0/4 experimental IP range for
> mesh addresses to make this task a little easier and more scalable.
Bingo!
I was about to NAT myself into a knot until you mentioned the /4 address space.
To avoid NAT, one has to divide the whole network space in half,
giving half the bits to the WLAN and half to the HNAs. For the current
SWUG 192.168.0.0/16 range, that means only 253 WLAN addresses and I am
now having to recycle addresses that appear dormant. One day someone
is going to switch their router on after being away for over a year
and we'll have the duplicate mesh address nightmare.
The immediate solution was to use the 10.0.0.0/8 range and split the
24 available bits into two halves of 12 bits each, giving 4093 WLAN
addresses instead of 253. This makes determination of the IP from
phone number (and vice versa) difficult (but possible) and it didn't
seem worth it for a scale-up of x16.
However a /4 network range scales up x64 and gives a possible 16 381
WLAN addresses/phone numbers and seems worth doing, until either IPv6
becomes standard or routers become powerful enough to NAT IPv4 without
too much effort.
I have written a telephone-to-IP conversion script at
http://www.prospect.ac.za/ip.html. Note that I have used the constant
3FFE (11111111111110) as the first 14 bits of the WLAN network range,
so phone number 16382 cannot have a HNA.
At some stage I'd like to explore decentralized IP/phone number
allocation using this range:
1. Single-digit numbers are reserved for local IVRS functions (signal
strength, metrics, local config).
2. Double digit numbers are reserved for gateway IVRS functions
(service availability, announcements, voicemail), limiting the number
of standard gateways on a mesh to 9.
3. Any unconfigured router will choose a random IP address among the
8191 addresses in the 255.255.160.0/19 range, but will not be able to
route data or calls until a phone number is chosen through IVRS/webif,
which corresponds to an IP in the lower 255.255.128.0/19 range.
4. The chosen number is broadcasted to all routers on the mesh. Every
router that receives it stores it as a 2 byte record using uci.
Routers update each others records during quiet times.
5. If any router already has the number stored, a response is sent to
the requesting router that vetoes use of that number and the user is
asked to choose another one.
6. If no veto response is received, the new router configures itself
to use that WLAN IP permanently.
Advantages:
1. Self-configuration with no centralized server/supernode or custom
firmware images.
2. Each user chooses their own phone number.
Disadvantages:
1. Limits number of routers on a mesh to 8089.
2. Limits number of gateways to 9.
Hopefully by the time these limitations are reached, IPv6 will be
standard or the MP09 will have a 400MHz processor and 64MB RAM :)
Using the 240.0.0.0/4 address space also avoids the necessity of
installing netfilter on routers to drop the 192.168.0.0/16 and
10.0.0.0/8 packets from machines that are still polling network shares
from their previous LAN - the one reason why I need netfilter on the
MPs at the moment.
David
Paul Gardner-Stephen
On Aug 30, 4:18 am, David Carman <tidg...@gmail.com> wrote:
> On Sun, Aug 29, 2010 at 2:49 PM, Paul Gardner-Stephen
>
> > We could also consider using the 240.0.0.0/4 experimental IP range for
> > mesh addresses to make this task a little easier and more scalable.
>
> Bingo!
>
> I was about to NAT myself into a knot until you mentioned the /4 address space.
>
> To avoid NAT, one has to divide the whole network space in half,
> giving half the bits to the WLAN and half to the HNAs. For the current
> SWUG 192.168.0.0/16 range, that means only 253 WLAN addresses and I am
> now having to recycle addresses that appear dormant. One day someone
> is going to switch their router on after being away for over a year
> and we'll have the duplicate mesh address nightmare.
>
> The immediate solution was to use the 10.0.0.0/8 range and split the
> 24 available bits into two halves of 12 bits each, giving 4093 WLAN
> addresses instead of 253. This makes determination of the IP from
> phone number (and vice versa) difficult (but possible) and it didn't
> seem worth it for a scale-up of x16.
>
> However a /4 network range scales up x64 and gives a possible 16 381
> WLAN addresses/phone numbers and seems worth doing, until either IPv6
> becomes standard or routers become powerful enough to NAT IPv4 without
> too much effort.
>
> so phone number 16382 cannot have a HNA.
>
> At some stage I'd like to explore decentralized IP/phone number
> allocation using this range:
> 1. Single-digit numbers are reserved for local IVRS functions (signal
> strength, metrics, local config).
> 2. Double digit numbers are reserved for gateway IVRS functions
> (service availability, announcements, voicemail), limiting the number
> of standard gateways on a mesh to 9.
> 3. Any unconfigured router will choose a random IP address among the
> 8191 addresses in the 255.255.160.0/19 range, but will not be able to
> route data or calls until a phone number is chosen through IVRS/webif,
> which corresponds to an IP in the lower 255.255.128.0/19 range.
odd to have a bitmask of 240.0.127.255, but it avoids the problem of
IP addresses that end in .255, which may otherwise confuse things/
people. The trade-off is that you reduce your number of WLANs by
about 1/256. Alternatively, such a non-intuitive netmask might cause
even more confusion ...
> 4. The chosen number is broadcasted to all routers on the mesh. Every
> router that receives it stores it as a 2 byte record using uci.
> Routers update each others records during quiet times.
> 5. If any router already has the number stored, a response is sent to
> the requesting router that vetoes use of that number and the user is
> asked to choose another one.
> 6. If no veto response is received, the new router configures itself
> to use that WLAN IP permanently.
>
> Advantages:
> 1. Self-configuration with no centralized server/supernode or custom
> firmware images.
> 2. Each user chooses their own phone number.
>
> Disadvantages:
> 1. Limits number of routers on a mesh to 8089.
> 2. Limits number of gateways to 9.
>
> Hopefully by the time these limitations are reached, IPv6 will be
> standard or the MP09 will have a 400MHz processor and 64MB RAM :)
>
> Using the 240.0.0.0/4 address space also avoids the necessity of
> installing netfilter on routers to drop the 192.168.0.0/16 and
> 10.0.0.0/8 packets from machines that are still polling network shares
> from their previous LAN - the one reason why I need netfilter on the
> MPs at the moment.
advantage of the 240.0.0.0/4 network.
I do have a further crazy idea that makes this one redundant as well,
but it requires a bit more work.
Basically it is possible to modify BATMAN to function as a pure
overlay-mesh using UDP broadcast packets (remember everything on radio
is really a broadcast anyway). Doing this makes the IPv4 addresses
completely unnecessary; every node on the mesh could have the same IP
address, and it would still work. You just use MAC addresses or some
other nice unique quantity as the node addresses. Then payloads are
carried in large packets that double as BATMAN messages, with the next
and final hop addresses tagged on each embedded payload. This also
has the opportunity to be much more efficient of air-time, and causes
the BATMAN scores to actually reflect the ability to get traffic
through, since there is no longer a separation from control and data
packets.
On the down side it will need some hacking to get Asterisk and friends
to use this virtual transport. Having said that, the fact that it
works at such a low layer means that we can just intercept socket(),
sendto(), recvfrom() etc. I have done similar things before.
Paul.
> David
David Rowe
> Maybe you guys should do that? It would save you all from manually
> having to set an IP & phone number for each device.
As Steve pointed out, manually setting the IP and hence phone number
works really well. To put it plainly - it's not a problem we need to
fix. The (CONF-2663) system is actually one of the strengths of the
Village Telco.
The Dili Village Telco guys are now performing "2nd generation
training", the guys I trained are now training others as the Potatoes go
up all over Dili. This makes the Village Telco viral. One of the main
reason is ease of set up - CONF-2663. Importantly, nothing much can go
wrong with this feature.
So setting the IP and hence phone number has been solved several times
now for the Village Telco! Curiously, it seems to be an area that still
attracts a lot of work and interest.....
However, there are plenty of others problems out there that _do_ need
solving, for example :
1/ What happens to voice quality when the network scales?
2/ Do networks stay up over time? How much maintenance is required? Can
people make phone calls whenever they want?
3/ We still have problems setting up reliable links with interference
and Line of Site issues.
4/ 100% rock solid and reliable Mesh Potato firmware update over Wifi,
such that a MP never ever gets bricked up a mast.
5/ Server-side software (Afrimesh, billing system etc) that is easy to
set up and as stable and mature as the Mesh Potato. We need a release
far far more than we need more Alpha features.
6/ A simple and mature tool/procedure for setting up a good mesh Wifi
link. One my 12 year old can use without knowing about ping, Linux
command lines, technical details of batman metrics etc etc. One that
works while you are hanging off a pole 12m in the air with one hand on
your Potato.
7/ A procedure/tool that tells non-Wifi experts (i) when they need a
directional antenna (ii) when a link isn't possible as LOS or
interference is so bad. See (6).
8/ Test procedures, plans, reports, and software for MP firmware and
server releases so we can establish the software quality of each
release. This becomes more important as we leave the experimental stage
and start deploying. In the experimental stage of the project alpha
features can be tolerated, for deployments they can't. The
coding/testing effort swings from 80/20 to 20/80 between these phases.
For release software we have "test sprints" rather than "coding
sprints" (although the tests themselves may in fact be software
performing automated testing).
9/ A MP directional antenna option that can be fabricated for a few $,
either in a factory or possibly from locally available materials.
10/ Deployments, Deployments, deployments, so we can find out what
works, and what doesn't. Remember beta testers, nothing to stop you
deploying with a minimum of 2 MPs.
Cheers,
David
David Carman
On Mon, Aug 30, 2010 at 12:22 AM, David Rowe <da...@rowetel.com> wrote:
> As Steve pointed out, manually setting the IP and hence phone number
> works really well. To put it plainly - it's not a problem we need to
> fix. The (CONF-2663) system is actually one of the strengths of the
> Village Telco.
...until you have 254 MPs on your network, or someone chooses a
duplicate number using 2663.
> So setting the IP and hence phone number has been solved several times
> now for the Village Telco! Curiously, it seems to be an area that still
> attracts a lot of work and interest.....
I am attempting to provide phone services on an existing data network.
In my situation, data drives the growth of the mesh. If I were to use
2663, I would have run out of numbers and the routers would be NATing.
So I need to solve this; others do too, and so will you when you have
254 routers on the Dili mesh, which sounds like it's going to happen
sooner rather than later and then you'll also be faced with
reconfiguring 250 routers.
> 1/ What happens to voice quality when the network scales?
Then the beauty of a mesh network is revealed. Infrastructure networks
degrade with the addition of nodes - mesh network performance
improves. 10 hop ping stats across 10km have never been better:
PING 192.168.10.93 (192.168.10.93) 56(84) bytes of data.
64 bytes from 192.168.10.93: icmp_seq=1 ttl=56 time=65.4 ms
64 bytes from 192.168.10.93: icmp_seq=2 ttl=56 time=30.3 ms
64 bytes from 192.168.10.93: icmp_seq=3 ttl=56 time=39.4 ms
64 bytes from 192.168.10.93: icmp_seq=5 ttl=56 time=30.2 ms
64 bytes from 192.168.10.93: icmp_seq=6 ttl=56 time=19.5 ms
64 bytes from 192.168.10.93: icmp_seq=7 ttl=56 time=18.9 ms
64 bytes from 192.168.10.93: icmp_seq=8 ttl=56 time=20.5 ms
64 bytes from 192.168.10.93: icmp_seq=9 ttl=56 time=32.7 ms
64 bytes from 192.168.10.93: icmp_seq=10 ttl=56 time=22.1 ms
^C
--- 192.168.10.93 ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 9018ms
rtt min/avg/max/mdev = 18.974/31.043/65.448/13.855 ms
> 3/ We still have problems setting up reliable links with interference
> and Line of Site issues.
For the hell of it, I am running the batman test network on channel 11
- the same as the SWUG OLSR network. I have 2 Nanos, 2MPs and a WRT in
my lounge and see very little degradation on my SWUG connection.
However when I use the microwave, everything goes down.
802.11 scanning is like those x-ray glasses they sold on the back page
of 80s comics - looks real but isn't. Only a 2.4GHz spectrometer can
do the job.
As stated before, the OLSR beta-MP can squeeze a few packets through
while the microwave's on and I think this may be due to it being in a
metal box. A plastic production MP should confirm this. The solution
to microwave oven interference is... more nodes.
> 4/ 100% rock solid and reliable Mesh Potato firmware update over Wifi,
> such that a MP never ever gets bricked up a mast.
I have used "mtd write" to update WRTs over WiFi 200+ times and have
never bricked a box. However that is taking advantage of the NVRAM in
the WRT. With MPs I need to mtd write generic images over LAN and then
log in to reconfigure.
Caveat: ensure that your kernel mtd partition is big enough early on
to cater for larger kernel updates; otherwise you're going to be up
every Nano mast to access the reset button for a future upgrade. LAN
MP RedBoot access is a major improvement over Nanos in this regard.
David
David Rowe
> ...until you have 254 MPs on your network
I can think of a several way around this, I don't think it will be a
show stopper. The dial plan already supports dialling the full IP or
any subset, e.g. 10.130.1.1, 130.1.1, 1.1, 1. So when node 256 gets
installed it can be dialled on 2*1. Or a line of dial-plan could be
added to each MP to make them convert 2001 -> 2.1.
Based on other system constraints (CPU load, hops, real time voice), our
modelling and tests suggest we will hit a wall on voice networks at
about 150 nodes/Wifi channel at a 10% activity factor (15 calls).
David, I am not familiar with your mesh. Can you please explain whey
you are running out of IPs (if that is the problem)? As one of the only
real live meshes running MPs, I am really interested. Thanks.
> Then the beauty of a mesh network is revealed. Infrastructure networks
> degrade with the addition of nodes - mesh network performance
> improves.
Yes I am hoping to see improved coverage too, and less interference
problems as the average links get shorter. However pings on a lightly
loaded mesh are different to real time voice traffic along multiple hops
on a heavily loaded mesh. More nodes brings more users. I am curious
about what voice traffic sounds like when we load an 80 node MP01 mesh
with 10-20 calls. We will find out in a few months.
> > 4/ 100% rock solid and reliable Mesh Potato firmware update over Wifi,
> > such that a MP never ever gets bricked up a mast.
>
> I have used "mtd write" to update WRTs over WiFi 200+ times and have
> never bricked a box.
Very cool. That's a great target for us to aim at :-)
Cheers,
David
David Carman
On Sun, Aug 29, 2010 at 11:07 PM, Paul Gardner-Stephen
<paul.gardn...@gmail.com> wrote:
> Can I suggest that you switch the bit orders around? I know it seems
> odd to have a bitmask of 240.0.127.255, but it avoids the problem of
> IP addresses that end in .255, which may otherwise confuse things/
> people. The trade-off is that you reduce your number of WLANs by
> about 1/256. Alternatively, such a non-intuitive netmask might cause
> even more confusion ...
While using 240.0.0.0/4 is already sailing close to the IANA wind,
inverting the bitmask flouts CIDR and is more likely to fail in
existing IP implementations.
We are used to addresses that end in .255 being broadcasts, but any IP
stack worth its salt would use the netmask.
From what I have read, Mac OSX and Linux are ready to use 240.0.0.0/4
while Microsoft, as usual, is anyone's guess.
> Yes, this separation from the "normal" private IP ranges is a strong
> advantage of the 240.0.0.0/4 network.
Having de-resigned myself to the use of netfilter once again, I have
figured a way to stop these IP ranges from flooding the mesh - route
them back to the local loop. There is one particularly annoying
Microsoft machine on the mesh that keeps looking for its
192.168.0.0/24 network - I'll experiment with "ip route"ing its
packets away from the wireless interface.
David
David Carman
On Mon, Aug 30, 2010 at 9:30 PM, David Rowe <da...@rowetel.com> wrote:
> I can think of a several way around this, I don't think it will be a
> show stopper. The dial plan already supports dialling the full IP or
> any subset, e.g. 10.130.1.1, 130.1.1, 1.1, 1. So when node 256 gets
> installed it can be dialled on 2*1.
Asterisks in phone numbers sound like an unnecessary complication for
the end users.
> Or a line of dial-plan could be
> added to each MP to make them convert 2001 -> 2.1.
Then you are losing phone number space as the third-last digit of
every number will always be 0,1 or 2, and if it is 2, the second-last
number will be <= 5. So you are losing 75% of your possible phone
numbers, making them unnecessarily long, and will have to code this
into the 2663 function and dialplan to ensure that 258 is rejected as
an invalid number.
I would prefer to see callers deal with phone numbers and MPs deal
with IPs addresses. SWUG uses the variable WLAN 4th IP segment as a
"router number". Users must be able to cite their router number when
requesting tech support and it is also their bank reference for paying
into the automated accounting system. So it should be as short as
possible and not include non-numeric characters.
> Based on other system constraints (CPU load, hops, real time voice), our
> modelling and tests suggest we will hit a wall on voice networks at
> about 150 nodes/Wifi channel at a 10% activity factor (15 calls).
Does the model take into account that not all nodes can see each other
and that not all calls will be passing through a single node?
> David, I am not familiar with your mesh. Can you please explain whey
> you are running out of IPs (if that is the problem)? As one of the only
> real live meshes running MPs, I am really interested. Thanks.
To avoid NAT, the WLAN runs in the 192.168.10.255/24 range, while each
router has a LAN IP 192.168.x.1 and can provide DHCP addresses in the
192.168.x.0/24 range, where x is the 4th segment of the router's WLAN
address.
For example, my SWUG router has WLAN IP 192.168.10.221, LAN IP
192.168.221.1 and provides LAN DHCP in 192.168.221.0/24.
Both OLSR and BATMAN offer host-network association (HNA) routing to
the WLAN, which exposes router LAN IPs to the WLAN without NAT.
Default MP installations don't use this function.
So now the whole WLAN and each router's LAN can be seen by the
gateways as a 192.168.0.0/16 network.
The 3rd segment of the WLAN address (10) is constant, precluding the
use of 192.168.10.10 as a WLAN IP - because its LAN range would be the
same as the whole WLAN range.
This addressing system appears simple when applied to the
192.168.0.0/16 address space, but it can be applied to any subnet
range as long as the number of constant and variable bits are the
same. If applied to a 10.0.0.0/8 range, the extra 8 bits have to be
divided between the constant and variable ranges - so 4 bits each,
scaling the actual address space to 255 * 16 = 4096.
Using the extra 2 bits each side in the 240.0.0.0/4 range scales to
255 * 64 = 16384 sequential "phone numbers" or "router numbers".
If you are not running data on the network, this is not a showstopper.
But if you decide to one day, even for non-Internet data, you are
going to have to NAT on each router. For example, how do you see
Afrimesh pages served off a router to which you are not connected by
LAN?
>> I have used "mtd write" to update WRTs over WiFi 200+ times and have
>> never bricked a box.
> Very cool. That's a great target for us to aim at :-)
Not at all. Over the past few years Freifunk-OLSR has gone through a
number of improvements and I have kept the routers as up-to-date as
possible because the OLSR updates have been big improvements. I used
to have a couple of terminals open while working in the early morning,
and upgraded a few routers in the background while I worked. I
described the procedure on this list elsewhere. Fortunately OLSR has
stabilised considerably in the last year and I don't have to do this
anymore.
A friend operating another Freifunk-OLSR mesh used shared key auth for
SSH on all the routers, which meant that he could script upgrades.
That would be the way to go in the future.
David
Steve Song
I feel like we are talking about two different problems. The reason I
don't worry about using more than 254 nodes in a peer-to-peer
telephone network is that I don't really expect a purely peer-to-peer
telephone model to get much bigger than that. I would expect that at
some point whoever is managing the network would want to switch to
using something like the VTE server which would, among other things,
allow coordinated provisioning of telephone numbers. Alternatively if
you did want to scale up a peer-to-peer telephony network, then Paul's
DNA service which assigns your own mobile or PSTN DID as your phone
number might be the way to go.
Cheers... Steve
Rudolf Meijering
Ultimately the village telco is useless if business men, who have the vision but not the technical background cannot use it with reasonable ease. This is one of the goals of the village telco and although a great deal has been accomplished, we still need more good documentation. It helps us if you ask questions cause then we know where we haven't been clear enough. The very fact that you needed to come ask these questions on the list and that it wasn't very clear on the website means we are not living up to our goal (yet).
David Rowe
> Does the model take into account that not all nodes can see each other
> and that not all calls will be passing through a single node?
Yes, capacity is based on the average number of hops over the mesh.
Check out this blog post from last year:
http://www.villagetelco.org/2009/11/factors-affecting-village-telco-performance/
> > David, I am not familiar with your mesh. Can you please explain whey
> > you are running out of IPs (if that is the problem)? As one of the only
> > real live meshes running MPs, I am really interested. Thanks.
>
> To avoid NAT, the WLAN runs in the 192.168.10.255/24 range, while each
> router has a LAN IP 192.168.x.1 and can provide DHCP addresses in the
> 192.168.x.0/24 range, where x is the 4th segment of the router's WLAN
> address.
<snip>
Thank you for taking the time to explain this. Although I am not very
strong on networks, I understood your explanation as I have a very
similar design for the Dili Village Telco:
http://dili.villagetelco.org/index.php?title=Main_Page#Network_Diagram
I also wanted a flat (no NAT) network. The idea is some kid with a
eeepc can put some content up on a web server and share it with other
people in Dili.
The mesh routers are on 10.130.0.0/16 and the DHCP (HNA) addresses that
hang off each router are on 10.30.0.0/24, e.g. MP 10.130.1.8 has
10.30.8.0/24 hanging (HNA-ed) off it. But if we run out of 10.30.0.0/16
addresses I think we can just go to 10.31.0.0/24 for the local DHCP
(HNA) address range. Somehow batman policy routing foo makes it all
work.
So in Dili we don't have the 8 bit limit for number number of mesh
nodes.
Having said that I am not seeing much interest in the "metro WLAN" part
of Dili Village Telco. All the real world users seem to want is
telephony. At least so far, it's early days.
This is one of the interesting social (non-technical) outcomes from a
real world trial. I spent a lot of time working on a nice network
design. Then no one use it. It's why I an so keen on real world
deployments over more feature development.
> >> I have used "mtd write" to update WRTs over WiFi 200+ times and have
> >> never bricked a box.
> > Very cool. That's a great target for us to aim at :-)
>
> Not at all. Over the past few years Freifunk-OLSR has gone through a
What I meant was it's very cool to have that level of reliability when
reflashing over Wifi.
Cheers,
David
David Carman
On Wed, Sep 1, 2010 at 12:06 AM, David Rowe <da...@rowetel.com> wrote:
> http://dili.villagetelco.org/index.php?title=Main_Page#Network_Diagram
Aah - I had seen the diagram but hadn't noticed that each MP had a HNA
subnet. The beta-MPs don't have it configured, and also don't have
dnsmasq preinstalled.
> The mesh routers are on 10.130.0.0/16 and the DHCP (HNA) addresses that
> hang off each router are on 10.30.0.0/24, e.g. MP 10.130.1.8 has
> 10.30.8.0/24 hanging (HNA-ed) off it. But if we run out of 10.30.0.0/16
> addresses I think we can just go to 10.31.0.0/24 for the local DHCP
> (HNA) address range. Somehow batman policy routing foo makes it all
> work.
> So in Dili we don't have the 8 bit limit for number number of mesh
> nodes.
My penny has dropped! This "flat network" addressing scheme is far
more efficient and intuitive than 240.0.0.0/4 as the phone number is
derived from two complete segments. It also doesn't require a HNA
range as large as the WLAN range. So I'll be using this scheme,
probably with 10.x.y.0/24 HNA for 10.255.x.y/16 WLAN. Thank you for
your patient enquiries and explanation.
Using 10.0.0.0/8 still exposes the WLAN to non-existent network
shares, but at least 192.168.0.0/16 can be routed to null, and
10.0.0.0/8 dealt with when encountered.
> Having said that I am not seeing much interest in the "metro WLAN" part
> of Dili Village Telco. All the real world users seem to want is
> telephony. At least so far, it's early days.
>
> This is one of the interesting social (non-technical) outcomes from a
> real world trial. I spent a lot of time working on a nice network
> design. Then no one use it. It's why I an so keen on real world
> deployments over more feature development.
The metro WLAN design will pay off in the real world. HNA is an
integral part of the BATMAN protocol and is a clever way of avoiding
NAT overhead. Network admin data can flow directly to client machines
for a start, and I think NGOs can benefit both shared data resources
and Internet. However they are not going to appreciate the
multipurpose capabilities of the mesh until it is demonstrated.
Acquaintances working for the UN in Timor Leste use Timor Telecom 3G
for Internet at huge expense. The economic model of African telecoms
seems to apply there - only the wealthy have Internet access. The
worst consequence of this is that schoolchildren have no access to the
world's largest information resource unless their parents are prepared
and able to pay the high ongoing costs. Two schoolchildren who got
involved in SWUG 4 years ago are now studying IT at university -
neither of them would have had broadband Internet access if SWUG were
not available - they were previously restricted to brief moments of
dialup access because their parents were down their throat about the
phone bill and taking up the phone line.
Providing Internet over a VoIP mesh has not appeared to degrade phone
calls from my experience in providing IAX softphone-to-POTS and
recently testing of beta-MPs. Given, the phone call load was not high,
but the most reassuring observation was that UDP packets are
transmitted far more effectively than large TCP packets over the mesh.
That said, there is some Internet traffic that can choke the mesh:
1. UDP packets from a Skype supernode.
2. UDP packets from gamers.
3. TCP/UDP packets from malware.
4. Multiple TCP connections from torrent filesharing.
5. Non-existent network shares.
I am in the business of writing myself out of mesh/gateway admin by
developing methods that can regulate this type of traffic without
inspecting packet contents. The only information that I use is:
1. Packet and byte counts from pmacct running on the gateways. This
gives me an idea of whether heavy traffic is TCP or UDP.
2. Source IP address. Without HNA and "flat network" design, I cannot
tell whether heavy traffic is due to a large LAN behind the router or
from a single machine. I also cannot redirect specific LAN machines to
a custom web page that guides the user to resolving the issue, and
reactivating their Internet connection having done so.
So while the flat network design does not do much for you yet, I hope
that it does so later and that I can help with the Internet gateway.
So far, using packages like lighttpd and sqlite, I have been able to
squeeze all Internet gateway functions onto a board with a Via 577MHz
CPU and 512MB RAM, drawing 30W of 12VDC, with no speed loss. However
when I deploy a SIP gateway, it will definitely be on another machine,
preferably on the other side of the mesh.
regards
David
Corinna Elektra Aichele
HNA announced subnets are the default in the end-user version of the MP
firmware available at ftp://elektrad.info/MESH-POTATO if the user selects the
"mesh gateway client" profile. An individual local subnet address is generated
from the last octet of the WiFi IP. So far it is limited to a Class C (/24)
address range, which is probably fair enough for a end user. There is no lack
of IP space to accommodate larger subnets including HNA.
> > The mesh routers are on 10.130.0.0/16 and the DHCP (HNA) addresses that
> > hang off each router are on 10.30.0.0/24, e.g. MP 10.130.1.8 has
> > 10.30.8.0/24 hanging (HNA-ed) off it. But if we run out of 10.30.0.0/16
> > addresses I think we can just go to 10.31.0.0/24 for the local DHCP
> > (HNA) address range. Somehow batman policy routing foo makes it all
> > work.
It is just plain IP sub-netting, so doesn't need policy routing.
> The metro WLAN design will pay off in the real world. HNA is an
> integral part of the BATMAN protocol and is a clever way of avoiding
> NAT overhead. Network admin data can flow directly to client machines
> for a start, and I think NGOs can benefit both shared data resources
> and Internet. However they are not going to appreciate the
> multipurpose capabilities of the mesh until it is demonstrated.
Indeed - NAT cripples routing performance and network versatility.
> Providing Internet over a VoIP mesh has not appeared to degrade phone
> calls from my experience in providing IAX softphone-to-POTS and
> recently testing of beta-MPs. Given, the phone call load was not high,
> but the most reassuring observation was that UDP packets are
> transmitted far more effectively than large TCP packets over the mesh.
> That said, there is some Internet traffic that can choke the mesh:
> 1. UDP packets from a Skype supernode.
> 2. UDP packets from gamers.
> 3. TCP/UDP packets from malware.
> 4. Multiple TCP connections from torrent filesharing.
> 5. Non-existent network shares.
That is an excellent result. However I expect that any additional traffic in the
wireless medium will have influence on the number of calls. It is obvious that
voice traffic needs to be prioritized on the Internet gateway, particularly with
the Internet uplink problems of developing countries.
Cheers,
Elektra