Hi all - first post and all... so hopefuly Im not breaking any ethics rules. I do not expect anyone to solve problems for me, but I am stumped by this: recently subscribed to a SMS service (Celtrust) that, amongst other svcs, pushed (POST) SMS data from my short code to a dev server (still looking for a final production hosting solution) that is located on servage.net. It's just some real simple data like CID, carrier, network, message, etc ... 11 short text-only fields in all.
Anyway, the long & short is that I am not receiving anything. However, moved the EXACT SAME script (PHP) to 3 other servers I have access to, and when I point the SMS service to them it works great.
Working this prob for 3 days now. servage,net (no, I'm not ranting btw) asked for the sending IP, gave it to them, they say: not blocked, network operates ok. Looked at file permissions, ownership, server (as much as I am allowed) & PHP params... I just do not see it. Eventually the script needs to interact with a db, right now it just writes data to a flat file. Only difference btwn the various servers: all run BSD and Servage is Linux.. grasping here.
Is just smells like servage.net is not letting it pass, although their support claims all is well. :confused:
Anyone able to send me in the right direction? Getting tunnel vision here

Most common reason for PHP scripts to work on some servers and not others: register_globals setting. Check what's set on your accounts with a phpinfo script, like this:
<?php phpinfo(); ?>

If the script you're using does need register_globals switched on you might want to get it checked by an expert - mostly it's the very old and / or badly-written scripts that need this and it's not unusual to find other problems as well, like vulnerabilities that would allow an attacker into your account.

Thats what I am thinking, if register globals is on, then $formdata would work. but $_POST['formdata'] should as well.

Make sure you are not using the register globals format, as it can be insecure, and it is not recommended to use at all anymore.

Thanks foobic & csparks for the replies, appreciated.
I am aware of all that, and tried several different settings and combinations. For test purpose:
PHP 5.2.3
PHP safe mode: off
PHP safe mode GID: off
PHP register globals: on
Acceleration off
no .htaccess

the script itself:

<?php
error_reporting(E_ALL);
ob_implicit_flush();

$nickname = trim($_POST['CustomerNickname']);
$resptype = trim($_POST['ResponseType']);
$keyword = trim($_POST['Keyword']);
$option = trim($_POST['Option']);
$data = trim($_POST['Data']);
$message = trim($_POST['Message']);
$oaddress = trim($_POST['OriginatorAddress']);
$acptime = trim($_POST['AcceptedTime']);
$deltype = trim($_POST['DeliveryType']);
$carrier = trim($_POST['Carrier']);
$nettype = trim($_POST['NetworkType']);

$text = "==================================\n\r";
$text .= "Nickname: ".$nickname."\n\r";
$text .= "Resp.Type: ".$resptype."\n\r";
$text .= "Keyword: ".$keyword."\n\r";
$text .= "Option: ".$option."\n\r";
$text .= "Data: ".$data."\n\r";
$text .= "Message: ".$message."\n\r";
$text .= "Orig Adr.: ".$oaddress."\n\r";
$text .= "Acpt.Time: ".$acptime."\n\r";
$text .= "DelivType: ".$deltype."\n\r";
$text .= "Carrier: ".$carrier."\n\r";
$text .= "Network: ".$nettype."\n\r\n\r";
$text .= "==================================\n\r";

// write it into the logfile now.
// to read the logfile in realtime use: tail -f /tmp/sms_response
$fdesc = fopen("responses.txt","a");
fwrite($fdesc, $text."\n");
fclose($fdesc);
?>


Did a fsockopen to this from somewhere else and header coming back is 200 OK etc...

You might want to check that there's a .htaccess statement that allows posting to the directory in question. By default most hosts disallow posting from an external web site.

yeah.. did all that.. looks like I need to find another place to do this.

Not much to go wrong there. I think Windows line endings are normally \r\n not \n\r but that should only affect the formatting, if anything.

Have you checked that your script has permission to write responses.txt? (there would be a difference there between a system running PHP as suexec and one using the Apache module).

Another test would be to create a simple HTML form and post data from that.

Not much to go wrong there. I think Windows line endings are normally \r\n not \n\r but that should only affect the formatting, if anything.
that's right, just a leftover from sample code given by Celtrust (SMS provider)... obviously I do need to do much more besides writing it to a file, if I ever can get to the data - responses.txt is chmod'd 666.

Have you checked that your script has permission to write responses.txt? (there would be a difference there between a system running PHP as suexec and one using the Apache module).
How would I check that? phpinfo() ?

Another test would be to create a simple HTML form and post data from that.
I did write a simple form that POST data to this script, ran it from another server and got the data. Anyway that gave me another idea, so I wrote this:


<?php
/*****************************************************************************
temp patch to SMS reception problem:

SMS -> serverA.com/MOaa.php -> smsgateway.mycellmed.com/MOAcceptor.php

*****************************************************************************/

error_reporting(E_ALL);
ob_implicit_flush();

$server = 'smsgateway.mycellmed.com';
$port = 80;
$url = '/MOAcceptor.php';
$ret = "";
$content = "";
$recordseperator = "-----------------------------------------------------------------------------------------";

// move POST data from SMS into a header-content variable
foreach ( $_POST as $varname => $varvalue ) {
$varvalue = ( ( $varname == 'Option' ) ? 'Relay' : $varvalue );
$content .= $varname . '=' . trim($varvalue) . '&';
}

// remove extra & from above
$content = substr_replace( $content , '&' , -1 , 1 );

// writing data to serverA for sanity check
if ( $fdesc = fopen("responses.txt","a") ) {
fwrite($fdesc, $content."\n");
fwrite($fdesc, $recordseperator."\n");
fclose($fdesc);
}

// construct header and push it where it should goto in the first place...
$content_length = strlen($content);
$headers= "POST $url http/1.1\r\nhost: $server\r\ncontent-type: application/x-www-form-urlencoded\r\ncontent-length: $content_length\r\n\r\n";

if ( $fp = fsockopen($server, $port, $errno, $errstr) ) {
fputs($fp, $headers);
fputs($fp, $content);
while (!feof($fp)) {
$ret.= fgets($fp, 1024);
}
fclose($fp);
// return response
print $ret;
}
?>

And thus... I am getting the data in roundabout way... temp fix, but at least I'm able to continue with other things.

Going to move all this to another host svc anyway... thinking about deru.net

Thank you all, especially foobic for helping me think. Still do not understand why servage.net :confused: is not accepting the POST data directly from the SMS provider, but life goes on. :stickout:

Very simple, but try this:


foreach ($_POST as $key => $value)
echo "$key: $value<BR>";


or

print_r($_POST);

Hi jimpoz!

I did, maybe u r responding in ref to a couple of posts up... that code was taken from the SMS provider's code. My main concern at the time was getting their data, the rest was just semantics at the time.

Interesting. So with the same data, POSTed from an intermediate server, the script works. Write permissions on responses.txt aren't the issue then - it must be something about the original POST request. Did you check the access log? Is the request perhaps being rejected with a 403 or a 406 error code?

Assuming the Servage tech is right and they're not blocking your cell provider at the firewall, one other possibility is that mod_security is finding something unacceptable. As an experiment you could try to disable mod_sec in your .htaccess and see if it makes a difference:
<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

Nope... nothing.
Believe me, when soliciting a new host svc I will test it prior to making any commitments.
Good one though... .

Oh yes: celltrust reported that when I set the TxTFeedback string to point directly to the servage.net app .. it hangs and times out.
Most likely indicative to a firewall issue, according the celltrust support, but then again.. servage.net says no... .
No matter, I need to continue this way for now. When I have more time I may look into this again. Need to get the app working, first and foremost. $-men can not be disappointed.
Anyway, after reading some (unrelated) horror stories about servage.net (although in all fairness, I can not complain, besides this I never had an issue with them) I need to go to a more intimate relationship with another service that is also capable of dedicated and co-locating service for the future.

Yves.