Donnerstag, 12. Oktober 2017

Von Partnerstädten und deren Nutzen


Wenn ich Erfahrungen selber mache, wächst in mir immer wieder das Bedürfnis, diese mit einer guten Prise meiner persönlichen Meinung anderen mitzuteilen.

In der Vergangenheit bin ich dabei immer wieder mit der Situation konfrontiert worden, daß es den Zuhörern am Ende völlig egal war.
Dabei konnte es sich um brisante oder belanglose Dinge handeln.
Spätestens 2 Tage nach dem Gespräch waren alle Ambitionen aus der Nachlese wieder hinweggefegt.

So wird es Ihnen, lieber Leser übermorgen auch gehen.

Sollten Sie nun der Meinung sein, daß Sie nicht in diesen Pool von Menschen gehören, bleibt es Ihnen überlassen, mich zu überzeugen, daß das nicht so ist.

Aber genug von Ihnen und mir, lassen Sie mich Ihnen ein wenig aus meinem Jahr 2017 erzählen.

Dieses Jahr war für mich von einem besonderen Ereignis geprägt. Einer Radtour. Nicht "irgendeiner" Radtour, sondern schon mit einem besonderen Hintergrund.
Mal abgesehen von den knapp 1100km, welche ich in rund 9 Tagen zurückgelegt habe, sondern auch das Ziel war besonders. Besonders in sofern, als daß es sich um die kleine Stadt Chateâubriant in Frankreich handelt, welches die Französische Partnerstadt meines aktuellen Wohnortes Radevormwald ist.

Die Stadt Radevormwald pflegt eine langjährige Beziehung zu dieser Stadt und jedes Jahr liest man in kleinen oder großen Artikeln von wirtschaftlicher Zusammenarbeit oder einem Schüleraustausch.

Ein eigener Partnerstadtverein existiert ebenfalls und natürlich ein kleiner Park, der den Namen der Stadt trägt.

Würde man das nun so stehen lassen, könnte man meinen, alles sei bestens und ganz toll.

Ja, das dachte ich auch. Bis ich mich entschloss diese Fahrradtour zu machen.
Meine Idee ging in die Richtung, daß man doch auch in einer Gruppe fahren und da eine "echte" Aktion draus machen könnte.
Ja, so dumm -oder vielmehr naiv; war ich.
Was mich dann nämlich traf, war die harte Wirklichkeit.

Die begann damit, daß der Partnerstadt Verein Chateâubriant nicht das geringste Interesse hatte, mitzuarbeiten und endete darin, daß selbst nach einem Gesprächstermin mit dem Bürgermeister und dessen Zusage die Vereine anzusprechen, nichts (null -nada -garnichts) an Rücklauf stattfand.

Dabei hätte niemand wirklich noch etwas "machen" müssen. Sowohl der Tourenplan, als auch alle Nebenbaustellen (Versicherung, Ärtze, Transport im Notfall) waren im Vorfeld schon geklärt worden.
Man hätte sich nur noch um seine persönliche Ausrüstung kümmern und am Starttag etwas früher Aufstehen müssen.

Selbst die, welche sich in einer lokalen Facebookgruppe noch in der Planungsphase als hoch interessiert darstellten, verschwanden ganz schnell wieder, als es um konkrete Dinge ging -naja, Facebook halt.

Wer nun noch das Argument "Geld" im Nacken hat, dem sei gesagt: für mich alleine habe ich sage und schreibe weit unter €200,- auf der Tour benötigt. Und ich glaube, wenn da jemand wirklich in der Not gewesen wäre, hätten sich dann bestimmt Lösungen finden können.

Und die Partnerstadt? Naja, das ist ein eigenes Thema, welches ich zum heutigen Zeitpunkt noch nicht so richtig klar darlegen kann, und ich will da auch keine falschen oder voreiligen Rückschlüsse ziehen. Für mich gab es eine lustige aber etwas verstörende Begegnung auf dem Campingplatz und einen super lieben und interessierten Thai-Wirt in der Altstadt. Außerdem höfliches Hotelpersonal und eine merkwürdige Begegnung mit der Touristeninfo.

Aus heutiger Sicht muss ich sagen, daß ich die Tour mehr im Sinne "der Weg ist das Ziel" sehe und ich würde sie jederzeit wieder machen -wobei das Ziel nicht zwingend das Selbe sein muss.

Bleibt eventuell jetzt bei Ihnen, lieber Leser, die Frage offen, was ich mir eigentlich vorgestellt hätte?

Pragmatisch: Ein breiteres Publikum mit Interesse und Wissen rund um unsere Partnerstadt.
Im weiteren Sinne eine neue Kontaktebene zwischen den Städten und eine ganz neue Wahrnehmung.
Bis heute ist das für den Großteil der Rader doch nur ab und an mal ein Zeitungsartikel und für eine mehr oder minder erlesene Gruppe der Bürger einmal im Leben ein Schüleraustausch.
Aber hier bot sich die Chance auf eine völlig neue Möglichkeit.
Vielleicht war es aber auch genau das, was den Bergischen Holzschädel und im speziellen den völlig unbeweglichen Radevormwalder in seinen Grundfesten erschütterte und in die übliche Blockadehaltung verfallen ließ.
Ich weiß es nicht.

Tatsache war, daß wenige Wochen nach meiner Tour wieder ein Zeitungsartikel erschien -natürlich mit Bürgermeister und Partnerschaftsverein auf dem Bild; welche in Chateâubriant für eine bessere Zusammenarbeit im wirtschaftlichen Sektor warben.

Und so hat sich auch dieses Jahr wieder alles in seinem üblichen begrenzten Horizont bewegt.
Nächstes Jahr ist dann wieder Schüleraustausch.

Keine Kritik, ohne Konstruktives:
Wenn es in Rade nun jemanden gibt, der diese unsägliche Geschichte wieder gerade rücken möchte, so bin ich für alles offen. Mein Rad und meine Tourenausrüstung sind jedenfalls wieder startklar.

-----------------Links-------------------------
Partnerstadt Verein
http://www.chateaubriant.radevormwald.de/cms222chat/startseite/
Beziehung intensivieren
http://www.rp-online.de/nrw/staedte/radevormwald/kontakt-zu-partnerstaedten-intensivieren-aid-1.7051737
Mein Backlink zur Tour:
http://mitdemfahrradnach.blogspot.co.uk/2017/06/chateaubriant-2017-prolog.html
Die "Erlesenen" ;-) :
http://www.realschule-radevormwald.de/?page_id=356

Mittwoch, 4. Oktober 2017

Upgrading SCCP Firmware on a 7940 Series

I write this in english, because I have found a lot of threads in several communities asking about that issue.
Recommendation: Take time, coffee/tea and some biscuits and read with a smile. Don't expect anything, but be filled with hope ;-)

Ok, here we go:

You have a Cisco 7940 SCCP phone running an older firmware version, and You are in the need to upgrade.
In my case it was an update of the CHAN_SCCP for the Asterisk Server.

My 7940 had firmware version 7.2 installed, and because of some enhancements in the newer SCCP driver it did not display the Caller ID anymore, but tagged all incoming calls as "unknown (private)"

On my system there is an atftp running, but did not work very well.
For some reason it did not find all files in the tftp folder.

So when trying to install a new firmware it failed already when loading new files.

Playing around the tftp client from a remote machine and tcpdump on the atftp server showed me, that the atftp even did not receive all requests.
As I had installed the daemon out of the box and never did more configuring than setting the root folder, I started to look for the tweaks.

First stop was to enable a separate log file and the verbose flag:
################/etc/default/atftp######################
USE_INETD=false
OPTIONS=" --tftpd-timeout 300
--port 69
--retry-timeout 5
--mcast-port 1758
--mcast-addr 239.239.239.0-255
--mcast-ttl 1
--maxthread 100
--verbose=7
--logfile /var/log/atftp.log
/var/tftpdir"
###################################################

After triggering "service atftp restart; tail -f /var/log/atftp.log" I ended up with a "file not found".
So I created the file with a "touch /var/log/atftp.log" and restarted again.
Now I got a line like this:
"...
Oct 03 23:29:27 derdapp003 atftpd[8859.-1224986096]: Advanced Trivial FTP server started (0.7)
Oct 03 23:29:27 derdapp003 atftpd[8860.-1224986096]: atftpd: can't bind port :69/udp
..."
Uups... hey... WTF...
Searching the world I found many hint point out "inetd". And indeed the file
/etc/inetd.conf showed this line:
"...
tftp dgram udp4 wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /var/tftdir
..."

This line initiates the inetd tftp configuration and somehow seems to start it own daemon, blocking atftp. That's why I got some answer from the tftp server, but not the correct one.
A quick "#" at the beginning of the line solved that one.

Now when restarting the atftp I got only this line on the log:
"...
Oct 03 23:38:26 derdapp003 atftpd[1321.-1224838640]: Advanced Trivial FTP server started (0.7)
Oct 03 23:43:48 derdapp003 atftpd[2003.-1224953328]: Advanced Trivial FTP server started (0.7)
Oct 03 23:46:09 derdapp003 atftpd[2032.-1225088496]: Advanced Trivial FTP server started (0.7)
..."

Hmm... This is verbose mode 7??? Never ever....
During the search though the net, I got some hints about permission issues on the root folder of the tftp server. I found an advise to set the user in the configuration to some other. Default is "nobody" (btw, is that a real user? ;-) ).
So I added
"...
--user=root
..."
to the configuration -don't panik, just for testing!!
And guess what, it now works. The logfile shows:
"...
Oct 04 00:02:04 derdapp003 atftpd[2767.-1225154032]: Advanced Trivial FTP server started (0.7)
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   running in daemon mode on port 69
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   logging level: 7
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   directory: /var/tftpdir/
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   user: root.nogroup
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   log file: /var/log/atftp.log
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   not forcing to listen on local interfaces.
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   server timeout: Not used
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   tftp retry timeout: 5
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   maximum number of thread: 100
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   option timeout:   enabled
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   option tzise:     enabled
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   option blksize:   enabled
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:   option multicast: enabled
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:      address range: 239.239.239.0-255
Oct 04 00:02:04 derdapp003 atftpd[2768.-1225154032]:      port range:    1758
..."

Having the logfile in place I turn back to the tftp client and tried to "put" and "get" some files, which worked now.
The next step was putting the logfile away from the /var/log folder, which is more or less reserved for "root".
I changed it to write into the tftp root folder:
"...
--logfile /var/tftpdir/atftp.log
..."
and deleted the user setting. But again, when starting the service, only the "server started" message appeared. So I did a "chown nodody /var/tftpdir/atftp.log" and it started to log again.

I turned back to the tftp client.
But whatever I tried, I always got an "Error 2: permission denied" or "file not found".
summarizing the threads on the net it turned out, that the FOLDER has to have execute permission.
So I did a "chmod 777 /var/tftpdir".
For the files most threads state to set "666", so I did a "chmod 666 /var/tftpdir/*".
And as I have a subfolder for the language packs on the cisco phones, I also need to do a:
"chmod 777 /var/tftpd/germany" and "chmod 666 /var/tftpd/germany/*"
And hurray, it worked.

To my honest opinion from security perspective, this is catastrophic, but... well its a tftp ;-)

Now I got the tftp running. As I wanted to upgrade my 7940, we now can turn to that task.
My first steps were to upload the P0030801SR02 and configure the control files
SEP[macaddress].cnfxml and XMLDefault.cnf.xml
Only those two files are needed to run the upgrades.
I found several hints to a very huge XMLDefault.cnf.xml containing all kind of devices, but for me this was far enough:
###################XMLDefault.cnf.xml####################
<Default>
    <loadInformation7 model="Cisco 7960">P0030801SR02</loadInformation7>
    <loadInformation8 model="Cisco 7940">P0030801SR02</loadInformation8>
</Default>
##########################################################
The corresponding part in the SEP[MAC].cnf.xml:
 [...]
<versionStamp>{Okt 03 2017 22:36:00}</versionStamp>
<loadInformation>P0030801SR02</loadInformation> 
[...]

Now to the phone. The soft reset sequence is [MENU] -> "**#**". Now You can see on the phone and on the tftp log file, that it loads "P0030801SR02.loads" BUT.....
it does not install it. It even does not return any error code.
My installed firmware was "P00307020200". Well, ok, from other software products, I know that some release changes are only available, if You walk through every single version.
As I have had "P00307020400" allready on the drive, I configured that version and... failed.....
"Häää???" WTF...???
I checked the Cicso archive and found, that I was right with this version to be the next available. There was no "P00307020300" as a step in between.
It took me some hours, before I quit and did a last desperate attempt.
I created a cisco account and downloaded the version fresh from their pages.
I made an MD5 check on my version and the "new" downloaded version. Both where the same.
Nevertheless I pushed the new files to my tftp and did a reset on the phone, changing nothing else...and it worked. The phone started the "verifing load" process and did a successful update to version 7.2(4).
Unbelievable!!
And all in all, that is what is is about. Make a fresh load from the Cisco websites and do it version by version as described above.

I hope this helps anybody anytime.
btw: The CallerID "unknown" went away with version 8.0(3).

-------------Some Links to the tools mentioned in this article------------------
**Asterisk VoIP Server: 
**Skinny replacement CHAN_SCCP:
**advanced tftp server
**Cisco 7940 downloads