This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

quinta-feira, 22 de março de 2018

Protocolos - O que é QUIC - UDP 443

Google’s QUIC protocol: moving the web from TCP to UDP

Mattias Geniar, Saturday, July 30, 2016 - last modified: Sunday, December 4, 2016
The QUIC protocol (Quick UDP Internet Connections) is an entirely new protocol for the web developed on top of UDP instead of TCP.
Some are even (jokingly) calling it TCP/2.
I only learned about QUIC a few weeks ago while doing the curl & libcurl episode of the SysCast podcast.
The really interesting bit about the QUIC protocol is the move to UDP.
Now, the web is built on top of TCP for its reliability as a transmission protocol. To start a TCP connection a 3-way handshake is performed. This means additional round-trips (network packets being sent back and forth) for each starting connection which adds significant delays to any new connection.
(Source: Next generation multiplexed transport over UDP (PDF))
If on top of that you also need to negotiate TLS, to create a secure, encrypted, https connection, even more network packets have to be sent back and forth.
(Source: Next generation multiplexed transport over UDP (PDF))
Innovation like TCP Fast Open will improve the situation for TCP, but this isn't widely adopted yet.
UDP on the other hand is more of a fire and forget protocol. A message is sent over UDP and it's assumed to arrive at the destination. The benefit is less time spent on the network to validate packets, the downside is that in order to be reliable, something has to be built on top of UDP to confirm packet delivery.
That's where Google's QUIC protocol comes in.
The QUIC protocol can start a connection and negotiate all the TLS (HTTPs) parameters in 1 or 2 packets (depends on if it's a new server you are connecting to or a known host).
(Source: Next generation multiplexed transport over UDP (PDF))
This can make a huge difference for the initial connection and start of download for a page.

Why is QUIC needed?

It's absolutely mind boggling what the team developing the QUIC protocol is doing. It wants to combine the speed and possibilities of the UDP protocol with the reliability of the TCP protocol.
Wikipedia explains it fairly well.
As improving TCP is a long-term goal for Google, QUIC aims to be nearly equivalent to an independent TCP connection, but with much reduced latency and better SPDY-like stream-multiplexing support.
If QUIC features prove effective, those features could migrate into a later version of TCP and TLS (which have a notably longer deployment cycle).
There's a part of that quote that needs emphasising: if QUIC features prove effective, those features could migrate into a later version of TCP.
The TCP protocol is rather highly regulated. Its implementation is inside the Windows and Linux kernel, it's in each phone OS, ... it's pretty much in every low-level device. Improving on the way TCP works is going to be hard, as each of those TCP implementation needs to follow.
UDP on the other hand is relatively simple in design. It's faster to implement a new protocol on top of UDP to prove some of the theories Google has about TCP. That way, once they can confirm their theories about network congestion, stream blocking, ... they can begin their efforts to move the good parts of QUIC to the TCP protocol.
But altering the TCP stack requires work from the Linux kernel & Windows, intermediary middleboxes, users to update their stack, ... Doing the same thing in UDP is much more difficult for the developers making the protocol but allows them to iterate much faster and implement those theories in months instead of years or decades.

Where does QUIC fit in?

If you look at the layers which make up a modern HTTPs connection, QUIC replaces the TLS stack and parts of HTTP/2.
The QUIC protocol implements its own crypto-layer so does not make use of the existing TLS 1.2.
It replaces TCP with UDP and on top of QUIC is a smaller HTTP/2 API used to communicate with remote servers. The reason it's smaller is because the multiplexing and connection management is already handled by QUIC. What's left is an interpretation of the HTTP protocol.

TCP head-of-line blocking

With SPDY and HTTP/2 we now have a single TCP connection being used to connect to a server instead of multiple connections for each asset on a page. That one TCP connection can independently request and receive resources.
(Source: QUIC: next generation multiplexed transport over UDP)
Now that everything depends on that single TCP connection, a downside is introduced: head-of-line blocking.
In TCP, packets need to arrive be processed in the correct order. If a packet is lost on its way to/from the server, it needs to be retransmitted. The TCP connection needs to wait (or "block") on that TCP packet before it can continue to parse the other packets, because the order in which TCP packets are processed matters.
(Source: QUIC: next generation multiplexed transport over UDP)
In QUIC, this is solved by not making use of TCP anymore.
UDP is not dependent on the order in which packets are received. While it's still possible for packets to get lost during transit, they will only impact an individual resource (as in: a single CSS/JS file) and not block the entire connection.
(Source: QUIC: next generation multiplexed transport over UDP)
QUIC is essentially combining the best parts of SPDY and HTTP2 (the multiplexing) on top of a non-blocking transportation protocol.

Why fewer packets matter so much

If you're lucky enough to be on a fast internet connection, you can have latencies between you and a remote server between the 10-50ms range. Every packet you send across the network will take that amount of time to be received.
For latencies < 50ms, the benefit may not be immediately clear.
It's mostly noticeable when you are talking to a server on another continent or via a mobile carrier using Edge, 3G/4G/LTE. To reach a server from Europe in the US, you have to cross the Atlantic ocean. You immediately get a latency penalty of +100ms or higher purely because of the distance that needs to be traveled.
(Source: QUIC: next generation multiplexed transport over UDP)
Mobile networks have the same kind of latency: it's not unlikely to have a 100-150ms latency between your mobile phone and a remote server on a slow connection, merely because of the radio frequencies and intermediate networks that have to be traveled. In 4G/LTE situations, a 50ms latency is easier to get.
On mobile devices and for large-distance networks, the difference between sending/receiving 4 packets (TCP + TLS) and 1 packet (QUIC) can be up to 300ms of saved time for that initial connection.

Forward Error Correction: preventing failure

A nifty feature of QUIC is FEC or Forward Error Correction. Every packet that gets sent also includes enough data of the other packets so that a missing packet can be reconstructed without having to retransmit it.
This is essentially RAID 5 on the network level.
Because of this, there is a trade-off: each UDP packet contains more payload than is strictly necessary, because it accounts for the potential of missed packets that can more easily be recreated this way.
The current ratio seems to be around 10 packets. So for every 10 UDP packets sent, there is enough data to reconstruct a missing packet. A 10% overhead, if you will.
Consider Forward Error Correction as a sacrifice in terms of "data per UDP packet" that can be sent, but the gain is not having to retransmit a lost packet, which would take a lot longer (recipient has to confirm a missing packet, request it again and await the response).

Session resumption & parallel downloads

Another exciting opportunity with the switch to UDP is the fact that you are no longer dependent on the source IP of the connection.
In TCP, you need 4 parameters to make up a connection. The so-called quadruplets.
To start a new TCP connection, you need a source IP, source port, destination IP and destination port. On a Linux server, you can see those quadruplets using netstat.
$ netstat -anlp | grep ':443'
tcp6       0      0 2a03:a800:a1:1952::f:443 2604:a580:2:1::7:57940  TIME_WAIT   -
tcp        0      0       TIME_WAIT   -
If any of the parameters (source IP/port or destination IP/port) change, a new TCP connection needs to be made.
This is why keeping a stable connection on a mobile device is so hard, because you may be constantly switching between WiFi and 3G/LTE.
(Source: QUIC: next generation multiplexed transport over UDP)
With QUIC, since it's now using UDP, there are no quadruplets.
QUIC has implemented its own identifier for unique connections called the Connection UUID. It's possible to go from WiFi to LTE and still keep your Connection UUID, so no need to renegotiate the connection or TLS. Your previous connection is still valid.
This works the same way as the Mosh Shell, keeping SSH connections alive over UDP for a better roaming & mobile experience.
This also opens the doors to using multiple sources to fetch content. If the Connection UUID can be shared over a WiFi and cellular connection, it's in theory possible to use both media to download content. You're effectively streaming or downloading content in parallel, using every available interface you have.
While still theoretical, UDP allows for such innovation.

The QUIC protocol in action

The Chrome browser has had (experimental) support for QUIC since 2014. If you want test QUIC, you can enable the protocol in Chrome. Practically, you can only test the QUIC protocol against Google services.
The biggest benefit Google has is the combination of owning both the browser and the server marketshare. By enabling QUIC on both the client (Chrome) and the server (Google services like YouTube,, they can run large-scale tests of new protocols in production.
There's a convenient Chrome plugin that can show the HTTP/2 and QUIC protocol as an icon in your browser: HTTP/2 and SPDY indicator.
You can see how QUIC is being used by opening the chrome://net-internals/#quic tab right now (you'll also notice the Connection UUID mentioned earlier).
If you're interested in the low-level details, you can even see all the live connections and get individual per-packet captures: chrome://net-internals/#events&q=type:QUIC_SESSION%20is:active.
Similar to how you can see the internals of a SDPY or HTTP/2 connection.

Won't someone think of the firewall?

If you're a sysadmin or network engineer, you probably gave a little shrug at the beginning when I mentioned QUIC being UDP instead of TCP. You've probably got a good reason for that, too.
For instance, when we at Nucleus Hosting configure a firewall for a webserver, those firewall rules look like these.
Take special note of the protocol column: TCP.
Our firewall isn't very different from the one deployed by thousands of other sysadmins. At this time, there's no reason for a webserver to allow anything other than 80/TCP or 443/TCP. TCP only. No UDP.
Well, if we want to allow the QUIC protocol, we will need to allow 443/UDP too.
For servers, this means opening incoming 443/UDP to the webserver. For clients, it means allowing outgoing 443/UDP to the internet.
In large enterprises, I can see this be an issue. Getting it past security to allow UDP on a normally TCP-only port sounds fishy.
I would've actually thought this to be a major problem in terms of connectivity, but as Google has done the experiments -- this turns out to not be the case.
(Source: QUIC Deployment Experience @Google)
Those numbers were given at a recent HTTP workshop in Sweden. A couple of key-pointers;
  • Since QUIC is only supported on Google Services now, the server-side firewalling is probably OK.
  • These numbers are client-side only: they show how many clients are allowed to do UDP over port 443.
  • QUIC can be disabled in Chrome for compliance reasons. I bet there are a lot of enterprises that have disabled QUIC so those connections aren't even attempted.
Since QUIC is also TLS-enabled, we only need to worry about UDP on port 443. UDP on port 80 isn't very likely to happen soon.
The advantage of doing things encrypted-only is that Deep Packet Inspection middleware (aka: intrusion prevention systems) can't decrypt the TLS traffic and modify the protocol, they see binary data over the fire and will -- hopefully -- just let it go through.

Running QUIC server-side

Right now, the only webserver that can get you QUIC is Caddy since version 0.9.
Both client-side and server-side support is considered experimental, so it's up to you to run it.
Since no one has QUIC support enabled by default in the client, you're probably still safe to run it and enable QUIC in your own browser(s). (Update: since Chrome 52, everyone has QUIC enabled by default, even to non-whitelisted domains)
To help debug QUIC I hope curl will implement it soon, there certainly is interest.

Performance benefits of QUIC

In a 2015 blogpost Google has shared several results from the QUIC implementation.
As a result, QUIC outshines TCP under poor network conditions, shaving a full second off the Google Search page load time for the slowest 1% of connections.
These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC.
A QUIC update on Google’s experimental transport (2015)
The YouTube statistics are especially interesting. If these kinds of improvements are possible, we'll see a quick adoption in video streaming services like Vimeo or "adult streaming services".


I find the QUIC protocol to be truly fascinating!

The amount of work that has gone into it, the fact that it's already running for the biggest websites available and that it's working blow my mind.
I can't wait see the QUIC spec become final and implemented in other browsers and webservers!

Update: comment from Jim Roskind, designer of QUIC

Jim Roskind was kind enough to leave a comment on this blog (see below) that deserves emphasising.
Having spent years on the research, design and deployment of QUIC, I can add some insight. Your comment about UDP ports being blocked was exactly my conjecture when we were experimenting with QUIC’s (UDP) viability (before spending time on the detailed design and architecture). My conjecture was that the reason we could only get 93% reachability was because enterprise customers were commonly blocking UDP (perchance other than what was needed for DNS).
If you recall that historically, enterprise customers routinely blocked TCP port 80 "to prevent employees from wasting their time surfing," then you know that overly conservative security does happen (and usability drives changes!). As it becomes commonly known that allowing UDP:443 to egress will provide better user experience (i.e., employees can get their job done faster, and with less wasted bandwidth), then I expect that usability will once again trump security ... and the UDP:443 port will be open in most enterprise scenarios.
... also ... your headline using the words “TCP/2” may well IMO be on target. I expect that the rate of evolution of QUIC congestion avoidance will allow QUIC to track the advances (new hardware deployment? new cell tower protocols? etc.) of the internet much faster than TCP.
As a result, I expect QUIC to largely displace TCP, even as QUIC provides any/all technology suggestions for incorporation into TCP. TCP is routinely implemented in the kernel, which makes evolutionary steps take 5-15 years (including market penetration!… not to mention battles with middle-boxes), while QUIC can evolve in the course of weeks or months.
-- Jim (QUIC Architect)
Thanks Jim for the feedback, it's amazing to see the original author of the QUIC protocol respond!

Further reading

If you're looking for more information, have a look at these resources:
Many thanks to Google for leading the efforts here!

-- link

Nota: foi copiado na integra porque o autor explicou muito bem o assunto. Parabens ao autor.

segunda-feira, 19 de março de 2018

BGP - AS Reservados

ASN de 16 bits
Número de AS/bloqueasignación
48128-54271Sin asignar
54272-64511Reservado por IANA
64512-65534Libre para uso interno (private range)

ASN de 32 bits
Número de AS/bloqueasignación
0.0-0.65535Antiguos ASN de 16 bits
2.0-2.1023Asignado a APNIC
2.1024-2.65535Sin asignar
3.0-3.1023Asignado a RIPE NCC
3.1024-3.65535Sin asignar
4.0-4.1023Asignado a LACNIC
4.1024-4.65535Sin asignar
5.0-5.1023Asignado a AfriNIC
5.1024-5.65535Sin asignar
6.0-6.1023Asignado a ARIN
6.1024-65535.65534Sin asignar

sábado, 17 de março de 2018

Mikrotik - links avaliar

--- link sobre vlan no mk (desatualizado)

config freeradius e sql 

avaliar pagina de login:




auto login:


Is it possible to configure AP isolation or Wireless isolation?, so that mi wireless clients cannot "see" each other.

Set "default-forwarding=no" on your wireless interface...

---- pesquisar os posts repetidos

Tela de login responsiva (adapta-se ào tamanho da tela do aparelho) e lê o código QR e faz login automático ou manual.


--- ap dual band

--- "dual channel"

leave the width 20mhz and specify the extension channel eC or Ce and then it should be working as a 20/40mhz.

--- avaliar dicas

traduzir msg de erro para portugues


--- vpn

-- vpn sonicwall

-- vpn redundante:

--- certificado digital

--- backup restore e import export

--- milliscript

--- ddns

-- modem huawei e8372

---- template para criar voucherqr code

---- scripts variados

--- script vpn ipsec dynamic ip

---- artigo

--- ptp - wi-fi

--- change password

 --- 802.1x EAP

---- vlan configuration

--- links

- verificar sniffer

--- load balance

--- melhoria failover   <


--- mostra diagrama de fluxo dentro do mikrotik

--- software de admin isp?

--- radius captcha


--- hotspot user profile radius

--- advertasin

--- interface name variable login page

--- scripts

---configurar AP mikrotik

--- Boas Práticas de Instalação de Equipamentos em Redes Wireless

--- projeto alta capac

---- esse seleção de rate suported



---avaliar tool realtime traffic monitor
--- blacklist?
--- site interessante - tem lista de url e de onde estao vendo.
--- avaliar site sobre vmware vsan e mikrotik 
--- link sobre queues bem explicado

--- spamhaus para mk Spamhaus + Dshield + Malc0de + OpenBL Malicious Ip Blacklists!

--- mikrotik ssh key

--- avaliar blog

---- avaliar link blacklist update php 
--- hotspot 
--- avaliar site interessante 
--- avaliar site sobre MK e cracks
--- avaliar site interessante?

--- avaliar video sobre mimo e nv2

--- site interessante, avaliar melhor

--- avaliar site
-- avaliar autodeploy
--- avaliar site
--- avaliacao de vpns 
--- downloadas uteis 
--- links avaliar
---- script pre-config avaliar
 ---- avaliar site meio desatualizado
-- avaliar este site:

--- meio desatualizado

--- script completo? avaliar

--- avaliar site sobre wifi 
--- avaliar site

 --boa explicação para pptp

 ---fazer vpn + freeradius

---site interessante -avaliar

---- pptp + radius

---- comentarios sobre openvpn no mikrotik

--- openvpn

--- bem direto

--- dicas hotspot

--- mikrotik vlan

/interface vlan add name=vlan3 interface=ether3 vlan-id=3
/interface vlan add name=vlan2 interface=ether3 vlan-id=2

/interface bridge add name=bridge-vlan30
/interface bridge port add bridge=bridge-vlan30 interface=ether5
/interface bridge port add bridge=bridge-vlan30 interface=vlan30

/interface bridge add name=bridge-vlan20
/interface bridge port add bridge=bridge-vlan2 interface=ether2
/interface bridge port add bridge=bridge-vlan2 interface=vlan2

-----avaliar posts ---

---- avaliar site clonar --- 
--- avaliar hostpot com voucher. 
--- avaliar password recovery, hotspot voucher. 
--- avaliar site  (clonar?) 
-- ssl para hotspot e script para fetch test
--- avaliar sobre ping gw check usando dns do google
---- avaliar scripts

quinta-feira, 15 de março de 2018

IPv6 - BGP

IPv4 BGP vs IPv6 BGP

IPv4 BGP vs IPv6 BGPBGP is older than IPv6. Even BGP-4, the version we still use today, predates IPv6: the first BGP-4 RFC (RFC 1654) was published in July 1994, while RFC 1883, the first IPv6 RFC, wasn’t published until December 1995. And unlike protocols like RIP and OSPF, which have separate versions for IPv4 and IPv6, there’s only one BGP: BGP-4 handles both IPv4 and IPv6. (And VPNs, MPLS and more.)
A little magic is required to let a 21-year-old routing protocol carry routing information for a 19-year-old network protocol: that would be the Multiprotocol Extensions. These turn regular BGP-4 into Multiprotocol BGP (MP-BGP), although that term is rarely used these days. The Multiprotocol Extensions, originally published as RFC 2283 in 1998, use some clever encoding to allow BGP-4 to carry a wide range of “address families”.
Usually, an address family identifies a network protocol, but there are also AFI (address family identifier) numbers given out for phone numbers and DNS names, which don’t map directly to a network protocol. In addition to the AFI, MP-BGP also uses a Subsequent Address Family Identifier (SAFI), which indicates the use of regular unicast routing, multicast routing, distributing VPN information, and so on. For instance, AFI 1 with SAFI 2 means BGP will carry IPv4 multicast routing information, and AFI 2 with SAFI 1 specifies IPv6 unicast routing information.
BGP routers that support IPv6 allow BGP sessions to be set up using IPv6 addresses. MP-BGP speakers tell their neighbors which AFI+SAFI combinations they want to use in the OPEN message at the beginning of a BGP session. This can lead to the situation where IPv6 routing information is exchanged over IPv4, or IPv4 routing information is exchanged over IPv6. In principle, there’s nothing wrong with that, but it does lead to a complication: how does the router know what IPv6 next hop address to include in its updates towards an IPv4 neighbor? To avoid this situation, it’s considered best practice to only exchange IPv4 prefixes over an IPv4 external BGP (EBGP) session and only exchange IPv6 prefixes over an IPv6 EBGP session.
However, internal BGP (IBGP) doesn’t update the next hop address, so there are no problems exchanging both IPv4 and IPv6 prefixes over the same IBGP session. So most networks use the existing IPv4 IBGP sessions to exchange IPv6 prefixes rather than set up a whole new set of IPv6 IBGP sessions. The only downside of this approach is that if then something bad happens to IPv4, the IPv4 IBGP sessions go down and IPv6 is also affected. If IPv6 had its own IBGP sessions, it may have continued to operate independently from IPv4.
All this comingling of IPv4 and IPv6 within BGP does make configuring a router a bit more complex. This is what a simple BGP configuration on a Cisco router looks like in an IPv4-only world:
router bgp 64512
network mask
neighbor remote-as 65500
neighbor description My favorite BGP neighbor
neighbor prefix-list outfilter out
neighbor filter-list 1 out
ip as-path access-list 1 permit ^(64512_)*$
ip prefix-list outfilter permit

A BGP configuration that does the same thing for IPv6 looks like this:
router bgp 64512
neighbor 2001:db8:c0f:fee::6:5500 remote-as 65500
neighbor 2001:db8:c0f:fee::6:5500 description My favorite BGP neighbor
address-family ipv6 unicast
neighbor 2001:db8:c0f:fee::6:5500 activate
neighbor 2001:db8:c0f:fee::6:5500 prefix-list outfilter out
neighbor 2001:db8:c0f:fee::6:5500 filter-list 1 out
network 3ffe::/16
ip as-path access-list 1 permit ^(64512_)*$
ipv6 prefix-list outfilter permit 3ffe::/16

So the settings that are the same for both IPv4 and IPv6 (most notably the remote AS number, but also the description) are configured immediately following the “router bgp …” line, but anything IPv6-specific is grouped under “address-family ipv6”. (Or “address-family ipv6 unicast”.) Obviously, the IPv6 prefixlist goes under the IPv6 settings, but the same applies to the IP AS path access list: you may want to apply different AS path filters to IPv4 and IPv6. Things get interesting when we merge both configurations. If we then display the router configuration, it will look something like this:
router bgp 64512
neighbor 2001:DB8:C0F:FEE::6:5500 remote-as 65500
neighbor 2001:DB8:C0F:FEE::6:5500 description My favorite BGP neighbor
neighbor remote-as 65500
neighbor description My favorite BGP neighbor
address-family ipv6
neighbor 2001:DB8:C0F:FEE::6:5500 activate
neighbor 2001:DB8:C0F:FEE::6:5500 prefix-list outfilter out
neighbor 2001:DB8:C0F:FEE::6:5500 filter-list 1 out
network 3FFE::/16
address-family ipv4
no neighbor 2001:DB8:C0F:FEE::6:5500 activate
neighbor activate
neighbor prefix-list outfilter out
neighbor filter-list 1 out
network mask

So what has happened is that the router decided that now that we’re using an IPv6 address family, we need to be more specific about our IPv4, too, and moved all the IPv4-specific configuration commands to a new “address-family ipv4” section.
Also note how neighbors are deactivated for IPv4 and activated for IPv6, as exchanging IPv4 prefixes and not exchanging IPv6 prefixes are the default behavior—even for BGP sessions towards an IPv6 neighbor. However, these defaults may not be universal across software versions and different BGP implementations that use Cisco-like configuration commands, so it’s best to always explicitly activate and deactivate all IP version combinations, with the exception of activating IPv4 for IPv4.
Old Cisco IOS versions curiously used show bgp for IPv6 wherever show ip bgp was used for IPv4. Later this was changed to show bgp ipv6 and after that to show bgp ipv6 unicast . (And show ipv4 unicast can be used for IPv4.)
The minimum prefix size that you’ll see in IPv6 is /48, which is the size of provider independent address blocks. ISPs get at least a /32. The IPv6 routing table is much smaller at some 21,000 prefixes while the IPv4 global routing table is well over half a million prefixes. But with the above in mind, there’s really no fundamental difference between how BGP works for IPv4 and IPv6. IPv6 is still IP, after all.

Boost BGP Preformance

Automate BGP Routing optimization with Noction IRP



quarta-feira, 14 de março de 2018

Hardware - Conheça o novo Raspberry Pi 3 Model B+

Com preço sugerido de US$35, nova placa da Raspberry Pi Foundation traz Wi-Fi 802.11ac dual-band e processador quad-core 64-bit de 1.4GHz.

A Raspberry Pi Foundation tem um novo mini PC para o Dia do Pi, que é comemorado nesta quarta-feira, 14/3. Chamado de Raspberry Pi Model B+, o aparelho vai custar 35 dólares, mesmo preço de outros dispositivos vendidos pela fundação.
A nova versão do mini PC inclui Wi-Fi 802.11ac dual-band, o que significa que oferece a versatilidade de redes wireless de 2.4GHz e 5GHz. O Model B+ ainda conta com um processador quad-core 64-bit de 1.4GHz – um ganho de 200Mhz em relação ao chip de 1.2GHz do antecessor Pi 3 Model B.
Para a nova placa, a Raspberry Pi Foundation usa uma versão atualizada do processador presente no Pi 3 Model B. Essa nova versão pode alcançar velocidades maiores de clock, e consegue monitorar e controlar de forma mais precisa a temperatura do chip, de acordo com um post feito pelo diretor da Raspberry Pi, Eben Upton. O Model B+ também conta com Bluetooth 4.2 e uma conexão ethernet mais rápida (via USB 2.0). 
Uma coisa importante sobre o novo Raspberry Pi é que a empresa aconselha fortemente os usuários a usarem uma “fonte de energia de alta qualidade de 2.5A”. Em outras palavras, não compre o adaptador mais barato que você encontrar na Internet. A razão para isso é que o Pi 3 Model B+ precisa “substancialmente de mais energia do que o seu antecessor”. 
Apesar do lançamento deste novo modelo, pouco vai mudar com os preços da linha de placas da Raspberry Foundation. O Raspberry Pi 1 B+, o Raspberry Pi 2B e o Raspberry Pi 3B continuam custando, respectivamente, 25 dólares, 35 dólares e 35 dólares.
Obviamente, que o modelo mais indicado para compra é o novo Pi 3 B+. As outras placas de 35 dólares são voltadas principalmente para clientes corporativos que precisam continuar usando um aparelho específico.


Hardware - tudo que você precisa saber sobre o novo Bluetooth 5

Com foco na Internet das Coisas, novo padrão do protocolo traz alcance maior e menor uso de energia para transmissão de dados.
O Bluetooth está em todos os lugares. O que começou como uma maneira de conectar headsets estranhos transformou-se em um protocolo wireless robusto que conecta tudo, desde fones de ouvido até monitores cardíacos, wearables e estações climáticas.
A última atualização do protocolo, o Bluetooth 5, traz melhorias significativas, especialmente para modos de operação com baixa energia. Esse update tem o objetivo de preparar a tecnologia para a futura “inundação” de aparelhos IOT (Internet das Coisas), e se você tem um iPhone 8 ou X, então a nova versão já está no seu smartphone.
Confira abaixo cinco coisas que você precisa saber sobre o novo Bluetooth 5.
É apenas ‘Bluetooth 5’
As versões anteriores do Bluetooth, incluindo a 1.0, tinham um ponto decimal. Assim, você veria coisas como Bluetooth 3.0 ou Bluetooth v4.1 nas listas por aí. Mais recentemente, no update 4.0, o Bluetooth adicionou um novo protocolo de baixo consumo de energia normalmente listado como Bluetooth LE (de Low Energy, ou algo como “Baixa Energia”, em português).
Com essa nova versão do Bluetooth, o grupo SIG (special interest group), que controla a especificação, optou por simplesmente chamá-la de Bluetooth 5, sem nenhum ponto decimal ou acréscimo de “v” ou “LE” no final. Sim, o novo padrão ainda inclui o protocolo de baixa energia (e ele foi amplamente melhorado). Mas o SIG queria deixar a marca mais simples e fácil de ser entendida pelo público. 
Novo hardware
Para poder aproveitar o Bluetooth 5, você precisará de novos aparelhos que ofereçam suporte para a tecnologia. Se você tem um iPhone 8 ou X, por exemplo, então já está coberto – pelo menos no campo dos smartphones. A Apple foi uma das primeiras a lançar um aparelho compatível com o Bluetooth 5 (juntamente com a Samsung no Galaxy S8). 
Mas os aparelhos com os quais você se conecta também precisam contar com hardware compatível com o Bluetooth 5. Isso significa fones de ouvido, alto-falantes inteligentes, mouses, teclados e tudo mais com Bluetooth 5.
O Bluetooth 5 está tornando-se rapidamente o padrão nos smartphones top de linha, mas nem tanto nesses outros aparelhos citados acima. Provavelmente não veremos uma proliferação de acessórios compatíveis com Bluetooth 5 até que smartphones, tablets e laptops que suportam a nova especificação passem a ser mais comuns no mercado.
Compatibilidade reversa
A boa notícia é que os hardwares com Bluetooth 5 possuem compatibilidade reversa completa com as versões anteriores da tecnologia. Desta forma, o seu smartphone com Bluetooth 5 não terá nenhum problema para se conectar com fones, alto-falantes, smartwatches e outros aparelhos com versões anteriores do Bluetooth.  
No entanto, você não receberá nenhum dos benefícios da nova versão do Bluetooth – a conexão funcionará como se você não tivesse o Bluetooth 5 no seu dispositivo.
Alcance maior
A especificação do Bluetooth 5 permite transmissões com menor uso de energia e que sacrifiquem a taxa de dados por um maior alcance. Aliás, um alcance muito maior: até quatro vezes o alcance do anterior Bluetooth 4.2 LE, com um alcance máximo de cerca de 240 metros. Vale notar que essa é uma distância teórica. No mundo real, você pode esperar por muito menos, apesar de que ainda será uma melhoria enorme em relação às versões anteriores do Bluetooth.
É bom ter em mente que você não terá esse tipo de alcance o tempo todo e em todos os aparelhos. Os desenvolvedores escolheram de forma consciente sacrificar a largura total de banda pelo alcance. Mas isso é perfeito para muitos aparelhos de Internet das Coisas, que costumam transferir pequenas quantidades de dados e precisam alcançar uma casa inteira ou uma loja grande, por exemplo.
Maior largura de banda máxima
Além de habilidade de sacrificar a largura de banda por um alcance maior, o Bluetooth 5 também adiciona uma nova interface que consegue dobrar a largura de banda às custas da energia. Essa nova camada física (PHY) suporta velocidades de até 2MB/s e transmissões de +20dB no modo de baixa energia.
Em outras palavras, o novo Bluetooth oferece duas interfaces para operação de baixa energia: uma para transmitir menos dados por distâncias maiores, e outra para transmitir o dobro de dados, mas com um alcance menor. 
Essa é uma ótima notícia para aparelhos que precisam transmitir grandes quantidades de dados (como uma atualização de firmware) ou para aplicativos que usam muitos dados, como vídeo e áudio. 
Também significa que um dia poderemos ver fones de ouvido Bluetooth que usam a especificações de baixo consumo de energia, o que poderia aumentar significativamente a duração da bateria. Infelizmente, o Bluetooth 5 não inclui um protocolo de transmissão de áudio padrão dentro da especificação de baixa energia. Então, por enquanto os fones e headsets Bluetooth continuarão a usar os modos Bluetooth Classic que gastam mais bateria. 
Voltado para IoT
Quase todas as grandes melhorias do Bluetooth 5 são exclusivamente para o seu modo Low Energy (BLE). Introduzido inicialmente no Bluetooth 4.0 e depois melhorado nas versões v4.1 e v4.2, o LE é um protocolo totalmente separado do Bluetooth “clássico”.  
Desde o Bluetooth 4.2, o modo Bluetooth LE transmite muito menos dados do que o Bluetooth clássico, mas possui um alcance parecido, latência muito menor, e usa apenas uma fração da quantidade de energia. É por isso que ele é tão usado em aparelhos de IoT, e em qualquer lugar onde uma duração maior de bateria ou uma operação com baixo uso de energia seja chave.
O Bluetooth 5 adiciona melhorias à operação de baixa energia, além das conexões opcionais com maior largura de banda ou maior alcance. Por exemplo, o novo padrão traz um aumento significativo de oito dígitos em termos de eficiência de transmissão de dados. Isso significa, essencialmente, até oito vezes mais aparelhos conectados.
O grupo SIG imaginou casas e escritórios cheios de aparelhos iOS, e desenvolveu o Bluetooth 5 para torná-lo mais poderoso, útil e fácil de se conectar.


sexta-feira, 9 de março de 2018

IPv6 - Tools links

quinta-feira, 8 de março de 2018

IPv6 - Windows não aceita DNS via stateless
--- endereços temporarios

DNS - Guia de dos melhores servidores publicos (desatualizado mas ainda ta valendo)


Melhores Servidores DNS

Google Public DNS

Servidor primário:;
Servidor secundário:
Caso você tenha suporte a IPv6, esses são os endereços:
Servidor primário: 2001:4860:4860::8888;
Servidor secundário: 2001:4860:4860::8844.


Servidor primário:;
Servidor secundário:


Para usar o serviço, configure seu computador ou roteador com os seguintes endereços:
Servidor primário:;
Servidor secundário:
Caso sua rede tenha suporte a IPv6, esses são os endereços:
Servidor primário: 2804:10:10::10;
Servidor secundário: 2804:10:10::20.

Level 3

Servidor principal primário:;
Servidor principal secundário:;
Servidor alternativo:;
Servidor alternativo:;


Para utilizar – IPv4
Servidor primário:
Servidor secundário:
Para utilizar – IPv6
Servidor primário: 2001:1608:10:25::1c04:b12f
Servidor secundário: 2001:1608:10:25::9249:d69b


É um DNS gratuito que promete confidência nas suas requisições.
Para configurar no IPV4 use:
  • Servidor primário:
  • Servidor secundário:

Norton ConnectSafe

Nota: No caso do Norton, eles oferecem três classes de DNS, escolha a proteção que você deseja:
Proteção para: Segurança (malware, phishing sites e sites fraudulentos)
Servidor primário:
Servidor secundário:
Proteção para: Security + Pornografia
Servidor primário:
Servidor secundário:
Proteção para: Security + Pornografia + Outros
Servidor primário:
Servidor secundário:

 Mais DNS acesse:


Top 10 Public DNS Servers: Google DNS vs OpenDNS vs Level3 vs Verisign and Others

As you may know, your Internet Service Provider (ISP) will usually assign Domain Name System (DNS) servers that your router will connect to when accessing the internet. These servers translate written web addresses (i.e. - into IP addresses ( and vice versa, thus making the web more user-friendly. However, sometimes the DNS assigned by your ISP isn't the fastest one available in your area, and you do have the option of changing your DNS servers within your router or computer settings. We recently published a guide on how to use DNS Benchmark and Namebench to compare the best DNS servers.
Ultimately, the speed and overall performance of your DNS will depend on your location and other variables, so it's best to use a benchmarking application to determine which DNS is truly best before making your decision. With that said, if you've been wondering about the differences between the most popular options like Google DNS, OpenDNS, Level3, and Verisign, check out this comparison of the fastest and most reliable free public DNS servers:

Google Public DNS

  • Primary DNS server address -
  • Secondary DNS server address -
Google Public DNS is easily the most commonly used and widely recommended third-party DNS services, most likely because Google is such a household name and their server addresses are easy to remember. Google also offers a premium paid DNS solution called Cloud DNS, which offers high performance, low-latency access to a global DNS network, although it is generally intended for business level users.
Overall, most users find that switching to Google Public DNS speeds up their web browsing, improves security, and minimizes unnecessary redirects. Still, benchmarking against the other DNS servers on this list is always recommended – sometimes alternatives can be faster, particularly Open DNS.


  • Primary DNS server address –
  • Secondary DNS server address –
OpenDNS is perhaps the second-most popular DNS service because in some cases it can be more than 150% faster than Google Public DNS and it also provides some extra filtering features. It's also typically faster than the default name servers assigned by ISPs.
Although speeds will vary and benchmarking is still recommended, it's worthwhile to try out OpenDNS because it has content blocking and web security options that aren't offered by other free DNS services. In fact, they have a Family Shield version that comes pre-configured to block adult content, as well as a Home version that is fully customizable.

Level3 Communications

  • Primary DNS server address –
  • Secondary DNS server address –
Level3 provides one of the most commonly used DNS services in the world, with many ISPs and mobile data providers relying on their DNS servers. Verizon's DNS servers are frequently listed as,,,, and/or, however those DNS servers are actually alternate addresses of the Level3 server addresses shown above.
Mobile carriers like Verizon usually try to balance DNS traffic by routing the requests through their server first and then to Level3 servers on a filtered basis. Many ISPs use Level3 in a similar manner, so the default DNS assigned to your router by your ISP may in fact be a Level3 DNS server.


  • Primary DNS server address –
  • Secondary DNS server address –
The Verisign Public DNS is a fully free DNS service that aims to provide a combination of stability, privacy, and security. It's commonly ranked as a top 10 DNS based on the reliability and uptime of its servers, which can be checked at any time on their Server Status page. They also make it easy to configure their DNS with a simplified configuration instructions page, so it's an ideal recommendation for a novice DNS user.
Of course, the process of switching your DNS servers to Verisign is the same as assigning any other DNS, but it helps to have guidance if you've never done it before. The company has pledged not to share user data or display ads, and also offers IPv6 public DNS servers.

Honorable Mentions


  • Primary DNS server address –
  • Secondary DNS server address –
They also offer IPv6 DNS server at the following addresses:
  • Primary IPv6 DNS server address: 2001:1608:10:25::1c04:b12f
  • Secondary IPv6 DNS server address: 2001:1608:10:25::9249:d69b, which is the service's actual home web address as well as its name, is a popular DNS provider that promises fast, uncensored and fully free public DNS servers. Their services uses no logging and uses the Domain Name System Security Extensions (DNSSEC) protocol to ensure privacy and anonymity. This is essentially a philanthropic web company that aims to improve and preserve net neutrality by making high quality DNS servers available to the public free of charge.

Comodo Secure DNS

  • Primary DNS server address –
  • Secondary DNS server address –
Other DNS server addresses used by Comodo Secure DNS:
Comodo Secure DNS is a free service offered by Comodo Group. Many users find that this is the fastest DNS in heir area after performing benchmarking tests against several other competitors and their ISPs assigned servers. The key advantage of this GPS is that it is made by a leader in internet and computer security. The filtering features are also useful for parents or in workplaces where web moderation is a necessity. Strategically placed nodes and proprietary routing technology makes this one of the faster free public DNS servers available.

Norton ConnectSafe

  • Primary DNS server address –
  • Secondary DNS server address –
Norton ConnectSafe is a free public DNS service from the creators of Norton Antivirus. Although the primary focus of the DNS is security, it also excels in reliability and availability, making it a top choice for many users, especially those who already have Norton installed on their machine. Norton's DNS blocks the user's computer from accessing sites that contain scams, malware, phishing schemes, pornography, and other cyber risks and categories considered by Norton to be unfriendly to families and/or and business. The filtering and categorization is based on the Symantec RuleSpace service. It's important to make sure you agree with all of their filtering policies before deciding to go with this DNS.


  • Primary DNS server address –
  • Secondary DNS server address –
SafeDNS is a free public DNS that specializes in content filtering. It aims to protect the user from botnets, malware, and other cyber threats and annoyances. The SafeDNS database contains profile on more than 90 million of the internet's top sites, with filtering capabilities separated into more than 55 categories. The network is also capable of blocking traffic form all sorts of advertising pop-ups and content, including contextual, audio, and video ads. Another interesting feature of Safe DNS is that it comes with free support, so it's a good solution for businesses or novice web users that need guidance when setting up and using the DNS.


  • Primary DNS server address –
  • Secondary DNS server address –
GreenTeamDNS offers a comprehensive web filtering and site blocking service that is great for businesses and families. The free version utilizes their moderate policy, but upgrading to a paid Premium account gives the user the ability to choose which sites and categories are blocked. One of the key advantages of using GreenTeamDNS is that it is compatible with every kind of devices, including smartphones, tablets, and even game consoles like the PS3. The filtering is separated into 47 categories to give the user maximum control over what their computer access through the DNS. It's ideal for parental or workplace monitoring and control as there are logs kept that allows you to view which sites were visited and blocked.


  • Primary DNS server address –
  • Secondary DNS server address –
OpenNIC is based on a very large network of volunteer-provided servers, so the above addresses are just the main portals, but there are actually a lot of DNS servers available on their All Servers page. However, clicking the large self-titled link above to visit their home page and you'll see a list of the fours closest server. NIC stands for “Network Information Center,” which describes the network of servers that comprise OpenNIC. The network is design to serve as a “non-national alternative” to Top-Level Domain (TLD) corporate registry systems such as the Internet Corporation for Assigned Names and Numbers (ICANN). It's an interesting topic to research when learning about anonymity, security, and DNS neutrality.


If you really want to be through the best way to determine which DNS is the best would be to use a benchmarking application to compare the two. However, if you frequently travel then it's good to know which services are typically the most ideal in the areas you most frequently visit.
Although conducting a comparison is important, in general here are some broad suggestions that can be made depending on what you're looking for in a DNS:
  • Speed and Reliability - In terms of server reliability, Google Public DNS, Level3, and OpenDNS are generally the most widely available regardless of where you are. However, in the minority of cases other DNS servers may perform more optimally. Since speed and reliability are the two most important performance factors, it's best to learn how to benchmark the top options quickly and effectively using a program like Namebench.
  • Filtering and Blocking - If you want an automated filtering or blocking solution, Norton ConnectSafe or GreenTeamDNS are some of the best options. OpenDNS is also excellent for this purpose. Some free public DNS servers offer paid premium services that allow you to control the types of categories and sites that are blocked.
  • Logging and Monitoring – If you're apprehensive about a company logging your internet activity the it's important to use a no-logging service like DNS.Watch. On the other hand, if you'd prefer to be able to monitor and investigate web usage in retrospect, then a service that keeps logs would be ideal. Businesses and families typically choose to keep logs, whereas someone concerned with anonymity and privacy would opt for a no-log DNS.
Finally, it's worth noting that the best DNS can vary and change from day to day, depending on server uptime and other factors. Thus, it's worthwhile to conduct daily benchmark tests to see which DNS consistently performs the best over a long period of time.