Modem not able to connect to WAP Gateway to send MMS

Modem not able to connect to WAP Gateway to send MMS SearchSearch
Author Message
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 4
Registered: 07-2006
Posted on Monday, October 16, 2006 - 04:44 pm:   

Hi Bryce,
I have recently installed a Multitech GPRS modem on a server here in Canada, and although I am able to send SMS, when I set-up and try to test the MMS connection, I get the following error:
"Unable to connect to WAP Gateway"
To isolate the problem, I have tried several things:
1) With the same settings/modem/SIM I am able to connect to the MMS Gateway from a laptop running NOWSMS
2) I have tried testing the MMS connection with the modem connected to the server with a SIM / APN from another GSM operator in Canada to no avail
3) From the server I have been able to establish an AT#CONNECTIONSTART to the MMS APN from Hyperterminal

Any ideas of what else I can try?
Have you ever seen the situation before that SMS works but not MMS (if it were, for example, a problem with the driver)?
Thanks!
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 5
Registered: 07-2006
Posted on Tuesday, October 17, 2006 - 04:22 pm:   

Hi Bryce, I forgot to mention that the server we are running is a Windows 2003 server. Is there potentially some security feature to Windows 2003 Server that blocks the socket through the modem?

Thanks.
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 6687
Registered: 10-2002
Posted on Tuesday, October 17, 2006 - 07:48 pm:   

Hi Adrian,

I've got a Windows 2003 Server in my office with a Multitech modem attached, so I'm pretty confident that there is not any issue specific to Windows 2003 Server.

It is extremely bizarre that the same modem would work ok from a laptop.

The only thing that I can think of is that I remember an issue where someone was using "10." addresses on their network, and they had a similar problem connecting to Orange which assigned "10." addresses for GPRS connections.

Let me see if I can find that thread ...

http://support.nowsms.com/discus/messages/485/8026.html

I could never understand why this would be a problem, unless the IP address assigned through the GPRS connection was in direct conflict with an IP on the local network.

Enable the MMSWAPDEBUG.LOG, and that should include some IP address information in it ... maybe that will provide us with some clues.

-bn
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 6
Registered: 07-2006
Posted on Wednesday, October 18, 2006 - 01:07 am:   

Hi Bryce, I think we have located a key problem. The NOWSMS gateway creates a dial-up connection for the modem which dials the number *99# to establish a connection. We have verified that we are able to connect to the WAP gateway if the dial up number is *99***1#. When we change this manually in the dial-up settings the connection tests out correctly, however every time the NOWSMS Gateway attempts to establish a connection, it resets the dial-up number to *99#. Can we change this setting somewhere?

Thanks.
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 7
Registered: 07-2006
Posted on Wednesday, October 18, 2006 - 01:22 am:   

And the log file:

application/octet-stream
MMSCDEBUG.LOG (84.4 k)
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 6689
Registered: 10-2002
Posted on Wednesday, October 18, 2006 - 08:19 pm:   

Hi Adrian,

Actually we do dial *99***1# (or the "1" might be a "2" or some other value, depending on the AT+CGDCONT settings on the modem).

The profile that we create uses *99#, but we always override the phone number at dial time. (That's one of the reasons I'd like to see the log file, as it will tell us the current AT+CGDCONT settings.)

If you suspect the profile is a problem, you might want to try deleting it, and let it be recreated.

It is strange that it would work on one PC, but not on another ... is there any chance that you have extra "initialisation commands" defined for the modem in its setup under the Windows Control Panel? Could you check the modem driver there, and make sure that this setting for extra initialisation commands is blank? That's the only thing that I can think of.

It is also possible to configure NowSMS to use a dial-up profile that you create, instead of the one that it generates automatically. To do this, create a separate dial-up profile, and in the NowSMS config, instead of selecting "Modem: modem driver name", select "Dialup: dial-up connection name". (Note that if you do this, be sure to tell NowSMS which named modem driver is used by this connection, so that it can properly switch modes between SMS and GPRS access.)

Also, sorry if I mentioned the wrong log file, but I'm interested in the MMSWAPDEBUG.LOG, which is separate from the MMSCDEBUG.LOG ... it only contains information about the dialog with the modem.

-bn
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 8
Registered: 07-2006
Posted on Thursday, October 19, 2006 - 01:14 am:   

application/octet-streamlog
MMSWAPDEBUG.LOG (10.3 k)
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 9
Registered: 07-2006
Posted on Thursday, October 19, 2006 - 04:22 pm:   

Hi Bryce,
We have been able to find a temporary work-a-around on our Windows 2003 server.

1.Create a Dial-Up connection
2.Stop the MMS/SMS services
3.Specify the network conneciton as the "dial-up:dial-up connection name".
4.Connect to WAP gateway manually through the "Network Connections" window in the control panel of the rerver. Successful, 115kbps
5.Launch the SMS/MMS service
6.Open the NOW SMS web interface
7.Send an mms file
8.MMS gets sent and is received
9.Connection to WAP gateway through GPRS modem is automatically closed
10.MMS/SMS services still running

If we try to connect to the WAP gateway to send another mms through the nonw/smsweb interface, the SMS/MMS gateway tries to initialize the dial up connection again, but is unable to.

The only way to be able to send the mms is to disable the mms/sms services in the "services" tab in the gateway interface, re-connect the dial-up conneciton manually through the "network connection" window, and then relaunch the MMS/SMS services. Then go back into the web interface, load and send the media files.

To sum it up: our windows server environment won't let the NOW/SMS application create a dial-up network connection. We need to create it and connect manually to the WAP gateway before launching the service. The connection to the WAP gateway is always closed automatically by NOW/SMS after any action is performed through the web interface. Afterward the NOW.SMS app is bound to the modem port and so we can not even connect manually through the network connection tab until we disable the mms/sms services in the gateway window and release the modem for a new network connection to the WAP gateway.

Sorry for rambling. But do you know how we can rememdy this and give NOW/SMS the ability to create dial-up network connections and connect to the WAP gateway?

thanks,
Adrian

I will post a useful log (the one above was posted after a restart)
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 10
Registered: 07-2006
Posted on Thursday, October 19, 2006 - 04:59 pm:   

application/octet-streamMMS LOG
MMSWAPDEBUG.LOG (86.6 k)



Here is a log which shows a successful mms sent (as described above) and unsuccessful attempts (the attempts of using the now/sms app to start the dial up connection and connect to the WAP gateway).
Adrian
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 6702
Registered: 10-2002
Posted on Thursday, October 19, 2006 - 08:27 pm:   

Hi Adrian,

Sorry to keep asking for logs, without offering too much constructive advice.

But, I'd like to see an MMSWAPDEBUG.log that shows NowSMS trying to use "Modem: modem driver name" instead of "Dial-up: RAS connection name".

When we are configured to use a RAS connection, we have no control over the settings of that connection. So that doesn't tell me much.

Or have you been using a separate RAS connection all along? I've just been doing a little investigation, and I noticed that we always use "*99***1#" (or the appropriate CID number) when dialing via a RAS profile that we create. However, if we are using a pre-existing RAS profile, then we always override the dial number with "*99#" ... which would match what you state as the original problem.

The modem should interpret "*99#" and "*99***1#" as the same thing, but my observation here is that maybe you were using "Dial-up: RAS connection name" from the beginning, whereas you'd be better off using "Modem: Modem driver name".

In fact, as I look at your original MMSCDEBUG.LOG, I can see that it is using "Dial-up: FIdo" ... so this is likely the issue.

I am going to look into this behaviour of changing the dial-up phone number though when using a "Dial-up:" profile, because this should not happen.

-bn
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 6703
Registered: 10-2002
Posted on Thursday, October 19, 2006 - 09:01 pm:   

Follow-up ...

I have confirmed that the problem is that NowSMS is overriding the dial phone number with "*99#" (as you described) when you configure NowSMS to use an existing "Dial-up:" profile for the GPRS connection.

Sorry that I didn't notice that in the first log that you sent. (It is unusual to use this configuration option instead of choosing a "Modem:" entry directly.)

We're going to produce a patch to correct this problem, but my immediate suggestion would be to change the connction to use a "Modem:" entry instead, and let NowSMS dynamically create the dial-up profile.

As a side note, it is interesting to note that the Multitech GPRS modem interprets "*99#" differently from "*99***1#". Yet, I see this is clearly stated in its documentation ... if the CID number (1) is omitted, then it will try to connect to a blank (default) APN.

I had always assumed "*99#" was interpreted the same as "*99***1#", because that seemed the behaviour of other modems ... but I guess 3GPP TS 07.07 is a bit unclear.

-bn
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 11
Registered: 07-2006
Posted on Monday, October 30, 2006 - 08:16 pm:   

Hi Bryce,

We have tried both selecting the Mutlitech modem and the dial-up network connection in the Routing settings in the NOWSMS gateway. Neither works.
Recently, I believce the problem is this:

Windows server will not allow NOW SMS to create and connect through a dial-up netowrk connection. I have tried to use a demand-dial up network interface, but have been unsuccessful.
Do you know what I need to do to make the demand-dial network interfaces selectable under the "network connection" drop-down menu in the routinmg screen?

Thanks,
Adrian
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 6768
Registered: 10-2002
Posted on Wednesday, November 01, 2006 - 05:34 pm:   

Hi Adrian,

What happens when you select the modem directly as the "Network Connection"? I'd be curious to see the "MMSWAPDEBUG.LOG" that results.

I wonder if the issue is one of rights?

As I mentioned above, the PC in my office that has a Multitech GPRS modem attached to it is running Windows 2003 Server. But, I installed/setup/configured NowSMS logged in to an administrator account. (The actual service runs under "localsystem".)

When you configure the network connection to point to a modem directly, NowSMS will always try to dynamically create a dial-up networking profile if one does not already exist. So maybe there is an issue that the user account under which you are running the setup/configuration does not have rights to do this?

I'm still curious to see an MMSWAPDEBUG.LOG showing this connection attempt using the "Modem:" entry directly.

But ... I also should follow-up on my follow-up above. We did produce a patch that addresses this issue of NowSMS overwriting the dial phone number when you configure it to use an existing dial-up networking connection. You can download the update as http://www.nowsms.com/download/patch2006.zip.


quote:

Do you know what I need to do to make the demand-dial network interfaces selectable under the "network connection" drop-down menu in the routinmg screen?




You shouldn't have to do anything special, but there is the issue that NowSMS, before this patch, is always going to substitute "*99#" for the phone number in the profile.

The only other issues are that this list might be cached, so you might have to exit the NowSMS configuration program and reload it for it to pick up new entries.

And also it ignores any entries that have "NowSMS -" as the prefix.

Oh wait ... you're talking about "demand dial networking" that you setup under remote access services. I'm not familiar with how that works, so it is likely that we don't recognise it.

At this point, I'd say that the best option is probably to get the patch, and I'd expect that it would work with your manually created dial-up networking profile.

From a knowledge standpoint, I'm still curious about why selecting the modem entry directly for the "Network Connection" does not work, and would like to see an "MMSWAPDEBUG.LOG" ... because this is the way that we generally tell people to set things up, and I can't understand why it is not working.

-bn
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 12
Registered: 07-2006
Posted on Wednesday, November 01, 2006 - 06:27 pm:   

Hi Bryce,

Here is the MMSWAPDEBUG.LOG before installing the patch using the Modem: Multitech... as the Network Connection.

I will now try installing the patch.

Thanks! and please let us know what you discover from the log.
application/octet-streamMMSWAPDEBUG.LOG
MMSWAPDEBUG.LOG (3.5 k)
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 6800
Registered: 10-2002
Posted on Tuesday, November 07, 2006 - 09:44 pm:   

Hi Adrian,

Apologies for the delay in response. Did the patch resolve the issue when using the "Dial-up" entry?

Based upon that MMSWAPDEBUG.LOG, we should be dialing "*99***1#" when we attempt to make a connection on the "NowSMS - MultiTech Systems GSM_GPRS Wireless Modem" profile.

But I am puzzled by some things that I see in the MMSWAPDEBUG.LOG. In particular, I'm looking at this sequence here:


quote:

12:46:22:421 [260] WSPRasDial: Before RasDial NowSMS - MultiTech Systems GSM_GPRS Wireless Modem
12:46:27:578 [260] WSPRasDial: RasDial connected to NowSMS - MultiTech Systems GSM_GPRS Wireless Modem
12:46:27:578 [260] WSPRasDial: Unable to connect to WAP gateway at 205.151.11.13
12:46:27:578 [260] WSPRasHangUp: Disconnecting RAS connection NowSMS - MultiTech Systems GSM_GPRS Wireless Modem




It takes about 5 seconds for the modem to make a GPRS connection and acquire an IP address, which is not unreasonable.

But then, once we have detected that the connection is active, no time ... not even a millisecond ... elapses before we declare "Unable to connect to WAP gateway".

That is VERY unusual. It looks like we are not even trying to connect to the WAP gateway. (This is all especially odd, when you mention that this same modem works with NowSMS on a different PC that is not running Windows 2003 server.)

I've reviewed this with another engineer and we've determined a reason why this might occur. After NowSMS connects it uses some Windows API calls ... where if one of these calls fails, we don't make any attempt to connect to the WAP gateway.

Basically, we are calling "gethostname" to return the name of the current machine (it doesn't matter that the name returned is generally not a full internet name) ... and then "gethostbyname" to enumerate all of the current IP addresses associated with the machine. The idea here is that we want to know about the IP address assignments related to the new connection. Everything I've read indicates that these functions should never fail, but they certainly seem to be.

I've uploaded an updated MMSWAP.DLL with some extra debugging. It's at http://www.nowsms.com/download/adrian.zip. Give that a try, and generate another mmswapdebug.log, and hopefully that will give us a better idea what we are dealing with.

-bn
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 13
Registered: 07-2006
Posted on Thursday, November 09, 2006 - 10:48 pm:   

Hi Bryce,

Here is the new info from the log:

17:22:56:578 [C34] InitTAPI: Performing TAPI initialisation
17:23:07:078 [C34] WSPRasDial: Before RasDial fido
17:23:17:312 [C34] WSPRasDial: RasDial connected to fido
17:23:17:312 [C34] WSPRasDial: gethostname = VORTXTSERVER
17:23:17:312 [C34] WSPRasDial: gethostbyname returned ok
17:23:17:312 [C34] WSPRasDial: gethostbyname returned 192.168.1.104
17:23:17:312 [C34] WSPRasDial: Unable to connect to WAP gateway at 205.151.11.13
17:23:17:312 [C34] WSPRasHangUp: Disconnecting RAS connection fido
17:23:31:953 [C34] WSPRasHangUp: Complete
17:26:16:250 [C34] InitTAPI: Returning cached TAPI session information
17:26:24:281 [C34] WSPRasDial: Before RasDial fido
17:26:29:109 [C34] WSPRasDial: RasDial connected to fido
17:26:29:109 [C34] WSPRasDial: gethostname = VORTXTSERVER
17:26:29:109 [C34] WSPRasDial: gethostbyname returned ok
17:26:29:109 [C34] WSPRasDial: gethostbyname returned 192.168.1.104
17:26:29:109 [C34] WSPRasDial: Unable to connect to WAP gateway at 205.151.11.13
17:26:29:109 [C34] WSPRasHangUp: Disconnecting RAS connection fido
17:26:44:546 [C34] WSPRasHangUp: Complete

Hoping this gets us closer.
Adrian
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 14
Registered: 07-2006
Posted on Thursday, November 09, 2006 - 10:52 pm:   

Hi Bryce,
Here is the debug info when I connect manually in network connections to the gateway and then hit the "test connection" button in routing details.

17:32:26:781 [440] InitTAPI: Performing TAPI initialisation
17:32:34:031 [440] WSPRasDial: RAS connection fido is already active
17:32:34:031 [440] WSPRestoreRoute: Dial-up: fido
17:32:34:031 [440] WSPConnect: Sending 65 byte request to 205.151.11.13
17:32:34:031 [440] WSPConnect: Packet Length is 65 bytes
17:32:34:031 [440] WSPConnect: 0A 00 01 12 01 10 0A 2F 04 80 8F F8 00 04 81 8F /
17:32:34:031 [440] WSPConnect: F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 Now SMS/MMS G
17:32:34:031 [440] WSPConnect: 61 74 65 77 61 79 20 32 30 30 36 00 45 6E 63 6F ateway 2006 Enco
17:32:34:031 [440] WSPConnect: 64 69 6E 67 2D 56 65 72 73 69 6F 6E 00 31 2E 33 ding-Version 1.3
17:32:34:031 [440] WSPConnect: 00
17:32:34:031 [440] Debug: Before sendto
17:32:34:031 [440] Debug: After sendto
17:32:34:796 [440] WSPConnect: Received 13 byte response from 205.151.11.13
17:32:34:796 [440] WSPConnect: Packet Length is 13 bytes
17:32:34:796 [440] WSPConnect: 12 80 01 03 40 C4 00 C0 30 AC 19 B0 05 @ 0
17:32:34:796 [440] WSPRestoreRoute: Dial-up: fido
17:32:34:796 [440] Debug: Before sendto
17:32:34:796 [440] Debug: After sendto
17:32:34:796 [440] WSPRestoreRoute: Dial-up: fido
17:32:34:796 [440] WSPConnect: Sending 65 byte request to 205.151.11.13
17:32:34:796 [440] WSPConnect: Packet Length is 65 bytes
17:32:34:796 [440] WSPConnect: 0A 00 01 12 01 10 0A 2F 04 80 8F F8 00 04 81 8F /
17:32:34:796 [440] WSPConnect: F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 Now SMS/MMS G
17:32:34:796 [440] WSPConnect: 61 74 65 77 61 79 20 32 30 30 36 00 45 6E 63 6F ateway 2006 Enco
17:32:34:796 [440] WSPConnect: 64 69 6E 67 2D 56 65 72 73 69 6F 6E 00 31 2E 33 ding-Version 1.3
17:32:34:796 [440] WSPConnect: 00
17:32:34:796 [440] Debug: Before sendto
17:32:34:796 [440] Debug: After sendto
17:32:35:562 [440] WSPConnect: Received 134 byte response from 205.151.11.13
17:32:35:562 [440] WSPConnect: Packet Length is 134 bytes
17:32:35:562 [440] WSPConnect: 12 80 01 02 8C C6 FF 52 0A 72 04 80 8F F8 00 04 R r
17:32:35:562 [440] WSPConnect: 81 8F F8 00 C3 93 78 2D 75 70 2D 70 72 6F 78 79 x-up-proxy
17:32:35:562 [440] WSPConnect: 2D 62 6F 6F 6B 6D 61 72 6B 00 68 74 74 70 3A 2F -bookmark http:/
17:32:35:562 [440] WSPConnect: 2F 6D 79 68 6F 6D 65 70 61 67 65 2F 6D 61 72 6B /myhomepage/mark
17:32:35:562 [440] WSPConnect: 00 78 2D 75 70 2D 70 72 6F 78 79 2D 75 70 6C 69 x-up-proxy-upli
17:32:35:562 [440] WSPConnect: 6E 6B 2D 76 65 72 73 69 6F 6E 00 31 2E 31 00 78 nk-version 1.1 x
17:32:35:562 [440] WSPConnect: 2D 75 70 2D 70 72 6F 78 79 2D 68 6F 6D 65 2D 70 -up-proxy-home-p
17:32:35:562 [440] WSPConnect: 61 67 65 00 68 74 74 70 3A 2F 2F 6D 79 68 6F 6D age http://myhom
17:32:35:562 [440] WSPConnect: 65 70 61 67 65 00 epage
17:32:35:562 [440] WSPRestoreRoute: Dial-up: fido
17:32:35:562 [440] Debug: Before sendto
17:32:35:562 [440] Debug: After sendto
17:32:35:562 [440] WSPRestoreRoute: Dial-up: fido
17:32:35:562 [440] WSPConnect: Packet Length is 3 bytes
17:32:35:562 [440] WSPConnect: 18 00 01
17:32:35:562 [440] Debug: Before sendto
17:32:35:562 [440] Debug: After sendto
17:32:35:562 [440] WSPConnect: Gateway redirect to 172.25.176.5:49200
17:32:35:562 [440] WSPRestoreRoute: Dial-up: fido
17:32:35:562 [440] Debug: Before sendto
17:32:35:562 [440] Debug: After sendto
17:32:35:562 [440] WSPDisconnect: Packet Length is 9 bytes
17:32:35:562 [440] WSPDisconnect: 0A 00 02 12 05 8C C6 FF 52 R
17:32:35:562 [440] WSPRasDial: Connection to WAP gateway at 172.25.176.5:49200 OK!
17:32:36:562 [440] WSPRasHangUp: Disconnecting RAS connection fido
17:32:40:015 [440] WSPRasHangUp: Complete

-Adrian
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 6839
Registered: 10-2002
Posted on Tuesday, November 14, 2006 - 10:49 pm:   

Interesting.

Basically, we're expecting that API call to return to us all IP addresses, including ones associated with any dial-up connection. But we're only getting the address associated with the network adapter.

The only reason that the test works when you manually initiate the connection is because the connection is setup to be the "default internet route". When NowSMS manually creates a connection, it doesn't set this attribute for the connection, because that can cause problems communicating with the server over the normal LAN connection.

I'm puzzled by all of this, because I don't understand why the API call is not returning the information about the dial-up IP address.

I tested this version on my Windows 2003 server, and I see the following:

WSPRasDial: gethostbyname returned ok
WSPRasDial: gethostbyname returned 192.168.1.10
WSPRasDial: gethostbyname returned 10.186.190.105

The first entry is the IP address for the network adapter, and the second IP address is the one associated with the GPRS connection.

Are you on Windows 2003 Server R2? This particular server that I'm testing on has not been updated to R2. I can't imagine that would make a difference, but I'm just trying to figure out why we'd see this strange behaviour.

But anyway, I've got an idea. We actually use another API to get similar information in another part of NowSMS. So ... let's see if that API is returning more accurate information (I suspect it will, because it is a more full-featured API).

I've updated http://www.nowsms.com/download/adrian.zip with a new version of MMSWAP.DLL. Give that a try, and if that also fails, let me see the MMSWAPDEBUG.LOG from that connection attempt.

-bn
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 15
Registered: 07-2006
Posted on Thursday, November 16, 2006 - 06:49 pm:   

Hi Bryce, the laste mmswap.dll update has fixed our problem! We were able to connect to the WAP gateway and send an MMS...



Thx for all the tech help,
Adrian
Adrian Schauer
New member
Username: Adrian_schauer

Post Number: 16
Registered: 07-2006
Posted on Tuesday, November 21, 2006 - 09:53 pm:   

Hi Bryce,

The patch you sent resolved the issue and we are now able to send MMS! Thanks for your help, and let us know if we can provide any information to help you solve similar issues in the future.

All the best.
team Vortxt