Hi All,
Just wanted to know the status of the tickets in this link , whether they are fully/partially implemented or not implemented .
Custom Query – Haiku.
I am thinking of focussing on the implementation of path mtu discovery but everyone is welcome to suggest if anything else in this list has a higher priority than my choice .
1 Like
I think all those tickets are still valid, yes.
I don’t know what else would be higher priority. The ticket about memory leaks I intend to look into myself in the coming weeks, as I know my way around the network stack better now…
@waddlesplash This issue (#12310 (ICMP errors don't seem to be correctly propagated in all cases) – Haiku) mentions about ICMP destination host unreachable prints not coming in the host machine , Is that correct ?
If yes, I believe the issue is already resolved . I tried pinging a random ip address and it gave the following output . I am running haiku inside a VM .
If you’re on a nightly, that’s possible as there were few commits by @waddlesplash about 24 hours ago. See here, I think it’s probably this one that fixed it. IPv4: Make header fields go out of scope when no longer usable.
No, I don’t think this is the problem mentioned, so I don’t think anything is fixed here. This is a “sendto” error, not an ICMP error, I think.
@waddlesplash So you are saying it should come like this ?
From 192.168.1.31 icmp_seq=8 Destination Host Unreachable
From 192.168.1.31 icmp_seq=9 Destination Host Unreachable
From 192.168.1.31 icmp_seq=10 Destination Host Unreachable
No, the screenshot is correct for what it shows: there’s no route for the packets at all.
The example you give here would be for when the packets are sent, but a server down the line returned a “host unreachable” error.
@waddlesplash then What is the error that is being specified in the ticket ? I am not able to interpret it correctly .
In my linux host, if I try to ping a random ip with a subnet of 192.168.1.1, I will get the error message as mentioned in the previous comment .
Whereas, if I try to ping the same random ip from haiku inside a VM (using bridged adapter setting for networking ), I get the message as attached in the screenshot .
Can you kindly clarify if I am understanding the issue in the ticket or totally going down a wrong path ?
I am seeing “ICMP unreachable” in tcpdump, but ping doesn’t show those (although strace seems to show that ping might get those ICMP messages):
~> tcpdump -npi /dev/net/virtio/0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on /dev/net/virtio/0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:11:59.629478 IP 192.168.171.49 > 192.168.173.2: ICMP echo request, id 64514, seq 0, length 64
01:12:00.641866 IP 192.168.171.49 > 192.168.173.2: ICMP echo request, id 64514, seq 1, length 64
01:12:01.650859 IP 192.168.171.49 > 192.168.173.2: ICMP echo request, id 64514, seq 2, length 64
01:12:02.664780 IP 192.168.171.49 > 192.168.173.2: ICMP echo request, id 64514, seq 3, length 64
01:12:02.689772 IP 192.168.173.24 > 192.168.171.49: ICMP host 192.168.173.2 unreachable, length 92
01:12:02.690791 IP 192.168.173.24 > 192.168.171.49: ICMP host 192.168.173.2 unreachable, length 92
01:12:02.691006 IP 192.168.173.24 > 192.168.171.49: ICMP host 192.168.173.2 unreachable, length 92
01:12:02.691159 IP 192.168.173.24 > 192.168.171.49: ICMP host 192.168.173.2 unreachable, length 92
01:12:03.681638 IP 192.168.171.49 > 192.168.173.2: ICMP echo request, id 64514, seq 4, length 64
01:12:06.757071 IP 192.168.173.24 > 192.168.171.49: ICMP host 192.168.173.2 unreachable, length 92
and
~> strace ping -c 5 192.168.173.2
[ 764] <... image_relocated resumed> (1452 us)
[ 764] set_area_protection(0x45e7, B_READ_AREA|B_EXECUTE_AREA) = 0x0 No error (649 us)
[ 764] set_area_protection(0x45ea, B_READ_AREA|B_EXECUTE_AREA) = 0x0 No error (895 us)
[ 764] set_area_protection(0x45ed, B_READ_AREA|B_EXECUTE_AREA) = 0x0 No error (546 us)
[ 764] set_area_protection(0x45f0, B_READ_AREA|B_EXECUTE_AREA) = 0x0 No error (689 us)
[ 764] set_area_protection(0x45f2, B_READ_AREA|B_EXECUTE_AREA) = 0x0 No error (475 us)
[ 764] set_area_protection(0x45f4, B_READ_AREA|B_EXECUTE_AREA) = 0x0 No error (433 us)
[ 764] get_system_info(0x7fe4e732dc70) = 0x0 No error (732 us)
[ 764] get_system_info(0x7fe4e732da70) = 0x0 No error (553 us)
[ 764] reserve_address_range([0x100100000000], B_RANDOMIZED_BASE_ADDRESS, 0x1000000000) = 0x0 No error ([0x1102af50f000]) (796 us)
[ 764] create_area("heap", [0x1102af50f000], B_EXACT_ADDRESS, 0x40000, 0x0, B_READ_AREA|B_WRITE_AREA) = 0x45f9 ([0x1102af50f000]) (2563 us)
[ 764] open(0xffffffff, "/dev/random", 0, 0x0) = 0x3 (947 us)
[ 764] read(0x3, 0xffffffffffffffff, 0x18172059988, 0x8) = 0x8 (357 us)
[ 764] close(0x3) = 0x0 No error (496 us)
[ 764] resize_area(0x45f9, 0x60000) = 0x0 No error (611 us)
[ 764] get_next_image_info(0x0, [0x0], 0x7fe4e732d5a0, 0x450) = 0x0 No error (1137 us)
[ 764] open(0xffffffff, "/boot/system/data/network/protocols", O_CLOEXEC, 0x0) = 0x3 (770 us)
[ 764] read_stat(0x3, (nil), false, 0x7fe4e732da70, 0x80) = 0x0 No error (379 us)
[ 764] read(0x3, 0xffffffffffffffff, 0x1102af565170, 0x2000) = 0x182c (491 us)
[ 764] close(0x3) = 0x0 No error (296 us)
[ 764] socket(AF_INET, SOCK_RAW, 0x1) = 0x3 (357 us)
[ 764] getsockopt(0x3, 0xffffffff, 0x40000001, 0x7fe4e732ddd4, [0x4]) = 0x0 No error (1211 us)
[ 764] setsockopt(0x3, 0xffffffff, 0x40000004, 0x20da4deaae0, 0x4) = 0x0 No error (394 us)
[ 764] read_stat(0x1, (nil), false, 0x7fe4e732b190, 0x80) = 0x0 No error (722 us)
[ 764] ioctl(0x1, TCGETA, 0x7fe4e732b160, 0x20) = 0x0 No error (310 us)
PING 192.168.173.2 (192.168.173.2): 56 data bytes
[ 764] write(0x1, 0xffffffffffffffff, 0x1102af565170, 0x32) = 0x32 (577 us)
[ 764] sigaction(0x2, 0x7fe4e732dd40, 0x7fe4e732dd60) = 0x0 No error (979 us)
[ 764] sigaction(0xe, 0x7fe4e732dd40, 0x7fe4e732dd60) = 0x0 No error (299 us)
[ 764] sendto(0x3, 0x20da4deabf4, 0x40, 0, {AF_INET, 192.168.173.2/0}, 0x20) = 0x40 (1758 us)
[ 764] sigaction(0xe, 0x7fe4e732dd20, 0x7fe4e732dd40) = 0x0 No error (622 us)
[ 764] set_timer(0x0, 0xffffffff, 0xf4240, 0x0, 0x8, 0x7fe4e732dc60) = 0x0 No error (217 us)
[ 764] recvfrom(0x3, 0x1102af524e00, 0xc0, 0, 0x7fe4e732de00, [0x20]) = 0xffffffff8000000a (1000023 us)
[ 764] --- SIGALRM (Alarm) {si_signo=SIGALRM, si_code=SI_TIMER, si_pid=764, si_uid=0, si_value=(nil)} ---
[ 764] sendto(0x3, 0x20da4deabf4, 0x40, 0, {AF_INET, 192.168.173.2/0}, 0x20) = 0x40 (2353 us)
[ 764] sigaction(0xe, 0x7fe4e732d7c0, 0x7fe4e732d7e0) = 0x0 No error (582 us)
[ 764] set_timer(0x0, 0xffffffff, 0xf4240, 0x0, 0x8, 0x7fe4e732d700) = 0x0 No error (425 us)
[ 764] restore_signal_frame(0x7fe4e732d850) = 0xffffffff8000000a (237 us)
[ 764] recvfrom(0x3, 0x1102af524e00, 0xc0, 0, 0x7fe4e732de00, [0x20]) = 0xffffffff8000000a (1000181 us)
[ 764] --- SIGALRM (Alarm) {si_signo=SIGALRM, si_code=SI_TIMER, si_pid=764, si_uid=0, si_value=(nil)} ---
[ 764] sendto(0x3, 0x20da4deabf4, 0x40, 0, {AF_INET, 192.168.173.2/0}, 0x20) = 0x40 (3857 us)
[ 764] sigaction(0xe, 0x7fe4e732d7c0, 0x7fe4e732d7e0) = 0x0 No error (800 us)
[ 764] set_timer(0x0, 0xffffffff, 0xf4240, 0x0, 0x8, 0x7fe4e732d700) = 0x0 No error (815 us)
[ 764] restore_signal_frame(0x7fe4e732d850) = 0xffffffff8000000a (797 us)
[ 764] recvfrom(0x3, 0x1102af524e00, 0xc0, 0, 0x7fe4e732de00, [0x20]) = 0xffffffff8000000a (998989 us)
[ 764] --- SIGALRM (Alarm) {si_signo=SIGALRM, si_code=SI_TIMER, si_pid=764, si_uid=0, si_value=(nil)} ---
[ 764] sendto(0x3, 0x20da4deabf4, 0x40, 0, {AF_INET, 192.168.173.2/0}, 0x20) = 0x40 (2723 us)
[ 764] sigaction(0xe, 0x7fe4e732d7c0, 0x7fe4e732d7e0) = 0x0 No error (2206 us)
[ 764] set_timer(0x0, 0xffffffff, 0xf4240, 0x0, 0x8, 0x7fe4e732d700) = 0x0 No error (456 us)
[ 764] restore_signal_frame(0x7fe4e732d850) = 0xffffffff8000000a (915 us)
[ 764] recvfrom(0x3, 0x1102af524e00, 0xc0, 0, 0x7fe4e732de00, [0x20]) = 0x70 (16146 us)
[ 764] set_signal_mask(0x1, 0x7fe4e732dde8, [0x0]) = 0x0 No error (1304 us)
[ 764] set_signal_mask(0x3, 0x7fe4e732dde0, (nil)) = 0x0 No error (750 us)
[ 764] recvfrom(0x3, 0x1102af524e00, 0xc0, 0, 0x7fe4e732de00, [0x20]) = 0x70 (2189 us)
[ 764] set_signal_mask(0x1, 0x7fe4e732dde8, [0x0]) = 0x0 No error (1214 us)
[ 764] set_signal_mask(0x3, 0x7fe4e732dde0, (nil)) = 0x0 No error (392 us)
[ 764] recvfrom(0x3, 0x1102af524e00, 0xc0, 0, 0x7fe4e732de00, [0x20]) = 0x70 (621 us)
[ 764] set_signal_mask(0x1, 0x7fe4e732dde8, [0x0]) = 0x0 No error (586 us)
[ 764] set_signal_mask(0x3, 0x7fe4e732dde0, (nil)) = 0x0 No error (552 us)
[ 764] recvfrom(0x3, 0x1102af524e00, 0xc0, 0, 0x7fe4e732de00, [0x20]) = 0x70 (1041 us)
[ 764] set_signal_mask(0x1, 0x7fe4e732dde8, [0x0]) = 0x0 No error (1778 us)
[ 764] set_signal_mask(0x3, 0x7fe4e732dde0, (nil)) = 0x0 No error (734 us)
[ 764] recvfrom(0x3, 0x1102af524e00, 0xc0, 0, 0x7fe4e732de00, [0x20]) = 0xffffffff8000000a (958032 us)
[ 764] --- SIGALRM (Alarm) {si_signo=SIGALRM, si_code=SI_TIMER, si_pid=764, si_uid=0, si_value=(nil)} ---
[ 764] sendto(0x3, 0x20da4deabf4, 0x40, 0, {AF_INET, 192.168.173.2/0}, 0x20) = 0x40 (5531 us)
[ 764] sigaction(0xe, 0x7fe4e732d7c0, 0x7fe4e732d7e0) = 0x0 No error (646 us)
[ 764] sigaction(0xe, 0x7fe4e732d7c0, 0x7fe4e732d7e0) = 0x0 No error (221 us)
[ 764] set_timer(0x0, 0xffffffff, 0x989680, 0x0, 0x8, 0x7fe4e732d700) = 0x0 No error (854 us)
[ 764] restore_signal_frame(0x7fe4e732d850) = 0xffffffff8000000a (385 us)
[ 764] recvfrom(0x3, 0x1102af524e00, 0xc0, 0, 0x7fe4e732de00, [0x20]) = 0x70 (3070213 us)
[ 764] set_signal_mask(0x1, 0x7fe4e732dde8, [0x0]) = 0x0 No error (1770 us)
[ 764] set_signal_mask(0x3, 0x7fe4e732dde0, (nil)) = 0x0 No error (958 us)
[ 764] recvfrom(0x3, 0x1102af524e00, 0xc0, 0, 0x7fe4e732de00, [0x20]) = 0xffffffff8000000a (6921846 us)
[ 764] --- SIGALRM (Alarm) {si_signo=SIGALRM, si_code=SI_TIMER, si_pid=764, si_uid=0, si_value=(nil)} ---
[ 764] sigaction(0x2, 0x7fe4e732d7d0, 0x7fe4e732d7f0) = 0x0 No error (923 us)
[ 764] sigaction(0xe, 0x7fe4e732d7d0, 0x7fe4e732d7f0) = 0x0 No error (1047 us)
[ 764] write(0x1, 0xffffffffffffffff, 0x1102af565170, 0x1) = 0x1 (678 us)
--- 192.168.173.2 ping statistics ---
[ 764] write(0x1, 0xffffffffffffffff, 0x1102af565170, 0x26) = 0x26 (434 us)
5 packets transmitted, 0 packets received, 100% packet loss
[ 764] write(0x1, 0xffffffffffffffff, 0x1102af565170, 0x3c) = 0x3c (669 us)
[ 764] exit_team(0x1) (536 us)
BTW, if I had to make a guess why ping doesn’t show anything here, it’s probably because of ping.c « ping « network « bin « src - haiku - Haiku's main repository (check_icmph)
That doesn’t seem to make sense.
@cmeerw If I am pinging an ip in my local subnet and the ip is invalid , so arp does not go through, in this scenario, do we expect the ping to show “destination host unreachable” , like it shows in linux ?
I would expect ping to print any related ICMP unreachable message it receives (which I think is what ticket #12310 is about).
I am not sure if the failed ARP triggers an ICMP unreachable message on Haiku, so it might be a different issue.
@cmeerw Correct me if I am wrong
For global ip addresses, there is no guarantee that the destination router will reply back with “destination host unreachable” message .
Also, how are you getting back icmp response while trying to ping a private ip from different subnet ? aren’t routers supposed to block/ignore ping to private ip’s in different subnets ?
Yes, sure, you don’t get any guarantees.
It’s all Linux based routing here. There is no reason to block anything.
But private ip addresses are not routable on the internet , right ? So how you are pinging from 1 subnet to the other ?
These are just local subnets.
It is not even reaching the condition . The ip version check is failing only in that function .
@waddlesplash @cmeerw Why is the structure definition for icmp_header put in icmp.cpp and not in ip_icmp.h where icmp packet structure is defined ?
Haiku-implementation is needed in some cases. MTR was implemented
which suoercedes the current ping/traceroute tools for Haiku R1B4.
Well… I’d rather say, check the results or test conditions with MTR if ping/traceroute fails what you are testing.
@cocobean @waddlesplash @cmeerw in case of icmp reponse not being type 0 (ICMP_ECHOREPLY), I see that we are trying to send a dns resolution for the source address in the icmp response . I wanted to know why is it necessary to do a dns resolution in this case, because we are not doing the same when the icmp response is of type 0 .
Relevant link → (ping.c « ping « network « bin « src - haiku - Haiku's main repository)