• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Fehlerhafte Router-Konfiguration??

coogor

coogor

Hacker
Moin Leute,

ich hab das Problem, dass bei einem Kunden (MS-Shop) die WLAN Verbindung andauernd ausfällt - erst ist die Namensauflösung weg, dann ist keine Verbindung (selbst bei Skype) mehr möglich. Ich bin im Netz für die Externen,, das an Arcor-DSL angeschlossen ist.
Bei der Suche hab ich im Log folgendes gefunden:
Code: 
Jun 25 08:45:25 T520 dhclient[22133]: Internet Systems Consortium DHCP Client 4.2.3-P2
Jun 25 08:45:25 T520 dhclient[22133]: Copyright 2004-2012 Internet Systems Consortium.
Jun 25 08:45:25 T520 dhclient[22133]: All rights reserved.
Jun 25 08:45:25 T520 dhclient[22133]: For info, please visit https://www.isc.org/software/dhcp/
Jun 25 08:45:25 T520 dhclient[22133]: 
Jun 25 08:45:25 T520 dhclient[22133]: Listening on LPF/wlan0/10:0b:a9:ef:6c:4c
Jun 25 08:45:25 T520 dhclient[22133]: Sending on   LPF/wlan0/10:0b:a9:ef:6c:4c
Jun 25 08:45:25 T520 dhclient[22133]: Sending on   Socket/fallback
Jun 25 08:45:25 T520 dhclient[22133]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
Jun 25 08:45:25 T520 dhclient[22133]: DHCPOFFER from 1.1.1.1
Jun 25 08:45:26 T520 avahi-daemon[1140]: Registering new address record for fe80::120b:a9ff:feef:6c4c on wlan0.*.
Weiterhin:
Code: 
T520:~> /sbin/ifconfig wlan0
wlan0     Link encap:Ethernet  Hardware Adresse 10:0B:A9:EF:6C:4C  
          inet Adresse:10.0.0.137  Bcast:10.0.0.255  Maske:255.255.255.0
          inet6 Adresse: fe80::120b:a9ff:feef:6c4c/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:166836 errors:0 dropped:0 overruns:0 frame:0
          TX packets:152303 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:1000 
          RX bytes:111477753 (106.3 Mb)  TX bytes:24528867 (23.3 Mb)
Mein Eindruck ist dass die da in irgendeinem Subnetz (1.1.1.1) einen Wins-Server (o.ä.) stehen haben, der irgendwie für Ärger sorgt.
Kann das sein?
Any workarounds?
 
S

spoensche

Moderator
Teammitglied
Eins Winsserver beantwortet keine DHCP Anfragen und vergibt auch keine IP´s. Ist die IP von wlan0 aus dem richtigen Netz? Wie sehen die Routen aus? Wie verhält sich die Verbindung per Kabel? Sind in den ARP Tabellen Einträge vorhanden, die auf Manipulation des ARP-Caches, z.B. durch arp Spoofing hinweisen?
Ist ein eigener DNS-Nameserver vorhanden? Wenn ja welcher und was sagen die Logs? Liegen bei der Namensauflösung Einträge vor die dir seltsam vorkommen, wenn ja kannst du ein erfolgreiches DNS- Spoofing oder DNS- Poisoning ausschließen? Verhält es sich bei einem anderen WLAN Client ähnlich oder genau so? Was sagen die Logs der Firewall? Ist in den Logfiles des Shops (Datenbank, Webserver, Systemlogs) etwas verdächtiges zu finden, sofern die Analyse mangels informativer Meldungen möglich ist.

Ist im Netz ein ungewöhnlich hohes Traffic aufkommen fest zustellen?
 
OP
coogor

coogor

Hacker
Viele Fragen...ich fang mal an.
Mit MS-Shop war nicht gemeint dass sie ein Shopsystem betreiben, sondern eine Firma, die alles nur von MS im Einsatz hat... ;)
Ja, die IP von WLAN0 ist aus dem richtigen Netz.
Routen:
Code: 
T520:~> netstat -r
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
default         localhost       0.0.0.0         UG        0 0          0 wlan0
localhost       *               255.255.255.0   U         0 0          0 wlan0
Arp:
Code: 
T520:~> /sbin/arp --verbose
Address                  HWtype  HWaddress           Flags Mask            Iface
localhost                ether   00:00:0c:07:ac:1e   C                     wlan0
Einträge: 1   Ignoriert: 0   Gefunden: 1
Als Nameserver ist der von Arcor eingetragen:
Code: 
T520:~> more /etc/resolv.conf
### /etc/resolv.conf file autogenerated by netconfig!
### Please remove (at least) this line when you modify the file!
nameserver 145.253.2.11
nameserver 212.82.225.7
nameserver 145.253.2.75
In der Firewall gibt es ein paar Einträge, mit denen kann ich aber nicht so richtig viel anfangen:
Code: 
Jun 26 10:08:02 T520 kernel: [ 3538.750505] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=10:0b:a9:ef:6c:4c:4c:b1:99:02:8e:58:08:00 SRC=10.0.0.31 DST=10.0.0.137 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=8286 DF PROTO=TCP SPT=51919 DPT=6783 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303040101080A0FBCC3EE0000000004020000) 
Jun 26 10:08:04 T520 kernel: [ 3540.715004] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=10:0b:a9:ef:6c:4c:4c:b1:99:02:8e:58:08:00 SRC=10.0.0.31 DST=10.0.0.137 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=36630 DF PROTO=TCP SPT=51919 DPT=6783 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303040101080A0FBCC7E10000000004020000) 
Jun 26 10:08:04 T520 kernel: [ 3540.826531] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=10:0b:a9:ef:6c:4c:4c:b1:99:02:8e:58:08:00 SRC=10.0.0.31 DST=10.0.0.137 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=10363 DF PROTO=TCP SPT=51919 DPT=6783 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303040101080A0FBCCBFF0000000004020000) 
Jun 26 10:08:27 T520 kernel: [ 3563.719095] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=10:0b:a9:ef:6c:4c:4c:b1:99:02:8e:58:08:00 SRC=10.0.0.31 DST=10.0.0.137 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=5531 DF PROTO=TCP SPT=52176 DPT=6783 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303040101080A0FBD24C90000000004020000)
Was andere Clients angeht - muß ich versuchen, werde ich mitteilen
Thx!
 
S

spoensche

Moderator
Teammitglied
Da hat jemand aus deinem Netz innerhalb von 5 Sek. 4 mal eine Verbindung zu Port 6783 aufzubauen. Wenn er das auch bei anderen Rechnern versucht hat, solltest du Erfahrung bringen, wessen Rechner diese IP hat.
 
OP
coogor

coogor

Hacker
Ich glaube das ist nichts wildes......
Das Netz ist nach 3-5 Minuten weg. Kann es sein dass das so eine Active-Directory-Scheisse ist?
 
A

admine

Ultimate Guru
Splashtop verwendet wohl u.a. Port 6783 - eine Remotesofware für zum Beispiel das IPad.

http://www.splashtopremote.com/faq#defining_pc_to_connect_to
 
S

spoensche

Moderator
Teammitglied
coogor schrieb:
Ich glaube das ist nichts wildes......
Das Netz ist nach 3-5 Minuten weg. Kann es sein dass das so eine Active-Directory-Scheisse ist?
Zum Vergrößern anklicken....

Das hat nichts mit AD zu tun. Das sieht man am DST Port. Wenn das Netz weg ist u. an dem Netz Produktivserver angeschlossen sind, dann soll das nichts schlimmes sein?? :schockiert:

Netz weg = Produktionsstillstand => Verluste, im schlimmsten Fall ein sehr hoher wirtschaftl. Schaden, der weiter Konsequenzen nach sich zieht.
 
OP
coogor

coogor

Hacker
Ja, der kausale Zusammenhang ist mir geläufig. Aber warum tritt das nur bei meinem Rechner unter openSUSE 12.1 auf, nicht auf den ganzen Windows-Kisten und auch nicht unter Ubuntu 12.04 Live CD??? Und auch NUR in diesem Netzwerk? Alle anderen, inclusive versuchter Hotelnetze, funktionieren einwandfrei!
 
S

spoensche

Moderator
Teammitglied
coogor schrieb:
Ja, der kausale Zusammenhang ist mir geläufig. Aber warum tritt das nur bei meinem Rechner unter openSUSE 12.1 auf, nicht auf den ganzen Windows-Kisten und auch nicht unter Ubuntu 12.04 Live CD??? Und auch NUR in diesem Netzwerk? Alle anderen, inclusive versuchter Hotelnetze, funktionieren einwandfrei!
Zum Vergrößern anklicken....

Durch optimieren einiger TCP Parameter, wie z.B. Größe des Sende- und Empfangspuffer, der Window Size, etc kann zu einem höheren Datendurchsatz beitragen.

Folgende Werte haben sich bei mir als effiziente Grundeinstellung erwiesen;
Code: 
# Increase TCP max buffer size
# 16 MB receive and send buffer
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# increase autotuning TCP buffers limits
# min, default, max number of bytes
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# recommended to increase this for 10G NICS
net.core.netdev_max_backlog = 30000

# these should be the default, but just be sure
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1

# do not cache sstresh from previous connection
net.ipv4.tcp_no_metrics_save = 1

# turn off window scaling
net.ipv4.tcp_window_scaling = 0

Ein Router kann seine Arbeit effizienter verrichten, wenn er Netze statt einzelner IP-Addressen routen kann. Die Routing Tabellen sind dann auch weniger umfangreich.

Die Bandbreitenbegrenzung für den Upload zum Provider sorgt für eine stabile Uploadverbindung. Die bei unserem Router eintreffenden Pakete werden kurz "geparkt", anschließend auf den Weg zum Provider geschickt. Durch diese Drossellung wird verhindert, dass beim Provider die Queue des Modems nicht bis zum Anschlag gefüllt ist und die Anzahl der abgewiesenen Pakete (Wegen Vollast keine Beaarbeitung) gering bleibt und zusätzliches Trafficaufkommen vermieden wird.
 
S

spoensche

Moderator
Teammitglied
Die Kernel Parameter werden in der /etc/sysctl.conf eingetragen. Mit
Code: 
sysctl -p
werden sie übernommen und angewendet.
 
OP
coogor

coogor

Hacker
Mal als Follow-up hierzu: Nachdem ich auf Tumbleweed gewechselt bin (Kernel 3.5.1-38-desktop) habe ich das Problem nicht mehr feststellen können. Scheint also was im openSUSE - Standard zu sein....
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben