Is that true when the message is originating in the fakesmsc? My setup is: [fakesmsc] <-> [bearerbox] <-> [something like the smsbox]
I'm sending a message from the fakesmsc using the command: > ./test/fakesmsc -H 127.0.0.1 -r 20000 -m 1 "123 345 text nop" Which yields the following the bearerbox logs: 2010-10-11 14:54:56 [16534] [6] INFO: Fakesmsc client connected from 127.0.0.1 2010-10-11 14:54:56 [16534] [6] DEBUG: smsc_fake: new message received 2010-10-11 14:54:56 [16534] [9] DEBUG: send_msg: sending msg to box: <127.0.0.1> 2010-10-11 14:54:56 [16534] [9] DEBUG: boxc_sender: sent message to <127.0.0.1> The bearerbox then sends a message to the smsbox (or in this case, a client that I'm creating to behave like the smsbox) with a uuid. The smsbox replies to the message with an ack with the success status and the same uuid. However, the bearerbox doesn't seem to recognize the uuid, so it keeps the message in the queue, even though the uuid that is received by the smsbox and sent back in the ack is the same. 2010-10-11 14:54:56 [16534] [8] ERROR: BOXC: Got ack for nonexistend message! 2010-10-11 14:54:56 [16534] [8] DEBUG: Msg object at 0x9811a60: 2010-10-11 14:54:56 [16534] [8] DEBUG: type: ack 2010-10-11 14:54:56 [16534] [8] DEBUG: ack.nack: 0 2010-10-11 14:54:56 [16534] [8] DEBUG: ack.time: 1286834096 2010-10-11 14:54:56 [16534] [8] DEBUG: ack.id: 602613a5-b878-4a96-b878-cd8ac10dc00c 2010-10-11 14:54:56 [16534] [8] DEBUG: Msg object ends. 2010-10-11 14:54:56 [16534] [8] DEBUG: boxc_receiver: got ack The ack I am creating looks like this: 00000034 00000003 00000000 4CB387B0 | ...4.... ....L... 00000024 36303236 31336135 2D623837 | ...$6026 13a5-b87 382D3461 39362D62 3837382D 63643861 | 8-4a96-b 878-cd8a 63313064 63303063 | c10dc00c So, a couple of questions: 1. Is there anything about the ack I am creating that looks incorrect/incomplete, even though the bearerbox appears to be parsing it correctly? 2. Is there a way to list the outstanding messages in the bearerbox that have not yet been delivered to the smsbox? 3. Is there a way to output the raw (hex encoded) box messages in debug statements as they are passed between the bearerbox and smsbox? I'd like to look at the raw messages from the smsbox so I can model my own implementation on those. Thanks, Garth 2010/10/11 Nikos Balkanas <[email protected]>: > 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 >> ------------------------------------------------------------------- >> >> > >
