New stack

intro

As you may or may not know, I (hidnplayr) am since long time working on a new network stack for KolibriOS

I will use this page for myself as a total image of what I have done so far, but also to inform others.

I'm currently working on: everything (drivers, protocols, fine-tuning API, applications, ..)

Kernel

The old kernel functions 52 and 53 have been removed and the New_network_api has been created.

Internally, the stack has been completely rewritten (from scratch!)
Currently the old code is used for ARP, but it needs a (partial) rewrite too.

• What works

  • attaching network drivers
  • sending and receiving Ethernet packets
  • queuing of packets
  • Sending and receiving of IPv4 packets
  • Receiving Fragmented IPv4 packets
  • Sending and receiving ICMP packets
  • Sending and receiving UDP packets
  • UDP sockets
  • Working with multiple network card's at once (not fully tested)
  • ICMP sockets (needs to be tested, must write the application for that first ;)

• What doesnt work yet

  • Sending fragmented IPv4 packets
  • TCP
  • Unix-type domain sockets
  • IPv4 sockets
  • Ethernet sockets
  • DNS ?? (should it be in kernel, or some library...)
  • ..

Drivers

These new type network drivers are MS COFF files, just like the sound drivers in KolibriOS.

Notice that one driver can handle multiple devices.

Once the driver is loaded, an application (NetCFG) can use system function 68/17 ("Driver Control") to communicate with the driver.
For this, it uses the IOCTL structure wich looks like this: <asm> struc IOCTL {

  .handle      dd ?
  .io_code     dd ?
  .input       dd ?
  .inp_size    dd ?
  .output      dd ?
  .out_size    dd ?  

} </asm> for more info about this, please read Writing_drivers_for_KolibriOS

Here is a list of opcodes:

0 - Getversion

standard for all drivers, not only network drivers

1 - Hook

Attach driver to a device

IN:
db 1 ; Type of device, 1 means (32-bit) PCI (In the future, also isa, pci-x, etc should be supported)
db ? ; For PCI devices, this byte must be set to the pci bus number.
db ? ; For PCI devices, this byte must be set to the pci device number.

OUT:
eax = device number or -1 on error

---

Once the HOOK function of the driver has been called, the driver creates the ETH_DEVICE structure, allocates some buffers needed for the driver, and calls the kernel function 'EthRegDev'.
This function registers an ethernet device (device, not driver!) to the kernel.
It only needs one parameter: pointer to device structure (ETH_DEVICE) in ebx.
The function returns the device number in edi (..wich the driver then sends to the application in eax, see above..)

This ETH_DEVICE structure is created and filled in by the driver, for every device it is hooked to.
The driver may use this to store pointers to buffers, descriptors,.. etc
But the top of the structure must always look like this: (Since it is shared by the driver and the kernel)

<asm> struc ETH_DEVICE {

pointers to driver procedures

     .unload           dd ?
     .reset            dd ?
     .transmit         dd ?
     .set_MAC          dd ?
     .get_MAC          dd ?
     .set_mode         dd ?
     .get_mode         dd ?

device status

     .bytes_tx         dq ?
     .bytes_rx         dq ?
     .packets_tx       dd ?
     .packets_rx       dd ?
     .mode             dd ?  ; This dword contains cable status (10mbit/100mbit, full/half duplex, auto negotiation or not,..)
     .name             dd ?  ; Pointer to device name
     .mac              dp ?

} </asm>

When a packet is received by the driver, it copies it into a buffer allocated using 'KernelAlloc'.
Then the driver pushes the size of the buffer and the pointer to the buffer onto the stack (in this particular order)
And it calls 'EthReceiver'.
This kernel function will but the packet into the incoming queue, so the appropriate protocol handler can handle it later.

When the kernel needs to send a packet, it simple looks up the appropriate driver in it's driver table.
In the table it will find the pointer to the device structure, so the driver can directly call the transmit function listed in the structure.

TODO - explain more and better

---

Current status of the drivers

• RTL8139: This is the main developing driver, it's as good as complete, except for one bug: collission of packets occurs in some cases.
• PCnet: I Started the work on this driver recently, but havent tested any code yet, probably 80% complete
• i8255x (Intel eepro 100): The rough template of the code and structures has been written, 25% complete
• RTL8029: same as above
• ne2000 (for ISA cards): not started yet
• 3c90x/3c59x: not started yet
• mtd80x: not started yet

Other drivers will need to be written by other people, as I dont have the hardware to test it!
(And actually, i dont have much time too hehe)

Programs

• NetCFG

  This is a program I wrote to load the drivers, it detects all network cards in your computer (PCI), and lets you load the appropriate driver for it.

• Zeroconf

  This program is the newer version of what used to be 'autodhcp', it works with the new network API.

• TFTPc

  A TFTP client with a GUI. (not done yet)

• TFTPd

  A TFTP daemon. (not started yet)

• ICMP

  program for sending ICMP echo reply's (ping) and trace-route. (not started yet)

We need you!

If you would like to start writing applications/drivers/kernel code ,
please contact me at hidnplayr@kolibrios.org (or find me in #general on irc.kolibrios.org)