[Discuss] Tunnel
Walter Ring
(spam-protected)
So Nov 6 20:56:40 CET 2005
ad 1) werd ich tun
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.
Hier alle meine Interfaces, welche sind da deiner Meinung nach falsch
konfiguriert?
(spam-protected):/etc# ifconfig
eth0 Link encap:Ethernet HWaddr 00:14:BF:42:53:86
inet6 addr: fe80::214:bfff:fe42:5386/10 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:1924 errors:0 dropped:0 overruns:0 frame:0
TX packets:1112 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:457500 (446.7 KiB) TX bytes:193084 (188.5 KiB)
Interrupt:5 Base address:0x2000
eth1 Link encap:Ethernet HWaddr 00:14:BF:42:53:88
inet addr:193.238.156.18 Bcast:193.238.159.255
Mask:255.255.252.0
inet6 addr: fe80::214:bfff:fe42:5388/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:19429
TX packets:216 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:19160 (18.7 KiB)
Interrupt:4 Base address:0x1000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:29 errors:0 dropped:0 overruns:0 frame:0
TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3091 (3.0 KiB) TX bytes:3091 (3.0 KiB)
tap0 Link encap:Ethernet HWaddr 00:FF:A4:05:88:18
inet addr:193.238.158.109 Bcast:193.238.158.111
Mask:255.255.255.248
inet6 addr: fe80::2ff:a4ff:fe05:8818/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:986 errors:0 dropped:0 overruns:0 frame:0
TX packets:214 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:317152 (309.7 KiB) TX bytes:17224 (16.8 KiB)
vlan0 Link encap:Ethernet HWaddr 00:14:BF:42:53:86
inet addr:193.238.156.19 Bcast:193.238.159.255
Mask:255.255.252.0
inet6 addr: fe80::214:bfff:fe42:5386/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:269 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:20794 (20.3 KiB)
vlan0:0 Link encap:Ethernet HWaddr 00:14:BF:42:53:86
inet addr:193.238.158.105 Bcast:193.238.159.255
Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
vlan1 Link encap:Ethernet HWaddr 00:14:BF:42:53:86
inet addr:10.0.0.102 Bcast:10.255.255.255 Mask:255.255.0.0
inet6 addr: fe80::214:bfff:fe42:5386/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1923 errors:0 dropped:0 overruns:0 frame:0
TX packets:839 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:422702 (412.7 KiB) TX bytes:172002 (167.9 KiB)
(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
Mehr Informationen über die Mailingliste Discuss