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:
* Complete rewrite of TCP code based on that of 4.4BSD * updating netstat and netcfg applications * Finishing TFTP client
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 (mostly from scratch)
- 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)
- ARP code has been rewritten (altough not 100% bug-free yet)
- IP/UDP/TCP checksum generation and confirmation
- ~ Establishing a TCP connection (active open)
- TODO
- Sending fragmented IPv4 packets
- TCP
- IPC sockets
- RAW sockets (ethernet/ipv4/icmp/..)
- Enhance the API to work with network drivers
- Replace EthRegDev with more universal function
- Same for EthReceiver (order of registers on stack should change too)
- Port trunking (IEEE 802.1AX-2008)
- ..
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: (ISA) <asm> type db 0 ; isa io_addr dw ? irq_line db ? </asm>
IN: (PCI) <asm> type db 1 ; pci pci_bus db ? pci_dev db ? </asm>
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.
NOTE: the kernel will put the address of buffer to send in [esp+4], and length of that buffer in [esp+8]
Current status of the drivers
- RTL8139: This is the main developing driver, it's as good as complete.
- ne2000/RTL8029: Needs some fixing in transmit procedure
- PCnet32: Working (also on vmware and virtualbox)
- SIS900: Working? Written by clevermouse
- 3c90x/3c59x: Working, only boomerang types tested
- i8255x (Intel eepro 100): The rough template of the code and structures has been written
- mtd80x: not started yet
- ForcedETH: shurf started to write the code ?
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.
It has some new functionality, you can run it with paramters 'F' to silently load first detected card, or parameter 'A' to load all cards
- Netstat
- This program allows you to read some variables from the stack.
- ARPcfg
- This program allows you to view the ARP entries, in future, you should be able to add and remove static entry's using this progam.
- Zeroconf
- This program is the newer version of what used to be 'autodhcp', it works with the new network API.
- nslookup
- Commandline DNS client from CleverMouse
- TFTPc
- A TFTP client with a GUI.
27/12: can receive files and store them using libio.obj, network.obj and box_lib.obj 28/12: Now it can also send files
- ICMP
- program for sending ICMP echo reply's (ping) and trace-route. (not existing yet)
- Telnet
- a new telnet client, based on the code of nslookup
Libraries
- network_lib
- The network library for KolibriOS, written by Clevermouse, was ported to the net branch, by the same person
I need your help!
I would really appreciate it if somebody could write some network applications,
so I can further test the kernel code without having to code them myself now :),
If you are interessed please contact me at hidnplayr@kolibrios.org (or find me in #general on irc.kolibrios.org)