Hi Clemens,
I wonder if you still maintain this code ?
Qemu has recently changed the way to manage network devices,
and I had to do changes to keep it working.
This worked like an charm until today, and is still interesting me as Im beginning tests for wireless nics in ReactOS.
CCing ros-dev mailing list in case someone has it already built it in.
Kind regards,
Sylvain Petreolle
----- Message d'origine ----
> De : Clemens Kolbitsch <clemens.kol(a)gmx.at>
> À : qemu-devel(a)nongnu.org
> Envoyé le : Jeudi, 28 Février 2008, 15h12mn 09s
> Objet : [Qemu-devel] Atheros Wireless Device Emulation
>
> Hi!
> This patch adds virtual wireless networking support to qemu-0.9.1.
> Besides being funny having a wireless LAN in Qemu, I guess wireless driver
> developers could use this a lot.
>
> I have 3 screenshots here:
> http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan_hardware.jpg
> http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan_connecting.jpg
> http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan_connected.jpg
>
>
> Some infos about the emulation:
> - We simulate an Atheros AR5212 NIC
> - Additionally, we have a virutal access point that can
> be used to connect to Qemu
> - The code is based on ath5k reverse engineering from
> about 10 months ago. I did not check what these guys
> did since then.
> - I added tons of hours doing reverse engineering.. but the
> code is still a MESS! I'm sorry, but at least it works ;-)
> - We can simulate different network card vendors. I.e.
> through an additional model-name, we can specify if the
> network card is identified as "Atheros XXXX" or "HP W400", etc.
> ---> different drivers are installed automatically by guest system
> - The hardware reverse engineering still lacks some stuff. Known
> problems:
> * Depending on the driver, you have to use a different model
> ---> official windows drivers VS. madwifi Linux driver
> * Newest madwifi code probably does not work
> ---> Use Madwifi 0.9.3. Works just fine ;-)
> - The networking-code is still a *little* ugly. Outbound connections
> work, but there seem to be problems for inbound connections (e.g.
> tcp-redirection, etc.)
> - VM Snapshots supported
>
> Some infos about the patch:
> - 2 lines added to pci.c
> - added function declaration to pci.h
> - patched Makefile.target (2 lines)
> - added files qemu/hw/atheros_wlan_.*.[ch]
> - took 2 files from wireshark to generate CRC32 checksums
> - took 3 files from ath5k
> ---> licence people, please have a look if that is ok!!
>
> Enabling emulation:
>
> As I wrote above, there are still problems when using the same code for
> windows and linux guests. The model parameter helps here. Using the NIC on
> windows (that's how I tested):
>
> qemu ... -net user -net nic,model=atheros_wlan_winxp_HPW400 ...
>
> and
>
> qemu ... -net user -net nic,model=atheros_wlan_linux_HPW400 ...
>
> for Linux systems.
>
> The "atheros_wlan" is the device itself, "_linux" / "_windows" is necessary
> because the reverse engineering is still buggy and "_HPW400" gives the NIC
> identification for the guest. HPW400 is the Hewlett-Packard W400 device, but
> there are some more (see the atheros_wlan_eeprom.h for details).
>
> I have used the device on Debian (Kubuntu) Linux. The guests were WinXP-SP2
> and Kubuntu Linux, Kernel 2.6.20, MadWifi 0.9.3. My system is x86, so there
> might be problems with big/little endian I am not aware of!!
>
> Please try the patch and let me know what you think of it!!
>
> Greets,
> Clemens
Isn't that actually the same?
It also ignores the number of full descriptors, which I guess is wrong.
And it looks like the whole parsing code is broken. It ignores the
number of partial descriptors and does FullList++
Timo
janderwald(a)svn.reactos.org schrieb:
> Author: janderwald
> Date: Sat Apr 25 16:05:08 2009
> New Revision: 40694
>
> URL: http://svn.reactos.org/svn/reactos?rev=40694&view=rev
> Log:
> - Fix allocation of CM_RESOURCE_LIST
> - Might fix bug 4354
> See issue #4354 for more details.
>
> Modified:
> trunk/reactos/drivers/video/videoprt/dispatch.c
>
> Modified: trunk/reactos/drivers/video/videoprt/dispatch.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/video/videoprt/dis…
> ==============================================================================
> --- trunk/reactos/drivers/video/videoprt/dispatch.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/video/videoprt/dispatch.c [iso-8859-1] Sat Apr 25 16:05:08 2009
> @@ -340,9 +340,11 @@
>
> /* Save the resource list */
> ResourceCount = AllocatedResources->List[0].PartialResourceList.Count;
> - ResourceListSize =
> - FIELD_OFFSET(CM_RESOURCE_LIST, List[0].PartialResourceList.
> - PartialDescriptors[ResourceCount]);
> + ResourceListSize = sizeof(CM_RESOURCE_LIST);
> +
> + if (ResourceCount > 1)
> + ResourceListSize += (ResourceCount-1) * sizeof(CM_PARTIAL_RESOURCE_DESCRIPTOR);
> +
> DeviceExtension->AllocatedResources = ExAllocatePool(PagedPool, ResourceListSize);
> if (DeviceExtension->AllocatedResources == NULL)
> {
>
>
>
I feel that some things really need to be clearly explained, regarding apps
being use to test releases with.
At the moment, despite numerous attempts, i failed to find who (if anyone)
is responsible for compiling and maintaining the list of apps used for
release version testing. Especially, the non-downloader stuff section is
basically changing completely with every release, making those tests
virtually pointless, if we cant keep any consistency. On the other hand,
looks like no one is responsible for maintaining Downloader app list.
Without such responsibilites set, we are slipping into disorganisation,
which is both confusing and uproductive. Clear policies should be set and
observed in this matter, taking care of such basic thing as
adding/linking/opening a bug report for an app that failed in release Test.
I feel that testers have more productive things to do, than cleaning
up/sorting test entries, incorrectly made up by first timers.
Sorry if anyone feels this post to sound harsh, but its still really gentle
and kind, compared to obscenities, curses and swears others have to put up,
when i vent out after seeing the current state of Release testing wiki.
HI!
I was wondering if you people were interested in a new ISO/QUEMU/VMWARE
download mirror, I got space and on my server and I would like to help this
wonder full project.
If the service I'm offering you for free please answer back with the
information for starting "mirroring"
Here's my server's information:
Conection speed: VLAN on 100Mbits
Mirroring protocol: HTTP
Space reserved for ReactOS: 7GB,
Bandwith: Unlimited Bandwith
Waiting your answer,
Jorge Guerra
Kernel Error Administrator
Will Rogers <http://www.brainyquote.com/quotes/authors/w/will_rogers.html>
- "I don't make jokes. I just watch the government and report the
facts."
Hi,
by today most of the bugs which were having 0.3.9 as a milestone are
fixed - including fixing 4-months old bug with richedit control,
properly trimming DLL names during PE loading so that apps now can
find their DLLs (previously that failed in some cases), newest
downloader problem introduced yesterday and fixed today (not to speak
about yesterday's fixes too!).
This is a very good example of team collaboration, team effort aimed
at a narrow set of problems. It worked very well, and I think we
would utilise such bugfixing sessions in future too.
Branching date is now set to tomorrow, 17th of April, 2009 and is not
going to be changed anymore. As soon as the 0.3.9 branch is created,
feature freeze is considered to be finished.
After the release is branched, usual testing will be conducted,
actual packages built and released as usual.
Thank you for your efforts and for being patient with regards to the
feature freeze.
WBR,
Aleksey Bragin.