Why does(n't) it work?

How to tcpdump only IPv6 ping packets

3 minute read Modified:

IPv6 upper-layer protocol is not supported by proto[x]

When I was setting up a new system it was configured to have 2 IPv6 addresses. One fixed IPv6 address and one IPv6 via automatic configuration. I wanted to know which IPv6 address was used for as default, so I started tcpdump on a different host with IPv6. But this resulted in a lot of traffic.

root@nynaeve:~# tcpdump -nni eth0 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:36:29.233603 IP6 fe80::4:1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:8:4:5::1, length 32
14:36:29.234108 IP6 fe80::4:1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:8:4:f::1, length 32
14:36:29.234119 IP6 fe80::4:1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:8:4:4::1, length 32
14:36:29.234122 IP6 fe80::4:1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:8:4:e::1, length 32
14:36:29.234215 IP6 fe80::4:1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:8:4:c::1, length 32
14:36:29.234337 IP6 fe80::4:1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:8:4:1::1, length 32
14:36:29.250866 IP6 fe80::5054:ff:feac:88c2 > ff02::1:ffea:c8c5: ICMP6, neighbor solicitation, who has fe80::6600:6aff:feea:c8c5, length 32
14:36:29.683534 IP6 fe80::4:1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:8:4:1::1, length 32
14:36:29.683772 IP6 fe80::4:1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a01:8:4:6::1, length 32

With that much traffic it is hard to see which my ICMP6 packets are my ping packets. And since I can’t filter on IPv6 address. Because I don’t know which IPv6 address will be used. So I wanted to filter on ICMP6 echo request and reply packages.

root@nynaeve:~# tcpdump -nni eth0 icmp6[0]=128
tcpdump: IPv6 upper-layer protocol is not supported by proto[x]
root@nynaeve:~#

beep and “;stefan@chiad:~” written to the display when running screen on Fedora

2 minute read Modified:

What is the issue?

After a reboot of the system chiad (which runs fedora) I noticed a problem when I started a screen session. It gave a beep/bell and displayed the following:

;stefan@chiad:~[stefan@chiad ~]$
[stefan@chiad ~]$

The second line is there because I gave an enter and it shows what has been added to the first line. And when I logged out of the screen session it should show

;screen

I also noticed this only happend when I logged in via ssh from my console system. When logging in via ssh from a xterm didn’t give any problems. Also logging into a system running CentOS (kari) I didn’t have these issues.

What to search for?

The biggest disadvantage of using screen as a terminal multiplexer is that it is hard to search for on the internet, because a lot of things are screens, but not the GNU screen program. Because searching for a beep or bell doesn’t really make sense I tried searching for "linux screen ncurses background color not filling" because I also noticed that mutt and wyrd did not fill the background color when it supposed to. This search led me to some interesting URL’s.

Correct IP logging with sslh

2 minute read Modified:

Logging when using sslh

On a server I use sslh to allow ssh to port 443 and allow serving https sites at the same time. But when this is used, the logging for the TLS/SSL vhosts all show 127.0.0.1 as the source IP. This post will fix this problem

Needed changes

The original documentation mentioned the transparent mode, but when I tried to set it up on a test system it didn’t work. After searching I found a good article which works and does not need iptables configuration.

EdgeRouter: IPsec tunnel to FRITZ!Box 7390

3 minute read Modified:

Why an IPsec tunnel?

Previously I used a tinc tunnel between me and my parents’ server. This situation was not ideal because my parents’ server had to be the gateway for some things to be able to use them via the tunnel, while the FRITZ!Box was the real gateway. Since I wanted to replace my gateway with an EdgeRouter Lite, I used this to setup an IPsec tunnel with the FRITZ!Box.

EdgeRouter: merge error: SSL peer certificate or SSH remote key was not OK

3 minute read Modified:

merge does not work via scp

When I was testing something with my EdgeRouter Lite, I saw some command that might help me create a config outside the router itself and then load it. One of them was the merge command, so I tried to use it. The help information on the CLI was the following:

# merg<tab><tab>
Possible completions:
  merge         Load configuration from a file and merge running configuration
      
[edit]
# merge <tab>
Possible completions:
  <Enter>                               Merge from system config file
  <file>                                Merge from file on local machine
  scp://<user>:<passwd>@<host>/<file>   Merge from file on remote machine
  ftp://<user>:<passwd>@<host>/<file>   Merge from file on remote machine
  http://<host>/<file>                  Merge from file on remote machine
  tftp://<host>/<file>                  Merge from file on remote machine

      
[edit]
#
Recent posts
- full list -