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 > ------------------------------------------------------------------- > >
