Re: Difficulty with netbooting - le0: lost carrier when bringing downthenetbsd kernel
Mouse <[email protected]> Wed, 7 Jan 2026 05:44:39 -0500 (EST)
| Newsgroups | gmane.os.netbsd.ports.hp300 |
|---|---|
| Message-ID | <[email protected]> |
> Using tcpdump I can see inbound traffic on port 111, but nothing outbound: Hm? This looks to me like traffic in both directions: > 00:38:54.842747 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 104) 192.168.2.123.1023 > 192.168.2.23.111: [no cksum] UDP, length 76 > 00:38:54.842990 IP (tos 0x0, ttl 64, id 44675, offset 0, flags [DF], proto UDP (17), length 56) 192.168.2.23.111 > 192.168.2.123.1023: [bad udp cksum 0x8618 -> 0xf3b4!] UDP, length 28 Which one is the hp300 and which is the pi? I would tend to assume .123 is the hp300 and .23 is the pi, since 111 is the portmapper port and 1023 is nothing special (just a high "privileged" port). I assume the tcpdump in question was running on the pi; since you didn't mention an interposed snooper machine, I assume there isn't one, and it sure isn't running on the hp300. :-) In any case, the "bad udp chcksum" indicates that at least one of the kernel, portmapper, or tcpdump on the .23 machine is severely busted. (Possibly tcpdump, if it's lying about the checksum being bad. Otherwise, the checksum really is wrong, in which case possibly the kernel, if it generated the bad checksum, or possibly the portmapper, if *it* generated a bad checksum and then told the kernel to send it without recomputation, if that's even possible on that OS.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B