[Discuss] Tunnel
Andreas Marksteiner
(spam-protected)
So Nov 6 21:05:24 CET 2005
> ad 2) ich hab chello, daher vlan1. Ein ppp0 Interface gibts bei mir
> gar
> nicht. Bei mir ist das so konfiguriert, dass ich über einen Netgear-
> Router
> an Chello hänge, und dahinter die Linksys mit dem wan-Interface am
> internen
> 10.0er Netz am Netgear hängen hab.
>
ist bei mir auch ppp0 und ich hab chello - das hängt mitm OpenVPN zam
und hat afaik nichts mit PPTP (adsl & Co.) zu tun.
> Hier alle meine Interfaces, welche sind da deiner Meinung nach falsch
> konfiguriert?
>
scheint alles korrekt - bis auch wie schon angemerkt tap0 !
grüße, andi.
> (spam-protected):/etc#
>
> lg walter
>
>
> -----Original Message-----
> From: Andreas Marksteiner [mailto:(spam-protected)]
> Sent: Sonntag, 06. November 2005 20:51
> To: Walter Ring
> Cc: (spam-protected)
> Subject: Re: [Discuss] Tunnel
>
> so noch ein gravierender fehler!!
>
> du verwendest als tunnel IP eine IP aus deinem Client IP Space. Damit
> ist auch die Broadcast IP falsch --> kann nicht funktionieren (imho).
>
> 1) lege im frontend ein device vom typ "VPN Tunnel" an und trage als
> IP dort die vom Tunnel Device ein mit netmask 255.255.252.0 und
> broadcast 193.238.159.255.
>
> 2) warum ist das carrierdevice auf vlan1 - sollte imo "ppp0" sein.
>
>> export FF_tun_carrierdevice=vlan1
>> export FF_tun_ipaddr=193.238.158.109
>> export FF_tun_netmask=255.255.255.248
>> export FF_tun_broadcast=193.238.158.111
>
> Bitte aktuell wieder als ein Subnetz announcen!
>
>> export FF_olsrd_hna4_network="193.238.158.105 193.238.158.106
>> 193.238.158.107 193.238.158.108 193.238.158.109 193.238.158.110"
>> export FF_olsrd_hna4_netmask=255.255.255.255
>
> ACHTUNG, da gibts dann einen Art Bug in der fw (je nachdem welche
> version du hast - sollte bei dir das alias device dann nicht
> ordentlich angelegt werden - genau schauen, broadcast und netmask
> werden vermutlich falsch sein).
>
>> export FF_olsrd_hna4_alias_broadcast=193.238.159.255
>
> SOLLTE das passieren - zur Behebung musst du zwischenzeitlich
> dazufügen:
> export FF_olsrd_hna4_alias_netmask=255.255.255.248
>
>
> grüße, andi.
>
>>
>> export FF_dhcpd_active=off
>> export FF_dhcpd_if=
>> export FF_dhcpd_leasetime=
>> export FF_dhcpd_range_start=
>> export FF_dhcpd_range_end=
>> export FF_dhcpd_range_netmask=
>>
>> export FF_pptp_active=off
>> export FF_pptp_alias_if=
>> export FF_pptp_alias_ip=
>> export FF_pptp_alias_netmask=
>> export FF_pptp_alias_broadcast=
>> export FF_pptp_dest_ip=
>> export FF_pptp_username=
>> export FF_pptp_passwd=
>>
>> export txant=0
>> export antdiv=0
>> export txpwr=28
>> (spam-protected):~#
>>
>>
>>
>> und dann noch das olsrd.conf
>>
>> (spam-protected):/etc# cat olsrd.conf
>> #
>> # olsr.org OLSR daemon config file
>> #
>> # Lines starting with a # are discarded
>> #
>> # This file was shipped with olsrd 0.4.8 #
>>
>> # Debug level(0-9)
>> # If set to 0 the daemon runs in the background
>>
>> DebugLevel 0
>>
>> # IP version to use (4 or 6)
>>
>> IpVersion 4
>>
>> Hna4
>> {
>> 193.238.158.105 255.255.255.255
>> 193.238.158.106 255.255.255.255
>> 193.238.158.107 255.255.255.255
>> 193.238.158.108 255.255.255.255
>> 193.238.158.109 255.255.255.255
>> 193.238.158.110 255.255.255.255
>>
>> }
>>
>> Hna6
>> {
>>
>> }
>>
>>
>> # Should olsrd keep on running even if there are # no interfaces
>> available?
>> This is a good idea # for a PCMCIA/USB hotswap environment.
>> # "yes" OR "no"
>>
>> AllowNoInt yes
>>
>> # TOS(type of service) value for
>> # the IP header of control traffic.
>> # If not set it will default to 16
>>
>> #TosValue 16
>>
>> # The fixed willingness to use(0-7)
>> # If not set willingness will be calculated # dynamically based on
>> battery/power status # if such information is available
>>
>> #Willingness 4
>>
>> # Allow processes like the GUI front-end # to connect to the daemon.
>>
>> IpcConnect
>> {
>> MaxConnections 1
>> Host 127.0.0.1
>> }
>>
>> # Wether to use hysteresis or not
>> # Hysteresis adds more robustness to the # link sensing but delays
>> neighbor
>> registration.
>> # Used by default. 'yes' or 'no'
>>
>> UseHysteresis no
>>
>>
>> # Link quality level
>> # 0 = do not use link quality
>> # 1 = use link quality for MPR selection # 2 = use link quality for
>> MPR
>> selection and routing # Defaults to 0
>>
>> LinkQualityLevel 2
>>
>> # Link quality window size
>> # Defaults to 10
>>
>> LinkQualityWinSize 20
>>
>> # Polling rate in seconds(float).
>> # Default value 0.05 sec
>>
>> Pollrate 0.05
>>
>>
>> # TC redundancy
>> # Specifies how much neighbor info should # be sent in TC messages #
>> Possible values are:
>> # 0 - only send MPR selectors
>> # 1 - send MPR selectors and MPRs
>> # 2 - send all neighbors
>> #
>> # defaults to 0
>>
>> TcRedundancy 2
>>
>>
>> #
>> # MPR coverage
>> # Specifies how many MPRs a node should
>> # try select to reach every 2 hop neighbor # # Can be set to any
>> integer >0
>> # # defaults to 1
>>
>> MprCoverage 2
>>
>>
>> # !!CHANGE THE INTERFACE LABEL TO MATCH YOUR INTERFACE!!
>> # (eg. wlan0 or eth1):
>> # THESE SETTINGS FOR FUNKFEUER ARE QUITE CONSERVATIVE # AND NOT
>> VERY MOBILE.
>> But they reduce olsr traffic overhead
>>
>>
>> Interface "vlan0"
>> {
>> HelloInterval 10.0
>> HelloValidityTime 200.0
>> TcInterval 25.0
>> TcValidityTime 500.0
>> MidInterval 25.0
>> MidValidityTime 500.0
>> HnaInterval 25.0
>> HnaValidityTime 500.0
>> }
>> Interface "eth1"
>> {
>> HelloInterval 10.0
>> HelloValidityTime 200.0
>> TcInterval 25.0
>> TcValidityTime 500.0
>> MidInterval 25.0
>> MidValidityTime 500.0
>> HnaInterval 25.0
>> HnaValidityTime 500.0
>> }
>> (spam-protected):/etc#
>>
>> Any help?
>>
>> lg walter
>>
>> -----Original Message-----
>> From: Andreas Marksteiner [mailto:(spam-protected)]
>> Sent: Sonntag, 06. November 2005 18:49
>> To: Walter Ring
>> Cc: (spam-protected)
>> Subject: Re: [Discuss] Tunnel
>>
>>> Aaron hat mir gesagt, als Tunneldestination sei jetzt 193.238.156.1
>>> einzutragen und nicht 62.116.34.150. Was ist jetzt richtig?
>>
>> sollte beides gehen - imo aber sicherheitshalber noch immer
>> 62.116.34.150 (hab das andere noch nicht verifiziert; wer weiß,
>> vielleicht geht ja die 193.238.156.1 er aus irgendeinem routing
>> paradoxon nicht ;-) und das wollen wir ja als fehlerquelle
>> ausschliessen).
>>
>> grüße, andi.
>>
>>>
>>> lg walter
>>>
>>> -----Original Message-----
>>> From: (spam-protected)
>>> [mailto:(spam-protected)] On Behalf Of Andreas
>>> Marksteiner
>>> Sent: Sonntag, 06. November 2005 02:59
>>> To: Bernd Petrovitsch
>>> Cc: (spam-protected)
>>> Subject: Re: [Discuss] Tunnel
>>>
>>>> Ja. Wenn ich Port 698/olsr anschau, dann broadcastet mein olsrd
>>>> raus,
>>>> aber es kommt nie eine Antwort zurück. Aber das scheint bei den
>>>> Tunneln
>>>> normal zu sein, weil bei anderen ist es nicht anders (zumindets
>>>> nicht
>>>> bei den 2 zufälligen, die jett kurz angeschaut hab).
>>>
>>> öhm - hast vom subway aus geschaut? wenn ich auf die topo map
>>> schaue,
>>> dann ist nur der tunnel zu onstage (outpost) und vivilokal überhaupt
>>> aktiv (meinen hab ich letztens auch abgedreht - interface auf meiner
>>> seite down) - erkennen kann man das schön an der topo map und den
>>> strecken die von dort weggehen. da wollten viele leute einen tunnnel
>>> aufbaun, gemacht hats keiner.
>>> also eigentlich müssen durch den tunnel auch olsrd broadcasts von
>>> der
>>> anderen seite kommen - sollte man schon sehen. reinschicken tust du
>>> scheinbar pakete, weil rauskommen tun ja welche vom subway
>>>
>>>> 00:36:08.719569 IP 193.238.158.188.698 > 193.238.159.255.698: UDP,
>>>> length: 420
>>>> 00:36:08.791079 IP 193.238.158.187.698 > 193.238.159.255.698: UDP,
>>>> length: 20
>>>
>>> VIELLEICHT HIER DEIN PROBBLEM?? -->
>>> wichtig in diesem zusammenhang. wie hängt diese kiste am internet?
>>> die hat ja dann ein netzwerk interface (eh kloa) und daher auch
>>> einen
>>> default gateway eingetragen (damit sie das große weite welt weit
>>> netz
>>> erreicht). nun mußt du den default gw löschen! jetzt eine hostroute
>>> zum subway eintragen (sicherheitshalber auf die IP 62.116.34.150)
>>> eintragen!! nun kann der tunnel aufgebaut werden (evtl. danach
>>> nochmal den olsrd neu starten), aber alle anderen paktet (also alle,
>>> die nicht destination 62.116.34.150 haben) werden nun in den tunnel
>>> eingefüllt - WEIL der olsrd nun die default route gesetzt hat.
>>>
>>>>
>>>>> 2 Fragen:
>>>>> - warum adressen mit *.158.* - wie/woher hast die bekommen. sind
>>>>> das
>>>>
>>>> Vom Frontend.
>>>>
>>>>> client IPs (wie auch immer sollte an der funktion nix ändern),
>>>>> oder
>>>>
>>>> Ja. Zumindest stehen im Frontend unter "Client-IPs".
>>>
>>> Also Client IPs sind dafür nicht gedacht, aber tut der Funktion nun
>>> erst mal keinen Abbruch.
>>>
>>>>
>>>> Hätte ich die bei den Devices eintragen sollen?
>>>>
>>>> Ich mach das mal.
>>>
>>>
>>>>
>>>> Hmm, die Device-Eingabe ist zu hoch für mich - im Namen ist nicht
>>>> möglich und bei der MAC-Adresse will es unbedingt Großbuchstaben
>>>> haben.
>>>> Soll ich einen Patch für den JavaScript-Check-Code basteln?
>>>
>>> Ja. Name war bisher immer z.B. "berndsstrasse9999gw" ich hab z.B.
>>> einen "oag18gw" (meine tunnel linksys kiste). Also nimm halt keine
>>> Sonderzeichen. Akku hat letztens schon was gesagt, ich habs noch
>>> nicht an Wolfgang weitergeleitet --> es gibt scheinbar ein Logik-
>>> Problem im Frontend GUI bzgl. MAC Adressen.
>>>
>>>>
>>>> Hmm, da bekomm' ich jetzt noch 2 IP-Adressen. Ich glaub, ich trag
>>>> die
>>>> mal ein.
>>>
>>> Genau die 2 Adressen kannst nehmen.
>>>
>>> EIGENTLICH ist es ja noch ganz anders.
>>> Auf Seite User:
>>> Man legt ein Device an und da kann man sowas wie Tunnel, oder so als
>>> Zweck eingeben (kann nicht nachschauen, komme grad nicht auf den
>>> outpost ... ). Dann bekommt man aber 2 IPs - brauchen tut man ja nur
>>> eine pro Seite für den Tunnel - also muss man dann momentan
>>> eigentlich hergehen und eine der beiden zugewiesenen IPs wieder
>>> freigeben (per pgpPgAdmin direkt in der DB).
>>>
>>> Auf Seite FunkFeuer (Subway):
>>> Ein Admin legt auch ein Device an im Standort VIVI an (und löscht
>>> wiederum die unnötige 2te IP).
>>>
>>>
>>> Hoffe es ist soweit klar - ich glaub wir müssen das nochmal besser
>>> dokumentieren.
>>>
>>> Wenn Fragen bitte gleich wieder Mail.
>>>
>>>
>>> Grüße, Andi.
>>>
>>>>
>>>> [ TOFU entsorgt ]
>>>>
>>>> Bernd
>>>> --
>>>> Firmix Software GmbH http://www.firmix.at/
>>>> mobil: +43 664 4416156 fax: +43 1 7890849-55
>>>> Embedded Linux Development and Services
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss mailing list
>>>> (spam-protected)
>>>> https://lists.funkfeuer.at/mailman/listinfo/discuss
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss mailing list
>>> (spam-protected)
>>> https://lists.funkfeuer.at/mailman/listinfo/discuss
>>
>>
>> _______________________________________________
>> Discuss mailing list
>> (spam-protected)
>> https://lists.funkfeuer.at/mailman/listinfo/discuss
>
>
> _______________________________________________
> Discuss mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/discuss
Mehr Informationen über die Mailingliste Discuss