9 Apr
2007
9 Apr
'07
5:57 p.m.
Hi all, particularly those who attended the workshop on 31st March and
1st April, and last saturday Rony, Jtd resumed the work.
Status:
Last saturday we successfully managed to get the mesh working. Actually
the mesh works out of the box like a charm. We only used several of our
legacy skills and actually wasted lot of time. But at the end every
moment spent was useful. We now know exactly what to communicate to
others who wish to setup such a mesh (mess ;-) successfully.
The dhcp on wireless was not working as of Saturday, but today afternoon
I tried based on a reply from the olsr-users mailing list. Again it
worked out of the box.
What I did:
installed a package called 'freifunk-dnsmasq', restarted it. Now we see
an additional parameter on the web interface called OLSR-DHCP: This is
where we give the DHCP share of the mesh network (not the lan network).
thats it.
Now we have a working mesh in the campus. I will write documentation
here: http://fci.wikia.com/wiki/WirelessMesh. Please add to everything
I missed out. I will also upload few screen shots so that new teams
setting it up will find it useful.
Next step:
Prepare a server (Rony contributed a server) and dump useful resources
there for community use. Next time, gluggers can walk into our campus
and sit in our lounge with a laptop and takeaway what the server has.
If we get a list of goodies that the community needs we will begin
archiving them. So send such a request to glab(a)hbcse.tifr.res.in. we
will download them during the night time and leave it one the server.
Nagarjuna
9 Apr
9 Apr
9:09 p.m.
Nagarjuna G. wrote:
The dhcp on wireless was not working as of Saturday, but today afternoon
I tried based on a reply from the olsr-users mailing list. Again it
worked out of the box.
What I did:
installed a package called 'freifunk-dnsmasq', restarted it. Now we see
an additional parameter on the web interface called OLSR-DHCP: This is
where we give the DHCP share of the mesh network (not the lan network).
thats it.
This is great news. So it was a missing package. :)
--
Regards,
Rony.
11:09 p.m.
On Monday 09 Apr 2007 17:57:32 Nagarjuna G. wrote:
installed a package called 'freifunk-dnsmasq',
restarted it. Now we see
an additional parameter on the web interface called OLSR-DHCP: This is
where we give the DHCP share of the mesh network (not the lan network).
thats it.
I need some details.
This entire thing now works only on the WLAN interface right? Is the LAN
completely out of the picture? So, the backend itself gets broadened? Maybe
subnetted, depending on the DHCP server(s).
Secondly, without the dnsmasq package, can we get the native udhcpd to work
with the OLSR interface? I think we can.. What's the OLSR interface that
shows up with ifconfig? It is possible, I think, to manually configure the
DHCP server to listen on the OLSR interface.
The problem, I think, wasn't with the missing package, but with the fact that
we had DHCP running on the WLAN interface instead of the OLSR interface. The
native DHCP should work perfectly fine if I'm right... unless dnsmasq has
some features I don't know about..
--
----------------------------------------
Mrugesh Karnik
GPG Key 0xBA6F1DA8
Public key on http://wwwkeys.pgp.net
----------------------------------------
10 Apr
10 Apr
1:21 a.m.
Mrugesh Karnik wrote:
On Monday 09 Apr 2007 17:57:32 Nagarjuna G. wrote:
DHCP works only in the LAN, not in WLAN. If WLAN is set to dhcp then
there is no mesh getting established. WLAN IP has to be static. With
static WLAN, we can access any network through the mesh. Even internet
access was possible by simply plugging in the cable to the WAN port of
one router. Even though it was outside the 192.168.x.x subnet. NAT and
Firewall were enabled.
installed a package called
'freifunk-dnsmasq', restarted it. Now we see
an additional parameter on the web interface called OLSR-DHCP: This is
where we give the DHCP share of the mesh network (not the lan network).
thats it.
I need some details.
This entire thing now works only on the WLAN interface right? Is the LAN
completely out of the picture? So, the backend itself gets broadened? Maybe
subnetted, depending on the DHCP server(s).
Secondly, without the dnsmasq package, can we get the native udhcpd to work
with the OLSR interface? I think we can.. What's the OLSR interface that
shows up with ifconfig? It is possible, I think, to manually configure the
DHCP server to listen on the OLSR interface.
The native dhcpd does not allow any changes to it.
The problem, I think, wasn't with the missing package, but with the fact that
we had DHCP running on the WLAN interface instead of the OLSR interface. The
native DHCP should work perfectly fine if I'm right... unless dnsmasq has
some features I don't know about..
Yes it works fine but only in LAN. There is no native provision to
allocate dhcp ips for wireless users who join in. Thats why the extra
package.
--
Regards,
Rony.
11:55 a.m.
On Tuesday 10 Apr 2007 01:21:14 Rony wrote:
There is provision. I did the last time. Edit the /etc/local.udhcpd.conf file.
Either that or something similar. It allows you to run DHCP on any interface.
With dnsmasq you get a DNS server + DHCP server. I'm wondering what has been
done with the DNS server part? Does it run a caching nameserver or something?
What's the nameserver address that any client connecting gets from the
server?
The mistake I made, due to obvious lack of knowledge, was to run the DHCP
server on the WLAN interface rather than the OLSR interface. Can someone
please post the ifconfig output on the `server'? Server being the wireless
router connected to the internet directly through its WAN port.
--
----------------------------------------
Mrugesh Karnik
GPG Key 0xBA6F1DA8
Public key on http://wwwkeys.pgp.net
----------------------------------------
DHCP works only in the LAN, not in WLAN. If WLAN is
set to dhcp then
there is no mesh getting established. WLAN IP has to be static. With
static WLAN, we can access any network through the mesh. Even internet
access was possible by simply plugging in the cable to the WAN port of
one router. Even though it was outside the 192.168.x.x subnet. NAT and
Firewall were enabled.
Err. The static WLAN IP is for the server. After that any client who wants to
connect gets an ip from the DHCP server. You can run the native udhcpd on any
interface you want.
The native dhcpd does not allow any changes to it.
It does. I had set it up and it was working properly on 31st. It was working
fine for WLAN, not OLSR, because if I'm not mistaken, there's a different
interface for OLSR, bridged with the actual WLAN interface. The DHCP server
was running on the WLAN interface rather than the OLSR interface.
The problem, I
think, wasn't with the missing package, but with the fact
that we had DHCP running on the WLAN interface instead of the OLSR
interface. The native DHCP should work perfectly fine if I'm right...
unless dnsmasq has some features I don't know about..
Yes it works fine but only in LAN. There is no native provision to
allocate dhcp ips for wireless users who join in. Thats why the extra
package. 
12:30 p.m.
On Tuesday 10 April 2007 11:55, Mrugesh Karnik wrote:
On Tuesday 10 Apr 2007 01:21:14 Rony wrote:
I think it was a combination of settings that allowed dhcp. Cause when
we disabled dhcp in the web i/f and tried to create a udhcpd.conf
file it simply refused to run on ANY interface.
DHCP works only in the LAN, not in WLAN. If WLAN
is set to dhcp
then there is no mesh getting established. WLAN IP has to be
static. With static WLAN, we can access any network through the
mesh. Even internet access was possible by simply plugging in the
cable to the WAN port of one router. Even though it was outside
the 192.168.x.x subnet. NAT and Firewall were enabled.
Err. The static WLAN IP is for the server. After that any client
who wants to connect gets an ip from the DHCP server.
You can run
the native udhcpd on any interface you want.
The native dhcpd does not allow any changes to
it.
It does. I had set it up and it was working properly on 31st. It
was working fine for WLAN, not OLSR, because if I'm not mistaken,
there's a different interface for OLSR, bridged with the actual
WLAN interface. The DHCP server was running on the WLAN interface
rather than the OLSR interface.
The OLSR i/f is for the backbone routing. running dhcp on this will
open a new can of worms requiring dhcp forwarding etc.
There is provision. I did the last time. Edit the
/etc/local.udhcpd.conf file. Either that or something similar. It
allows you to run DHCP on any interface.
Trust u not to remember ;-). We tried to replicate what u did but
could not.
With dnsmasq you get a DNS
server + DHCP server. I'm wondering what has been done with the DNS
server part? Does it run a caching nameserver or something? What's
the nameserver address that any client connecting gets from the
server?
The mistake I made, due to obvious lack of knowledge, was to run
the DHCP server on the WLAN interface rather than the OLSR
interface.
afaik what u did was right but we were unable to repeat it. Which
makes it a chance occurence or your own brand of witchcraft ;-) or
we were stupid - but i am sure that it's not the case.
Can someone please post the ifconfig output on the
`server'? Server being the wireless router connected to the
internet directly through its WAN port.
--
Rgds
JTD
2:41 p.m.
jtd wrote:
The OLSR i/f is for the backbone routing. running dhcp on this will
open a new can of worms requiring dhcp forwarding etc.
we have to think that the mesh administration as similar to an ISP
spreading its network. If an ISP baught a fixed number of IP's from its
ISP, then they have to either allocate the existing IPs dynamically
through dhcp or statically by allocating one to each customer. What
OLSR is doing is dynamically calculating the routing for each
neighborhood of the mesh.
Similarly, in a mesh what we have to do is to distribute the backbone
WLAN network IPs, the way we want. So, I think, each mesh manager must
adopt a policy.
If we use 10.0.0.0 network with mask 255.0.0.0 as the WLAN network. For
us these are the addresses that we can use. We can give for each router
say 16 clients (or even less) that is good enough. Some one may
calculate how many routers and clients are possible. If we have to
increase the number of routers, we do have to decrease the number of
clients. But, since clients can also be connected by parallel LAN, the
network can expand quite a lot.
As of now this is how I am understanding the mesh setup based on the
last three weeks of experience. someone may correct me if my
understanding is wrong.
Nagarjuna
6:16 p.m.
On Tuesday 10 Apr 2007 12:30:50 jtd wrote:
Agreed. It needs to run the DHCP server on the wired LAN ports. That's the
default setting. You can add one additional interface through the local
config file. Which is what I had done.
The init scripts are a kind of weird.
Hmmmm. Now I'm royally confused. Which interface does dnsmasq listen to, in
the working mesh? From what Dr. Nagarjuna said, there was a parameter called
`OLSR-DHCP'. I assumed that that corresponds to the OLSR interface. I assumed
wrong it seems :s So if I'm wrong, I guess OLSR handles the `cascaded' DHCP
requests properly with dnsmasq listening to the WLAN interface?
Well take a look at the init script /etc/init.d/udhcpd. There's a section
towards the end where it populates the /etc/udhcpd.conf file with a here
document. You'll see that it sources the file /etc/local.something at the end
of the here document. This is the file where the manual configuration goes.
In the udhcpd.conf, there comes up a comment saying `local settings go after
this' or something. The sourced local file is reproduced there, right below
the default config section.
It does. I had
set it up and it was working properly on 31st.
I think it was a combination of settings that allowed dhcp. Cause when
we disabled dhcp in the web i/f and tried to create a udhcpd.conf
file it simply refused to run on ANY interface. It
was working fine for WLAN, not OLSR, because if I'm not mistaken,
there's a different interface for OLSR, bridged with the actual
WLAN interface. The DHCP server was running on the WLAN interface
rather than the OLSR interface.
The OLSR i/f is for the backbone routing. running dhcp on this will
open a new can of worms requiring dhcp forwarding etc. There is
provision. I did the last time. Edit the
/etc/local.udhcpd.conf file. Either that or something similar. It
allows you to run DHCP on any interface.
Trust u not to remember ;-). We tried to replicate what u did but
could not. afaik what u did was right but we were unable to
repeat it. Which
makes it a chance occurence or your own brand of witchcraft ;-) or
we were stupid - but i am sure that it's not the case.
It definitely isn't.
> Can someone please post the ifconfig output on
the
> `server'? Server being the wireless router connected to the
> internet directly through its WAN port.
Hmmm. That one still stands..
--
----------------------------------------
Mrugesh Karnik
GPG Key 0xBA6F1DA8
Public key on http://wwwkeys.pgp.net
----------------------------------------
6:52 p.m.
On Tuesday 10 April 2007 18:16, Mrugesh Karnik wrote:
Well take a look at the init script /etc/init.d/udhcpd. There's a
section towards the end where it populates the /etc/udhcpd.conf
file with a here document. You'll see that it sources the file
/etc/local.something at the end of the here document. This is the
file where the manual configuration goes. In the udhcpd.conf, there
comes up a comment saying `local settings go after this' or
something. The sourced local file is reproduced there, right below
the default config section.
Ok. so that is where u put the settings rather than changing the
initial default interface.
On Tuesday 10 Apr 2007 12:30:50 jtd wrote:
Agreed. It needs to run the DHCP server on the wired LAN ports.
That's the default setting. You can add one additional interface
through the local config file. Which is what I had done.
Aha. But why not only on the wireless lan?.
It does.
I had set it up and it was working properly on 31st.
I think it was a combination of settings that allowed dhcp. Cause
when we disabled dhcp in the web i/f and tried to create a
udhcpd.conf file it simply refused to run on ANY interface.
The init scripts are a kind of weird.
Hmmmm. Now I'm royally confused. Which interface does dnsmasq
listen to, in the working mesh? From what Dr. Nagarjuna said, there
was a parameter called `OLSR-DHCP'. I assumed that that corresponds
to the OLSR interface. I assumed wrong it seems :s So if I'm wrong,
I guess OLSR handles the `cascaded' DHCP requests properly with
dnsmasq listening to the WLAN interface?
I am confused. Looks like we have to have a close look at "OLSR-DHCP".
Because having OLSR and wlan in the same subnet seems just not right,
cause u are reducing the number of nodes or clients, a completely
unneccessary trade off.
It
was working fine for WLAN, not OLSR, because if I'm not
mistaken, there's a different interface for OLSR, bridged with
the actual WLAN interface. The DHCP server was running on the
WLAN interface rather than the OLSR interface.
The OLSR i/f is for the backbone routing. running dhcp on this
will open a new can of worms requiring dhcp forwarding etc. There is provision. I did the last time. Edit the
/etc/local.udhcpd.conf file. Either that or something similar.
It allows you to run DHCP on any interface.
Trust u not to remember ;-). We tried to replicate what u did but
could not. > afaik what u did was right but we were unable to
repeat it. Which
> makes it a chance occurence or your own brand of witchcraft ;-)
> or we were stupid - but i am sure that it's not the case.
Well we were stupid. We should have put the local settings right where
it said we should - at the end of the conf file. Never trust oneself.
It definitely isn't.
Ya. Looks like we gotta go to HBCSE once more to look things up
thoroughly.
--
Rgds
JTD
> Can someone please post the ifconfig output
on the
> `server'? Server being the wireless router connected to the
> internet directly through its WAN port.
Hmmm. That one still stands..
7:52 p.m.
On Tuesday 10 Apr 2007 18:52:17 jtd wrote:
Aha. But why not only on the wireless lan?.
Bug.
Hehhe. I'm really really confused. We need to go back and take a look at the
setup again. I'll try to read up on how OLSR works too.
Nope. That's where I found out about the local config file. Actually, the
aforementioned bug may be corrected by correcting the init script.
Ya. Looks like we gotta go to HBCSE once more to look things up
thoroughly.
Yup.
--
----------------------------------------
Mrugesh Karnik
GPG Key 0xBA6F1DA8
Public key on http://wwwkeys.pgp.net
----------------------------------------
I think it was a combination of settings that allowed
dhcp. Cause
when we disabled dhcp in the web i/f and tried to create a
udhcpd.conf file it simply refused to run on ANY interface.
Agreed. It needs to run the DHCP server on the wired LAN ports.
That's the default setting. You can add one additional interface
through the local config file. Which is what I had done. Hmmmm. Now
I'm royally confused. Which interface does dnsmasq
listen to, in the working mesh? From what Dr. Nagarjuna said, there
was a parameter called `OLSR-DHCP'. I assumed that that corresponds
to the OLSR interface. I assumed wrong it seems :s So if I'm wrong,
I guess OLSR handles the `cascaded' DHCP requests properly with
dnsmasq listening to the WLAN interface?
I am confused. Looks like we have to have a close look at "OLSR-DHCP".
Because having OLSR and wlan in the same subnet seems just not right,
cause u are reducing the number of nodes or clients, a completely
unneccessary trade off. Well take a
look at the init script /etc/init.d/udhcpd. There's a
section towards the end where it populates the /etc/udhcpd.conf
file with a here document. You'll see that it sources the file
/etc/local.something at the end of the here document. This is the
file where the manual configuration goes. In the udhcpd.conf, there
comes up a comment saying `local settings go after this' or
something. The sourced local file is reproduced there, right below
the default config section.
Ok. so that is where u put the settings rather than changing the
initial default interface. Well we were stupid. We should have put the local
settings right where
it said we should - at the end of the conf file. Never trust oneself.
Actually no. I tried that, but the udhcpd.conf gets overwritten by the init
script. So I went on to read up the script and found the local config file.
> Can someone please post the ifconfig output on
the
> `server'? Server being the wireless router connected to the
> internet directly through its WAN port.
Hmmm. That one still stands..
2:25 p.m.
Mrugesh Karnik wrote:
On Monday 09 Apr 2007 17:57:32 Nagarjuna G. wrote:
What you are saying and what you did last time are correct. Without the
package we can achieve what we wanted. But instead of making changes on
each node, they made it simpler by making an addon package, and also
helping the dumb users to specify the dhcp range of wlan by providing
OLSR-DHCP. It was not an add on package for an older freifunk firmware,
but only in the current one. I guess they did it for space reasons, for
you cant make the firmware bigger after a limit. I dont know if they
have other reasons.
Nagarjuna
installed a package called
'freifunk-dnsmasq', restarted it. Now we see
an additional parameter on the web interface called OLSR-DHCP: This is
where we give the DHCP share of the mesh network (not the lan network).
thats it.
I need some details.
This entire thing now works only on the WLAN interface right? Is the LAN
completely out of the picture? So, the backend itself gets broadened? Maybe
subnetted, depending on the DHCP server(s).
Secondly, without the dnsmasq package, can we get the native udhcpd to work
with the OLSR interface? I think we can.. What's the OLSR interface that
shows up with ifconfig? It is possible, I think, to manually configure the
DHCP server to listen on the OLSR interface.
The problem, I think, wasn't with the missing package, but with the fact that
we had DHCP running on the WLAN interface instead of the OLSR interface. The
native DHCP should work perfectly fine if I'm right... unless dnsmasq has
some features I don't know about..
6:23 p.m.
On Tuesday 10 Apr 2007 14:25:54 Nagarjuna G. wrote:
Hmmm. How was the additional package installed?
And of course, it is easier to do it this `new' way, but I'm just wondering
what went wrong that it wasn't working with the old firmware. I guess the
manual way should work fine with the new firmware as well, so it'll be good
to have a fallback, in case something goes wrong with the dnsmasq way.
Then again, the problem is in getting it to work manually.
--
----------------------------------------
Mrugesh Karnik
GPG Key 0xBA6F1DA8
Public key on http://wwwkeys.pgp.net
----------------------------------------
The problem, I
think, wasn't with the missing package, but with the fact
that we had DHCP running on the WLAN interface instead of the OLSR
interface. The native DHCP should work perfectly fine if I'm right...
unless dnsmasq has some features I don't know about..
What you are saying and what you did last time are correct. Without the
package we can achieve what we wanted. But instead of making changes on
each node, they made it simpler by making an addon package, and also
helping the dumb users to specify the dhcp range of wlan by providing
OLSR-DHCP. It was not an add on package for an older freifunk firmware,
but only in the current one. I guess they did it for space reasons, for
you cant make the firmware bigger after a limit. I dont know if they
have other reasons.
7:54 p.m.
On Tuesday 10 Apr 2007 18:54:18 jtd wrote:
On Tuesday 10 April 2007 18:23, Mrugesh Karnik wrote:
I don't really like clicking. I'd prefer typing/editing with a text editor
anytime! At least I'll get to know exactly what is happening, never mind the
`pain' involved. Knowledge rocks :P
--
----------------------------------------
Mrugesh Karnik
GPG Key 0xBA6F1DA8
Public key on http://wwwkeys.pgp.net
----------------------------------------
Then again, the problem is in getting it to work
manually.
That is very important. Imagine clicking you way thru few tens of aps.
11:42 p.m.
Mrugesh Karnik wrote:
I don't really like clicking. I'd prefer typing/editing with a text editor
anytime! At least I'll get to know exactly what is happening, never mind the
`pain' involved. Knowledge rocks :P
Thats true but for production and easy implementation of community
meshes by many volunteers, it is necessary to streamline the process
with a working GUI.
--
Regards,
Rony.
11 Apr
11 Apr
12:01 a.m.
On 4/10/07, Mrugesh Karnik <mrugeshkarnik(a)gmail.com> wrote:
Hmmm. How was the additional package installed?
#ipkg update
#ipkg install 'package-name'
very simple. If the router is not connected to the net, we can scp
the package file and install it too.
Nagarjuna
10 Apr
10 Apr
noon
On Monday 09 April 2007 17:57, Nagarjuna G. wrote:
Hi all, particularly those who attended the workshop
on 31st March
and 1st April, and last saturday Rony, Jtd resumed the work.
Status:
The dhcp on wireless was not working as of Saturday, but today
afternoon I tried based on a reply from the olsr-users mailing
list. Again it worked out of the box.
Great ;-)).
What I did:
installed a package called 'freifunk-dnsmasq', restarted it. Now
we see an additional parameter on the web interface called
OLSR-DHCP: This is where we give the DHCP share of the mesh
network (not the lan network). thats it.
We must tell the freifunk guys to inclue this module as default. I
reall wonder how can anyone connect without dhcp.
Now we have a working mesh in the campus. I will
write
documentation here: http://fci.wikia.com/wiki/WirelessMesh. Please
add to everything I missed out. I will also upload few screen
shots so that new teams setting it up will find it useful.
Next step:
Prepare a server (Rony contributed a server)
And do voip. we can use ohphone and asterisk.
and dump useful resources there for community use.
Etch for one. Ubuntu, knoppix. Should we sync to a debian repository.
--
Rgds
JTD
11:26 p.m.
Nagarjuna G. wrote:
jtd wrote:
We could meet on Saturday to do the dumping. I got a small collection of
DVDs. I got Kubuntu 6.10 DVD iso too.
--
Regards,
Rony.
Etch for one. Ubuntu, knoppix. Should we sync to a debian repository.
if any of you already downloaded them, please dump them on the server.
particularly if it is a dvd.. for a cd, we can dowload again.
11 Apr
11 Apr
10:22 p.m.
Nagarjuna G. wrote:
Now we have a working mesh in the campus. I will write documentation
here: http://fci.wikia.com/wiki/WirelessMesh. Please add to everything
I missed out. I will also upload few screen shots so that new teams
setting it up will find it useful.
I have updated the http://fci.wikia.com/wiki/WirelessMesh. JTD and
Nagarjuna, please check it out and update missing links, information.
--
Regards,
Rony.
10:54 p.m.
On 4/11/07, Rony <ronbillypop(a)yahoo.co.uk> wrote:
Nagarjuna G. wrote:
Let us also add the links that helped us to solve the problem.
Nagarjuna
Now we have a working mesh in the campus. I will write documentation
here: http://fci.wikia.com/wiki/WirelessMesh. Please add to everything
I missed out. I will also upload few screen shots so that new teams
setting it up will find it useful.
I have updated the http://fci.wikia.com/wiki/WirelessMesh. JTD and
Nagarjuna, please check it out and update missing links, information.
6082
days inactive
6084
days old
20 comments
4 participants
participants (4)
-
jtd -
Mrugesh Karnik -
Nagarjuna G. -
Rony