Hi,
You have truncated logs, so I will have to take a wild guess about it. It
would seem that you received the SMS with fakesmsc client, which replies to
bb with its own ACK. At that point bb deletes the original SMS. So, when you
send in your own ACK, bb can no longer find the original SMS.
BR,
Nikos
----- Original Message -----
From: "Garth Patil" <[email protected]>
To: "Users mailing list" <[email protected]>
Sent: Tuesday, October 12, 2010 12:26 AM
Subject: Re: box protocol?
Hi,
Thanks for pointing me in the right direction. I have a question about
a behavior I am seeing from the bearerbox. Let me know if this is
better suited for the dev mailing list.
# I receive a message like this from the bearerbox (initially sent by
the fakesmsc):
000000B1 00000002 00000003 31323300 | ........ ....123.
00000333 3435FFFF FFFF0000 00036E6F | ...345.. ......no
704CB376 A8000000 0446414B 45FFFFFF | pL.v.... .FAKE...
FFFFFFFF FFFFFFFF FFFFFFFF FF000000 | ........ ........
24613236 35666335 312D3431 62302D34 | $a265fc5 1-41b0-4
3864662D 38643661 2D333739 61316264 | 8df-8d6a -379a1bd
64633662 34000000 00FFFFFF FFFFFFFF | dc6b4... ........
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF | ........ ........
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF | ........ ........
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF | ........ ........
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF | ........ ........
FF000000 00 | .....
# Which I parse to this:
Length: 177 = 0 0 0 -79
Type: 2 = 0 0 0 2
sender: 3 = 0 0 0 3 | 123
receiver: 3 = 0 0 0 3 | 345
udhdata: 0 = 0 0 0 0 | <NIL>
msgdata: 3 = 0 0 0 3 | nop
time: 1286829736 = 76 -77 118 -88
smsc_id: 4 = 0 0 0 4 | FAKE
service: 0 = 0 0 0 0 | <NIL>
account: 0 = 0 0 0 0 | <NIL>
uuid: 36 = 0 0 0 36 | 59650890-178e-48b7-9050-04a67315e532
sms_type: 828531812 = 49 98 100 100
mclass: 1664508468 = 99 54 98 52
mwi: 0 = 0 0 0 0
coding: -1 = -1 -1 -1 -1
compress: -1 = -1 -1 -1 -1
validity: -1 = -1 -1 -1 -1
deferred: -1 = -1 -1 -1 -1
dlr_mask: -1 = -1 -1 -1 -1
dlr_url: 0 = 0 0 0 0 | <NIL>
pid: -1 = -1 -1 -1 -1
alt_dcs: -1 = -1 -1 -1 -1
rpi: -1 = -1 -1 -1 -1
charset: 0 = 0 0 0 0 | <NIL>
boxc_id: 0 = 0 0 0 0 | <NIL>
binfo: 0 = 0 0 0 0 | <NIL>
msg_left: -1 = -1 -1 -1 -1
priority: -1 = -1 -1 -1 -1
# I try to send an ack to the bearerbox with the UUID that was sent:
00000034 00000003 00000000 4CB37E8D | ...4.... ....L...
00000024 35393635 30383930 2D313738 | ...$5965 0890-178
652D3438 62372D39 3035302D 30346136 | e-48b7-9 050-04a6
37333135 65353332 | 7315e532
# But the bearerbox believes that it is for a nonexistent message:
2010-10-11 14:15:57 [14822] [5] INFO: Client connected from <127.0.0.1>
2010-10-11 14:15:57 [14822] [5] DEBUG: Started thread 10
(gw/bb_boxc.c:function)
2010-10-11 14:15:57 [14822] [10] DEBUG: Thread 10
(gw/bb_boxc.c:function) maps to pid 14822.
2010-10-11 14:15:57 [14822] [10] DEBUG: Started thread 11
(gw/bb_boxc.c:boxc_sender)
2010-10-11 14:15:57 [14822] [11] DEBUG: Thread 11
(gw/bb_boxc.c:boxc_sender) maps to pid 14822.
2010-10-11 14:15:57 [14822] [11] DEBUG: send_msg: sending msg to box:
<127.0.0.1>
2010-10-11 14:15:57 [14822] [11] DEBUG: boxc_sender: sent message to
<127.0.0.1>
2010-10-11 14:15:57 [14822] [10] ERROR: BOXC: Got ack for nonexistend
message!
2010-10-11 14:15:57 [14822] [10] DEBUG: Msg object at 0x88ac458:
2010-10-11 14:15:57 [14822] [10] DEBUG: type: ack
2010-10-11 14:15:57 [14822] [10] DEBUG: ack.nack: 0
2010-10-11 14:15:57 [14822] [10] DEBUG: ack.time: 1286831757
2010-10-11 14:15:57 [14822] [10] DEBUG: ack.id:
59650890-178e-48b7-9050-04a67315e532
2010-10-11 14:15:57 [14822] [10] DEBUG: Msg object ends.
2010-10-11 14:15:57 [14822] [10] DEBUG: boxc_receiver: got ack
2010-10-11 14:15:58 [14822] [10] INFO: Connection closed by the box
<127.0.0.1>
Does anyone have an idea of what might be wrong with my interpretation
of the message or the ack I am trying to send back?
Thanks,
Garth
On Sun, Oct 10, 2010 at 10:26 AM, Stipe Tolj <[email protected]> wrote:
Nikos Balkanas schrieb:
Box's are passing Msg * structures between them. The protocol is very
stable and has changed only once if I remember correctly. For a
description check the gwlib/msg.h.
in addition to Nikos answer, let me add some details:
We use the msg struct for the sms and ack message type, which corresponds
to a
Req/Resp paradigm in classical client/server architectures. So, ie. in the
MT
case a smsbox connection passes a msg type 'sms' to bearerbox, and
bearerbox
responds with a msg type 'ack' to the smsbox for it.
It's a TCP connect we use, where we simply serialize the msg structs in a
very
easy octstr byte chain, see gw/msg.[ch] for the coding details.
Stipe
--
-------------------------------------------------------------------
Kφlner Landstrasse 419
40589 Dόsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
