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@hbcse.tifr.res.in. we will download them during the night time and leave it one the server.
Nagarjuna
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. :)
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 wrote:
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).
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.
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.
On Tuesday 10 Apr 2007 01:21:14 Rony 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.
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.
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.
On Tuesday 10 April 2007 11:55, Mrugesh Karnik wrote:
On Tuesday 10 Apr 2007 01:21:14 Rony 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.
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.
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.
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.
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
On Tuesday 10 Apr 2007 12:30:50 jtd wrote:
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.
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.
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.
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?
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.
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.
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..
On Tuesday 10 April 2007 18:16, Mrugesh Karnik wrote:
On Tuesday 10 Apr 2007 12:30:50 jtd wrote:
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.
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?.
The init scripts are a kind of weird.
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.
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.
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.
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.
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.
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..
Ya. Looks like we gotta go to HBCSE once more to look things up thoroughly.
On Tuesday 10 Apr 2007 18:52:17 jtd 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.
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?.
Bug.
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.
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.
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.
Nope. That's where I found out about the local config file. Actually, the aforementioned bug may be corrected by correcting the init script.
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..
Ya. Looks like we gotta go to HBCSE once more to look things up thoroughly.
Yup.
Mrugesh Karnik wrote:
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..
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
On Tuesday 10 Apr 2007 14:25:54 Nagarjuna G. wrote:
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.
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.
On Tuesday 10 Apr 2007 18:54:18 jtd wrote:
On Tuesday 10 April 2007 18:23, Mrugesh Karnik wrote:
Then again, the problem is in getting it to work manually.
That is very important. Imagine clicking you way thru few tens of aps.
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 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.
On 4/10/07, Mrugesh Karnik mrugeshkarnik@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
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.
Nagarjuna G. wrote:
jtd wrote:
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.
We could meet on Saturday to do the dumping. I got a small collection of DVDs. I got Kubuntu 6.10 DVD iso too.
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.
On 4/11/07, Rony ronbillypop@yahoo.co.uk wrote:
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.
Let us also add the links that helped us to solve the problem.
Nagarjuna
-
jtd -
Mrugesh Karnik -
Nagarjuna G. -
Rony