Bounty: TCP/IP stack for BareMetal OS

[IanSeyler]

Hello everyone,

I have received a generous donation of $500 USD to add a TCP/IP stack to BareMetal OS. Unfortunately I do not have the time to complete this myself (or the required knowledge) so I would like to open this up to the community.

TCP handling is the only requirement at the moment (and perhaps some additional ARP work). BareMetal OS already has the ability to set an IP for itself and can respond to ARP and ICMP requests. The stack would need to be written in x86-64 Assembly just like the rest of the system. Some of the required framework is already in place.

If you are interested please send me a message. There is no timeline for this work to be completed but the sooner the better. If they are any questions please let me know.

Thanks,
Ian Seyler

[ACcurrent]

Why not just use uIP?

[Brynet-Inc]

Why not just use uIP?

The OP has indicated he wants something written in assembly, uIP/lwIP is written in C.

He probably shouldn't have accepted the donation if he didn't already have someone lined up to do the work, hopefully he plans on refunding them.

[IanSeyler]

It needs to be written in Assembly as the rest of the OS is in Assembly.

I would have thought it to be more important to get the funding before announcing the bounty. The money will be returned if there are no takers. Paypal stated that it could be refunded within 60 days without penalty.

Another thing to note is that the core functionality will need to translate to BSD sockets at the C/C++ application level. So functions like send, recv, accept, bind, listen, and connect will need to be implemented. UDP is not required at the moment. BareMetal OS already has functionality to send and receive raw Ethernet frames:

Code: Select all

; os_ethernet_tx -- Transmit a packet via Ethernet
;  IN:	RSI = Memory location where data is stored
;	RDI = Pointer to 48 bit destination address
;	 BX = Type of packet (If set to 0 then the EtherType will be set to the length of data)
;	 CX = Length of data
; OUT:	Nothing. All registers preserved

The TCP handler would need split the data into Ethernet packets (as well as reassemble them) and handle the SYN/ACK communication.

I'm thinking of functions like:
os_tcp_open
os_tcp_close
os_tcp_send
os_tcp_recv
os_tcp_listen
os_tcp_accept

This should be a pretty good challenge and I'm interested to see what someone else can do. I wrote the incoming ICMP handler but TCP is a bit beyond me at the moment with all the handshakes and error correction.

Here is my ICMP code:

Code: Select all

; -----------------------------------------------------------------------------
; os_icmp_handler -- Handle an incoming ICMP packet
;  IN:	RCX = packet length
;	RSI = location of received ICMP packet
os_icmp_handler:
	push rsi
	push rax

	; Check if reply or request

	; Swap the MAC addresses
	mov rax, [rsi]			; Grab the Destination MAC as 8 bytes even though the MAC is 6 bytes
	mov ax, [rsi+0x0C]		; Store the EtherType in the low 16-bits of RAX
	push rax			; Save the new Source MAC (with EtherType) to the stack
	mov rax, [rsi+0x06]		; Grab the Source MAC as 8 bytes (the last two bytes will be overwritten)
	mov [rsi], rax			; Store the new Destination MAC in the packet
	pop rax				; Restore the new Source MAC + EtherType
	mov [rsi+0x06], rax		; Write it to the packet

	; Swap the IP addresses
	mov eax, [rsi+0x1A]		; Grab the Source IP
	push rax
	mov eax, [rsi+0x1E]		; Grab the Destination IP
	mov dword [rsi+0x1A], eax	; Overwrite the 'old' Source with the 'new' Source
	pop rax
	mov dword [rsi+0x1E], eax	; Overwrite the 'old' Destination with the 'new' Destination

	; Set to Echo Reply
	mov byte [rsi+0x22], 0x00	; Set to 0 for Echo Reply (Was originally 8 for Echo Request)

	; Adjust the checksum
	mov ax, [rsi+0x24]
	add ax, 8			; Add 8 since we removed 8 (by clearing the Echo Request)
	mov word [rsi+0x24], ax

	call os_ethernet_tx_raw		; Send the packet

	pop rax
	pop rsi
	ret
; -----------------------------------------------------------------------------

Best regards,
Ian Seyler

[guyfawkes]

Why not just convert the stack from menuetOS or DexOS they are both open source.

[IanSeyler]

That would be possible as well. It's up to whomever wants the bounty.

[turdus]

UDP is not required at the moment.

But TCP is, and TCP is build on top of UDP, ICMP and ARP.

[Kevin]

Not really. Both TCP and UDP are built on top of IP.

[turdus]

Not really. Both TCP and UDP are built on top of IP.

Read RFC793.
"TCP assumes it can obtain a simple,
potentially unreliable datagram service from the lower level
protocols."
and datagram service is...

[Love4Boobies]

Kevin is correct; TCP and UDP are both on the transport layer and both work on top of IP. There's even a figure in the document that you've quoted, you should look at that.

I suggest reading TCP/IP Illustrated, Volume 1: The Protocols, 2nd ed. (yes, the classic has been finally updated).

[Kevin]

Read RFC793.

I have not only read the RFC, but also implemented something that resembles TCP close enough to make it work. And I did that long before I even started implementing UDP (the protocols using TCP are so much more interesting to have ).

[turdus]

Let me put it this way:
you don't have to act on ip header field protocol number 17, but you've to write what's behind in order to handle ip protocol number 6.
Is this definition good enough for you?

The point is, you'll need to implement datagram service anyway, even if you don't want UDP. That's all I say.

[Combuster]

and datagram service is...

IPv4 or IPv6.

[Brynet-Inc]

But TCP is, and TCP is build on top of UDP, ICMP and ARP.

No.

TCP and UDP are independent protocols, you do not need to implement both, but you should for sake of completness.

I still say this bounty is rather absurd and poorly thought out, this supposed payout of $500 is hardly worth the effort of writing an entirely TCP/IP stack in assembly.. especially in the time allotted.

[Combuster]

It's a donation, not a hired job. At least he's trying to give him his pennies worth, and if I wasn't epicly busy I would've done that it for that price (after all, someone else would need a stack too in due time).