Re: [Toybox] [PATCH] ping: fix -q behavior.
On 07/11/2018 12:13 PM, enh wrote: > (To be clear: I'm not feeding you the answer in pieces... I only know pieces > of > the answer. If I knew what the code should look like, I'd send a patch 😁) Indeed. Trying to research it here myself, but can't during $DAYJOB time. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] ping: fix -q behavior.
(To be clear: I'm not feeding you the answer in pieces... I only know
pieces of the answer. If I knew what the code should look like, I'd send a
patch 😁)
On Tue, Jul 10, 2018, 15:56 enh wrote:
> > why/how does ping ::1 work
>
> link-local addresses
> (https://tools.ietf.org/html/rfc4291?referring_site=bodynav#section-2.5.6)
> are unrelated to the loopback address
> (https://tools.ietf.org/html/rfc4291?referring_site=bodynav#section-2.5.3
> ).
>
> ping6 with just -I should not work, but ping6 with just % should.
> (both together is fine too.) sin6_scope_id needs to be set to
> correspond to the interface.
>
> IPv6 is a sizeable bag of worms.
> On Mon, Jul 9, 2018 at 4:42 PM Rob Landley wrote:
> >
> >
> >
> > On 07/09/2018 04:49 PM, enh wrote:
> > > On Fri, Jul 6, 2018 at 6:16 PM Rob Landley wrote:
> > >>
> > >> On 07/06/2018 03:19 PM, enh wrote:
> > >>> they said they'd be much more worried about whether we use IP_RECVERR
> > >>> and parse ICMP errors correctly,
> > >>
> > >> I don't think we do but I'll throw it on the todo heap. I'm not 100%
> sure what
> > >> "correctly" means here, but I can try to research it.
> > >>
> > >>> or do link-local ping correctly...
> > >>
> > >> Again, define "correctly"...?
> > >>
> > >> (I can ping ::1 and ping 127.0.0.1 but I dunno if it's doing
> something wrong?)
> > >
> > > https://en.wikipedia.org/wiki/Link-local_address#IPv6
> >
> > This can of worms?
> >
> > https://twitter.com/RichFelker/status/982286128593043456
> >
> > (I've always considered ipv6 a poster child for the second system
> effect.)
> >
> > > try `ifconfig -a | grep link`
> >
> > No output. (Using ubuntu's ifconfig or toybox's.) Ah: case insensitive
> grep.
> >
> > > and then compare `ping6 $that_address`
> > > (which should fail) against `ping6 -I $that_interface $that_address`
> >
> > Sigh. I had -I working at one point... wait,
> >
> > printf("ntop=%s\n", ntop(sa));
> > if (TT.I && bind(TT.sock, sa, sizeof(src_addr))) perror_exit("bind");
> >
> > $ ./ping -I wlan0 fe80::6627:37ff:fe21:64bf
> > ntop=fe80::6627:37ff:fe21:64bf
> > Ping fe80::6627:37ff:fe21:64bf (fe80::6627:37ff:fe21:64bf) from wlan0
> > (fe80::6627:37ff:fe21:64bf): 56(84) bytes.
> > ping: sendto: Invalid argument
> >
> > What am I doing wrong? I'm binding to the same IP address I'm trying to
> ping,
> > how is sendto() giving me an invalid argument error? strace says:
> >
> > socket(PF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6) = 3
> > bind(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
> > "fe80::6627:37ff:fe21:64bf", &sin6_addr), sin6_flowinfo=0,
> > sin6_scope_id=if_nametoindex("wlan0")}, 28) = 0
> > sendto(3,
> >
> "\200\0002(\236+\1\\311\3412\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> > 64, 0, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
> > "fe80::6627:37ff:fe21:64bf", &sin6_addr), sin6_flowinfo=0,
> sin6_scope_id=0}, 28)
> > = -1 EINVAL (Invalid argument)
> >
> > Opened with v6, bound with v6... Sigh, do I have the destination packet
> > misformatted for v6? If so, why/how does ping ::1 work?
> >
> > Hmmm... And this is why I have systems built for qemu, so I can STICK
> PRINTKs
> > INTO THE KERNEL. Grrr...
> >
> > > and `ping6 $that_address%$that_interface`.
> >
> > I'm guessing percent is a synonym for -I so this is basically the same
> issue,
> > modulo implementing %?
> >
> > Rob
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] ping: fix -q behavior.
> why/how does ping ::1 work
link-local addresses
(https://tools.ietf.org/html/rfc4291?referring_site=bodynav#section-2.5.6)
are unrelated to the loopback address
(https://tools.ietf.org/html/rfc4291?referring_site=bodynav#section-2.5.3).
ping6 with just -I should not work, but ping6 with just % should.
(both together is fine too.) sin6_scope_id needs to be set to
correspond to the interface.
IPv6 is a sizeable bag of worms.
On Mon, Jul 9, 2018 at 4:42 PM Rob Landley wrote:
>
>
>
> On 07/09/2018 04:49 PM, enh wrote:
> > On Fri, Jul 6, 2018 at 6:16 PM Rob Landley wrote:
> >>
> >> On 07/06/2018 03:19 PM, enh wrote:
> >>> they said they'd be much more worried about whether we use IP_RECVERR
> >>> and parse ICMP errors correctly,
> >>
> >> I don't think we do but I'll throw it on the todo heap. I'm not 100% sure
> >> what
> >> "correctly" means here, but I can try to research it.
> >>
> >>> or do link-local ping correctly...
> >>
> >> Again, define "correctly"...?
> >>
> >> (I can ping ::1 and ping 127.0.0.1 but I dunno if it's doing something
> >> wrong?)
> >
> > https://en.wikipedia.org/wiki/Link-local_address#IPv6
>
> This can of worms?
>
> https://twitter.com/RichFelker/status/982286128593043456
>
> (I've always considered ipv6 a poster child for the second system effect.)
>
> > try `ifconfig -a | grep link`
>
> No output. (Using ubuntu's ifconfig or toybox's.) Ah: case insensitive grep.
>
> > and then compare `ping6 $that_address`
> > (which should fail) against `ping6 -I $that_interface $that_address`
>
> Sigh. I had -I working at one point... wait,
>
> printf("ntop=%s\n", ntop(sa));
> if (TT.I && bind(TT.sock, sa, sizeof(src_addr))) perror_exit("bind");
>
> $ ./ping -I wlan0 fe80::6627:37ff:fe21:64bf
> ntop=fe80::6627:37ff:fe21:64bf
> Ping fe80::6627:37ff:fe21:64bf (fe80::6627:37ff:fe21:64bf) from wlan0
> (fe80::6627:37ff:fe21:64bf): 56(84) bytes.
> ping: sendto: Invalid argument
>
> What am I doing wrong? I'm binding to the same IP address I'm trying to ping,
> how is sendto() giving me an invalid argument error? strace says:
>
> socket(PF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6) = 3
> bind(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
> "fe80::6627:37ff:fe21:64bf", &sin6_addr), sin6_flowinfo=0,
> sin6_scope_id=if_nametoindex("wlan0")}, 28) = 0
> sendto(3,
> "\200\0002(\236+\1\\311\3412\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 64, 0, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
> "fe80::6627:37ff:fe21:64bf", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> 28)
> = -1 EINVAL (Invalid argument)
>
> Opened with v6, bound with v6... Sigh, do I have the destination packet
> misformatted for v6? If so, why/how does ping ::1 work?
>
> Hmmm... And this is why I have systems built for qemu, so I can STICK PRINTKs
> INTO THE KERNEL. Grrr...
>
> > and `ping6 $that_address%$that_interface`.
>
> I'm guessing percent is a synonym for -I so this is basically the same issue,
> modulo implementing %?
>
> Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] ping: fix -q behavior.
On 07/09/2018 04:49 PM, enh wrote:
> On Fri, Jul 6, 2018 at 6:16 PM Rob Landley wrote:
>>
>> On 07/06/2018 03:19 PM, enh wrote:
>>> they said they'd be much more worried about whether we use IP_RECVERR
>>> and parse ICMP errors correctly,
>>
>> I don't think we do but I'll throw it on the todo heap. I'm not 100% sure
>> what
>> "correctly" means here, but I can try to research it.
>>
>>> or do link-local ping correctly...
>>
>> Again, define "correctly"...?
>>
>> (I can ping ::1 and ping 127.0.0.1 but I dunno if it's doing something
>> wrong?)
>
> https://en.wikipedia.org/wiki/Link-local_address#IPv6
This can of worms?
https://twitter.com/RichFelker/status/982286128593043456
(I've always considered ipv6 a poster child for the second system effect.)
> try `ifconfig -a | grep link`
No output. (Using ubuntu's ifconfig or toybox's.) Ah: case insensitive grep.
> and then compare `ping6 $that_address`
> (which should fail) against `ping6 -I $that_interface $that_address`
Sigh. I had -I working at one point... wait,
printf("ntop=%s\n", ntop(sa));
if (TT.I && bind(TT.sock, sa, sizeof(src_addr))) perror_exit("bind");
$ ./ping -I wlan0 fe80::6627:37ff:fe21:64bf
ntop=fe80::6627:37ff:fe21:64bf
Ping fe80::6627:37ff:fe21:64bf (fe80::6627:37ff:fe21:64bf) from wlan0
(fe80::6627:37ff:fe21:64bf): 56(84) bytes.
ping: sendto: Invalid argument
What am I doing wrong? I'm binding to the same IP address I'm trying to ping,
how is sendto() giving me an invalid argument error? strace says:
socket(PF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6) = 3
bind(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
"fe80::6627:37ff:fe21:64bf", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=if_nametoindex("wlan0")}, 28) = 0
sendto(3,
"\200\0002(\236+\1\\311\3412\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
64, 0, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
"fe80::6627:37ff:fe21:64bf", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28)
= -1 EINVAL (Invalid argument)
Opened with v6, bound with v6... Sigh, do I have the destination packet
misformatted for v6? If so, why/how does ping ::1 work?
Hmmm... And this is why I have systems built for qemu, so I can STICK PRINTKs
INTO THE KERNEL. Grrr...
> and `ping6 $that_address%$that_interface`.
I'm guessing percent is a synonym for -I so this is basically the same issue,
modulo implementing %?
Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] ping: fix -q behavior.
On Fri, Jul 6, 2018 at 6:16 PM Rob Landley wrote: > > On 07/06/2018 03:19 PM, enh wrote: > > they said they'd be much more worried about whether we use IP_RECVERR > > and parse ICMP errors correctly, > > I don't think we do but I'll throw it on the todo heap. I'm not 100% sure what > "correctly" means here, but I can try to research it. > > > or do link-local ping correctly... > > Again, define "correctly"...? > > (I can ping ::1 and ping 127.0.0.1 but I dunno if it's doing something wrong?) https://en.wikipedia.org/wiki/Link-local_address#IPv6 try `ifconfig -a | grep link` and then compare `ping6 $that_address` (which should fail) against `ping6 -I $that_interface $that_address` and `ping6 $that_address%$that_interface`. > Rob > > ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] ping: fix -q behavior.
On 07/06/2018 03:19 PM, enh wrote: > they said they'd be much more worried about whether we use IP_RECVERR > and parse ICMP errors correctly, I don't think we do but I'll throw it on the todo heap. I'm not 100% sure what "correctly" means here, but I can try to research it. > or do link-local ping correctly... Again, define "correctly"...? (I can ping ::1 and ping 127.0.0.1 but I dunno if it's doing something wrong?) Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] ping: fix -q behavior.
the networking folks said it probably doesn't matter. they did point out that it's a lot easier to implement the toybox behavior with the iputils ping than vice versa. they said they'd be much more worried about whether we use IP_RECVERR and parse ICMP errors correctly, or do link-local ping correctly... On Thu, Jun 14, 2018 at 6:13 PM Rob Landley wrote: > > On 06/14/2018 06:11 PM, enh wrote: > > This matches iputils and busybox. > > I couldn't figure out what their -q was for. Those are printing the header and > footer text so not "quiet", and it's continuing to ping after confirming the > site is up so it's not "quick". The one I implemented is both quick and quiet: > you don't have to > /dev/null to have no output, and if you're doing a script > ala "if ping -q site; then echo site is up; fi" this returns as soon as it > has a > result. > > If you have a user that cares (including you personally) I'm happy to change > it > back, but I'd like to confirm because this deviation was intentional. > > Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] ping: fix -q behavior.
On 06/14/2018 06:11 PM, enh wrote: > This matches iputils and busybox. I couldn't figure out what their -q was for. Those are printing the header and footer text so not "quiet", and it's continuing to ping after confirming the site is up so it's not "quick". The one I implemented is both quick and quiet: you don't have to > /dev/null to have no output, and if you're doing a script ala "if ping -q site; then echo site is up; fi" this returns as soon as it has a result. If you have a user that cares (including you personally) I'm happy to change it back, but I'd like to confirm because this deviation was intentional. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
