Asp drop - First TCP packet not SYN (tcp-not-syn)

I have many tcp-not-syn:
First TCP packet not SYN (tcp-not-syn) 46841247
For sure it is not a routing issue cause ie 10.32.3.230 usually can connect to 192.168.16.2 which is a proxy server. Sometimes it can't and I get the
tcp-not-syn error. So after a capture I got the following,
ASA# capture asp-drop type asp-drop tcp-not-syn
ASA# sh capture asp-drop | i 10.32.3.230
2397: 16:11:31.904295 802.1Q vlan#8 P0 10.32.3.230.2322 > 192.168.16.2.8080: R 556133793:556133793(0) win 0
2398: 16:11:31.905272 802.1Q vlan#8 P0 10.32.3.230.2322 > 192.168.16.2.8080: R 556133793:556133793(0) win 0
2400: 16:11:31.908583 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2401: 16:11:31.908613 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2402: 16:11:31.908629 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2403: 16:11:31.908659 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2404: 16:11:31.908766 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2405: 16:11:31.908796 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2406: 16:11:31.908812 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) ack 4258924744 win 0
2407: 16:11:31.909071 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2408: 16:11:31.909102 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2409: 16:11:31.909132 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2410: 16:11:31.910490 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
2411: 16:11:31.910521 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
2412: 16:11:31.910551 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
2413: 16:11:31.910566 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
2414: 16:11:31.911192 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
2415: 16:11:31.911207 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
2416: 16:11:31.911238 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
2417: 16:11:31.915205 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
2418: 16:11:31.915235 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
2419: 16:11:31.915296 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
2420: 16:11:31.915327 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2421: 16:11:31.915357 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2422: 16:11:31.915815 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
2432: 16:11:33.102426 802.1Q vlan#8 P0 10.32.3.230.2317 > 192.168.16.2.8080: R 4189536219:4189536219(0) win 0
2433: 16:11:33.102457 802.1Q vlan#8 P0 10.32.3.230.2317 > 192.168.16.2.8080: R 4189536219:4189536219(0) win 0
2434: 16:11:33.102487 802.1Q vlan#8 P0 10.32.3.230.2317 > 192.168.16.2.8080: R 4189536219:4189536219(0) win 0
syslog message says:
deny tcp (no connection) from 10.32.3.78/1646 to 192.168.16.2/8080 flags RST on interface inside
The question is how can I define it is:
1. the proxy 192.168.16.2 itself is too slow responding to the syn packet sent from the client 10.32.3.78
2. a reset is sent by the proxy 192.168.16.2 and then forwarded by the ASA to the client 10.32.3.78
3. an idle timeout tuning needed on firewall
4. anything else
Thanks

Hi,
Since it is a RST packet coming from client IP destined to proxy server IP on ASA's interface (of course with no associated connection in ASA state table), ASA will drop it as first tcp packet not syn.
When a packet arrives on ASA, it checks to see if it belongs to an existing flow, if not, it has to be a new connection but since SYN flag is not set here, it gets dropped under above reason code.
Now, you would probabaly want to capture the entire traffic stream from client to server on ASA interface to understand what caused those resets. May be client sent some new requests (SYN's) and proxy was too busy to respond. Again, complete capture in pcap would be needed for further analysis.
Regards,
Sourav Kakkar

Similar Messages

Dropping 40%+ internet packets, Spartansburg PA. Not losing packets beyond gateway.

To start, this is not an isolated issue. Others in Spartansburg PA are experiencing this issue after investigating, plus my friend in Spring Creak PA (a completely different service station) is experiencing this issue. This is NOT an issue with my line due to ANY reason.
I am losing over 40% of my internet packets when pinging google.com for over ten mins! I also tried yahoo.com, facebook.com... this isn't just one url I am loosing packets too!
To make sure this wasn't a line issue, I pinged my gateway address at the same time I was pinging those urls.. 0% packet lose!
My success rate for completing a Speakeasy speed test is also not 100% (It'd be one thing if the line was slow, its winter after all, but it’s another thing to loose packets entirely!)
I would like someone from Verizon to investigate this by running their own test. This has been going on for over a week and it is a serious hindrance. I have never had a Quality of Service issue like this with any other ISP.
Thank you for your time.

I am also having the same issues as mentioned above. This is coming from the subarbs of Philadelphia. I noticed it start last Thursday. Below are a couple ping/packet loss and traceroutes. I gathered these pings when I noticed extreme lag. 7 second pings for multiple seconds is terrible.
PING google.com (74.125.115.147) 56(84) bytes of data.
64 bytes from google.com (74.125.115.147): icmp_req=3 ttl=53 time=27.8 ms
64 bytes from google.com (74.125.115.147): icmp_req=4 ttl=53 time=28.2 ms
64 bytes from google.com (74.125.115.147): icmp_req=6 ttl=53 time=27.5 ms
64 bytes from google.com (74.125.115.147): icmp_req=8 ttl=53 time=26.7 ms
64 bytes from google.com (74.125.115.147): icmp_req=9 ttl=53 time=28.2 ms
64 bytes from google.com (74.125.115.147): icmp_req=11 ttl=53 time=28.2 ms
64 bytes from google.com (74.125.115.147): icmp_req=12 ttl=53 time=26.7 ms
64 bytes from google.com (74.125.115.147): icmp_req=14 ttl=53 time=27.1 ms
64 bytes from google.com (74.125.115.147): icmp_req=15 ttl=53 time=189 ms
64 bytes from google.com (74.125.115.147): icmp_req=16 ttl=53 time=356 ms
64 bytes from google.com (74.125.115.147): icmp_req=17 ttl=53 time=533 ms
64 bytes from google.com (74.125.115.147): icmp_req=18 ttl=53 time=27.0 ms
64 bytes from google.com (74.125.115.147): icmp_req=20 ttl=53 time=27.6 ms
64 bytes from google.com (74.125.115.147): icmp_req=21 ttl=53 time=27.4 ms
64 bytes from google.com (74.125.115.147): icmp_req=22 ttl=53 time=28.0 ms
64 bytes from google.com (74.125.115.147): icmp_req=23 ttl=53 time=26.1 ms
64 bytes from google.com (74.125.115.147): icmp_req=24 ttl=53 time=27.7 ms
64 bytes from google.com (74.125.115.147): icmp_req=25 ttl=53 time=27.6 ms
64 bytes from google.com (74.125.115.147): icmp_req=26 ttl=53 time=27.4 ms
64 bytes from google.com (74.125.115.147): icmp_req=27 ttl=53 time=29.5 ms
64 bytes from google.com (74.125.115.147): icmp_req=28 ttl=53 time=27.5 ms
64 bytes from google.com (74.125.115.147): icmp_req=29 ttl=53 time=26.4 ms
64 bytes from google.com (74.125.115.147): icmp_req=32 ttl=53 time=28.3 ms
64 bytes from google.com (74.125.115.147): icmp_req=33 ttl=53 time=413 ms
64 bytes from google.com (74.125.115.147): icmp_req=34 ttl=53 time=916 ms
64 bytes from google.com (74.125.115.147): icmp_req=35 ttl=53 time=1395 ms
64 bytes from google.com (74.125.115.147): icmp_req=36 ttl=53 time=1747 ms
64 bytes from google.com (74.125.115.147): icmp_req=37 ttl=53 time=2238 ms
64 bytes from google.com (74.125.115.147): icmp_req=38 ttl=53 time=2751 ms
64 bytes from google.com (74.125.115.147): icmp_req=43 ttl=53 time=4245 ms
64 bytes from google.com (74.125.115.147): icmp_req=46 ttl=53 time=4268 ms
64 bytes from google.com (74.125.115.147): icmp_req=47 ttl=53 time=4429 ms
64 bytes from google.com (74.125.115.147): icmp_req=48 ttl=53 time=4700 ms
64 bytes from google.com (74.125.115.147): icmp_req=51 ttl=53 time=5095 ms
64 bytes from google.com (74.125.115.147): icmp_req=52 ttl=53 time=4896 ms
64 bytes from google.com (74.125.115.147): icmp_req=57 ttl=53 time=1609 ms
64 bytes from google.com (74.125.115.147): icmp_req=58 ttl=53 time=799 ms
64 bytes from google.com (74.125.115.147): icmp_req=59 ttl=53 time=107 ms
64 bytes from google.com (74.125.115.147): icmp_req=60 ttl=53 time=28.1 ms
64 bytes from google.com (74.125.115.147): icmp_req=61 ttl=53 time=26.5 ms
64 bytes from google.com (74.125.115.147): icmp_req=62 ttl=53 time=26.9 ms
64 bytes from google.com (74.125.115.147): icmp_req=63 ttl=53 time=28.4 ms
64 bytes from google.com (74.125.115.147): icmp_req=64 ttl=53 time=27.9 ms
64 bytes from google.com (74.125.115.147): icmp_req=66 ttl=53 time=26.7 ms
64 bytes from google.com (74.125.115.147): icmp_req=67 ttl=53 time=26.7 ms
64 bytes from google.com (74.125.115.147): icmp_req=68 ttl=53 time=26.9 ms
64 bytes from google.com (74.125.115.147): icmp_req=69 ttl=53 time=29.3 ms
^C
--- google.com ping statistics ---
69 packets transmitted, 47 received, 31% packet loss, time 68192ms
rtt min/avg/max/mdev = 26.162/882.890/5095.440/1554.459 ms, pipe 6
ING google.com (74.125.113.103) 56(84) bytes of data.
64 bytes from google.com (74.125.113.103): icmp_req=1 ttl=53 time=7021 ms
64 bytes from google.com (74.125.113.103): icmp_req=2 ttl=53 time=6912 ms
64 bytes from google.com (74.125.113.103): icmp_req=3 ttl=53 time=6896 ms
64 bytes from google.com (74.125.113.103): icmp_req=4 ttl=53 time=7168 ms
64 bytes from google.com (74.125.113.103): icmp_req=5 ttl=53 time=7361 ms
64 bytes from google.com (74.125.113.103): icmp_req=6 ttl=53 time=7417 ms
64 bytes from google.com (74.125.113.103): icmp_req=8 ttl=53 time=7675 ms
64 bytes from google.com (74.125.113.103): icmp_req=9 ttl=53 time=7710 ms
64 bytes from google.com (74.125.113.103): icmp_req=11 ttl=53 time=7770 ms
64 bytes from google.com (74.125.113.103): icmp_req=13 ttl=53 time=7719 ms
64 bytes from google.com (74.125.113.103): icmp_req=14 ttl=53 time=7231 ms
64 bytes from google.com (74.125.113.103): icmp_req=15 ttl=53 time=7125 ms
64 bytes from google.com (74.125.113.103): icmp_req=16 ttl=53 time=7196 ms
64 bytes from google.com (74.125.113.103): icmp_req=17 ttl=53 time=7283 ms
64 bytes from google.com (74.125.113.103): icmp_req=19 ttl=53 time=7354 ms
64 bytes from google.com (74.125.113.103): icmp_req=20 ttl=53 time=7326 ms
64 bytes from google.com (74.125.113.103): icmp_req=21 ttl=53 time=7616 ms
64 bytes from google.com (74.125.113.103): icmp_req=23 ttl=53 time=7763 ms
64 bytes from google.com (74.125.113.103): icmp_req=25 ttl=53 time=7518 ms
64 bytes from google.com (74.125.113.103): icmp_req=26 ttl=53 time=7334 ms
64 bytes from google.com (74.125.113.103): icmp_req=30 ttl=53 time=7050 ms
64 bytes from google.com (74.125.113.103): icmp_req=31 ttl=53 time=6918 ms
64 bytes from google.com (74.125.113.103): icmp_req=32 ttl=53 time=7035 ms
64 bytes from google.com (74.125.113.103): icmp_req=33 ttl=53 time=7126 ms
64 bytes from google.com (74.125.113.103): icmp_req=34 ttl=53 time=6854 ms
64 bytes from google.com (74.125.113.103): icmp_req=37 ttl=53 time=7040 ms
64 bytes from google.com (74.125.113.103): icmp_req=39 ttl=53 time=7181 ms
64 bytes from google.com (74.125.113.103): icmp_req=40 ttl=53 time=7110 ms
64 bytes from google.com (74.125.113.103): icmp_req=42 ttl=53 time=7335 ms
64 bytes from google.com (74.125.113.103): icmp_req=43 ttl=53 time=7245 ms
64 bytes from google.com (74.125.113.103): icmp_req=44 ttl=53 time=7233 ms
64 bytes from google.com (74.125.113.103): icmp_req=45 ttl=53 time=6867 ms
64 bytes from google.com (74.125.113.103): icmp_req=46 ttl=53 time=6568 ms
64 bytes from google.com (74.125.113.103): icmp_req=48 ttl=53 time=6853 ms
64 bytes from google.com (74.125.113.103): icmp_req=49 ttl=53 time=6941 ms
64 bytes from google.com (74.125.113.103): icmp_req=51 ttl=53 time=6217 ms
64 bytes from google.com (74.125.113.103): icmp_req=52 ttl=53 time=5076 ms
64 bytes from google.com (74.125.113.103): icmp_req=53 ttl=53 time=4089 ms
64 bytes from google.com (74.125.113.103): icmp_req=54 ttl=53 time=3090 ms
64 bytes from google.com (74.125.113.103): icmp_req=56 ttl=53 time=1116 ms
64 bytes from google.com (74.125.113.103): icmp_req=57 ttl=53 time=123 ms
64 bytes from google.com (74.125.113.103): icmp_req=58 ttl=53 time=27.2 ms
64 bytes from google.com (74.125.113.103): icmp_req=59 ttl=53 time=27.6 ms
64 bytes from google.com (74.125.113.103): icmp_req=60 ttl=53 time=26.7 ms
64 bytes from google.com (74.125.113.103): icmp_req=61 ttl=53 time=28.1 ms
64 bytes from google.com (74.125.113.103): icmp_req=62 ttl=53 time=27.8 ms
64 bytes from google.com (74.125.113.103): icmp_req=63 ttl=53 time=26.4 ms
64 bytes from google.com (74.125.113.103): icmp_req=64 ttl=53 time=28.7 ms
^C
--- google.com ping statistics ---
64 packets transmitted, 48 received, 25% packet loss, time 63422ms
rtt min/avg/max/mdev = 26.432/5680.762/7770.894/2781.887 ms, pipe 8
traceroute to google.com (74.125.115.147), 30 hops max, 60 byte packets
1 * * *
2 10.7.16.1 (10.7.16.1) 9.245 ms 10.587 ms 12.078 ms
3 at (130.81.11.225) 13.893 ms 15.135 ms 16.356 ms
4 so (130.81.20.138) 17.821 ms 19.309 ms 20.454 ms
5 0.xe (152.63.3.69) 29.078 ms 0.xe (152.63.3.249) 30.880 ms 0.xe-3-0-2.XL4.IAD8.ALTER.NET (152.63.3.57) 31.131 ms
6 TenGigE0 (152.63.32.198) 59.392 ms 50.667 ms TenGigE0 (152.63.37.98) 49.240 ms
7 google (152.179.50.62) 82.575 ms 82.762 ms 81.635 ms
8 72.14.238.214 (72.14.238.214) 26.059 ms 72.14.238.212 (72.14.238.212) 28.260 ms 216.239.46.248 (216.239.46.248) 28.090 ms
9 209.85.243.114 (209.85.243.114) 60.433 ms 52.703 ms 51.837 ms
10 216.239.48.103 (216.239.48.103) 31.146 ms 26.518 ms 64.233.174.117 (64.233.174.117) 27.577 ms
11 209.85.242.177 (209.85.242.177) 36.145 ms * 209.85.242.181 (209.85.242.181) 33.298 ms
12 google.com (74.125.115.147) 30.762 ms 30.036 ms 28.894 ms

Event: NULL TCP PACKET

Hello all,
we are incrementally receiving a lot of MARS events that comes from Cisco IDS, all those events are â NULL TCP PACKETâ, and the destination is always the same, a smtp ironport machine trough the 25 port, from diferent public IPs.
Does anybody have a similar scenario? What can we do?
Thanks

Hi,
The signature version 364 and the IPS version is 6.1 (1) E2.
It is suppoused that is a single TCP packet with none of the SYN, ACK,FIN or RST flags.
It comes from different public IP's that comes from different ISP's.
Regards
Izaskun

TCP packet out of state: First packet isn't SYN & Outlook is trying to retrieve data from the Microsoft Exchange Server [CAS-ARray]

We are transitioning from Exchange 2003 to Exchange 2010. We found Outlook online mode (non-cached mode) have many warning "Outlook is trying to retrieve data from the Microsoft Exchange Server [CAS-ARray]", usually happen when users tried to open
address book but sometimes even normal operation like click the Send button. The problem does not affect OWA and extremely rare when Outlook is running in cached mode. Check the firewall logs, we notice a lot of "TCP Packet Out of State" drops.
We have a lot from the CAS/HT to DC/GC on TCP_3268 and LDAP. And the errors are "TCP packet out of state: First packet isn't SYN" with tcp_flags FIN-ACK, PUSH-ACK.
We also have a lot from CAS/HT to the Outlook Clients on the static RPC port (TCP_59933). And the errors are "TCP packet out of state: First packet isn't SYN" with tcp_flags FIN-ACK, PUSH-ACK and RST-ACK, ACK.
This happens even on Outlook 2010 which I though it has TCP Keep Alive implmented to keep the session active within 1 hour.
Can somebody tell me if these out-of-state are the cause of our problem? And how to fix it?
THANK 1,000,000

Hello AndyHWC,
I did some consulting with our CAS team and received the following feedback to your post:
It is difficult to determine what is causing resets without seeing the captures first hand however, the concern is that you are seeing dropped packets on the firewall logs. Where is this firewall located?
Based on the description "Check the firewall logs, we notice a lot of "TCP Packet Out of State" drops." and "We have a lot from the CAS/HT to DC/GC on TCP_3268 and
LDAP." indicates to me that the firewall is between CAS and GC. This not supported under any circumstances and would explain the issue they are seeing with clients trying to "retrieve data from the GC".
If there is not a firewall between the GC and CAS then a Microsoft support engineer would need to have concurrent Netmon Captures from client, CAS, GC during the
issue to analyze. If only one GC exists consider adding another GC to handle the client requests and for fault tolerance.
Also verify that all NIC card drivers are updated to the latest driver version
More information about firewalls with Exchange 2007/2010
http://msexchangeteam.com/archive/2009/10/21/452929.aspx
http://technet.microsoft.com/en-us/library/bb232184(EXCHG.80).aspx
You can install the Client Access server role on an Exchange 2007 computer that is running any other server roles except for the Edge Transport server role. You
cannot install the Client Access server role on a computer that is installed in a cluster. Installation of a Client Access server in a perimeter network is not supported.
http://technet.microsoft.com/en-us/library/dd577077(EXCHG.80).aspx
“The Installation of a Client Access Server in a Perimeter Network Is Not Supported
Issue You may want to install an Exchange 2007 Client Access server in a perimeter network. However, this type of installation is not supported in Exchange
2007.
Cause The Exchange 2007 Client Access server role is not supported in any configuration in which a firewall is located between the Client Access server
and a Mailbox server or a domain controller. This includes firewall devices, firewall programs, or any program or device that is designed to restrict traffic between two network locations.
For correct operation, Client Access servers require typical domain connectivity to domain controllers and global catalog servers. Because any devices
or programs that restrict or reduce access to domain controllers or global catalog servers may affect the correct operation of the Client Access server, we do not support this type of configuration.
Resolution To resolve this issue, move the Client Access servers to the internal network. For more information about the ports that Exchange 2007 uses
for various services, see Data Path Security Reference.”
Thanks,
Kevin Ca - MSFT
Kevin Ca - MSFT

WRT54GX2: TCP packets blocked (except SYN/SYN-ACK) to internet

I'm using WRT54GX2 with latest FW 1.01.22 and I've been running into internet connectivity with one of my laptop (Toshiba MX35-S149 using Atheros). From this laptop DNS/ping works to the internet (UDP/ICMP) but all of the TCP data packets from the internet are being blocked by the router (I think). All of the other PC's continue to work with no problem.
Rebooting the router (power cycle) causes thing to work again for this laptop but after some time (15-20 minutes or so) once again the problem comes back. I've already spent about 3 hours with support on this but no luck.
I did a packet capture on the laptop and any HTTP request show TCP SYN, SYN-ACK packets but no data packets. The laptop continues to do the retransmission. At this point I can still PING and DNS resolve any of the names.
The HTTP to the router's page (192.168.1.1) continues to work without any problem (still using the wireless NIC). Hard-wiring the laptop to router works fine.
I asked the support if I can do a packet capture on the router itself but I was told "That is not possible".
I'll add the packet capture files later today.
Any help is appreciated as I don't think I'll get any help from the tech-support.
TIA,
Navras

Interesting - I have a similar problem however I am trying to block packets going out. So you say that it allows the TCP for a little while then later it is blocked.
Why are you trying to pass TCP into the computer specifically?
Do you have a firewall on your laptop that you can check the logs off?
I have been with support for my issue which is basically the BLOCKED SERVICES options are all greyed out. I need to block udp/tcp packets from going out on exactly the same router, same firmware as yours. They just read scripts from their help desk manuals and do not really seem to understand problems that are NOT in the scripts. Too bad I was hoping after cisco took over linksys would get better at customer support, not the other way.
I saw a post previously that states that the same router DOES NOT HAVE the blocked services as a function. The manual and screen seem to indicate otherwise.
Interesting...let us know what happens.
danee

Some tcp packets are dropped using socketfilter

I user socketfilter to intercept tcp packet,but I find that not all of the tcp packet can be intercepted.For examle,I open chrome browser and
browse video website,as a result I miss some packets for HTTP commucication. Thanks very much. My English is not good,I am sorry.
Waiting for your help.

Oh dear. That confirms my fear that somehow you have got output files into your source files, maybe you published to that folder.
Within a version of RH, you could correct that, albeit with quite a bit of work.
http://www.robowizard.com/RoboWizard/NewProject.htm#MonthlyScry/062004.htm
However, what you are trying to do is upgrade an output file and the process is not designed for that. You have to decide on the least work. Uninstall RH8 and install RH7, fix the problem and then upgrade or just get on with redoing those dropdowns in RH8.
See www.grainge.org for RoboHelp and Authoring tips

My MBP has started to send out TCP packets larger than the MTU on the NIC - is there any place that this can be overriden?

Got a very weird issue here and wondering if anyone has any other ideas. Basically over the wired NIC only, my Mac has started to send out large HTTP/HTTPS packets from the browser (> 1500 bytes) Captures show packet sizes from 2000 all the way to 4000 sometimes. This happens in Firefox and Chrome so doesn't appear to be application related.
This causes fragmentation issues and traffic drops which basically causes most of my websites and tools to crash and burn (and I get all sorts of SSL errors from applications, etc).
It appears to be limited to just TCP packets as pings with the DF bit set will not send any larger than 1500 bytes.
However if I switch to wireless, everything works fine and captures show the correct maximum packet size of 1500 for all packets leaving my client.
The MTU on the en0 interface is 1500 as per ifconfig and I made sure that it was set to 1500 in Network config panel (because there is an option for jumbo frames there which bumps up the MTU).
A packet capture also shows that during the three way handshake the TCP MSS is successfully sent and negotiated as 1480, but then it appears to ignore that when sending packets later in the TCP stream.
I've rebooted, upgraded to 10.7.4, checked the "sysctl" outputs and matched against a Mac not having the issue.
This is the newest MBP 15 inch model.
Any other ideas on things to check?

Have you used any sort of "tuner" software? You are obviously an advanced user. Sometimes we hack things up and forget about it later. If you are sure you didn't do that, maybe poke around with IPv6 settings. Supposedly people are trying to enable that and it is going to be a disaster.

Double TNS datagrams in one TCP packet

I have the following Problem:
During a database Connection over an IPSec - tunnel between a Fortigate and a Juniper firewall the connection stalls.
This is exactly reproducible with on select or bulk insert statement. Neither OCI or thin changes the behavior. Without the tunnel(f.e. LAN or ISDN connect)
there no problem an no duplicate TNS.
I have logged the TCP traffic with wireshark on both sides and noticed that I have two tns datagrams in one TCP packet.
I use different IPSec tunnels and haven only problems with this one. Do you have a hint whats going on?
BTW: I change sdu and tdu sizes. This changes the point in time of the stall (double tns).
Here is the Wireshark Log:
519     1128.135566     192.168.197.33     10.4.100.73     TNS     Request, Data (6), Data
520     1128.135912     192.168.197.33     10.4.100.73     TNS     Request, Data (6), Data
521     1128.179202     10.4.100.73     192.168.197.33     TCP     [TCP Window Update] ncube-lm > 64542 [ACK] Seq=7203 Ack=2341 Win=65535 Len=0
522     1128.202975     10.4.100.73     192.168.197.33     TCP     ncube-lm > 64542 [ACK] Seq=7203 Ack=3691 Win=64185 Len=0
523     1128.213284     10.4.100.73     192.168.197.33     TNS     Response, Marker (12), Attention
524     1128.213516     10.4.100.73     192.168.197.33     TNS     Response, Marker (12), Attention
525     1128.213557     192.168.197.33     10.4.100.73     TCP     64542 > ncube-lm [ACK] Seq=4265 Ack=7225 Win=64201 Len=0
526     1128.217649     192.168.197.33     10.4.100.73     TNS     Request, Marker (12), Attention
527     1128.255460     10.4.100.73     192.168.197.33     TCP     [TCP Dup ACK 524#1] ncube-lm > 64542 [ACK] Seq=7225 Ack=3691 Win=65535 Len=0
* 528     1128.501575     192.168.197.33     10.4.100.73     TNS     [TCP Retransmission] Request, Marker (12), Attention
529     1128.588704     10.4.100.73     192.168.197.33     TCP     ncube-lm > 64542 [ACK] Seq=7225 Ack=4276 Win=64950 Len=0
Here the connection stalls, but does not terminate. The data transmission is not finished.
The * packet has the following header information:
Frame 528: 639 bytes on wire (5112 bits), 639 bytes captured (5112 bits)
Ethernet II, Src: FujitsuT_92:f0:b5 (00:19:99:92:f0:b5), Dst: Fortinet_25:ea:de (00:09:0f:25:ea:de)
Internet Protocol, Src: 192.168.197.33 (192.168.197.33), Dst: 10.4.100.73 (10.4.100.73)
Transmission Control Protocol, Src Port: 64542 (64542), Dst Port: ncube-lm (1521), Seq: 3691, Ack: 7225, Len: 585
Transparent Network Substrate Protocol
Packet Length: 574
Packet Checksum: 0x0000
Packet Type: Data (6)
Reserved Byte: 00
Header Checksum: 0x0000
Data
Transparent Network Substrate Protocol
Packet Length: 11
Packet Checksum: 0x0000
Packet Type: Marker (12)
Reserved Byte: 00
Header Checksum: 0x0000
Attention
Marker Type: Data Marker - 1 Data Bytes (0x01)
Marker Data Byte: 0x00
Marker Data Byte: 0x02
Any idea?

Ben wrote:
Convert dbl to U64 then use swap words. Swap Words is polymorphic and will adapt the the data type you prest to it.
Ben
Convert is a bad idea here.you want to typecast instead.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Sending TCP packets to many IP addresses after downloading a program

I constantly monitor UDP and TCP packets sent to IP addresses on my Windows 7 computer. After downloading a free online program to convert media video files, I soon noticed my computer constantly and rapidly sending out packets to more
than 10 IP addresses (and quite a few were going to China, Russia and Germany). I tried a search on my hard drive for the file that contained those specific IP addresses and found nothing.
Note: For Viewing Folders, I do not hide operating system files, and I show hidden files, folders and drives.
Then I tried searching my windows registry (via REGEDIT) for those IP addresses and found nothing.
I assumed these IP addresses may have been hidden and included in a .dll file. I could not find an answer on the internet to determine where these hacking IP addresses originated from, so I deleted the program and rebooted.
The problem still existed, so I had to restore to a previous backup date. The restore fixed the problem. I am so confused. If I wasn't monitoring my connections I would never have known about this hacking flaw in Windows 7 security. I
still don't know what type of file(s) were causing this problem. Or what causes my computer to send unsolicited packets to so many IP addresses (to domestic, foreign and hostile locations).

Message to members... DO NOT download the software in this area.
Contains malicious code.
Thank you FangZhou Chen for your response. I am not exactly sure which of these two programs (listed below) was the culprit for this problem, but I do know that both programs have issues with malicious code. Understand I have used both of these programs
in the past, but stopped using them because of these issues. The Freeware #1 was my favorite and was user friendly, until the malicious code was added, and may be the real culprit.
Malicious Freeware #1: Any Video Converter (program name: avc-free.exe)
This program contains PUP.Optional.OpenCandy - While PUP.Optional.OpenCandy is not technically a virus, this PUP can be extremely annoying and quite difficult to get rid of. It comes loaded with adware, which as anyone who has been infected by adware can tell
you, can drive you to the brink of insanity with its relentless adverts, plus it will very likely hijack your browser and install a strange and unwanted toolbar on your machine too. Not only do unwanted toolbars get in the way but they can direct you to websites
that the creators want you to visit and can in general make using your computer a real user-unfriendly experience. PUP.Optional.OpenCandy is also a form of spyware which enables it to be installed deep within your PC’s operating system so that it is harder
for you to find – and therefore delete.
Link to site:              any-video-converter.com/products/for_video_free/
Link to download program: any-video-converter.com/download-avc-free.php
Malicious Freeware #2: SUPER © Media Converter Encoder
This program is bundled with other software. I don't remember the malicious type or effects.
Link to site:             erightsoft.com/SUPER.html
Link to download program: erightsoft.info/GetFile3.php?SUPERsetup.exe
Hope this helps. Again thanks! God Bless.
P.S. - Excellent tools in cleaning up maleware have been to use Malwarebytes, AdwCleaner and  HitmanPro (both recommended by the malwarebytes.org website).

Cisco 3750 --- Mark TCP packets from port 80 with DSCP ef

Good afternoon,
I am trying to mark outgoing traffic from a web server with value of DSCP ef
When I am doing a traffic capture all TCP packets have tos 0x0
If I marked UDP packets, or icmp packets, I can see it with in trafic capture, but not TCP traffic.
This is my config,
mls qos
ip access-list extended MARK-HTTP-ACL
permit tcp host 10.10.10.10 eq www any
class-map match-any HTTP-CM
match access-group name MARK-HTTP-ACL
policy-map PRIORITY-PM
class HTTP-CM
set dscp ef
interface GigabitEthernet1/0/11
switchport access vlan 20
switchport mode access
spanning-tree portfast
mls qos trust dscp
service-policy input PRIORITY-PM
Can anybody can help me to understand, why I cannot mark TCP packets?
Thank you

Yes. You need to eliminate the things I've said to eliminate with the other side. Ensure your configs are matching exactly. They probably are, whatever, just make sure of it because it's easy. You both need to run packet captures on your interfaces both in and out to even begin to have an idea of where to look.
The more info you can have just one person responsible for the better. What I mean by that is, it's typically a nice step for the 'bigger end' to have the 'smaller end's' config file to look at.
If you are seeing packets come in your inside, leave your outside, and never make it to his inside, then take it a step at a time.
If you're seeing them come in his interface and never come back out, you know where to look.
Set your caps to a single host to single host if need be, and generate traffic accordingly.
You need to narrow down where NOT to look so that you know where TO look. I would say then, and only then, do you get the ISP involved. Once you're sure the problem exists between his edge device and your edge device.
I do exactly this for a living on a daily basis...day after day after day. I'm responsible for over 200 IPSec s2s connections and thousands of SSL VPN sessions. I always start the exact same way...from the very bottom.

How to watch packets in a TCP/IP stream

hi
can anyone tell me how to watch packets in a TCP/IP stream using jpcap??

You could read the JPCAP documentation... it surely has one.

Java.io.IOException: Transport scheme NOT recognized: [tcp]

Hi everyone, I developed a Java class that allow me to connect, create, send and receive information to an ActiveMQ queues.
However when I loaded this java class to Oracle 11gR2 (11.2), the java class did not show any error message (its status is active and without errors. The output I got in SqlDeveloper is
*java.io.IOException: Transport scheme NOT recognized: [tcp].* When I called this Java Class from Jdeveloper 11g It worked but PL/SQL did not.
This is the Java Class I have been using
import javax.jms.JMSException;
import javax.jms.*;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import org.apache.activemq.ActiveMQConnectionFactory;
public class ActiveMQRequest {
// URL of the JMS server. DEFAULT_BROKER_URL will just mean
// that JMS server is on localhost
// Name of the queue we will be sending messages to
// private static String destMameReq = "QueueIN"; // request
// private static String destNameResp = "QueueOUT"; // response
public static String Request(String urlMQ,
String destNameReq,
String destNameResp,
String OperationType,
String XMLmessage) throws JMSException {
int JMSDeliveryMode=2 ; //for PERSISTENT
QueueConnectionFactory connectionFactory =null;
Context jndiContext =null;
Queue destRequ =null;
Queue destResp =null;
QueueSession session =null;
QueueConnection connection =null;
String messageID = null;
QueueReceiver queueReceiver =null;
QueueSender queueSender =null;
String replyString =null;
boolean transacted = false;
TextMessage outMessage = null;
try {
jndiContext = new InitialContext();
} catch (NamingException e) {
//System.out.println("Could not create JNDI API context: " + e.toString());
//System.exit(1);
return "Error: Initial Context Failed";
try {
connectionFactory = new ActiveMQConnectionFactory(urlMQ);
//connectionFactory = (QueueConnectionFactory) jndiContext.lookup("connectionFactory");
//destRequ = (Queue) jndiContext.lookup(destNameReq); // Request queue
// destResp = (Queue) jndiContext.lookup(destNameResp); // Response queue
} catch (Exception e) {
//System.out.println("JNDI API lookup failed: " + e.toString());
//System.exit(1);
return "Error: MqConnection Factory failed: " + e.toString();
// begin
try {
connection = connectionFactory.createQueueConnection();
connection.start();
} catch (JMSException jmse) {
//System.out.println("Error:JMS Exception occurred: " + jmse.toString());
return "Error:JMS Exception occurred Create Queue Connection: " + jmse.toString();
} catch (Exception e) {
//System.out.println("JNDI API lookup failed: " + e.toString());
//e.printStackTrace();
return "Error:JNDI API lookup failed Create Queue Connectio: " + e.toString();
try {
session = connection.createQueueSession( transacted,Session.AUTO_ACKNOWLEDGE);
// check this instead of using JNDI
destRequ = session.createQueue(destNameReq);
destResp = session.createQueue(destNameResp);
} catch (JMSException jmse) {
//System.out.println("Error:JMS Exception occurred: " + jmse.toString());
return "Error:JMS Exception occurred createQueueSession: " + jmse.toString();
} catch (Exception e) {
//System.out.println("JNDI API lookup failed: " + e.toString());
//e.printStackTrace();
return "Error:JNDI API lookup failed createQueueSession: " + e.toString();
try {
queueSender = session.createSender(destRequ);
outMessage = session.createTextMessage(XMLmessage);
// Sets other properties of the message
outMessage.setJMSPriority(7);
outMessage.setJMSReplyTo(destResp);
outMessage.setJMSDeliveryMode(JMSDeliveryMode);
//outMessage.setJMSType("Interval"); Interval
outMessage.setJMSType(OperationType); // ODR , Interval, Ping
System.out.println("Sending message.: " + outMessage.getText());
} catch (JMSException jmse) {
//System.out.println("Error:JMS Exception occurred: " + jmse.toString());
return "Error:JMS Exception occurred createSender: " + jmse.toString();
} catch (Exception e) {
//System.out.println("JNDI API lookup failed: " + e.toString());
//e.printStackTrace();
return "Error:JNDI API lookup failed: createSender " + e.toString();
// Here we are sending the message!
try {
queueSender.send(outMessage);
System.out.println("Message Sent....: " + outMessage.getText() + "'");
// Receiving
messageID = outMessage.getJMSMessageID();
String selector = "JMSCorrelationID = '"+messageID+"'";
System.out.println("JMSCorrelationID = '"+messageID+"'");
queueReceiver = session.createReceiver(destResp, selector);
System.out.println("Receiving Message.");
Message inMessage = queueReceiver.receive(2000);
if ( inMessage instanceof TextMessage ) {
replyString = ((TextMessage) inMessage).getText();
System.out.println("Message Received: " + replyString + "'");
else
replyString = "Error: TextMessage is empty";
} catch (JMSException jmse) {
//System.out.println("Error:JMS Exception occurred: " + jmse.toString());
return "Error:JMS Exception occurred Receiving: " + jmse.toString();
} catch (Exception e) {
//System.out.println("JNDI API lookup failed: " + e.toString());
//e.printStackTrace();
return "Error:JNDI API lookup failed Receiving: " + e.toString();
} finally {
queueReceiver.close();
queueSender.close();
session.close();
connection.close();
return replyString;
This is th pl/sql wrapper
create or replace
function ActiveMQRequest( url in varchar2,
destNameReq in varchar2,
destNameResp in varchar2,
OperationType in varchar2,
XMLmessage in varchar2) return varchar2
as language java
name 'ActiveMQRequest.Request( java.lang.String,java.lang.String, java.lang.String , java.lang.String , java.lang.String ) return java.lang.String';
and this is the JDeveloper Output
Sending message.:
<Message>
<Header>
<SourceID >sourceid</SourceID>
<TransactionID>11111111111</TransactionID><MeterID>AAAAAAA</MeterID><REPID>41679178</REPID><TransactionDate>2010-10-08T02:00:00</TransactionDate><UserID>Sensus</UserID><CustomerID>Customer</CustomerID></Header><Body><StarDate>2010-10-01T14:00:00</StartDate><EndDate>2010-10-06T14:00:00</EndDate><IntervalFlag>Y</IntervalFlag><MeterFlag>Y</MeterFlag></Body>
JMSCorrelationID = 'ID:W05834007-3793-1286901259437-0:0:1:1:1'
Receiving Message.
Message Received: <Message>
<Header>
<TransactionID>11111111111</TransactionID>
<SourceID>sourceid</SourceID>
</Header>
<Body>
<TransactionStatus>Acknowledge</TransactionStatus>
<TransactionMessage>Interval Flag null is not Y or N</TransactionMessage>
</Body>
</Message>'
Result is :<Message>
<Header>
<TransactionID>4444444444444444</TransactionID>
<SourceID>RNI</SourceID>
</Header>
<Body>
<TransactionStatus>Acknowledge</TransactionStatus>
<TransactionMessage>Interval Flag null is not Y or N</TransactionMessage>
</Body>
</Message>
When I run in Oracle Sqldeveloper the output was
Error:JMS Exception occurred Create Queue Connection: javax.jms.JMSException: Could not create Transport. Reason: java.io.IOException: Transport scheme NOT recognized: [tcp]
Do you know what do I do in the Oracle 11gR2 configuration for making this work. I would appreciate your help.
Thanks

Perhaps you did not notice that you posted to a forum named "Database - General" with a question that is neither general nor related to the Oracle Database.
Please update this thread (use Edit) and change the subject to "Please Ignore."
Then repost your question in a Java related forum.
Thank you.
~ Posted from PEOUG: Lima Peru

Error type: COMPONENT_ERROR Could not start TCP connection listener

Hi All,
I am working with EDI to SAP R/3 scenario with Seeburger. In this i am using EDI message ORDERS V9A .
i have configured OFTP adapter for this.
when i enter into the Runtimeworkbench i have seen adapter monitoring. in this i got one error mentioned below.
Please give me solution for this error
Processing Details for Cluster Node Server 0 1_39044
Type
Time Stamp
Message ID
Explanation
03/04/08 14:22:12
Error type: COMPONENT_ERROR >> Error date: 03/04/08 14:22 >> Description: Error occurred while trying to start connection listeners. Could not start TCP connection listener [[TCP listener Channel: CC_SOURCE_EDI;Party: GXSMAILBOX;Service: GXSMAILBOX (ID: ): 198.133.252.208:11551]]. Reason: Could not start connection listener [03/04/08 14:22]
Thanks and regards
sai

Hi,
The date format which can seen in error in not suppoted in SAP ECC system.......it will take yyyymmdd as the date format......change the date format in XI.......in mapping we can use standard funtion fro date transformation.
Regards,
Phani

IS IT POSSIBLE TO SEND TCP PACKET WITH THE SOCKET?

Hello everybody iam programing HIJACK attack with jbuilder8 that consiste to detecte a communication between the client and server (tcp session or tcp connexion) and read all informations from this tcp packet(like N�ACK,N� SEQ..) and finnaly send a tcp packet with false information. I have make this project with C under linux(red hat9) compiled with GCC and i have used raw socket like this:
int creat_socket(char *interface)
int fd;
struct ifreq ifr;
struct sockaddr_ll sll;
if ((fd=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)))==-1)//creat socket {
     perror("socket");
     return -1;
memset(&ifr, 0, sizeof(struct ifreq));//remplir ifr par des '0'
strcpy(ifr.ifr_name, interface);//copier le nom de l'interface ds ifr_name
if (ioctl(fd, SIOCGIFINDEX, &ifr)==-1)//Retrouve le num�ro d'interface et le place dans ifr_ifindex.
     perror("ioctl");
     return -1;
memset(&sll, 0, sizeof(struct sockaddr_ll));//remplir sll par des '0'
sll.sll_family=PF_PACKET;
sll.sll_ifindex=ifr.ifr_ifindex;
sll.sll_protocol=htons(ETH_P_ALL);
if (bind(fd, (struct sockaddr *)&sll, sizeof(struct sockaddr_ll))==-1)//lie le socket a l'interface
     perror("bind");
     return -1;
if (ioctl(fd, SIOCGIFFLAGS, &ifr)==-1)//Lire les attributs actifs du p�riph�rique
     perror("ioctl");
     return -1;
ifr.ifr_flags|=IFF_PROMISC;//Interface en mode promiscuous
if (ioctl(fd, SIOCSIFFLAGS, &ifr)==-1)////ecrire les attributs actifs du p�riph�rique
     perror("ioctl");
     return -1;
return fd;
PROBLEM : I want to know if it�s possible to make that in java because i had search and i have found just the client and server socket but i want a socket to send tcp Packet? Thank you.

hello i had found the ROCKSAW (http://www.savarese.org/software/rocksaw.html ) and i had used in my program, but when the program arrived in:
socket_send=new RawSocket();
i had this error:
java.lang.UnsupportedClassVersionError: org/savarese/rocksaw/net/RawSocket (Unsupported major.minor version 49.0)
     at java.lang.ClassLoader.defineClass0(Native Method)
     at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
     at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
     at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
     at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
     at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
     at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
     at hijack.M_HIJACK.tcpsend(M_HIJACK.java:345)
     at hijack.M_HIJACK.injection_actionPerformed(M_HIJACK.java:611)
     at hijack.M_HIJACK_injection_actionAdapter.actionPerformed(M_HIJACK.java:861)
     at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764)
     at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817)
     at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419)
     at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257)
     at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245)
     at java.awt.Component.processMouseEvent(Component.java:5093)
     at java.awt.Component.processEvent(Component.java:4890)
     at java.awt.Container.processEvent(Container.java:1566)
     at java.awt.Component.dispatchEventImpl(Component.java:3598)
     at java.awt.Container.dispatchEventImpl(Container.java:1623)
     at java.awt.Component.dispatchEvent(Component.java:3439)
     at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450)
     at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165)
     at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095)
     at java.awt.Container.dispatchEventImpl(Container.java:1609)
     at java.awt.Component.dispatchEvent(Component.java:3439)
     at java.awt.EventQueue.dispatchEvent(EventQueue.java:450)
     at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
     at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)
i think that is a problem with a version of JDK (i have jdk1.4) so if you have an idea please help me

100083/rpc/tcp still active and was not reconfigur

Hi,
When I restarted my Inetd daemon , it logs the following line to /var/adm/messages/
May 2 15:31:40 MyMachine inetd[121]: config: 100083/rpc/tcp still active and was not reconfigured.
Can anyone explain me what does it mean?
( the /etc/inetd.conf contains this entry :
100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd /usr/dt/bin/rpc.ttdbserverd )
Thanks

Well the message means that someone else is using this port/service.
Sometimes people who have wrappers built around a particular service
see that if they have already have an instance of the service running and
they try to stop/start the inetd daemon.

Asp drop - First TCP packet not SYN (tcp-not-syn)

Similar Messages

Maybe you are looking for