Friday, June 25, 2021

IPv6 Deployment - LACNIC region

The video below shows the IPv6 deployment for the LACNIC region using a Bar Chart Race format




Made with https://flourish.studio/

Tuesday, June 1, 2021

Solved: Finder on MAC does not find any files in its searches

Problem:

   Finder can't find files when searching.


Solution:

   I know there are many solutions, many with spotlight in system preferences, but the one that worked for me was to open a terminal window and run/execute:


  #sudo mdutil -E /




    I hope this is useful

Wednesday, May 19, 2021

Solved: nping - libnsock mksock_bind_addr(): Bind to 2001:db8:1::1:0 failed (IOD #1): Cannot assign requested address (99)

 Problem:

  When using nping (which comes with nmap) we receive the message:

libnsock mksock_bind_addr(): Bind to 2001:db8:1::1:0 failed (IOD #1): Cannot assign requested address (99)


Current situation:
  The issue is that nping can not bind to the IP 2001:db8:1::1


Solution:
  There could be many different solutions, I'm only going to mention one.  What I did was to create a logical interface (tunnel type) with the IPv6 address I was needing (2001:db8:1::1). Here you have the commands.

ip tuntap add mode tun dev tun1
ip -6 addr add 2001:db8:1::1 dev tun1
ifconfig tun1 up


Finally, you could execute something like:

nping -6 -S 2001:db8:1::1 --tcp-connect -c 2 -p 53 <ipv6_dest> --source-mac 00:50:XX:XX:XX:35  --dest-mac 2c:XX:XX:XX:44:20


Hope this is useful

Thursday, September 3, 2020

Solved: Closing connection because of an I/O error in FRR - at least in Ubuntu

 If you are getting this message in FRR:

Closing connection because of an I/O error in FR


The solution is straight forward. You have to compile FRR with this flag:

--enable-systemd


So, it would be something like:

./configure \

    --prefix=/usr \

    --includedir=\${prefix}/include \

    --enable-exampledir=\${prefix}/share/doc/frr/examples \

    --bindir=\${prefix}/bin \

    --sbindir=\${prefix}/lib/frr \

    --libdir=\${prefix}/lib/frr \

    --libexecdir=\${prefix}/lib/frr \

    --localstatedir=/var/run/frr \

    --sysconfdir=/etc/frr \

    --with-moduledir=\${prefix}/lib/frr/modules \

    --with-libyang-pluginsdir=\${prefix}/lib/frr/libyang_plugins \

    --enable-configfile-mask=0640 \

    --enable-logfile-mask=0640 \

    --enable-snmp=agentx \

    --enable-multipath=64 \

    --enable-user=frr \

    --enable-group=frr \

    --enable-vty-group=frrvty \

    --with-pkg-git-version \

    --enable-systemd

    --with-pkg-extra-version=-MyOwnFRRVersion



you can follow those instructions and adding my previous solution:

http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-ubuntu2004.html

Tuesday, September 1, 2020

Tiny script: how to get the RRSIG DNS records with python3

 (I guess there are many other ways to do this, even more elegant)


import dns.resolver
domain='lacnic.net'
domain = dns.name.from_text(domain)
request = dns.message.make_query(domain, dns.rdatatype.ANY)
response = dns.query.tcp(request,'8.8.8.8')
#print(response)

for item in str(response).splitlines( ):
  if 'RRSIG' in item: print (item)


Monday, August 10, 2020

My review about coin.space (in summary, not recommended)

 Hello there,

  I know many of you are looking for good BTC wallets, good cryptocurrency fees and so on.

  Unfortunately I can not tell you which one is the best or the cheapest, but I can tell you a real BAD one: coin.space

  This site (coin.space) starts charging “normal” fees for sending money, however, they start increasing the fee ONLY for certain accounts, not all of them.

  I will tell you a very simple test I performed from the very same computer, at the very same time.

  • I opened two different browsers (Chrome & Firefox)
  • In one browser I tried to send money using an “old coin.space” account
  • In the other browser I tried to send money using a very new coin.space account
  • Trying to send about usd 50, for the “old account” it wanted to charge about usd 12
  • Trying to send about usd 50, for the “new account” it wanted to charge about  use 4


  What do you think?.., sorry coin.space but I had to publish this.


Thanks


Friday, September 6, 2019

The sad tale of the ISP that didn’t deploy IPv6

Once upon a time in the not so distant past, a large ISP dominated a country’s 
telecommunications market and felt powerful and without competition. Whenever someone 
needed to log on to the 
Internet they would use their services. Everyone envied their market penetration.

This large ISP, however, had never wanted to deploy IPv6 because they thought their stock
 of IP addresses was enough and saw no indicator telling them that they needed the new 
protocol.
During the course of those years, another smaller ISP began implementing IPv6 and slowly 
began to grow, as they realized that the protocol did indeed make a difference in the eyes of their 
clients and that it was helping them win over new users.

The small ISP’s market penetration continued to grow, as did their earnings and general respect
 for their services. As they grew, it became easier for them to obtain better equipment, traffic 
and interconnection prices. Everything was going very well. The small ISP couldn’t believe that
something as simple as deploying IPv6 could be paying off so spectacularly. Their customers
 told them their needs included running VPNs and holding conference calls with partners in 
other parts of the world, and that their subsidiaries, customers and business partners in Europe
 and Asia had already adopted IPv6.

Despite being so powerful, the large ISP began experiencing internal problems that were 
neither billing nor money related. Sales staff complained that they were having trouble closing 
many deals because customers had started asking for IPv6 and, although their ISP was so
 large and important, they simply did not have IPv6 to offer. Both corporate customers and 
residential users were asking for IPv6; even major state tenders were requiring IPv6.

When this started happening, the Sales Manager complained to the Products, Engineering and 
Operations departments. The latter were left speechless and some employees were let go by 
the company. In the end, Sales did not care where the fault lay – they were simply unable to 
gain new customers. Realizing that they were losing customers, some of the salespeople 
accepted job offers at the small ISP who was looking to grow their staff as they could now 
afford the best sales force. 

Then the same thing happened with the larger ISP’s network manager, an expert who knew 
a lot about IPv6 but who had been unable to overcome the company’s bureaucracy and bring
 the new protocol into production. Logically, the network manager was followed by his trusted 
server administrator and head of security. The large ISP couldn’t believe what was happening
 right before their very eyes. The sales force hired by the smaller ISP (those who used to 
work for the large ISP) brought with them their huge customer base, all of them potential prospects.

A stampede of the large ISP’s clients was on the way. The months went by and the smaller
 ISP was no longer simply offering Internet access – its Data Center had grown, major 
companies brought in new cache servers and much more. They were now offering co-location, 
hosting, virtual hosting, voice and video, among many other services.

When the large provider decided to deploy IPv6, it had to do so very quickly. Things went 
wrong; many errors were made. In addition, certain consultants and companies took 
advantage of their problems and charged higher rush fees. Network downtime increased,
 as did the number of calls to the call center. The large ISP’s reputation started to crumble.


As expected, in the end, everyone who was part of this story – clients and providers alike – 
ended up deploying IPv6. Some ended up happier than others, but everyone adopted IPv6
 on their networks.

By Alejandro Acosta