[Discuss] Tunnel
Walter Ring
(spam-protected)
So Nov 6 18:51:13 CET 2005
Mein Routing schaut so aus:
(spam-protected):~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
193.238.156.1 10.0.0.1 255.255.255.255 UGH 0 0 0
vlan1
193.238.158.104 * 255.255.255.248 U 0 0 0 tap0
193.238.156.0 * 255.255.252.0 U 0 0 0
vlan0
193.238.156.0 * 255.255.252.0 U 0 0 0 eth1
10.0.0.0 * 255.255.0.0 U 0 0 0
vlan1
(spam-protected):~#
Sollte doch wohl alles passen, oder? Und OpenVPN sollte doch auch über ein
geNATedes Netz drübergehen.
pingen kann ich auch:
(spam-protected):~# ping 193.238.156.1
PING 193.238.156.1 (193.238.156.1): 56 data bytes
64 bytes from 193.238.156.1: icmp_seq=0 ttl=54 time=11.1 ms
64 bytes from 193.238.156.1: icmp_seq=1 ttl=54 time=18.3 ms
64 bytes from 193.238.156.1: icmp_seq=2 ttl=54 time=9.4 ms
64 bytes from 193.238.156.1: icmp_seq=3 ttl=54 time=11.0 ms
64 bytes from 193.238.156.1: icmp_seq=4 ttl=54 time=10.3 ms
--- 193.238.156.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss round-trip
min/avg/max = 9.4/12.0/18.3 ms (spam-protected):~#
OpenVPN und olsr Dämon laufen:
(spam-protected):~# ps
PID Uid VmSize Stat Command
1 root 372 S init
2 root SW [keventd]
3 root SWN [ksoftirqd_CPU0]
4 root SW [kswapd]
5 root SW [bdflush]
6 root SW [kupdated]
7 root SW [mtdblockd]
18 root SWN [jffs2_gcd_mtd4]
42 root 316 S klogd
43 root 360 S syslogd -C 16
355 root 356 S /usr/sbin/httpd -p 80 -h /www -r WRT54G Router
372 root 372 S /usr/bin/dropbear
378 root 376 S udhcpc -i vlan1 -b -p /tmp/dhcp-vlan1.pid
390 root 412 S /bin/sh /bin/olsrd-reanimator.sh 300
400 root 544 S /sbin/olsrd -d 0
425 root 464 S /usr/sbin/openvpn --remote 193.238.156.1 --dev
tap0 --port 5009 --daemon --persist-tun
444 root 412 S /bin/sh /bin/sight_scan.sh
446 root 372 S init
449 root 240 S sleep 86400
545 root 608 S /usr/bin/dropbear
546 root 472 S -sh
560 root 240 S sleep 300
562 root 360 R ps
(spam-protected):~#
Am tap0 interface spielt sich rein gar nix ab:
(spam-protected):~# tcpdump -ni tap0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 68 bytes
Hier meine vars.sh:
(spam-protected):~# cat /etc/vars.sh
#!/bin/sh
export FF_nodeowner=walter_ring
export FF_nodetype=omni
export FF_hostname=mar18omni
export FF_ns1_ipaddr=193.238.156.1
export FF_ns2_ipaddr=193.238.156.2
export FF_ntp_server=ts1.univie.ac.at
export FF_dropbear_active=on
export FF_telnetd_active=off
export FF_httpd_active=on
export FF_bridge_active=off
export FF_bridge_ifname=br0
export FF_bridge_addlan=no
export FF_bridge_addwifi=no
export FF_bridge_addwan=no
export FF_lan_active=on
export FF_lan_ipaddr=193.238.156.19
export FF_lan_ipaddr_v6=
export FF_lan_prefix=
export FF_lan_prefixlen=
export FF_lan_gateway_v6=
export FF_lan_netmask=255.255.252.0
export FF_lan_broadcast=193.238.159.255
export FF_lan_gateway=
export FF_lan_mtu=
export FF_lan_ifname=vlan0
export FF_lan_ifnames=vlan0
export FF_lan_proto=static
export FF_lan_macaddr=
export FF_wifi_active=on
export FF_wifi_ipaddr=193.238.156.18
export FF_wifi_ipaddr_v6=
export FF_wifi_prefix=
export FF_wifi_prefixlen=
export FF_wifi_gateway_v6=
export FF_wifi_netmask=255.255.252.0
export FF_wifi_broadcast=193.238.159.255 export FF_wifi_gateway= export
FF_wifi_mtu= export FF_wifi_channel=1 export
FF_wifi_ssid="freiesnetz_www.funkfeuer.at"
export FF_wifi_rate=
export FF_wifi_key=
export FF_wifi_wep=
export FF_wifi_ifname=eth1
export FF_wifi_ifnames=eth1
export FF_wifi_fragsize=
export FF_wifi_frameburst=1
export FF_wifi_rtsthreshold=300
export FF_wifi_proto=static
export FF_wan_active=on
export FF_wan_ipaddr=
export FF_wan_ipaddr_v6=
export FF_wan_prefix=
export FF_wan_prefixlen=
export FF_wan_gateway_v6=
export FF_wan_netmask=
export FF_wan_broadcast=
export FF_wan_gateway=
export FF_wan_mtu=
export FF_wan_ifname=vlan1
export FF_wan_ifnames=vlan1
export FF_wan_proto=dhcp
export FF_wan_macaddr=
export FF_tun_active=on
export FF_tun_carrierdevice=vlan1
export FF_tun_ipaddr=193.238.158.109
export FF_tun_ipaddr_v6=
export FF_tun_prefix=
export FF_tun_prefixlen=
export FF_tun_gateway_v6=
export FF_tun_netmask=255.255.255.248
export FF_tun_broadcast=193.238.158.111
export FF_tun_mtu=
export FF_tun_ifname=tap0
export FF_tun_ifnames=tap0
export FF_tun_destination=193.238.156.1
export FF_tun_gateway=10.0.0.1
export FF_tun_remoteport=5009
export FF_olsrd_active=on
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
export FF_olsrd_hna6_network=
export FF_olsrd_hna6_prefixlen=
export FF_olsrd_interfaces="vlan0 eth1"
export FF_olsrd_hna4_alias_ip=193.238.158.105
export FF_olsrd_hna6_alias_ip=
export FF_olsrd_hna4_alias_if=vlan0
export FF_olsrd_hna6_alias_if=
export FF_olsrd_hna4_alias_broadcast=193.238.159.255
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
Mehr Informationen über die Mailingliste Discuss