TLS And TCP/IP

I must use TCP/IP and TLS in a project but i can't find any help or solution how to do it.
Does any one know how to do it?

LabVIEW has no native support for TLS/SSL.
For those who need/desire such functionality, please support this Idea Exchange entry:
Native SSH and SFTP Support
Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.
"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Similar Messages

EAP-TLS and MS AD auth problem

Hi,
I have a problem with an ACS to authenticate users with certificate on MS AD.
Working things:
PEAP authentication with the MS AD;
EAP-TLS authentication with the local DB.
Not working things:
EAP-TLS authentication with MS AD.
Because I'm able to auth users with PEAP on MS AD, I guess my config on MS AD is correct.
Because I'm able to auth users with certif in EAP-TLS, I guess my certif config is correct.
So, why it's not working with the combination EAP-TLS and MS AD.
I receive the error 'External DB Account Restriction'
Thanks for your help.

This issue is generally seens when there are multiple domains. Try out this step. Choose Network Connections from the control panel. Right-click the local area connection.Choose Properties. Double-click the TCP/IP option. Choose Advanced at the bottom. Click on DNS at the top. Choose Append these DNS suffixes. Add the FQDN for each domain that ACS authenticates against in the field.

Lync 2013 PSTN calling not working with Sonus SBC 1000 over TLS and SRTP

Dear All,
We have recently installed Lync 2013 Enterprise Edition with a Pool of 3 FE Servers (MEDIATION COLLOCATED).
We need to implement TLS and SRTP with Sonus SBC 1000. However calls are not routing b/w SBC and Lync.
We are using wild card certificate with multiple SIP Domains as SAN(s), for internal FE servers as well SBC.
Also i would like to mentioned here that inbound and outbound calls are routing properly when we tested it over TCP.
When I move to TLS Only calls from Lync to SBC (outgoing) are working without encryption.
Here are the OCS Logger traces for incoming calls which are not landing on lync:
TL_INFO(TF_PROTOCOL) [1]2C5C.0D30::04/30/2014-14:35:18.020.00026518.020.00026518.020.00026518.020.00026518.020.00026518.020.00026518.020.00026518.020.000265d2
(S4,SipMessage.DataLoggingHelper:sipmessage.cs(774))[3491463749]
>>>>>>>>>>>>Outgoing SipMessage c=[<SipTlsConnection_AE0419>], 10.10.0.11:5067->10.10.7.50:25678
SIP/2.0 400 Bad Request
FROM: "3158222726"<sip:[email protected]>;tag=ac3201ce-4d7
TO: <sip:[email protected]:5067>;epid=D2091CF753;tag=f373543c
CSEQ: 2 INVITE
CALL-ID: [email protected]
VIA: SIP/2.0/TLS 10.10.7.50:5067;branch=z9hG4bK-UX-ac32-01ce-0b14
CONTENT-LENGTH: 0
SERVER: RTCC/5.0.0.0 MediationServer
------------EndOfOutgoing SipMessage
TL_INFO(TF_PROTOCOL) [1]2C5C.0D30::04/30/2014-14:35:18.027.00026518.027.00026518.027.00026518.027.00026518.027.00026518.027.00026518.027.00026518.027.000265d7
(S4,SipMessage.DataLoggingHelper:sipmessage.cs(774))[2666394843]
>>>>>>>>>>>>Outgoing SipMessage c=[<SipTlsConnection_370F030>], 10.10.0.11:58059->10.10.0.13:5061
SERVICE sip:2138797082;[email protected];user=phone SIP/2.0
FROM: <sip:2138797082;[email protected];user=phone>;epid=DCFDB95F4C;tag=17d286a93
TO: <sip:2138797082;[email protected];user=phone>
CSEQ: 3 SERVICE
CALL-ID: de750f98bdd94e908be5f2f975228ff7
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 10.10.0.11:58059;branch=z9hG4bKd47f1d3c
CONTACT: <sip:[email protected];gruu;opaque=srvr:MediationServer:CiGdW3iH5FiI3Qvr3PIKGQAA>
CONTENT-LENGTH: 630
SUPPORTED: gruu-10
USER-AGENT: RTCC/5.0.0.0 MediationServer
CONTENT-TYPE: application/msrtc-reporterror+xml
<?xml version="1.0" encoding="us-ascii"?>
<reportError xmlns="http://schemas.microsoft.com/2006/09/sip/error-reporting">
<error callId="[email protected]" fromUri="sip:3158222726;[email protected];user=phone" toUri="sip:2138797082;[email protected];user=phone" fromTag="ac3201ce-4d7"
toTag="" requestType="INVITE" contentType="application/sdp;call-type=audio" responseCode="400"><diagHeader>10013;reason="Gateway peer in inbound call is not found in topology document or does not depend
on this Mediation Server"</diagHeader><progressReports /></error></reportError>------------EndOfOutgoing SipMessage
Call
Send SMS
Add to Skype
You'll need Skype CreditFree via Skype

@Paul, Thanks for you response.
All ports / IP Add / DNS are defined properly. Telenet on listening port is working.
We are using Public Certificate for 3 Domains (wild card) and same is loaded and verified in SBC
I've not reviewed the OCS logs properly posted above.
What i've found or seems to me is that in a TLS Calls:
After receiving SIP Invite from SBC, mediation server started TLS Negotiation Process b/w Lync 2013 Server Pool and it fails.
SIP Domains:
contoso.com (default)
fabrikam.com
Lync FE Pool (lync.contoso.com
Here are the some more logs.
TL_INFO(TF_PROTOCOL) [0]2DF8.2930::05/01/2014-11:50:31.612.00025e49 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(774))[2716989131]
<<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_103DFE0>], 10.10.0.11:5067<-10.10.7.50:24591
INVITE sip:[email protected]:5067 SIP/2.0
FROM: "3158222726" <sip:[email protected]>;tag=ac3201ce-ae
TO: <sip:[email protected]:5067>
CSEQ: 2 INVITE
CALL-ID: [email protected]
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 10.10.7.50:5067;branch=z9hG4bK-UX-ac32-01ce-010c
CONTACT: <sip:[email protected]:5067;transport=TLS>
CONTENT-LENGTH: 406
SUPPORTED: replaces,update,100rel
USER-AGENT: SONUS SBC1000 3.1.2v293 Sonus SBC
CONTENT-TYPE: application/sdp
ALLOW: INVITE, ACK, CANCEL, BYE, NOTIFY, OPTIONS, REFER, REGISTER, UPDATE, PRACK
P-ASSERTED-IDENTITY: "3158222726" <sip:[email protected]>
v=0
o=SBC 9 1001 IN IP4 10.10.7.50
s=VoipCall
c=IN IP4 10.10.7.50
t=0 0
m=audio 16418 RTP/AVP 8 0 101 13
c=IN IP4 10.10.7.50
a=rtpmap:8 PCMA/8000/1
a=rtpmap:0 PCMU/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=ptime:20
a=tcap:1 RTP/SAVP
a=pcfg:1 t=1
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:pqL6Tke8pVmXPuplJ1G3+Sr9jM97H8R7iBagWzzh|2^31|1:1
a=sendrecv
------------EndOfIncoming SipMessage
TL_INFO(TF_PROTOCOL) [1]2DF8.0E04::05/01/2014-11:50:31.665.00025e8e (S4,SipMessage.DataLoggingHelper:sipmessage.cs(774))[2716989131]
>>>>>>>>>>>>Outgoing SipMessage c=[<SipTlsConnection_103DFE0>], 10.10.0.11:5067->10.10.7.50:24591
SIP/2.0 100 Trying
FROM: "3158222726"<sip:[email protected]>;tag=ac3201ce-ae
TO: <sip:[email protected]:5067>
CSEQ: 2 INVITE
CALL-ID: [email protected]
VIA: SIP/2.0/TLS 10.10.7.50:5067;branch=z9hG4bK-UX-ac32-01ce-010c
CONTENT-LENGTH: 0
------------EndOfOutgoing SipMessage
TL_INFO(TF_CONNECTION) [1]184C.0EFC::05/01/2014-11:50:32.652.00025f32 (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(454))[946832530] $$begin_record
Severity: information
Text: TLS negotiation started
Local-IP: 10.10.0.11:5061
Peer-IP: 10.10.0.11:52529
Connection-ID: 0x10BE00
Transport: TLS
$$end_record
TL_INFO(TF_PROTOCOL) [1]184C.0EFC::05/01/2014-11:50:32.669.00026236 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[1853494582] $$begin_record
Trace-Correlation-Id: 1853494582
Instance-Id: 425D
Direction: incoming
Peer: 10.10.0.11:52529
Message-Type: request
Start-Line: NEGOTIATE sip:127.0.0.1:5061 SIP/2.0
FROM: <sip:contoso.com>;ms-fe=LYNCFE1.fabrikam.com
TO: <sip:contoso.com>
CALL-ID: aa53739ef9b34b93ba9c97d3ee56cb99
CSEQ: 1 NEGOTIATE
VIA: SIP/2.0/TLS 10.10.0.11:52529
MAX-FORWARDS: 0
CONTENT-LENGTH: 0
SUPPORTED: NewNegotiate
SUPPORTED: ECC
REQUIRE: ms-feature-info
SERVER: RTC/5.0
$$end_record
TL_INFO(TF_CONNECTION) [1]184C.0EFC::05/01/2014-11:50:32.669.0002636e (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(383))[946832530] $$begin_record
Severity: information
Text: Connection established
Peer-IP: 10.10.0.11:52529
Peer: lync.contoso.com:52529;ms-fe=LYNCFE1.fabrikam.com
Peer-Cert: contoso.com(LYNCFE1.fabrikam.com)
Transport: M-TLS
Data: alertable="yes"
$$end_record
TL_WARN(TF_CONNECTION) [1]184C.0EFC::05/01/2014-11:50:32.669.00026387 (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(386))[946832530] $$begin_record
Severity: warning
Text: The pool FQDN provided by the peer in its NEGOTIATE feature information does not match the pool configured in CMS for the server FQDN that it provided
Peer-IP: 10.10.0.11:52529
Peer: lync.contoso.com:52529;ms-fe=LYNCFE1.fabrikam.com
Peer-Cert: contoso.com(LYNCFE1.fabrikam.com)
Transport: M-TLS
Data: fqdn="LYNCFE1.fabrikam.com";pool="contoso.com";expected-fqdn="lync.contoso.com";info="Possible server configuration issue"
$$end_record
TL_INFO(TF_DIAG) [1]184C.0EFC::05/01/2014-11:50:32.670.000265be (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[1853494582] $$begin_record
Severity: information
Text: Routed a locally generated response
SIP-Start-Line: SIP/2.0 200 OK
SIP-Call-ID: aa53739ef9b34b93ba9c97d3ee56cb99
SIP-CSeq: 1 NEGOTIATE
Peer: lync.contoso.com:52529;ms-fe=LYNCFE1.fabrikam.com
$$end_record
TL_INFO(TF_PROTOCOL) [1]184C.0EFC::05/01/2014-11:50:32.670.00026615 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[1853494582] $$begin_record
Trace-Correlation-Id: 1853494582
Instance-Id: 425E
Direction: outgoing;source="local"
Peer: lync.contoso.com:52529;ms-fe=LYNCFE1.fabrikam.com
Message-Type: response
Start-Line: SIP/2.0 200 OK
FROM: <sip:contoso.com>;ms-fe=LYNCFE1.fabrikam.com
To: <sip:contoso.com>;tag=C3A751556F332F7265E9BA2517C878D4
CALL-ID: aa53739ef9b34b93ba9c97d3ee56cb99
CSEQ: 1 NEGOTIATE
Via: SIP/2.0/TLS 10.10.0.11:52529;ms-received-port=52529;ms-received-cid=10BE00
Content-Length: 0
Require: ms-feature-info
Supported: NewNegotiate,OCSNative,ECC,IPv6,TlsRecordSplit
Server: RTC/5.0
$$end_record
TL_INFO(TF_PROTOCOL) [1]2DF8.1078::05/01/2014-11:50:32.671.000266da (S4,SipMessage.DataLoggingHelper:sipmessage.cs(774))[720988281]
>>>>>>>>>>>>Outgoing SipMessage c=[<SipTlsConnection_F8A09B>], 10.10.0.11:52529->10.10.0.11:5061
SERVICE sip:2138797082;[email protected];user=phone SIP/2.0
FROM: <sip:2138797082;[email protected];user=phone>;epid=16FEE4A02E;tag=22fd877f3a
TO: <sip:2138797082;[email protected];user=phone>
CSEQ: 3 SERVICE
CALL-ID: ac0f7bc4cdc94c1dbd0bb51c7c02c890
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 10.10.0.11:52529;branch=z9hG4bK67a4c9d1
CONTACT: <sip:[email protected];gruu;opaque=srvr:MediationServer:CiGdW3iH5FiI3Qvr3PIKGQAA>
CONTENT-LENGTH: 628
SUPPORTED: gruu-10
USER-AGENT: RTCC/5.0.0.0 MediationServer
CONTENT-TYPE: application/msrtc-reporterror+xml
- <reportError xmlns="http://schemas.microsoft.com/2006/09/sip/error-reporting">
- <error callId="[email protected]"
fromUri="sip:3158222726;[email protected];user=phone"
toUri="sip:2138797082;[email protected];user=phone"
fromTag="ac3201ce-ae"
toTag=""
requestType="INVITE"
contentType="application/sdp;call-type=audio"
responseCode="400">
<diagHeader>10013;reason="Gateway peer in inbound call is not found in topology document or does not depend on this Mediation Server"</diagHeader>
<progressReports/>
- </error>
------------EndOfOutgoing SipMessage

[solved] problems with timeouts and tcp retransmission

I've recently upgraded my archlinux and am having real problems with the network.
I have checked the configuation and all seems ok.
Everything like DNS/Gateways/IPs all seem to be setup (not changed anything from when it was working before)
I read about setting the MTU manually
ifconfig eth0 mtu 1492
I tried this but it doesn't seem to make any difference
Looking at the packetflow on wireshark it seems that there are a huge amount of TCP Dup ACK and TCP Retransmission when trying to POST
If I boot into windows everything is fine so unfortunately it seems that it might be something with linux
Everything in linux seemed to be working ok before I upgraded
Last edited by equilibrium (2009-12-05 15:13:14)

seems that I am still unable to post from my arch system
$ dmesg | grep sky2
sky2 driver version 1.23
sky2 0000:02:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
sky2 0000:02:00.0: setting latency timer to 64
sky2 0000:02:00.0: Yukon-2 EC chip revision 2
sky2 0000:02:00.0: irq 29 for MSI/MSI-X
sky2 eth0: addr xx:xx:xx:xx:xx:xx
sky2 eth0: enabling interface
sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:17:31:F4:ED:A2
inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1170 errors:0 dropped:0 overruns:0 frame:0
TX packets:1362 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1101154 (1.0 Mb) TX bytes:197742 (193.1 Kb)
Interrupt:19
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4595 errors:0 dropped:0 overruns:0 frame:0
TX packets:4595 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:541498 (528.8 Kb) TX bytes:541498 (528.8 Kb)
/etc/rc.conf
eth0="eth0 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255"
INTERFACES=(eth0)
gateway="default gw 192.168.1.1"
ROUTES=(gateway)

Solaris Kernel and TCP/IP Tuning Parameters (Continued)

This page describes some configuration optimizations for Solaris hosts running ATG Page Serving instances (application servers) that will increase server efficiency.
Note that these changes are specific to Solaris systems running ATG application servers (+page serving+ instances). Do not use these on a web server or database server. Those systems require entirely different settings.
h3. Solaris 10 Kernel
Adjust /etc/system (parameters below) and reboot the system.
set rlim_fd_cur=4096
set rlim_fd_max=4096
set tcp:tcp_conn_hash_size=32768
set shmsys:shminfo_shmmax=4294967295
set autoup=900
set tune_t_fsflushr=1h4. Set limits on file descriptors
{color:blue}set rlim_fd_max = 4096{color}
{color:blue}set rlim_fd_cur = 4096{color}
Raise the file-descriptor limits to a maximum of 4096. Note that this tuning option was not mentioned in the "Sun Performance And Tuning" book.
[http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-32/index.html]
h4. Increase the connection hash table size
{color:blue}set tcp:tcp_conn_hash_size=8192{color}
Increase the connection hash table size to make look-up's more efficient. The connection hash table size can be set only once, at boot time.
[http://download.oracle.com/docs/cd/E19455-01/816-0607/chapter4-63/index.html]
h4. Increase maximum shared memory segment size
{color:blue}set shmsys:shminfo_shmmax=4294967295{color}
Increase the maximum size of a system V shared memory segment that can be created from roughly 8MB to 4GB.
This provides an adequate ceiling; it does not imply that shared memory segments of this size will be created.
[http://download.oracle.com/docs/cd/E19683-01/816-7137/chapter2-74/index.html]
h4. Increase memory allocated for dirty pages
{color:blue}set autoup=900{color}
Increase the amount of memory examined for dirty pages in each invocation and frequency of file system synchronizing operations.
The value of autoup is also used to control whether a buffer is written out from the free list. Buffers marked with the B_DELWRI flag (which identifies file content pages that have changed) are written out whenever the buffer has been on the list for longer than autoup seconds. Increasing the value of autoup keeps the buffers in memory for a longer time.
[http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-16/index.html]
h4. Specify the time between fsflush invocations
Specifies the number of seconds between fsflush invocations.
{color:blue}set tune_t_fsflushr=1{color}
[http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-105/index.html]
Again, note that after adjusting any of the preceding kernel parameters you will need to reboot the Solaris server.
h3. TCP
ndd -set /dev/tcp tcp_time_wait_interval 60000
ndd -set /dev/tcp tcp_conn_req_max_q 16384
ndd -set /dev/tcp tcp_conn_req_max_q0 16384
ndd -set /dev/tcp tcp_ip_abort_interval 60000
ndd -set /dev/tcp tcp_keepalive_interval 7200000
ndd -set /dev/tcp tcp_rexmit_interval_initial 4000
ndd -set /dev/tcp tcp_rexmit_interval_max 10000
ndd -set /dev/tcp tcp_rexmit_interval_min 3000
ndd -set /dev/tcp tcp_smallest_anon_port 32768
ndd -set /dev/tcp tcp_xmit_hiwat 131072
ndd -set /dev/tcp tcp_recv_hiwat 131072
ndd -set /dev/tcp tcp_naglim_def 1h4. Tuning the Time Wait Interval and TCP Connection Hash Table Size
{color:blue}/usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000{color}
The tcp_time_wait_interval is how long a connection stays in the TIME_WAIT state after it has been closed (default value 240000 ms or 4 minutes). With the default setting, this socket will remain for 4 minutes after you have closed the FTP connection. This is normal operating behavior. It is done to ensure that any slow packets on the network will arrive before the socket is completely shutdown. As a result, a future program that uses the same socket number won't get confused upon receipt of packets that were intended for the previous program.
On a busy Web server a large backlog of connections waiting to close could build up and the kernel can become inefficient in locating an available TCP data structure. Therefore it is recommended to change this value to 60000 ms or 1 minute.
h4. Tuning the maximum number of requests per IP address per port
{color:blue}ndd -set /dev/tcp tcp_conn_req_max_q 16384{color}
{color:blue}ndd -set /dev/tcp tcp_conn_req_max_q0 16384{color}
The {color:blue}tcp_conn_req_max_q{color} and {color:blue}tcp_conn_req_max_q0{color} parameters are associated with the maximum number of requests that can be accepted per IP address per port. tcp_conn_req_max_q is the maximum number of incoming connections that can be accepted on a port. tcp_conn_req_max_q0 is the maximum number of “half-open” TCP connections that can exist for a port. The parameters are separated in order to allow the administrator to have a mechanism to block SYN segment denial of service attacks on Solaris.
The default values are be too low for a non-trivial web server, messaging server or directory server installation or any server that expects more than 128 concurrent accepts or 4096 concurrent half-opens. Since the ATG application servers are behind a DMZ firewall, we needn't starve these values to ensure against DOS attack.
h4. Tuning the total retransmission timeout value
{color:blue}ndd -set /dev/tcp tcp_ip_abort_interval 60000{color}
{color:blue}tcp_ip_abort_interval{color} specifies the default total retransmission timeout value for a TCP connection. For a given TCP connection, if TCP has been retransmitting for tcp_ip_abort_interval period of time and it has not received any acknowledgment from the other endpoint during this period, TCP closes this connection.
h4. Tuning the Keep Alive interval value
{color:blue}ndd -set /dev/tcp tcp_keepalive_interval 7200000{color}
{color:blue}tcp_keepalive_interval{color} sets a probe interval that is first sent out after a TCP connection is idle on a system-wide basis.
If SO_KEEPALIVE is enabled for a socket, the first keep-alive probe is sent out after a TCP connection is idle for two hours, the default value of the {color:blue}tcp_keepalive_interval{color} parameter. If the peer does not respond to the probe after eight minutes, the TCP connection is aborted.
The {color:blue}tcp_rexmit_interval_*{color} values set the initial, minimum, and maximum retransmission timeout (RTO) values for a TCP connections, in milliseconds.
h4. Tuning the TCP Window Size
{color:blue}/usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 65535{color}
{color:blue}/usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 65535{color}
Setting these two parameters controls the transmit buffer and receive window. We are tuning the kernel to set each window to 65535 bytes. If you set it to 65536 bytes (64K bytes) or more with Solaris 2.6, you trigger the TCP window scale option (RFC1323).
h4. Tuning TCP Slow Start
{color:blue}/usr/sinb/ndd -set /dev/tcp tcp_slow_start_initial 4{color}
tcp_slow_start_initial is the number of packets initially sent until acknowledgment, the congestion window limit.
h4. Tuning the default bytes to buffer
{color:blue}ndd -set /dev/tcp tcp_naglim_def 1{color}
{color:blue}tcp_naglim_def{color} is the default number of bytes to buffer. Each connection has its own copy of this value, which is set to the minimum of the MSS for the connection and the default value. When the application sets the TCP_NODELAY socket option, it changes the connection's copy of this value to 1. The idea behind this algorithm is to reduce the number of small packets transmitted across the wire by introducing a short (100ms) delay for packets smaller than some minimum.
Changing the value of tcp_naglim_def to 1 will have the same effect (on connections established after the change) as if each application set the TCP_NODELAY option.
{note}
The current value of any of the TCP parameters can be displayed with the command ndd get. So to retrieve the current setting of the {color:blue}tcp_naglim_def parameter{color}, simply execute the command:\\
{color:blue}ndd -get /dev/tcp tcp_naglim_def{color}
{note}
h3. References
Solaris Tunable Parameters Reference Manual
[http://download.oracle.com/docs/cd/E19455-01/816-0607/index.html]
WebLogic Server Performance and Tuning
[http://download.oracle.com/docs/cd/E11035_01/wls100/perform/OSTuning.html]

For example,
Socket.setSoTimeout() sets SO_TIMEOUT option and I
want to what TCP parameter this option corresponds in
the underlying TCP connection.This doesn't correspond to anything in the connection, it is an attribute of the API.
The same questions
arises fro other options from SocketOptions class.setTcpNoDelay() controls the Nagle algorithm. set{Send,Receive}BufferSize() controls the local socket buffers.
Most of this is quite adequately described in the javadoc actually.

EAP-TLS and EAP-FAST

Hi NetPro.
EAP-TLS is working now, but how to configure EAP-FAST as the backup in case TLS is failure then user still able to use FAST as the second choice ?
your reply will be highly appreciated.
thanks heaps.
Jack

All you really need to do is enabled EAP-FAST on the Radius server. If you are running a controller environment there isn't any changes on the controller needed. If you are running autonomous make sure you have both "authentication open..." and "authentication network-eap..." configured under the SSID. They only thing that would need to be changed would be the client. You could setup two profiles, one for TLS and the other for EAP-FAST.

EAP Chaining with Machine TLS and User PEAP

We are deploying an ISE based .1x. The design is to use eap-tls for machine and eap-peap for user. Apparently EAP-Chaining is recommended, but can anyone confirm if we can do chaining based on machine TLS and user PEAP. I have done some investigation and could not find any supporting document, but not any document saying not supporting either. Looking at Anyconnect profile editor, it does not look like this configuration is supported. Has anyone done this before?
Thanks a lot.

http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-security/howto_80_eapchaining_deployment.pdf
Just change the authentication policy to allow the methods you want to use under eap-fast (eap-chaining) and use the same ones in your nam client configuration settings.

How can i use the SNMP and TCP/IP together in Labview?

I want to use the SNMP and TCP/IP together in the Labview to communicate between the two computers, If anyone know about it , please write back.
Santosh Chavan
IIT MADRAS.

You can use LabVIEWs UDP functions to communicate with SNMP devices. The tedious part is converting the MIB information into the required hex message.
There is also a problem in using the UDP functions on port 161 (default SNMP port) if the Windows SNMP services is running.

ACE duplicate ack and tcp out-of-order errors

Hi,
I have just performed a capture using a NAM in my 6500 on the port attached to my ACE appliance.
What i have noticed in the capture is a lot of duplicate ack errors and tcp out-of-sync errors.
The reason we found this was becuase the link utilisation per session seems higher than we expected, hence are the errors adding to this and is there any way to remedy them?
Thanks
Scott

Hi Scott,
I'm not sure why you would see duplicate packets, although when you use SPAN, I know you can see them when you configure it to capture both directions on a VLAN. This is because you see each packet as it enters and leaves the VLAN. I don't know if that would apply to a NAM.
One thing you could do is use the ACE 4710's built-in capture utility to see if you see the same symptoms from an alternative source. This is covered in the Capturing Packet Information section of the configuration guides.
Hope this helps,
Sean

ACE Dup ACK and TCP Out-of-order

Hi,
I have a pair of FT ACE 4710 offloading https traffic to a couple of webservers. We are seeing very high network utilisation when I capture the client facing port of the active ACE. There appears to alot of duplicate ACKs and TCP out-of-order packets (as shown by wireshark). Does anyone know if this is a problem with the ACE or "normal"
Thanks

I've seen some similar behaviour with the ACE Module and Apache webservers. To mitigate this I've configured the following which seems to work.
On the ACE Module
parameter-map type http ALL-HEADERS
persistence-rebalance
parameter-map type connection TCP-OPTIONS
set tcp syn-retry 5
tcp-options timestamp allow
policy-map multi-match test-policy
class http-vip
    loadbalance vip inservice
    loadbalance policy http-test-pm
    loadbalance vip icmp-reply active
    appl-parameter http advanced-options ALL-HEADERS
    connection advanced-options TCP-OPTIONS
On Apache here are the two test results with keepalive on and off
httpd.conf
KeepAlive Off
MaxKeepAliveRequests 1024
KeepAliveTimeout 30
MK-ACE01/001# show serverfarm MK-FARM-sf
serverfarm     : MK-FARM-sf, type: HOST
total rservers : 8
                                                ----------connections-----------
       real                  weight state        current    total      failures
   ---+---------------------+------+------------+----------+----------+---------
   rserver: MK-HOST10
       10.10.1.10:0          8      OPERATIONAL 321        510863     16442
   rserver: MK-HOST11
       10.10.1.11:0          8      OPERATIONAL 304        512718     16276
   rserver: MK-HOST12
       10.10.1.12:0          8      OPERATIONAL 286        524207     17257
   rserver: MK-HOST13
       10.10.1.13:0          8      OPERATIONAL 291        516987     16626
   rserver: MK-HOST14
       10.10.1.14:0          8      OPERATIONAL 291        513016     16594
   rserver: MK-HOST15
       10.10.1.15:0          8      OPERATIONAL 311        510177     16434
   rserver: MK-HOST16
       10.10.1.16:0          8      OPERATIONAL 345        516340     16708
   rserver: MK-HOST17
       10.10.1.17:0          8      OPERATIONAL 282        513046     16418
httpd.conf
KeepAlive On
MaxKeepAliveRequests 1024
KeepAliveTimeout 30
MK-ACE01/001# show serverfarm MK-FARM-sf
serverfarm     : MK-FARM-sf, type: HOST
total rservers : 8
                                                ----------connections-----------
       real                  weight state        current    total      failures
   ---+---------------------+------+------------+----------+----------+---------
   rserver: MK-HOST10
       10.10.1.10:0          8      OPERATIONAL 0          553        0
   rserver: MK-HOST11
       10.10.1.11:0          8      OPERATIONAL 0          551        0
   rserver: MK-HOST12
       10.10.1.12:0          8      OPERATIONAL 0          552        0
   rserver: MK-HOST13
       10.10.1.13:0          8      OPERATIONAL 0          555        0
   rserver: MK-HOST14
       10.10.1.14:0          8      OPERATIONAL 0          554        0
   rserver: MK-HOST15
       10.10.1.15:0          8      OPERATIONAL 0          551        0
   rserver: MK-HOST16
       10.10.1.16:0          8      OPERATIONAL 0          550        0
   rserver: MK-HOST17
       10.10.1.17:0          8      OPERATIONAL 0          550        0
This seems to of reduced the large number or re-transmits and dup-acks.

TLS and message filter question

Hello,
I don't believe this is possible because of the email workflow but I want to cover all bases.
Here is the scenario:
- We have 2 IronPort C350's. I have one that handles all normal outbound mail flow and the other handles CRE encryption as well as being set to TLS preferred for all outbound mail
-I have several outbound content filters set on the first box that will send to alt host (the second box) for either CRE encryption or simply delivered via TLS preferred.
-The filters that do not use CRE encryption are basically for SSN and HIPAA term matches from (careless) internal users who do not choose end-to-end encryption.
I was wondering if it were possible to have a rule set up on the second box to basically act on failed TLS requests for outbound messages and use CRE encryption?
Another option I was looking at was setting TLS to required and then setting up a rule to notify the internal sender of failed TLS.
My third option ( and the one I think I'll end up having to use) is to set the filters up to use CRE encryption instead.
Any insight into this would be greatly appreciated. Thanks![/list]

I was wondering if it were possible to have a rule set up on the second box to basically act on failed TLS requests for outbound messages and use CRE encryption?
Currently, The IronPort is not able to turn over a failed TLS
connection to another mechanism.
Another option I was looking at was setting TLS to required and then setting up a rule to notify the internal sender of failed TLS.
You can configure a workaround of sorts by creating specific bounce
profiles for domains that require TLS, and setting these profiles to
bounce messages within a short period of time 9 say 2 minutes or
less).
That way, if the message is in the delivery queue and a TLS
connection cannot be verified to the recipient host, the message
would bounce.
The bounce would contain a 5.4.7 error message stating that TLS was
unavailable. This workaround would depend on how savvy your users
are at reading/understanding bounce messages.
My third option ( and the one I think I'll end up having to use) is to set the filters up to use CRE encryption instead.
This would probably be the best option.

EAP-TLS and LEAP on a 1200 AP

Is it possible to have a 1200 AP use EAP-TLS and LEAP authentication simultaneously? We currently use LEAP in production and I have successfully configured a test 1200 AP to use EAP-TLS, but we would like to have it use both methods until all clients can be set up for EAP-TLS.

You may view this link : http://www.cisco.com/warp/public/cc/pd/sqsw/sq/tech/acstl_wp.htm
Regards
Mc

What is relationship between ping and tcp in BGP ?

Dear All, As we know, BGP peer relation needs reachability of tcp 179. But usually if the two peer neighbors can ping each other, we can consider the tcp 179 is working well. So what is relationship between ping and tcp in BGP in this situation ? Thank you !

Ping is a tool in the ICMP suite, and doesn't use ports. It uses codes. TCP is a different protocol, and does use ports. In the case of BGP, once the process is started (and you have at least one neighbor command) it will open port 179. Who is the client and who is the server in the neighborship, does not matter. If you have issues with BGP neighbors being formed, and you believe the configuration is correct - Telnet to the port to be sure that it is working. Also, if they are not directly connected, you may need to enable multihop. Check Access lists also.
Pinging the other router it is unrelated to the BGP TCP process. - Here is an example pinging fine, but before the BGP process has opened port 179.
There is just two routers on a /30 segment - 10.19.2.2 and 10.19.2.1
LON-ROUTER#ping 10.19.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.19.2.1, timeout is 2 seconds:
Success rate is 80 percent (4/5), round-trip min/avg/max = 8/9/12 ms
Pings fine.
LON-ROUTER#
LON-ROUTER#telnet 10.19.2.1 179
Trying 10.19.2.1, 179 ...
% Connection refused by remote host
Enable BGP on the neighbor:
LON-CORE(config)#router bgp 65000
LON-CORE(config-router)#neighbor 10.19.2.2 remote-as 65001
LON-CORE(config-router)#
try the TCP connection again
LON-ROUTER#
LON-ROUTER#telnet 10.19.2.1 179
Trying 10.19.2.1, 179 ... Open
The connection now works, as the port is open on the neighbor.

Master and tcp/ip newbie questions?

Hi folks,
Just a little questions about replication and tcp/ip capabilities of Berkeley DB.
Is it possible that the master database is not on the same computer that the computer running the app?
Is it possible there in no database on the computer that run the app, only on "servers"?
Thanks in advance for all answer
PS: Sorry for my bad english

For example,
Socket.setSoTimeout() sets SO_TIMEOUT option and I
want to what TCP parameter this option corresponds in
the underlying TCP connection.This doesn't correspond to anything in the connection, it is an attribute of the API.
The same questions
arises fro other options from SocketOptions class.setTcpNoDelay() controls the Nagle algorithm. set{Send,Receive}BufferSize() controls the local socket buffers.
Most of this is quite adequately described in the javadoc actually.

OSI and TCP/IP model

Hi,
I made a table for OSI model and TCP/IP model and diffrent protocols. If you have any additions, comments feel free to reply. There are a lot of protocols out there and these are only few and I want to separate each protocol to its correct layers.
Any addition or comments will be much appreciated.
Thanks.

Hi Rivan,
The listed protocols sounds good to me. If you want complete list of protocols which runs on each layer then click on the below links for each layer.
Protocols run on Session layer:
http://en.wikipedia.org/wiki/Application_layer
http://en.wikipedia.org/wiki/Session_layer
http://en.wikipedia.org/wiki/Presentation_layer
http://en.wikipedia.org/wiki/Transport_layer
http://en.wikipedia.org/wiki/Network_layer
http://en.wikipedia.org/wiki/Datalink_layer
http://en.wikipedia.org/wiki/Physical_layer
HTH
Regards
Inayath
*Plz rate the usefull posts and close the thread if no further info is needed.

TLS And TCP/IP

Similar Messages

Maybe you are looking for