Showing results for 
Search instead for 
Did you mean: 

Welcome to the Smart Call Home Community!

Our online forum for Smart Call Home customers to share, learn, and collaborate on Smart Call Home related topics. We encourage you to ask questions of Cisco experts, start a discussion, or share ideas and insight.

Smart Call Home enabled devices perform proactive diagnostics on their own components to provide real-time alerts and remediation advice when an issue is detected. An embedded support feature available on a broad range of Cisco products, it is provided at no additional cost with an active Smart Net Total Care Service, SP Base, Unified Computing Support Service, or Mission Critical Support Service contract for the designated products.

This Community will provide you with an overview about Cisco Smart Call Home features and how these features are embedded in a wide range of Cisco products to help your network. Smart Call Home provides higher network availability and support service quality.

Smart Call Home Portal Performance

On We are currently experiencing performance issues with accessing and operations of the Small Call Home portal. Users are being dropped from the portal. Our team is working to resolve this issue as quickly as possible. We apologize for any inconvenience this is creating.


Transport Gateway doesn't appears to start web listener

Tried installing Transport Gateway 3.5 under CentOS 6.x. I can start the process and I see a couple of items in the process list for it, but I don't see anything listening on port 80 when looking at the output from netstat and, of course, dont' see anything when trying to access the web gui.

Any ideas?


Accepted Solutions
Bryan Williams

Make sure your hostname is in your hosts file.  The HTTP daemon uses the hosts file to determine which IP Address to listen on.

View solution in original post

Lawrence Searcy
Cisco Employee

There is an issue with the email functionality of Transport Gateway 3.5 (See CSCul96202) In addition, we have seen Windows 2008 issues installing the Transport Gateway version 3.5.

Some important points:

1. You need a complete reboot of the server for the Apache web server to come up at server boottime. It also needs to reboot if you make any configuration changes to the transport gateway URLs. The transport gateway uses the Apache web server for the HTTP(s) operations.

2. Make sure it fully installs successfully.

I would open a TAC case if you need further assistance moving forward or alternatively fallback to version 3.3 as a workaround. If you read the version 3.5 release notes, you can see if the version 3.3 bug fixes or version 3.5 new features would affect your operations.

Bryan Williams

Make sure your hostname is in your hosts file.  The HTTP daemon uses the hosts file to determine which IP Address to listen on.


Verified I had the hostname and IP address in /etc/hosts and tried a reboot. Apache starts just fine, but I see nothing in the apache configuration or in /var/www/ that would direct any requests to the Transport Gateway software. Should the Transport Gateway be installing a vhost config or a directive in the apache configuration to direct requests for /TransportGateway to the gateway processes running in java?

Already tried installing previous versions of the Transport Gateway, but had just as much, if not more, trouble trying to get them running on Linux and Windows.

I'll submit a case to TAC to see what they find.

TG does not use apache.  The HTTP listener is part of the TG java process.

[root@tspm-aus-tg4-rhel65 ~]# lsof -i


java      26546    root   79u  IPv6  96108      0t0  TCP (LISTEN)

java      26546    root   83u  IPv6  96110      0t0  TCP (LISTEN)

That's what I suspected.

Hmm. Curious. It doesn't seem to want to start a listener on the http or https ports. I see it listening on localhost:31000 and 32000, but I'm pretty certain those are used for something other than the web interface for the app.

wrapper   3286 root    7u  IPv4  49309      0t0  TCP localhost:32000->localhost:31000 (ESTABLISHED)

java      3288 root    4u  IPv4  49291      0t0  TCP localhost:32000 (LISTEN)

java      3288 root   68u  IPv6  49308      0t0  TCP localhost:31000->localhost:32000 (ESTABLISHED)

Opened a case with TAC, but the rep is insisting that I neeed a GUI on the linux machine in order to troubleshoot, but I don't see how that would matter, so we'll see where that goes.

Not seeing much helpful in the log files. Seems pretty clean. No mention of missing components or unable to start services in either /var/log/messages or in the log files for the app.

I get a couple of processes: one wrapper process and the other is

I see in the file that it has 80 and 443 conigured for http and https and the TGServiceMain process has the jars for jetty in the command line.

I also see the ports 31000 and 32000 on my working TG.

wrapper   26544    root    7u  IPv4  96092      0t0  TCP localhost:32000->localhost:31000 (ESTABLISHED)

java      26546    root    4u  IPv4  96073      0t0  TCP localhost:32000 (LISTEN)

java      26546    root   68u  IPv6  96091      0t0  TCP localhost:31000->localhost:32000 (ESTABLISHED)

java      26546    root   77u  IPv6  96106      0t0  TCP *:commplex-link (LISTEN)

java      26546    root   79u  IPv6  96108      0t0  TCP (LISTEN)

java      26546    root   83u  IPv6  96110      0t0  TCP (LISTEN)

The TG specific logs are in /opt/CSCOSchtg/tg/logs.

Looks like I'm missing some listeners or the TG just isn't fully starting for some reason.

Makes me wonder if there's still something not quite right with my /etc/hosts file or something and jetty isn't picking up the hostname, so it's refusing to start those additional listeners.

Bingo! There was something about the format of the /etc/hosts file that jetty (or some other component) just didn't like.

Blew it away and recreated and now the TG web interface starts.

Thanks for all your pointers!

Sorry about that. I meant Jetty, not Apache.