AtariX => MagicOnLinux

[simonsunnyboy]

Aber ist simonsunnyboy hüben wie drüben nicht die selbe Person?
https://forum.atari-home.de/index.php?action=profile;u=1934

Ja bin ich. Habe es weitergeleitet und gesagt, daß auch ich von der Blockade dieser Domains nichts halte.
Ich bin da aber nicht Entscheider oder technischer Admin.

[Lukas Frank]

Ich habe eine web.de Mail Adresse und im Prinzip ist das doch egal man muss nur die IP freigeben also bei mir funktioniert das ...

[ragnar76]

Sodele, nach etwas längeren Meinungsverschiedenheiten zwischen Homebrew, GTK, bzip2 und freetype hab ich es geschafft mein Config Programm auch auf MacOS laufen zu lassen. Der Trick war in /opt/homebrew/opt/freetype/lib/pkgconfig/freetype2.pc die Requires so zu verändern dass dort kein bzip2 mehr steht.

[czietz]

Ich habe eine web.de Mail Adresse und im Prinzip ist das doch egal man muss nur die IP freigeben also bei mir funktioniert das ...

Es hat mit der IP-Adresse null-komma-gar-nix zu tun. Du kannst Dich mit einer web.de-Adresse nicht mehr neu registrieren bei Atari-Forum.com. Wenn Du es mir nicht glaubst, probiere es aus. Dann wirst Du die Fehlermeldung ("Spammers Domain - Stop Forum Spam!") auch sehen.

[ragnar76]

Ich habe eine web.de Mail Adresse und im Prinzip ist das doch egal man muss nur die IP freigeben also bei mir funktioniert das ...

Nicht böse gemeint aber warum hakt ihr alle auf der IP-Adresse rum. Kaum jemand hat eine statische IP die man whitelisten könnte. Jeder der noch DSL nutzt bekommt alle 24 Std. automatisch eine neue IP (Zwangstrennung). Bei FTTH sieht es etwas anders aus, Trennung täglich oder der DHCP lease bleibt so lange bestehen wie das Modem an ist.

[Ektus]

Nicht böse gemeint aber warum hakt ihr alle auf der IP-Adresse rum. Kaum jemand hat eine statische IP die man whitelisten könnte. Jeder der noch DSL nutzt bekommt alle 24 Std. automatisch eine neue IP (Zwangstrennung).

Ist zwar off topic, aber hier gibt es schon lange keine regelmäßige Zwangstrennung mehr. T-Online, VDSL 100 in Oberfranken. Verbindung steht seit 06. November, also fast ein Monat.

[AndreasK]

(...)
Ist zwar off topic, aber hier gibt es schon lange keine regelmäßige Zwangstrennung mehr. T-Online, VDSL 100 in Oberfranken. Verbindung steht seit 06. November, also fast ein Monat.

Ist der 06. November nun vor dem 6. November oder nach dem 6. November?   

Und ich könnte zwar meine gmail-Adresse ausprobieren, will ich aber nicht. Ich möchte, daß das alles über die Haupt-Email-Adresse kommt. Dazu kommt, daß gmail auf dem Telefon eine eigene Äpp ist.

[Thorsten Otto]

Ein problem in Netsurf gefunden (genauer gesagt lag das an Mintlib, die Dateinamen wie /etc/hosts nicht nach U:\etc\hosts wandelt, wenn kein Mint läuft). Fix in mintlib ist unterwegs, aber man kann sich auch behelfen indem man

Code: [Auswählen]

#_ENV UNIXMODE=brU
in MAGX.INF hinzu fügt. Hostnamen werden jetzt aufgelöst, allerdings bekomme ich immer noch Connection timeouts (auch auf nicht-SSL Verbindungen). Die Suche geht also weiter....

Immerhin sind die Farben jetzt richtig, nach den letzten Patches von Andreas.

Es gibt auch noch ein paar Redraw-Probleme wenn man das Fenster vergrössert (tritt unter XaAES komischerweise nicht auf).

[AndreasK]

(...)
Es gibt auch noch ein paar Redraw-Probleme wenn man das Fenster vergrössert (tritt unter XaAES komischerweise nicht auf).

Du kannst das sinnvolle Neuzeichnen ("smart redraw") abschalten. DRIs AES ist da einfach sehr schlecht programmiert, oder das Konzept taugt nix, das Ergebnis ist häßliches Fensterflackern, wie bei Windows damals und teilweise noch heute. Bei MacOS war das immer tadellos. Wenn die Bildfehler dann weg sind, ist das Progamm schlecht geschrieben, und XaAES kopiert DRIs Designfehler.

[Thorsten Otto]

Stimmt, damit geht es besser. Muss aber auch ein Fehler in Netsurf sein, andere Programme kommen ja auch mit Smart-Redraw zurecht.

Werde jetzt erstmal zusehen daß ich meine Patches reorganisiere, da gibt es ja ein paar Überschneidungen mittlerweile.

Treiber für MagCNet habe ich schonmal angehängt. Sourcen dafür sind auf https://github.com/th-otto/magxnet zu finden.

Die Dateien in dem Archiv sind alle GROSS geschrieben, besser wäre es allerdings, zumindest C:\ETC auf ein geeignetes Laufwerk zu legen (und dann etc_path in MAGX_RC.NET entsprechend anzupassen). Wäre vlt. eine Sache die man noch im Magic Configurator ergänzen könnte.

[AndreasK]

Stimmt, damit geht es besser. Muss aber auch ein Fehler in Netsurf sein, andere Programme kommen ja auch mit Smart-Redraw zurecht.
(..)

Richtig. Das schrieb ich ja auch sinngemäß.

DRI-AES hat nur ein Neuzeichungsrechteck, und das ist häufig noch größer als nötig. Tiefenbescheuert.

MagiC hat maximal zwei. Das macht den Bildschirmaufbau bereits wesentlich schöner, mit mäßigem Aufwand.

MacOS hat für jedes Fenster eine Liste aller sichtbaren Rechtecke, ohne Überschneidungen (paarweise disjunkt). Bei einer Fensteroperation (schieben, Größe ändern, Stapelposition ändern, öffnen, schließen) gibt es eine neue Liste. Dann wird quasi die alte Liste von der neuen subtrahiert, unter Berücksichtigung von Verschiebungen, die durch Kopieren des Bildspeichers gelöst werden, und das Ergebnis ist dann eine  beliebig lange Liste von neuzuzeichnenden Rechtecken (ebenfalls paarweise disjunkt). Das Konzept ist quasi ideal, was die Eleganz und Ruhe des Bildschirmaufbaus angeht. Kein Flackern, kein Flickern, alles weich und elegant, ohne 3D-Grafikbeschleuniger.

Windows war da irgendwie auch nicht so dolle.

Das Ganze hat sich inzwischen mit dem  "compositing window manager" erledigt, mit massivem Hardware-Einsatz; hier ist der Bildschirm eine 3D-Szene, und jedes Fenster liegt im 3D-Raum an einer bestimmten z-Position, der Inhalt ist Textur, und den Rest erlegt die 3D-Grafik-Hardware, auch mit Transparenz, Unschärfen, Abdunkeln etc.

[Thorsten Otto]

So, Patches rebased gegen deinen momentan Stand, verfügbar unter https://github.com/th-otto/MagicOnLinux/commits/PR/  Der Netzwerk-Treiber ist Teil davon.

Netsurf für '000 ist verfügbar unter https://tho-otto.de/download/netsurf/ns000-7057.zip (nur executable, rest in https://ci.netsurf-browser.org/builds/atari/NetSurf-m68k-atari-mint-gcc-7057.zip)

Ach und bevor ich es vergesse: Konfiguration ist wie bei Aranym. Ich habe allerdings nur bridge-Modus getestet, für point-to-point-Modus wäre aratapif erforderlich  (ein suid executable).

[AndreasK]

So, Patches rebased gegen deinen momentan Stand, verfügbar unter https://github.com/th-otto/MagicOnLinux/commits/PR/  Der Netzwerk-Treiber ist Teil davon.

Beeindruckend! Genial! Was machst Du beruflich? Informatikprofessor?

Wie ist der Plan? Soll ich das übernehmen (merge), oder möchtest Du das getrennt halten? Eleganter wäre natürlich eine modulare (XCMD-) Lösung, mit einer .so-Datei bzw. .dylib.

Bin gerade beim Versuch, mehr Programme zum Laufen zu bringen bzw. den Totalabsturz zu vermeiden oder wenigstens an den Debug-Ausgaben zu sehen, was die so treiben. Ich habe gerade eine Omikron-Basic-Version auf dem Seziertisch. Das gruselig,. wenn man sich anschaut, was für einen Schindluder die mit den Hardware-Registern treibt.

Im übrigen (denn was zur Hölle ist ein Übriges?) beißen sich solche Versuche mit einem großen Atari-RAM. Wenn man den I/O-Adreßbereich des ST analysiert, dann liegt der irgendwo bei 0x00fxxxxx. Das beschränkt den emulierten (ST-) Speicher auf 15 MB inklusive Bildspeicher. Bei 1280x960x32 bleiben dann etwa 10 MB RAM übrig. Finde ich jetzt nicht weiter schlimm, aber ist zu berücksichtigen. Wenn man nur 0xffxxxxxx analysiert, gibt es diese enge Einschränkung natürlich nicht.

Eigentlich müßte man noch User-Modus-Zugriffe auf die Adressen 0 und 4 abfangen (Busfehler), und wenn man TT-Speicher emulierten wollte, wird es noch komplizierter. Leider vermindert jede Größer- oder Kleiner-Abfrage bei den Speicherzugriffen direkt die Emulationsgeschwindigkeit, weil das ständig in der innersten Emulationsschleife aufgerufen wird. Der Zugriff aufs TT-RAM wäre dann etwas langsamer, nicht schneller. Die Zugriffe auf 0 und 4 baue ich aber erstmal im Debug-Modus ein, für die Fehlersuche ist das wichtig. Eine Überwachung der "exception vectors" ist auch hilfreich, um zu schauen, ob ein Programm daran herumbiegt und sich dann nicht mehr sauber entfernen läßt.

[Thorsten Otto]

Wie ist der Plan? Soll ich das übernehmen (merge), oder möchtest Du das getrennt halten?

Wäre gut wenn du das übernehmen könntest. Ich will ja die User nicht verwirren indem ich ein Konkurrenz-Produkt anbiete
Muss allerdings dazu sagen, daß Netsurf immer noch nicht funktioniert bei mir, bin immer noch auf der Suche.

Eleganter wäre natürlich eine modulare (XCMD-) Lösung, mit einer .so-Datei bzw. .dylib.

Ist denke ich unnötig kompliziert, und führt zu noch mehr System-Abhängigkeiten. Ausserdem müsste so eine sharedlib ja dann erst irgendwo installiert werden wo der Emulator sie finden kann.

Ich habe gerade eine Omikron-Basic-Version auf dem Seziertisch. Das gruselig,. wenn man sich anschaut, was für einen Schindluder die mit den Hardware-Registern treibt.

Ja, Omikron ist bekannt für seine "Schweinereien". In EmuTOS gab es damit auch schon Probleme.

Wenn man den I/O-Adreßbereich des ST analysiert, dann liegt der irgendwo bei 0x00fxxxxx. Das beschränkt den emulierten (ST-) Speicher auf 15 MB inklusive Bildspeicher.

Ich habe bei mir gerade 512MB durchgehendes ST-RAM konfiguriert. Da MagicOnLinux den Kernel ja nicht an die übliche $00e00000 läd, funktioniert das problemlos. Funktioniert natürlich nur, solange die Programme nicht direkt auf die Hardware zugreifen, vor allem nicht auf den Bereich ab $00ff0000. Da MagcMacX/MagicOnLinux aber nur das BIOS emuliert und nicht die Hardware, würden solche Programme sowieso nicht funktionieren.

Eigentlich müßte man noch User-Modus-Zugriffe auf die Adressen 0 und 4 abfangen (Busfehler),

Theoretisch ja. In der Praxis dürfte es aber wohl kein Programm geben das dort Schreibversuche unternimmt.  Addressen < $800 sollte man aber abfangen, wobei ich eigentlich nicht erwarte, daß es Programme gibt die dort versuchen im User-Modus zuzugreifen.

und wenn man TT-Speicher emulierten wollte, wird es noch komplizierter.

Könnte man, muss man aber denke ich nicht.

[Thorsten Otto]

Bin gerade etwas am verzweifeln bei den Netzwerk-Problemen. Vlt. kann mir ja jemand auf die Sprünge helfen.

Zusammenfassung:

- Frisch übersetzte Netsurf-Version funktioniert unter Aranym/MiNT. Das sagt mir eigentlich daß es grundsätzlich keine Probleme bei der Netzwerk-Konfiguration gibt.
- Ich verwende die gleichen Einstellungen (inklusive MAC-Addresse & IP-Addresse) auch für MagicOnLinux
- PING.TTP aus dem MagicNet Paket funktioniert. Das sagt mir eigentlich daß der Netzwerk-Treiber für MagcNet grundsätzlich funktioniert.
- auch ein ping das mit der mintlib für freemint übersetzt wurde, funktioniert.
- Aber: wenn ich mit netsurf unter MagicOnLinux versuche eine Seite aufzurufen, bekomme ich Timeouts. Scheinbar kommen dort keine Daten an.

Irgendwelche Ideen? Ich habe es auch schon mit Log-Ausgaben sowohl unter Aranym als auch MagicOnLinux versucht, und versucht die zu vergleichen, sehe dort aber nicht verdächtiges.
Was mich allerdings irritiert: in den folgenden die Log-Ausgaben von Aranym, bei Aufruf meiner eigenen Homepage):

Code: [Auswählen]

ETH0: packet received (len 90), triggering ETHERNETDriver interrupt
ETH0: recv   90:eth: dst 33:33:00:00:00:01 src 60:31:97:4b:08:28 type 86dd   data: 60 00 00 00 00 24 00 01 fe 80 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ff 02
Ethernet: Dispatch 7
ETH0: SendPacket src 20fba152, len 0x3c
ETH0: send   60:eth: dst ff:ff:ff:ff:ff:ff  00 00 00 00src 00:41:45:54:48:30 type 0806  arp: hws 0001 prs 0800 hwl 06 prl 04 opcode 0001 src 00:41:45:54:48:30 192.168.1.7  00 00 00 00 00 00 00 00 00 01 3adst ff:ff:ff:ff:ff:ff 192.168.1.1  data: 00 00 00 01 00 05 02 00 00 82 00 56 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 27 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 7d 00 00
ETH0: waiting for int acknowledge with pending irq mask 01
Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0x5a
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba160, len 0x5a
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
Ethernet: Dispatch 2
ETH0: packet received (len 60), triggering ETHERNETDriver interrupt
ETH0: recv   60:eth: dst 00:41:45:54:48:30 src 60:31:97:4b:08:28 type 0806  arp: hws 0001 prs 0800 hwl 06 prl 04 opcode 0002 src 60:31:97:4b:08:28 192.168.1.1 dst 00:41:45:54:48:30 192.168.1.7  data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ETH0: waiting for int acknowledge with pending irq mask 01
Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0x3c
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba160, len 0x3c
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
Ethernet: Dispatch 7
ETH0: SendPacket src 20fba044, len 0x4a
ETH0: send   74:eth: dst 60:31:97:4b:08:28 src 00:41:45:54:48:30 type 0800  ip: hl 45 tos 00 length    60 ident     1 frag 0000 ttl ff proto 01(ICMP) csum 3867 src 192.168.1.7 dst 192.168.1.1   data: 03 02 fc fd 00 00 00 00 46 00 00 20 00 00 40 00 01 02 43 2d c0 a8 01 01 e0 00 00 01 94 04 00 00 11 0a ee f5 00 00 00 00
ETH0: packet received (len 170), triggering ETHERNETDriver interrupt
ETH0: recv  170:eth: dst 33:33:00:00:00:16 src aa:f3:a0:bf:1c:4e type 86dd   data: 60 00 00 00 00 74 00 01 fe 80 00 00 00 00 00 00 64 16 36 ff fe bf 51 5c ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 16 3a 00 05 02 00 00 01 00 8f 00 7e 80 00 00 00 05 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 fb 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff 0d 96 58 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff bf 1c 4e 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff bf 51 5c 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 6a
ETH0: waiting for int acknowledge with pending irq mask 01
Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0xaa
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba060, len 0xaa
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
ETH0: packet received (len 60), triggering ETHERNETDriver interrupt
ETH0: recv   60:eth: dst 01:00:5e:00:00:01 src 60:31:97:4b:08:28 type 0800  ip: hl 46 tos 00 length    32 ident     0 frag 4000 ttl 01 proto 02(IGMP) csum 432d src 192.168.1.1 dst 224.0.0.1   data: 94 04 00 00 11 0a ee f5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ETH0: waiting for int acknowledge with pending irq mask 01Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0x3c

Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba060, len 0x3c
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
ETH0: packet received (len 90), triggering ETHERNETDriver interrupt
ETH0: recv   90:eth: dst 33:33:00:00:00:01 src 60:31:97:4b:08:28 type 86dd   data: 60 00 00 00 00 24 00 01 fe 80 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 01 3a 00 01 00 05 02 00 00 82 00 56 96 27 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 7d 00 00
ETH0: waiting for int acknowledge with pending irq mask 01
Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0x5a
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba160, len 0x5a
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
Ethernet: Dispatch 7
ETH0: SendPacket src 20fba044, len 0x4a
ETH0: send   74:eth: dst 60:31:97:4b:08:28 src 00:41:45:54:48:30 type 0800  ip: hl 45 tos 00 length    60 ident     2 frag 0000 ttl ff proto 01(ICMP) csum 3866 src 192.168.1.7 dst 192.168.1.1   data: 03 02 fc fd 00 00 00 00 46 00 00 20 00 00 40 00 01 02 43 2d c0 a8 01 01 e0 00 00 01 94 04 00 00 11 0a ee f5 00 00 00 00
ETH0: packet received (len 170), triggering ETHERNETDriver interrupt
ETH0: recv  170:eth: dst 33:33:00:00:00:16 src aa:f3:a0:bf:1c:4e type 86dd   data: 60 00 00 00 00 74 00 01 fe 80 00 00 00 00 00 00 64 16 36 ff fe bf 51 5c ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 16 3a 00 05 02 00 00 01 00 8f 00 7e 80 00 00 00 05 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 fb 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff 0d 96 58 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff bf 1c 4e 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff bf 51 5c 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 6a
ETH0: waiting for int acknowledge with pending irq mask 01
Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0xaa
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba060, len 0xaa
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
Ethernet: exit
ETH0: Stop thread

Irgendwie sehe ich da überhaupt keine Pakete für die eigentliche Seite. Sie wird aber korrekt angezeigt.

Zur Konfiguration:
- 60:31:97:4b:08:28 ist die MAC-Addresse von meinem Router (192.168.1.1)
- 00:41:45:54:48:30 ist die MAC-Addresse des Emulators (192.168.1.7)

[czietz]

Ich kenne mich mit Netsurf nicht aus. (U.a. weil ich Web-Browsen auf TOS-Systemen für ein sinnloses Unterfangen halte ). Aber kannst Du ausschließen, dass Deine Webseite von einem früheren Aufruf im Browser-Cache liegt und daher gar nicht neu übers Netzwerk angefragt wird?

Ich würde mich an das Problem langsam herantasten und erst einmal einen simpleren Client (FTP, Telnet, ...) testen.

[Thorsten Otto]

(U.a. weil ich Web-Browsen auf TOS-Systemen für ein sinnloses Unterfangen halte ).

Auf "normalen" TOS-Systemen: da stimme ich dir zu. Aber in schnellen Emulatoren durchaus praktikabel. Es geht mir mir auch nicht primär um Netsurf, sondern hauptsächlich generell um Netzwerk-Zugriff über den Host.

Aber kannst Du ausschließen, dass Deine Webseite von einem früheren Aufruf im Browser-Cache liegt und daher gar nicht neu übers Netzwerk angefragt wird?

Ja, kann ich denke ich.

Ich würde mich an das Problem langsam herantasten und erst einmal einen simpleren Client (FTP, Telnet, ...) testen.

Simpler als ping? Aber ich schau mal. ftp und telnet laufen allerdings keine Server bei mir, wenn das nicht klappt kann es auch an der firewall liegen.

[ragnar76]

Hast du schon das DNS im Auge? Was ist wenn die die IP statt der Webadresse eingibst?

[Thorsten Otto]

Eigentlich ein guter Tip, aber daran liegt es nicht. Auch bei Eingabe einer IP bekomme ich Timeout. Und ping funktioniert auch bei Eingabe eines Hostnamens.

PS: wer ftp etc. testen will: im Treiber-Archiv fehlt dafür noch eine C:\etc\services Datei. Kann man aber wohl vermutlich von überall her kopieren.

[ragnar76]

Hmmm... Ich werfe mal ein paar Schlagwörter in den Raum:

- Firewallregeln die den Transfer blockiern
- NAT Regeln richtig?

Du könntest auch mal probieren ob Cab läuft und was dann passiert. Ansonsten fällt mir noch der WebOne Proxy (oder Sqquid aber den zu confen ist ne eigene Nummer) ein. Geht es damit?

Wenn alles nichts hilft musst du wohl den traffic mit ncap/wireshark sniffen