mirror of
https://github.com/mbirth/wiki.git
synced 2024-09-19 06:23:25 +01:00
Added abbreviation feature of Kramdown.
This commit is contained in:
parent
7a96d075d0
commit
e0f780a5d7
@ -1,3 +1,8 @@
|
||||
abbr, acronym {
|
||||
border-bottom: 1px dotted #888;
|
||||
cursor: help;
|
||||
}
|
||||
|
||||
#headerleft, #headerright {
|
||||
display: inline-block;
|
||||
}
|
||||
|
||||
@ -128,3 +128,7 @@ To use custom DNS entries instead of those given by your ISP, use the
|
||||
|
||||
Now just insert your desired DNS servers, upload the changed config and you should be set.
|
||||
(Info found on [ip-phone-forum.de](http://www.ip-phone-forum.de/showthread.php?t=86191&page=2).)
|
||||
|
||||
*[FB]: Fritz!Box
|
||||
*[DNS]: Domain Name System
|
||||
*[ISP]: Internet Service Provider
|
||||
|
||||
@ -26,16 +26,25 @@ The router ID was found quick: In the `dd-wrt.v23_asus.trx` at `0x356fc4`, there
|
||||
|
||||
57 4c 35 30 30 67 78
|
||||
|
||||
which is `WL500gx`. After changing it to `WL300g ` (with a space after the "g" to fill up the digit), the router didn't reject the firmware directly, but initiated the update, then rebooted quickly after that and showed the old firmware again.
|
||||
which is `WL500gx`. After changing it to `WL300g ` (with a space after the "g" to fill up the digit), the router didn't reject the
|
||||
firmware directly, but initiated the update, then rebooted quickly after that and showed the old firmware again.
|
||||
|
||||
According to the [DD-WRT manual for the WL-500g](http://www.dd-wrt.com/wiki/index.php/Installation#Asus_WL500G</u>.28Original.29), the router should have a recovery mode which you can enable by holding the Reset button while powering on the device. But seems this mode wasn't there in my router.
|
||||
According to the [DD-WRT manual for the WL-500g](http://www.dd-wrt.com/wiki/index.php/Installation#Asus_WL500G</u>.28Original.29),
|
||||
the router should have a recovery mode which you can enable by holding the Reset button while powering on the device. But seems this mode wasn't there in my router.
|
||||
|
||||
So there has to be some sort of checksum which tells the router whether the firmware file is corrupt or not. In the DD-WRT forums I read somewhere, that there are only some informational bytes different between a normal DD-WRT binary firmware and the ASUS TRX format - maybe the ID-string at the end.
|
||||
So there has to be some sort of checksum which tells the router whether the firmware file is corrupt or not. In the DD-WRT forums
|
||||
I read somewhere, that there are only some informational bytes different between a normal DD-WRT binary firmware and the ASUS TRX format - maybe the ID-string at the end.
|
||||
|
||||
Therefore I compared the two files `dd-wrt.v23_asus.trx` and `dd-wrt.v23_generic.bin` and voilà: Besides the few bytes at the end of the file, there were 4 additional bytes different at position `0x08`. This HAD to be the checksum. The remaining question was, from which bytes it was calculated. Since the seemingly compressed data began at `0x28`, I tried from there to the end and used [Hex-Workshop](http://www.hexworkshop.com/) to calculate different checksums, but nothing matched what was in these 4 bytes. The next try was from `0x10` but also no match. Then I tried starting directly after the checksum in the header, from `0x0c` and bang: The CRC32 checksum matched that in the header.
|
||||
Therefore I compared the two files `dd-wrt.v23_asus.trx` and `dd-wrt.v23_generic.bin` and voilà: Besides the few bytes at the end of
|
||||
the file, there were 4 additional bytes different at position `0x08`. This HAD to be the checksum. The remaining question was, from
|
||||
which bytes it was calculated. Since the seemingly compressed data began at `0x28`, I tried from there to the end and used
|
||||
[Hex-Workshop](http://www.hexworkshop.com/) to calculate different checksums, but nothing matched what was in these 4 bytes. The next
|
||||
try was from `0x10` but also no match. Then I tried starting directly after the checksum in the header, from `0x0c` and bang:
|
||||
The CRC32 checksum matched that in the header.
|
||||
|
||||
|
||||
|
||||
So I calculated the CRC32 of my modified file and changed the header - and now I could upload the DD-WRT file using the normal firmware upgrade of the original firmware. After installing v23, you can easily update to v24 using the DD-WRT web interface.
|
||||
So I calculated the CRC32 of my modified file and changed the header - and now I could upload the DD-WRT file using the normal firmware
|
||||
upgrade of the original firmware. After installing v23, you can easily update to v24 using the DD-WRT web interface.
|
||||
|
||||
|
||||
|
||||
@ -17,3 +17,5 @@ According to a MEDION employee, there are only 2 employees who know this passwor
|
||||
Well, IMHO everyone should decide for his own whether he wants to risk damaging his PC or not. But I guess the newer BIOSes ask for another password.
|
||||
|
||||
More info: [PC Welt forums](http://www.pcwelt.de/forum/showthread.php?t=196865), [Wim's BIOS](http://www.wimsbios.com/phpBB2/viewtopic.php?t=7557)
|
||||
|
||||
*[IMHO]: In My Humble Opinion
|
||||
|
||||
@ -80,3 +80,7 @@ After passing the roundabout, the map displays fine but as soon as you reach the
|
||||
After it started up again and you're above the "hide map"-speed, it crashes and reboots again. The crossing which should show up is the one at `N 52° 31.744', E 13° 06.607'`.
|
||||
|
||||
Tested with NavCore 9.014 and 9.024, maps 830 and 840. All combinations show the same behavior.
|
||||
|
||||
*[PNAs]: Personal Navigation Assistants
|
||||
*[TTS]: Text to Speech
|
||||
*[POIs]: Points of Interest
|
||||
|
||||
@ -24,3 +24,5 @@ With the [SMI UFD Utility](http://ftp.usboffice.kr/files/SMI_UFD_Utility.zip), y
|
||||
|
||||
This way, you can make it e.g. a Windows XP or Windows 7 installation device, use it for the [System Rescue CD](http://www.sysresccd.org/Main_Page) or - if you can trick the *U3 LaunchPad* into
|
||||
accepting the stick - burn the U3 software to it to make it U3 compatible.
|
||||
|
||||
*[SMI]: Semiconductor Manufacturing International
|
||||
|
||||
@ -23,3 +23,6 @@ and maybe [mtp-tools](apt://mtp-tools). Now connect your player in MTP mode and
|
||||
(make sure, the directory `/mnt/sansa` exists before trying the mount command.)
|
||||
|
||||
Now you should have access to the MTP area of your Sansa where you can delete the demo songs or put new files in.
|
||||
|
||||
*[MTP]: Media Transfer Protocol
|
||||
*[MSC]: Mass Storage device Class
|
||||
|
||||
@ -41,3 +41,7 @@ The `playlist_path` and `playlist_format` describe the location for playlists an
|
||||
|
||||
|
||||
The file `/usr/share/hal/fdi/information/10freedesktop/10-usb-music-players.fdi` lists the options usually set for FUZE players. Just search for the string "Fuze". But I guess the PnP-ID of the newer models isn't in that XML file.
|
||||
|
||||
*[MTP]: Media Transfer Protocol
|
||||
*[MSC]: Mass Storage device Class
|
||||
*[FUSE]: Filesystem in Userspace
|
||||
|
||||
Loading…
Reference in New Issue
Block a user