php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21653 Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed
Submitted: 2003-01-15 04:30 UTC Modified: 2003-07-18 18:53 UTC
Votes:128
Avg. Score:4.2 ± 0.9
Reproduced:108 of 116 (93.1%)
Same Version:35 (32.4%)
Same OS:35 (32.4%)
From: support at hostcolor dot com Assigned:
Status: No Feedback Package: Sockets related
PHP Version: 4.3.3RC2-dev OS: RedHat 7.2
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2003-01-15 04:30 UTC] support at hostcolor dot com
Script:
-------------------------
<?php
$fp = fsockopen ("localhost", 80, $errno, $errstr, 30);
if (!$fp) {
    echo "$errstr ($errno)<br>\n";
}
fclose ($fp);
?>

Output:
-------------------------
Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed in /home/virtual/site1/fst/var/www/html/t5.php on line 2
Warning: fsockopen() [function.fsockopen]: unable to connect to localhost:80 in /home/virtual/site1/fst/var/www/html/t5.php on line 2
Operation now in progress (115)
Warning: fclose(): supplied argument is not a valid stream resource in /home/virtual/site1/fst/var/www/html/t5.php on line 6

Modules:
---------------------------
./configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext=shared' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pear' '--with-png' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-debugger' '--enable-exif' '--enable-ftp=shared' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--enable-sockets' '--with-imap=shared' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql' '--with-pgsql=shared' '--with-snmp=shared' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--disable-experimental-zts' '--with-apxs=/usr/sbin/apxs' '--enable-debug' 

Additional information:
----------------------
The same script is running at the command prompt.
$result = socket_connect ($socket, "localhost", 80); is running fine on prompt and into browser.
I am sure www service is up and running. There is no internal firewall rules on the machine.

gdb backtrace:
----------------------------
I configured with --enable-debug 
[root@ensim html]# gdb /usr/sbin/httpd
GNU gdb Red Hat Linux (5.2-2)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
(gdb) run -X
Starting program: /usr/sbin/httpd -X
[New Thread 1024 (LWP 3641)]
Processing config directory: /etc/appliance/apacheconf
 Processing config file: /etc/appliance/apacheconf/apache
Processing config directory: /etc/httpd/conf/virtual
 Processing config file: /etc/httpd/conf/virtual/site1
Processing config directory: /etc/httpd/conf/site1
 Processing config file: /etc/httpd/conf/site1/cgi
 Processing config file: /etc/httpd/conf/site1/frontpage
 Processing config file: /etc/httpd/conf/site1/mod_perl
 Processing config file: /etc/httpd/conf/site1/sqmail
 Processing config file: /etc/httpd/conf/site1/ssi
 Processing config file: /etc/httpd/conf/site1/weblogs
 Processing config file: /etc/httpd/conf/virtual/site10
..............................
Processing config directory: /etc/httpd/conf/site99
 Processing config file: /etc/httpd/conf/site99/frontpage
 Processing config file: /etc/httpd/conf/site99/sqmail
 Processing config file: /etc/httpd/conf/site99/weblogs
Program exited with code 01.

I can't get a core file.
I didn't get any message at gdb prompt. May be I am doing something wrong.Please advise.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-15 13:08 UTC] iliaa@php.net
Doe your Webserver allow more then 1 Apache child to be running at any one time?
 [2003-01-16 03:51 UTC] support at hostcolor dot com
Yes there are always between 5 and 10 childs waiting for connections.
 [2003-02-11 01:53 UTC] laudanp at yahoo dot com
I have a couple scripts that worked 100% of the time under PHP 4.2.3.  Immediately after the upgrade to PHP 4.3 I get the function.fsockopen: php_hostconnect errors as well.

Here are two of the links you can launch an "authorized" scan from to see the errors:

http://www.computercops.biz/modules.php?name=Trojan_TCP_Scan
http://www.computercops.biz/modules.php?name=TCP_Scanner

These pages make use of the same code as posted earlier in this bug report by support@hostcolor.com.

To reiterate, under PHP 4.2.3 this code worked perfectly fine.  Now PHP 4.3 has broken it and I cannot seem to fix it.
 [2003-02-28 17:28 UTC] wez@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

If you read the release notes, you will notice that 4.3.1 contains *NO* bug fixes.
Please try the stable snapshot as requested (which *DOES* contain bug fixes).
 [2003-03-18 16:22 UTC] laudanp at yahoo dot com
Ok, the problem wasn't resolved using php 4.3.x.  This is the response from my host admin:

<start quote>
I do not normally install snapshot builds, the latest releases are used. Released versions undergo a testing phase that a development tree do not have. This applies to most software. The snapshot installed now is marked as 4.3.2-RC, or release candidate, which means that "if we do not get too many bug reports for this version it will become a release." However, a PHP developer will undoubtably know more about PHP than I do. If they are suggesting the use of this version they must be comfortable enough for it to be used in a production environment. 

I am not sure what you are needing to know now, if a PHP contributor or developer recommends use of this version it should be fine. 

The upgrade was performed in the same manner all of your custom builds are installed: 
PHP is configured/built. 
PHP is installed into the apache source tree. 
Any other apache modules are installed at this time. 
Apache is built, including PHP as a static module. 
The new binary or binaries are copied to your system. 
Apache is restarted. 

The only difference between the upgrade and the usual install process for your httpd was that a different PHP source tree was used. 

</end quote>

My host has read this bug report and has seen your suggestion.  The response is as above.

Help?  Ideas? 

Thanks in advance.
 [2003-03-26 23:34 UTC] steve at hostusa dot biz
I also am experiencing this issue after just updating php. 

Here are 2 links that are displaying the errors...

https://www.hostusa.biz/status.php
https://www.hostusa.biz/whois/index.php (do a whois lookup)

Any info on this would be appreciated.
 [2003-04-15 16:04 UTC] jim at revjim dot net
This is now a problem for me as well. I am running PHP 4.2.3 under Linux. When I was using the built in MySQL libraries, this was not an issue. However, now that I've recompiled (same apache version, same PHP version) I am showing the same problem. Restarting Apache seems to correct it temporarily.

(Apache 1.3.27, Mysql 4.0.12, PHP 4.2.3)
 [2003-04-28 06:14 UTC] insyderhomielc at hotmail dot com
Just putting in my two cents... suddenly SquirrelMail doesn't run because of this error.  Please get this bug fix in soon.  Thanks.
 [2003-04-28 06:23 UTC] wez@php.net
How long does it take to produce the error message?
You are specifying a timeout of 30 seconds; if it takes longer than 30 seconds, PHP will abort the connection attempt, even if it is "in progress".
 [2003-04-28 06:29 UTC] wez@php.net
Also, this item from the NEWS file is also relevant:
- Added php.ini option "default_socket_timeout" to set the
  timeout limit for PHP network streams.
 (kalowsky, ilia@prohost.org, Wez)

The default value is 60 seconds (it was introduced to avoid DoS attacks).

You can set this value from your scripts as well in the ini or httpd.conf. (see docs for ini_alter).
 [2003-05-05 13:39 UTC] laudanp at yahoo dot com
My issue still hasn't been resolved because we still haven't traveled down your recommended path.  Someone at my provider is looking into this for me.
 [2003-05-09 07:25 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2003-05-15 00:56 UTC] davideturner at hotmail dot com
I am receiving the same issue with eNoms app. Worked in 4.2.3 now receive that error with 4.3.1.
 [2003-05-15 01:02 UTC] davideturner at hotmail dot com
Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed in /home/xxxxxxxxx/include/EnomInterface_inc.php on line 140

Warning: fsockopen() [function.fsockopen]: unable to connect to resellertest.enom.com:80 in /home/xxxxxxxxx/include/EnomInterface_inc.php on line 140

Fatal error: Call to undefined function: strerror() in /home/xxxxxxxxx/include/EnomInterface_inc.php on line 142



Line 140+
		$address = gethostbyname( $host );
		
		// Create a TCP/IP socket.
		$socket = fsockopen($host,80); 
		if ( !$socket ) {
			$this->AddError( "socket() failed: " . strerror( $socket ) );
 [2003-06-03 14:37 UTC] scmvs at cs dot cf dot ac dot uk
I experience the same problem with fsockopen. Is this ever going to be fixed? (I am using PHP 4.3.2)
 [2003-06-10 12:08 UTC] laudanp at yahoo dot com
My current host has not done this whatsoever, we have obtained another server with another host.  We'll be working on it this week.  On the new server we see the same exact error as on the current server at computercops.biz.  So the new server will have the CVS build installed.

Cross your fingers.  (crossing ours)
 [2003-06-19 15:52 UTC] caitlin at meowww dot com
I just started seeing this bug in code that worked for PHP 4.1.2 (never saw this error for almost a year of daily use) when my ISP upgraded to 4.3.2.  I am using it in a pop mail reader.  I don't see this error every time I try to connect to the mail server, just randomly, although it tends to occur many times in a row if I reload the page.

The code looks like this: 

 $this->Socket = fsockopen($server, $port, $errno, $errstr, 5);
 socket_set_timeout($this->Socket, 5);

Where $port = 110 for a pop mail reader, and $server is the address of my mail server.

Originally the timeout was set to 30, but I read a post by another user who eliminated this problem by lowering their timeout.  That didn't work for me.  Whether the time out was 5 or 30 seconds, the error would return immediately.

Here's my ISP's system software versions: 

OS: RedHat 7.3
Apache: 1.3.27
Mysql: 3.23.56
Tomcat: 4.1.12
JDK: 1.4.1
PHP: 4.3.2
PERL: 5.6

Thanks for any help in a fix or workaround for this bug, which is affecting me daily.
 [2003-06-19 23:22 UTC] kmaier at jkaugust dot com
We were running into this exact problem and it was driving us nuts....  but.... we noticed it happened after a kernel upgrade where ECN was enabled by default.

Try disabling it with:

echo 0 >/proc/sys/net/ipv4/tcp_ecn

... and see if the errors go away.

More info on ECN is here:   http://gtf.org/garzik/ecn/

-ken
 [2003-06-20 02:20 UTC] wez@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

For those of you using Linux, if the ECN suggestion does not work for you, please try the latest stable snapshot as it contains a linux specific workaround that *might* solve your problem.

If it does, report back here and we can make the workaround a more portable solution.
 [2003-06-21 21:28 UTC] laudanp at yahoo dot com
Hi folks, we finally have a new server, and we just now installed the CVS Stable build from your recommended download:

http://snaps.php.net/php4-STABLE-latest.tar.gz

You can see the phpinfo here:

http://64.246.34.44/phpinfo.php

And you can see the port scan page here, and the same exact errors show up in this STABLE CVS 4.3.3RC2-dev build that I downloaded via your recommended link.

So it appears, this is an actual bug as you can see other folks are running into the same issue.

What is the next step?  I'd like to help in debugging this issue such that it can be resolve sooner rather than later.

Thank you,

Paul Laudanski
http://64.246.34.44/testpaul.php
 [2003-06-21 21:29 UTC] laudanp at yahoo dot com
Oops, I did not mean to place the "testpaul.php" file at the end, however, here is the link again:

http://64.246.34.44/testpaul.php

Thank  you... don't mind the "test" in the file name, it contains the code exact code as found at computercops.biz I linked to way above.

Paul
 [2003-06-22 05:11 UTC] wez@php.net
When I visited your test page, it seemed to be working; the port-scans triggered my port-sentry and that dropped the route to your machine.
So the only "problem" is that you see two separate error messages?
I've removed a redundant message from the stable branch.

 [2003-06-22 15:09 UTC] laudanp at yahoo dot com
Yes that error message pops up.  If you run it with a couple of those open ports, what do you get?

But yes, I'm getting those errors.  Re-download newest stable?
 [2003-06-23 20:48 UTC] sniper@php.net
Yes, get the latest stable snapshot..

 [2003-06-27 08:48 UTC] laudanp at yahoo dot com
HI, I grabbed the newest stable snapshot today (http://snaps.php.net/php4-STABLE-latest.tar.gz), build:

php4-STABLE-200306271330 / PHP Version 4.3.3RC2-dev

And the problem still shows up:

http://64.246.34.44/testpaul.php

Warning: fsockopen(): unable to connect to xxx.xxx.xxx.xxx in /var/www/html/testpaul.php on line 134

Which is this line in the script:

$fp = fsockopen($REMOTE_ADDR, $portno, $errno, $errstr, 1);

For confirmation of the build, you can use this:

http://64.246.34.44/phpinfo.php

Thanks
 [2003-06-29 21:27 UTC] iliaa@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Sample script appears to work correctly, assuming fixed.
 [2003-06-29 22:18 UTC] laudanp at yahoo dot com
Hi, thanks for the reply.  I'll grab the newest stable source tomorrow morning and give it a try once more.  But as of my last comment above, the error message I get is:

Warning: fsockopen(): unable to connect to ...

Again, I'll test it out again tomorrow with the newest build and report back.

Thanks
 [2003-06-30 08:24 UTC] laudanp at yahoo dot com
Download: .bz2 (3.5M) .gz (4.3M) 
Built On: Jun 30, 2003 11:30 GMT
php4-STABLE-200306301130

http://64.246.34.44/phpinfo.php
http://64.246.34.44/testpaul.php

Hi, I grabbed the latest stable cvs snapshot and it appears the problem persists.  Its the same code, no change, since I started using it prior to PHP 4.2.3.  For some reason, it doesn't work with 4.3.x.

Now, for my UDP scanner (http://www.computercops.biz/modules.php?name=UDP_Scanner) on PHP 4.3.x I use the following code which works well with either 4.2.3 or 4.3.x:

$handle = fsockopen($this-> targetIP, $portNumber, &$errno, &$errstr, 2);

For the TCP Scanner (http://www.computercops.biz/modules.php?name=TCP_Scanner), I have this line:

$handle = fsockopen($this-> targetIP, $index, $errno, $errstr, $this-> timeout);

So something is different between the TCP and UDP connections.  Now, I'm running these scans from a box that is dropping the probes.  Hence, since UDP is connectionless and TCP is connection oriented, the bug may have something to do with this?  I haven't tested it on a system that is not running a firewall recently.  What do your tests show now with the current snapshot?

Thanks

(Phew, this is one elusive bug).

P.S.  Here is my configure statement:

./configure --with-mysql --with-apxs --with-gd --with-jpeg-dir=../jpeg-6b/ --with-zlib
 [2003-06-30 08:27 UTC] laudanp at yahoo dot com
CORRECTION TO THIS:

So something is different between the TCP and UDP connections.  Now, I'm
running these scans from a box that is dropping the probes.  Hence,
since UDP is connectionless and TCP is connection oriented, the bug may
have something to do with this?  I haven't tested it on a system that is
not running a firewall recently.  What do your tests show now with the
current snapshot?

------------

CORRECTED VERSION:

*... Now, I'm running these scans from the server against a system that is dropping the probes via a firewall.  ... I haven't tested it on a system that is not protected by a firewall (or disabled it).  What do your tests show now with the current snapshot? ...*

-----

Thanks
 [2003-07-01 06:38 UTC] laudanp at yahoo dot com
Ok, I disabled any port blocking on my end this morning, and as it turns out I get the same messages as when port blocking was on:

Warning: fsockopen(): unable to connect to xxx.xxx.xxx.xxx:21 in /var/www/html/testpaul.php on line 134
Connection Refused: Port 21 used by Nerte 7.8.1.

This is odd indeed.
 [2003-07-09 09:21 UTC] laudanp at yahoo dot com
HI folks, welcome back.  So, what is the status?  Those errors are still there.
 [2003-07-10 02:51 UTC] support at hostcolor dot com
I am not the original submitter of the bug but I was contacted by mr. Paul Laudanski and also by seeing the number of comments it seems that the problem is still there. We certainly found no solution as nothing else but reverting to 4.2.3 helped.
best regards and good luck
 [2003-07-10 11:41 UTC] sniper@php.net
This is propably stupid question..but why shouldn't fsockopen() give an error when it fails to connect???
Obviously that's what is happening here? :)

 [2003-07-10 14:51 UTC] laudanp at yahoo dot com
Each "ports are filtered or open" line is with respect to the client PC (target PC), and not the server that PHP is installed.

Scenario A: 

- ports are filtered (closed or stealth)
- PHP 4.2.3 is installed

Scenario B:

- ports are open
- PHP 4.2.3 is installed

Scenario C:

- ports are filtered (closed or stealth)
- PHP 4.3.x is installed

Scenario D:

- ports are open
- PHP 4.3.x is installed

Ok, under both Scenario A and B, no "fsockopen()..." error is generated.

Under both Scenario C and D, the "fsockopen()..." error is displayed.

Clearly what worked 100% of the time in 4.2.3, no longer functions in 4.3.x.  This has been an ongoing issue for several months now.
 [2003-07-10 14:53 UTC] laudanp at yahoo dot com
In addition, the http://64.246.34.44/ address I listed just above is no longer in use.  You can refer back to the original http://computercops.biz links way above.

Thanks
 [2003-07-10 14:53 UTC] laudanp at yahoo dot com
In addition, I'm not sure why the error would continue even after wez...

"[22 Jun 5:11am CDT] wez@php.net 
When I visited your test page, it seemed to be working; the port-scans
triggered my port-sentry and that dropped the route to your machine.
So the only "problem" is that you see two separate error messages?
I've removed a redundant message from the stable branch.

"
 [2003-07-18 18:53 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

No feedback from original bug submitter.
laudanp at yahoo dot com:
If you still feel this is a bug, open new report with
short example script, expected result and got result.


 [2003-07-23 14:31 UTC] laudanp at yahoo dot com
Hi I provided the feedback above, I'm still having those problems.  Help
 [2003-07-23 14:44 UTC] laudanp at yahoo dot com
re: "No feedback from original bug submitter.
laudanp at yahoo dot com:
If you still feel this is a bug, open new report with
short example script, expected result and got result."

Thanks for replying to me.  I'll go ahead and open a new ticket while referencing this one for posterity.  Look for it tonight.
 [2003-07-23 21:16 UTC] laudanp at yahoo dot com
I opened a new bug report here:

http://bugs.php.net/bug.php?id=24785
 [2005-01-05 12:50 UTC] suhailc at gmail dot com
Hi,

I get the following error:

Warning: fsockopen(): unable to connect to whois.crsnic.net:43 in /home/ecompco/public_html/test.php on line 2
Could not open connection

However, the connection is made perfectly and fast when I switch off APF. I get:

Connected OK.

For the life of me I cannot figure out why - I've added ports 43, 443, 4343, 80 to conf.php but still error shows when APF is on. But it does have something to do with APF.

Regards,
Suhail.
 [2006-06-28 09:08 UTC] sosingus at yahoo dot com
I have a similar problem using php 4.4.1 with pfsockopen
Part of code:
------------------
<?php
$fp = pfsockopen("ssl://example.com", 443, $errno, $errstr);
if (!$fp){
    echo "$errstr ($errno)<br>\n";
    exit;
}
?>
Output:
------------------
Operation now in progress (115)

Modules:
------------------
'./configure' '--with-gd' '--with-msql=/usr/local/msql2.0' '--with-mysql=/usr/local/mysql' '--with-apache=../apache_1.3.34' '--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib' '--with-mhash' '--with-openssl=/usr/local/ssl' '--enable-ftp' '--enable-imap' '--with-zlib-dir=/usr/local/lib' '--with-pear' '--with-curl=/usr/local/lib' '--with-pear=../PEAR-1.1' '--enable-mbstring=all' '--with-dom=/usr/local' '--with-domxml=/usr/local' '--enable-memory-limit=yes' '--enable-sockets' '--with-gd-native-ttf' '--enable-gd-imgstrttf' '--with-freetype-dir=/usr/local' '--enable-shared' '--with-expat-dir=/usr/local' '--with-dom-xslt=/usr/local' '--with-xslt-sablot'

Additional info
--------------------
I have it working on another domain and server with php 4.3.4
 [2006-09-27 20:24 UTC] phpbugs at whitesands dot net
I'm getting the same "Operation now in progress (115)" w/ PHP  4.4.2 configured with:	 

'./configure' '--with-mysql=/usr' '--with-apxs2=/usr/local/bin/apxs' '--enable-mbstring'

and using Apache 2.0.59 on RHEL 4 and using this script:

<?php
$fp = fsockopen ("localhost", 80, $errno, $errstr, 30);
if (!$fp) {
    echo "$errstr ($errno)<br>\n";
}
fclose ($fp);
?>

What I have been able to figure out is that if I have less that ~500 virtual domains in the httpd.conf file, the problem goes away.  If I have more, the problem comes back.  Am I hitting some kind of resource limit?
 [2007-03-02 16:34 UTC] blah at mailinator dot com
I have the same problem with Mac OS X 10.4.8 and PHP 5.2.
Unix sockets on the same machine work OK. Same code with TCP/IP socket fails with "Operation now in progress".
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Tue Oct 19 08:03:37 2021 UTC