Skip to content

Blog

  • 7 min read

systemd vs. syslog on Debian

This was originally posted on blogger here.

I got pissed off by yet another systemd weirdness: My logfiles (generated by rsyslog) /var/log/daemon.log got flooded with shit like this:

Sep  1 13:35:36 lux systemd[13644]: Starting Paths.
Sep  1 13:35:36 lux systemd[13644]: Reached target Paths.
Sep  1 13:35:36 lux systemd[13644]: Starting Timers.
Sep  1 13:35:36 lux systemd[13644]: Reached target Timers.
Sep  1 13:35:36 lux systemd[13644]: Starting Sockets.
Sep  1 13:35:36 lux systemd[13644]: Reached target Sockets.
Sep  1 13:35:36 lux systemd[13644]: Starting Basic System.
Sep  1 13:35:36 lux systemd[13644]: Reached target Basic System.
Sep  1 13:35:36 lux systemd[13644]: Starting Default.
Sep  1 13:35:36 lux systemd[13644]: Reached target Default.
Sep  1 13:35:36 lux systemd[13644]: Startup finished in 13ms.
Sep  1 13:35:37 lux systemd[13644]: Stopping Default.
Sep  1 13:35:37 lux systemd[13644]: Stopped target Default.
Sep  1 13:35:37 lux systemd[13644]: Stopping Basic System.
Sep  1 13:35:37 lux systemd[13644]: Stopped target Basic System.
Sep  1 13:35:37 lux systemd[13644]: Stopping Paths.
Sep  1 13:35:37 lux systemd[13644]: Stopped target Paths.
Sep  1 13:35:37 lux systemd[13644]: Stopping Timers.
Sep  1 13:35:37 lux systemd[13644]: Stopped target Timers.
Sep  1 13:35:37 lux systemd[13644]: Stopping Sockets.
Sep  1 13:35:37 lux systemd[13644]: Stopped target Sockets.
Sep  1 13:35:37 lux systemd[13644]: Starting Shutdown.
Sep  1 13:35:37 lux systemd[13644]: Reached target Shutdown.
Sep  1 13:35:37 lux systemd[13644]: Starting Exit the Session...
Sep  1 13:35:37 lux systemd[13644]: Received SIGRTMIN+24 from PID 13654 (kill).
Sep  1 13:35:37 lux systemd[13666]: Starting Paths.
Sep  1 13:35:37 lux systemd[13666]: Reached target Paths.
Sep  1 13:35:37 lux systemd[13666]: Starting Timers.
Sep  1 13:35:37 lux systemd[13666]: Reached target Timers.
Sep  1 13:35:37 lux systemd[13666]: Starting Sockets.
Sep  1 13:35:37 lux systemd[13666]: Reached target Sockets.
Sep  1 13:35:37 lux systemd[13666]: Starting Basic System.
Sep  1 13:35:37 lux systemd[13666]: Reached target Basic System.
Sep  1 13:35:37 lux systemd[13666]: Starting Default.
Sep  1 13:35:37 lux systemd[13666]: Reached target Default.
Sep  1 13:35:37 lux systemd[13666]: Startup finished in 8ms.
Sep  1 13:35:37 lux systemd[13666]: Stopping Default.
Sep  1 13:35:37 lux systemd[13666]: Stopped target Default.
Sep  1 13:35:37 lux systemd[13666]: Stopping Basic System.
Sep  1 13:35:37 lux systemd[13666]: Stopped target Basic System.
Sep  1 13:35:37 lux systemd[13666]: Stopping Paths.
Sep  1 13:35:37 lux systemd[13666]: Stopped target Paths.
Sep  1 13:35:37 lux systemd[13666]: Stopping Timers.
Sep  1 13:35:37 lux systemd[13666]: Stopped target Timers.
Sep  1 13:35:37 lux systemd[13666]: Stopping Sockets.
Sep  1 13:35:37 lux systemd[13666]: Stopped target Sockets.
Sep  1 13:35:37 lux systemd[13666]: Starting Shutdown.
Sep  1 13:35:37 lux systemd[13666]: Reached target Shutdown.
Sep  1 13:35:37 lux systemd[13666]: Starting Exit the Session...
Sep  1 13:35:37 lux systemd[13666]: Received SIGRTMIN+24 from PID 13685 (kill).
Sep  1 13:35:37 lux systemd[13705]: Starting Paths.
Sep  1 13:35:37 lux systemd[13705]: Reached target Paths.
Sep  1 13:35:37 lux systemd[13705]: Starting Timers.
Sep  1 13:35:37 lux systemd[13705]: Reached target Timers.
Sep  1 13:35:37 lux systemd[13705]: Starting Sockets.
Sep  1 13:35:37 lux systemd[13705]: Reached target Sockets.
Sep  1 13:35:37 lux systemd[13705]: Starting Basic System.
Sep  1 13:35:37 lux systemd[13705]: Reached target Basic System.
Sep  1 13:35:37 lux systemd[13705]: Starting Default.
Sep  1 13:35:37 lux systemd[13705]: Reached target Default.
Sep  1 13:35:37 lux systemd[13705]: Startup finished in 8ms.
Sep  1 13:35:38 lux systemd[13705]: Stopping Default.
Sep  1 13:35:38 lux systemd[13705]: Stopped target Default.
Sep  1 13:35:38 lux systemd[13705]: Stopping Basic System.
Sep  1 13:35:38 lux systemd[13705]: Stopped target Basic System.
Sep  1 13:35:38 lux systemd[13705]: Stopping Paths.
Sep  1 13:35:38 lux systemd[13705]: Stopped target Paths.
Sep  1 13:35:38 lux systemd[13705]: Stopping Timers.
Sep  1 13:35:38 lux systemd[13705]: Stopped target Timers.
Sep  1 13:35:38 lux systemd[13705]: Stopping Sockets.
Sep  1 13:35:38 lux systemd[13705]: Stopped target Sockets.
Sep  1 13:35:38 lux systemd[13705]: Starting Shutdown.
Sep  1 13:35:38 lux systemd[13705]: Reached target Shutdown.
Sep  1 13:35:38 lux systemd[13705]: Starting Exit the Session...
Sep  1 13:35:38 lux systemd[13705]: Received SIGRTMIN+24 from PID 13714 (kill).
Sep  1 13:35:38 lux systemd[13742]: Starting Paths.
Sep  1 13:35:38 lux systemd[13742]: Reached target Paths.
Sep  1 13:35:38 lux systemd[13742]: Starting Timers.
Sep  1 13:35:38 lux systemd[13742]: Reached target Timers.
Sep  1 13:35:38 lux systemd[13742]: Starting Sockets.
Sep  1 13:35:38 lux systemd[13742]: Reached target Sockets.
Sep  1 13:35:38 lux systemd[13742]: Starting Basic System.
Sep  1 13:35:38 lux systemd[13742]: Reached target Basic System.
Sep  1 13:35:38 lux systemd[13742]: Starting Default.
Sep  1 13:35:38 lux systemd[13742]: Reached target Default.
Sep  1 13:35:38 lux systemd[13742]: Startup finished in 14ms.
Sep  1 13:35:38 lux systemd[13742]: Stopping Default.
Sep  1 13:35:38 lux systemd[13742]: Stopped target Default.
Sep  1 13:35:38 lux systemd[13742]: Stopping Basic System.
Sep  1 13:35:38 lux systemd[13742]: Stopped target Basic System.
Sep  1 13:35:38 lux systemd[13742]: Stopping Paths.
Sep  1 13:35:38 lux systemd[13742]: Stopped target Paths.
Sep  1 13:35:38 lux systemd[13742]: Stopping Timers.
Sep  1 13:35:38 lux systemd[13742]: Stopped target Timers.
Sep  1 13:35:38 lux systemd[13742]: Stopping Sockets.
Sep  1 13:35:38 lux systemd[13742]: Stopped target Sockets.
Sep  1 13:35:38 lux systemd[13742]: Starting Shutdown.
Sep  1 13:35:38 lux systemd[13742]: Reached target Shutdown.
Sep  1 13:35:38 lux systemd[13742]: Starting Exit the Session...
Sep  1 13:35:38 lux systemd[13742]: Received SIGRTMIN+24 from PID 13753 (kill).
Sep  1 13:35:39 lux systemd[13779]: Starting Paths.
Sep  1 13:35:39 lux systemd[13779]: Reached target Paths.
Sep  1 13:35:39 lux systemd[13779]: Starting Timers.
Sep  1 13:35:39 lux systemd[13779]: Reached target Timers.
Sep  1 13:35:39 lux systemd[13779]: Starting Sockets.
Sep  1 13:35:39 lux systemd[13779]: Reached target Sockets.
Sep  1 13:35:39 lux systemd[13779]: Starting Basic System.
Sep  1 13:35:39 lux systemd[13779]: Reached target Basic System.
Sep  1 13:35:39 lux systemd[13779]: Starting Default.
Sep  1 13:35:39 lux systemd[13779]: Reached target Default.
Sep  1 13:35:39 lux systemd[13779]: Startup finished in 14ms.
Sep  1 13:35:39 lux systemd[13779]: Stopping Default.
Sep  1 13:35:39 lux systemd[13779]: Stopped target Default.
Sep  1 13:35:39 lux systemd[13779]: Stopping Basic System.
Sep  1 13:35:39 lux systemd[13779]: Stopped target Basic System.
Sep  1 13:35:39 lux systemd[13779]: Stopping Paths.
Sep  1 13:35:39 lux systemd[13779]: Stopped target Paths.
Sep  1 13:35:39 lux systemd[13779]: Stopping Timers.
Sep  1 13:35:39 lux systemd[13779]: Stopped target Timers.
Sep  1 13:35:39 lux systemd[13779]: Stopping Sockets.
Sep  1 13:35:39 lux systemd[13779]: Stopped target Sockets.
Sep  1 13:35:39 lux systemd[13779]: Starting Shutdown.
Sep  1 13:35:39 lux systemd[13779]: Reached target Shutdown.
Sep  1 13:35:39 lux systemd[13779]: Starting Exit the Session...
Sep  1 13:35:39 lux systemd[13779]: Received SIGRTMIN+24 from PID 13788 (kill).


What the * is that? What the hell does it mean? I googled a bit but after reading few meaningless discussion like A: "What does it mean? Is it serious? How do I get rid of this". B: "It is for your own good. Suffer and be silent." I got finally an impression that it is harmless and it simple means that systemd mothe*er somehow help to log-in and log-out users and it does something(?) with processes that get started by cron.

Then I came across some RHEL/Fedora bug report where even Lennart Poettering posted his "Won'tfix! It's for your own good. Resistance is futile, keep you mouth shut and suffer with systemd." Somebody called him an idiot in response. :-)

Anyway, the problem occurred only on Debian systems that have been upgraded from Wheezy to Jessie, but not on freshly installed Jessies. So I compared configuration and the difference that... well, it made the difference, was:

session        optional        pam_systemd.so


line in /etc/pam.d/common-session . I just commented it out and the shitload of annoying log messages stopped.

1 comments captured from original post on Blogger

Elijah Jericho said on 2016-04-20

Thanks for that :)

  • 3 min read

mgetty in systemd for modem dial-in server

This was originally posted on blogger here.

I used to have a modem dial-in server as an out-of-band management for key network elements. The idea was to call the server over the GSM from another place with minicom, connect to the terminal of the server and then use another serial consoles that was connected from the server to routers, switches etc...

So far so good, I used to have a simple /etc/inittab line like this:

T3:23:respawn:/sbin/mgetty -D -s 115200 ttyS0


But... The ****ing almighty systemd came to create hell on earth for Linux users... No /etc/inittab anymore, no nothing. Well, UTFG, so I get completely wrong advice to try:

# systemctl start getty@ttyS0.service


And that's it... (?) No, it isn't! It simply does not accept the call, because it uses agetty and agetty can't do that or it is not configured or whatever.

After one particularly hot, unpleasant and exhausting afternoon spent on experimenting with this I came to following config for systemd that works for me (place it to /etc/systemd/system/mgetty.service):

[Unit]
Description=Smart Modem Getty(mgetty)
Documentation=man:mgetty(8)
Requires=systemd-udev-settle.service
After=systemd-udev-settle.service

[Service]
Type=simple
ExecStart=/sbin/mgetty -D -s 115200 /dev/ttyS0
Restart=always
PIDFile=/var/run/mgetty.pid.ttyS0

[Install]
WantedBy=multi-user.target


And of course:

# systemctl start mgetty.service
# systemctl enable mgetty.service


I hate systemd! I really do. But I'll learn about it. It has spread to all reasonable distros like a nasty infection so we have to learn living with it, I guess.

5 comments captured from original post on Blogger

Unknown said on 2015-08-21

Thanks. Finally surrendered to systemd since it seemed inevitable, and needed my trusty faxmodem still receiving for legal documents.

Unknown said on 2018-07-20

I didn't fully understand this ...
(still reeling from the systemd crap)

I created a directory entry:

serial-getty@ttyUSB0.service.d

much like the one I created for ttyS0 where my terminal is, but the modem just keeps running. It's treating the modem like a terminal.

How did you specify that it use mgetty instead of agetty?

Sorry ... still trying to grasp this.

/etc/inittab was soooooo much easier!

-rAllcorn-

Rich Allcorn said on 2018-08-10

After reviewing this, I have come to the conclusion that "YOU SIR" are the ONLY ONE who ever explained this on how to do with a "systemd infected system".

THANK YOU SO VERY MUCH!!!!


I am copying the file I created, to make things simple, and to honor YOUR labors ... again, I thank you!!

(see following post)

Rich Allcorn said on 2018-08-10

/etc/systemd/system/mgetty.service
#
# credit for creating this goes to:
# "Snarky Brill", who posted a guide that helped me to create this one
#
# see URL:
# https://snarkybrill.blogspot.com/2015/08/mgetty-in-systemd-for-modem-dial-in.html?showComment=1533868591623#c3913812844269156303
#
#
# This file enables model dial-in services using mgetty for ttyUSB0
# where the modem resides on my system.
#
# You can tailor this for whatever serial port your modem may reside
#
#
# Copy this file to: /etc/systemd/system

[Unit]
Description=Smart Modem Getty(mgetty)
Documentation=man:mgetty(8)
Requires=systemd-udev-settle.service
After=systemd-udev-settle.service

[Service]
Type=simple
ExecStart=/sbin/mgetty -D -s 38400 /dev/ttyUSB0
Restart=always
PIDFile=/var/run/mgetty.pid.ttyUSB0

[Install]
WantedBy=multi-user.target


# Don't forget to run the following commands:
#
#
# $ sudo systemctl start mgetty.service
# $ sudo systemctl enable mgetty.service
#
#
# ... after copying the file to /etc/systemd/system/
#

Unknown said on 2018-12-13

Thank you very much.

I am the author of mgetty, but I stopped using Linux a while ago due to systemd plague - and today I needed to install mgetty on a customer's Ubuntu system. Which brought a nice precompiled package, but NO UNIT FILE...

Now I have one, thanks to your blog :-)

  • 2 min read

Debian's driver for Intel GPUs is s***

This was originally posted on blogger here.

After a few years spent with Ubuntu and Linux Mint I decided to give Debian Jessie a try this week. And I have to admit that I also wanted to see systemd in action just to assess it myself and see whether it has some potential to do something good or otherwise.

But the Debian Jessie with either Cinnamon or Mate desktop was unusable on my ThinkPad X301. The graphics was sluggish. Even video playback in VLC was apparently loosing one third of frames even in lower quality movies. The mouse wheel on external USB mouse was lagging. Keyboard has visible lag behind key press and the letter being inserted to terminal/text editor/whatever. The experience was really horrible. Wtf?

Well, I suspected the Cinnamon desktop that I installed in the first place. I thought that it might eat up CPU and put too much strain on GPU. This assumption proved wrong. So the problem was apparently somwhere in XOrg. Sluggish video and lagging inputs worried me because how one problem could possibly cause that. Well, it is possible in the XOrg because one driver can slow down the whole thing and cause problems even in other subsystems.

After a few hours tuning this and that I checked the version of the Intel driver and... Well, the driver is old deprecated ***. And it is present in all current Debian versions (stable... that's a joke:-) ), testing (which is freezed so it is going to be "stable", LOL), and unstable (at least the name suggest that it does not work properly, which is completely true).

This blog post explains everything: http://blogs.fsfe.org/the_unconventional/2014/11/12/debian-x-drivers/

Just for reference: That's what I have.

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
 Subsystem: Lenovo Device 20e4
 Flags: bus master, fast devsel, latency 0, IRQ 47
 Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
 Memory at d0000000 (64-bit, prefetchable) [size=256M]
 I/O ports at 1800 [size=8]
 Expansion ROM at  [disabled]
 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
 Capabilities: [d0] Power Management version 3
 Kernel driver in use: i915


And my solution was: 

echo "deb http://ftp.debian.org/debian experimental main" >> /etc/apt/sources.list
apt-get update
apt-get -t experimental install xserver-xorg-video-intel
  • 3 min read

OpenHantek udev rulez

This was originally posted on blogger here.

I have a small and cheap Hantek DSO-2090 USB oscilloscope... And, well, the HW is old, cheap Chinese box that looks extremely ugly. I have not enough bravery to look inside but I do not hope for anything good. But it was cheap enough and when I was moving I really needed to get rid of my old Russian 15 kg, 0.5 cubic meter CRT oscilloscope so I decided to buy this one. It was conscious choice and it works for me pretty well since I am doing only basic electronic measurements here.

But I migrated to a newer Debian system so I had to rebuild my OpenHantek SW, which was pretty painless. Many thanks to the author of this blog post: http://verahill.blogspot.cz/2012/12/298-hantek-dso-2250-usb-with-openhantek.html

But there were still a problem with udev that failed to change group and access rights to the /dev/bus/usb/... file, so I was unable to use OpenHantek as an ordinary user. The solution is obvious, the old udev rule file used SYSFS instead of ATTR. This is my working version:


# Hantek DSO-2090
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/2090/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso2090-firmware.hex -s /usr/local/share/hantek/dso2090-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="04b5", ATTR{idProduct}=="2090", MODE="0660", GROUP="plugdev"

# Hantek DSO-2100
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="547/1006/*", RUN+="/sbin/fxload -t an21 -I /usr/local/share/hantek/dso2100-firmware.hex -s /usr/local/share/hantek/dso2100-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="0547", ATTR{idProduct}=="1002", MODE="0660", GROUP="plugdev"

# Hantek DSO-2150
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/2150/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso2150-firmware.hex -s /usr/local/share/hantek/dso2150-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="04b5", ATTR{idProduct}=="2150", MODE="0660", GROUP="plugdev"

# Hantek DSO-2250
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/2250/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso2250-firmware.hex -s /usr/local/share/hantek/dso2250-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="04b5", ATTR{idProduct}=="2250", MODE="0660", GROUP="plugdev"

# Hantek DSO-5200
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/5200/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso5200-firmware.hex -s /usr/local/share/hantek/dso5200-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="04b5", ATTR{idProduct}=="5200", MODE="0660", GROUP="plugdev"

# Hantek DSO-5200A
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/520A/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso520a-firmware.hex -s /usr/local/share/hantek/dso520a-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="04b5", ATTR{idProduct}=="520A", MODE="0660", GROUP="plugdev"


Assuming the path to the *.hex file generated by the openhantek-extractfw is /usr/local/share/hantek .

2 comments captured from original post on Blogger

partinis said on 2018-02-09

Hello,

I have just tried it and have exactly the same problem as described by Mladen on https://sourceforge.net/p/openhantek/discussion/1153137/thread/d4f2beda/.


Please do you have any suggestions to solve it?


My device:

ID 0547:1006 Anchor Chips, Inc. Hantek DSO-2100 UF

ID 0547:1002 Anchor Chips, Inc. Python2 WDM Encoder (after loading firmware with fxload)


Using following sources I was able to achieve best results ever (Scope is detected and relay clicks are hearable)

http://svn.code.sf.net/p/openhantek/code/trunk


I have also tried:

https://github.com/OpenHantek/openhantek

http://verahill.blogspot.de/2012/12/298-hantek-dso-2250-usb-with-openhantek.html

However without any success…


Regards,
partinis

Tomas Hlavacek said on 2018-02-09

I suggest you to ask on GitHub (create issue in OpenHantek project perhaps). It seems that developer is unexpectedly helpful, responds quickly and tries to solve your problems.

I know, unfortunately just my version (DSO-2090) and is works out of box with current OpenHantek cloned from GitHub.

  • 2 min read

Smokeping s*y madness

This was originally posted on blogger here.

So once again I have been hit by an insane portion of weird, flawed and inherently unreliable design in Smokeping.

What the **** is Smokeping? Well, it is an utility for measuring and graphing latency in network. It should be pretty straight-forward to use. You configure IP addresses and names of boxes to monitor and that't it? Well, not so fast... It is a bit poxy because it is Perl after all. You need some modules, you need to have multiple configuration files, you have to configure probes, bind them to targets, modify arguments for probes in target configs etc. There is quite a lot of how-to's for this and in fact it works almost out of box on most distributions.

But... The Smokeping beast has also a slave mode. Which means: You have one master that holds configurations and it performs measurements and it generate graphs, everything is the same as in standalone mode. But it also commands slaves to perform the same measurements and report results so the master saves the results to .rrd files and it create graphs.

This communication with slaves is performed by CGI in the Smokeping webroot. And here comes the problem: Privileges.

When Smokeping runs as a daemon it is executed under smokeping user, at least on Debian. So all files that it stores (on Debian usually these files end up in /var/lib/smokeping) have smokeping:smokeping user and group and privileges 644. That works for daemon to store data and for CGIs to read them.

But if you need CGIs to store data from slaves, it is not enough. The Smokeping (daemon perhaps?) creates proper .rrd files for the remote measurements from slaves, but these files are updated, so no data in are being displayed in graphs.

Solution:

chmod -R g+w /var/lib/smokeping
  • 2 min read

Flaw in common network design pattern (or in understanding how to use it)?

This was originally posted on blogger here.

There is an old and not-so-clever network design pattern like this:



I know this from CCN(A|P) but I have no idea who invented it. Cisco perhaps. Idea is to use IGP, nowadays it is naturally OSPF in most cases, for resolution of the L3 path towards a subnet in question. The subnet itself is terminated on a gateway. Two different gateways to be accurate. One acts as a default gateway, which means that it is active router in HSRP, so it holds "virtual" IP address as well as MAC address of the default gateway. It is the address that hosts in the subnet uses in their routing tables and subsequently in their ARP tables.

So far so good. Everything is up and running, one gateway is active, another one passive, both routers are redistributing connected routes to OSPF and both are able to deliver traffic from L3 networks towards clients in the L2 subnet in question.

But wait a moment... How do L3 switches know where to send the traffic over L2? Yes, routing table and ARP resolution. By default the ARP table records timeout is 4 hrs, right?

And how do L2 switches know the port to forward traffic? MAC address table (or switching table, depends on terminology). Timeout for MAC address table? 5 mins.

So what does the passive switch do when no traffic from hosts hits this switch, because it does not have active default GW address and nobody wants to communicate over L2 to it's "real IP". Well, obviously the MAC address table cleans out after a while but ARP records stays much much longer (and ARP records are refreshed when some traffic arrives and the L3 switch does not have proper ARP table records).

But... When there is no MAC address table record for the particular MAC on the standby L3 switch, the switch just broadcasts the traffic for that MAC to all ports. And it multiplies in the network further because in case you have prevailing vertical flows in your network it is likely that any other L2 switch in the chain does not know the MAC address either. Except the one which has the destination host connected. So it means you might have huge multiplication of useless traffic if your L3 switch attracts some traffic in OSPF for any subnet which it is standby for it's gateway.

It might several megs or even tens or hundred megs of constant scattered traffic in real life scenario in 1 Gig network.

And what to do to avoid this? Think of the design pattern... Set higher OSPF costs for redistributed routes on the standby router. Simple but effective, huh?

  • 5 min read

USB device ID 0bdb:1926 Ericsson Business Mobile Networks BV stopped working after update Linux Mint 14 to 15

This was originally posted on blogger here.

I tried to upgrade Linux Mint on my laptop from Linux Mint 14 (Nadia) to 15 (Olivia). And suddenly GSM/3G modem that I am using to connect to one Czech mobile ISP stopped working.

The problem was that the connecting to the network timed out each time. And there was no apparent reason in /var/log/syslog apart from that DHCP did not received a reply from the ISP:

May 26 02:31:58 tapir modem-manager[13636]:   (ttyACM2) opening serial port...
May 26 02:31:58 tapir modem-manager[13636]:   (ttyACM1): using PDU mode for SMS
May 26 02:31:58 tapir modem-manager[13636]:   Modem /org/freedesktop/ModemManager/Modems/0: state changed (enabling -> enabled)
May 26 02:31:58 tapir NetworkManager[13638]:  WWAN now enabled by management service
May 26 02:31:59 tapir modem-manager[13636]:   Modem /org/freedesktop/ModemManager/Modems/0: state changed (enabled -> searching)
May 26 02:32:02 tapir modem-manager[13636]:   Modem /org/freedesktop/ModemManager/Modems/0: state changed (searching -> registered)
May 26 02:32:42 tapir NetworkManager[13638]:  Activation (wwan0) starting connection 'T-Mobile Default'
May 26 02:32:42 tapir NetworkManager[13638]:  (wwan0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
May 26 02:32:42 tapir NetworkManager[13638]:  Activation (wwan0) Stage 1 of 5 (Device Prepare) scheduled...
May 26 02:32:42 tapir NetworkManager[13638]:  Activation (wwan0) Stage 1 of 5 (Device Prepare) started...
May 26 02:32:42 tapir NetworkManager[13638]:  Activation (wwan0) Stage 1 of 5 (Device Prepare) complete.
May 26 02:32:42 tapir modem-manager[13636]:   Modem /org/freedesktop/ModemManager/Modems/0: state changed (registered -> connecting)
May 26 02:32:44 tapir modem-manager[13636]:   Modem /org/freedesktop/ModemManager/Modems/0: state changed (connecting -> connected)
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Stage 2 of 5 (Device Configure) scheduled...
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Stage 2 of 5 (Device Configure) starting...
May 26 02:32:44 tapir NetworkManager[13638]:  (wwan0): device state change: prepare -> config (reason 'none') [40 50 0]
May 26 02:32:44 tapir NetworkManager[13638]:  (wwan0): bringing up device.
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Stage 2 of 5 (Device Configure) successful.
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Stage 3 of 5 (IP Configure Start) scheduled.
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Stage 2 of 5 (Device Configure) complete.
May 26 02:32:44 tapir avahi-daemon[657]: Joining mDNS multicast group on interface wwan0.IPv6 with address fe80::dcc9:44ff:fe89:56fc.
May 26 02:32:44 tapir avahi-daemon[657]: New relevant interface wwan0.IPv6 for mDNS.
May 26 02:32:44 tapir avahi-daemon[657]: Registering new address record for fe80::dcc9:44ff:fe89:56fc on wwan0.*.
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Stage 3 of 5 (IP Configure Start) started...
May 26 02:32:44 tapir NetworkManager[13638]:  (wwan0): device state change: config -> ip-config (reason 'none') [50 70 0]
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Beginning DHCPv4 transaction (timeout in 45 seconds)
May 26 02:32:44 tapir NetworkManager[13638]:  dhclient started with pid 13689
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Stage 4 of 5 (IPv6 Configure Timeout) scheduled...
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Stage 3 of 5 (IP Configure Start) complete.
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Stage 4 of 5 (IPv6 Configure Timeout) started...
May 26 02:32:44 tapir NetworkManager[13638]:  Activation (wwan0) Stage 4 of 5 (IPv6 Configure Timeout) complete.
May 26 02:32:44 tapir dhclient: Internet Systems Consortium DHCP Client 4.2.4
May 26 02:32:44 tapir dhclient: Copyright 2004-2012 Internet Systems Consortium.
May 26 02:32:44 tapir dhclient: All rights reserved.
May 26 02:32:44 tapir dhclient: For info, please visit https://www.isc.org/software/dhcp/
May 26 02:32:44 tapir dhclient: 
May 26 02:32:44 tapir NetworkManager[13638]:  (wwan0): DHCPv4 state changed nbi -> preinit
May 26 02:32:44 tapir dhclient: Listening on LPF/wwan0/de:c9:44:89:56:fc
May 26 02:32:44 tapir dhclient: Sending on   LPF/wwan0/de:c9:44:89:56:fc
May 26 02:32:44 tapir dhclient: Sending on   Socket/fallback
May 26 02:32:44 tapir dhclient: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 3 (xid=0x40900a61)
May 26 02:32:47 tapir dhclient: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 8 (xid=0x40900a61)
May 26 02:32:55 tapir dhclient: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 13 (xid=0x40900a61)
ay 26 02:33:08 tapir dhclient: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 7 (xid=0x40900a61)
May 26 02:33:15 tapir dhclient: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 13 (xid=0x40900a61)
May 26 02:33:28 tapir dhclient: DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 20 (xid=0x40900a61)
May 26 02:33:29 tapir NetworkManager[13638]:  (wwan0): DHCPv4 request timed out.
May 26 02:33:29 tapir NetworkManager[13638]:  (wwan0): canceled DHCP transaction, DHCP client pid 13689
May 26 02:33:29 tapir NetworkManager[13638]:  Activation (wwan0) Stage 4 of 5 (IPv4 Configure Timeout) scheduled...
May 26 02:33:29 tapir NetworkManager[13638]:  Activation (wwan0) Stage 4 of 5 (IPv4 Configure Timeout) started...
May 26 02:33:29 tapir NetworkManager[13638]:  (wwan0): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]
May 26 02:33:29 tapir NetworkManager[13638]:  Activation (wwan0) failed for connection 'T-Mobile Default'
May 26 02:33:29 tapir NetworkManager[13638]:  Activation (wwan0) Stage 4 of 5 (IPv4 Configure Timeout) complete.
May 26 02:33:29 tapir modem-manager[13636]:   Modem /org/freedesktop/ModemManager/Modems/0: state changed (connected -> disconnecting)
May 26 02:33:29 tapir NetworkManager[13638]:  (wwan0): device state change: failed -> disconnected (reason 'none') [120 30 0]
May 26 02:33:29 tapir NetworkManager[13638]:  (wwan0): deactivating device (reason 'none') [0]
May 26 02:33:29 tapir avahi-daemon[657]: Interface wwan0.IPv6 no longer relevant for mDNS.
May 26 02:33:29 tapir avahi-daemon[657]: Leaving mDNS multicast group on interface wwan0.IPv6 with address fe80::dcc9:44ff:fe89:56fc.
May 26 02:33:29 tapir avahi-daemon[657]: Withdrawing address record for fe80::dcc9:44ff:fe89:56fc on wwan0.
May 26 02:33:29 tapir modem-manager[13636]:   Modem /org/freedesktop/ModemManager/Modems/0: state changed (disconnecting -> registered)


WTF?! I have asked myself?

After some time spent with the change-logs, debugging and asking google I have found this: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1172178

So it seems there is another pile of code in Linux kernel that aims to standardize some drivers and set common APIs, but it breaks things in meantime. Why it is always me who have to suffer this?:-)

Advice from Oleg Cherkasov at the end of the ticked worked for me. Thanks!

  • 1 min read

Shameful spyware in Smooth Gestures

This was originally posted on blogger here.

Once again there was an ugly shameful and disgusting breach of what modern computing with OSS stands for. The Smooth Gestures extension to Chromium / Google Chrome was mucked with spyware which reports all the browsing actions to the creator of the extension.

Look here: http://codeonfire.cthru.biz/?p=96

I personally used the extension so I was a bit upset when it disappeared from Chrome Market but a bit of googling was enough to wake up. It said: What the ****?!

Anyway I hunted for some replacement which wasn't that easy... But I have found one: Recognize it for Chrome - https://chrome.google.com/webstore/detail/recognize-it-for-chrome/bclaagbljldlbmihblajinlijckggkea

1 comments captured from original post on Blogger

mwj said on 2014-01-21

thanks - i hated SG's adware - thanks for the replacement tip!

  • 1 min read

OpenWRT insanity, shame and ignorancy

This was originally posted on blogger here.

I have been hit by a idiotic, unreasonable, insane and stupid setting in OpenWRT:

/etc/sysctl.conf:

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=3600


Well what does it mean? Simple thing: Every long-lasting connections breaks after one hour. No matter whether I have TCP keepalive on, because TCP keepalive timeout defaults to 7200 seconds.

In practice you will see this:

brill@tapir ~ $ ssh milhouse.backbone.ignum.cz
Linux milhouse 2.6.32-5-amd64 #1 SMP Wed May 18 23:13:22 UTC 2011 x86_64

Keep keep your hands off this server!
Nikdo tu na nic nesahejte!

Last login: Sun Dec 30 00:46:47 2012 from 89.177.24.237
<no activity for more than 1 hour>
brill@milhouse:~$ Write failed: Broken pipe

brill@tapir ~ $


There was a flame on this topic on OpenWRT forum:

https://dev.openwrt.org/ticket/5777

And the result is: invalid, wontfix, *yourself.

Mother*ers. They break everything. God... You can sacrifice filesystem, give up serial port, GPIO, LED diodes, whatever, but keep firewall working normally when you are building network appliance you idiots!

  • 1 min read

Buggy Xfce xkb applet looses keyboard layout config

This was originally posted on blogger here.

I have been hit by a nasty Xfce xkb applet bug, which is widely known in several bloody bugzillas (of RH/CentOS, Ubuntu, Debian,...) but it seems unresolved yet. The backround of the bug is, that the applet looses it's configuration, especially configured keyboard layouts and shortcut for switching them while for while which may seem to be random or it may seem to have some coincidence with suspending/wakeups of the computer. Well it is not random, it resolves to connections and disconnections of external (or even internal) USB keyboard, which may of course be triggered by suspend/wakeup.

So it seems I have the reason isolated. Now what is the solution? Well the applet is part of so-called Xfce-goodies, which is sort of external project. I did not find corresponding bugzilla nor some mailinglist etc. But I think that author is perhaps aware of this behavior, so there is no need to shout at him. But I needed the workaround and I think I have found one. It is simple and it is Linux-like: Just configure all your keyboards in xorg.xonf file in InputClass section and then use the applet as an indicator and switcher.

I am using following snippet of xorg.conf on my ThinkPad X301 which I am connecting and disconnecting to a USB keyboard:

Section "InputClass"
    Identifier "keyboard defaults"
    MatchIsKeyboard "on"
    Option "XkbLayout" "us, cz"
    Option "XkbVariant" ", qwerty_bksl"
    Option "XKbOptions" "grp:alt_shift_toggle, terminate:ctrl_alt_bksp"
EndSection