Whether you have used pink or trace road or trace path, some of those implementations,
I just wonder, does anybody use arping?
Okay, you are network administrators, I guess.
And clock diff, has anyone used recently clock diff?
No, that's a nice question.
Thank you.
IPv2 is a very old project.
It was started by Alex Seikyuznetsov in 1999.
He was a Linux-Cannell network upstream developer.
He was also IPv2 upstream developer at the time.
He ported some BSD sources from Linux and he wrote some other tools for IPv2.
And he maintained the project till 2002.
He also used net-death-linux-cannell mailing list.
Hideaki Yoshifuji was the next maintainer.
He was also Linux-Cannell network developer.
He was doing IPv6 at the time.
Hideaki improved the project a lot.
He started to use Git, so we have some history now.
He moved the project to source for Chnet, which was popular at the time.
And he still continued to use net-death-mailing list.
He introduced use-illipsee support, so it was not just for G-Lipsee.
Although he made his last release in 2015, the last widely-adopted release was probably
the previous one from 2012.
Because IPv2's development slowed down, David Heidelberg forked IPv2 and moved development
on GitHub in 2014.
The initial goal was to upstream various patches from Linux distributions.
Still at that time, I did also muscle-lipsee support and other things, because the tools
were very old.
License cleanup was done, which people from Linux distributions approved or were happy
about that.
There were other people at the time, for example, Janssen Aček and Pavel Šimetdá.
They were both from Redezhet.
Pavel improved a lot, modernized the code.
He started to use the new C-functions, get other info instead of the old ones, which
were for IPv4 or for IPv6.
And there were other improvements.
Semi-Carola was the next maintainer, starting in 2017.
He modernized the code a lot.
And he also introduced Messonbelt system.
There were other people at the time, Noach, Myron Hans and Yuri Hornovian, who still maintains
localization.
There could be another question, who needs localization for tools like Pink?
Really?
I guess not really many people, but I got approached that people really like localization.
So I kept that.
I came in 2017 and actually there were obviously many people in Git history.
There are nearly 140 contributors.
And there was history before.
So current tools.
IPv2 tools have currently Pink, Arping, Tracepath and Clogdiff.
Pink sends ICMP a correct Vest to network host.
It's very old-called from 1983.
I think it's the most important IPv2 tool.
And it supports both Sockets, raw socket and ICMP datagram socket, which is more secure.
Unfortunately, not all distros use that.
I see some of the people from the Bien.
So I would recommend to stop using raw socket.
But the reason why it's used is system D, which is not used on all systems.
You know, the Bien supports other, other in its system.
So that is reason why Pink wouldn't work by default.
Yeah.
Below we have example, pingingsusa.com.
That's very basic example.
I'm sorry.
Pink supports obviously a lot of functionality.
So there are loads of switches.
So just a simple example.
Arping.
It sends ARP requests to network host.
It was written by Alexei Kuznetsov.
And it supports IPv4 only because the protocol itself is for IPv4 only.
So, again, basic example.
Trace path.
It traces path to network host discovering MTU.
Again, it was written by Alexei Kuznetsov.
There's a small example.
Tracing path to suce.com.
And clock diff.
That's again very old quote from 1985 from unknown author supports IPv4 only.
We removed some obsolete tools in 2021.
Those tools were using some experimental protocol which were not relevant later.
Or there were much better implementation of other tools.
So there was no point to maintain something which is not really well used or it's kind
of buggy.
Because those tools we have in IPv2 are basic network tools.
You know, written long time ago.
There are obviously other projects which are implementing similar tools.
So just to highlight some of them.
F-Ping is very enhanced ping.
It's written in modern C.
It allows to ping any number of targets.
Its output is designed to be parsed.
So it's good for using in scripts.
Also it doesn't perform reverse DNS lookup by default.
Which is in some cases faster.
MTR, my trace road.
It's a tool which combines trace road and ping.
It uses QE and N-Curses.
And it's also for free BSD.
Very nice tool.
Those two projects are collection of tools.
So busybox is for low power embedded devices.
It has many tools and among them are ping, ping and trace road.
It's somehow compatible with tools from IPv2 but it implements just part of the functionality.
Inetutils is old GNU project which also has RHS and stuff like that.
So very old project.
Not that active nowadays and it has also ping and trace road.
So future, IPv2's future, what we should do.
We should rewrite the code to the modern C.
We concentrate mainly on ping so other tools are neglected.
I wonder whether we should keep clock diff.
Also trace path, it's questionable because my trace road is much better.
There is trace road, the original project which is also better than trace path.
So it's a question whether to keep this.
Project would need reviewers and real network developers.
We should write tests because we have CI tests but we don't have functional tests.
So sometimes regression slips in.
Tools could have JSON output and color output.
So that's it.
Do you have any question?
Sorry, I didn't quite understand how system D or lack of it can force to use row circuits.
There is a sys control tool which handles kernel parameters for networking.
ICMP data gram socket is by default allowed just for root.
So if you want to have ping just for normal users and you want to use
safer ICMP data gram socket you need to set something.
And this row says that with ETC, CCTL config or somehow is called that file.
And this works differently for system D and for other tools.
So if you want to use busy boxes in its system then you would lose this configuration.
I would say mainly there should be a solution just not to block this and there is the band bug report.
But no one works about that.
Any other questions?
Hello.
So I have one question.
What is the future of the IP tools?
So what's the next feature or roadmap that you are actually getting on?
What's the future?
Or like five years or ten years?
So those tools are very old.
So one would say the work has been done.
But the problem is there are bugs, there are improvements which can you know,
broad regression.
My motivation to join the development was to keep ping working because I need that for
Kana network testing.
So I would say there is no future otherwise someone finds interesting to rewrite the tool
as an exercise to rewrite them into more than C because the code is terrible.
It's 40 years old or something.
So no real future but I think JSON output would be a good feature and color output would be also good.
So some of those.
But mainly maintenance mode.