net: recvfrom says who sent it, and a datagram is delivered whole

The second of the two things the stack owed. recvfrom accepted the
address arguments and ignored them, so every caller was told nothing
about where a datagram came from -- which for UDP is most of the point:
a server that cannot see the sender cannot reply to it.

Fixing it properly meant fixing something worse that was sitting
underneath. UDP payloads went into the same byte ring TCP uses, with no
record of where one datagram ended and the next began, so two datagrams
that arrived together came back from one read as one. That is a bug
whose appearance depends on timing and whose blame lands on the sender.

Datagrams now carry a header alongside the bytes: source address, source
port, length. Sixteen of them per socket, in a ring beside the existing
one. Whole buffers would have been 16 sockets x 16 datagrams x an MTU of
static memory for something almost always empty; only the boundaries need
keeping, and those are eight bytes each. A datagram too big for the
buffer it is read into is truncated and the remainder discarded, rather
than left in the ring to be delivered as the head of the next one. One
that arrives with the queue full is dropped whole -- that is UDP's own
contract, and half a datagram in the ring would corrupt every one after.

An empty queue and a zero-length datagram are kept apart, because a
sender really can send zero bytes and the right answer to that is 0
rather than "nothing has arrived yet".

sendto grew the mirror image: a destination address on a datagram
socket, which is what a server replying to whoever just wrote to it
needs. On TCP a destination is ignored rather than refused -- the
connection decides where the bytes go, and programs pass one out of
habit. For a stream, recvfrom's source is read from the pcb: it is the
peer, and it is the same answer for every byte.

Verified: bootcheck -Net now covers UDP too, 45 [ok] and no failures.
The address check is real rather than cosmetic -- nettest deliberately
leaves its sockaddr uninitialised, so a kernel that filled in nothing
would print stack rubbish instead of 10.0.2.2 and the port the responder
is actually on. The boundaries are checked by byte count: the responder
sends 20 bytes and then 16, and the guest reports reading 20 and then
16. Treated as a stream the first read would have taken all 36.

Left for later, and deliberately: accept() still does not report the
peer's address, and getsockname/getpeername do not exist.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

kernel/sys/sys_net.c

@@ -317,47 +317,104 @@ SYSCALL_DEFINE(socketpair)
     return 0;
 }
 
-// send/recv with no flags are read/write. Implementing them here rather than
-// leaving them ENOSYS costs four lines and saves every ported program from
-// having to be rewritten to use write().
+// Host byte order to network, for a port on its way back to userland. The
+// inverse of port_from_net above, and the same two lines: a sockaddr always
+// carries the port big-endian, whichever direction it is travelling.
+static ushort
+port_to_net(ushort p)
+{
+    return (ushort)(((p & 0xFF) << 8) | ((p >> 8) & 0xFF));
+}
+
+// send/recv with no flags are read/write, and sendto/recvfrom are those plus an
+// address. Implementing them here rather than leaving them ENOSYS saves every
+// ported program from being rewritten to use read() and write().
 SYSCALL_DEFINE(sendto)
 {
     struct socket *s;
-    addr_t ubuf;
-    int len, flags, r;
+    addr_t ubuf, uaddr;
+    int len, flags, ulen, r;
+    uint   ip   = 0;
+    ushort port = 0;
 
     if ((r = argsock(0, &s)) < 0)
         return r;
     argaddr(1, &ubuf);
     argint(2, &len);
     argint(3, &flags);
+    argaddr(4, &uaddr);
+    argint(5, &ulen);
 
     if (len < 0)
         return -EINVAL;
     char *p = (char *)user_ptr(ubuf, (uint64)len);
     if (len && !p)
         return -EFAULT;
-    return sockwrite(s, p, len);
+
+    // A null address is send(), not an error: the socket already knows where
+    // it is pointed, which for TCP is the only possibility anyway.
+    if (uaddr) {
+        if ((r = fetch_sin(uaddr, ulen, &ip, &port)) < 0)
+            return r;
+        port = port_from_net(port);
+    }
+    return socksendto(s, p, len, ip, port);
 }
 
 SYSCALL_DEFINE(recvfrom)
 {
     struct socket *s;
-    addr_t ubuf;
+    addr_t ubuf, uaddr, ulenp;
     int len, flags, r;
+    uint   ip   = 0;
+    ushort port = 0;
 
     if ((r = argsock(0, &s)) < 0)
         return r;
     argaddr(1, &ubuf);
     argint(2, &len);
     argint(3, &flags);
+    argaddr(4, &uaddr);
+    argaddr(5, &ulenp);
 
     if (len < 0)
         return -EINVAL;
     char *p = (char *)user_ptr(ubuf, (uint64)len);
     if (len && !p)
         return -EFAULT;
-    return sockread(s, p, len);
+
+    r = sockrecvfrom(s, p, len, &ip, &port);
+    if (r < 0 || uaddr == 0)
+        return r;
+
+    // The address is reported only for the family that has one to report. A
+    // Unix socket leaves ip at zero, and the honest answer there is a length of
+    // zero rather than a sockaddr full of nothing that a caller would read as
+    // 0.0.0.0:0 and believe.
+    int alen = 0;
+    if (sock_domain(s) == AF_INET) {
+        struct sockaddr_in sa;
+        memset(&sa, 0, sizeof(sa));
+        sa.sin_family = AF_INET;
+        sa.sin_addr   = ip;
+        sa.sin_port   = port_to_net(port);
+        alen = (int)sizeof(sa);
+
+        // Truncated rather than refused if the caller's buffer is smaller,
+        // which is what accept() and getsockname() do everywhere: the length
+        // written back tells them what they got.
+        int cap = alen;
+        if (ulenp && get_user(cap, ulenp) < 0)
+            return -EFAULT;
+        if (cap > alen)
+            cap = alen;
+        if (cap > 0 && copy_to_user(uaddr, &sa, (uint64)cap) < 0)
+            return -EFAULT;
+    }
+
+    if (ulenp && copy_to_user(ulenp, &alen, sizeof(alen)) < 0)
+        return -EFAULT;
+    return r;
 }
 
 // shutdown(2). Half-close is not modelled -- there is one buffer per