WinPCap and Bochs?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

Thanks, mystran. That was the problem. Now I just can't send the reply :evil: ...

Bochs says

Code: Select all

[ETH-WIN32] Error sending packet: 31
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

Well, what was the problem?

If enabling promiscuous mode allows you to see the packets, then it simply means that you have wrong ethernet address programmed into the NIC, which makes it filter the packets that you're supposed to be receiving.

How do you get the address for the ARP reply? By reading PAR0-PAR5?
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

Promiscuous mode was already enabled... I realised that half of the bits in the RCR weren't set (0x0E) when I looked at the data sheet and looked at the structure of the register, so changing it to 0x1E solved the receive problem.

The transmit error still remains. I think it may be something to do with my version of WinPCap - I'm using version 4.0, elsewhere it is said that I should use 2.3...
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

pcmattman wrote: The transmit error still remains. I think it may be something to do with my version of WinPCap - I'm using version 4.0, elsewhere it is said that I should use 2.3...
Oh... you could gimme an image, and I could test.. I've got 2.3 and I can't remember if I actually tried newer ones and they failed...
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

I've removed the shell on this image. It's address is 192.168.1.109, takes a ne2k card (on ISA, IRQ 9, on PCI, it detects).

If you need code, just go to my sourceforge site.

The image is in my CVS repository on my sourceforge site (ne2k_testing.img).

Edit: it's on http://mattise.cvs.sourceforge.net/mattise/ now.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

My Bochs says:

Code: Select all

00441230054i[NE2K ] DCR write - AR set ???
00441230196i[NE2K ] DCR write - AR set ???
00441230280i[NE2K ] TCR write, loop mode 2 not supported
So there's at least something wrong in there. AR is:
AUTO-INITIALIZE REMOTE
0: Send Command not executed, all packets removed from Buffer Ring under program control.
1: Send Command executed, Remote DMA auto-initialized to remove packets from Buffer Ring.
That probably doesn't work on a PC if Bochs doesn't support it.

As for the TCR loopmode:
ENCODED LOOPBACK CONTROL: These encoded configuration bits set the type of loopback
that is to be performed. Note that loopback in mode 2 sets the LPBK pin high, this places the SNI
in loopback mode and that D3 of the DCR must be set to zero for loopback operation.
LB1 LB0
Mode 0 0 0 Normal Operation (LPBK e 0)
Mode 1 0 1 Internal Loopback (LPBK e 0)
Mode 2 1 0 External Loopback (LPBK e 1)
Mode 3 1 1 External Loopback (LPBK e 0)
(ok the copypaste from the PDF isn't optimal, but..)

Why would you want to set looback mode?



Now, enabling ne2k debugging outputs (from per device log) and rebooting:

Code: Select all

06199081567d[NE2K ] write addr c10e, value 58 len 1
06199081567d[NE2K ] page 0 write to register 0x0e, value=0x58
06199081567i[NE2K ] DCR write - AR set ???
06199081599d[NE2K ] read addr c11f, len 1
06199081625d[NE2K ] write addr c11f, value 0 len 1
06199081625d[NE2K ] asic write addr=0x0f, value=0x0000
06199081642d[NE2K ] read addr c107, len 1
06199081642d[NE2K ] page 0 read from register 0x07, value=0x80
06199081668d[NE2K ] write addr c107, value ff len 1
06199081668d[NE2K ] page 0 write to register 0x07, value=0xff
06199081688d[NE2K ] write addr c100, value 21 len 1
06199081688d[NE2K ] wrote 0x21 to CR
06199081709d[NE2K ] write addr c10e, value 58 len 1
06199081709d[NE2K ] page 0 write to register 0x0e, value=0x58
06199081709i[NE2K ] DCR write - AR set ???
06199081730d[NE2K ] write addr c10a, value 0 len 1
06199081730d[NE2K ] page 0 write to register 0x0a, value=0x00
06199081751d[NE2K ] write addr c10b, value 0 len 1
06199081751d[NE2K ] page 0 write to register 0x0b, value=0x00
06199081772d[NE2K ] write addr c10c, value 1e len 1
06199081772d[NE2K ] page 0 write to register 0x0c, value=0x1e
06199081793d[NE2K ] write addr c10d, value 14 len 1
06199081793d[NE2K ] page 0 write to register 0x0d, value=0x14
06199081793i[NE2K ] TCR write, loop mode 2 not supported
06199081814d[NE2K ] write addr c104, value 40 len 1
06199081814d[NE2K ] page 0 write to register 0x04, value=0x40
06199081835d[NE2K ] write addr c101, value 46 len 1
06199081835d[NE2K ] page 0 write to register 0x01, value=0x46
06199081856d[NE2K ] write addr c103, value 46 len 1
06199081856d[NE2K ] page 0 write to register 0x03, value=0x46
06199081877d[NE2K ] write addr c102, value 60 len 1
06199081877d[NE2K ] page 0 write to register 0x02, value=0x60
06199081898d[NE2K ] write addr c107, value ff len 1
06199081898d[NE2K ] page 0 write to register 0x07, value=0xff
06199081919d[NE2K ] write addr c10f, value 1f len 1
06199081919d[NE2K ] page 0 write to register 0x0f, value=0x1f
06199081939d[NE2K ] write addr c100, value 61 len 1
06199081939d[NE2K ] wrote 0x61 to CR
06199081962d[NE2K ] write addr c107, value 47 len 1
06199081962d[NE2K ] page 1 write to register 0x07, len=1, value=0x0047
06199081982d[NE2K ] write addr c100, value 22 len 1
06199081982d[NE2K ] wrote 0x22 to CR
06199082003d[NE2K ] write addr c10d, value 0 len 1
06199082003d[NE2K ] page 0 write to register 0x0d, value=0x00
06245700000d[NE2K ] rx_frame with length 554
06245700000d[NE2K ] rx_frame promiscuous receive
Then I get:

Code: Select all

07266000000d[NE2K ] rx_frame with length 60
07282140000d[NE2K ] rx_frame with length 60
07299210000d[NE2K ] rx_frame with length 60
07316490000d[NE2K ] rx_frame with length 60
when I attempt to ping it from another machine... said machine says:

Code: Select all

PING 192.168.1.109 (192.168.1.109) 56(84) bytes of data.
From 192.168.1.2 icmp_seq=1 Destination Host Unreachable
From 192.168.1.2 icmp_seq=2 Destination Host Unreachable
From 192.168.1.2 icmp_seq=3 Destination Host Unreachable
Looking at tcpdump output, ARP requests are sent, but never received, and Bochs doesn't claim to have sent any packets..

Should there be some output from the OS after "becoming 192.168.1.109: OK" ? I don't get any.

It keeps receiving those packets of 554 bytes, but doesn't seem to do anything with them.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

Oh and a bonus bit: you probably don't initialize PIT (instead relying on the default settings) because the time on top of screen keeps jumping in large steps on every update. My Bochs is set to run with real-time mode, so if you intialized PIT to some value, it would give you interrupts at right times to keep the clock approximately accurate, but for some reason the default speed is nowhere near normal PC default PIT clock.. edit: actually I'm not 100% sure this is the issue, as I've not bother to test if much, since I personally couldn't care any less about the default PIT speed.
Last edited by mystran on Fri Apr 13, 2007 4:08 am, edited 1 time in total.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

It should print out information whenever an ICMP packet arrives (look at the code, icmp_lib.c).

I'll have to go back and fix all those problems first.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

mystran wrote:Oh and a bonus bit: you probably don't initialize PIT (instead relying on the default settings) because the time on top of screen keeps jumping in large steps on every update. My Bochs is set to run with real-time mode, so if you intialized PIT to some value, it would give you interrupts at right times to keep the clock approximately accurate, but for some reason the default speed is nowhere near normal PC default PIT clock..
I noticed that but it works perfectly on normal PCs so I didn't really worry much. And I did actually change the default clock rate to 1000 ticks per second. Made my life easier when handling seconds.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

You should take advantage of the per-device log options in Bochs. Setting debug=log for a given device will give you tons of helpful information. For most devices you'll get info about every IO read and write, as well as information about what Bochs did with your reads/writes.

Usually stuff that indicates a problem gets some higher message priority, but the debug messages usually help finding where the problem-indicating message came from.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

Looks like I have some work to do :D

Thanks for you help.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

These errors have been fixed:

Code: Select all

00441230054i[NE2K ] DCR write - AR set ??? 
00441230196i[NE2K ] DCR write - AR set ??? 
00441230280i[NE2K ] TCR write, loop mode 2 not supported 
Loopback is turned off, but I still can't send ICMP packets. ARP replies go through though :?

I'll just have to keep looking...

Edit: Nope, still get the error in Bochs. This should be working... it does work up until I reach this part:

Code: Select all

	outportb(io + REMOTEBYTECOUNT0, size);
	outportb(io + REMOTEBYTECOUNT1, size >> 8);
	outportb(io + REMOTESTARTADDRESS0, 0);
	outportb(io + REMOTESTARTADDRESS1, TRANSMITBUFFER);
	outportb(io + COMMAND, E8390_RWRITE | E8390_START);
	while(i < size)
	{
		outportb(io + NE_DATA, data[i]);
		i++;
	}
	outportb(io + TRANSMITPAGE, TRANSMITBUFFER);
	outportb(io + TRANSMITBYTECOUNT0, size);
	outportb(io + TRANSMITBYTECOUNT1, size >> 8);

/**** This is the problem, obviously because that's when the transmission happens: ****/
	outportb(io + COMMAND, E8390_NODMA | E8390_TRANS | E8390_START);
Then it fails.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

Found a problem thanks to Bochs debug log...

Data is not actually sent. When the ICMP packet is generated it basically gets filled with 0xFF... which is wrong.

Edit: it actually happens between the IP and Ethernet layers.
Post Reply