Sorry. I realized I was working from an out-of-date version of gw/msg-decl.h. I was missing some components of the message. Thanks, Garth
On Mon, Oct 11, 2010 at 3:46 PM, Garth Patil <[email protected]> wrote: > 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 >>> ------------------------------------------------------------------- >>> >>> >> >> >
