OSDev.org

so i could just set the IP to anything and packets would just make it to my emulated OS somehow ?

It actually all starts at the frame level or also called the data-link layer.

The little electrical pulses are translated into a string of eight bit values. The first six are the destination media access control address. The next six are the source media access control address. Then comes two more bytes which are used for encapsulation.

You know six bytes in hex look something like:
00:03:45:FE:0A:99

Every network card has a built-in media access control address or also called a "MAC" address. Normally the card will only receive frames that have the first six bytes matching their internal MAC address. Any other packet is always ignored. A exception is that they will also listen for a MAC address of ff:ff:ff:ff:ff:ff which is considered a broadcast address.

No two network cards in the entire world should ever have the same media access control address or MAC. If you researched it you might have a screw up by a company somewhere in the past years where somehow two cards did get the same address. This is not intended to happen just note for you.

You will have to look up some documentation on how to read the MAC from the network card to find out what it is. You may also in some network cards or at least all modern ones change the MAC address if you like.
hint: You will talk to the network card with MMIO and I/O instructions like: in, and out.

What happens in a emulated state is that QEMU or BOCHS will open you're network adapter or all adapters in promiscuous mode in Windows Or Linux depending on which or what you are using. In a normal situation like (above) only listen to frames that have the first six bytes matching their own internal address or have all binary ones which make the ff:ff:ff:ff:ff:ff address. However, in promiscuous mode the network card will ignore nothing and instead listen to every frame regardless of the destination address (or the first six bytes). The kernel will normally do extra filtering in the event that a program turns on the promiscuous mode for a network card, but will still provide all the frames in a unfiltered manner.

This is what QEMU and BOCHS depend on. They will listen on the network adapter in promiscuous mode. This will work on Windows and Linux. QEMU and BOCHS will listen for packets matching their emulated network card's MAC address and once found will do the magic of emulating the network card you're emulated kernel is listening for as being received.

QEMU and BOCHS should also emulate their own network cards being in promiscuous mode. Where they will emulate frames straight from the Linux or Windows kernel into the virtual computer where you kernel is running.

The network card knows nothing and does not care anything about a IP address. It has absolutely no idea what a IP address is.

You could actually test receiving packets by starting you're kernel in QEMU or BOCHS and letting it initialize the network card and wait for packets then:

- if you are using Linux or Windows.
Find you're IP address.
Change the last number of you're IP address to another number.
Then ping this new ip address.

If everything goes okay. You're network card will receive a frame. This frame will have the first six bytes of ff:ff:ff:ff:ff:ff. This is the broadcast address and if you want to further study it you will need to google for "arp header".

What you are doing is trying to use a IP address on you're local subnet. One in which does not get forwarded to you're gateway (or entrance onto the internet). You also need a IP address that Windows Or Linux has never seen which will cause them to generate a ARP packet with a broadcast destination MAC address. The computer owning the IP address will normaly respond with a ARP reply.

Just imagine trying to send information to a certain IP address and not knowing the six byte media access control address. How could you send it if any network card will ignore any frame that does not match it's own?

That is what ARP is for and the MAC broadcast.

cool, i think I'm starting to understand some of this stuff, I've just stated on a simple ne2k driver, nothing wrote yet, but now I'm stuck, I just want to setup the card and wait for packets, and print: "Packet!", I've looked at some drivers, but there fairly complicated, how do I just setup the NIC in the most basic way, is there a tutorial or some .pdf's that explain just that?

thx!

GLneo wrote:cool, i think I'm starting to understand some of this stuff, I've just stated on a simple ne2k driver, nothing wrote yet, but now I'm stuck, I just want to setup the card and wait for packets, and print: "Packet!", I've looked at some drivers, but there fairly complicated, how do I just setup the NIC in the most basic way, is there a tutorial or some .pdf's that explain just that?

My driver, the one I posted in "Packets not arriving" thread a while back, and linked here: http://www.osdev.org/phpBB2/download.php?id=146 is probably one of the most simple ones you'll find, yet manages to both send and receive packets pretty reliably (and in Bochs and QEMU I've yet to see a dropped packet). Mostly commented, so should give you a decent idea of how things work, especially if you read it with datasheet in the other hand.

hi, mystran! I use your code. but I find my os can only get the broadcast packets.
my testing entironment are: bochs2.3 + winpcap 3.0, under windowsXp2.

at the same time, I reused ominos's code, but also only get the broadcast packets.

wangy414 wrote:hi, mystran! I use your code. but I find my os can only get the broadcast packets.
my testing entironment are: bochs2.3 + winpcap 3.0, under windowsXp2.

at the same time, I reused ominos's code, but also only get the broadcast packets.

Are you specifically crafting ethernet packets with the correct MAC, or answering ARP requests? Because unless you answer ARP requests, nobody will know where you are (what's your MAC)..

If you're crafting special packets or answering ARP requests (you use "arp print" in cmd.exe to see the ARP table to see if you've managed to respond) and still can't hear anything but broadcast, then did you include the code that sets the PAR registers with the data from so called "SA-PROM" (my driver has all that)..

If you STILL can't receive any packets other than broadcasts, then you need to tell some more (or give access to your code)...

Oh, and please ignore the IP address in my driver. It's not relevant part of the driver, rather it was just a nice place to stick hard-coded IP configuration. It's higher layers (IPv4 protocol and ethernet ARP) that actually use that.

hi,mystran!
below is the code, i modified a little.
http://www.osdev.org/phpBB2/files/ne2k_103.c
I used ethereal , found that the windows have get the arp request.

first, i used bochs2.3 and WinPcap_4.0, but the niclist can't get the ethdev. so I try several versions of the bochs and winpcap.
at last, i use bochs2.3 andWinPcap_3.0. the niclist can get the ethdev.

wangy414 wrote:hi,mystran!
below is the code, i modified a little.
http://www.osdev.org/phpBB2/files/ne2k_103.c
I used ethereal , found that the windows have get the arp request.

first, i used bochs2.3 and WinPcap_4.0, but the niclist can't get the ethdev. so I try several versions of the bochs and winpcap.
at last, i use bochs2.3 andWinPcap_3.0. the niclist can get the ethdev.

Yeah, anything newer than 3.0 certainly doesn't work. WinPCap 2.3 is the safest bet. About the code, I've never tested it with the ISA version, but if broadcast packets work, then it's not that..

The code itself looks more or less like mine, so I'm going to suggest that if you see packets sent, from the OS the problem is probably somewhere else, and not the driver..

BUT: get rid of the "while(1)" loop in receive. You aren't running it in a thread controlled in by a semaphore, so it doesn't make any sense to loop forever.

Win Pcap 4.0 has trouble with the 'niclist' program.

I got WinDump as well and got the devices that way. WinDump is also really useful as a way of seeing what's happening on the network - when I enable the 'checksum' option I found out why UDP wasn't working .

hi mystran, thank you!
After use bochs2.3 + winpcap2.3， I the driver can work correctly.
thank you!

wangy414 wrote:hi mystran, thank you!
After use bochs2.3 + winpcap2.3， I the driver can work correctly.
thank you!

Do you remember at what the host OS driver work?
Thx.

jzef wrote:

wangy414 wrote:hi mystran, thank you!
After use bochs2.3 + winpcap2.3， I the driver can work correctly.
thank you!

Do you remember at what the host OS driver work?
Thx.

The last post in this thread was

Posted: Sat Apr 28, 2007 12:18 pm

From wangy414's profile:

Last visited: Wed Sep 03, 2008 3:29 pm

Unfortunately, your question is unlikely to be answered.

Roman wrote:Unfortunately, your question is unlikely to be answered.

OK, I started a new thread already --> Network problems on Bochs