[B.A.T.M.A.N.] [PATCH] Make batman timer functions thread safe

[B.A.T.M.A.N.] [PATCH] Make batman timer functions thread safe

[Sven Eckelmann]

The calculation inside of update_internal_clock aren't atomic and can lead to
bogus time informations when many threads calling get_time_msec64 or
get_time_msec.

Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
---
 batman/posix/posix.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/batman/posix/posix.c b/batman/posix/posix.c
index dd24a65..042a2b9 100644
--- a/batman/posix/posix.c
+++ b/batman/posix/posix.c
@@ -49,6 +49,7 @@ static float system_tick;
 
 uint8_t tunnel_running = 0;
 
+static pthread_mutex_t batman_clock_mutex = PTHREAD_MUTEX_INITIALIZER;
 
 void update_internal_clock()
 {
@@ -61,14 +62,26 @@ void update_internal_clock()
 
 uint32_t get_time_msec()
 {
+	uint32_t time;
+
+	pthread_mutex_lock(&batman_clock_mutex);
 	update_internal_clock();
-	return (uint32_t)(((float)(batman_clock_ticks) * 1000) / system_tick);
+	time = (uint32_t)(((float)(batman_clock_ticks) * 1000) / system_tick);
+	pthread_mutex_unlock(&batman_clock_mutex);
+
+	return time;
 }
 
 uint64_t get_time_msec64()
 {
+	uint64_t time;
+
+	pthread_mutex_lock(&batman_clock_mutex);
 	update_internal_clock();
-	return (uint64_t)(((float)(batman_clock_ticks) * 1000) / system_tick);
+	time = (uint64_t)(((float)(batman_clock_ticks) * 1000) / system_tick);
+	pthread_mutex_unlock(&batman_clock_mutex);
+
+	return time;
 }
 
 /* batman animation */
-- 
1.6.0.1

Re: [B.A.T.M.A.N.] [PATCH] Make batman timer functions thread safe

[Marek Lindner]

On Saturday, 13. September 2008 07:24:20 Sven Eckelmann wrote:
> The calculation inside of update_internal_clock aren't atomic and can lead
> to bogus time informations when many threads calling get_time_msec64 or
> get_time_msec.

Just applied your latest patches as well. Thanks for looking over the code. 
Virgin eyes stumble easier over nasty stuff.  :-)

Greetings,
Marek

Re: [B.A.T.M.A.N.] [PATCH] Make batman timer functions thread safe

[freifunk]

Hi,

> Just applied your latest patches as well. Thanks for looking over the
> code.
> Virgin eyes stumble easier over nasty stuff.  :-)
>

When you find some problems in batman, can you also apply those patches to
the batman-experimental branch? At moment it is running without problems for
freifunk dresden. But if the network is growing perhaps some issues may
cause problems.

Bye
 Stephan

---------------------------------------
Dipl.Informatiker(FH) Stephan Enderlein
Freifunk Dresden

Re: [B.A.T.M.A.N.] [PATCH] Make batman timer functions thread safe

[Marek Lindner]

On Monday, 15. September 2008 16:28:19 freifunk@ddmesh.de wrote:
> When you find some problems in batman, can you also apply those patches to
> the batman-experimental branch? At moment it is running without problems
> for freifunk dresden. But if the network is growing perhaps some issues may
> cause problems.

It seems we are lacking a maintainer for this code at the moment. Are you 
interesting in doing that job ? I would have no problem with that. 
Of course, we should ask Axel first but I don't see why he would not agree. 

Greetings,
Marek

Re: [B.A.T.M.A.N.] [PATCH] Make batman timer functions thread safe

[Axel Neumann]

Hi

On Montag 15 September 2008, freifunk@ddmesh.de wrote:
> Hi,
>
> > Just applied your latest patches as well. Thanks for looking over the
> > code.
> > Virgin eyes stumble easier over nasty stuff.  :-)
>
> When you find some problems in batman, can you also apply those patches to
> the batman-experimental branch? At moment it is running without problems
> for freifunk dresden. But if the network is growing perhaps some issues may
> cause problems.

Over the time a reasonable part of the code structure of bmx and batman has 
forked pretty much. Therefore I am not sure if it would be easy to simply 
apply existing batman patches to the bmx branch. But be sure, whenever I am 
getting aware of critical bugs identified in the batman code which also apply 
to the bmx code, I'll fix them too. But for many current and older series of 
patches its simply not necessary. For example looking at the main recent 
bug-fixes

Regarding the debug thread:
I have removed the debug thread completely about 2 weeks ago (due to ongoing 
problems with this thing) and integrated its functionality into the main 
thread. I could not see any benefit of having this threaded except constant 
syncronization problems. Unfortunately I could not commit it yet because of 
unfinished testing. But I'll do it this week.

The gw-kernel module: There are no gw-tunnel module problems with bmx simply 
because there is no support for this feature. Most existing bmx-mesh networks 
I am aware of are using the one-way-tunnel mode. It does not implement the 
black hole detection but still allows you to dynamically change the preferred 
gw. Compared to the two-way-tunnel it has less overhead, avoids tunneling 
from the gw to the client node (no need to optimize something which does not 
exist) and allows internet access with only one level of network address 
translation.  

Packet aggregation:
Have been implemented and activated by default in bmx about a year ago and 
seem to work quite reliable since then.

Problem with timing issues have been solved individually

And very important. BMX has continued to rely on the concept of a rolling 
metric based on the number of received OGMs via the best path. Many patches 
in the batman-0.3 brach were due to changing this concept to a dedicated 
metric field carried with each OGM.


By the way, I think a number of bugs in bmx and batman have been identified 
due to your hints. Thanks for that. If you want to intensify your work on the 
code and want commit patches directly just let us know.




>
> Bye
>  Stephan
>
> ---------------------------------------
> Dipl.Informatiker(FH) Stephan Enderlein
> Freifunk Dresden
>
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Re: [B.A.T.M.A.N.] [PATCH] Make batman timer functions thread safe

[Stephan Enderlein (Freifunk Dresden)]

Hi Axel,

thanks for your comments. At moment I have no much time to spend for
batman development. We got a son two month ago and I'm currently enjoy
him much.
But I have a good idea concerning the routing script.
The problem is that I like batman-exp to setup all routes as defined by
parameters, but also want batman-exp to call the script.
Batman may call the script twice. One call before and one after setting
the routes. All should depend on the return code of the first call of the
script.
If the script returns "0", then batman should not set routes and also
there is no need to call the script a second time.
If the first call of the script returns "1", then batman should set the
routes as defined by parameters and after it should call the script a
second time (like pre/post scripts).

This allows me to get the routing information without need to setup all
routings per hand.
Bye setting a environment variable you can distingnuish if the script is
called as pre or post script.
This leads to the next solution/patch:

You should also add information about the gateway
selection/changes/deselection to this script. Together with the
modification above you can let batmand set the routes and update your
resolv.conf to find the correct router that knows how to resolve dns
requests.
At moment you have to get the dns ip from dhcp or you should enter this
as a fix value. But a fix value for this is bad if you build a firmware
with a simple user interface. Many people don't know how dns works and
what ip they should enter. If you have different ISP some dns server are
not
accessible.

At moment I have added my own patch where I call (system("gateway_scirpt"))
each time the gateway tunnel is created or deleted. this is working
perfectly.

/Stephan


> Hi
>
> On Montag 15 September 2008, freifunk@ddmesh.de wrote:
>> Hi,
>>
>> > Just applied your latest patches as well. Thanks for looking over the
>> > code.
>> > Virgin eyes stumble easier over nasty stuff.  :-)
>>
>> When you find some problems in batman, can you also apply those patches
>> to
>> the batman-experimental branch? At moment it is running without problems
>> for freifunk dresden. But if the network is growing perhaps some issues
>> may
>> cause problems.
>
> Over the time a reasonable part of the code structure of bmx and batman
> has
> forked pretty much. Therefore I am not sure if it would be easy to simply
> apply existing batman patches to the bmx branch. But be sure, whenever I
> am
> getting aware of critical bugs identified in the batman code which also
> apply
> to the bmx code, I'll fix them too. But for many current and older series
> of
> patches its simply not necessary. For example looking at the main recent
> bug-fixes
>
> Regarding the debug thread:
> I have removed the debug thread completely about 2 weeks ago (due to
> ongoing
> problems with this thing) and integrated its functionality into the main
> thread. I could not see any benefit of having this threaded except
> constant
> syncronization problems. Unfortunately I could not commit it yet because
> of
> unfinished testing. But I'll do it this week.
>
> The gw-kernel module: There are no gw-tunnel module problems with bmx
> simply
> because there is no support for this feature. Most existing bmx-mesh
> networks
> I am aware of are using the one-way-tunnel mode. It does not implement the
> black hole detection but still allows you to dynamically change the
> preferred
> gw. Compared to the two-way-tunnel it has less overhead, avoids tunneling
> from the gw to the client node (no need to optimize something which does
> not
> exist) and allows internet access with only one level of network address
> translation.
>
> Packet aggregation:
> Have been implemented and activated by default in bmx about a year ago and
> seem to work quite reliable since then.
>
> Problem with timing issues have been solved individually
>
> And very important. BMX has continued to rely on the concept of a rolling
> metric based on the number of received OGMs via the best path. Many
> patches
> in the batman-0.3 brach were due to changing this concept to a dedicated
> metric field carried with each OGM.
>
>
> By the way, I think a number of bugs in bmx and batman have been
> identified
> due to your hints. Thanks for that. If you want to intensify your work on
> the
> code and want commit patches directly just let us know.
>
>
>
>
>>
>> Bye
>>  Stephan
>>
>> ---------------------------------------
>> Dipl.Informatiker(FH) Stephan Enderlein
>> Freifunk Dresden
>>
>>
>> _______________________________________________
>> B.A.T.M.A.N mailing list
>> B.A.T.M.A.N@open-mesh.net
>> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>


---------------------------------------
Dipl.Informatiker(FH) Stephan Enderlein
Freifunk Dresden

Re: [B.A.T.M.A.N.] policy-routing-script issues

[Axel Neumann]

Hi,

I can understand your need and agree that your idea with the return value 
makes the hole thing very flexible. But i am not sure if it makes sense to 
call the policy routing script even more than once because system calls like 
that can be quite expensive. And another problem i see comes with the return 
values itself.  Currently the policy-routing feature is not aware of the 
return value of the called script. One reason for this is that the 
policy-routing-script is essentially operating in a loop waiting to be feeded 
with new commands via a pipe. Therefore the script itself does not terminate 
after being feeded and does not return anything. Another problem is that the 
C-function execv() (which is currently used) does not really support return 
values except in case of an error. As you suggested, the function system() 
could be used instead, but the manpage suggests to not use this function with 
suid privileges. 

Regarding the cost (in terms of processing-time) i did some small experiences 
on a netgear wgt634u and a linksys WRT with openwrt which showed that 
configuring a route via a bash script (using the ip command) or by using 
system() to execute the ip command is up to 50 times more expensive than 
doing it directly (using netlink sockets).
In my test adding and removing 100 route entries using netlink sockets took 
about 200ms while using the ip command it takes about 6-10 seconds.
Even just calling a script with system() which does nothing else than return 0 
takes about 50ms per call. 

Therefore I am not sure if using the policy routing script in a large network 
and with slow devices is a good idea at all. And if the threat must be 
blocked during the execution of the script to wait for the return value it 
would be even worse. 

What about introducing the possibility to define that the routing information 
which is forwarded to the policy routing script is only informative and is 
still applied by the daemon itself?

ciao,
axel


On Donnerstag 18 September 2008, Stephan Enderlein (Freifunk Dresden) wrote:
> Hi Axel,
>
> thanks for your comments. At moment I have no much time to spend for
> batman development. We got a son two month ago and I'm currently enjoy
> him much.
> But I have a good idea concerning the routing script.
> The problem is that I like batman-exp to setup all routes as defined by
> parameters, but also want batman-exp to call the script.
> Batman may call the script twice. One call before and one after setting
> the routes. All should depend on the return code of the first call of the
> script.
> If the script returns "0", then batman should not set routes and also
> there is no need to call the script a second time.
> If the first call of the script returns "1", then batman should set the
> routes as defined by parameters and after it should call the script a
> second time (like pre/post scripts).
>
> This allows me to get the routing information without need to setup all
> routings per hand.
> Bye setting a environment variable you can distingnuish if the script is
> called as pre or post script.
> This leads to the next solution/patch:
>
> You should also add information about the gateway
> selection/changes/deselection to this script. Together with the
> modification above you can let batmand set the routes and update your
> resolv.conf to find the correct router that knows how to resolve dns
> requests.
> At moment you have to get the dns ip from dhcp or you should enter this
> as a fix value. But a fix value for this is bad if you build a firmware
> with a simple user interface. Many people don't know how dns works and
> what ip they should enter. If you have different ISP some dns server are
> not
> accessible.
>
> At moment I have added my own patch where I call (system("gateway_scirpt"))
> each time the gateway tunnel is created or deleted. this is working
> perfectly.
>
> /Stephan
>
> > Hi
> >
> > On Montag 15 September 2008, freifunk@ddmesh.de wrote:
> >> Hi,
> >>
> >> > Just applied your latest patches as well. Thanks for looking over the
> >> > code.
> >> > Virgin eyes stumble easier over nasty stuff.  :-)
> >>
> >> When you find some problems in batman, can you also apply those patches
> >> to
> >> the batman-experimental branch? At moment it is running without problems
> >> for freifunk dresden. But if the network is growing perhaps some issues
> >> may
> >> cause problems.
> >
> > Over the time a reasonable part of the code structure of bmx and batman
> > has
> > forked pretty much. Therefore I am not sure if it would be easy to simply
> > apply existing batman patches to the bmx branch. But be sure, whenever I
> > am
> > getting aware of critical bugs identified in the batman code which also
> > apply
> > to the bmx code, I'll fix them too. But for many current and older series
> > of
> > patches its simply not necessary. For example looking at the main recent
> > bug-fixes
> >
> > Regarding the debug thread:
> > I have removed the debug thread completely about 2 weeks ago (due to
> > ongoing
> > problems with this thing) and integrated its functionality into the main
> > thread. I could not see any benefit of having this threaded except
> > constant
> > syncronization problems. Unfortunately I could not commit it yet because
> > of
> > unfinished testing. But I'll do it this week.
> >
> > The gw-kernel module: There are no gw-tunnel module problems with bmx
> > simply
> > because there is no support for this feature. Most existing bmx-mesh
> > networks
> > I am aware of are using the one-way-tunnel mode. It does not implement
> > the black hole detection but still allows you to dynamically change the
> > preferred
> > gw. Compared to the two-way-tunnel it has less overhead, avoids tunneling
> > from the gw to the client node (no need to optimize something which does
> > not
> > exist) and allows internet access with only one level of network address
> > translation.
> >
> > Packet aggregation:
> > Have been implemented and activated by default in bmx about a year ago
> > and seem to work quite reliable since then.
> >
> > Problem with timing issues have been solved individually
> >
> > And very important. BMX has continued to rely on the concept of a rolling
> > metric based on the number of received OGMs via the best path. Many
> > patches
> > in the batman-0.3 brach were due to changing this concept to a dedicated
> > metric field carried with each OGM.
> >
> >
> > By the way, I think a number of bugs in bmx and batman have been
> > identified
> > due to your hints. Thanks for that. If you want to intensify your work on
> > the
> > code and want commit patches directly just let us know.
> >
> >> Bye
> >>  Stephan
> >>
> >> ---------------------------------------
> >> Dipl.Informatiker(FH) Stephan Enderlein
> >> Freifunk Dresden
> >>
> >>
> >> _______________________________________________
> >> B.A.T.M.A.N mailing list
> >> B.A.T.M.A.N@open-mesh.net
> >> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
> >
> > _______________________________________________
> > B.A.T.M.A.N mailing list
> > B.A.T.M.A.N@open-mesh.net
> > https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>
> ---------------------------------------
> Dipl.Informatiker(FH) Stephan Enderlein
> Freifunk Dresden
>
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Re: [B.A.T.M.A.N.] policy-routing-script issues

[Stephan Enderlein (Freifunk Dresden)]

Hi Axel,

sorry for the late response. I missed the email and found it today.
I understand your concerns and agree with that.
The reason for all this was to get the information on every gateway change.
I need the node ip of the gateway node at the time when the gateway is selected
or deselected. At moment I have modified the batmand to call a script in both
cases to setup /etc/resolv.conf which is important to always have a valid dns
server. the main publich dns servers often are not accessible from different
provider networks.

/stephan

> Hi,
>
> I can understand your need and agree that your idea with the return value
> makes the hole thing very flexible. But i am not sure if it makes sense to
> call the policy routing script even more than once because system calls like
> that can be quite expensive. And another problem i see comes with the return
> values itself.  Currently the policy-routing feature is not aware of the
> return value of the called script. One reason for this is that the
> policy-routing-script is essentially operating in a loop waiting to be feeded
> with new commands via a pipe. Therefore the script itself does not terminate
> after being feeded and does not return anything. Another problem is that the
> C-function execv() (which is currently used) does not really support return
> values except in case of an error. As you suggested, the function system()
> could be used instead, but the manpage suggests to not use this function with
> suid privileges.
>
> Regarding the cost (in terms of processing-time) i did some small experiences
> on a netgear wgt634u and a linksys WRT with openwrt which showed that
> configuring a route via a bash script (using the ip command) or by using
> system() to execute the ip command is up to 50 times more expensive than
> doing it directly (using netlink sockets).
> In my test adding and removing 100 route entries using netlink sockets took
> about 200ms while using the ip command it takes about 6-10 seconds.
> Even just calling a script with system() which does nothing else than return 0
> takes about 50ms per call.
>
> Therefore I am not sure if using the policy routing script in a large network
> and with slow devices is a good idea at all. And if the threat must be
> blocked during the execution of the script to wait for the return value it
> would be even worse.
>
> What about introducing the possibility to define that the routing information
> which is forwarded to the policy routing script is only informative and is
> still applied by the daemon itself?
>
> ciao,
> axel
>
>
> On Donnerstag 18 September 2008, Stephan Enderlein (Freifunk Dresden) wrote:
>> Hi Axel,
>>
>> thanks for your comments. At moment I have no much time to spend for
>> batman development. We got a son two month ago and I'm currently enjoy
>> him much.
>> But I have a good idea concerning the routing script.
>> The problem is that I like batman-exp to setup all routes as defined by
>> parameters, but also want batman-exp to call the script.
>> Batman may call the script twice. One call before and one after setting
>> the routes. All should depend on the return code of the first call of the
>> script.
>> If the script returns "0", then batman should not set routes and also
>> there is no need to call the script a second time.
>> If the first call of the script returns "1", then batman should set the
>> routes as defined by parameters and after it should call the script a
>> second time (like pre/post scripts).
>>
>> This allows me to get the routing information without need to setup all
>> routings per hand.
>> Bye setting a environment variable you can distingnuish if the script is
>> called as pre or post script.
>> This leads to the next solution/patch:
>>
>> You should also add information about the gateway
>> selection/changes/deselection to this script. Together with the
>> modification above you can let batmand set the routes and update your
>> resolv.conf to find the correct router that knows how to resolve dns
>> requests.
>> At moment you have to get the dns ip from dhcp or you should enter this
>> as a fix value. But a fix value for this is bad if you build a firmware
>> with a simple user interface. Many people don't know how dns works and
>> what ip they should enter. If you have different ISP some dns server are
>> not
>> accessible.
>>
>> At moment I have added my own patch where I call (system("gateway_scirpt"))
>> each time the gateway tunnel is created or deleted. this is working
>> perfectly.
>>
>> /Stephan
>>
>> > Hi
>> >
>> > On Montag 15 September 2008, freifunk@ddmesh.de wrote:
>> >> Hi,
>> >>
>> >> > Just applied your latest patches as well. Thanks for looking over the
>> >> > code.
>> >> > Virgin eyes stumble easier over nasty stuff.  :-)
>> >>
>> >> When you find some problems in batman, can you also apply those patches
>> >> to
>> >> the batman-experimental branch? At moment it is running without problems
>> >> for freifunk dresden. But if the network is growing perhaps some issues
>> >> may
>> >> cause problems.
>> >
>> > Over the time a reasonable part of the code structure of bmx and batman
>> > has
>> > forked pretty much. Therefore I am not sure if it would be easy to simply
>> > apply existing batman patches to the bmx branch. But be sure, whenever I
>> > am
>> > getting aware of critical bugs identified in the batman code which also
>> > apply
>> > to the bmx code, I'll fix them too. But for many current and older series
>> > of
>> > patches its simply not necessary. For example looking at the main recent
>> > bug-fixes
>> >
>> > Regarding the debug thread:
>> > I have removed the debug thread completely about 2 weeks ago (due to
>> > ongoing
>> > problems with this thing) and integrated its functionality into the main
>> > thread. I could not see any benefit of having this threaded except
>> > constant
>> > syncronization problems. Unfortunately I could not commit it yet because
>> > of
>> > unfinished testing. But I'll do it this week.
>> >
>> > The gw-kernel module: There are no gw-tunnel module problems with bmx
>> > simply
>> > because there is no support for this feature. Most existing bmx-mesh
>> > networks
>> > I am aware of are using the one-way-tunnel mode. It does not implement
>> > the black hole detection but still allows you to dynamically change the
>> > preferred
>> > gw. Compared to the two-way-tunnel it has less overhead, avoids tunneling
>> > from the gw to the client node (no need to optimize something which does
>> > not
>> > exist) and allows internet access with only one level of network address
>> > translation.
>> >
>> > Packet aggregation:
>> > Have been implemented and activated by default in bmx about a year ago
>> > and seem to work quite reliable since then.
>> >
>> > Problem with timing issues have been solved individually
>> >
>> > And very important. BMX has continued to rely on the concept of a rolling
>> > metric based on the number of received OGMs via the best path. Many
>> > patches
>> > in the batman-0.3 brach were due to changing this concept to a dedicated
>> > metric field carried with each OGM.
>> >
>> >
>> > By the way, I think a number of bugs in bmx and batman have been
>> > identified
>> > due to your hints. Thanks for that. If you want to intensify your work on
>> > the
>> > code and want commit patches directly just let us know.
>> >
>> >> Bye
>> >>  Stephan
>> >>
>> >> ---------------------------------------
>> >> Dipl.Informatiker(FH) Stephan Enderlein
>> >> Freifunk Dresden
>> >>
>> >>
>> >> _______________________________________________
>> >> B.A.T.M.A.N mailing list
>> >> B.A.T.M.A.N@open-mesh.net
>> >> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>> >
>> > _______________________________________________
>> > B.A.T.M.A.N mailing list
>> > B.A.T.M.A.N@open-mesh.net
>> > https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>>
>> ---------------------------------------
>> Dipl.Informatiker(FH) Stephan Enderlein
>> Freifunk Dresden
>>
>>
>> _______________________________________________
>> B.A.T.M.A.N mailing list
>> B.A.T.M.A.N@open-mesh.net
>> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>


---------------------------------------
Dipl.Informatiker(FH) Stephan Enderlein
Freifunk Dresden

Re: [B.A.T.M.A.N.] policy-routing-script issues

[Bastian Bittorf]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

* Stephan Enderlein (Freifunk Dresden) <freifunk@ddmesh.de> [18.12.2008 12:30]:

> server. the main publich dns servers often are not accessible from different
> provider networks.

Please give an example: which dns server is n/a from which provider?
(i think it's an urban legend...)

bye, Bastian /weimarnetz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [B.A.T.M.A.N.] policy-routing-script issues

[Stephan Enderlein (Freifunk Dresden)]

Hi,

> Please give an example: which dns server is n/a from which provider?
> (i think it's an urban legend...)
I have seen this here in dresden with telekom and arcor dns servers. I used the dns server
from telekom that we got while connecting via DSL. This is not working if the router that offers
internet connection is connected to VDSL or Alice. I could use DNS server of acor for the
router that was connected to the VDSL.
But as you can not predict which gateway is used, you must habe a different solution.
I therefore use a script that always set the dns server to the router ip that currently is used
as gateway. The router ensures that dns is working.

/Stephan

---------------------------------------
Dipl.Informatiker(FH) Stephan Enderlein
Freifunk Dresden

Re: [B.A.T.M.A.N.] policy-routing-script issues

[Gustavo Lindberg]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

2008/12/19 Stephan Enderlein (Freifunk Dresden) <freifunk@ddmesh.de>

> Hi,
>
> > Please give an example: which dns server is n/a from which provider?
> > (i think it's an urban legend...)
> I have seen this here in dresden with telekom and arcor dns servers. I used
> the dns server
> from telekom that we got while connecting via DSL. This is not working if
> the router that offers
> internet connection is connected to VDSL or Alice. I could use DNS server
> of acor for the
> router that was connected to the VDSL.
> But as you can not predict which gateway is used, you must habe a different
> solution.
> I therefore use a script that always set the dns server to the router ip
> that currently is used
> as gateway. The router ensures that dns is working.
>

Might find useful Opendns.org
208.67.222.222
208.67.220.220  Gustavo.

>
> /Stephan
>
> ---------------------------------------
> Dipl.Informatiker(FH) Stephan Enderlein
> Freifunk Dresden
>
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

[-- Attachment #2: Type: text/html, Size: 1874 bytes --]