Category Archives: Network

Evolution of Managed Network Services

Network

... or how to get rid of monolithic service architectures.

1991 - CORBA
A distributed management framework for network services. The father of it all. First on Uni* systems, later on other operating systems as well.

Pros:
- Not monolithic as everything before.
- The "O" stands for "Object", so it must be totally awesome.

1996 - DCOM
A distributed management framework for network services. The Microsoft way. Back in the days Microsoft reinvented everything to set new standards and own them.

Pros:
- Not monolithic as everything before.
- The "O" stands for "Object", so it must be totally awesome.

1997 - Java JNDI and RMI
A distributed management framework for network services. Along came the bytecode revolution with Java, and yes, of course Java wanted to do it the Java way.

Pros:
- Not monolithic as everything before.
- It's Java, so it must be totally awesome.

1999 - Java JNDI and EJB
A distributed management framework for network services. Way cooler than RMI.

Pros:
- Not monolithic as everything before.
- Even more object-oriented, so it must be totally awesome.

1999 - Java JNDI and Tomcat
A distributed management framework for network services. Way cooler than EJB.

Pros:
- Not monolithic as everything before.
- Everyone is using it, so it must be totally awesome.

2003 - SOAP
Distributed network services. Can be used by other programming languages than Java. In case there are any. Lacks service discovery, as e.g. CORBA already provided out of the box more than 20 years ago. So you need an additional layer called ESB.

Pros:
- Not monolithic as everything before.
- The "O" stands for "Object", so it must be totally awesome.

201? - REST
Distributed network services. Advancement of SOAP.

Pros:
- Almost the same as SOAP, just a bit smaller.

2015 - Cloud Microservices
A distributed management framework for network services. Based on REST. Lacks service discovery though, as e.g. CORBA already provided out of the box more than 20 years ago. So you need an additional layer called service mesh.

Pros:
- Not monolithic as everything before.
- It has the word "Cloud" in it, so it must be totally awesome.

202? - ...
Not sure what it will be called, but sure as hell it will be a distributed management framework for network services. And it will be way hotter than everything before, because it will not be monolithic.

Share

Slow wifi network on Linux laptop

wifi on Linux laptop

If network performance on your laptop is slow and unstable, it might be because power management of your wifi adapter and of Linux are not playing together.

One of the things you will notice are flapping ping rates:

$ ping 192.168.0.1 
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=23.3 ms 
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=44.7 ms 
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1161 ms 
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=35.2 ms
...
^C 
--- 192.168.0.1 ping statistics --- 
30 packets transmitted, 20 received, 33% packet loss, time 30000.14s 
rtt min/avg/max/mdev = 23.3/537.9/2119.2/2005.3 ms

As you can see the 3rd ping has a high round trip time of over one second. You might also notice high packet loss rates.

If this is the case and your hardware seems to be ok, you can try to switch off Network Manager's automatic power management in /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf:

[connection] 
wifi.powersave = 2

Restart NetworkManager (sudo systemctl restart NetworkManager) or reboot your Laptop.

If you are not using NetworkManager, you can try to switch off power management directly:

sudo iwconfig wlp2s0 txpower fixed

Afterwards check that power management is really disabled:

sudo iwconfig wlp2s0
...
    Power Management:off
...
Share

World's most famous and secure public VPN service is leaking sensitive information

Probably one of the world's most famous public VPN providers is leaking your traffic. The weirdest thing about it is, nobody noticed the traffic before.

Lessons learned: Always check no matter how good the reputation might be.

https://www.niem.es/2019/03/f5d599a39d02caef1984e95fdc606f838893ffc5-xyz.html

Update (2019-10)
Nobody is perfect. Half a year later, there seems to be another problem with our famous VPN service. Not so much information about it out there, so here is a link in case you want to check yourself.

Lessons learned: Double check for safety's sake.

https://www.theregister.co.uk/2019/10/05/security_roundup_october_4/

Update (2019-10)
Oh noooo, now our famous VPN provider got hacked really bad. Private keys for OpenVPN have been revealed, but they already expired in 2018. Nevertheless, it could be that those keys were hacked in 2018 when they were still valid. All I can say: "Told ya!"

Lessons learned: Triple check for safety's sake.

https://share.dmca.gripe/hZYMaB8oF96FvArZ.txt

Share

BIND9 network ports

List of network ports that the DNS nameserver ISC BIND v9.10 listens to by default:

Port NumberUDP / TCPDescription
53UDPstandard port to respond to name queries
53TCPused for master/slave zone transfers or if query answers don't fit in UDP packet
953TCPcommunicate with rndc client utility
2200TCPstatistics channel (built-in webserver to display statistics page)

Share

iSCSI connection states in Open-iSCSI

This is the iSCSI connection state if the underlying network interface changes from "UP BROADCAST RUNNING MULTICAST" to "UP BROADCAST MULTICAST".

Log entries showing that the network interface has no longer the state "RUNNING":

Jul 3 14:17:31 host kernel: [974138.571169] bnx2 0000:08:05.0 eth2: NIC Copper Link is Down
Jul 3 23:05:05 host kernel: [1005760.957474] sd 10:0:0:0: rejecting I/O to offline device
... previous message repeats many times ...

Checking iSCSI connection state:

# iscsiadm -m session -P1
...
iSCSI Connection State: TRANSPORT WAIT
iSCSI Session State: FREE
Internal iscsid Session State: REOPEN

Log entry once the network interface state is back to "RUNNING":

Jul 4 06:56:31 host kernel: [1034019.191222] bnx2 0000:08:05.0 eth2: NIC Copper Link is Up, 1000 Mbps full duplex

Checking iSCSI connection state again:

# iscsiadm -m session -P1
...
iSCSI Connection State: LOGGED IN
iSCSI Session State: LOGGED_IN
Internal iscsid Session State: NO CHANGE

The output of "iscsiadm -m session -P1" can be used for monitoring the iSCSI connection e.g. in a simple Nagios or Icinga Perl script.

Share