[Discuss] Tunnel
Andreas Marksteiner
(spam-protected)
So Nov 6 20:54:25 CET 2005
BERND: kann es bei dir evtl. detto ein broadcast problem sein - die
Tunnel Endpunkt IP muss netmask 255.255.252.0 und broadcast
193.238.159.255 haben.
ich denke, das würde erklären, warum eure olsr pakete zwar durch den
tunnel gehen, aber euer olsrd und der am subway effektiv nicht
kommunizieren.
grüße, andi.
Am 06.11.2005 um 20:51 schrieb Andreas Marksteiner:
> 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