I have experienced crashing with Nokia 7110 as well. From SMSC perspective
SM is delivered, but visually observing phone hasn't received it. And what's
most nasty, it's not able to receive SM anymore until next reset.
Also the problem can reside in SMSC or even in signaling level. I have seen
An important note to this is, that we've only experienced it recently
(last 3 weeks or so), using the oct22 kannel - we've been using
kannel since february, without noticing similar 'stuff'.
Hi Aarno,
I think I know what's going on. The key is the following comment:
/*
* We support networks using IP as a bearer and GSM using SMS as bearer, so
we
* must reject others. Default bearer is IP, it is (currently) not-SMS.
After
* the check we change meaning of the
OK, a slight correction:
select_bearer_network correctly modifies bearer/network_required.
Unfortunately this is not what Kannel actually uses. It uses the
old copy of the data stored in the PPGPushMachine.
Regards
Jörg
-Original Message-
From: Jörg Pommnitz
To: 'Aarno Syvänen ';
I don't have a strong opinion in this matter, so I won't argue.
I would suggest, however, to make the communication of the
bearer more explicit. The current overloading of the
bearer/network_required fields seems hackish to me.
Regards
Jörg
-Ursprüngliche Nachricht-
Von: Aarno
Hi Jörg,
Jörg Pommnitz wrote:
I don't have a strong opinion in this matter, so I won't argue.
I would suggest, however, to make the communication of the
bearer more explicit. The current overloading of the
bearer/network_required fields seems hackish to me.
Yes. I will change that, so
I'm getting a hell lot more messages than expected
in one of my machines.
First, bearerbox crashes with the "too many
concurrent allocations" because the
store.lock gots to big (1700 messages, 38KBytes is
big?).
Then I've compiled with native malloc and I got the
same error.
Then I've
Then I've compiled with native malloc and I
got the same error.
You only see this with the gw_check_ interface and
you won't
getthis withnative malloc, so check your
build again.
Then I've added a throughput delay in EMI2 inside
the receive messages while, to
2001-11-29 07:49:27 [0] DEBUG: Started thread 5
(gwlib/http.c:write_request_thread)
2001-11-29 07:49:31 [6] INFO: Starting to service
key from number to number2001-11-29 07:49:31 [5]
DEBUG: HTTP: Sending request:2001-11-29 07:49:31 [5] DEBUG: Octet string at
0x404032f8:2001-11-29