I’ve been hit by the “periodic boot failure” issue of the Beaglebone Black (aka BBB) reported by quite a few on the net. For most users this is an inconvenient annoyance, but for people, like me, using the platform in embedded applications, this issue causes a serious stability issue of the whole system, when 100% reliable boot is not achievable.
After having hunches about instability caused by the intermittent experiences during development, where the board was seen failing boot on power on, and not getting much more help from the net than “try the recommended power supply” (which btw. I can’t use because I live in a country where main sockets are non-US, even a bit non-European standard) I decided to make a systematic test to get the basic facts straight.
I settled on trying to establish some reasonable statistics about the error’s frequency on plain BBBs to have a reference against testing whether a theory put forward on the mailinglist (here and here) about the uboot bootloader being confused by noise being interpreted as valid data on UART0_RXD (pin E15) of the AM3358x (see near U15 page 4, of the BBB REV B schematics) as the cause of the failure.
This is the results (test report detailed below), I’m posting a writeup in the Beagleboard mailinglist (Edit: my post here), so hopefully you’ll find further discussion about this issue there soon.
The two differing Element14 branded BBB products I have access to, but both PCB REV B6, exhibits a somewhat varying boot failure rate. But overall the boards fail to boot in almost 4 of 100 boots.
Investigating the theory relating to noise on UART0_RXD seems to have paid off, as first removing U15 (SN74LVC2G241: Dual Buffer/Driver With 3-State Outputs) for the purpose of adding a pull down on its pad 6 (which is connected to UART0_RXD) alleviated the problem altogether. But also the experiment of removing the pull down and redo the test, showed that the act of removing U15 itself caused the boot to always succeed.
Unfortunately, in hindsight, I was too quick to grab the soldering iron, because I should have verified and quantized the occurrence of the failure on the actual board being modified. A shame It didn’t occur to me before modification, but I’ll be more than willing to try to remove U15 on DUT#2, which has had the highest failure rate, if discussions prove that it is a reasonable theory of the root cause of the failure. That is why I continued testing it through to 120 boots, to get more samples for improving statistics in the event that I pull U15 from it later.
The success of removing U15 could be caused by the now floating AM3388 input UART0_RXD (pin E15) which presumably has a default weak internal pull up/down (the AM335x TRM says reset value is pad-dependent (register conf_uart0_rxd in Table 9.7 p. 1366 and Section 9.3.1.50 p. 1420), which I haven’t yet figured out the exact meaning of) stabilizing the signal
The activity when U15 is in place is somehow exhibited on output 1Y (pin 6) , probably because it is not stable, and thus has an erratic state, during the first moments of the chips power up sequence. This erratic behaviour can in fortunate/unfortunate circumstances be interpreted as valid bits and resulting bytes by the uart rxd cirtcuitry, which also can happen to be latched into the uart fifo rx buffer, waiting for uboot to read them when its code is executed looking for a user interrupt.
I’ll put in the disclaimer on this thesis, that I haven’t yet studied U15 in detail, but it is advertised as both a level converter, ESD protection and power live-insertion/partial-power-down suggesting it does something in reaction to it’s power condition.
Also the recommendation on page 1 of its datasheet; “To ensure the high-impedance state during power up or power down, OE (active low) should be tied to VCC through a pullup resistor, and OE (active high) should be tied to GND through a pulldown resistor”, seems not to be followed in the BBB circutry, as the OEs are hardwired in to be always active (opposite of the recommendation in the power up/down condition). If this is actually a problem, I need to do further analysis to establish.
(formatted in nice emacs org-mode)
* BBB boot lockup test report ** Device under test #1: Modified Beaglebone Black produced by CircuitCo (PCB REV B6, serial 007142901445, marked "beaglebone"+ beagle logo and "beagleboard.org"). Modified by adding hard pulldown resistor on TI AM3358 pin E15 (uart0 rx). Specifically U15 was removed and terminal pin 6 (1Y=UART0_RX) was shorted to J1 pin 1 through a 82k5 ohm resistor. ** Device under test #2: Unmodified Beaglebone Black (BBB) produced by Element 14 (PCB REV B6, serial EM-400524+XA6001961, marked "Element 14"). ** Device under test #3: Unmodified Beaglebone Black (BBB) produced by mbest (PCB REV B6, serial EM-400441+XA3001688). ** Power supply Jentec Technologies CF1805-E, output 5V 3A. Danish plug. Sourced from a D-Link DUB-H7 USB 2.0 HUB. ** Test 1 procedure Each Beaglebone was tested by consequtively applying power by inserting the plug into the mains socket while keeping the DC barrel connector inserted and verifying that the power led light up, and then noting whether boot from SD-card succeeded or failed. Then removing the PSU from the mains connector waiting 5 seconds and repeat. The power supply and SD-card used was the same for all three DUTs. Results can be seen in section Test 1 results. ** Test 2 procedure After a short analysis of test 1 results I decided to try to remove the resistor, to see if the behavious was restored. Otherwise test procedure was identical to test 1. Results can be seen in section Test 2 results. ** Test 1 results (pull down and reference boards) | Boot no | DUT#1 | DUT#2 | DUT#3 | Note | | 1 | boot | boot | boot | | | 2 | boot | boot | boot | | | 3 | boot | boot | boot | | | 4 | boot | boot | boot | | | 5 | boot | boot | boot | | | 6 | boot | boot | boot | | | 7 | boot | boot | boot | | | 8 | boot | boot | boot | | | 9 | boot | boot | boot | | | 10 | boot | boot | boot | | | 11 | boot | no boot | boot | DUT#2: pwr sw=lock, rst sw=boot | | 12 | boot | boot | boot | | | 13 | boot | boot | boot | | | 14 | boot | boot | boot | | | 15 | boot | boot | boot | | | 16 | boot | boot | boot | | | 17 | boot | boot | boot | | | 18 | boot | boot | boot | | | 19 | boot | boot | boot | | | 20 | boot | no boot | boot | DUT#2: pwr sw=no boot, rst sw=boot | | 21 | boot | boot | boot | | | 22 | boot | boot | boot | | | 23 | boot | boot | boot | | | 24 | boot | boot | boot | | | 25 | boot | boot | boot | | | 26 | boot | boot | boot | | | 27 | boot | boot | boot | | | 28 | boot | boot | boot | | | 29 | boot | boot | boot | | | 30 | boot | boot | boot | DUT#3: pause before comencing test 31 | | 31 | boot | boot | no boot | DUT#3: pwr sw=no boot, rst sw=boot | | 32 | boot | no boot | boot | DUT#2: pwr sw=no boot, rst sw=boot | | 33 | boot | boot | boot | | | 34 | boot | boot | boot | | | 35 | boot | boot | boot | | | 36 | boot | boot | no boot | DUT#3: pwr sw=no boot, rst sw=boot | | 37 | boot | boot | boot | | | 38 | boot | boot | boot | | | 39 | boot | boot | boot | | | 40 | boot | boot | boot | | | 41 | | boot | | | | 42 | | boot | | | | 43 | | boot | | | | 44 | | boot | | | | 45 | | boot | | | | 46 | | boot | | | | 47 | | boot | | | | 48 | | boot | | | | 49 | | boot | | | | 50 | | boot | | | | 51 | | boot | | | | 52 | | boot | | | | 53 | | boot | | | | 53 | | boot | | | | 54 | | boot | | | | 55 | | boot | | | | 56 | | boot | | | | 57 | | boot | | | | 58 | | boot | | | | 59 | | boot | | | | 60 | | boot | | | | 61 | | boot | | | | 62 | | boot | | | | 63 | | boot | | | | 64 | | boot | | | | 65 | | boot | | | | 66 | | boot | | | | 67 | | boot | | | | 68 | | boot | | | | 69 | | boot | | | | 70 | | boot | | | | 71 | | boot | | | | 72 | | boot | | | | 73 | | boot | | | | 74 | | boot | | | | 75 | | boot | | | | 76 | | boot | | | | 77 | | boot | | | | 78 | | boot | | | | 79 | | boot | | | | 80 | | boot | | | | 81 | | boot | | | | 82 | | boot | | | | 83 | | boot | | | | 84 | | boot | | | | 85 | | boot | | | | 86 | | boot | | | | 87 | | boot | | | | 88 | | boot | | | | 89 | | boot | | | | 90 | | boot | | | | 91 | | boot | | | | 92 | | boot | | | | 93 | | boot | | | | 94 | | boot | | | | 95 | | boot | | | | 96 | | boot | | | | 97 | | boot | | | | 98 | | boot | | | | 99 | | boot | | | | 100 | | boot | | | | 101 | | boot | | | | 102 | | boot | | | | 103 | | boot | | | | 104 | | boot | | | | 105 | | boot | | | | 106 | | no boot | | | | 107 | | boot | | | | 108 | | boot | | | | 109 | | boot | | | | 110 | | boot | | | | 111 | | boot | | | | 112 | | boot | | | | 113 | | boot | | | | 114 | | boot | | | | 115 | | boot | | | | 116 | | boot | | | | 117 | | boot | | | | 118 | | boot | | | | 119 | | boot | | | | 120 | | boot | | | General DUT#3 behaviour: slower boot, pause after power on, and visible delay while lighting USRLED1-3 until SD-card boots. Might be caused by a different uboot edition than DUT#1 and DUT#2. ** Test 2 results (DUT#1 pulldown removed) | Boot no. | DUT#1 | | 1 | boot | | 2 | boot | | 3 | boot | | 4 | boot | | 5 | boot | | 6 | boot | | 7 | boot | | 8 | boot | | 9 | boot | | 10 | boot | | 11 | boot | | 12 | boot | | 13 | boot | | 14 | boot | | 15 | boot | | 16 | boot | | 17 | boot | | 18 | boot | | 19 | boot | | 20 | boot | | 21 | boot | | 22 | boot | | 23 | boot | | 24 | boot | | 25 | boot | | 26 | boot | | 27 | boot | | 28 | boot | | 29 | boot | | 30 | boot | | 31 | boot | | 32 | boot | | 33 | boot | | 34 | boot | | 35 | boot | | 36 | boot | | 37 | boot | | 38 | boot | | 39 | boot | | 40 | boot |
I have invested quite a lot of time and energy the last weeks, on a project of mine that has had a long time building in my consciousness.
Last September I sent out a cry for participation on hackerspaces.org, for people wanting to be part of a hackerspace in my hometown of Esbjerg, Denmark. Although Esbjerg is home to quite both technical and heavy duty industries, servicing offshore drilling and wind farms in the North Sea, there really isn’t a community were technical like-minded can meet up and have fun using their skills. My hope was to find fellow tinkers/hackers/makers/creative people for joining in on having fun with technology with me and whoever wanted to be part of the party.
During the next 3/4 year I received about 6 emails from interested parties in and around the city of Esbjerg. So in late August I acted on an idea I have long had, of the hackerspace being a part of a creative workshop that is voluntary driven in a culture and concert venue called Tobakken. After some talks, organization of interested parties and some thoughts at both sides, we are in the process of establishing what we, in lack of a better name, currently refer to as Hackerspace/Makerspace Esbjerg.
A picture from the first meeting at the location. Mikkel is talking about important stuff, as can be seen from the neck-grab position :).
You can see some more shots of the physical space here; hmse.mikini.dk/doku.php?id=gallerier
Most of the organizational efforts and communication is in the Facebook group at the moment, but I’m trying to push stuff over to a dokuwiki-site, which I think is much more appropriate.
You are more than welcome to chime in, if you happen to be in Esbjerg and miss an outlet for the creative technological cravings inside. See you in the space!
Working on a Beaglebone Black based product, running the latest Debian GNU/Linux system image (bone-debian-7.5-2014-05-14-2gb.img) from the BB HQ at beagleboard.org I just had the following strange experience.
Using Subversion I wanted to commit a change to a file made locally on the BBB. The file resided in a working copy of a repository on which I had done the initial work on my x86_64 laptop. The working copy was checked out and updated on the BBB without any problems, but comitting I got the following error:
debian@beaglebone:~/VCAS_FR$ svn ci rc.local -m"Append to vncserver.log." Authentication realm: <https://svn.xx.xx> Subversion Repository Password for 'yaya': Sending rc.local Transmitting file data .svn: Commit failed (details follow): svn: File not found: transaction '414-1', path '/trunk/BBB%20deployment/rc.local' debian@beaglebone:~/VCAS_FR$
This failed repeatedly, and checking out a fresh new working copy exhibited the same result.
For the fun of it, because file name issues are long gone in my everyday computing life, I tried to remove the space from the directory path. And voila, unexpectedly it succeeded!
debian@beaglebone:~/VCAS_FR$ svn ci rc.local -m"Append to vncserver.log." Authentication realm: <https://svn.xx.xx> Subversion Repository Password for 'yaya': Sending rc.local Transmitting file data . Committed revision 416. debian@beaglebone:~/VCAS_FR$
Without spaces, things actually did work. Apparently there’s an issue with ARM built subversion and repositories containing spaces.
URL before
debian@beaglebone:~/VCAS_FR$ svn info | grep URL URL: https://svn.xx.xx/trunk/BBB%20deployment debian@beaglebone:~/VCAS_FR$
URL after
debian@beaglebone:~/VCAS_FR$ svn info | grep URL URL: https://svn.xx.xx/trunk/BBB_deployment debian@beaglebone:~/VCAS_FR$
Investigating a bit further narrowed down that the Debian distribution uses an old (old, old) subversion 1.6.17 release from 2009:
debian@beaglebone:~/VCAS_FR$ svn --version svn, version 1.6.17 (r1128011) compiled Mar 15 2014, 21:37:31 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.apache.org/ This product includes software developed by CollabNet (http://www.Collab.Net/).
Probaly, this has been fixed since, a quick investigation in svn issue tracker revealed no open issues regarding this. I’ll look further into this later, and of course report it appropriately if this is an unknown issue.
But as you see, you can still experience basic issues on the latest and greatest stuff out there. Be wary!
A very annoying feature of the Ångström image that is shipped with the BeagleBone Black, is that a display connected to the HDMI output of the board will by default be blanked when powering up, and is first woken when any pointer activity occur (touch/mouse).
This seems to originate from the fbdev that is used for displaying graphics, and it took me some time to figure out how to cirumvent it. The normal X commands for controlling blanking of “xset -dpms” or “xset s off” did nothing, and neither did the terminal options of “setterm powersave off” or “setterm powerdown 0”. I went all the way back to old ANSI escape sequences trying “echo -e ‘\033[9;X]'” without success.
Luckily I fell by at Armadeus.com’s framebuffer tips, which listed the sys-fs node named /sys/class/graphics/fb0/blank that controls blanking of the low level framebuffer, thus executing (as root)
echo 0 > /sys/class/graphics/fb0/blank
disables blanking and wakes up the BBB HDMI output.
To do this at every boot (really login) you can use the Gnome Startup Applications Preferences (gnome-session-properties) to execute this at Gnome autologin, or add it to whatever startup script you see fit.
Beware that you might need to delay the execution when using the gnome-session-properties, I had to put in a sleep, but that probably depends on what other stuff is starting up from it.
Eric S. Raymond, “The Cathedral and the Bazaar” (@Goodreads)
The above quotes the first lesson from Eric S. Raymond‘s (ESR) essay/book “The Cathedral and the Bazaar“ (link to full book, summary at Wikipedia), which has become a kind of bible within the FOSS ecosystem (also nicknamed CatB). In his text Eric investigates motivations and social organisation of free and open source software projects. Itches are known initiators of many both large projects and minor changes to FOSS software. Itches, and the scratching of those by developers in the FOSS community, highlights a FOSS software user’s right to access, modify and redistribute the source codes behind FOSS software. With access to the underlying source code of FOSS software, a developer is able to scratch an itch, and is usually very motivated by this, because it often is a very personal itch.
You can listen to an audio recording of Eric elaborating about the central topics of CatB in a recording from a talk at Linux Kongress all the way back to May 22th 1997 17:15 CEST (48k MP3, 96k MP3):
I’ve long been trying to keep a list of itches I want to scratch in free software projects/products. Realizing that most of these were lost in transit in the chaotic neuron mess of my brain, my intention now is to, also, keep track of them textually using the mechanisms of this site.
This effort will be an ongoing, and probably ever expanding, mix of my private personal itches and itches related to and spun-off from my software development work done as a professional embedded developer, but still personal itches.
You can head over to the static page at mikini.dk/what/itches and take a look at my past and present itches.
EDIT 2021-08-24: add prominent quote source, add GR quote link, add CatB main page link, add para. with audio recording, minor copyediting
Scouring the net looking for data and specifications of Google’s Nexus 7 tablet (wanting to try out the Ubuntu Touch Developer Preview) , I got myself into the Nexus 5 smartphone specifications too. Here I noticed a peculiar grammatical difference in how the specs is presented, which also exists in the specs for other products (at least the Nexus 7 also).
The issue is a result of internationalization (i18n) and localization (l10n) of the specification texts as presented to users in different regions of the globe. I’m a native Dane, so my search ended correctly (helped by my browser language setting and Google geo-ip) up on the Danish Google page at http://www.google.dk/nexus/5/.
In accordance to Danish grammatical rules, the localization of the text had led to the use of a comma (“,”) instead of punctuation mark (“.”) as decimal point in the specification of the phone processor’s clock frequency, presenting the English text
in Danish as:
This changes the meaning of the sentence in Danish to a listing of three features, namely “Snapdragon™ 800”, “2” and “26GHz processor” which is both incorrect, incomprehensible and ambiguous.
From my grammatical point of view, a better solution in both English and Danish would be to parenthesize the clock frequency, which is in reality a sub-specification to the actual processor model:
This text doesn’t hit my abomination trigger, and also better models the information’s true inheritance as being not side-ordered, but a sub specification to the the processor model.
How and if this kind of subtle difference between locales and languages should be handled in internationalization systems I can’t really comprehend. It’s a complex task even without this, but this example clearly emphasizes the need for proofreading by an actual native speaker of all languages, before completeness and non-ambiguity can be guaranteed.
(An even more peculiar fact, is that the textual similar Android revision reference “Android™ 4.4, KitKat®” is not localized, and thus in the Danish localized text is identical to the English.)
When dealing with policy enforcement for products that you distribute from business partners and whose sales your organization directly profits from, you’d think that you’d want to engage in some kind of communication with your peers before making drastic moves like shutting down distribution of these products. Especially when your peer is a national lottery organization partly owned by a European state, who is strictly professional about their business and which probably has a non-significant turnover facilitated by the product.
Well, if your are Google and runs the Google Play software distribution system for the Android platform, you apparently couldn’t care less. At least that is what a move today by Google implies, when banning an Android gaming app by Danske Spil, the national Danish lottery, who has a governement enforced monopoly on lottery in Denmark. This was done without any interaction with Danske Spil which of course was taken by surprise when realizing this, as reported (GTrans) by Danish tech magazine Version2.
Admittedly, as it stands now from an objective point of view, the app clearly breaks the content policy of Google Play which states that “We don’t allow content or services that facilitate online gambling”. So the real question, apart from the peculiar behaviour of Google towards this app provider for Google Play, is for Danske Spil; “How on earth did you think you could distribute an app through Google Play which so blatantly is in direct violation of the content policy?”.
Maybe the endorsement by the Danish legislation has risen to their heads, making them think their monoploy in Denmark made them so special that they could ignore Google’s standard policies? The current response from Danske Spil is that the app had been previously “approved” by Google, whatever that means because to my knowledge there is no verification procedure as such for content on Google Play (that’s a point for further investigation when time permits) .
At the moment not only the app itself, but also the provider page for Danske Spil A/S is inaccessible at Google Play, even though marketing from Danske Spil still tries to lure new users to the lotteries provided by the app, both from the web, TV and electronic billboards.
If your business model relies on outside partners (and which doesn’t?), this might be a good occasion to take the time for a second thought about what dependencies it has. And especially who is in the power to pull the carpet below it without interacting with you.
If I had a business with parts, components or services not under my in complete control, I’d prefer a partner which had a fellow human representing him, with which I could meet and look into his eyes. That way a social bond is created, which hopefully increases the probability that I will know if anything is about to happen that affects my business.
Nice story in the media (GTrans) (+2 (GTrans), 3, (GTrans)) in Denmark right now, is of a consumer who filed a complaint to The Danish Consumer Agency regarding reimbursement of his OEM Windows license, and won in a principal judgment (warning Google Translate exaggerates the price by some decades, the correct refund is DKK 850 ~ EUR 114 ~ USD 151 ).
He wanted to use his new computer for GNU/Linux only, but the store (a supermarket) and the computer manufacturer would only accept a refund for the complete purchase, regardless of the Windows Vista license offer to get a refund for the bundled software.
The consumer agency ruled in favor of the consumer, citing his right for reimbursement as pr. the license agreement, and the Danish consumer law that interprets in favor of the consumer when doubts arise.
This is very good news for the rights of Danish consumers, after we were let down by Poul-Henning Kamp’s recent loss in court (GTrans) about a similar complaint.
Go get those Vista refunds!
But remember for Windows 7, the license reads “you must return the entire system on which the software is installed for a refund or credit”, effectively making any product distributed with Windows 7 a madatory subject to the Microsoft tax.
UPDATE 2011/01/18 20:40:
A followup article at ComputerWorld Denmark (GTrans) states that HP Denmark doesn’t think the ruling will have any “practical effect” on their business. They believe very few consumers are interested in alternative operating systems, and haven’t seen any demand for it in the market. How a demand can be established without a product, HP doesn’t have any insights into, as they have never had alternative offerings.
Even though we all know what the OEM license says, an OEM director from Microsoft Denmark cleverly enough states that; “we can not and should not interfere with the wording of return policies, including whether the software can be returned with the PC only“. In the last blow to any logic, the HP response is to; “await a statement from Microsoft, and then implement a solution“.
Just saw the Google Street View car driving by at my daily whereabouts in Esbjerg, Denmark. Did get a little exhilerated and spilled some coffee in excitement and attempt to wave at the cameras (Hi mom!!) . Here’s a shot of the car taken by itself when passing my home at it’s last visit in 2009.
Apparently Google Streetview has started collecting data again here i Denmark, as they did in Norway, Sweden, Ireland and South Africa in July. Now with the Wi-Fi privacy issue resolved.
The following netfrenzy brought me to the official schedule at http://www.google.dk/help/maps/streetview/where-is-street-view.html which shows some mid to large sized cities in Denmark beeing up for an update, including Esbjerg. Strangely I haven’t noticed any lack of imagery in my local area. I know that most of Denmark was beeing photographed during July and August 2009, so something must be missing, or of inferior quality since they are coming back.
I also found a fun Street View Partner site; Legoland in California has allowed Street View to take a tour through the park. Fun for me, because the Lego Group HQ and original Legoland Billund is close to Esbjerg, and I have been going there regularly wiht the kids. Going to be fun to take them for a virtual walk in the park in California ;). The Billund park doesn’t seem to have been mapped internally, though.
Also a hilarious joke on Google Streetview from an interesting group of people; The Free Art and Technology (F.A.T.) Lab. Will be digging these nutty people out for sure.
Once in a while it is useful to dismiss abstractions and layers that makes daily routines easier and take the raw approach. Like when debugging a software problem that doesn’t make sense, it is nice to see the underlying basic stuff is behaving nicely, to better be able to locate where the unexpected occurs.
In the IP world of the internet, the swiss army knife for debugging interprocess communications in a totally protocol agnostic way is called ‘telnet’. Telnet opens up a communication channel between your local computer and a daemon/server on a specific port on a specific IP address. Then it gets out of the way for you to talk directly to the daemon in clear text.
Knowledge of how to interact using a specific protocol can be very useful to check server availability and functionality. All common protocols in use on the internet (like DNS, HTTP, SMTP, POP3, IMAP, XMPP etc.) can be debugged like this, because all of them transfers data in clear text (or at least initiates other transfer types from a clear text session). Full specifications for the HTTP protocol can be found in IETF RFC2616. I keep forgetting this, and end up digging around for it when needed, therefore this blog post.
Below is a basic HTTP session to my web server www.mikini.dk using telnet on the command line.
Red text is local text input by me. Blue text is local text by telnet application. Green text is server response.
$ telnet www.mikini.dk 80 Trying 92.61.152.47… Connected to 92-61-152-47.static.servage.net. Escape character is ‘^]’. GET /index.php/2010/06 HTTP/1.1 Host: www.mikini.dk
HTTP/1.1 200 OK Date: Wed, 21 Jul 2010 09:19:13 GMT Server: Apache X-Pingback: http://www.mikini.dk/xmlrpc.php Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8
2bd2 <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“>
<… remainder of HTML document dropped …>
We are asking the server at www.mikini.dk port 80 (default http port) for the document at path /index.php/2010/06 (“GET /index.php/2010/06”). Notice the two CRLF characters after the Host header field, this indicates to the server that the request header is done, and that it should begin parsing header and send its response. Also notice that even though you tell the telnet program on the commandline that you want to access www.mikini.dk, you have to tell it again to the server in th HTTP Host field. Thats because telnet is only concerned about the IP address of the server, it resolves www.mikini.dk to the IP 92.61.152.47 through DNS and forgets about it. From the servers point of view, it needs to know which of its virtual hosts you want to talk to, cause one server application on one port on one ip can potentially host thousands of separate websites (virtual hosts).
Below is the same session using nc (netcat) as a one-liner (wow, old PHP at Hostinger, better get that move to a self-administered box going).
$ echo -ne "GET /index.php/2010/06 HTTP/1.1\r\nHost:www.mikini.dk\r\n\r\n"|nc www.mikini.dk 80 | head -10 HTTP/1.1 200 OK Date: Thu, 05 Jul 2018 16:30:07 GMT Server: Apache X-Powered-By: PHP/5.5.35 Link: <http://www.mikini.dk/wp-json/>; rel="https://api.w.org/" Content-Length: 32356 Content-Type: text/html; charset=UTF-8 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> $
2018-07-05: nc command line added
