# WLAN-Verbindung "schluckt" Daten in eine Richtung [solved]

## manuels

Moin zusammen,

ich habe mir einen HostAP-Server eingerichtet. Allerdings habe ich das Problem, dass Server-Daten am Client nicht ankommen, Client-Daten beim Server aber wohl.

Der Verbindungsaufbau über WPA läuft ohne Probleme (der Client "sagt er sei übers WLAN connected").

Hier die Einstellungen vom Server:

```

# ifconfig wlan1

wlan1     Link encap:Ethernet  Hardware Adresse 00:16:ce:14:ff:72  

          inet Adresse:192.168.3.1  Bcast:192.168.3.255  Maske:255.255.255.0

          inet6-Adresse: fe80::216:ceff:fe14:ff72/64 Gültigkeitsbereich:Verbindung

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1

          RX packets:1138 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1754 errors:0 dropped:0 overruns:0 carrier:0

          Kollisionen:0 Sendewarteschlangenlänge:1000 

          RX bytes:124827 (124.8 KB)  TX bytes:212642 (212.6 KB)

# iwconfig wlan1

wlan1     IEEE 802.11bg  Mode:Master  Frequency:2.452 GHz  Tx-Power=20 dBm   

          Retry  long limit:7   RTS thr:off   Fragment thr:off

          Power Management:off

          Link Quality:0  Signal level:0  Noise level:0

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

# sudo iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination         

ACCEPT     all  --  192.168.3.0/24       anywhere            ctstate NEW 

ACCEPT     all  --  anywhere             anywhere            ctstate RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

# route -n

Kernel-IP-Routentabelle

Ziel            Router          Genmask         Flags Metric Ref    Use Iface

192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan1

192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 wlan0

```

Und der Client:

```

# sudo iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

# iwconfig wlan0

wlan0     IEEE 802.11bg  ESSID:"snet"  

          Mode:Managed  Frequency:2.452 GHz  Access Point: 00:16:CE:14:FF:72   

          Bit Rate=5.5 Mb/s   Tx-Power=20 dBm   

          Retry  long limit:7   RTS thr:off   Fragment thr:off

          Power Management:off

          Link Quality=49/70  Signal level=-61 dBm  Noise level=-94 dBm

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

# ifconfig wlan0

wlan0     Link encap:Ethernet  Hardware Adresse 00:c0:a8:cc:23:27  

          inet Adresse:192.168.3.2  Bcast:192.168.3.255  Maske:255.255.255.0

          inet6-Adresse: fe80::2c0:a8ff:fecc:2327/64 Gültigkeitsbereich:Verbindung

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1

          RX packets:64687 errors:0 dropped:0 overruns:0 frame:0

          TX packets:39297 errors:0 dropped:0 overruns:0 carrier:0

          Kollisionen:0 Sendewarteschlangenlänge:1000 

          RX bytes:92484541 (92.4 MB)  TX bytes:3682373 (3.6 MB)

# route -n

Kernel-IP-Routentabelle

Ziel            Router          Genmask         Flags Metric Ref    Use Iface

192.168.3.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0

169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0

0.0.0.0         192.168.3.1     0.0.0.0         UG    0      0        0 wlan0

```

Lausche ich am Server und am Client mittels tcpdump, sehe ich, dass der Client z.B. ein Ping- oder ARP-Request abgeschickt wird, welches beim Server auch ankommt.

Der Server scheint die Antwort auch zu "formulieren" (die tcpdump-Instanz auf dem Server listet das Paket auf), aber am Client kommt es nicht an.

Es ist nun die Frage, ob der Server das Paket nicht abschickt (ich weiß nicht, ob iptables oder irgendwas auf Kernel-Level das Paket noch abfangen könnte) oder ob es der Client nicht empfangen möchte.

Das ganze kommt mir ziemlich seltsam vor und ich bin irgendwie mit meinem Latein am Ende.

Vielleicht habe ich aber einfach nur Tomaten auf den Augen.

Kann jemand von euch Licht ins Dunkle bringen?

PS: Ja, ich muss gestehen: Es sind Ubuntu 9.10-Maschinen   :Embarassed:   - ich war das ewige kompilieren leid.

Aber die Ubuntu-Community ist mit der Gentoo-Community in Sachen Kompetenz einfach nicht vergleichbar...  :Laughing: 

----------

## papahuhn

Server-wlan0 und Client-wlan0 sind im gleichen Layer2-Netz?

Clientanfragen an 192.168.3.1 gehen raus über client::wlan0 und kommen rein über server::wlan0.

Der Server "routet" auf server::wlan1. Server antwortet auf server::wlan1 und trifft ins Leere.

----------

## manuels

 *papahuhn wrote:*   

> Server-wlan0 und Client-wlan0 sind im gleichen Layer2-Netz?

 

Falls du damit meinst, ob Server-wlan0 und Client-wlan0 im selben WLAN sind:

Nein, Server-wlan0 ist mit einem WLAN verbunden, das ein Gateway zum Internet bereitstellt (und fuers Masquerading genutzt werden soll [sollte mein Problem behoben eines Tages sein]).

 *Quote:*   

> 
> 
> Clientanfragen an 192.168.3.1 gehen raus über client::wlan0 und kommen rein über server::wlan0.
> 
> Der Server "routet" auf server::wlan1. Server antwortet auf server::wlan1 und trifft ins Leere.

 Da Server-wlan0 nicht im selben WLAN ist, trifft das nicht zu, oder?

----------

## papahuhn

 *manuels wrote:*   

>  *papahuhn wrote:*   Server-wlan0 und Client-wlan0 sind im gleichen Layer2-Netz? 
> 
> Falls du damit meinst, ob Server-wlan0 und Client-wlan0 im selben WLAN sind:
> 
> Nein, Server-wlan0 ist mit einem WLAN verbunden, das ein Gateway zum Internet bereitstellt (und fuers Masquerading genutzt werden soll [sollte mein Problem behoben eines Tages sein]).
> ...

 

Das kannst eigentlich nur du beantworten. Es sind also Server-wlan1 und Client-wlan0 im gleichen WLAN? Und du hast vom Client aus einen ping auf 192.168.3.1 abgesetzt? Auf welchen Interfaces hast du gedumpt?

----------

## manuels

 *papahuhn wrote:*   

> Das kannst eigentlich nur du beantworten. Es sind also Server-wlan1 und Client-wlan0 im gleichen WLAN?

 Ja, sind sie. *Quote:*   

> Und du hast vom Client aus einen ping auf 192.168.3.1 abgesetzt? Auf welchen Interfaces hast du gedumpt?

 Nach der Routing-Tabelle duerfte das eigentlich nicht passieren.

Wenn ich einen Ping vom Client absetze, passiert folgendes (nach tcpdump-Ausgabe!):

Ping verlaesst Client ueber wlan0

Ping wird vom Server ueber wlan1 empfangen

Ping wird vom Server ueber wlan1 beantwortet

Der Client empfaengt die Antwort nicht

Kann die Antwort auf dem Server noch, nachdem es tcpdump "passiert" hat, auf wlan0 umgeroutet werden?

Ich werde, wenn ich nach hause komme, mal schauen, ob das wirklich passiert.

EDIT: Ich habe auf dem Client auf wlan0 und auf dem Server auf wlan1 "gedumpt".

----------

## papahuhn

> Nach der Routing-Tabelle duerfte das eigentlich nicht passieren.

Was dürfte nicht passieren?

> Kann die Antwort auf dem Server noch, nachdem es tcpdump "passiert" hat, auf wlan0 umgeroutet werden?

Das weiss ich nicht genau; wenn ich raten sollte, nein.

> Ich habe auf dem Client auf wlan0 und auf dem Server auf wlan1 "gedumpt".

Dumpe doch zusätzlich auf auf server::wlan0, dann siehst du ja, ob es umgeroutet wird. Schau dir außerdem mal die Src-IP der Pakete an, die beim Server ankommen. Ist das auch wirklich die 192.168.3.2 oder eventuell die IP-Adresse eines anderen Client-Interfaces?

----------

## manuels

 *papahuhn wrote:*   

> > Nach der Routing-Tabelle duerfte das eigentlich nicht passieren.
> 
> Was dürfte nicht passieren?
> 
> > Kann die Antwort auf dem Server noch, nachdem es tcpdump "passiert" hat, auf wlan0 umgeroutet werden?
> ...

 Sorry, da war mein Gedankengang wohl nicht wirkich linear.

Eben diese "Umroutung" sollte nicht passieren.

 *Quote:*   

> 
> 
> > Ich habe auf dem Client auf wlan0 und auf dem Server auf wlan1 "gedumpt".
> 
> Dumpe doch zusätzlich auf auf server::wlan0, dann siehst du ja, ob es umgeroutet wird. Schau dir außerdem mal die Src-IP der Pakete an, die beim Server ankommen. Ist das auch wirklich die 192.168.3.2 oder eventuell die IP-Adresse eines anderen Client-Interfaces?

 Werd ich spaeter machen und bescheid geben.

----------

## manuels

Ok, die Pakete gehen definitiv nicht über Server-wlan0 raus.

Kann man tcpdump trauen, dass das Paket Server-wlan1 wirklich verlässt?

----------

## manuels

Hmm, die Pakete gehen anscheinend auch nicht über Server-wlan1 raus:

bei ifconfig ändert sich der TX count nicht.

EDIT: Ups, das muss ich revidieren. Der TX count steigt.

----------

## papahuhn

Was steht in den NAT-Tabellen?

----------

## manuels

Stimmt, die habe ich vergessen zu posten (dachte, bei iptables -L wäre schon alles bei).

Hier die des Servers:

die OUTPUT und PREROUTING sind leer und auf ACCEPT

```
Chain POSTROUTING (policy ACCEPT)

target     proto opt source     destination

MASQUERADE   all  --  anywhere   anywhere

```

Auf dem Client sind alle drei leer und auf ACCEPT

----------

## papahuhn

Hm, dann weiss ich auch nicht weiter. Gehen wir kurz mal von IP weg. Was ist, wenn du vom Server ein "arping -I wlan1 192.168.3.2" absetzt? Kommen die Requests auch nicht an?

----------

## manuels

Poing! Da will man alles überkorrekt machen und trägt in die hostapd.conf

```
country_code=DE
```

ein und macht damit alles kaputt.

Wenn ich die Zeile rausnehme, funktionierts. Ich weiß nicht warum, ist mir aber auch erstmal egal!

----------

## papahuhn

Äh  :Question: 

Ich gebe zu, ich habe die Info, dass du hostapd benutzt, ignoriert und auch nicht nachgesehen, wozu es dient.

Jetzt lese ich, dass es dafür zuständig ist, sich beim Server zu authentifizieren. Wenn das wegen des country_codes fehltschlägt,

frage ich mich, warum da überhaupt Pakete ankommen...

----------

