[Solved] NE2K in BOCHS

[Tomaka17]

Hello,

I wrote a NE2K driver a few days ago.

For testing purposes, I pinged google.fr (with Windows) and sniffed the sent packet (with Wireshark). I copied this packet into my O/S and tried sending it.
When I send the packet, I get an interruption telling me it has been successfully sent.

I sniffed this and discovered that my O/S (using BOCHS) successfully sends the ping request, and that Google answers. But my O/S doesn't get any interruption from receiving a packet. I'm sure that interrupts are working as I get one from sending something.

Also I quote this from the BOCHS source code:

Code: Select all

/*
 * rx_frame() - called by the platform-specific code when an
 * ethernet frame has been received. The destination address
 * is tested to see if it should be accepted, and if the
 * rx ring has enough room, it is copied into it and
 * the receive process is updated
 */
void bx_ne2k_c::rx_frame(const void *buf, unsigned io_len)
{
  int pages;
  int avail;
  unsigned idx;
  int wrapped;
  int nextpage;
  unsigned char pkthdr[4];
  unsigned char *pktbuf = (unsigned char *) buf;
  unsigned char *startptr;

  BX_DEBUG(("rx_frame with length %d", io_len));

But I don't see "rx_frame" in the logs even when setting "debug events" to "log".

To sum up:
- my O/S sends a ping request which is sent by my real computer
- Google replies to my compter
- but BOCHS doesn't detect this


What can I do ? :-/
Is BOCHS's ne2k not working on Windows ? Or is there something I didn't think about ?

[Tomaka17]

I forgot to tell that I changed the MAC address in the packet in order to match the MAC address of the virtual ne2k

The ping request contains the virtual MAC address (as its source) but the answer contains my real NIC's MAC address (as its destination)

[Tomaka17]

I think that I solved the problem

BOCHS certainly redirects the packets according to their destination MAC address

The problem is that when I ping google, the request goes through my router
The router redirects the request to google, which answers
The router then receives the answer and retreives my computer's IP in the packet
And using ARP it detects that this IP has address MAC xx:xx:xx:xx:xx:xx which is in fact my real MAC address, despite the fact that the initial packet had a different MAC address


I tried putting in the packet an IP (let's say 192.168.1.5) which doesn't exist
The router sends the request, receives the answer
But he doesn't know where it should send it as it doesn't know the MAC belonging to 192.168.1.5
Thus it sends an ARP request (MAC address ff:ff:ff:ff:ff:ff, ie. broadcast) over the network

...which is detected by BOCHS

For the moment I still don't receive anything with by driver but I see "rx_frame" written in BOCHS's logs

Consequently you can't simply send something over the network and hope you will get an answer, you have to support the ARP protocol to do so


PS : sorry for (very) bad english :s

[jal]

PS : sorry for (very) bad english :s

You're English is perfectly fine, especially compared to some (not all!) of our Chinese and Indian friends here :). As for your routing problem, I'm not much of a routing / TCP/IP expert, but your virtual ne2k should of course use a different IP address than your real network card in your real PC. You are basically using the same IP-address from two different network cards, which naturally confuses the router. So indeed you solved it by using a different address. It may be possible in your router config to 'hardwire' your virtual IP address with your virtual MAC (but then, it may not).


JAL

[mystran]

Indeed. One (or more) IP per network adapter (ethernet address = MAC), but never more than one MAC per an IP.

You really have two computers now: the "real" one, and the "virtual" one. Both need an IP or you have no way to know where the IP packet should be sent; remember MAC addresses are local to ethernet block, and never routed anywhere. As far as TCP/IP is concerned, it couldn't care less whether you're sending over ethernet (which uses MAC addresses internally) or a modem (several possible implementations exist) or even pigeons (see RFC1149 / RFC2549).