MavEtJu's Distorted View of the World - 2006-02

Posted on 2006-02-17 14:34:25, modified on 2006-02-17 15:32:01
Tags: Rant, Mobile phones

The D600 is a nice looking phone, but it's user interface has some bad design issues.

• The D600 is sliding phone, which means you slide the top half forward to gain access to the keyboard. When entering a number, slide open the phone and then three quarters of it's weight is not in your hands anymore but dangling over your index finger. Often the only reason why it stays in your hand is because you keep your thumb close but you have to move it to enter the number to call.
• Putting the phone on hands-free-speaker looks like you have to press the up-button (because that's where the icon is), but you have to press the OK button. Bad choice of button. After that, you have to confirm that you want to go to hands-free-speaker, while you don't have to confirm that you want to go back to the normal operations.
• A contact can only have one home, one office, one fax and one mobile number.
• When browsing the contacts list, the contacts are shown up with their default number (most likely their mobile number).
  • Pressing OK on a contact will give you the read-only list with the name and the numbers belonging to that contact.
  • Pressing the phone button will give you the list of numbers belonging to that contact.
  So what's the deal? You're browsing through your contacts and want to make a call.
  • In the first one (OK button) pressing OK will bring you in the editor of the contact.
  • In the first one (OK button) pressing the phone button will call that number.
  • In the second one (phone button) pressing OK will call that number.
  • In the second one (phone button) pressing the phone button will call that number.
  The differences in what the OK button does do is way too confusing.
• The ring tone: There is no simple bleep-bleep ringtone, they're all full-spectrum songs.
• Incoming calls have three alerts: melody, vibration, and melody after vibration. Yes, there is no "vibration and melody starting at the same time". So you either have your phone in your pocket so you can feel it, or you have it in your backpack and hear it. But you can't switch because if it is in your backpack and the melody finally gets through, it's way too late to grab it and answer the call.
• When entering text messages, it doesn't follow the rule of "after a period comes a capital character", you have to press the one-capital-character-please yourself.

Posted on 2006-02-16 22:27:51, modified on 2006-02-16 22:28:58
Tags: Coding

This is while compiling zaptel on a FC4 linux machine with gcc 4.0.0.

No comments | Share on Facebook | Share on Twitter

Posted on 2006-02-15 13:22:52, modified on 2006-02-15 13:55:21
Tags: Networking, DNS, DDOS

Dear Script kiddies, Blackmailers and other thugs on the internet,

Please stop abusing my computer as a reflector for your 'greater plans' on the Internet.

Edwin

13:05

I get a phone call via my VoIP phone. Halfway the call, the call, it just drops dead and I see the phone rebooting. Funny, not something I see often since I moved from wireless ADSL to just-use-an-ethernet-ADSL.

My VPN connection is... getting... very... sluggish. Yes, sluggish is the word. Trafshow to the rescue!

Wonder why there is so much DNS traffic going on:

From Address                 To Address                   Prot      Bytes CPS
63.214.168.62..15796         192.168.1.1..53              udp       48193   11632
192.168.1.1..53              63.214.168.62..15796         udp       488276   65655

A general WTF comes up in my mind. Anyway, now that I know it's DNS traffic, let's see what it is.

# tcpdump -s 1500 -ni sk0 port 53
13:07:17.035118 IP 63.214.168.62.20435 > 192.168.1.1.53:  15043+ [1au] ANY ANY? x.p.ctrc.cc. (40)
13:07:17.035258 IP 192.168.1.1.53 > 63.214.168.62.20435: 15043- 1/1/2 TXT[|domain]
13:07:17.176355 IP 63.214.168.62.15879 > 192.168.1.1.53:  13909+ [1au] ANY ANY? x.p.ctrc.cc. (40)
13:07:17.176515 IP 192.168.1.1.53 > 63.214.168.62.20435: 13909- 1/1/2 TXT[|domain]
13:07:17.225230 IP 208.222.0.82.9761 > 192.168.1.1.53:  24263+ [1au] ANY ANY? x.p.ctrc.cc. (40)
13:07:17.225398 IP 192.168.1.1.53 > 208.222.0.82.9761:  24263- 1/1/2 TXT[|domain]

Somebody is asking my nameserver for x.p.ctrc.cc. Why me? And why do I give answers (and why is 1500 bytes not enough to hold the answer?

# ipfw -a l
ipfw add 50 deny udp from 63.214.168.62 to me dst-port 53
ipfw add 51 deny udp from 208.222.0.82 to me dst-port 53

Why does my nameserver actually answer this request? I mean, I'm not authoritative and I have disabled recursion and I have... oh wait... This new machine still has a virgin named running.

acl nobody {
        none;
};
acl everybody {
        any;
};
acl we {
        192.168.0.0/16;
        127.0.0.0/8;
};
options {
        allow-recursion {
                we;
        };
};

I forgot, the payload. Why wasn't 1500 bytes enough to hold the answer?

$ dig x.p.ctrc.cc any
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.1 <<>> x.p.ctrc.cc any
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55082
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;x.p.ctrc.cc.                   IN      ANY

;; ANSWER SECTION:
x.p.ctrc.cc.            81842   IN      TXT     "...............................
................................................................................
................................................................................
................................................................" ".............
................................................................................
................................................................................
................................................................................
.." "...........................................................................
................................................................................
[...]
............................................................................" ".
................................................................................
........"

;; AUTHORITY SECTION:
p.ctrc.cc.              81842   IN      NS      321blowjob.com.

;; ADDITIONAL SECTION:
321blowjob.com.         27224   IN      A       66.98.217.195

;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 15 13:30:05 2006
;; MSG SIZE  rcvd: 4015

That's 4015 bytes of data to be sent out for every request. No wonder my VoIP phone dropped out.

Keep your configurations secure. Do not allow SMTP relaying, do not allow DNS recursion. There are people out there who don't play nice.

Weblog finished :-)

Posted on 2006-02-08 17:58:54, modified on 2006-02-08 21:05:06
Tags: Voice over IP, IPMUX

The IPMux are TDMoIP (Time Division Multiplexer over IP) devices, to transport E1/T1s over an IP network.

The IPMux 8 requires a female DB9 serial cable for it's console, which comes default on 19200 bps. You can see it booting. If your cable doesn't set the DCD, you will see still see it booting, but the IPMux won't accept the data from it. So if you wonder why the IPMuxes don't respond to your keystrokes, make sure you use the cable coming with it!

The IPMux 11 on the other hand requires a male DB9 serial cable, and it set to 115200 bps (note the two differences). If you try to define the timeslots on a bundle on it, and the current bundle is active, it will not accept any changes but will only say "ERROR", while not giving a hint of what the error is. After disabling the bundle, you can edit the timeslots.