Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s code a TCP/IP stack, 1: Ethernet and ARP (2016)

saminiir.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Let’s code a TCP/IP stack, 1: Ethernet and ARP (2016)

#21

Post by hylaride »

miohtama wrote: post #17
zoobab wrote: post #13

If you compile a minimal linux kernel without a tcp/ip stack -> 400KB. If you add a tcp/ip stack -> 800KB. For a project where I should just send the temperature, I just made a small C program in userspace that sent the value over a crafted UDP message, saved a lot of space (and complexity) :-).

Curiosly, why is the IP stack so large? 400kbytes of binary is a lot of code. Is it highly optimised for large server use case?

Modern TCP/IP stacks have a lot of extra code, including for anti-spoofing, performance enhancements (eg zero-copy integration with hardware network cards), various attack prevention measures (SYN floods, randomization of sequence numbers, etc) support for various hardware offloading (including many network cards that will do checksum offloading, etc), IPv6 (that also originally mandated IPSec integration), support for lower layer 2 protocols (mostly just ARP for Ethernet, but there are still others around).

Re: Let’s code a TCP/IP stack, 1: Ethernet and ARP (2016)

#23

Post by kasajian »

One minute into it, the article says, "The dmac and smac are pretty self-explanatory fields"

This immediately turns off anyone reading it who doesn't know what those things mean. The thought process will be, "Oh, this article is for those for whom these fields are self-explanatory. Since it's not for me, I'll stop reading"

Re: Let’s code a TCP/IP stack, 1: Ethernet and ARP (2016)

#24

Post by petee »

kasajian wrote: post #23

One minute into it, the article says, "The dmac and smac are pretty self-explanatory fields" This immediately turns off anyone reading it who doesn't know what those things mean. The thought process will be, "Oh, this article is for those for whom these fields are self-explanatory. Since it's not for me, I'll stop reading"

Unless they just updated it, the next sentence explained it -

> They contain the MAC addresses of the communicating parties (destination and source, respectively).

Re: Let’s code a TCP/IP stack, 1: Ethernet and ARP (2016)

#25

Post by howerj »

kasajian wrote: post #23

One minute into it, the article says, "The dmac and smac are pretty self-explanatory fields" This immediately turns off anyone reading it who doesn't know what those things mean. The thought process will be, "Oh, this article is for those for whom these fields are self-explanatory. Since it's not for me, I'll stop reading"

The full quote would be "The dmac and smac are pretty self-explanatory fields. They contain the MAC addresses of the communicating parties (destination and source, respectively).", it does explain them. However, this is an article about how to make a network stack, it is safe to assume the reader should know something about networking before hand.

Re: Let’s code a TCP/IP stack, 1: Ethernet and ARP (2016)

#26

Post by tga_d »

chamomeal wrote: post #20
zoobab wrote: post #13

If you compile a minimal linux kernel without a tcp/ip stack -> 400KB. If you add a tcp/ip stack -> 800KB. For a project where I should just send the temperature, I just made a small C program in userspace that sent the value over a crafted UDP message, saved a lot of space (and complexity) :-).

Wow that’s crazy! As someone who knows nothing about anything: that doesn’t mean the tcp/ip stuff is half the source code of the whole kernel, does it?

The majority of the Linux kernel's source code is device drivers. The overwhelming majority of that is not included in the kernel image by default, but instead made available as kernel modules you can enable as needed. E.g., your thermostat probably doesn't need support for an obscure game controller, so doesn't have those drivers, but it could if you were so inclined.

Re: Let’s code a TCP/IP stack, 1: Ethernet and ARP (2016)

#27

Post by mannyv »

kbouck wrote: post #9

If you disable ARP, you can have a group of servers on the same network configured with the same IP! and if a server acting as a routing frontend can forward packets to a backend server's network interface by mac address (need a kernel extension for this trickery), that backend server will recognize itself as the destination, swap the source/dest IP and respond directly back to the client (without going back through…

F5s have an arp proxy setting so you don't have to do this. The downside is it tends to break dhcp.

Re: Let’s code a TCP/IP stack, 1: Ethernet and ARP (2016)

#29

Post by jpfr »

cihangir wrote: post #14

Years ago, I attempted to build a user-space network stack in C [0] that processes raw packets through the TUN interface and got it working to a certain point. It currently includes a simple shell that allows configuring IP addresses, routes, and such. A hybrid structure reminiscent of both mbuf and sk_buf is used to hold the network packets. However, after completing the UDP implementation I didn't find the time or…

Many embedded devices run the lwip implementation of TCP/IP.

The "POSIX port" of lwip does the same. It takes the raw Ethernet bytes from a TUN/TAP device.

https://github.com/lwip-tcpip/lwip/blob/master/contrib/ports...

Re: Let’s code a TCP/IP stack, 1: Ethernet and ARP (2016)

#30

Post by lmz »

kbouck wrote: post #9

If you disable ARP, you can have a group of servers on the same network configured with the same IP! and if a server acting as a routing frontend can forward packets to a backend server's network interface by mac address (need a kernel extension for this trickery), that backend server will recognize itself as the destination, swap the source/dest IP and respond directly back to the client (without going back through…

Also known as DSR (Direct Server Return) https://www.haproxy.com/blog/layer-4-load-balancing-direct-s...
Post reply on HN