Networking discussion

Discussion of development and patch submission.
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

OK, so here is my combined SLiRP and PCAP binary/source.

http://vpsland.superglobalmegacorp.com/ ... p-slirp.7z

Again sorry, you have to deal with the stupid password protection. The 404 page has the username and password.

USING PCAP
If you want to use pcap, you will need to know the interface 'guid' to connect to. YOU CANNOT USE PCAP+WIFI since almost all wifi chips won't send and receive promiscuous packets with a forged address. This is a hardware limitation, and Pcap will never work in this setup. Instead try SLiRP.

PCAP can work with protocols like IPX, DecNET, AppleTalk as the raw Ethernet frames are passed on the wire. It will always work best with a WIRED Ethernet connection.

To find your ethernet GUID names, I've included a program ethlist.exe
D:\temp\pcem>ethlist
Network devices:
Number NAME (Description)
0 \Device\NPF_{0DF68748-A9D1-461A-A3E8-F1E10E495688} (Local Area Connection* 2)
1 \Device\NPF_{0CFA803F-F443-4BB9-A83A-657029A98195} (Ethernet)
2 \Device\NPF_{A3F2C156-9D1C-4442-9766-2D745AB46145} (VMware Network Adapter VMnet8)
3 \Device\NPF_{69E9FFD0-D3D6-4985-8823-CDA5937BB224} (Local Area Connection 3)
4 \Device\NPF_{99C37A8D-040F-4217-A0DE-A3CE88B33F8B} (Bluetooth Network Connection 2)
5 \Device\NPF_{551CFF39-47A8-43FE-8137-598FD60859F1} (Wi-Fi)
6 \Device\NPF_{656B6ADB-13BF-4A58-96AD-BD0B61333E6A} (VMware Network Adapter VMnet13)
7 \Device\NPF_{726F0EB3-CC94-45F5-891F-8A8AE8C7CEEB} (VMware Network Adapter VMnet1)
8 \Device\NPF_{A542548C-1A7F-4C49-8CCC-1F8E890F026C} (tun0)
Press Enter to continue...
In this example my Ethernet device is "\Device\NPF_{0CFA803F-F443-4BB9-A83A-657029A98195}". You may need a lot of trial and error here. Sorry. Open up the pcem.cfg file, and you will need to manually add the following:

Code: Select all

netinterface = 1
netcard = 1
net_type = 0
pcap_device = \Device\NPF_{0CFA803F-F443-4BB9-A83A-657029A98195}

[Novell NE2000]
netcard = 1
addr = 0x300
irq = 10
#EMPTY LINE
net_type = 0 sets this to Pcap. You need a valid pcap_device. It shouldn't error out if you use the wrong interface, it just won't work. It's silent and I don't like that. However I did include a PCem-debug which will output all kinds of good debug data to the file pclog.txt. Look for the ne2000 sections and you can follow what is going on.

For example, a working configuration will have output similar to this:
D:\pcem>grep ne2000 pclog.txt
ne2000 pcap device \Device\NPF_{0CFA803F-F443-4BB9-A83A-657029A98195}
ne2000 reset
ne2000 init 0x300 10 slirp is 0 net_is_pcap is 1
ne2000 initalizing libpcap
ne2000 Pcap version [WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008)]
ne2000 pcap is currently in blocking mode
ne2000 Setting interface to non-blocking mode......!
ne2000 Building packet filter.........!
ne2000 Using filter [( ((ether dst ff:ff:ff:ff:ff:ff) or (ether dst ac:de:48:88:bb:aa)) and not (ether src ac:de:48:88:bb:aa) )]
ne2000 net_is_pcap is 1 and net_pcap is 10ed28f8
ne2000 is_slirp 0 is_pcap 1
ne2000 closing pcap
ne2000 close
ne2000 pcap device \Device\NPF_{0CFA803F-F443-4BB9-A83A-657029A98195}
ne2000 reset
ne2000 init 0x300 10 slirp is 0 net_is_pcap is 1
ne2000 initalizing libpcap
ne2000 Pcap version [WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008)]
ne2000 pcap is currently in blocking mode
ne2000 Setting interface to non-blocking mode......!
ne2000 Building packet filter.........!
ne2000 Using filter [( ((ether dst ff:ff:ff:ff:ff:ff) or (ether dst ac:de:48:88:bb:aa)) and not (ether src ac:de:48:88:bb:aa) )]
ne2000 net_is_pcap is 1 and net_pcap is 11b328f8
ne2000 is_slirp 0 is_pcap 1
ne2000 reset
ne2000 pcap sending packet
ne2000 pcap received a frame 60 bytes
ne2000 pcap sending packet
ne2000 pcap received a frame 60 bytes
ne2000 closing pcap
ne2000 close
While having an incorrect GUID will give you output similar to this:
D:\pcem>grep ne2000 pclog.txt
ne2000 pcap device \Device\NPF_{0CFA803F-F443-4BB9-A83A-657029A98196}
ne2000 reset
ne2000 init 0x300 10 slirp is 0 net_is_pcap is 1
ne2000 initalizing libpcap
ne2000 Pcap version [WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008)]
ne2000 pcap_open_live error on \Device\NPF_{0CFA803F-F443-4BB9-A83A-657029A98196}!
ne2000 close

USING SLiRP

Using SLiRP is far more easier, as it is 100% user mode code.

SLiRP only supports TCP/IP. PPTP doesn't work going through it's NAT. It's best suited to HTTP/HTTPS traffic, and unidrectional traffic, like Quake. The IP address you need to give a SLiRP VM is STATIC. Non Passive (active) mode FTP will not work. Passive mode FTP may or may not work, it really depends on the client. Telnet and SSH work fine.

You *MUST* either use BOOTP/DHCP or the following static IP address:
IP: 10.0.2.15
NETMASK: 255.255.255.0
GATEWAY: 10.0.2.2
DNS: 10.0.2.3
Anything other than this will not work. You can *ONLY* ping the address 10.0.2.2 . If you get a reply this will verify that SLiRP is functioning. You will also need to ensure the following entries are in your pcem.cfg file:

Code: Select all

netinterface = 1
netcard = 1
net_type = 1

[Novell NE2000]
netcard = 1
addr = 0x300
irq = 10
#EMPTY LINE

THE FUTURE
I want to add more network connection options, but I think this is a 'good start' for now. Let me know if it works, what kind of setup, even if it fails.
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

Neozeed, the SLiRP network still works with this updated patch! :D

As for network connection options, I would also like to see the AMD PCNet II Family Adapter and Realtek RTL8139 network cards emulated. That network card is currently used in Qemu, VMware Workstation/Player, VirtualBox.
SA1988
Posts: 274
Joined: Wed 30 Apr, 2014 9:38 am

Re: Networking discussion

Post by SA1988 »

about the netinterface, I think it should be deprecated thanks to this! :) As at the time in 2013 I was not as good as I am now.
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

ppgrainbow wrote:Neozeed, the SLiRP network still works with this updated patch! :D

As for network connection options, I would also like to see the AMD PCNet II Family Adapter and Realtek RTL8139 network cards emulated. That network card is currently used in Qemu, VMware Workstation/Player, VirtualBox.
I think adding PCI devices is a bit more involved..... But it is certainly something that can be re-visited later.
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

neozeed wrote:
ppgrainbow wrote:Neozeed, the SLiRP network still works with this updated patch! :D

As for network connection options, I would also like to see the AMD PCNet II Family Adapter and Realtek RTL8139 network cards emulated. That network card is currently used in Qemu, VMware Workstation/Player, VirtualBox.
I think adding PCI devices is a bit more involved..... But it is certainly something that can be re-visited later.
That would be a good idea especially when it comes to adding the PCI version of the Novell NE2000 emulated network card. Right now, it would be better to let the networking capabilities mature and improve before other devices are added. Right now, I'm only using the ISA version of the NE2000 emulated network card.

Windows 95 does infact work with r322, but Windows 98 doesn't in this revision...it crashes.
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

SA1988 wrote:about the netinterface, I think it should be deprecated thanks to this! :) As at the time in 2013 I was not as good as I am now.

I was trying not to be all that invasive to the code... And most of what I have in there needs to be changed around a bit to make it easier to read, and to make it support more card types, along with back end connection types.
startmenu
Posts: 104
Joined: Sat 29 Nov, 2014 7:39 am

Re: Networking discussion

Post by startmenu »

What are the changes in sound.c for? If I don't commit those changes, will it work?
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

startmenu wrote:What are the changes in sound.c for? If I don't commit those changes, will it work?

I compile it without any optimization

gcc -c sound.c

So far that seems to work the best. No idea why it crashes otherwise while creating a thread.
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

startmenu wrote:What are the changes in sound.c for? If I don't commit those changes, will it work?
apparently it was a floppy change that was corrupting things. Also due to the way PCem works with constant loading and unloading I want to re-do SLiRP as a DLL so hopefully it has a more full state flush when loading and unloading so usermode nat will work across reboots.
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

neozeed wrote:apparently it was a floppy change that was corrupting things. Also due to the way PCem works with constant loading and unloading I want to re-do SLiRP as a DLL so hopefully it has a more full state flush when loading and unloading so usermode nat will work across reboots.
I'm wondering if redoing SLiRP as a DLL will fix the reboot glitch that causes the network to not function will work though. :)
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

A bit off topic with r322 of PCem. I found a glitch in the Configure PCem menu that displays CPU types other than Intel, AMD and Cyrix. I'll bet that selecting "I Premiere/PCI", "CL" or the other "Intel"would cause PCem to crash instantly!

Here's a screenie:
Config PCem glitch.png
Config PCem glitch.png (45.07 KiB) Viewed 30620 times
I'm hoping that you fix this bug using the latest revision. :)
nerd73
Posts: 116
Joined: Wed 24 Sep, 2014 11:16 pm

Re: Networking discussion

Post by nerd73 »

ppgrainbow wrote:A bit off topic with r322 of PCem. I found a glitch in the Configure PCem menu that displays CPU types other than Intel, AMD and Cyrix. I'll bet that selecting "I Premiere/PCI", "CL" or the other "Intel"would cause PCem to crash instantly!

Here's a screenie:
Config PCem glitch.png
I'm hoping that you fix this bug using the latest revision. :)
That's been there since like forever.
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

nerd73 wrote:
ppgrainbow wrote:A bit off topic with r322 of PCem. I found a glitch in the Configure PCem menu that displays CPU types other than Intel, AMD and Cyrix. I'll bet that selecting "I Premiere/PCI", "CL" or the other "Intel"would cause PCem to crash instantly!

Here's a screenie:
Config PCem glitch.png
I'm hoping that you fix this bug using the latest revision. :)
That's been there since like forever.
Yep. It sure has.
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Networking discussion

Post by SarahWalker »

Not something I've seen. Instructions on how to reproduce would be helpful.
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Networking discussion

Post by SarahWalker »

Or it might be the memory corruption bug in 322. Try a newer revision.
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

TomWalker wrote:Or it might be the memory corruption bug in 322. Try a newer revision.
That's what I've been thinking all along. I hope that I can update to a newer revision soon.
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

TomWalker wrote:Not something I've seen. Instructions on how to reproduce would be helpful.
All the 386/486 type processors let you select vendors that clearly are not vendors... Selecting the blanks, or motherboard types gives an instant crash. I guess there isn't a correct terminator in the drop down list..
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

neozeed wrote:All the 386/486 type processors let you select vendors that clearly are not vendors... Selecting the blanks, or motherboard types gives an instant crash. I guess there isn't a correct terminator in the drop down list..
See if you can fix the terminator in the drop down list of the CPU type. Tom can no longer produce it in r326.
Last edited by ppgrainbow on Wed 26 Aug, 2015 9:09 pm, edited 1 time in total.
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Networking discussion

Post by SarahWalker »

Doesn't happen to me on rev 326.
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

ppgrainbow wrote:
neozeed wrote:All the 386/486 type processors let you select vendors that clearly are not vendors... Selecting the blanks, or motherboard types gives an instant crash. I guess there isn't a correct terminator in the drop down list..
See if you can fix the terminator in the drop down list of the CPU type. Tom can no longer produce it in r326.
I would just as soon merge in my newer stuff onto 326... No need to back port
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

Oh yeah, in the Makefile.mingw stuff the CPP should be CXX

CPP is the C preprocessor by default as a macro, CXX is C++ ..

I still get the broken menu, must be something with the resource compiler?

$ /usr/local/gcc-4.8.0-qt-4.8.4-for-mingw32/win32-gcc/bin/i586-mingw32-windres --version
GNU windres (GNU Binutils) 2.23.2
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

Let me find rc from Visual Studio.. .. .never mind MinGW can't like a compiled resource script from RC.EXE.

I just downloaded the latest snap, I didn't change anything and I still get the corrupt vendor list on the 386 and 486.

I'm at work, so I downloaded the latest snap PCem-6161293317e0/326 and I get the same thing, where the 386 and 486 cpu type has invalid entries.
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

neozeed wrote:Oh yeah, in the Makefile.mingw stuff the CPP should be CXX

CPP is the C preprocessor by default as a macro, CXX is C++ ..

I still get the broken menu, must be something with the resource compiler?

$ /usr/local/gcc-4.8.0-qt-4.8.4-for-mingw32/win32-gcc/bin/i586-mingw32-windres --version
GNU windres (GNU Binutils) 2.23.2
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

Let me find rc from Visual Studio.. .. .never mind MinGW can't like a compiled resource script from RC.EXE.

I just downloaded the latest snap, I didn't change anything and I still get the corrupt vendor list on the 386 and 486.

I'm at work, so I downloaded the latest snap PCem-6161293317e0/326 and I get the same thing, where the 386 and 486 cpu type has invalid entries.
Something could be wrong here. I'm wondering what could be causing the invalid CPU type entries on 386 and 486-based CPU types.
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

ppgrainbow wrote: Something could be wrong here. I'm wondering what could be causing the invalid CPU type entries on 386 and 486-based CPU types.
So basically in win-config.c the expression:

Code: Select all

                h = GetDlgItem(hdlg, IDC_COMBOCPUM);
                c = 0;
                while (models[romstomodel[romset]].cpu[c].cpus != NULL && c < 3)
is evaluating as true, since the table is.. corrupt. one way to 'fix' it is to do something like this:

Code: Select all

		while(c<3)
                {
			if(models[romstomodel[romset]].cpu[c].cpus != NULL){
                        SendMessage(h, CB_ADDSTRING, 0, (LPARAM)(LPCSTR)models[romstomodel[romset]].cpu[c].name);
			c++;}
Since we hard code ourselves to 3 manufacturers anyways. Better would be to check to make sure models[romstomodel[romset]].cpu[c].name is memset 0x0 beforehand since it looks like the optimization flags are copying junk instead of memsetting .... Or optimizing the memset out if there is one.
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

neozeed wrote:
ppgrainbow wrote: Something could be wrong here. I'm wondering what could be causing the invalid CPU type entries on 386 and 486-based CPU types.
So basically in win-config.c the expression:

Code: Select all

                h = GetDlgItem(hdlg, IDC_COMBOCPUM);
                c = 0;
                while (models[romstomodel[romset]].cpu[c].cpus != NULL && c < 3)
is evaluating as true, since the table is.. corrupt. one way to 'fix' it is to do something like this:

Code: Select all

		while(c<3)
                {
			if(models[romstomodel[romset]].cpu[c].cpus != NULL){
                        SendMessage(h, CB_ADDSTRING, 0, (LPARAM)(LPCSTR)models[romstomodel[romset]].cpu[c].name);
			c++;}
Since we hard code ourselves to 3 manufacturers anyways. Better would be to check to make sure models[romstomodel[romset]].cpu[c].name is memset 0x0 beforehand since it looks like the optimization flags are copying junk instead of memsetting .... Or optimizing the memset out if there is one.
That should fix the corrupt table issue in the next revision of PCem. :D

When the optimisation flags try to copy junk from parts of the machine model name, PCem ends up NOT properly recognising the name of the CPU brand and the emulator crashes with an access violation error (0xC0000005).
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

ppgrainbow wrote:
neozeed wrote:
ppgrainbow wrote: Something could be wrong here. I'm wondering what could be causing the invalid CPU type entries on 386 and 486-based CPU types.
So basically in win-config.c the expression:

Code: Select all

                h = GetDlgItem(hdlg, IDC_COMBOCPUM);
                c = 0;
                while (models[romstomodel[romset]].cpu[c].cpus != NULL && c < 3)
is evaluating as true, since the table is.. corrupt. one way to 'fix' it is to do something like this:

Code: Select all

		while(c<3)
                {
			if(models[romstomodel[romset]].cpu[c].cpus != NULL){
                        SendMessage(h, CB_ADDSTRING, 0, (LPARAM)(LPCSTR)models[romstomodel[romset]].cpu[c].name);
			c++;}
Since we hard code ourselves to 3 manufacturers anyways. Better would be to check to make sure models[romstomodel[romset]].cpu[c].name is memset 0x0 beforehand since it looks like the optimization flags are copying junk instead of memsetting .... Or optimizing the memset out if there is one.
That should fix the corrupt table issue in the next revision of PCem. :D

When the optimisation flags try to copy junk from parts of the machine model name, PCem ends up NOT properly recognising the name of the CPU brand and the emulator crashes with an access violation error (0xC0000005).
Looking at the struct in model.c what it looks like is happening is that there is space for 3 manufactuers, and when all 3 are being used, it's not catching the null terminator, and it's spilling over. The Sward 430VX PCI correctly lists Intel and
IDT, the Acer 386sx25/N correctly lists only Intel... And the Award SiS 496/497 lists fewer corrupt 486 entries. Let me try expanding the model structure......
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

Yep that did it!

in model.h

Code: Select all

typedef struct
{
        char name[24];
        int id;
        struct
        {
                char name[8];
                CPU *cpus;
        } cpu[3];
        int fixed_gfxcard;
        void (*init)();
} MODEL;
So basically the cpu[3] needs to change to cpu[4]. Then it'll be fine.... This is like having char bob[4];, placing four chars in there, so there is no null terminator, and it buffer overflows.... so expand it by one more.
Last edited by neozeed on Thu 27 Aug, 2015 4:55 am, edited 1 time in total.
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

neozeed wrote:Yep that did it!

in model.h

Code: Select all

typedef struct
{
        char name[24];
        int id;
        struct
        {
                char name[8];
                CPU *cpus;
        } cpu[3];
        int fixed_gfxcard;
        void (*init)();
} MODEL;
So basically the cpu[3] needs to change to cpu[4]. Then it'll be fine.... This is like having char bob[4];, placing for chars in there, so there is no null terminator, and it buffer overflows.... so expand it by one more.
That should really finally fix the corrupt entry issue. :)
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Networking discussion

Post by SarahWalker »

Committed in rev 327.
User avatar
ppgrainbow
Posts: 479
Joined: Thu 04 Sep, 2014 7:03 am
Contact:

Re: Networking discussion

Post by ppgrainbow »

TomWalker wrote:Committed in rev 327.
Thank you for fixing the CPU vendor bug! :)
neozeed
Posts: 176
Joined: Tue 08 Jul, 2014 4:41 am
Location: Hong Kong SAR
Contact:

Re: Networking discussion

Post by neozeed »

I'm still getting crashes in the sound thread for some unknown reason....

Code: Select all

[New Thread 9104.0x1c90]
[New Thread 9104.0x32c0]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 9104.0x32c0]
0x0052c426 in sound_cd_thread ()
(gdb)

So as a temporary measure I've added this to the Makefile so it builds slightly different:

Code: Select all

sound.o : sound.c
	$(CC) -O2 -march=i686 -fomit-frame-pointer -DRELEASE_BUILD -c $<
Post Reply