Deutsche Telekom gives you online access to the bills they want you to pay: Rechnung Online
Of course I felt intrigued to perl-script this thing (exactly: Rechnung Online / Standard Version), and here you find my TAR ball: (TAR ball still to be prepared, but you can drop me a line)
It downloads all bills it finds, i.e. for all months still accessible together with printable (PDF!) reports and CSV formatted call records.
online configuration of ISDN MSN-s (I would actually love a sort of routing tables here: calls from that caller id go ...)
Am 2006-09-26 postete ich unter dem Titel „Router vs. strenge Kompatibilitätsliste?!!!!!“ den folgenden Text im Customer Care Forum von Siemens für das Gigaset C450 IP, Siemens' im Sommer 2006 erschienenes DECT-SIP-Telefon. Vielleicht habe ich den hier folgenden Text inzwischen auch schon geringfügig, ganz geringfügig geändert.
Vorab: Ich bin eigentlich von der Idee eines DECT-SIP-Telefons sehr begeistert, deswegen habe ich mir dieses Gerät auch zugelegt.
Aber ...
Kann es sein, dass es eigentlich gar nicht viele Router gibt, mit denen dieses Gerät "out-of-the-box" gut zusammenarbeitet?
Zuerst hatte ich einen Netgear FR328S dran, mit dem lief es nicht gut. OK, ich habe ja noch mehr Router (hauptsächlich und eher Netgear) zur Auswahl, also war als nächster der DG824B dran, ebenso mies. Was die Probleme sind? (Auf englisch, weil ich Computer-Zeugs etc. lieber auf englisch mit mir sprechen lasse:) Schon bei "Select VoIP Provider" sagt das Ding zu mir: "Server not available!"
OK, OK, das Gerät ist ja eigentlich schon längst konfiguriert, also bräuchte ich in diesen Menü-Punkt ja gar nicht mehr, aber ich glaube gelernt zu haben, dass das eine triviale Möglichkeit ist, zu prüfen, ob das Gerät überhaupt einen funktionierenden Internet-Zugang hat. Wenn es dazu insgesamt mal eine detaillierte Check-Liste für Nicht-DAUs gäbe, dann würde ich die ja gerne anwenden, z.B. um zu checken, ob dieses und jenes geht: „Mach mal aus einem "Nachbar-Rechner" aus dem selben LAN ein "telnet DOWNLOAD-SERVER PORT-XY". Und geht das?“ Wenn man mir zu dem Linux auf der Kiste Zugang gäbe, dann würde ich die Tests auch gerne von dort tätigen.
Zwischendurch und wie aus heiterem Himmel und ohne, dass ich etwas dazu tat, „geht dann alles“, zumindest sieht die Status-Anzeige ganz gut aus.
Was kann ich noch an Informationen beisteuern? Ich habe mit einem sipgate.de-Account angefangen, weil's dazu beim Kauf einen Voucher gab. Ich habe ein Port-Forwarding für 3 UDP-Ports in eingehender Richtung eingerichtet, weil es ohne noch viel weniger ging: 5060 (SIP-signalling), 5004 (RTP), 10000 (STUN). Firmware: 10.29. Feste IP-Adresse, weil's mit DHCP eher noch schlechter lief.
Kann es sein, dass STUN einfach nicht gut läuft mit den gebräuchlichen Routern?
Kann es sein, dass Port-Forwarding auf UDP-Ports einfach nicht das normale ist?
Kann es sein, dass man nach dem Telefon einen Router anschaffen muss, mit welchem die Entwickler bislang getestet haben und mit welchem sie auch zukünftig testen - nur damit man absolut auf der sicheren Seite ist?
Sorry, wenn das nach rhetorischen Fragen klingt, aber sie sind schon wirklich auch einigermaßen rhetorisch gemeint.
Und ich würde mich wohl sogar auch darauf einlassen, einen Router auf Empfehlung der Entwickler anzuschaffen. Ich habe schon (Modem-)Router von Netgear, Linksys und AVM / Fritz!Box benutzt, und eigentlich kommen für mich persönlich solche Kisten nicht in Frage, auf welchen ich dem eingebauten DHCP-Server (oder evtl. sogar DNS-Server) kein festes Mapping MAC-Adressen auf lokale IP-Adressen vorgeben kann. (Von daher also eher keine Fritz!Box, auch wenn mir das Teil ansonsten ganz gut gefällt) Ansonsten bin ich einigermaßen leidenschaftslos.
Bis jetzt sieht es für mich einfach danach aus, als würde ich von
sipgate.dedie 555 Frei-Minuten bekommen, damit ich innerhalb des ersten Monats endlos experimentieren kann, bis es vielleicht endlich anstandslos klappt. Lieber schaffe ich mir aber noch einen neuen Router an, bevor ich in diesem Zusammenhang meine Zeit vertrödle.Aber kurzum: Bis jetzt sieht die Situation für mich eigentlich eindeutig nach Fehlkauf aus. Und wenn ich das Teil bis in 2 Wochen nicht völlig in den Griff bekomme, dann gehe ich zu Conrad an der Urania (Berlin), leg denen das Teil auf den Tisch und will mein Geld zurück.
Für mich sieht das wirklich noch nicht ganz ausgereift aus und ich konnte mir bei Siemens doch nicht vorstellen, dass die so ami-mäßig Banana-Ware ausliefern würden. [1]
So! Nix für ungut! Aber eigentlich will ich das Teil wirklich gerne ab sofort und zu 99% zuverlässig benutzen können, selbst wenn ich damit via SIP nicht billiger telefonieren kann, als wenn ich mit 2 oder 3 günstigen Vorwahlen via Festnetz arbeite. An diese Vorwahlen komme ich via
www.billigertelefonieren.de, und so billig anscheinend mit keinem SIP-Provider.
Ergänzungen:
Inzwischen habe ich das Gerät auch mal in die DMZ meines Routers gesetzt, was ihm anscheinend (kurzfristig) auch nicht geschadet hat, aber ob es geholfen hat???
These devices support 802.11b, and 802.11g.
WG511 -> 32-Bit CardBus card
WG602 -> access point
WGR614 - router w/ integrated access point
These devices support just 802.11b.
MA401 -> 32-Bit CardBus card
...
It has a detachable aerial (unlike the WGR614), and I want to attach a slightly more powerful external one instead; it shouldn't be that difficult to cover the entire center of West Berlin, should it? We shall see. Yes, until then at the latest I will protect my LAN from my WLAN with yet another firewall, just as the WLAN gurus suggest.
...
Of course, I had no problem getting this card to run under WinXP and Win2000 and to let it communicate with their WGR614.
The crucial question is actually, how to get it running under SuSE Linux.
This is what I got reported into syslog, when I first inserted it:
May 20 23:44:19 HayekA kernel: cs: cb_alloc(bus 6): vendor 0x1260, device 0x3890
May 20 23:44:19 HayekA kernel: PCI: Enabling device 06:00.0 (0000 -> 0002)
May 20 23:44:19 HayekA cardmgr[3748]: socket 1: CardBus hotplug device
May 20 23:44:20 HayekA /sbin/hotplug[26628]: /sbin/hotplug pci
May 20 23:44:20 HayekA /sbin/hotplug[26628]: HOME=/
May 20 23:44:20 HayekA /sbin/hotplug[26628]: PATH=/bin:/sbin:/usr/sbin:/usr/bin
May 20 23:44:20 HayekA /sbin/hotplug[26628]: ACTION=add
May 20 23:44:20 HayekA /sbin/hotplug[26628]: PCI_CLASS=28000
May 20 23:44:20 HayekA /sbin/hotplug[26628]: PCI_ID=1260:3890
May 20 23:44:20 HayekA /sbin/hotplug[26628]: PCI_SUBSYS_ID=1385:4800
May 20 23:44:20 HayekA /sbin/hotplug[26628]: PCI_SLOT_NAME=06:00.0
May 20 23:44:20 HayekA /sbin/hotplug[26628]: invoke /etc/hotplug/pci.agent
May 20 23:44:22 HayekA /etc/hotplug/pci.agent[26635]: ... no modules for PCI slot 06:00.0
I then read, I should launch a cardctl ident in order to display the card identification strings.
Socket 1:
product info: "Intersil", "ISL3890", "-", "-"
manfid: 0x000b, 0x3890
function: 254 ((null))
The chipset of the card was mentioned on the lwlan-devel mailing list:
I didn't even attempt to use this device under WinXP -- I simply had / have no need to.
It was pretty clear, that the card would run under SuSE-Linux 8.2 with their patched 2.4.20 Linux kernel and the Linux Kernel Card Services 3.1.22.
It still took me a while, to get everything as nice, as I want it.
This article supplied by SuSE helped me a lot: Wireless LANs with SuSE Linux.
SuSE Linux employs the orinoco module for the PrismII chipset,
and avoids WLAN-NG.
They attempted to remove all cards using the PrismII from the WLAN-NG system,
but apparently they didn't consider Netgear's MA401,
so I had to comment out that card myself in /etc/pcmcia/wlan-ng.conf.
They also describe, you yourself would have to prepare an entry
in /etc/pcmcia/config[2].
After this amendment everything is fine with the basic configuration.
Because when I initially started with WLAN and the Netgear stuff for it, I assumed I would only work with 802.11g equipment for the time being, but as I now would have to integrate a "just 802.11b" NIC, I had to change one setting for my WGR614 in the “Wireless Settings” section: Instead of just “g” I set the to “g and b”.
And as setting up an environment with basic settings (and later progressing to the more advanced levels) makes life much easier than diving into a complicated set-up from the very beginning, I changed my to “Disable” and the to “Automatic”.
Finally I changed the back to “Shared Key”, which corresponds to a “iwconfig eth0 key restricted” on the Linux side; actually Open System (resp. open on the Linux side) means, the interface accepts non-encrypted packets only, whereas Shared Key (resp. restricted on the Linux side) means, the interface discards non-encrypted packets.
And I also changed the back to “128bit”; I assume, on the Linux side they seek to use exactly that encryption strengh, that works fine with the access point or whatever, therefore there is no settings variable for that.
Only from looking at the shell script /etc/sysconfig/network/scripts/ifup-wireless
I found, that the proper way to set the authentication type to restricted
is to set WIRELESS_IWCONFIG_OPTIONS="key restricted"
in /etc/sysconfig/network/wireless.
Otherwise you just have to set WIRELESS_ESSID and WIRELESS_KEY[3]
as needed, and set WIRELESS_MODE='Managed',
corresponding to Infrastructure.
Through /etc/sysconfig/network/ifcfg-eth-pcmcia and /etc/sysconfig/network/wireless
you can't define an entire set of WEP keys
and let one of them be the active one.
Therefore I wrote my script /etc/sysconfig/network/JH_set_keys.sh,
that defines every single WEP key (1 through 4) of a set
and makes one of them the active one:
iwconfig eth0 key 'aaaaaaaaaaaaaaaaaaaaaaaaaa' '[1]' iwconfig eth0 key 'bbbbbbbbbbbbbbbbbbbbbbbbbb' '[2]' iwconfig eth0 key 'cccccccccccccccccccccccccc' '[3]' iwconfig eth0 key 'dddddddddddddddddddddddddd' '[4]' iwconfig eth0 key '[2]'
Actually I got the impression, that this software finds the matching key itself und does not need explicit setting.
Nokia's support area for the D211;
for the Linux device driver registered users will get
the “support guide” (that's the instuctions the installer has to follow), a .tar.gz source archive, and one of two .tar.gz binary archives (originally meant for Redhat Linux),
the binary archive depends on which gcc was used for compiling your Linux system libraries,
a version >=3.2 or a lower one -- SuSE Linux 8.2 was compiled using a gcc version 3.3
a couple of useful links on the Hannu Valtanen Ltd laptop web page
Markku Mikael Hautamäki's thesis;
did anybody ever find the appendices of the thesis?
This card talks WLAN, GPRS, and HSCSD.
Nokia provides the Linux community with working drivers, but actually they only support Redhat Linux. There are ways to get it functional under SuSE Linux and Debian Linux as well. And I want to describe, what I did for SuSE Linux 8.2.
There is an issue with the use of initlog within /etc/pcmcia/nokia_cs.
initlog is a utility, that is not known on SuSE and Linuxes than Redhat,
and I replaced the initlog line by this one:
... (to be done) ...
Be really sure, you copy it to a system directory, that is actually on the PATH!
... (to be done) ...
nokia_ctl gsm enable_gsm nokia_ctl gsm enableGSMradio # asks for the PIN code of the SIM card
Adopt d211/scripts/wvdial.conf to your needs!
I added this for T-Mobile account:
[Dialer operator_t_mobile]
Init4 = AT+CGDCONT=,,"internet.t-d1.de"
Phone = *99#
Username = Ihr_Name
password = t-d1
Yes, I know, T-Mobile wants you to use your name, but I like Ihr Name better.
Comment out lcp-echo-interval and lcp-echo-failure!
I found this advice in Markku Mikael Hautamäki's thesis,
as you don't want to have an idle timeout after 2 minutes,
if you only pay by data transmitted and not by connection time.
Jean Tourrilhes' article “Wireless LAN resources for Linux”
The SuSE article on “Wireless LANs with SuSE Linux” mentioned above pointed me to Airsnort, a set of patches to standard Linux software and some extra software, allowing NIC-s based on the PrismII chipset to work in a monitor mode, basically allowing to NIC to capture the WLAN network traffic for concurrent sniffing. The sofware also helps cracking the WEP keys. This sounds rather frightening. In their FAQ they have an item “About how long would it take to get the password for a network with AirSnort?”, that I think is worth reading and digesting.
AirSnort requires approximately 100M-1GB of data to be gathered. Once enough packets have been gathered, AirSnort can guess the encryption password in under a second.
URL-s:
My humble statement on security in WLAN-s:
Alright, let us consider a WLAN just as insecure as the Internet out there; it's not, but let us assume this for the time being!
You do employ VPN software like OpenVPN to safely communicate with you company LAN over the Internet, don't you?
So go and do the same with your WLAN!
www.WiMo.de -- ...
www.WiMo.de -- WLAN FAQ -- ...
www.NodeDB.com -- The Wireless Node Database Project
my separate article on using GPRS under Linux
Nobody knows, when they are able to provide us with UMTS.
URL-s:
Kunden-Service (incl. Rechnung Online, SMS via web; no calls redirection yet, and far away from routing tables)
Home >> Dienste >> Mobil im Ausland >> T-Mobile Roaming >> Länderauswahl & Preise