Yeah, probably this is related. Only I'm not sure how exactly. -----Oorspronkelijk bericht----- Van: l...@nozara.com [mailto:l...@nozara.com] Verzonden: woensdag 27 juli 2016 13:10 Aan: Rene Kluwen <rene.klu...@chimit.nl>; users@kannel.org Onderwerp: RE: SMPP Box binding after restart
Note sure if it's linked however every few hours I get: PANIC: Socket accept failed in smpp box logs, then the service crashes.. Checking the code it seems this would only occur if newconn == NULL . What could could cause this? On 2016-07-22 15:55, l...@nozara.com wrote: > I can see one is using Kannel from the logs they sent... > > I was thinking client side but odd they all come back a exactly the > same moment... > > > On 2016-07-22 03:34, Rene Kluwen wrote: >> Maybe it has something to do with the client software that the ESME's >> are using? >> >> -----Oorspronkelijk bericht----- >> Van: users [mailto:users-boun...@kannel.org] Namens l...@nozara.com >> Verzonden: donderdag 21 juli 2016 16:03 >> Aan: users@kannel.org >> Onderwerp: SMPP Box binding after restart >> >> Dear Users >> >> I have a strange issue that I can't seem to find the direct cause. >> >> I have running SMPP Box, with many ESME connected fine. It seems that >> when my Kannel Service is restarted many different ESME cannot rebind. >> SMPP Box log displays the following for those attempting to >> connection: >> >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: type_name: bind_transceiver >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: command_id: 9 = 0x00000009 >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: command_status: 0 = >> 0x00000000 >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: sequence_number: 1329 = >> 0x00000531 >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: system_id: "*****" >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: password: "*****" >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: system_type: NULL >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: interface_version: 52 = >> 0x00000034 >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: addr_ton: 1 = 0x00000001 >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: addr_npi: 1 = 0x00000001 >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: address_range: NULL >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: SMPP PDU dump ends. >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: SMPP[*****]: Sending PDU: >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: SMPP PDU 0x7f70f001f950 dump: >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: type_name: >> bind_transceiver_resp >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: command_id: 2147483657 = >> 0x80000009 >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: command_status: 0 = >> 0x00000000 >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: sequence_number: 1329 = >> 0x00000531 >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: system_id: "OurSytemId" >> 2016-07-21 11:20:00 [9301] [2504] DEBUG: SMPP PDU dump ends. >> 2016-07-21 11:20:00 [9301] [2504] ERROR: Invalid SMPP PDU received. >> >> Many other clients can bind fine however a minority cannot. The bind >> appears in the status page and then disconnects immediately. >> When I run packet traces I can see the bind_transceiver_resp is sent >> fine and is acknowledged. >> >> I'm thinking there has to be something ins SMPPLogins file that is >> different for these clients however nothing is obvious. All follow >> the same format as clients connected ok. >> >> The even more strange thing is that at some moment in time, 1-2 hours >> after the service restart, all of those failing connections magically >> bind ok. As if a timer or cache is preventing them all from >> re-connecting for a certain period... >> >> I've checked around the code source and previous issue but cannot >> find anything obvious. I'd appreciate any ideas on this. >> >> Thanks >> >> Lee
