Re: [atlas] IPv4 leading zeroes and weird interface behaviour

2017-10-25 Thread Hugo Salgado-Hernández 
It was warned before on this IETF draft, but it was never published:
  

Hugo

On 13:54 25/10, Phillip Remaker wrote:
> Historically, C uses a 0 to precede an octal number, 0x to precede a
> decimal, and 0b for binary. Leading zeroes are otherwise stripped in
> numerical representation.
> 
> Since 0x is not accepted, I'd call it a bug and request that the numbers
> always get treated as decimal, regardless of leading zeros.
> 
> There's probably some downstream library making the anachronistic
> assumption.
> 
> On Wed, Oct 25, 2017 at 1:45 PM, Max Grobecker <
> max.grobec...@ml.grobecker.info> wrote:
> 
> > Hello,
> >
> > is there - by standard - a definition on how to represent an IPv4 address?
> >
> > I have (for example) the IP address "73.0.255.229", which can IMHO also be
> > written as "073.000.255.229" as the leading zeroes
> > are not giving any changes to the binary representation of this address.
> > Am I right on this?
> >
> > But: When I lookup this IP address on https://stat.ripe.net/073.000.
> > 255.229 the first octet is internally getting swapped to "59".
> > This can be explained, if you take "073" as an octal value and convert it
> > to a decimal value.
> > It is definitely a octal-to-decimal conversion thing, as for example also
> > the value "010" is getting replaced by "8" and so on.
> >
> > Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not
> > very common.
> > But: Is it officially prohibited or discouraged?
> >
> > This weird conversion also happens inside the "geoiplookup" tool by
> > MaxMind and I'm not sure if I'm going to be the moron in this story
> > or if I found the same bug inside multiple softwares at once ;-)
> >
> >
> > Thanks and greetings from Wuppertal
> >  Max
> >
> >


signature.asc
Description: Digital signature

Re: [atlas] IPv4 leading zeroes and weird interface behaviour

2017-10-25 Thread Roman Mamedov 
On Wed, 25 Oct 2017 22:45:42 +0200
Max Grobecker  wrote:

> But: When I lookup this IP address on https://stat.ripe.net/073.000.255.229 
> the first octet is internally getting swapped to "59".
> This can be explained, if you take "073" as an octal value and convert it to 
> a decimal value.
> It is definitely a octal-to-decimal conversion thing, as for example also the 
> value "010" is getting replaced by "8" and so on.
> 
> Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not 
> very common.
> But: Is it officially prohibited or discouraged?
> 
> This weird conversion also happens inside the "geoiplookup" tool by MaxMind 
> and I'm not sure if I'm going to be the moron in this story
> or if I found the same bug inside multiple softwares at once ;-)

There are many ways to write an IP address, and yes, leading zeroes mean the
octal form. Even basic utilities like "ping" use this conversion:

$ ping 010.020.030.040
PING 010.020.030.040 (8.16.24.32) 56(84) bytes of data.
^C
--- 010.020.030.040 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms


Another way is to give a full 32-bit number as integer:

$ ping 728374928
PING 728374928 (43.106.30.144) 56(84) bytes of data.
^C
--- 728374928 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1015ms


Or you can skip zeroes (almost like in IPv6):

$ ping 10.9
PING 10.9 (10.0.0.9) 56(84) bytes of data.
^C
--- 10.9 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1015ms


So what you found is not a bug, but a common behavior. I'm sure all of this is
described in great detail in some 40 year old RFC.

-- 
With respect,
Roman

Re: [atlas] IPv4 leading zeroes and weird interface behaviour

2017-10-25 Thread Nick Hilliard 
Max Grobecker wrote:
> Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not 
> very common.
> But: Is it officially prohibited or discouraged?

It was never defined in the rfcs, but by rfc convention, leading zeros
should probably be interpreted as decimal (e.g. rfc790).

The problem is, inet_aton() interprets leading zeros as octal, and on
any operating system which uses the bsd socket library, the address may
get converted into octal, or may not, depending on whether the program
is using inet_aton(), which assumes octal if there are leading zeros, or
getaddrinfo(), which will interpret as decimal in all cases, because
POSIX was a bit more careful about the definition.

In other words, you have no idea a priori what someone else's code will
do, so unless you're ok about your output being interpreted as random
garbage, you should avoid zero-padding at all costs.

Nick

Re: [atlas] IPv4 leading zeroes and weird interface behaviour

2017-10-25 Thread Phillip Remaker 
Historically, C uses a 0 to precede an octal number, 0x to precede a
decimal, and 0b for binary. Leading zeroes are otherwise stripped in
numerical representation.

Since 0x is not accepted, I'd call it a bug and request that the numbers
always get treated as decimal, regardless of leading zeros.

There's probably some downstream library making the anachronistic
assumption.

On Wed, Oct 25, 2017 at 1:45 PM, Max Grobecker <
max.grobec...@ml.grobecker.info> wrote:

> Hello,
>
> is there - by standard - a definition on how to represent an IPv4 address?
>
> I have (for example) the IP address "73.0.255.229", which can IMHO also be
> written as "073.000.255.229" as the leading zeroes
> are not giving any changes to the binary representation of this address.
> Am I right on this?
>
> But: When I lookup this IP address on https://stat.ripe.net/073.000.
> 255.229 the first octet is internally getting swapped to "59".
> This can be explained, if you take "073" as an octal value and convert it
> to a decimal value.
> It is definitely a octal-to-decimal conversion thing, as for example also
> the value "010" is getting replaced by "8" and so on.
>
> Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not
> very common.
> But: Is it officially prohibited or discouraged?
>
> This weird conversion also happens inside the "geoiplookup" tool by
> MaxMind and I'm not sure if I'm going to be the moron in this story
> or if I found the same bug inside multiple softwares at once ;-)
>
>
> Thanks and greetings from Wuppertal
>  Max
>
>

[atlas] IPv4 leading zeroes and weird interface behaviour

2017-10-25 Thread Max Grobecker 
Hello,

is there - by standard - a definition on how to represent an IPv4 address?

I have (for example) the IP address "73.0.255.229", which can IMHO also be 
written as "073.000.255.229" as the leading zeroes
are not giving any changes to the binary representation of this address. Am I 
right on this?

But: When I lookup this IP address on https://stat.ripe.net/073.000.255.229 the 
first octet is internally getting swapped to "59".
This can be explained, if you take "073" as an octal value and convert it to a 
decimal value.
It is definitely a octal-to-decimal conversion thing, as for example also the 
value "010" is getting replaced by "8" and so on.

Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not very 
common.
But: Is it officially prohibited or discouraged?

This weird conversion also happens inside the "geoiplookup" tool by MaxMind and 
I'm not sure if I'm going to be the moron in this story
or if I found the same bug inside multiple softwares at once ;-)


Thanks and greetings from Wuppertal
 Max



signature.asc
Description: OpenPGP digital signature

Re: [atlas] Why did I get "Over the limit on number of results"?

2017-10-25 Thread Wouter de Vries 
Hi Eduardo,

There are also limits on the number of results that you generate per
day, called the "Daily measurement result flow". This could be what you
are describing. 

The limits are shown at https://atlas.ripe.net/atlas/user/

Best,

Wouter

On Wed, Oct 25, 2017 at 01:03:15PM +0100, Eduardo Duarte wrote:
> Hello,
> 
> I schedule some measurements to run during today but I got an error on
> some of them. The error is "Over the limit on number of results".
> I have enough credits to run all the measures so I don't understand this
> message.
> 
> Thank you and best regards,
> -- 
> Eduardo Duarte
> Gestão e Desenvolvimento de Projetos l Project Development Management
>  
> *DNS.PT*
> Rua Latino Coelho, n.º 13, 5.º piso | 1050-132 Lisboa | Portugal
> Tel: (+351) 211 308 200  Fax: (+351) 211 312 720
> dns.pt  | dnssec.pt  | 3em1.pt
>  | facebook.com/dns.pt
>  | pt.linkedin.com/in/dnspt
> 
> 
>  
> Aviso de Confidencialidade/Disclaimer:
> Este e-mail foi escrito de acordo com o novo acordo ortográfico.
> Esta mensagem é exclusivamente destinada ao seu destinatário, podendo
> conter informação CONFIDENCIAL, cuja divulgação está expressamente
> vedada nos termos da lei. Caso tenha recepcionado indevidamente esta
> mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta
> via devendo apagar o seu conteúdo de imediato. This message is intended
> exclusively for its addressee. It may contain CONFIDENTIAL information
> protected by law. If this message has been received by error, please
> notify us via e-mail and delete it immediately.
> [ Antes de imprimir esta mensagem pense no ambiente. Before printing
> this message, think about environment ]

[atlas] Why did I get "Over the limit on number of results"?

2017-10-25 Thread Eduardo Duarte 
Hello,

I schedule some measurements to run during today but I got an error on
some of them. The error is "Over the limit on number of results".
I have enough credits to run all the measures so I don't understand this
message.

Thank you and best regards,
-- 
Eduardo Duarte
Gestão e Desenvolvimento de Projetos l Project Development Management
 
*DNS.PT*
Rua Latino Coelho, n.º 13, 5.º piso | 1050-132 Lisboa | Portugal
Tel: (+351) 211 308 200  Fax: (+351) 211 312 720
dns.pt  | dnssec.pt  | 3em1.pt
 | facebook.com/dns.pt
 | pt.linkedin.com/in/dnspt


 
Aviso de Confidencialidade/Disclaimer:
Este e-mail foi escrito de acordo com o novo acordo ortográfico.
Esta mensagem é exclusivamente destinada ao seu destinatário, podendo
conter informação CONFIDENCIAL, cuja divulgação está expressamente
vedada nos termos da lei. Caso tenha recepcionado indevidamente esta
mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta
via devendo apagar o seu conteúdo de imediato. This message is intended
exclusively for its addressee. It may contain CONFIDENTIAL information
protected by law. If this message has been received by error, please
notify us via e-mail and delete it immediately.
[ Antes de imprimir esta mensagem pense no ambiente. Before printing
this message, think about environment ]


smime.p7s
Description: S/MIME Cryptographic Signature