Category Archives: Linux

EDID Reading on Arch Linux

There are several tools to read the Extended Display Identification Data, EDID, from systems but I found LinuxTV’s edid-decode the most thorough when debugging for a linux 5.0.x display boot flicking problem.

On arch I ran installed edid-decode-git and then ran a quick script:

for f in `find /sys/devices -name 'edid'`; do sudo cat $f| edid-decode;done

and I got something like:

EDID version: 1.4
Manufacturer: BOE Model 65a Serial Number 0
Made in week 1 of 2015
Digital display
6 bits per primary color channel
DisplayPort interface
Maximum image size: 34 cm x 19 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing includes the native pixel format and preferred refresh rate
Display x,y Chromaticity:
  Red:   0.6416, 0.3437
  Green: 0.3183, 0.6103
  Blue:  0.1494, 0.0439
  White: 0.3125, 0.3281
Established timings supported:
Standard timings supported:
Detailed mode: Clock 139.770 MHz, 344 mm x 194 mm
               1920 1968 2000 2080 hborder 0
               1080 1083 1089 1120 vborder 0
               +hsync -vsync 
               VertFreq: 59 Hz, HorFreq: 67197 Hz
Detailed mode: Clock 111.820 MHz, 344 mm x 194 mm
               1920 1968 2000 2080 hborder 0
               1080 1083 1089 1120 vborder 0
               +hsync -vsync 
               VertFreq: 47 Hz, HorFreq: 53759 Hz
ASCII string: J125V
Manufacturer-specified data, tag 0
Checksum: 0xa9 (valid)

This helped when trying to diagnose: black screen on Dell XPS 15 with kernel 5.0 and Bug 109959 – REGRESSION: black screen with linux 5.0 when starting X

Linux Client VPN using Meraki Cloud Controller authentication

If you want to VPN into your network using the Meraki Cloud Controller the Client VPN Instructions indicate that you may be out of luck when trying to use xl2tp.

Note: The xl2tp package does not send user credentials properly to the MX when using Meraki Cloud Controller authentication, and this causes the authentication request to fail. Active Directory or RADIUS authentication can be used instead for successful authentication.
Note: The xl2tp package does not send user credentials properly to the MX when using Meraki Cloud Controller authentication, and this causes the authentication request to fail. Active Directory or RADIUS authentication can be used instead for successful authentication.

It turns out that if you setup the IPSEC phase1 and phase2 algorithms then it’ll work.

It took some googling to bring it all around but combined with the Project network-manager-l2tp Github issue 34 of  “IPSec options hard coded” and the Ubuntu question “L2tp IPSEC PSK VPN client on (x)ubuntu 16.04“, I found that setting IPSEC Phase1 Algorithms to 3des-sha1-modp1024 and Phase2 Algorithms to 3des-sha1 works.

Phase1 Algorithms: 3des-sha1-modp1024 Phase2 Algorithms: 3des-sha1
Phase1 Algorithms: 3des-sha1-modp1024 Phase2 Algorithms: 3des-sha1

Now I can connect to the VPN no problem. On Arch Linux!