Fritz!App WLAN App

Wer im privaten Umfeld sein WLAN messen möchte, kann sich der "Fritz!Box WLAN" App bedienen. Im Rahmen meiner End2End-Checks wollte ich natürlich mal sehen ,was technisch im Hintergrund passiert. Hat die Fritz!Box eine "Test-Gegenstelle", die ich ebenfalls benutzen kann?

App installieren

Die App gibt es sowohl für IOS als auch Android:

Es gibt aber keine Version für Windows Desktops. Ich habe daher die Capture-Funktion meiner Fritz!Box genutzt, um der App auf die Finger zu schauen, welche Pakete übersendet werden. Die ein oder andere Überraschung war schon dabei.

Ähnliche Programme gibt es z.B. auch von Ubiquiti (WiFiMan https://blog.ui.com/2018/12/11/introducing-wifiman/), Deutsche Glasfaser DG Heimnetz https://www.deutsche-glasfaser.de/service/app-familie/)

Beispielausgaben

Zuerst habe ich auf dem Smartphone mehrere Umgebungen abgeprüft und schon die erste Ausgabe war ganz nett: Sobald ich im WLAN war, hat mit die App einige Details zur Fritz!Box ohne weitere Anmeldung angezeigt. Hier mal drei Umgebungen:

  • Vodafone Kabel mit 30/2 Megabit
  • Deutsche Glasfaser mit 1 Gigabit Uplink (aber real nur 400/100 Megabit)
  • Telekom-DSL

Die Daten erhalten ich sogar, wenn ich über andere WLAN-Systeme eingebucht bin solange die App mit der Fritz!Box kommunizieren kann.

Daten per UPNP

Über die URL http://fritz.box/html/capture.html kann ich nach Anmeldung ein Capture starten. Bei mir musste ich ETH0 auswählen, da mein WLAN nicht über die Fritz!Box bereitgestellt wird. Interessant waren die Pakete des Clients, die ich aber schon auf anderen Seite beschrieben haben.

Die App hat folgende URLs genutzt, um der Fritz!Box die Details zu entlocken:

1283 0.001 6.993 192.168.178.46 192.168.178.1 HTTP     310 64 GET /jason_boxinfo.xml HTTP/1.1
1314 0.000 7.184 192.168.178.46 192.168.178.1 HTTP     250 64 GET /fboxdesc.xml HTTP/1.1
1331 0.000 7.252 192.168.178.46 192.168.178.1 HTTP     255 64 GET /tr64desc.xml HTTP/1.1
1343 0.009 7.269 192.168.178.46 192.168.178.1 HTTP     261 64 GET /deviceinfoSCPD.xml HTTP/1.1
1354 0.001 7.289 192.168.178.46 192.168.178.1 HTTP/XML 548 64 POST /upnp/control/deviceinfo HTTP/1.1
1376 0.002 7.340 192.168.178.46 192.168.178.1 HTTP     311 64 GET /fboxSCPD.xml HTTP/1.1
1390 0.000 7.405 192.168.178.46 192.168.178.1 HTTP/XML 593 64 POST /upnp/control/fritzbox HTTP/1.1
1421 0.003 7.488 192.168.178.46 192.168.178.1 HTTP     310 64 GET /igddesc.xml HTTP/1.1
1432 0.001 7.500 192.168.178.46 192.168.178.1 HTTP     314 64 GET /igdicfgSCPD.xml HTTP/1.1
1442 0.001 7.519 192.168.178.46 192.168.178.1 HTTP/XML 644 64 POST /igdupnp/control/WANCommonIFC1 HTTP/1.1
1468 0.010 7.608 192.168.178.46 192.168.178.1 HTTP/XML 626 64 POST /igdupnp/control/WANIPConn1 HTTP/1.1

Die POST-Requests haben noch unterschiedliche XML-Payloads zur Anforderung der gewünschten Daten.

Externe Bandbreite

Besonders interessant fand ich auch die Anfrage nach der externen Bandbreite, die bei meinem Gigabit-Link wie folgt ermittelt wurde. Alle Requests gingen auf den Port 49000 der Fritz!Box:

POST /igdupnp/control/WANCommonIFC1
SOAPACTION: urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1#GetCommonLinkProperties
Content-Length: 201
Host: 192.168.178.1:49000
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: FRITZ-App-WLAN/2.10.0 (23360) UPnP/1.0 Android/11 (samsung; SM-P610)
Content-Type: text/xml; charset="utf-8"
Accept: text/xml

<?xml version="1.0"?>
   <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" 
    s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <s:Body>
         <GetCommonLinkProperties/>
      </s:Body>
   </s:Envelope>

Die Antwort darauf war dann:

HTTP/1.1 200 OK
DATE: Mon, 14 Jun 2021 14:29:09 GMT
SERVER: FRITZ!Box 7590 UPnP/1.0 AVM FRITZ!Box 7590 154.07.27
CONNECTION: keep-alive
CONTENT-LENGTH: 575
CONTENT-TYPE: text/xml; charset="utf-8"
EXT:

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope 
   xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" 
         s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <s:Body>
      <u:GetCommonLinkPropertiesResponse xmlns:u="urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1">
         <NewWANAccessType>Ethernet</NewWANAccessType>
         <NewLayer1UpstreamMaxBitRate>1000000000</NewLayer1UpstreamMaxBitRate>
         <NewLayer1DownstreamMaxBitRate>1000000000</NewLayer1DownstreamMaxBitRate>
         <NewPhysicalLinkStatus>Up</NewPhysicalLinkStatus>
      </u:GetCommonLinkPropertiesResponse>
   </s:Body>
</s:Envelope>

Das kann man natürlich auch einfach mal per PowerShell umsetzen.

$headers=@{}
$headers.Add("SOAPACTION","urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1#GetCommonLinkProperties")

$body = '<?xml version="1.0"?>
   <s:Envelope 
      xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" 
      s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <s:Body>
         <GetCommonLinkProperties/>
      </s:Body>
   </s:Envelope>'

$result= Invoke-Restmethod `
   -URI http://fritz.box:49000/igdupnp/control/WANCommonIFC1 `
   -Method POST `
   -Contenttype 'text/xml' `
   -Headers $headers `
   -Body $Body

$result.Envelope.Body.GetCommonLinkPropertiesResponse

u                             : urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
NewWANAccessType              : Ethernet
NewLayer1UpstreamMaxBitRate   : 1000000000
NewLayer1DownstreamMaxBitRate : 1000000000
NewPhysicalLinkStatus         : Up

bei DSL-Verbindungen oder Internet über Kabelfernsehen haben die Daten gut gepasst. Bei meiner Verbindung über den LAN1-Ports zu einem Glasfasermoden hat die Fritz!Box natürlich einen Gigabit-Link gesehen. Die technische Drosselung der Bandbreite kann ich so nicht sehen. Nicht umsonst kann ich bei der Fritz!Box bei der Einrichtung die niedrigere zugesicherte Regelbandbreite hinterlegen.

Damit kann die Fritz!Box dann ihre Priorisierungsregeln besser anpassen. Allerdings sind auch 400MBit/Down und 100 MBit/Up kaum zu überlasten.

Performancetest

Die "Fritz_WLAN"-App kann aber auch noch eine Durchsatzmessung durchführen. Da war ich natürlich mal gespannt, was die App hier macht. Sollte es ein Dauerping sein oder hat die Fritz!Box vielleicht sogar einen Echo-Server?

Die Messungen Werte lagen auf einem IPhone 11 bei ca. 126MBit und einem Samsung S6 Lite Tablet komme ich auch grade mal 35-55 Megabit.

Also schaue ich mit Wireshark auf das "Kabel". Der Mitschnitt per Wireshark sagt aber was ganz anderes:

Anscheinend sendet die App einfach UDP-Pakete mit 1502 Bytes an den "DISCARD"-Port der Fritz!Box auf die ersten Pakete antwortet die Fritz!Box noch freundlich mit einem "ICMP not reachable" um dieses Verhalten nach 6 Paketen einfach einzustellen. Die Fritz_WLAN-App sendet aber munter weiter Pakete. Sie misst also weder Roundtrip-Time noch Durchsatz in beide Richtungen, sondern IOS/Android senden so "schnell sie können" und das Betriebssystem bremst den Client einfach aus, wenn er zu schnell unterwegs ist.

Auf der Seite PowerShell und UDP habe ich ja beschrieben, wie per PowerShell solche UDP-Pakete gesendet werden können. Das geht dann auch unter Windows

param (
   [string]$remoteip = "fritz.box", # IP to send to 
   [int]$remoteudpport=9   ,        # port to send to
   [int]$sourceudpport = 0,         # SourcePort, maybe empty uses and available port
)

$udpClient = new-Object system.Net.Sockets.Udpclient($sourceudpport)
$byteBuffer  = [System.Byte[]]::new(1460)

$totalbytes=0
$stopwatch =  [system.diagnostics.stopwatch]::New()
$stopwatch.start()

while (!([console]::KeyAvailable)) {
   $sendbytes = $udpClient.Send($byteBuffer, $byteBuffer.length, $remoteip, $remoteudpport)
   if ($sendbytes -ne $byteBuffer.length) {
     write-host "Problem sending" -forgroundcolor yellow
   } 
   else {
      $totalbytes+=$bytebuffer.count
   }
   if ($stopwatch.Milliseconds -gt 1000) {
      Write.host "TotalBytes $($totalbytes)/Sec"
      $totalbytes=0
      $stopwatch.restart()
   }
}
[system.console]::readkey($true) | out-null

Auf meinem normalen Notebook bin ich per PowerShell und Gigabit-LAN-Kabel aber auch nur auf bescheidene 40MBit gekommen.

PS C:\temp> .\udpstorm.ps1
Init UDP-Socket
Init DataBuffer
Start Loop
TotalBytes 4250060/Sec   Total Pakets 2911
TotalBytes 4277800/Sec   Total Pakets 2930
TotalBytes 4509940/Sec   Total Pakets 3089
TotalBytes 4330360/Sec   Total Pakets 2966
TotalBytes 4355180/Sec   Total Pakets 2983
TotalBytes 4362480/Sec   Total Pakets 2988
TotalBytes 4308460/Sec   Total Pakets 2951
TotalBytes 4766900/Sec   Total Pakets 3265
TotalBytes 4870560/Sec   Total Pakets 3336

Ich kann also nicht wirklich sagen, dass PowerShell die UDP-Schnittstelle auslasten könnte und die Messung ist dahingehend also auch nur bedingt aussagekräftig. Auf IOS und Android sind die Ergebnisse auch nur Vorsicht zu betrachten.

Einschätzung

Die App ist wirklich gelungen was die Anzeige der externen Bandbreite bei DSL und Kabel-Anschlüssen anzeigt. Bei einem externen Anschluss über die LAN1 oder WAN-Buchse stimmen zumindest bei mir die Werte nicht.

Die Android-App ist deutlich leistungsfähiger und kann z.B. benachbarte WLANs samt derer Kanalbelegung und Signalstärke anzeigen. Auch kann ich durch den Raum gehen und quasi in Echtzeit die Signalstärke sehen. All das kann die IOS, vermutlich bedingt durch Einschränkungen bei Apple, leider nicht liefern. Hier gibt es nur die allgemeinen Informationen. Schade, dass AVM hier dann nicht auf die Informationen der Fritz!Box selbst zurückgreift, die ähnliche Informationen zumindest von ihrem Standort hat.

Eine Mogelpackung ist aber aus meiner Sicht die Durchsatz-Messung, die einfach nur möglichst schnell per UDP Pakete zur Fritz!Box sendet, die diese aber einfach verwirft. Über die Aussagekraft lässt sich hier streiten.

Dennoch: Auf meinem Android-Tablet gehört die Software nun zum Standardrepertoire, da Sie schnell einen Überblick schafft und sogar mit anderen Routern und WLAN-Access-Points funktioniert.

Weitere Links