Windows TCP/IP stack and packet bursts

Hi all!
I'm trying to make a server that sends ~30 packets (tcp/ip) loaded with a little data (a long). (Streaming with dataOutputStream.writeLong())
I would really like to get those 30 Hz signals updating on the clients in a smooth fashion.
On linux/mac (on those I have tested), I receive the packets one by one. But, in Windows, I receive them as bursts 5/pause/5/pause... and so on. This is really annoying. Anyone knows what the problem might be? I suspect some tcp/ip stack in windows...
I have heard ppl streaming with 100Hz, so this might not be a problem? Or should I use UDP datagram packets instead?
Thank you!

First, there is no 'problem', as none of the RFCs guarantees the kind of behaviour that you want, so you may be better off reviewing your requirement for feasibility rather than chasing some non-existent 'problem'.
Having said that, there are all kinds of TCP/IP parameters you can tune via the Windows registry:
http://technet2.microsoft.com/WindowsServer/en/Library/823ca085-8b46-4870-a83e-8032637a87c81033.mspx

Similar Messages

Tcp/ip stacks

I have been trying to set up my wireless network for a couple of days now. My router is a WRT54GS and the problem I am having is on my desktop with the wireless adapter. I can connect to the network and can ping the router with no problem. It is when I try to connect to the internet I keep getting the cannot find page error. Tech support says I need to check my tcp/ip stacks and my DNS address. Does anyone know how to refresh the tcp/ip stacks on Windows ME and how to resolve the DNS issue.
Thanks Jabe

pls visit this one... this will tell you how to refresh your TCP/IP stacking
http://support.microsoft.com/kb/299357
"a helping hand in a community makes the world a universe"

IPS Tech Tip - Evasions - TCP/IP examples and handling - Sig team presentation

Hi Customers,
Its summer time and nothing evokes cool quite like a discussion into the TCP / IP stack and how creative attacker types try to hide attacks behind it. This presentation will feature a security researcher from our signature team and will be the first of several presentations on evastions and how the Cisco IPS handle them.
We hope that you can make it.
Thanks,
-Robert
Robert Albach invites you to attend a 30-45 minute Web seminar on the Cisco IPS internal operations using WebEx. This event requires registration.
Topic: Cisco IPS Tech Tips - Handling Evasions
Host: Robert Albach
Date and Time:
August 25, 2011 9:30 am, Central Daylight Time (Chicago, GMT-05:00)
To register for the online event
1. Go to https://ciscosales.webex.com/ciscosales/onstage/g.php?d=201261254&t=a&EA=ralbach%40cisco.com&ET=64ed8e6d81005252203f6671cfeee480&ETR=fb46b8799a6afe989e9a744f0fac0d77&RT=MiM3&p
2. Click "Register".
3. On the registration form, enter your information and then click "Submit".
Once the host approves your registration, you will receive a confirmation email message with instructions on how to join the event.

Sadly we did not get the recording done. The presentation and the example pcaps however are on this forum now.
-Robert

Issue Exporting TCP IP stack information to CSV file

I'm having difficulties reporting IP information (IPAddress, Default Gateway,
and DNSSearchOrder) in TCP IP stack and exporting it to CSV file. But if I remove the export-CSV statement everything appears fiine on the screen. for privacy reasons I've removed columns after DNS Search Order. note my examples below:
Get-WMIObject -Class Win32_NetworkAdapterConfiguration -ComputerName (Get-Content .\Servers.txt) -Credential DOMAIN\USERADDCOUNT |
Where-Object -FilterScript {$_.IPEnabled} |
    Select-Object DNSHostName, IPAddress, DefaultIPGateway, DNSServerSearchOrder, WINSPrimaryServer, WINSSecondaryServer,
@ {Label="ADSDomainName";Expression={(Get-WMIObject -Class Win32_ComputerSystem -ComputerName $_.__Server).Domain}} |
     Export-csv PowerShell-ServerProfileIPInformation.csv -NoTypeInformation
DNSHostName    IPAddress       DefaultIPGateway DNSServerSearchOrder
SERVER1100496 System.String[] System.String[]    System.String[]
SERVER1100497 System.String[] System.String[]    System.String[]
SERVER1100169 System.String[] System.String[]    System.String[]
SERVER1100496 System.String[] System.String[]    System.String[]
SERVER1100497 System.String[] System.String[]    System.String[]
SERVER1100169 System.String[] System.String[]    System.String[]
SERVER1100496 System.String[] System.String[]    System.String[]
SERVER1100497 System.String[] System.String[]    System.String[]
SERVER1100169 System.String[] System.String[]    System.String[]

Hi,
This is happening because you are trying to export a array. Simple way to get rid of this is, convert the array into comma separated values and then export it.I slightly modified your code as below.
$IPs = Get-WMIObject -Class Win32_NetworkAdapterConfiguration -ComputerName (Get-Content .\Servers.txt) -Credential DOMAIN\USERADDCOUNT | ? {$_.IPEnabled }
$Outarray = @()
foreach($IP in $IPs) {
$OutputObj = New-Object -TypeName PSobject
$OutputObj | Add-Member -MemberType NoteProperty -Name ComputerName -Value $IP.DNSHostName
$OutputObj | Add-Member -MemberType NoteProperty -Name IPAddress -Value $IP.IPAddress -join ","
$OutputObj | Add-Member -MemberType NoteProperty -Name DefaultIPGateway -Value $IP.DefaultIPGateway -join ","
$Outarray += $OutputObj
$OutArray | export-csv c:\temp\IPdetails.csv -NoTypeInformation
If you want to understand more on how to export such kind of data to csv/excel, refer to this(http://learn-powershell.net/2014/01/24/avoiding-system-object-or-similar-output-when-using-export-csv/) article written by Boe Prox. It is really worth reading.
If you are looking for complete script that can export Ip config details of remote computers into CSV, try the script mentioned at
http://techibee.com/powershell/powershell-get-ip-address-subnet-gateway-dns-serves-and-mac-address-details-of-remote-computer/1367
Hope this helps.
Thanks,
Sitaram Pamarthi
Blog : http://techibee.com
Follow on Twitter
This posting is provided AS IS with no warranties or gurentees,and confers no rights

Windows 7 - TCP Parameter TcpMaxConnectRetransmissions and TcpInitialRTT

(this is a dummy post, for an issue which has been resolved under the partner area after i raised a break fix ticket with Microsoft, but not available to the wider audience)
We have a redundant NIC situation where we want the swap on failure to be fast, i.e. we want the default TcpMaxConnectRetransmissions to be 0 or 1, not 2. The resulting default no connection time is 21s
Research has shown posts like
http://go4answers.webhost4life.com/Example/window-registy-14268.aspx which implies this has been dropped in Windows 7 and you can no longer control a range of settings. Also see
http://blogs.technet.com/b/netro/archive/2010/08/30/tcp-ip-stack-hardening-in-operating-systems-starting-with-windows-vista.aspx
There is also TcpInitialRTT but neither work. However their is a KB
http://support.microsoft.com/kb/170359 which imply they should work. Someone is tell porkies ?
>> Is this true, we can't adjust the timeout for a connection in Windows 7, or is there still a backdoor to this functionality ?
Thanks

Hi,
I’m glad to hear your issue has been resolved. Hope your experience will help other community members facing similar problems.
Regards,
Leo
Huang
TechNet Subscriber Support
If you are
TechNet Subscription user and have any feedback on our support quality, please send your feedback
here.
Leo Huang
TechNet Community Support

Improve Auto-Stack and Process Collections with user settings

I have read through all of the Bridge request discussions, and encountered a few comments on the stacking process but nothing to explain my critique and feature request. My apologies for any redundancy.
Bridge CS4 includes two features that would (virtually) streamline my entire photo-organization workflow. Brilliant! Except that they offer zero configuration and my default scenario is very different from Adobe's, so these two would-be-wonderful features are pretty much useless to me, and to anybody else who doesn't happen to shoot in the way the presets are configured.
The first feature is to automatically group images into stacks, based on their similarity, exposure settings, and timestamps. Unfortunately Bridge considers no minimum or maximum amount of photos per stack, and has a fixed timestamp window of 18 seconds. I shoot everything in three-exposure bursts and sometimes multiple shots in less than 18 seconds, so being able to say "process collections in 3-item stacks only" would be absolutely perfect. For other people, being able to limit the timestamp range or other min/max exposure options would work great.
The second feature, which could save me hours every week but is equally useless, is to automatically process collections in Photoshop. My biggest ire about this function is that it completely ignores stacks that I have manually created AND stacks that were previously created using the auto-stack feature. Every time this function is run, it re-runs the auto-stack process from scratch and then delivers the collections to Photoshop. Not only is this made useless by the previously mentioned inflexibility of the auto-stack process, but even if auto-stack worked perfectly, this would waste time by doing the entire thing again and denying the user the option to review the stacks before committing to the Photoshop processing. The process collections feature would also be much improved if the option were given to process ONLY panoramas or HDR photos, or auto-detect. I have never shot a panorama in my life and I'm sure plenty of people have never shot HDR, but Photoshop isn't capable of knowing our intentions and there's no reason why we shouldn't be able to instruct it.

Agree. It is an interesting capability that falls short of being really useful. I feel like an ingrate to complain, but ...
I'd also like to see the capability to specify something than "Auto" for the panorama option. My experience is that most of my panos work best with "Cylindrical + Geometric Correction".
My experience is that once you get past 5+ images in a pano, it becomes very tedious ... and then 20+ images in rows is painful. Unlike a single image that you can quickly evaluate, with panos I find I need to make the pano to tell if it going to turn out. I have been generating smaller 1800x1200 or 1200x1800 files to speed up the evaluation process, but it is still very manual and tedious.
The Auto-Stack generates a AutoCollectionCache.xml, but I haven't found it workable to edit this. I'd like to be able to modify it to "force" my knowledge of what is in a group. It seems to check the time-stamp, and re-do the Auto-Stack, thus ignoring my changes. Sigh.

Windows TCP Socket Buffer Hitting Plateau Too Early

Note: This is a repost of a ServerFault Question edited over the course of a few days, originally here: http://serverfault.com/questions/608060/windows-tcp-window-scaling-hitting-plateau-too-early
Scenario: We have a number of Windows clients regularly uploading large files (FTP/SVN/HTTP PUT/SCP) to Linux servers that are ~100-160ms away. We have 1Gbit/s synchronous bandwidth at the office and the servers are either AWS instances or physically hosted
in US DCs.
The initial report was that uploads to a new server instance were much slower than they could be. This bore out in testing and from multiple locations; clients were seeing stable 2-5Mbit/s to the host from their Windows systems.
I broke out iperf
-s on a an AWS instance and then from a Windows client in the office:
iperf
-c 1.2.3.4
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[ 5] 0.0-10.0 sec 6.55 MBytes 5.48 Mbits/sec
iperf
-w1M -c 1.2.3.4
[ 4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[ 4] 0.0-18.3 sec 196 MBytes 89.6 Mbits/sec
The latter figure can vary significantly on subsequent tests, (Vagaries of AWS) but is usually between 70 and 130Mbit/s which is more than enough for our needs. Wiresharking the session, I can see:
iperf
-c Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (*512)
iperf
-c -w1M Windows SYN - Windows 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9
Clearly the link can sustain this high throughput, but I have to explicity set the window size to make any use of it, which most real world applications won't let me do. The TCP handshakes use the same starting points in each case, but the forced one scales
Conversely, from a Linux client on the same network a straight, iperf
-c (using the system default 85kb) gives me:
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[ 5] 0.0-10.8 sec 142 MBytes 110 Mbits/sec
Without any forcing, it scales as expected. This can't be something in the intervening hops or our local switches/routers and seems to affect Windows 7 and 8 clients alike. I've read lots of guides on auto-tuning, but these are typically about disabling scaling
altogether to work around bad terrible home networking kit.
Can anyone tell me what's happening here and give me a way of fixing it? (Preferably something I can stick in to the registry via GPO.)
Notes
The AWS Linux instance in question has the following kernel settings applied in sysctl.conf:
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216
I've used dd
if=/dev/zero | nc redirecting to /dev/null at
the server end to rule out iperfand
remove any other possible bottlenecks, but the results are much the same. Tests with ncftp(Cygwin,
Native Windows, Linux) scale in much the same way as the above iperf tests on their respective platforms.
First fix attempts.
Enabling CTCP - This makes no difference; window scaling is identical. (If I understand this correctly, this setting increases the rate at which the congestion window is enlarged rather than the maximum size it can reach)
Enabling TCP timestamps. - No change here either.
Nagle's algorithm - That makes sense and at least it means I can probably ignore that particular blips in the graph as any indication of the problem.
pcap files: Zip file available here: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Anonymised
with bittwiste, extracts to ~150MB as there's one from each OS client for comparison)
Second fix attempts.
I've enabled ctcp and disabled chimney offloading: TCP Global Parameters
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : enabled
Initial RTO : 3000
Non Sack Rtt Resiliency : disabled
But sadly, no change in the throughput.
I do have a cause/effect question here, though: The graphs are of the RWIN value set in the server's ACKs to the client. With Windows clients, am I right in thinking that Linux isn't scaling this value beyond that low point because the client's limited CWIN
prevents even that buffer from being filled? Could there be some other reason that Linux is artificially limiting the RWIN?
Note: I've tried turning on ECN for the hell of it; but no change, there.
Third fix attempts.
No change following disabling heuristics and RWIN autotuning. Have updated the Intel network drivers to the latest (12.10.28.0) with software that exposes functioanlity tweaks viadevice manager tabs. The card is an 82579V Chipset on-board NIC - (I'm going to
do some more testing from clients with realtek or other vendors)
Focusing on the NIC for a moment, I've tried the following (Mostly just ruling out unlikely culprits):
Increase receive buffers to 2k from 256 and transmit buffers to 2k from 512 (Both now at maximum) - No change
Disabled all IP/TCP/UDP checksum offloading. - No change.
Disabled Large Send Offload - Nada.
Turned off IPv6, QoS scheduling - Nowt.
Further investigation
Trying to eliminate the Linux server side, I started up a Server 2012R2 instance and repeated the tests using iperf (cygwin
binary) and NTttcp.
With iperf,
I had to explicitly specify -w1m on both sides
before the connection would scale beyond ~5Mbit/s. (Incidentally, I could be checked and the BDP of ~5Mbits at 91ms latency is almost precisely 64kb. Spot the limit...)
The ntttcp binaries showed now such limitation. Using ntttcpr
-m 1,0,1.2.3.5 on the server and ntttcp
-s -m 1,0,1.2.3.5 -t 10 on the client, I can see much better throughput:
Copyright Version 5.28
Network activity progressing...
Thread Time(s) Throughput(KB/s) Avg B / Compl
====== ======= ================ =============
0 9.990 8155.355 65536.000
##### Totals: #####
Bytes(MEG) realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
79.562500 10.001 1442.556 7.955
Throughput(Buffers/s) Cycles/Byte Buffers
===================== =========== =============
127.287 308.256 1273.000
DPCs(count/s) Pkts(num/DPC) Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
1868.713 0.785 9336.366 0.157
Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
57833 14664 0 0 9.476
8MB/s puts it up at the levels I was getting with explicitly large windows in iperf.
Oddly, though, 80MB in 1273 buffers = a 64kB buffer again. A further wireshark shows a good, variable RWIN coming back from the server (Scale factor 256) that the client seems to fulfil; so perhaps ntttcp is misreporting the send window.
Further PCAP files have been provided, here:https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip
Two more iperfs,
both from Windows to the same Linux server as before (1.2.3.4): One with a 128k Socket size and default 64k window (restricts to ~5Mbit/s again) and one with a 1MB send window and default 8kb socket size. (scales higher)
One ntttcp trace
from the same Windows client to a Server 2012R2 EC2 instance (1.2.3.5). here, the throughput scales well. Note: NTttcp does something odd on port 6001 before it opens the test connection. Not sure what's happening there.
One FTP data trace, uploading 20MB of /dev/urandom to
a near identical linux host (1.2.3.6) using Cygwin ncftp.
Again the limit is there. The pattern is much the same using Windows Filezilla.
Changing the iperf buffer
length does make the expected difference to the time sequence graph (much more vertical sections), but the actual throughput is unchanged.
So we have a final question through all of this: Where is this limitation creeping in? If we simply have user-space software not written to take advantage of Long Fat Networks, can anything be done in the OS to improve the situation?

Hi,
Thanks for posting in Microsoft TechNet forums.
I will try to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.
Kate Li
TechNet Community Support

How to reconfigure the tcp/ip stack in Solar8 to include my STREAMS module?

I am currently writing a NAT STREAMS module that I would like to place on the tcp/ip stack so it intercepts all incoming and outgoing packets going to or coming from the IP module. I want the stack to look like the following:
Current Solaris Stack: hme0 -> ip -> tcp
The new stack I want: hme0 -> MY_NAT -> ip -> tcp
I would appreciate any help to my problem. Also, if anyone knows a resource where I could find any more information like this please let me know. I've look at docs.sun.com and searched the web but I still haven't found the answer.
Thanks,
Ben

Check out the Solaris 8 (or 9) STREAMS programming manual on docs.sun.com.
It covers in detail how from userspace or from kernelspace linking a STREAMS module into the chain of modules. I think the example it gives is with terminal drivers, but same idea.

Server 2008 (R2) TCP/IP Stack sending RST to close short lived sessions

Hi,
I'm having an issue with some vendor software, but it appears to be more closely related to the way the TCP/IP stack is handling session shutdown. I'd like to know what this feature is called, any available documentation, and ideally how to disable it.
Basically, what appears to happen, is Server 2008 is sending a Rst, Ack to terminate a short lived connection, instead of entering the standard TCP shutdown (Using FIN flags). This appears to be an attempt to avoid having short lived sessions sit in a
TIME_WAIT state, as I can see long TCP connections properly being shutdown.
I realize the benefits of what this is trying to accomplish, however, the software in question is making HTTP calls, and the server being rather basic, is sending HTTP responses without content-length or transfer encoding: chunked, which means the only
way to tell the server is done sending content is for the connection to close. However, it appears that the stack is interpreting this type of Tcp shutdown as in error, and generating annoying alerts within the application that is monitoring the close state.
Does windows have a way to disable this stack feature. I've confirmed the chimney offload doesn't appear to be in use, so this is an effect of the Windows stack itself. I don't have control of the software on either end, but do have a bug open with the vendor,
I'm more interested in a possible workaround for the short term.
** Entire connection lasts ~1 second
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 0, Len: 0
Flags: 0x02 (SYN)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 0, Ack: 1, Len: 0
Flags: 0x12 (SYN, ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 1, Ack: 1, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 1, Ack: 2921, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 2921, Ack: 1, Len: 1234
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 1, Ack: 4155, Len: 57
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 58, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 58, Ack: 4155, Len: 1024
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 1082, Ack: 4155, Len: 1460
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 2542, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 2542, Ack: 4155, Len: 1460
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 4002, Ack: 4155, Len: 1460
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 5462, Ack: 4155, Len: 1460
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 6922, Ack: 4155, Len: 1081
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 8003, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 8003, Ack: 4155, Len: 1460
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 9463, Ack: 4155, Len: 108
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 9571, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 9571, Ack: 4155, Len: 0
Flags: 0x14 (RST, ACK)

Rick, this did not help as it's the approach i've already taken in testing. Albeit, I did disable the chimney offload on the NIC drivers instead of the windows options, but in the wireshark captures I'm still seeing the same behavior.
Humand, I don't think you're issue is the same as mine, I beleive these RST, ACK's are in response to a NORMAL connection shutdown, and being interpretted as errors be the partner stack. I haven't seen this cause premature tcp shutdown, which would be you're
dropped RDP connections.
TCP Global Parameters
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disabled

TCP out of order packets

Hi,
We are getting TCP out of error packets while sending requests to outside. Though we can access the internet and also connectivity is fine. But some of the application is not working due to this error, specially TCP based application as on the remote side they are not accepting two requests from our network. That means two requests are going from our network with each of the request sent to outside network.
We have 4-5 vlans and intervlan routing is configured. Could somebody pls. let me know the reason of this and how can I solve this problem?
Thanks,
Pawan

Good mornning.
We have many application similar to the case you have explained.
Our links use satelite connection and the delayare between: 600 msec to 1000 msec.
Delays over 1000 msec generates delay and connectivitiy problems with tcp applications.
What is the delay between your endpoints ?
Do you have access to internet router ? so can you tell us if there are packets drops in the interfaces ?
Waiting your answer.

Error Stack and Error DTP-Doubts.

Hi Experts,
I have a doubt on Error Stacks and Error DTP's in BI 7.0.
For example i am doing a load that has 100 records and 10 of these records have some invalid characters and hence are showing up in the Error Stack.Now I know that i can change these records directly in the Error Stack and then use the Error DTP to process these 10 records.
But for the remaining 90 records the Error Handling in the Update tab is set to "No Update,No reporting" and hence the original request is red.How do I update these remaining 90 records?Is the only way to set Error Handling to "Valid Records Update,Reporting Possible(Request Green)" so that these error free 90 records are loaded and available for reporting?
Also what is the advantage of using of the Icon "Manually Post-Process Error Records" that exists in the DTP Monitor window against using Error DTP's?
Thanks
Aravind

Hi...
If it failed due to issues like Invalid char or error records, you may have the error data alone loaded to Error stack which you can edit and reload using an error DTP.
Else in case if your entire DTP failed, then you need to retrigger the DTP.
Handling of Data Records with Errors
http://help.sap.com/saphelp_nw70/helpdata/EN/42/fbd598481e1a61e10000000a422035/content.htm
Error Stack
http://help.sap.com/saphelp_nw70/helpdata/EN/42/fa1acfcf2c1aa2e10000000a422035/content.htm
Thanks
Assign points if this helps

EA6300 - Windows TCP/IP Printing Using LPR Protocol to USB ??

I am in process of replacing an old Zyxel router with (probably) an EA6300 (depending on the answer to this post...)
Currently I have a Dymo USB label printer connected to the Zyxel's USB port, and my Windows 7 clients are set up to print to that device using the LPR protocol through a Windows TCP/IP print port connected to 192.168.1.1 (the IP address of the Zyxel).
So my question is whether the EA6300 will work in the same way?

Hi Andrew! Yes the VUSB software must be installed on your Windows 7 computer for it to be able to see the printer that will be connected to the USB port of the EA6300 and be able to print . Here's more information about the EA6300, http://kb.linksys.com/Linksys/ukp.aspx?vw=1&docid=7e5454f239a946599bd151dccb031a57_Getting_to_know_t...

Ulimit(stack) and ulimit(nofiles) needs to be changed.

root@iibtreasury2 # ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 1024
memory(kbytes) unlimited
root@iibtreasury2 #
And
root@iibtreasury1 # ulimit -Ha
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 10
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 16384
virtual memory (kbytes, -v) unlimited
root@iibtreasury1 #
how to:-
1)Increase the ulimit(STACK) to a minimum of 32768
2)Increase the ulimit(NOFILES) to a minimum of 4096
permanently.
these are entries in /etc/system
set noexec_user_stack=1
set max_nprocs = 30000
set maxuprc = 16384
set rlim_fd_cur=1024
set shmsys:shminfo_shmmax=12884901888

well, after hours of searching around on the web and just after posting my question I now finally found this:
http://www.sapgeek.net/2010/10/sap-j2ee-engine-db-connection/
Using the configtool.bat (logged in with windows account <SID>adm and startet it from E:\usr\sap\<SID>\Jxx\j2ee\configtool) I was able to edit the connection string accordingly.
Now j2ee starts up properly.
Regards
Renaud

How to share Windows 7 Internet connection AND Extreme USB hard disk?

Hi All,
I'm trying to share the mobile broadband Internet connection on a Windows 7 PC as well as the USB hard disk connected to the Airport Extreme (2nd Gen) with other WiFi devices. The problem is that I can get either the one to work or the other, but not both.
When I configure the Airport Extreme for DHCP+NAT, all machines on the Airport network can see each other, share files, etc. When I enable Internet Connection Sharing on the Windows 7 machine, the only way I've gotten that to work is to set the Airport Extreme to bridge mode, but then file sharing of the Airport Extreme's disk no longer works.
Device info: Internet-connected Dell Latitude E5420 Windows 7 Professional 32-bit, Airport Extreme 802.11n (2nd Gen), Windows XP Home Edition + Nokia N8 + etc. WiFi devices.
I've read all the manuals I could find and searched these forums but haven't been able to figure out a solution. I'm really getting desperate and will really appreciate any and all suggestions!
Many thanks,
Francois

I've found a solution that works with my existing equipment. It's now possible to share the Windows 7 machine's Internet connection at the same time as the AirPort's drive. An additional challenge was to avoid having to manually reconfigure every WiFi client, but it turned out that's also possible.
For the sake of posterity, here's the guide! :-)
Background
My setup is based on an AirPort Extreme access point WiFi network. The AirPort shares a hard drive, and a number of Windows clients connect to the network. One of these, a Windows 7 machine, has a USB mobile broadband dongle which I also wanted to share with the network.
Previously I got this to work, but whatever configuration I came up with required manual reconfiguration of each network client, one way or the other. This was not ideal. Also, Internet Connection Sharing (ICS) defaults to IP address .1, the same one to which the AirPort defaults. This needed manual reconfiguration of the ICS host each time ICS was turned on.
Solution
THIS SOLUTION REQUIRES THE AIRPORT TO BE IN EITHER DHCP + NAT OR DHCP MODE. IF FOR SOME REASON YOU DEPEND ON THE AIRPORT BEING IN BRIDGE MODE, UNFORTUNATELY THIS SOLUTION WILL NOT WORK FOR YOU.
1. Do the AirPort's non-Internet configuration
On the AirPort Utility main screen, click the AirPort button, work through all the tab sheets and configure the items as you require. Do the same for the Printers, Disks and Advanced buttons. Once that's complete, we can do the Internet configuration.
2. Set the AirPort to DHCP & NAT
This is needed so you can choose the AirPort network address in the next step (but you can still set a different Connection Sharing mode later on, see step 7). For now, set Connection Sharing to Share a public IP address:
3. Set the AirPort to the same network address as ICS
Set the AirPort to the network address used by ICS, namely 192.168.137.xyz. Note that the AirPort does not allow a beginning address below 2:
4. Obtain the AirPort's MAC addresses
These will be used in the next step. Record both the Airport ID as well as the Ethernet ID:
5. Fix the AirPort IP addresses to prevent clashing with ICS
The AirPort will default to the same IP address as ICS, namely 192.168.137.1. To prevent this, assign different addresses to the AirPort with DHCP reservations. Underneath DHCP Reservations, click the '+' and create reservations for each of the AirPort and Ethernet interfaces. You can use other values, but to be consistent with the rest of this guide use 192.168.137.253 for the AirPort interface and 192.168.137.254 for the Ethernet inteface:
6. Distribute ICS configuration data with AirPort DHCP
Yes, you read right! This is where the magic happens. To avoid having to manually configure each WiFi client for the additional ICS network, that configuration data is included with the AirPort DHCP configuration. Assuming you've stuck to the numbers above, configure the TCP/IP screen exactly as shown. .254 is the AirPort router (and also its Ethernet interface) address, and .1 is the IP address that Windows configures for the ICS interface:
7. Set AirPort Connection Sharing
If your AirPort is sharing a connection on its WAN port, choose Share a public IP address, otherwise choose Distribute a range of IP address. In the latter case the NAT tab disappears:
8. Save your AirPort's configuration
Your AirPort configuration is now complete and you can push the Update button. Once your AirPort has rebooted, its network will be fully operational.
9. Ensure your Internet sharing port is correctly configured
ICS involves two network ports on the sharing computer - the shared Internet-connected port, and the sharing port connected to your local network. When you enable ICS on the shared port, Windows will temporarily configure the sharing port's settings to fit in with the scheme above (it will get the fixed IP address 192.168.137.1). When ICS is disabled, Windows will restore the default configuration of the sharing port. The purpose of this step is to ensure that the default sharing port configuration is correct. When ICS is inactive the sharing port needs to obtain an IP address automatically from the AirPort via DHCP. Right-click your chosen WiFi sharing connection > Properties > Networking > Internet Protocol Version 4 (TCP/IPv4) > Properties and configure as follows:
10. Share your Internet connection
Right-click the connection you want to share > Properties > Sharing and configure as follows (you may find the other settings also useful but they're not covered here):
And now you're ready to enjoy your local network services as well as your shared Internet connection, all on your Airport Extreme network - without having to lift a finger to configure network clients!
Windows Network Profiles
If you use Windows network profiles to distinguish between Home, Work and Public networks, here are some additional notes you may find useful.
As Windows recognises networks, it applies their assigned profiles which add or remove sets of restrictions wrt. network discovery, file & printer sharing and so on. The amount of ICS configuration data that can be included with AirPort DHCP information is limited and in some instances this interferes with how Windows recognises networks.
It seems that Windows recognises a network once a default router has been configured for it. Following are some known scenarios with fixes for each, based on that principle.
1. WiFi network not recognised
When ICS is enabled, on the ICS host Windows configures only an IP address for the sharing port and no default router. When ICS is disabled, on the ICS host this port receives its configuration from the AirPort via DHCP, as do all other WiFi clients. This DHCP configuration includes router information for the ICS network, but again no router information for the AirPort network itself.
Therefore the AirPort network is not recognised on any Windows machines on the WiFi network, under any circumstances.
To make Windows recognise the AirPort network, execute the following from the command line with Administrator privileges:
     route -4 add 0.0.0.0 mask 0.0.0.0 192.168.137.254 metric 3000
This metric is high enough to ensure that "real" default routes get preference over this one.
If you want to remove the above routing table entry, execute the following from the command line with Administrator privileges:
     route -4 delete 0.0.0.0 192.168.137.254
For convenience I created shortcuts for these two commands.
2. WiFi network recognised, unrecognised network remains
Once you've added the route above to make Windows recognise your AirPort network, when ICS is disabled Windows will probably identify TWO networks on your WiFi adapter:
     Unidentified network, your_AirPort_network
Windows now recognises your AirPort network, but the DHCP router entry for the inactive ICS network makes it think there must be yet another network. However, the 192.168.137.1 ICS port is not present when ICS is inactive, so Windows reports the inactive router entry as an unidentified network.
If you want to remove this unidentified network/router entry, execute the following from the command line with Administrator privileges:
     route -4 delete 0.0.0.0 192.168.137.1
On your Windows ICS host, removing this entry can cause no harm.
However, on network clients where you removed this entry and subsequently want to share your Internet connection from again, you'll need to add it back.
To restore the ICS router entry, execute the following from the command line with Administrator privileges:
     route -4 add 0.0.0.0 mask 0.0.0.0 192.168.137.1 metric 1

C6 - Windows 7, Ovi Suite and connection via Bluet...

Hello
I have a problem with connection my Nokia C6 with computer (system Windows 7) via Bluetooth.
Ovi found the device, move on to the next step. Displays the message "Your computer may be required to install the Bluetooth modem", then a long, long time nothing. And then an error "Can not connect to the device. " What could be wrong?

I have the same trouble with my E71 and Lenovo TP w510 (Windows-7-64).
I've made clean install recently (disc crash) and I have now everything up2date - system, drivers, BT (Microsoft stack) and latest OVI suite. But I can't connect with BT (same messages and then error). However, I can browse my phone directly (windows BT connect) easilly.
Before disc crash I've had Office 2007 and OVi Suite 2.xx together with PC Suite (ver. 7) and everything worked ok. Now with clean install of all latest system, drivers and sw it doesnt work. This is what make me furious with Nokia and their SW - it is worthless. By my opinion the step from PC Suite to OVI Suite is is like step from ugly good horse to fancy dressed **bleep**. You have no control of syncing things not even a proper logs etc. This is simple stupid. And OVI messed thing many times. For example - lately it write me some events (serise) all over many days in my caledar. And gues what - it looks it is immpossible to clean whole calendar with one simple move on the phone.
I am seriously looking for a new phone and it looks like this is my last Nokia.

Windows TCP/IP stack and packet bursts

Similar Messages

Maybe you are looking for