Cid not found

Legacy Open AT
1

I’ve got an application running that has a tcp socket connection to a server. Sometimes I see the following trace message:
001;ADL;1;[WIP] CID NOT FOUND[5]
Can somebody tell me what this means?
the application is running perfectly so I don’t understand it.

thanks

2

Could you post some more context - that might give a clue?

Have you asked your Distributor or FAE?

It could be something that WIP just corrects internally?

3

Hey

I’ve also noticed this trace. It occurs when you have a bearer open, and a +CREG unsolicited message is received. It doesn’t seem to cause any problems, but I can’t find what generates it. I’ve just been ignoring it.

4

Hi,

We have also noticed this trace.
It causes problems to our ISP RADIUS server, because we use our devices in a VPN network.
As a result, our ISP activated data barring on our SIM cards.

Below is the description of the problem from our ISP:
The problem is located in customer device, which is sending PDP activation requests although there is an active PDP connection and normal payload. These PDP activation requests are coming extremely frequently and from traces we have verified that it happens every time device is changing location (cell update). Thus this is not an expected behavior and customer should seek advice from his vendor, regarding modem specs or configuration.

This is the reply from the Sierra FAE:
[i]The reception of "[WIP] CID NOT FOUND[5]” from WIP point of view may be due to following reasons

  1. GPRS session de activated
  2. Network loss
  3. the Username, password credentials are not valid
  4. when a PDP activation requests is sent using WIPLib when already an active PDP connection is present, etc.[/i]

We have tried our devices with a different ISP but the problem still exists.
We have sent traces from our devices to the Sierra FAE several times.
The Sierra FAE is looking for a solution for two months now.

5

Are you sure it’s +CREG and not +CGREG ?

Mind you, I guess they probably come together…?

That would, indeed, correspond to receipt of a +CREG (and/or +CGREG) response.

Indeed!

Is your application restarting the Bearer each time it sees a +CREG (and/or +CGREG) response?

If it is, as your original ISP suggested, due to your device “sending PDP activation requests although there is an active PDP connection” - then it would make no difference what ISP you use!

That would be a Bearer-level problem - which is below the ISP level.

6

No, our application do not restart the bearer each time it sees a +CGREG.
Moreover, the problem mentioned above exists in Sierra’s Gateway sample too.
So I don’t think the problem is caused by our custom OpenAT application.

7

What about +CREG?

I would check that very carefully: some of the SiWi examples are, how shall we say, “questionable”… :unamused:

8

I did a grep through some old traces, and found this:

So when a[WIP] CID NOT FOUND[5] happens, it’s always on an unsolicited +CREG/+CGREG - but not every +CREG/+CGREG causes a [WIP] CID NOT FOUND[5]

It happened in 2 logs out of 140.

9

No, our application do not restart the bearer each time it sees a +CREG.

Only if the cell has changed.

10

Yes, i also can see this messages on every cell change. And my GSM operator reports about multiple unused PDP contexts created by modems. Currently looking for workaround.

11

Quite so.

So, to be more precise, I should have said:

So when a[WIP] CID NOT FOUND[5] happens, it’s always on an unsolicited +CREG/+CGREG indicating a cell change - but not every +CREG/+CGREG indicating a cell change causes a [WIP] CID NOT FOUND[5]

Which, again, ties-up with what your ISP said…

12

On our devices, a[WIP] CID NOT FOUND[5] always happens on an unsolicited +CGREG indicating a cell change.

Report your problem to the Sierra FAE.
They may find a solution faster, if there are many tickets on the problem.

13

Of course. But some more info needed.

Also i noticed that cell change always accompanied by ADL_GPRS_EVENT_ME_ATTACH notification. If this means GPRS attach, i dont sure its normal to repeat attaches while already in active mode… Network also can request modem to repeat attach for its own purpose…

And about this [5] in message - what is it? PDP context ID? Maybe it is CID, requested by network? With valid CID numbers from 1 to 4 it is for sure invalid.

Or maybe modem wrongly threat as CID NSAPI identifier, which always 5 in simple applications as i see.

14

From 7.45 FW release notes:

Is this our case? :question:

15

Field tests confirm this bug is fixed in 7.45 firmware.

16

Is this a generic problem so we should all be moving to R7.45 because of it? We do get occasional connection losses/dropped connections, but no specific report back from the ISP, so I’m not sure if it is affecting us.

17

I think yes. But not always critical.

You can request PDP connections statistic for your modem group. In our case we have ~6000 PDP-sessions active for ~2000 modems. Most critical was fact that every context reactivation (2 times in minute on certain modems) generate DHCP request, sometimes leading to DHCP-servers overload.

18

The problem exists in 7.45 firmware.
We are still getting the [WIP] CID NOT FOUND[5] trace.

19

It seems that just getting the trace, in itself, is not necessarily a problem?

Do you just get the trace, or do you also see other problems resulting from it :question:

20

Exactly. Check release note text.