When looking for documentation on Ethernet, one can easily find that the frame includes a Frame Check Sequence. This is a bunch of bits that allow the receiver to verify the frame. If the frame somehow got corrupted on its way from sender to receiver, the FCS will not match the frame data and the receiver will discard the corrupt frame. Exactly how this FCS is calculated is not that easy to find.
Archive for the ‘Networking & Security’ Category
When doing some network engineering, it’s sometimes necessary to tunnel across IP-clouds. There are multiple reasons why one would use a tunnel:
- Security: You don’t want the carrier-network to see your data
- IP conflicts and/or routing issues: You want to carry private IP addresses (eg 10.0.0.0/8 in IPv4) across a public segment (eg the Internet)
- Workarounds: for whatever reason you whised that there was a connection between A and B
Technically, a tunnel consists of taking a bunch of bytes and re-packaging it. The well knows GRE-tunnel takes IP packets and encapsulates them in another IP packet. The outer IP-layer is used to carry the packet across to the other endpoint, where the inner IP-layer reappears. Other tunnels operate at different layers. SSH for example encapsulates TCP segments inside its TCP-connection; SSL-based VPN encapsulate IP packets inside their TLS-session.
Especially in the third case, workarounds, it would be very practical to be able to build a layer 2 tunnel: transport raw ethernet frames, including IEEE802.1q VLAN tags. This is called the L2TP, Layer 2 tunneling protocol. The current version (3) is defined in RFC 3931.
When hosts have a dynamic IP, it’s very convenient to have its DNS-name follow that dynamic IP. There are several services on the net that do this. However, the regular DNS already provides this feature. The nsupdate tool (comes with BIND) allows you to send an update to the DNS servers. By default, a DNS server does not allow updates for security reasons.
To keep the whole world from updating your zone, there are several possibilities to restrict who can update what. The easiest to setup is an IP restriction: specify from which IPs updates are to be accepted. In my setup, however, I’d like the host to update its own record. Since the host’s IP is dynamic, this is not an option.
When doing some research on the different tables in iptables, I was trying to figure out in what order what tables are traversed. Obviously PREROUTING happens before POSTROUTING, but it becomes more difficult to figure out if mangle happens before are after nat.
I found a post which links to this overview (local copy):
Recent tests on kernel 3.13.0 (Ubuntu Trusty 14.04) show that tcpdump captures before mange-PREROUTING and after nat-POSTROUTING.
Everyone that has used the Cisco IOS command line knows this problem. When you mistype a command, the router tries to resolve the “hostname” and you have to wait for 24 very long seconds:
Router#conft Translating "conft"...domain server (255.255.255.255) (255.255.255.255) Translating "conft"...domain server (255.255.255.255) % Unknown command or computer name, or unable to find computer address Router#
Until recently I used the “no ip domain-lookup” configuration entry to counter this. This disables DNS-lookups altogether, which might not always be what you want. I recently found the proper solution to fix this:
When I was updating my GPG/OpenPGP key, I did some research on the internals of the keys. There appear to be very nice tools to explore the internals of a key. You can also manipulate this key in different aspects: use multiple passwords on a single key, remove part of a secret key for enhanced security; you can even move subkeys between master-keys.
When troubleshooting a network performance problem today, I discovered some strange behavior when using an internet connection over a cellular network (GSM in my case):
When the line was idle for half a minute or so, the connection seems to hang a few seconds before working again. I verified this with our mobile provider Proximus and got the following interesting response: (liberally translated by me)
Continue reading ‘Setup delay on wireless data networks’ »
Up until now, I logged into my blog using the standard username/password. Since my blog is hosted as a vhost, setting up SSL (https) is a pain: You either need a dedicated IP:port per ssl-vhost, or need to work with certificates that list multiple domains (Update 2009-04-18: SNI). Running SSL on a non-standard port works pretty well, but most firewalls don’t like that. Conclusion: the only widely available way to log into my blog is over plain http. Needless to say, I don’t like my password going in plaintext over the Internet.
IPv6 is, big surprise, the new version of IP. The current internet runs on IPv4, which has some drawbacks. Practically both versions are the same: they allow connections from one host to another host. Technically however, there are some major differences, most notably the enlarged address space. For the moment, most hosts will run a dual-stack configuration.
I decided that it was time to implement IPv6 on my home network and get a IPv6 connection to the IPv6-Internet.
Cisco switches are very verbose in their layer 1 error reporting as shown in the output below:
FastEthernet0/1 is down, line protocol is down
Hardware is Fast Ethernet, address is 0030.94bd.4041 (bia 0030.94bd.4041)
MTU 1500 bytes, BW 0 Kbit, DLY 100 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive not set
Duplex setting unknown, Unknown Speed, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:35:31, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1 packets input, 64 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 watchdog, 0 multicast
0 input packets with dribble condition detected
3 packets output, 444 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
On this page on the Cisco website, there is a table listing all error counters and their meaning for Ethernet interfaces.
