2020-11-25 add news item about cable extension to Copenhagen, add Bulk data center blog link 2019-06-04 add details of Bulk data center in Esbjerg and infrastructure, add local news items about construction start 2019-05-08 add system summary from FCC application, elaborate on landing point discrepancies between FCC/cablemap, link to docs describing seg. 5 cable lay schedule 2019-03-06 fix links to submarinecablemap.com and some press, add info from TE Subcom experience doc., some general touch ups 2019-01-22 change “Danish Press Coverage” to “National Press”, add “International Press”, add some National about datacenter prospects & International Press items about contractors choosen 2018-10-05 initial commit
Europe, Denmark and my local neighbourhood of Western Jutland is going to get its connectivity boosted by the Havfrue transatlantic cable system being built by a consortium consisting of Google, Facebook, Aqua Comms and Bulk Infrastructure. To quote the announcement done by Google;
To increase capacity and resiliency in our North Atlantic systems, we’re working with Facebook, Aqua Comms and Bulk Infrastructure to build a direct submarine cable system connecting the U.S. to Denmark and Ireland. This cable, called Havfrue (Danish for “mermaid”), will be built by TE SubCom and is expected to come online by the end of 2019. Google blog post, 2018-01-16
Digging into the details first reveals the projected trench as illustrated in below by some of the stakeholders;
Projected trench of the Havfrue cable as illustrated by cloud.google.com.
Projected trench of the Havfrue cable as illustrated by TE SubCom.
Projected trench of the Havfrue cable as illustrated by submarinecablemap.com.
EDIT 2020-11-25: Additionally in 2019-06-21 Interxion announced a direct connection between the AEC2 landing site in Blaabjerg to its two datacenters in Ballerup/Copenhagen.
More digging into the Danish parts reveals that most sources mention Blåbjerg (Blaabjerg) as the Danish landing point for Havfrue (just as TAT-14), although ComputerWorld DK (see National Press below) relays the information that it will land at Endrup (where COBRAcable is terminated). However, a FCC application dated 2018-05-25 SCL-00214S (pdf) refers to it as the “Havfrue system” and specifically states that a new cable landing station will be constructed in Blaabjerg (as well as in Leckanvy, Ireland and Kristiansand, Norway);
The Havfrue system will consist of three segments. (1) The Main Trunk will connect the existing cable landing station at Wall, New Jersey with a new cable landing station to be constructed at Blaabjerg, Denmark. (2) The Ireland Branch will connect a new cable landing station to be constructed at Old Head Beach, Leckanvy, Ireland with a branching unit on the Main Trunk. (3) The Norway Branch will connect a new cable landing station at Kristiansand, Norway with a branching unit on the Main Trunk.
Google is currently also projecting its own private subsea cables, some of the rationale behind their mixed private/consortium/lease approach are disclosed in blog post from 2018-07-17 announcing the Dunant cable, which is the first Google private transatlantic subsea cable projected to connect Virginia Beach and France.
EDIT 2020-11-25: see blog post detailing my visit to the construction site in June 2019
Bulk has announced that the Esbjerg data center location will be referred to as DK01 Campus which is described on the about page (EDIT 2020-11-25: now has its own page with different wording) as follows:
Bulk’s DK01 Campus, Esbjerg, southwest Denmark, will be a scalable Carrier Neutral Colocation data center ready for customers Q4 2019. Esbjerg is becoming a highly strategic data center location with several subsea fiber systems terminating within or nearby. These include Havfrue (US, Ireland, Norway, Denmark), Havhingsten (Ireland, Denmark), Cobra (Holland, Denmark), Skagerrak 4 (Norway Denmark), DANICE (Iceland, Denmark) and TAT-14 (United Kingdom, France, the Netherlands, Germany, and Denmark). Combined with excellent terrestrial connectivity, this will make Esbjerg the main international entry point to the Nordics and enable the Bulk DK01 campus to be the natural traffic exchange point.
An article (translated) in the local newspaper JydskeVestkysten first revealed the exact location of the center and renderings of its visual appearence and construction. The location is in Kjersing industrial area North of Esbjerg.
A further map of the Bulk connections between Norway, Denmark and Ireland has been revealed in an article of Capacitymedia and on Bulk’s own fiber networks page. Also a partnership with Amazon about delivering both connectivity and datacenter infrastructure for AWS has been announced.
NOTE 2024-08-31: see also recent discussion I was involved in on a Mosquitto github issue about a similar need of generating credentials for use on systems where installed software is very constrained. As this pops up continually I’ll put on my tinkering TODO (which means no promises or guarantees at all(!)) to look into and potentially contribute a suite of utilities to do this using different tools, currently I guess PHP, OpenSSL and maybe Python would be a good start. Feel free to also ping me if this would be something you are interested in.
NOTE 2021-07-11: prompted by an email from a reader the approach described below was refined into a script which can be used as a (sort of) drop-in replacement for mosquitto_passwd, find it on sourcehut in my hometools repository as mosquitto_passwd.php (first edition also on paste.sr.ht). Even though it generates a pre-2.0 plain hash using SHA512 this is still parsable by 2.0 and later. However, 2.0 adds support for PBKDF2 aka. RFC2898 on top of SHA512 with 20.000 iterations which is also the default generated by 2.0+ mosquitto_passwd, but the broker is still able to parse previous SHA512 hashes (notice the algorithm identifier after <username>:$, 6 for SHA512, 7 for PBKDF2-SHA512, similar to common /etc/shadow convention and extensions to implementations of POSIX crypt()).
Here is a delayed write-up of my involvement in a question posted to the liberally licensed MQTT broker (server) Mosquitto’s developer list list about how to generate authentication tokens programmatically. It kicked the curious cat in me which propelled a journey into the backyards of the C code for the mosquitto_passwd tool which normally is used for this purpose. This resulted in the proof of concept PHP implementation outlined in my answer on the list which is reproduced below.
MQTT (once Message Queue Telemetry Transport) is a lightweight publish/subscribe protocol intended for communication between low power, low bandwidth embedded devices. These days it is commonly hyped as a holy grail in the religion of IoT. The protocol was originally developed by IBM but is now a standard overseen by the OASIS standardization organization which also has the OpenDocument standard (ODF, think Open/Libre-Office) under its wings. According to Wikipedia MQTT is used behind the scenes of Facebook Messenger, OpenStack and Amazon’s IoT services.
For further practical use of the concept outlined you would need to produce a random 16 byte base64 encoded salt to feed into the hasher, that could be done using something like; $salt_base64=base64_encode(openssl_random_pseudo_bytes(12));
If your need a shrink wrapped solution to this you could try to ping me.
Hi Srinivas. On 2016-07-26 12:49, Srinivas Pokala wrote: > Username successfully created using linux command with: > "mosquitto_passwd /etc/mosquitto/passwd guest". > I need to create same with php or javascript how? Looking at the source of mosquitto_passwd (https://github.com/eclipse/mosquitto/blob/master/src/mosquitto_passwd.c) basically all it does to generate the resulting line you see in the password file is: 1) draw a random 12 byte binary salt 2) hash the combination of password and salt using sha512 3) write username, base64 encoded salt, base64 encoded hash in one line A PHP implementation would use something like this ($salt is fixed for demonstration purposes, it ought to be random in production); --- $username="Bitten"; $password="Insect"; $salt_base64="spicychilinstuff"; $salt=base64_decode($salt_base64); $hash=hash("sha512",$password.$salt, true); $hash_base64=base64_encode($hash); echo($username.":$6$".$salt_base64."$".$hash_base64."\n"); --- Comparing against mosquitto_passwd using a one-liner (uses the base64 salt from output to be able to correlate the two); --- $ mosquitto_passwd -b ~/mosq_passwd_test Bitten Insect $ cat ~/mosq_passwd_test Bitten:$6$mfJ0Eq3rIDLKG33r$gkiIlz80JA6Pq9OtGhasIsx7L2vf0APdZH77+thmNW2Zp5vE1d/dAi5TjbfO9mZpKHLh38Oem1ic072rSO328g== $ php -r '$username="Bitten"; $password="Insect"; $salt_base64="mfJ0Eq3rIDLKG33r"; $salt=base64_decode($salt_base64); $hash=hash("sha512",$password.$salt, true); $hash_base64=base64_encode($hash); echo($username.":$6$".$salt_base64."$".$hash_base64."\n");' Bitten:$6$mfJ0Eq3rIDLKG33r$gkiIlz80JA6Pq9OtGhasIsx7L2vf0APdZH77+thmNW2Zp5vE1d/dAi5TjbfO9mZpKHLh38Oem1ic072rSO328g== --- As can be seen, the PHP generated password line are identical to the mosquitto_passwd generated. I have also successfully tested authentication against the mosquitto broker with PHP generated users. One caveat is that the above can generate a salt of arbitrary length, but the broker must see a 12 byte binary salt (16 byte base64) or authentication will fail. Note however, that this hasn't been tested on more than a few username/password pairs, there might be other issues lurking. Regards, -- Mikkel
Redigeret 2018-08-03: rettet døde links
Min kommentar til LoRa og LoRaWANs åbenhed i forbindelse med artikel i Version2 med overskriften “TDC holder fast i proprietær IoT-standard – andre kører billig open source”, som nok mest minder om et bidrag til “open washing” af LoRa/LoRaWAN-teknologien. Se mere om open washing i denne blogpost fra Open Knowledge Foundation Denmark (Engelsk udgave).
Det er noget misvisende at snakke om at LoRa eller LoRaWAN er “open source”. Man er i hvert fald nødt til at skelne hårdt mellem LoRa og LoRaWAN.
LoRa specificerer radiomodulationen i luften, og det er en proprietær teknologi udviklet af virksomheden Semtech, som både har varemærkebeskyttet og patenteret den (EPO-patent);
LoRa is a proprietary spread spectrum modulation scheme that is derivative of Chirp Spread Spectrum modulation (CSS)
Kilde: Semtech AN1200.22, LoRa(TM) Modulation Basics (https://www.semtech.com/uploads/documents/an1200.22.pdf, afsnit 1)
LoRaWAN er en åben protokol der anvender LoRa som transmissionsmedie, men som yderligere definerer hvordan flere enheder der alle kan snakke LoRa kan fungere sammen i et netværk. Den specificeres af et samarbejde mellem mange interessenter i LoRa Alliance, herunder også Semtech.
Q: What is LoRaWAN(TM)? A: The LoRa modulation is the pshysical layer (PHY), and LoRaWAN is a MAC protocol for a high capacity, long range star network that the LoRa Alliance is standardizing for Low Power WideArea Networks (LPWAN).
Kilde: Semtech LoRa® FAQ (http://www.semtech.com/wireless-rf/lora/LoRa-FAQs.pdf, spgm. 3)
En mere teknisk beskrivelse kan findes her; https://www.lora-alliance.org/What-Is-LoRa/Technology (from). LoRaWAN-specifikationen selv er næsten frit tilgængelig, det er kun folk med offentlige email-adresser der ikke må få den (dette er senere ændret, pr. 2018-08-03 er den frit tilgængelig).
For mig ser det dog ud som om Semtech og LoRa Alliance helt bevidst mudrer sondringen mellem LoRa og LoRaWAN, og synes det lugter af at det udelukkende er Semtech der kan og må producere silicium der implementerer LoRa. Selvom jeg ikke har kunnet finde steder det bliver sagt helt eksplicit.
Microchip og andre har produkter der snakker LoRa, men Semtech ser ud til altid at være med inde over, så jeg vil tro det stadig er en chip fra deres fabrik der ligger til grund for LoRa-funktionaliteten.
Der er dog folk der har kigget i sprækkerne på LoRa;
Spændende hvad der sker på dette felt. En mere fri og uafhængig infrastruktur i åbne licensbånd skal da være så velkommen.
Mikkel
Edit 2023-04-23: on present day Ring is known instead as GNU Jami. Contact me using ring:f20607f4f974714ba91c664b153496fb931020e5 on the Ring distributed communication platform: ring.cx
Today I managed to get a Huawei E1752 3G modem (USB id 12d1:1446/140c, usually called E1552 by lsusb) running on Ubuntu 10.04 without all the hassle described elsewhere (see this, this or this or this …).
This particular modem came from the danish cable ISP YouSee, in an offering known as Mobilt Bredbånd (mobile broadband), targeting their existing cable internet customers. Pricing starts at lowest offering of 1 Mbit/384 kbit transmission speed with 1GiB/month data limit at DKK 99/month (~USD 16.5 ~EUR 13.3).
As many recent USB modems, this one is a mode switching type with multiple personalities (Option ZeroCD(TM)). At plugin it defaults to an emulated CD mass storage drive (USB ID 12d1:1446), with an onboard Windows driver and dialer (Mobile Partner). When detected by a driver knowing it’s schizophrenic nature, it can be manipulated, utilizing psychotherapeutic tricks, to switch it’s personality to the modem it actually is (USB ID 12d1:140c). Hence, on non-Windows systems some magic needs to be established to make the modem actually behave like a modem.
One incarnation (se discussion about other stuff here) of this magic is called usb_modeswitch. That is also the solution chosen by the Ubuntu distribution team, and it is present in the repositories and configured for the Huawei E1752 in Ubuntu 10.04 ‘Lucid Lynx’, so we just need to know that we need it. You do now…
Activating usb_modeswitch is a matter of installing the usb-modeswitch package. Find it in Synaptic or issue the following in a terminal:
sudo apt-get install usb-modeswitch
Now all you have to do is insert the modem and check (we like to be certain, right?) with lsusb that you have the 12d1:140c modem device instead of the 12d1:1446 mass storage device.
The Gnome Network Manager should now pick up on the new modem device, and offer you the possibility of adding a new mobile broadband connection. In my case, it defaulted to an Oister connection, but removing that and using the wizard to create a TDC connection (YouSee is a part of/close associate of TDC) did the trick, after reinserting the modem once more.
Now I wonder why my own E160G modem works without usb_modeswitch installed…
