Android HotSpot und Debian Netbook

[thiro]

Hallo,

Ich habe Debian 9.1 auf einem Netbook installiert, das läuft soweit auch super... Auch zu Hause im WLAN ist alles ok. Verbindung läuft automatisch ohne Problem...

Aber mit dem Android Handy als Hotspot will es einfach nicht...

Ich hatte zuvor das Samsung Galaxy S6 Edge + und jetzt habe ich das Samsung Galaxy S8+ und mit beiden das selbe, mal verbindet das Netbook automatisch, mal nicht... Mal hilft es einfach auf das "Netzwerk" vom Hotspot (in der Liste der verfügbaren Netzwerken) zu klicken mal hilft das nicht... Manchmal hilft auch einfach warten (bis zu 10 Minuten), manchmal hilft das auch nicht... Dann gibt es noch die reboot Variante, manchmal hilft es Handy UND Netbook zu rebooten und manchmal hilft aber auch das nicht...

Dann muss ich das Netzwerk aus den "Known Netwokrs" löschen und alles rebooten und mit ein wenig Geduld und viel Hoffnung kann ich das Netbook dann wieder verbinden... Dazu kommt ja dann, dass ich den Hotspot mit meinem Handy mache und das auch mobil nutzen muss, so dass auch manchmal das Netzwerk zusammen mit dem Handy verschwindet, was jedoch schonmal gut ist, wenn ich es schaffe morgens zu verbinden, dann funktioniert es den Rest des Tages automatisch. Wenn es aber Morgens nicht klappt, dann muss ich irgendwann im Laufe des Tages einmal die Ganze Reboot-Prozedur machen um es wieder halbwegs ordentlich hin zu bekommen...

Was kann ich machen um das etwas stabiles und anständiges hin zu bekommen?

Mit dem Kabel Tethering mache, dann funktioniert auch alles Einwandfrei, aber dann hängt das Handy ständig am Strom, 5-6 Stunden am Tag... (2-3 Stunden am Tag bin ich gewöhnlich irgendwo im Betrieb unterwegs...)
Und das ist ja auch nicht unbedingt super für den Akku, wenn er ständig am Strom hängt...

mfG
thiro

[BenutzerGa4gooPh]

Vielleicht hilft der Thread? viewtopic.php?f=30&t=167430#p1152192
tl;dr: Haken bei "Automatisch verbinden" im Netzwerkmanager für alle Netzwerke/SSIDs weg! Manuell verbinden durch Klicken auf gewünschte SSID in NW-Applet möglich.

Mit dem Kabel Tethering mache, dann funktioniert auch alles Einwandfrei, aber dann hängt das Handy ständig am Strom, 5-6 Stunden am Tag... (2-3 Stunden am Tag bin ich gewöhnlich irgendwo im Betrieb unterwegs...)
Und das ist ja auch nicht unbedingt super für den Akku, wenn er ständig am Strom hängt...

Das macht dem Akku nichts, die Ladeelektronik regelt schon richtig, schaltet ab bzw. macht Erhaltungsladung. Spart Lade-/Entladezyklen. Daumenregel: 1000 Zyklen -> halbe Akkukapazität. Ich betreibe meinen Laptop mit Akku soweit möglich immer am Netzteil. Nach 5 Jahren noch recht ordentliche Werte (80 %). Prüfe spaßeshalber mal mit Hand die Erwärmung des Smartphones: Während Ladung warm, voll geladen trotz angeschlossenem Netzteil merklich weniger. Ladeelektronik hat abgeschaltet, Ladehysterese wirksam.

[thiro]

Hallo,

Danke für die Antwort. So direkt geholfen hat mir der Thread jetzt nicht... Der Befehl tcpdump kennt mein Debian nicht...
Für den Rest habe ich da auch jetzt nicht direkt eine Lösung für das Problem erlesen. Alle Netzwerke löschen ist ja bei mir auch eine Teillösung, die manchmal funktioniert und manchmal nicht.

Aber das mit den Ladezyklen glaube ich nicht so ganz... Vorallem da ich ja mehrmals am Tag weg vom Schreibtisch gehe und dann das Handy abziehe und danach wieder anstecke. Wenn ich jetzt morgens auf der Arbeit ankomme habe ich so ca 95% dann stecke ich dann sofort das Handy ein zum Tethering und dann läd es auf 100%, sagen wir mal nach 2 Stunden muss ich dann mal weg, ziehe das Ding ab und komm nach 30min zurück wieder mit 98-99% (evtl. hab ich dazwischen telefoniert oder gefacebooked, dann sind es evtl. wieder nur 80-95%) dann stecke ich es wieder ein zum Tethering und es läd wieder auf 100% auf. Nach 1 oder 2 oder 3 Stunden ziehe ich es wieder ab weil ich wieder weg muss und es beginnt wieder... So würde das Handy dann 3-4 oder gar 5-6 mal am Tag von 90 auf 100% geladen werden. An manchen Tagen (wenn hier wieder mal die Welt unter geht) muss ich alle paar Minuten mal raus... Das kostet dann jedes Mal ein Ladezyklus für nicht einmal 10% Akku... Dann kann der Akku nicht sehr alt werden, wenn du mich fragst... Ich bin zwar kein Akku-Experte, aber irgendwie sagt mit mein Gefühl dass das nicht sehr gut sein kann für ein Akku...

[BenutzerGa4gooPh]

So direkt geholfen hat mir der Thread jetzt nicht... Der Befehl tcpdump kennt mein Debian nicht...
...
Wenn ich jetzt morgens auf der Arbeit ankomme habe ich so ca 95% dann stecke ich dann sofort das Handy ein zum Tethering und dann läd es auf 100%, sagen wir mal nach 2 Stunden muss ich dann mal weg, ziehe das Ding ab und komm nach 30min zurück wieder mit 98-99% (evtl. hab ich dazwischen telefoniert oder gefacebooked, dann sind es evtl. wieder nur 80-95%) dann stecke ich es wieder ein zum Tethering und es läd wieder auf 100% auf. Nach 1 oder 2 oder 3 Stunden ziehe ich es wieder ab weil ich wieder weg muss und es beginnt wieder... So würde das Handy dann 3-4 oder gar 5-6 mal am Tag von 90 auf 100% geladen werden.

Da hast du den verlinkten Thread und mein tl;dr nicht richtig verstanden. Bezueglich Smartphone-Akku hast du Recht, andere Situation als bei mir, wenn du das Smartphone zwischendurch mitnimmst. Das WLAN-Tethering wuerde allerdings ganz huebsch am Akku saugen.

[thiro]

Ich hab alle Netzwerke gelöscht...
Da ist also keins mehr mit Häckchen. Normal hat das ja auch immer funktioniert bis jetzt aber jetzt geht überhauptnichts mehr... Ich versuchs morgen nochmal...

[BenutzerGa4gooPh]

Ich hab alle Netzwerke gelöscht...
Da ist also keins mehr mit Häckchen. Normal hat das ja auch immer funktioniert bis jetzt aber jetzt geht überhauptnichts mehr...

Der ist echt gut!

3. Versuch: Nimm Haken bei "Automatisch verbinden" fuer jede konfgurierte SSIDs raus!!!

Klickt man auf "Verbindungen bearbeiten" / "Bearbeiten" , kann man Verbindungen von Hand konfigurieren. Alternativ kann man den Verbindungs-Manager auch über das Anwendungsmenü unter "Einstellungen -> Netzwerkverbindungen" öffnen.
...
Im Reiter "Wireless" findet man alle WLAN-Netzwerke, zu denen man sich schon einmal verbunden hat. Sollte man in Reichweite eines dieser WLANs sein, so wird der NetworkManager versuchen, automatisch eine Verbindung zu ihnen aufzunehmen. Sollte man dies nicht wollen, so muss man das Häkchen bei "Automatisch verbinden" in den nicht erwünschten WLAN-Verbindungen löschen.

https://wiki.ubuntuusers.de/NetworkManager/

[MSfree]

Bezueglich Smartphone-Akku hast du Recht

Generell kann man sagen, daß man LiIon-Akkus mit 10 Zyklen 90-100% genauso streßt wie mit einem Zyklus 0-100%. Es gibt dazu inzwischen Untersuchungen, die sogar zeigen, daß 12-14 90-100% Zyklen etwa einem 0-100% Zyklus entsprechen, dieses sogenannte shallow Cycling den Akku sogar weniger streßt als volle Zyklen.

Insofern ist es sogar akkuschonend, den immer wieder von wenig entleert auf voll zu laden.

Das WLAN-Tethering wuerde allerdings ganz huebsch am Akku saugen.

Natürlich braucht der WLAN-Sender Strom, aber so schlimm ist das (zumindest mit meinem Telefon) nun auch wieder nicht, der Akku ist bei mir dann vielleicht in 3/4 der normalen Zeit leer.

[thiro]

Guten Morgen liebe Sorgen

Ich habe jetzt gestern ein wenig getestet.

Vorgestern hatte ich ja alle WLAN Netzwerke in der Liste gelöscht. Und dann eben per USB gearbeitet.
Gestern dann wollte ich wieder per WLAN arbeiten. Das hat auch funktioniert, es war ja kein Netzwerk gespeichert, ich habe das "Galaxy" Netzwerk (Hotspot) eingeschaltet, in "Netzwerke" auf dem Netbook ausgewählt, Passwort eingegeben und es lief. Dann habe ich in der Konfiguration des Netzwerkes das Häkchen bei "automatisch Verbinden" weg geklickt und den Rest des Tages eben jedes mal auf das Netzwerk geklickt wenn ich mal weg war und wieder zurück gekommen bin. Das lief soweit auch immer direkt wieder.

Heute dann wieder als wenn nichts gewesen wäre... Debian verbindet einfach nicht mehr mit dem Hotspot. Ich kann jetzt natürlich wieder das Netzwerk aus der Liste löschen und wieder Handy und Netbook neu starten und wieder das ganze Theater aufführen, aber die Lösung ist das doch wohl nicht?

Was meint ihr? Gibt es da keine andere Möglichkeit? Und warum funktioniert es zu Hause im "richtigen" WLAN immer und per Hotspot muss ich immer son Theater veranstalten?

[pferdefreund]

Da Wlan zu Hause und Hotspat für den Laptop ja das gleiche sind - ob jetzt ein Router oder ein Handy funkt, ist wohl schnuppe,
sehe ich das Problem da eher am Telefon. Eventuell geht da der Sender aus Stromspargründen in den Schlafmodus. Schon mal die wakelock-app probiert ? - Die muss ich auf dem Handy auch bei einigen Sachen verwenden, z. B. wenn meine simulierte S/370 mit MVS 3.8 läuft und keiner was im TSO macht, dann wird die irgendwann schlafen gelegt (ohne wakelock) und die Terminalverbindung zum TSO oder zur Systemkonsole (schlimmer) kackt ab. Und bei ner S/370 ne Konsole ohne Konsole reaktivieren ist wie die berühmte Windowsmeldung "Es ist keine Tastatur angeschlossen drücken Sie eine beliebige Taste um den Vorgang fortzusetzen".

[smutbert]

Ich meine eher, dass es an network-manager-gnome liegt. Das verhält sich mit mehreren möglichen Verbindungen wirklich merkwürdig – er scheitert daran sich mit einem verfügbaren Netz zu verbinden oder fragt nach root- und WLAN-Passwort obwohl ersteres nicht notwendig sein sollte und zweiteres bereits bekannt ist.

Wie im von Jana verlinkten Thread hilft mir in solchen Situationen nmtui im Terminal, damit klappt es meistens verlässlich
Wahlweise lösche ich auch einige Dateien von network-manager unter /var (und starte network-manager neu), dann funktioniert auch network-manager-gnome gelegentlich wieder zuverlässig(er) (hab ich ebenfalls in dem Thread festgehalten).

[BenutzerGa4gooPh]

Da Wlan zu Hause und Hotspat für den Laptop ja das gleiche sind - ob jetzt ein Router oder ein Handy funkt, ist wohl schnuppe,
sehe ich das Problem da eher am Telefon.

Unterschiedliche Authentifizierung und WLAN-Modi koennten problematisch sein.
Ratsam: WPA2-PSK (AES) only und 802.11n only (evtl. auch 802.11n+g)
Was ein (problematischer) Smartphone-Hotspot nun genau macht, weiss ich nicht, wird m. E. nicht ausfuehrlich angezeigt, Unterschiede koennte man mit Linux-Client scannen.

Code: Alles auswählen

iw dev <Interface> scan

Ein Posting der Angaben ausschliesslich fuer die beiden benutzten SSIDs sind ausreichend, keiner schaut gern hunderte unnuetze Zeilen durch! Bringt wohl eh nichts, da m. E. Smartphone-Hotspot kaum aenderbar. Jedenfalls ungerootet.

Die Hinweise von smutbert oder ein Test von wicd sind m. E. erfolgversprechender.

[thiro]

Ich benutze zur Zeit nur den Hotspot, habe also auch nur 1 SSID..

Ich weiss nicht genau was du brauchts...text.txt

Code: Alles auswählen

	SSID: Galaxy
	Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 
	DS Parameter set: channel 6
	Country: LU	Environment: Indoor/Outdoor
		Channels [1 - 13] @ 20 dBm
	Power constraint: 0 dB
	TPC report: TX power: 19 dBm
	ERP: <no flags>
	Extended supported rates: 6.0 9.0 12.0 48.0 
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: PSK
		 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
	HT capabilities:
		Capabilities: 0x1ad
			RX LDPC
			HT20
			SM Power Save disabled
			RX HT20 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 8 usec (0x06)
		HT RX MCS rate indexes supported: 0-15
		HT TX MCS rate indexes are undefined
	HT operation:
		 * primary channel: 6
		 * secondary channel offset: no secondary
		 * STA channel width: 20 MHz
		 * RIFS: 1
		 * HT protection: no
		 * non-GF present: 0
		 * OBSS non-GF present: 0
		 * dual beacon: 0
		 * dual CTS protection: 0
		 * STBC beacon: 0
		 * L-SIG TXOP Prot: 0
		 * PCO active: 0
		 * PCO phase: 0
	Extended capabilities: Extended Channel Switching, BSS Transition, 6
	WMM:	 * Parameter version 1
		 * BE: CW 15-1023, AIFSN 3
		 * BK: CW 15-1023, AIFSN 7
		 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
		 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
BSS b8:27:eb:f9:b2:84(on wlp6s0b1)
	TSF: 793908696 usec (0d, 00:13:13)
	freq: 2412
	beacon interval: 100 TUs
	capability: ESS Privacy SpectrumMgmt ShortSlotTime (0x0511)
	signal: -51.00 dBm
	last seen: 648 ms ago

PS: Gestern ging es und heute bekomme ich schon wieder keine Verbindung....

[BenutzerGa4gooPh]

Tja, ich sehe nichts Auffälliges. Kannst mal das Gleiche posten, wenn der Smartphone-Hotspot nicht funktioniert. Vielleicht sieht man Unterschiede oder gar nichts?! In letztem Fall könnte man auf @pferdefreunds Tipp zurückkommen ...

[thiro]

Jana, das ist das Resultat wenn ich KEINE Verbindung zum Hotspot bekomme...

Hier ist das Resultat wenn ich verbunden bin:

Code: Alles auswählen

	Information elements from Probe Response frame:
	SSID: Galaxy
	Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 
	DS Parameter set: channel 6
	Country: LU	Environment: Indoor/Outdoor
		Channels [1 - 13] @ 20 dBm
	Power constraint: 0 dB
	TPC report: TX power: 19 dBm
	ERP: <no flags>
	Extended supported rates: 6.0 9.0 12.0 48.0 
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: PSK
		 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
	HT capabilities:
		Capabilities: 0x1ad
			RX LDPC
			HT20
			SM Power Save disabled
			RX HT20 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 8 usec (0x06)
		HT RX MCS rate indexes supported: 0-15
		HT TX MCS rate indexes are undefined
	HT operation:
		 * primary channel: 6
		 * secondary channel offset: no secondary
		 * STA channel width: 20 MHz
		 * RIFS: 1
		 * HT protection: no
		 * non-GF present: 0
		 * OBSS non-GF present: 0
		 * dual beacon: 0
		 * dual CTS protection: 0
		 * STBC beacon: 0
		 * L-SIG TXOP Prot: 0
		 * PCO active: 0
		 * PCO phase: 0
	Extended capabilities: Extended Channel Switching, BSS Transition, 6
	WMM:	 * Parameter version 1
		 * BE: CW 15-1023, AIFSN 3
		 * BK: CW 15-1023, AIFSN 7
		 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
		 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
BSS b8:27:eb:f9:b2:84(on wlp6s0b1)
	TSF: 18978998423 usec (0d, 05:16:18)
	freq: 2412
	beacon interval: 100 TUs
	capability: ESS Privacy SpectrumMgmt ShortSlotTime (0x0511)
	signal: -55.00 dBm
	last seen: 1336 ms ago

[BenutzerGa4gooPh]

Jana, das ist das Resultat wenn ich KEINE Verbindung zum Hotspot bekomme...

Hier ist das Resultat wenn ich verbunden bin:

Also keine Scan-Ergebnisse für den Hotspot im Fehlerfall???

[thiro]

Doch Jana,

das erste Resultat war von heute Morgen als ich nicht verbinden konnte.
das zweite ist von später nachdem ich das Handy rebootet habe und danach eben verbinden konnte und auch verbunden war...

[BenutzerGa4gooPh]

Na, dann wird dein Smartphone im Ruhezustand oder wenn kein Client verbunden ist (Smartphone mitgenommen, damit zu weit weit vom Linux-Client entfernt), den Hotspot einfach abschalten?! Erscheint mir sehr sinnvoll. Der Hotspot muss dann sicher wieder eingeschaltet werden - dafür ist doch bestimmt kein Reboot des Smartphones nötig?! Nimm das Ding einfach nochmal mit und wenn du zurückkehrst, schalte nur den Hotspot ein oder aus/ein!

Habe kein Smartphone, dazu können andere wohl mehr sagen.

[thiro]

Nee nee Jana, so einfach ist das nicht...

Hier geht es ja um "das erste Mal". Sprich wenn ich morgens ankomme, schalte ich den Hotspot ein, boote das Netbook, und wenn es dann einmal bis läuft, dann kann ich auch zwischenzeitig weg gehen mit dem Handy, und wenn ich dann wieder komme geht es immer noch. Einfach wieder auf das Netzwerk vom Hotspot klicken und schon verbindet er wieder... Manchmal bin ich auch so lange weg, dass das Handy den Hotspot ausschaltet, und wenn ich dann zurück komme schalte ich den Hotspot wieder ein und verbinde wieder normal.

Manchmal komme ich aber auch an, (wie heute wieder) und ich klicke auf das Netzwerk vom Hotspot und er verbindet nicht. Dann kann ich das 100 Mal versuchen und es geht 100 Mal nicht.

Dann habe ich wie bereits erwähnt mehrere Möglichkeiten:
- Manchmal hilft es nur das Handy neu zu starten
- Manchmal hilft es nur das Netbook neu zu starten
- Manchmal muss ich BEIDES neu starten
- Manchmal hilft alles nichts und ich muss per USB-Kabel Tethering machen.

Aber 2 Sachen sind sicher:
- Es hat noch NIE geholfen wenn ich nur den HotSpot aus- und eingeschaltet habe und es hat auch noch NIE geholfen wenn ich nur das WLAN am Netbook aus- und eingeschaltet habe...
- Und wenn es morgens "beim ersten Mal" klappt, dann klappt es für gewöhnlich den Rest des Tages auch.

[MSfree]

Na, dann wird dein Smartphone im Ruhezustand oder wenn kein Client verbunden ist (Smartphone mitgenommen, damit zu weit weit vom Linux-Client entfernt), den Hotspot einfach abschalten?!

Oder die Software ist schlicht Mist. Ich weiß leider nicht, ob Android auch hostapd verwendet, was ansich gut funktioniert, oder ob die irgendetwas in Java nachprogrammiert haben.

Habe kein Smartphone, dazu können andere wohl mehr sagen.

Habe zwar ein Smartphone, aber nicht mit Android.

Bei meinem Telefon geht der Hotspot jedenfalls nicht in den Standby oder schaltet sich ab. Mir ist allerdings aufgefallen, daß (bei meinem Telefon) der Zeitabstand zwischen zwei Beaconframes viel größer ist als bei gewöhnlichen APs (und Platikroutern). Vermutlich spart das Strom, bedeutet aber auch, daß es länger dauert, bis ein Client verbunden ist, weil der Client länger und häufiger scannen muß, bis er einen ihm bekannten AP findet.

[BenutzerGa4gooPh]

Nichtsdestotrotz sendet beim TO der Hotspot im "Fehlerfall" nicht. So habe ich zumindest die komplett fehlende Scanausgabe im "Fehlerfall" verstanden. Man könnte das mit einem weiteren Client / zusätzlichem Smartphone verifizieren - Android-App "Wifi Analyzer". Das zusätzliche Smartphone muss dazu nicht verbunden sein, nur WLAN-Sender anzeigen.

[thiro]

Hallo,

Also Heute ist es wieder ganz schlimm...

Ich schalte immer zuerst den hotSpot ein und dann erst das Netbook, andersrum funktioniert es irgendwie nie (beim ersten booten am Tag). Danach wenn der HotSpot mal weg ist und wieder kommt ist es egal, es zählt immer nur der erste Verbinden pro Tag...

Heute habe ich den HotSpot gestartet, das Netbook gebootet, keine Verbindung möglich.
Dann habe ich das Handy neugestartet, keine Verbindung möglich.
Dann habe ich das Netbook rebootet, keine Verbindung möglich.
Dann habe ich das Netzwerk aus der "Bekannte Netzwerke" Liste gelöscht und nochmal neu verbunden --> OK

Dann kam ein Stromausfall (mein Netbook hat keinen Akku mehr da defekt) --> Also alles wieder von vorne.
Jetzt habe ich das Handy schon ein zweites mal rebootet und auch das Netbook nochmal 2 mal neu gebootet und ich kann einfach nicht mehr auf den HotSpot verbidnen...

Ich habe jetzt mal den ganzen Auszug kopier wenn es NICHT möglich ist zu verbinden... Es sind jetzt 2 Netzwerke drin, weil es eben der GANZE Auszug ist und hier 2 Netzwerke verfügbar sind.

"Galaxy" ist der HotSpot und "AELMP3" ist ein RasPi Zero der als MP3-Player dient. Das Netbook war jedoch noch NIE damit verbunden und soll auch NUR mit Galaxy verbunden werden.

Code: Alles auswählen

root@NETBOOK:/home/dl2roy# iw dev wlp6s0b1 scan
BSS 06:d6:aa:17:5d:70(on wlp6s0b1)
	TSF: 720299926 usec (0d, 00:12:00)
	freq: 2437
	beacon interval: 100 TUs
	capability: ESS Privacy SpectrumMgmt ShortSlotTime RadioMeasure (0x1511)
	signal: -51.00 dBm
	last seen: 344 ms ago
	Information elements from Probe Response frame:
	SSID: Galaxy
	Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 
	DS Parameter set: channel 6
	Country: LU	Environment: Indoor/Outdoor
		Channels [1 - 13] @ 20 dBm
	Power constraint: 0 dB
	TPC report: TX power: 19 dBm
	ERP: <no flags>
	Extended supported rates: 6.0 9.0 12.0 48.0 
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: PSK
		 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
	HT capabilities:
		Capabilities: 0x1ad
			RX LDPC
			HT20
			SM Power Save disabled
			RX HT20 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 8 usec (0x06)
		HT RX MCS rate indexes supported: 0-15
		HT TX MCS rate indexes are undefined
	HT operation:
		 * primary channel: 6
		 * secondary channel offset: no secondary
		 * STA channel width: 20 MHz
		 * RIFS: 1
		 * HT protection: no
		 * non-GF present: 0
		 * OBSS non-GF present: 0
		 * dual beacon: 0
		 * dual CTS protection: 0
		 * STBC beacon: 0
		 * L-SIG TXOP Prot: 0
		 * PCO active: 0
		 * PCO phase: 0
	Extended capabilities: Extended Channel Switching, BSS Transition, 6
	WMM:	 * Parameter version 1
		 * BE: CW 15-1023, AIFSN 3
		 * BK: CW 15-1023, AIFSN 7
		 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
		 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
BSS b8:27:eb:f9:b2:84(on wlp6s0b1)
	TSF: 1223373197 usec (0d, 00:20:23)
	freq: 2412
	beacon interval: 100 TUs
	capability: ESS Privacy SpectrumMgmt ShortSlotTime (0x0511)
	signal: -53.00 dBm
	last seen: 624 ms ago
	Information elements from Probe Response frame:
	SSID: AELMP3
	Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 
	DS Parameter set: channel 1
	TIM: DTIM Count 1 DTIM Period 2 Bitmap Control 0x0 Bitmap[0] 0x0
	Country: US	Environment: Indoor/Outdoor
		Channels [1 - 11] @ 30 dBm
	Power constraint: 0 dB
	TPC report: TX power: 19 dBm
	ERP: <no flags>
	Extended supported rates: 6.0 9.0 12.0 48.0 
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: PSK
		 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
	HT capabilities:
		Capabilities: 0x21
			RX LDPC
			HT20
			Static SM Power Save
			RX HT20 SGI
			No RX STBC
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 16 usec (0x07)
		HT Max RX data rate: 384 Mbps
		HT RX MCS rate indexes supported: 0-7
		HT TX MCS rate indexes are undefined
	HT operation:
		 * primary channel: 1
		 * secondary channel offset: no secondary
		 * STA channel width: 20 MHz
		 * RIFS: 1
		 * HT protection: no
		 * non-GF present: 1
		 * OBSS non-GF present: 0
		 * dual beacon: 0
		 * dual CTS protection: 0
		 * STBC beacon: 0
		 * L-SIG TXOP Prot: 0
		 * PCO active: 0
		 * PCO phase: 0
	Extended capabilities: Extended Channel Switching
	WMM:	 * Parameter version 1
		 * u-APSD
		 * BE: CW 15-1023, AIFSN 3
		 * BK: CW 15-1023, AIFSN 7
		 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
		 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
root@NETBOOK:/home/dl2roy#

Kennt denn niemand ein "System" das eine stabile Verbindung herstellen kann. Evtl. eine separate App fürs Handy mit einem separaten Netzwerkmanager für Debian, die eine stabile Verbindung untereinander herstellen können?

[pferdefreund]

Einfach mal die Energie-Einstellungen im Handy prüfen. Zumindest bei Android 7 - wie es früher war, weiß ich nicht mehr, kann man
Apps auswählen, die grundsätzlich von jeder Energiesparaktion ausgenommen werden. Hab ich z. B für Gnuroot.debian gemacht, damit meine simulierte S/370 (IBM-Großrechner) stabil durchläuft und nicht ab und an die Systemkonsole verliert. Eventuell dazu noch die Wakelock-App und hier partial wakelock aktivieren. Die gibts im Playstore und sorgt dafür dass zumindest die CPUs nicht schlafen gehen.

[MSfree]

Einfach mal die Energie-Einstellungen im Handy prüfen.

Was soll denn die Energieeinstellung bewirken, wenn der Hotspot selbst kurz nach eine Reboot nichtmal erreichbar ist? Da schläft beim Telefon noch nichts, das System ist zu diesem Zeitpunkt nämlich in der Regel noch mit einigen Sachen beschäftigt.

Ich würde erstmal versuchen, das fehlerhafte Gerät eindeutig zu identifizieren. Im Moment habe ich den Eindruck, ihr dreht euch im Kreis. Mal hier ein Reboot, mal dort ein Neustart eines Dienstes, mal ein löschen der Verbindung. Das ist alles andere als systematisch.

Ich würde den Laptop erstmal an verschiedenen WLAN-Hotspots ohne löschen der Verbindungsdaten und ohne Reboot testen. Wenn das nämlich klappt, ist das Smartphone schuld. Wenn das nicht klappt, ist igendwas am Laptop schuld.