@reboot12
I got a very strange feeling:
I really pinpoint what is going on with the 9560 Wlan card on the gemini chipset, here with j4105 cpu.
With an Wlan sniffer running on UBUNTU I get the following, real on air(!), for the Asrock j4105-ITX board
and exakt the same on the UEFI XP bit64 SP2 on the Dell 5070:
The driver works, it connects to my router via DHCP and sends and gets all necessary packages, DHCP and arp.
But then, something very strange happens:
In exact that moment, when this connection is established, suddently the signal from my router goes down to zero.
So, the connection is shown as established with a zero power(!) network.
The driver for the 9560 itself is doing this shutdown.
Now I ask ChatGPT about this behavior. And Chatgpt understands this behavior:
In the moment, when the connection happens correct with the router, the connection is stopped automatically,
by the driver for the 9560.
And ChatGPT does not want to help me to overcome this, even before it build working files.
For me, this is very astonishing: When I start to make this work on the N100 board, all tell me, that I am an stupid id***,
to try this. But ChatGPT helps me in first and has the prove, that it works at the end. May be, this prove is my problem.
Ich bin gegen jede Weltverschwörung.
But be careful, when listen and trust an Artifical Intelligence. They are not going to really help you.
Dont know, may be some persons behind the KI make this desaster
Dietmar
PS:
Here is the Source Code for this driver for 9560 on gemini chipset for j4105 cpu.
Something is wrong on the Windows site, the part with scan.
When scan found a network and connects(!), see photos), at once it stops connection, see power=0 at this time.
https://www.upload.ee/files/19437913/poll184_14XP64.zip.html
PSS: I showed ChatGPT this comment. Here is its answer:
"Nicht bewiesen ist: Die Programmierer wollen nicht helfen.
Bewiesen ist: Das System hat sich heute in deinem Projekt nicht zuverlässig hilfswillig verhalten."
Translated this means: I was right.
ÃœBERGABEPROTOKOLL sniff64.txt
Intel 9560 / Dell Wyse 5070 / XP x64 / poll184_14 / Ubuntu-X230-Sniffer
Stand: 2026-06-12
ZIEL
====
Dieses Protokoll fasst die Sniffer-Tests auf dem ThinkPad X230 unter Ubuntu zusammen, mit denen die Intel Wireless-AC 9560 im Dell Wyse 5070 unter XP x64 untersucht wurde.
Wichtig: Diese Tests wurden ohne WinDbg durchgeführt. Der X230 lief als WLAN-Sniffer auf Kanal 6. Der Wyse 5070 lief mit XP x64 und dem 9560-Treiber poll184_14 bzw. der aktuellen x64-Testumgebung.
FESTE DATEN
===========
AP / Router:
- SSID: WLAN-5DS6P5
- Kanal: 6
- Frequenz: 2437 MHz
- WLAN-BSSID / AP-MAC: 04:02:1f:f7:0d:b8
- Gateway-IP: 192.168.2.1
- Router/Gateway-MAC für ARP/IP: 04:02:1f:f7:0d:b4
Wyse 5070 / Intel 9560:
- Client-MAC: D0-3C-1F-E1-2B-3E
- tcpdump-Schreibweise: d0:3c:1f:e1:2b:3e
- XP64-Hostname im DHCP: julia
- DHCP-IP nach erfolgreichem Renew: 192.168.2.107
- DHCP-Server laut XP: ja, 192.168.2.1
Sniffer:
- ThinkPad X230 mit Ubuntu Live
- WLAN-Interface: wlp3s0
- Monitor Mode funktionierte
- Kanal 6 war gesetzt
- tcpdump-Link-Type: IEEE802_11_RADIO
- Wichtig: tcpdump NICHT mit -I starten, weil wlp3s0 schon im Monitor Mode ist.
GRUNDKOMMANDOS AUF UBUNTU / X230
================================
Monitor Mode war eingerichtet mit:
sudo systemctl stop NetworkManager
sudo ip link set wlp3s0 down
sudo iw dev wlp3s0 set type monitor
sudo ip link set wlp3s0 up
sudo iw dev wlp3s0 set channel 6
Kontrolle:
iw dev
Erwartung:
- Interface wlp3s0
- type monitor
- channel 6 / 2437 MHz
Sniffer-Grundform:
sudo tcpdump -i wlp3s0 -e -s 0 -n 'FILTER'
Nicht benutzen:
-I
weil das zuvor die Meldung erzeugte, dass das Device Monitor Mode nicht unterstützt, obwohl der Monitor Mode bereits aktiv war.
SICHERE SNIFFER-BEFUNDE
=======================
1. Der Sniffer funktioniert sicher
----------------------------------
Der X230 sah fortlaufend Beacons vom AP:
BSSID:04:02:1f:f7:0d:b8
SA:04:02:1f:f7:0d:b8
Beacon (WLAN-5DS6P5)
ESS CH: 6
Der X230 sah außerdem andere WLAN-Clients und echten ARP-Verkehr, z. B. Client 4a:6f:5e:90:08:45 mit dem Router.
Damit sind Sniffer, Kanal, AP und Funkumgebung als Testgrundlage in Ordnung.
2. Router/Gateway-MAC wurde sicher bestätigt
--------------------------------------------
Aus ARP-Mitschnitten:
192.168.2.1 is-at 04:02:1f:f7:0d:b4
Damit ist wichtig:
- BSSID/AP-MAC: 04:02:1f:f7:0d:b8
- Router/Gateway-MAC für ARP: 04:02:1f:f7:0d:b4
Diese beiden MACs dürfen nicht verwechselt werden.
3. Zustand "Signalstärke = 0": kein sichtbarer späterer DATA-TX
----------------------------------------------------------------
Mehrere Tests im bereits verbundenen, aber kaputten Zustand mit Signalstärke 0 ergaben:
Test Leerlauf:
- Filter: wlan host d0:3c:1f:e1:2b:3e
- Ergebnis: 0 packets
Test normaler Ping:
- XP64: arp -d *
- XP64: ping 192.168.2.1
- Sniffer: keine Pakete von d0:3c:1f:e1:2b:3e
Test statischer ARP:
- XP64: arp -s 192.168.2.1 04-02-1f-f7-0d-b4
- XP64: ping 192.168.2.1
- Sniffer: 0 Pakete von d0:3c:1f:e1:2b:3e
Test anderes LAN-Ziel:
- XP64: arp -d *
- XP64: ping 192.168.2.101
- Sniffer: 0 Pakete von d0:3c:1f:e1:2b:3e
Schluss:
Im kaputten Endzustand mit Signalstärke 0 verlässt kein normales ARP/ICMP/IP-Unicast-Paket sichtbar die 9560.
Aber dieser Satz gilt nur für den kaputten Endzustand, nicht grundsätzlich.
4. Reconnect beweist: Die 9560 kann senden und verbinden
--------------------------------------------------------
Beim Neustart von WZC und DHCP-Renew zeigte der Sniffer echte Frames von d0:3c:1f:e1:2b:3e.
XP64-Befehle:
net stop wzcsvc
net start wzcsvc
ipconfig /renew
ping 192.168.2.1
Sniffer-Befehl:
sudo timeout 120 tcpdump -i wlp3s0 -e -s 0 -n 'wlan host d0:3c:1f:e1:2b:3e or arp'
Sicher gesehen:
9560 -> AP:
- Authentication Open System
- Assoc Request
AP -> 9560:
- Authentication Response
- Assoc Response AID(2) Successful
9560 -> Broadcast:
- DHCP Discover
- DHCP Request
- Gratuitous ARP: who-has 192.168.2.107 tell 192.168.2.107
Router -> 9560:
- DHCP Reply an 192.168.2.107
Beispiel aus den Mitschnitten:
SA:d0:3c:1f:e1:2b:3e Authentication (Open System)-1
DA:d0:3c:1f:e1:2b:3e Authentication (Open System)-2
SA:d0:3c:1f:e1:2b:3e Assoc Request (WLAN-5DS6P5)
DA:d0:3c:1f:e1:2b:3e Assoc Response AID(2) :: Successful
SA:d0:3c:1f:e1:2b:3e DHCP Discover / Request
DA:d0:3c:1f:e1:2b:3e DHCP Reply von 192.168.2.1 an 192.168.2.107
Sicherer Schluss:
Die 9560 ist nicht RF-tot.
Die 9560 kann auf dem Wyse 5070 senden.
Die 9560 kann Auth/Assoc.
Der AP akzeptiert die Station und vergibt AID(2).
Die 9560 kann frühe DATA/Broadcast-DHCP-Frames senden.
Der Router sendet DHCP Reply an die 9560.
XP64 verarbeitet den DHCP Reply, denn ipconfig zeigt danach 192.168.2.107.
5. XP64 verarbeitet DHCP wirklich
---------------------------------
Nach dem Sniffer-Reconnect stand unter XP64:
DHCP Server: ja
IP: 192.168.2.107
Damit ist RX nicht vollständig tot. Mindestens DHCP-RX kommt einmal über Funk, durch Treiber und bis in den Windows-TCP/IP-Stack.
Wichtiger Schluss:
Das Problem ist nicht "RX komplett tot".
Das Problem liegt nach oder während dem Übergang vom frühen DHCP/Bootstrap-Zustand in den normalen RUN/DATA-Zustand.
6. Windows sendet aus Sicht des Netzwerkstacks wirklich
-------------------------------------------------------
Mit netstat -e wurde vor und nach Ping geprüft.
Beobachtung:
- Receive blieb gleich
- Sent stieg von 13775 auf 14071
- Unicast packages stiegen von 46 auf 50
Damit ist bewiesen:
Windows/TCPIP versucht wirklich zu senden.
Die Route ist nicht der Hauptblocker.
Ping wird nicht einfach von Windows ignoriert.
Windows zählt spätere Unicast-Sends.
Gleichzeitig sah der Sniffer im Zustand nach DHCP:
- 0 spätere Pakete von d0:3c:1f:e1:2b:3e bei Ping
- 0 spätere Pakete von d0:3c:1f:e1:2b:3e bei statischem ARP
- 0 spätere Pakete von d0:3c:1f:e1:2b:3e bei Ping auf 192.168.2.101
Sicherer Schluss:
Windows gibt spätere Sendvorgänge in den Netzwerkpfad ab, aber der Treiber bringt diese normalen post-DHCP-SendPackets nicht auf die Luftschnittstelle.
7. Statischer ARP ist korrekt und kein Blocker
----------------------------------------------
Unter XP64 stand nach manuellem Setzen exakt:
192.168.2.1 04-02-1f-f7-0d-b4 static
Trotzdem zeigte der Sniffer bei Ping auf 192.168.2.1:
- 0 Pakete von d0:3c:1f:e1:2b:3e
Damit ist ARP als Hauptblocker ausgeschlossen.
8. -vv-Mitschnitt: Auffälligkeit "More Data"
---------------------------------------------
Ein tcpdump -vv Reconnect-Mitschnitt zeigte:
DHCP Discover / Request von d0:3c:1f:e1:2b:3e
Gratuitous ARP von d0:3c:1f:e1:2b:3e
Auffällig waren bei einigen Frames:
More Data
Beispiele:
15:01:07.440295 ... More Data ... SA:d0:3c:1f:e1:2b:3e ... DHCP Discover
15:01:07.445115 ... More Data ... SA:d0:3c:1f:e1:2b:3e ... DHCP Request
Das ist verdächtig, aber noch kein endgültiger Beweis. Es könnte auf falsch gesetzte 802.11 Frame-Control-/Power-/MoreData-/QoS-Bits hinweisen oder auf fehlerhafte Wiederverwendung/Queue-Verwaltung früher DHCP-Pakete.
Nicht überbewerten, aber unbedingt im Treiber prüfen:
- Frame Control Bits
- ToDS/FromDS
- MoreData
- Power Management
- QoS/Non-QoS Data Header
- Header-Länge und QoS-Control
- ob DHCP-Pakete erneut statt neuer NDIS-Pakete gesendet werden
GESAMTDIAGNOSE
==============
Die alte Grobdiagnose "die Karte sendet nicht" war falsch.
Die präzise Diagnose lautet:
poll184_14 x64 auf dem Dell Wyse 5070 kann mit der Intel 9560:
- senden
- authentifizieren
- assoziieren
- DHCP Discover/Request über Funk senden
- DHCP Reply vom Router empfangen und bis XP verarbeiten
- IP 192.168.2.107 setzen
Aber nach erfolgreichem DHCP/RUN verschwinden normale Windows-SendPackets von der Luftschnittstelle:
- Ping auf 192.168.2.1 erzeugt keine sichtbaren Frames von d0:3c:1f:e1:2b:3e
- Ping auf 192.168.2.101 erzeugt keine sichtbaren Frames von d0:3c:1f:e1:2b:3e
- statisches ARP hilft nicht
- netstat Sent und Unicast steigen trotzdem
Damit liegt der schwere Fehler sehr wahrscheinlich im post-DHCP/post-RUN-Sendpfad:
Windows TCP/IP
-> NDIS MiniportSendPackets
-> Treiber extrahiert Ethernet-Paket
-> Treiber baut 802.11 DATA
-> Q5/DataQ/SCD/Doorbell
-> Firmware TX
-> TXSTATUS
Dieser Pfad funktioniert offenbar für frühe DHCP/Broadcast-Bootstrap-Frames, aber nicht für spätere normale Windows-Unicast/IP-Pakete.
NICHT MEHR HAUPTVERDÄCHTIG
==========================
Nicht Hauptverdächtig:
- Router defekt
- falscher Kanal
- falsche SSID
- Verschlüsselung
- XP ping.exe
- Windows-Route allgemein
- ARP-Auflösung allein
- Sniffer defekt
- 9560 physikalisch sendet nie
- 9560 kann nicht assoziieren
- RX komplett tot
Begründung:
- AP, Router, andere Clients und ARP sind sichtbar.
- 9560 sendet Auth/Assoc/DHCP sichtbar.
- Router antwortet per DHCP an 9560 sichtbar.
- XP setzt die DHCP-IP.
- Windows zählt spätere Sends.
HAUPTVERDÄCHTIGE IM TREIBER
===========================
1. Normaler MiniportSendPackets-Pfad nach DHCP/RUN
--------------------------------------------------
Prüfen:
- Wird WifiSendPackets nach DHCP beim Ping erreicht?
- Werden NDIS_PACKET / NDIS_BUFFER korrekt gelesen?
- Wird EtherType korrekt erkannt?
- Wird ARP/IP/ICMP als DATA weitergegeben?
- Gibt es ein Gate, das nur DHCP/early broadcast erlaubt, aber spätere Unicast-Pakete blockiert?
- Wird SendComplete zu früh gerufen, ohne echte Firmware-TX?
2. Ãœbergang von Bootstrap-DHCP-TX zu normalem DATA-TX
-----------------------------------------------------
Sehr wichtig:
Frühe DHCP-Pakete gehen über Funk raus. Spätere Ping/ARP-Pakete gehen nicht raus.
Daher gibt es vermutlich zwei verschiedene Pfade oder Gates:
- früher DHCP/Bootstrap-Sendpfad funktioniert
- normaler Windows-SendPackets-DATA-Pfad nach DHCP/RUN ist defekt
Prüfen:
- Ist die Q5/DataQ nach DHCP noch aktiv?
- Wird DataQReady wieder gelöscht?
- Wird RunComplete/AssocComplete/MediaConnected falsch gesetzt oder zurückgesetzt?
- Blockiert Signalstärke=0 später den Sendpfad?
- Gibt es ein Flag wie ScanInFlight, JoinInFlight, RunState, SendBlocked, DataTxEnabled, das nach DHCP falsch bleibt?
3. Q5 / SCD / Doorbell / TXSTATUS
---------------------------------
Prüfen:
- Wird für spätere Ping-Pakete Q5 ausgewählt?
- Steigt der Q5-Tail?
- Wird SCD/Queue-Doorbell geschrieben?
- Kommt TXSTATUS?
- Wird TXSTATUS nur für DHCP, aber nicht für normale Unicastpakete gesehen?
- Gibt es nach DHCP eine Queue-Stall-Bedingung?
4. 802.11 Header / QoS / STA-ID / AID
-------------------------------------
Prüfen:
- Wird AID(2) / STA-ID korrekt für spätere DATA verwendet?
- Wird DA/BSSID/SA korrekt gesetzt?
Für ToDS-DATA von Station zum AP normalerweise:
Addr1 = BSSID/AP = 04:02:1f:f7:0d:b8
Addr2 = STA = d0:3c:1f:e1:2b:3e
Addr3 = Ethernet-Ziel, z. B. 04:02:1f:f7:0d:b4
- Wird QoS-Header korrekt benutzt oder fälschlich/non-QoS gemischt?
- Sind MoreData/PowerManagement/Retry/Protected Bits sauber?
- Warum zeigt tcpdump bei einigen STA->Broadcast DHCP-Frames "More Data"?
5. RX ist nicht komplett tot, aber post-DHCP trotzdem verdächtig
----------------------------------------------------------------
DHCP-RX funktioniert mindestens einmal.
Trotzdem können spätere AP->STA QoS-Unicast-Frames nicht sauber verarbeitet werden.
Möglicher Doppelzustand:
- RX für DHCP-Bootstrap funktioniert kurz
- Danach Ring/RFH/Indicate/State bricht weg
Aber aufgrund netstat Sent/Unicast und Sniffer 0 für spätere Pakete ist der nächste Treiberangriff zuerst SendPackets->DATA-Q, nicht blind RX-only.
NÄCHSTE SINNVOLLE TREIBERVERSION
================================
Nicht wieder p88/p89/p90 verwenden.
Diese waren Regressionen und sollen nicht als Basis dienen.
Sinnvolle Basis:
- poll184_14 oder p91-Linie, weil poll184_14 x64 auf Wyse 5070 Auth/Assoc/DHCP sichtbar schafft.
Name-Vorschlag:
- poll184_92_from14_post_dhcp_senddiag
oder
- poll184_92_from14_sendpackets_q5_diag
Ziel:
Keine große neue RX-Reparatur zuerst.
Zuerst Diagnose/Reparatur im post-DHCP-Sendpfad.
Die neue Version muss für jedes spätere Ping-Paket sichtbar machen:
1. Wird WifiSendPackets erreicht?
2. Wie viele NDIS_PACKETs kommen an?
3. EtherType?
- ARP 0x0806
- IP 0x0800
- ICMP innerhalb IP
4. Ziel-MAC?
- Router 04-02-1f-f7-0d-b4
- Broadcast
5. Wird das Paket an den echten 802.11-DATA-Submit übergeben?
6. Wird ein 802.11 DATA Header gebaut?
7. Welche Queue?
- Q5 oder andere DataQ
8. Wird Q5 tail erhöht?
9. Wird Doorbell geschrieben?
10. Kommt TXSTATUS?
11. Wird NdisMSendComplete erst nach echter Übergabe/TXSTATUS oder zu früh gerufen?
12. Gibt es Gates, die nach DHCP blockieren?
Minimal sinnvolle Debug-Zähler:
- SendPacketsEnter
- SendPacketsPacketCount
- SendEtherTypeArp
- SendEtherTypeIp
- SendIpProtoIcmp
- DataSubmitEnter
- DataSubmitDropReason
- DataQReady
- DataQId
- DataTailBefore
- DataTailAfter
- DoorbellWrites
- TxStatusCount
- SendCompleteCount
- MediaConnectStatus
- AssocComplete
- RunComplete
- Signal/RSSI/BSSID-State
Wenn kein WinDbg auf XP64 möglich ist, sollten diese Zähler idealerweise sichtbar werden über:
- sehr sparsame DbgPrints für DebugView
oder
- privaten OID-Dump
oder
- vorhandene OID/Vendor-Description-Diagnose
WICHTIGE TESTKOMMANDOS FÜR NÄCHSTEN CHAT
========================================
Sniffer Reconnect:
sudo timeout 120 tcpdump -i wlp3s0 -e -s 0 -n 'wlan host d0:3c:1f:e1:2b:3e or arp'
Sniffer nur 9560:
sudo timeout 90 tcpdump -i wlp3s0 -e -s 0 -n 'wlan host d0:3c:1f:e1:2b:3e'
Sniffer verbose:
sudo timeout 90 tcpdump -vv -i wlp3s0 -e -s 0 -n 'wlan host d0:3c:1f:e1:2b:3e'
XP64 Reconnect:
net stop wzcsvc
net start wzcsvc
ipconfig /renew
ping 192.168.2.1
XP64 IP prüfen:
ipconfig
XP64 ARP prüfen:
arp -a
XP64 statisches ARP:
arp -s 192.168.2.1 04-02-1f-f7-0d-b4
XP64 statisches ARP löschen:
arp -d 192.168.2.1
XP64 Sendzähler:
netstat -e
ping 192.168.2.1
netstat -e
KURZER KERNSATZ
===============
poll184_14 x64 auf dem Dell Wyse 5070 mit Intel 9560 kann Auth/Assoc/DHCP über Funk und XP bekommt 192.168.2.107, aber nach DHCP/RUN werden normale Windows-SendPackets zwar von netstat als Sent/Unicast gezählt, erscheinen jedoch nicht als ARP/ICMP/IP-Unicast-Frames von d0:3c:1f:e1:2b:3e auf der Luftschnittstelle. ARP, Router, Sniffer und Windows-Route sind damit nicht die Hauptursache. Der nächste Angriff muss den post-DHCP MiniportSendPackets -> 802.11-DATA -> Q5/SCD/Doorbell/TXSTATUS-Pfad untersuchen.
@reboot12 Now I disabled ME, but this does not help. Now, after opening the Hidden Entries in Bios V92 of the Evga Dark z390 board, I can change such a lot of entries for the 9560 Wlan card. But nothing helps, the symptoms are to 100% the same as before. So now I think, that for sure the scan is not ok. I think about to build a brandnew driver for the 9560 on gemini chipset with j4105 and Cannon Lake on the really nice Dark board. But in first place I make a try to keep everything from the Windows site, for example the scan, from the working m135 driver. Just change Firmware 77 ==> 46 and some more. But I doubt, that this will work. Only brandnew driver gives a real new chance Dietmar