Re: [9fans] bug or feature ? --- ip/ping -6

[Anthony Martin]

erik quanstrom  once said:
> unfortunately, the simlification removes the code that solves an important
> use case.  it's important to be able to specify the protocol or network stack,
> such as in
> 
>   ip/ping /net.alt/icmp!someaddress

Most commands use an -x option and setnetmtpt(2) to arrange
an alternate network root. Is there any reason not to do the
same for ip/ping?

  Anthony

Re: [9fans] bug or feature ? --- ip/ping -6

[erik quanstrom]

> erik quanstrom  once said:
> > unfortunately, the simlification removes the code that solves an important
> > use case.  it's important to be able to specify the protocol or network 
> > stack,
> > such as in
> > 
> > ip/ping /net.alt/icmp!someaddress
> 
> Most commands use an -x option and setnetmtpt(2) to arrange
> an alternate network root. Is there any reason not to do the
> same for ip/ping?

"most" commands do not.  for example,

cpu -h /net.alt/tcp!ladd.quanstro.net

sorry i haven't the time to do statistics, but i'm pretty sure that
only programs lib ndb/dnsquery that do not take dial strings are
exceptions here.  and they are self-inconsistent.  some take -x
(bare option) and some take -x /mnt/pt.

that notwithstanding, it seems logical to allow icmpv6!host
as a proper dial string for ping, and this requires the same code.

i think it makes sense to do it as ping and traceroute have done.

- erik

Re: [9fans] bug or feature ? --- ip/ping -6

[erik quanstrom]

> "most" commands do not.  for example,
> 
>   cpu -h /net.alt/tcp!ladd.quanstro.net
> 

it turns out i had a bit of extra time since it's too icy to leave the
house.  :-(

anyway, here are all the programs that take -x mntpt, as determined by
the man pages.

vnc(1) vncs
httpfile(4)
6in4(8)
ndb(8) ndb/cs, csquery, dns, dnstcp, dnsquery, dnsdebug
ppp(8) ip/ppp, pppoe, pptp, pptpd
secstore(8) secstored
syslogd(8)
udpecho(8)

none of these programs take a dial string.

however, some of them could (see nettest(8), 
http://sources.9atom.org/magic/man2html/8/nettest)
such as syslogd, udpecho, secstored and vncs.

httpfile, well, rob has already made the point.

- erik

Re: [9fans] bug or feature ? --- ip/ping -6

[hiro]

your ipv4 "embedding" doesn't need to be part of the ping tool. it's
not commonly used anyway.
allowing the ping tool to do dns lookups on the other hand are a
common convenience.

Re: [9fans] bug or feature ? --- ip/ping -6

[erik quanstrom]

unfortunately, the simlification removes the code that solves an important
use case.  it's important to be able to specify the protocol or network stack,
such as in

ip/ping /net.alt/icmp!someaddress

the diff is here and i'll be working on a patch.

the basic idea is to translate only the dns names to ip addresses, and then
reassemble the string.  this way we can keep any decorations such as 
/net.alt/icmpv6!...

- erik

---

lilly; diff -c `{yesterday -n20 /sys/src/cmd/ip/ping.c} /sys/src/cmd/ip/ping.c
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:28,34 - /sys/src/cmd/ip/ping.c:28,34
  
  typedef struct {
int version;
-   char*net;
+   char*protoname;
int echocmd;
int echoreply;
unsigned iphdrsz;
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:393,398 - /sys/src/cmd/ip/ping.c:393,401
  
  /* from /sys/src/libc/9sys/dial.c */
  
+ static char defnet[] = "/net";
+ static char defproto[] = "icmp";
+ 
  enum
  {
Maxstring   = 128,
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:406,416 - /sys/src/cmd/ip/ping.c:409,414
char*netdir;
char*proto;
char*rem;
- 
-   /* other args */
-   char*local;
-   char*dir;
-   int *cfdp;
  };
  
  /*
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:417,423 - /sys/src/cmd/ip/ping.c:415,421
   *  parse a dial string
   */
  static void
- _dial_string_parse(char *str, DS *ds)
+ dsparse(char *str, char *defproto, DS *ds)
  {
char *p, *p2;
  
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:425,437 - /sys/src/cmd/ip/ping.c:423,435
ds->buf[Maxstring-1] = 0;
  
p = strchr(ds->buf, '!');
-   if(p == 0) {
-   ds->netdir = 0;
-   ds->proto = "net";
+   if(p == nil) {
+   ds->netdir = nil;
+   ds->proto = defproto;
ds->rem = ds->buf;
} else {
if(*ds->buf != '/' && *ds->buf != '#'){
-   ds->netdir = 0;
+   ds->netdir = nil;
ds->proto = ds->buf;
} else {
for(p2 = p; *p2 != '/'; p2--)
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:443,506 - /sys/src/cmd/ip/ping.c:441,560
*p = 0;
ds->rem = p + 1;
}
+   if(ds->netdir == nil || ds->netdir[0] == 0)
+   ds->netdir = defnet;
  }
  
  /* end excerpt from /sys/src/libc/9sys/dial.c */
  
- /* side effect: sets network & target */
- static int
- isv4name(char *name)
+ char*
+ dstopretty(DS *ds, char *name)
  {
-   int r = 1;
-   char *root, *ip, *pr;
+   char *port;
+ 
+   port = strchr(ds->rem, '!');
+   if(port == nil)
+   port = "";
+ 
+   if(ds->netdir == defnet)
+   return smprint("%s!%s%s", ds->proto, name, port);
+   else
+   return smprint("%s/%s!%s%s", ds->netdir, ds->proto, name, port);
+ }
+ 
+ char*
+ nametoip(char *name0, int *ipver, char **target, char **pretty)
+ {
+   int n,fd;
+   char buf[128], ip6[128], ip4[128], *cs, *s, *p, *name, *addr, *ip;
DS ds;
  
-   _dial_string_parse(name, );
+   *target = nil;
+   dsparse(name0, defproto, );
  
-   /* cope with leading /net.alt/icmp! and the like */
-   root = nil;
-   if (ds.netdir != nil) {
-   pr = strrchr(ds.netdir, '/');
-   if (pr == nil)
-   pr = ds.netdir;
-   else {
-   *pr++ = '\0';
-   root = ds.netdir;
-   network = strdup(root);
+   /* do not override protocol specified */
+   if(*ipver == -1 && ds.proto != defproto){
+   if(strcmp(ds.proto, v4pr.protoname) == 0)
+   *ipver = 4;
+   else if (strcmp(ds.proto, v6pr.protoname) == 0)
+   *ipver = 6;
+   }
+ 
+   name = ds.rem;
+   ip6[0] = 0;
+   ip4[0] = 0;
+   if(isdottedquad(name)){
+   snprint(ip4, sizeof ip4, "%s", name);
+   goto match;
+   }
+   if(isv6lit(name)){
+   snprint(ip6, sizeof ip6, "%s", name);
+   goto match;
+   }
+ 
+ 
+   cs = smprint("%s/cs", ds.netdir);
+   fd = open(cs, ORDWR);
+   if(fd < 0)
+   sysfatal("cannot open %s: %r", cs);
+   free(cs);
+ 
+   addr = smprint("tcp!%s!1", name);
+   if(write(fd, addr, strlen(addr)) != strlen(addr)){
+   close(fd);
+   sysfatal("cannot write %s to %s: %r", addr, cs);
+   }
+   free(addr);
+   seek(fd, 0, 0);
+   while((n = read(fd, buf, sizeof(buf)-1)) > 0){
+   buf[n] = 0;
+   ip = strchr(buf,' ');
+   ip++;
+   p = strchr(ip,'!');
+   *p = 0;
+   if(isdottedquad(ip)){
+   if(ip4[0] == 0)
+   snprint(ip4, sizeof ip4, "%s", ip);
+   

Re: [9fans] bug or feature ? --- ip/ping -6

[erik quanstrom]

> i spent some time thinking about this problem.
> 
> the purpose of -6 is to force icmpv6.  (one can use a v4 address
> with icmpv6, that works due to ipv4 embedding.)  this is not the same as
> controlling name lookup.  since there are better more flexible tools
> for doing that by hand.  the result can be fead to ip/ping.
> 
> it's kind of an ugly problem.

and it turns out that the patch as given breaks things like
ip/ping /net.alt/icmpv6!hostname

- erik

Re: [9fans] bug or feature ? --- ip/ping -6

[erik quanstrom]

On Sun Jan  3 13:42:21 PST 2016, 23h...@gmail.com wrote:
> your ipv4 "embedding" doesn't need to be part of the ping tool. it's
> not commonly used anyway.

i think the attribution here is false.  i read the man page for that 
information.

in any event, ping as patched is wrong.  addresses like icmpv6!address must
be accepted.  this may make the -4 flag silly in it's current form.

> allowing the ping tool to do dns lookups on the other hand are a
> common convenience.

but as such, one loses precision.  for example if i use a name, i can't
easily force the name lookup to find the ip i'm thinking of.

> perhaps i misunderstand. i'm not against adding zeros at the front.

see /sys/src/libip/ipaux.c^/uchar v4prefix

- erik

Re: [9fans] bug or feature ? --- ip/ping -6

[hiro]

-4 and -6 should error when used with an ip of the wrong type. when
used with domains correct behavior should be trivial and if there's no
dns response for A or  it should error once again.

Re: [9fans] bug or feature ? --- ip/ping -6

[erik quanstrom]

unfortunately, there is some imprecision when mixing -4 and -6 with names,
and i don't have a tidy solution.

also, the man page claims that the biggest an icmp packet could possibly be is 
8192 bytes, which
is incorrect.  icmp is fragmented like any other ip packet, so the maximum 
payload is 64k.

- erik

Re: [9fans] bug or feature ? --- ip/ping -6

[erik quanstrom]

on reading the man page, i found a small flaw in the implementation.  according 
to
the man page, -6 forces is of icmp6, even if the address is icmp4.  i changed 
ping to
do that.as a result, i added a -4 flag which forces the ping to use icmp4.  
obviously, there is no
native 6-in-4, so this is an error.

also, i corrected an indirection of a nil pointer when a name lookup fails.

my pathetic excuse for unit testing, and a diff are below.  my version (hacks 
and all)
is attached.

- erik

ps.  the hand-implementation of csquery seems to be a result of not trusting
ndb/cs to be running.  odd.  does anyone have context on why this would be 
useful?

---

; ip/ping -6an1 bwc
sending 1 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::9!1
2402:6b00:22cd:bf80::7 -> 2402:6b00:22cd:bf80::9
0: 2402:6b00:22cd:bf80::9 -> 2402:6b00:22cd:bf80::7 rtt 78 µs, avg rtt 78 µs, 
ttl = 255
; ip/ping -4an1 bwc
sending 1 64 byte messages 1000 ms apart to icmp!10.1.1.9!1
10.1.1.7 -> 10.1.1.9
0: 10.1.1.9 -> 10.1.1.7 rtt 70 µs, avg rtt 70 µs, ttl = 255
; ip/ping -an1 bwc
sending 1 64 byte messages 1000 ms apart to icmp!10.1.1.9!1
10.1.1.7 -> 10.1.1.9
0: 10.1.1.9 -> 10.1.1.7 rtt 72 µs, avg rtt 72 µs, ttl = 255
; ip/ping -4an1 10.1.1.7
sending 1 64 byte messages 1000 ms apart to icmp!10.1.1.7!1
10.1.1.7 -> 10.1.1.7
0: 10.1.1.7 -> 10.1.1.7 rtt 15 µs, avg rtt 15 µs, ttl = 255
; ip/ping -6an1 10.1.1.7
sending 1 64 byte messages 1000 ms apart to icmpv6!10.1.1.7!1
2402:6b00:22cd:bf80::7 -> 10.1.1.7
0: 10.1.1.7 -> 10.1.1.7 rtt 18 µs, avg rtt 18 µs, ttl = 255
; ip/ping -4an1 2402:6b00:22cd:bf80::7
ip/ping: ip/ping: nametoip: address 2402:6b00:22cd:bf80::7 does not match proto 
4
; ip/ping -an1 missing
ip/ping: cannot write tcp!missing!1 to/net/cs: cs: can't translate address: 
dns: resource does not exist; negrcode


; diffy -c ping.c
/n/dump/2016/0101/sys/src/cmd/ip/ping.c:391,505 - ping.c:391,461
return colon;
  }
  
- /* from /sys/src/libc/9sys/dial.c */
- 
- enum
+ char*
+ nametoip(char *cs, char *name, int *ipver)
  {
-   Maxstring   = 128,
-   Maxpath = 256,
- };
+   int n,fd;
+   char buf[128], ip6[128], ip4[128], *p, *addr, *ip;
  
- typedef struct DS DS;
- struct DS {
-   /* dist string */
-   charbuf[Maxstring];
-   char*netdir;
-   char*proto;
-   char*rem;
- 
-   /* other args */
-   char*local;
-   char*dir;
-   int *cfdp;
- };
- 
- /*
-  *  parse a dial string
-  */
- static void
- _dial_string_parse(char *str, DS *ds)
- {
-   char *p, *p2;
- 
-   strncpy(ds->buf, str, Maxstring);
-   ds->buf[Maxstring-1] = 0;
- 
-   p = strchr(ds->buf, '!');
-   if(p == 0) {
-   ds->netdir = 0;
-   ds->proto = "net";
-   ds->rem = ds->buf;
-   } else {
-   if(*ds->buf != '/' && *ds->buf != '#'){
-   ds->netdir = 0;
-   ds->proto = ds->buf;
-   } else {
-   for(p2 = p; *p2 != '/'; p2--)
-   ;
-   *p2++ = 0;
-   ds->netdir = ds->buf;
-   ds->proto = p2;
-   }
-   *p = 0;
-   ds->rem = p + 1;
+   ip6[0] = 0;
+   ip4[0] = 0;
+   if(isdottedquad(name)){
+   snprint(ip4, sizeof ip4, "%s", name);
+   goto match;
}
- }
+   if(isv6lit(name)){
+   snprint(ip6, sizeof ip6, "%s", name);
+   goto match;
+   }
  
- /* end excerpt from /sys/src/libc/9sys/dial.c */
- 
- /* side effect: sets network & target */
- static int
- isv4name(char *name)
- {
-   int r = 1;
-   char *root, *ip, *pr;
-   DS ds;
- 
-   _dial_string_parse(name, );
- 
-   /* cope with leading /net.alt/icmp! and the like */
-   root = nil;
-   if (ds.netdir != nil) {
-   pr = strrchr(ds.netdir, '/');
-   if (pr == nil)
-   pr = ds.netdir;
-   else {
-   *pr++ = '\0';
-   root = ds.netdir;
-   network = strdup(root);
+   if(cs == nil)
+   cs = "/net/cs";
+   fd = open(cs, ORDWR);
+   if(fd < 0)
+   sysfatal("cannot open %s: %r", cs);
+   addr = smprint("tcp!%s!1", name);
+   if(write(fd, addr, strlen(addr)) != strlen(addr)){
+   close(fd);
+   sysfatal("cannot write %s to%s: %r", addr, cs);
+   }
+   free(addr);
+   seek(fd, 0, 0);
+   while((n = read(fd, buf, sizeof(buf)-1)) > 0){
+   buf[n] = 0;
+   ip = strchr(buf,' ');
+   ip++;
+   p = strchr(ip,'!');
+   *p = 0;
+   if(isdottedquad(ip)){
+   if(ip4[0] == 0)
+   snprint(ip4, sizeof ip4, "%s", ip);
+   

Re: [9fans] bug or feature ? --- ip/ping -6

[Dave Eckhardt]

> I would display the IP address once only, rather on every line; as it
> is a common factor.

It's common only until it isn't.  If an intermediate router doesn't
like your packet it might choose to respond, in which case your
intended target doesn't get to.  At least that's why the Unix version
of ping reports the identity of the machine who issued the ICMP response.

Dave Eckhardt

Re: [9fans] bug or feature ? --- ip/ping -6

[Steve Simon]

I would display the IP address once only, rather on every line; as it is a 
common factor.

-Steve


> On 30 Dec 2015, at 15:26, Kurt H Maier  wrote:
> 
>> On Wed, Dec 30, 2015 at 03:05:33PM +, Steve Simon wrote:
>> If I where redesigning ping I wouldn't repeat any info that is common on 
>> each line - I.e. ip addresses or the column titles: rtt, ave etc.
>> 
>> consider plan9's ps(1) which has no column titles. they are described in the 
>> man page and are obvious from the context once you have read the man page 
>> once.
>> 
>> Having said this, I understand that tradition is also a strong guiding 
>> principal.
>> 
>> -Steve
> 
> I have no opinion on the labeling, but dropping the IPs from the output
> would make this tool useless for logging data.
> 
> khm

Re: [9fans] bug or feature ? --- ip/ping -6

[Bakul Shah]

On Wed, 30 Dec 2015 23:36:22 GMT "Steve Simon"  wrote:
> > It is not a common factor if you ping broadcast.
> 
> Yep, fair point.

If you're pinging plan9 machines, printing source address is
not useful as they sebd ping replies with source = broadcast
ip address.  You have to look at the source ether addr to find
out which machine responded.

> I admit I have never done a ping broadcast.
> 
> I did hear a story of somone who (in the early days of ethernet)
> built a ping broadcast packet, with the source address of the broadcast addre
> ss.
>
> This resulted in the mother of all packet storms.
> 
> Maybe apocryphal, but a nice story none the less.

Seems apocryphal or must've been very early days!  Ping
consists of sending an ICMP request packet, followed by the
responder(s) sending back ICMP reply packat(s).  No ICMP
errors are sent in response to any ICMP message to avoid just
such a storm.

Ages ago you could send a *directed* broadcast to a place far
away, which would get routed to the right subnet and many or
all machines on that subnet would respond.  Back then the 'Net
was a friendlier place and people didn't use NAT and script
kiddies were rather rare. All that changed a couple decades
ago.

Re: [9fans] bug or feature ? --- ip/ping -6

[Steve Simon]

> It is not a common factor if you ping broadcast.

Yep, fair point.

I admit I have never done a ping broadcast.

I did hear a story of somone who (in the early days of ethernet)
built a ping broadcast packet, with the source address of the broadcast address.

This resulted in the mother of all packet storms.

Maybe apocryphal, but a nice story none the less.

-Steve

Re: [9fans] bug or feature ? --- ip/ping -6

[Kenny Lasse Hoff Levinsen]

It is not a common factor if you ping broadcast. That is, the local address is 
common, the remote is not.

joushou

> On 30 Dec 2015, at 20:05, Steve Simon  wrote:
> 
> I would display the IP address once only, rather on every line; as it is a 
> common factor.
> 
> -Steve
> 
> 
>> On 30 Dec 2015, at 15:26, Kurt H Maier  wrote:
>> 
>>> On Wed, Dec 30, 2015 at 03:05:33PM +, Steve Simon wrote:
>>> If I where redesigning ping I wouldn't repeat any info that is common on 
>>> each line - I.e. ip addresses or the column titles: rtt, ave etc.
>>> 
>>> consider plan9's ps(1) which has no column titles. they are described in 
>>> the man page and are obvious from the context once you have read the man 
>>> page once.
>>> 
>>> Having said this, I understand that tradition is also a strong guiding 
>>> principal.
>>> 
>>> -Steve
>> 
>> I have no opinion on the labeling, but dropping the IPs from the output
>> would make this tool useless for logging data.
>> 
>> khm
> 

Re: [9fans] bug or feature ? --- ip/ping -6

[arisawa]

hello,

I did nothing about original ping options, so they should work as they have 
been.
I am afraid I have removed too much.
the new ping is here. test, please.



ping.c
Description: Binary data




> 2015/12/31 7:43、Kenny Lasse Hoff Levinsen  のメール：
> 
> It is not a common factor if you ping broadcast. That is, the local address 
> is common, the remote is not.
> 
> joushou
> 
>> On 30 Dec 2015, at 20:05, Steve Simon  wrote:
>> 
>> I would display the IP address once only, rather on every line; as it is a 
>> common factor.
>> 
>> -Steve
>> 
>> 
>>> On 30 Dec 2015, at 15:26, Kurt H Maier  wrote:
>>> 
 On Wed, Dec 30, 2015 at 03:05:33PM +, Steve Simon wrote:
 If I where redesigning ping I wouldn't repeat any info that is common on 
 each line - I.e. ip addresses or the column titles: rtt, ave etc.
 
 consider plan9's ps(1) which has no column titles. they are described in 
 the man page and are obvious from the context once you have read the man 
 page once.
 
 Having said this, I understand that tradition is also a strong guiding 
 principal.
 
 -Steve
>>> 
>>> I have no opinion on the labeling, but dropping the IPs from the output
>>> would make this tool useless for logging data.
>>> 
>>> khm
>> 
> 
> 

[9fans] bug or feature ? --- ip/ping -6

[arisawa]

hello,

is the following output of ping reasonable enough?


io% 6.ping -an3 hebe
sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1
192.168.0.5 -> 192.168.0.6
0: 192.168.0.6 -> 192.168.0.5 rtt 88 µs, avg rtt 88 µs, ttl = 255
1: 192.168.0.6 -> 192.168.0.5 rtt 83 µs, avg rtt 85 µs, ttl = 255
2: 192.168.0.6 -> 192.168.0.5 rtt 80 µs, avg rtt 83 µs, ttl = 255

io% 6.ping -an3 192.168.0.6
sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1
192.168.0.5 -> 192.168.0.6
0: 192.168.0.6 -> 192.168.0.5 rtt 107 µs, avg rtt 107 µs, ttl = 255
1: 192.168.0.6 -> 192.168.0.5 rtt 84 µs, avg rtt 95 µs, ttl = 255
2: 192.168.0.6 -> 192.168.0.5 rtt 95 µs, avg rtt 95 µs, ttl = 255

io% 6.ping -an3 2402:6b00:22cd:bf80::6
sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1
2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6
0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 103 µs, avg rtt 103 µs, 
ttl = 255
1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 96 µs, avg rtt 99 µs, 
ttl = 255
2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 83 µs, avg rtt 94 µs, 
ttl = 255

io% 6.ping -6an3 hebe
sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1
2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6
0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 101 µs, avg rtt 101 µs, 
ttl = 255
1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 82 µs, avg rtt 91 µs, 
ttl = 255
2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 89 µs, avg rtt 90 µs, 
ttl = 255

io% 6.ping -6an3 192.168.0.6
sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1
192.168.0.5 -> 192.168.0.6
0: 192.168.0.6 -> 192.168.0.5 rtt 90 µs, avg rtt 90 µs, ttl = 255
1: 192.168.0.6 -> 192.168.0.5 rtt 94 µs, avg rtt 92 µs, ttl = 255
2: 192.168.0.6 -> 192.168.0.5 rtt 90 µs, avg rtt 91 µs, ttl = 255

io% 6.ping -6an3 2402:6b00:22cd:bf80::6
sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1
2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6
0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 101 µs, avg rtt 101 µs, 
ttl = 255
1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 272 µs, avg rtt 186 µs, 
ttl = 255
2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 102 µs, avg rtt 158 µs, 
ttl = 255

code is simplified.

io% ls -l
--rw-rw-r-- M 327 arisawa arisawa  9942 Dec 30 21:27 ping.c
--rw-rw-r-- M 327 arisawa arisawa 10943 Dec 28 15:59 ping.c.orig
io% 

Kenji Arisawa



> 2015/12/28 18:04、arisawa  のメール：
> 
> hello 9fans,
> 
> I have once posted the message below to 9front mailing list.
> however looking the origin of the problem, now I think better place is 9fans.
> 
> == message posted to 9front mailing list ==
> 
> I am feeling weird that ip/ping -6 does not ping to ipv6 address with 
> /lib/ndb/local.
> 
> # sys=io
> # ip=192.168.0.5
> # ip=2402:6b00:22cd:bf80::5
> #
> hebe% ip/ping -6a io
> sending 32 64 byte messages 1000 ms apart to icmpv6!io!1
>   2402:6b00:22cd:bf80::6 -> 192.168.0.5
> 0: 192.168.0.5 -> 192.168.0.6 rtt 104 µs, avg rtt 104 µs, ttl = 255
> 1: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 94 µs, ttl = 255
> 2: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 91 µs, ttl = 255
> 3: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 89 µs, ttl = 255
> 
> this weirdness comes from the order of ip attributes.
> 
> # sys=io
> # ip=2402:6b00:22cd:bf80::5
> # ip=192.168.0.5
> #
> hebe% ip/ping -6a io
> sending 32 64 byte messages 1000 ms apart to icmpv6!io!1
>   2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5
> 0: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 102 µs, avg rtt 102 
> µs, ttl = 255
> 1: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 88 µs, avg rtt 95 µs, 
> ttl = 255
> 2: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 84 µs, avg rtt 91 µs, 
> ttl = 255
> 3: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 104 µs, avg rtt 94 
> µs, ttl = 255
> 
> is this a feature or a bug?
> 
> Kenji Arisawa

Re: [9fans] bug or feature ? --- ip/ping -6

[Charles Forsyth]

On 30 December 2015 at 12:48, arisawa  wrote:

> code is simplified.


It works better, but it's smaller? With luck, you might start a trend!

Re: [9fans] bug or feature ? --- ip/ping -6

[Steve Simon]

If I where redesigning ping I wouldn't repeat any info that is common on each 
line - I.e. ip addresses or the column titles: rtt, ave etc.

consider plan9's ps(1) which has no column titles. they are described in the 
man page and are obvious from the context once you have read the man page once.

Having said this, I understand that tradition is also a strong guiding 
principal.

-Steve

> On 30 Dec 2015, at 12:48, arisawa  wrote:
> 
> hello,
> 
> is the following output of ping reasonable enough?
> 
> 
> io% 6.ping -an3 hebe
> sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1
>192.168.0.5 -> 192.168.0.6
> 0: 192.168.0.6 -> 192.168.0.5 rtt 88 µs, avg rtt 88 µs, ttl = 255
> 1: 192.168.0.6 -> 192.168.0.5 rtt 83 µs, avg rtt 85 µs, ttl = 255
> 2: 192.168.0.6 -> 192.168.0.5 rtt 80 µs, avg rtt 83 µs, ttl = 255
> 
> io% 6.ping -an3 192.168.0.6
> sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1
>192.168.0.5 -> 192.168.0.6
> 0: 192.168.0.6 -> 192.168.0.5 rtt 107 µs, avg rtt 107 µs, ttl = 255
> 1: 192.168.0.6 -> 192.168.0.5 rtt 84 µs, avg rtt 95 µs, ttl = 255
> 2: 192.168.0.6 -> 192.168.0.5 rtt 95 µs, avg rtt 95 µs, ttl = 255
> 
> io% 6.ping -an3 2402:6b00:22cd:bf80::6
> sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1
>2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6
> 0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 103 µs, avg rtt 103 
> µs, ttl = 255
> 1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 96 µs, avg rtt 99 µs, 
> ttl = 255
> 2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 83 µs, avg rtt 94 µs, 
> ttl = 255
> 
> io% 6.ping -6an3 hebe
> sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1
>2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6
> 0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 101 µs, avg rtt 101 
> µs, ttl = 255
> 1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 82 µs, avg rtt 91 µs, 
> ttl = 255
> 2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 89 µs, avg rtt 90 µs, 
> ttl = 255
> 
> io% 6.ping -6an3 192.168.0.6
> sending 3 64 byte messages 1000 ms apart to icmp!192.168.0.6!1
>192.168.0.5 -> 192.168.0.6
> 0: 192.168.0.6 -> 192.168.0.5 rtt 90 µs, avg rtt 90 µs, ttl = 255
> 1: 192.168.0.6 -> 192.168.0.5 rtt 94 µs, avg rtt 92 µs, ttl = 255
> 2: 192.168.0.6 -> 192.168.0.5 rtt 90 µs, avg rtt 91 µs, ttl = 255
> 
> io% 6.ping -6an3 2402:6b00:22cd:bf80::6
> sending 3 64 byte messages 1000 ms apart to icmpv6!2402:6b00:22cd:bf80::6!1
>2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6
> 0: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 101 µs, avg rtt 101 
> µs, ttl = 255
> 1: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 272 µs, avg rtt 186 
> µs, ttl = 255
> 2: 2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5 rtt 102 µs, avg rtt 158 
> µs, ttl = 255
> 
> code is simplified.
> 
> io% ls -l
> --rw-rw-r-- M 327 arisawa arisawa  9942 Dec 30 21:27 ping.c
> --rw-rw-r-- M 327 arisawa arisawa 10943 Dec 28 15:59 ping.c.orig
> io% 
> 
> Kenji Arisawa
> 
> 
> 
>> 2015/12/28 18:04、arisawa  のメール：
>> 
>> hello 9fans,
>> 
>> I have once posted the message below to 9front mailing list.
>> however looking the origin of the problem, now I think better place is 9fans.
>> 
>> == message posted to 9front mailing list ==
>> 
>> I am feeling weird that ip/ping -6 does not ping to ipv6 address with 
>> /lib/ndb/local.
>> 
>> #sys=io
>> #ip=192.168.0.5
>> #ip=2402:6b00:22cd:bf80::5
>> #
>> hebe% ip/ping -6a io
>> sending 32 64 byte messages 1000 ms apart to icmpv6!io!1
>>2402:6b00:22cd:bf80::6 -> 192.168.0.5
>> 0: 192.168.0.5 -> 192.168.0.6 rtt 104 µs, avg rtt 104 µs, ttl = 255
>> 1: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 94 µs, ttl = 255
>> 2: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 91 µs, ttl = 255
>> 3: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 89 µs, ttl = 255
>> 
>> this weirdness comes from the order of ip attributes.
>> 
>> #sys=io
>> #ip=2402:6b00:22cd:bf80::5
>> #ip=192.168.0.5
>> #
>> hebe% ip/ping -6a io
>> sending 32 64 byte messages 1000 ms apart to icmpv6!io!1
>>2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5
>> 0: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 102 µs, avg rtt 102 
>> µs, ttl = 255
>> 1: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 88 µs, avg rtt 95 
>> µs, ttl = 255
>> 2: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 84 µs, avg rtt 91 
>> µs, ttl = 255
>> 3: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 104 µs, avg rtt 94 
>> µs, ttl = 255
>> 
>> is this a feature or a bug?
>> 
>> Kenji Arisawa
> 

Re: [9fans] bug or feature ? --- ip/ping -6

[Kurt H Maier]

On Wed, Dec 30, 2015 at 03:05:33PM +, Steve Simon wrote:
> If I where redesigning ping I wouldn't repeat any info that is common on each 
> line - I.e. ip addresses or the column titles: rtt, ave etc.
> 
> consider plan9's ps(1) which has no column titles. they are described in the 
> man page and are obvious from the context once you have read the man page 
> once.
> 
> Having said this, I understand that tradition is also a strong guiding 
> principal.
> 
> -Steve

I have no opinion on the labeling, but dropping the IPs from the output
would make this tool useless for logging data.

khm

[9fans] bug or feature ? --- ip/ping -6

[arisawa]

hello 9fans,

I have once posted the message below to 9front mailing list.
however looking the origin of the problem, now I think better place is 9fans.

== message posted to 9front mailing list ==

I am feeling weird that ip/ping -6 does not ping to ipv6 address with 
/lib/ndb/local.

#   sys=io
#   ip=192.168.0.5
#   ip=2402:6b00:22cd:bf80::5
#
hebe% ip/ping -6a io
sending 32 64 byte messages 1000 ms apart to icmpv6!io!1
2402:6b00:22cd:bf80::6 -> 192.168.0.5
0: 192.168.0.5 -> 192.168.0.6 rtt 104 µs, avg rtt 104 µs, ttl = 255
1: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 94 µs, ttl = 255
2: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 91 µs, ttl = 255
3: 192.168.0.5 -> 192.168.0.6 rtt 85 µs, avg rtt 89 µs, ttl = 255

this weirdness comes from the order of ip attributes.

#   sys=io
#   ip=2402:6b00:22cd:bf80::5
#   ip=192.168.0.5
#
hebe% ip/ping -6a io
sending 32 64 byte messages 1000 ms apart to icmpv6!io!1
2402:6b00:22cd:bf80::6 -> 2402:6b00:22cd:bf80::5
0: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 102 µs, avg rtt 102 µs, 
ttl = 255
1: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 88 µs, avg rtt 95 µs, 
ttl = 255
2: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 84 µs, avg rtt 91 µs, 
ttl = 255
3: 2402:6b00:22cd:bf80::5 -> 2402:6b00:22cd:bf80::6 rtt 104 µs, avg rtt 94 µs, 
ttl = 255

is this a feature or a bug?

Kenji Arisawa

Re: [9fans] bug or feature ? --- ip/ping -6

[Anthony Martin]

arisawa  once said:
> is this a feature or a bug?

It looks like a bug to me. The code in

  /sys/src/cmd/ip/ping.c:/^isv4name

is too clever for it's own good.

  Anthony