UDP EDNS packet size

Similar Questions

• MDS Http POST packet size restriction?

  Hello

  I have a problem with my application and a device connected to a BES for applications (MDS_4.1.7.16)

  I have this code example:

        connection = (HttpConnection) Connector.open(this.url,Connector.READ_WRITE,true);
  
        connection.setRequestMethod(HttpConnection.POST);
  
        connection.setRequestProperty("User-Agent", "MyUseragent";
  
        connection.setRequestProperty("Content-Type", "multipart/form-data" + "; boundary=" +  boundary);      
  
        connection.setRequestProperty("Content-Length","" + data.length);       connection.setRequestProperty("Connection","close");
  
        if (data != null && data.length > 0) {
  
          output = new DataOutputStream(connection.openDataOutputStream());        System.out.println("output opened");        output.write(data,0,data.length);        System.out.println("output wrote");           //output.flush();         //output.close();  input = new DataInputStream(connection.openInputStream());        System.out.println("input opened"); .... ....      }
  
  And then I close all my connections in a finally block
  

  To resume I've got this output:

  exit open
  output wrote

  When I try to write a few bytes on my outputstream there is no problem (got the entry 'opens'), but when I try to write about 29kilobytes, everythings seems good, but after the output.write (), the connection seems damaged... My input stream cannot be opened lock on it without any errors. I try with a flush() function and a close() after writing and then it is hunting water or closing that block my thread without exception more.

  Y at - it no limitation with the BES/MDS of MESSAGE size? I do my testing on a Blackberry Curve 8900 with OS 4.6.1.310

  Can I see any error on my bes log error? Could not find any information in the log folder...

  I have this problem only when I push my application via BES and not when I deploy it with JavaLoader. There is the default policy for the user and the cause of the application this is a new installation.

  Thank you in advance, I really need your help!

  Good bye

  Hello

  I found a solution that allow me to download my packages of 25 KB.

  I added a line in the header of the border: "Content-Transfer-Encoding: binary\r\n";

  After:

  ' Content-Disposition: form-data; name =-"o"; ("filename =------'b\' \r\n ');
  "" Content-Type: application/octet-stream\r\n ");"

  But now I have another problem.

  When my BES is offline my packages come up on a public MDS who?

  And when it is in offline mode I have the same problem of packet size, the ' Content-Transfer-Encoding: binary "seems to be not taken into consideration by the public MDS?

  How can I do, there are other properties that I can put?

  Thanks in advance,

  bloobi

• How to increase transmit UDP Ecris VI size

  I get the following error trying to send a message using UDP VI transfer:

  113 error in UDP, write to dataServer.vi

  Possible reasons:

  LabVIEW: A message sent on a datagram socket was larger than the message buffer internal or other network limit, or the buffer used to receive a datagram was smaller than the datagram itself.

  Does anyone know how to increase the size of the internal buffer to allow larger datagrams?

  Hello Davida2000,

  You should be able to use 8192 bytes which is 0x2000 in hexadecimal. The problem you are experiencing would be driven to Winows buffering, so the best solution may be to make a loop and the queue and extract the data from there.

• ICMP packet size?

  Hello

  I sniffed the ping packets, image size indicates 74 bytes.

  that would be 20 bytes of IP header, 8 bytes for 32 data, 18 bytes of the ethernet frame min + ICMP header.

  In my case, I have ping of win xp, 32 bytes of data.

  So, adding, 20 + 8 + 32 + 18 = 78 bytes. But framework said sniffes packages total 74 bytes on the wire.

  After some research, I found that the ethernet frame is taken as byte 6 D.A. + 6 byte byte, type of S.A + 2 = 14 bytes.

  And there is no added CRC byte. With this, the framework package will be exactly 74 bytes.

  Can you get it someone please tell me why CRC is not included in the ethernet frame?

  Lek

  I would say you should check some docs on sniff if you use. For example wireshark seizes not only field you can make it work, but I can suggest on that.

  Thank you
  Ajay

• BIS/BES - best HTTP packet size?

  Hello there, we need a large amount of data (up to several tens of MB) to be paid by the server by using HTTP. Somewhere, there is information that it is best to divide the data into small pieces with size about 20 KBs to pass to the Blackberry. Does anyone have information:-is it true? -different sizes of piece? -It is only limit BIS/BES? Thanks in advance!

  There is a limit of BES, it was once 128KB, now usually much larger.  I'm not aware of a BIS limit.

  I've seen other people recommend 64 KB as the largest block to download.  I can see why because it will take a reasonable amount of time to pass more wireless (especially not 3G).  You must take into account the time of retransmission and the possibility of a problem (such as a phone call, especially on phones not 3G) and does not have the size too large.

  But with this size of data, you should really be sure that you're in WiFi before download should not you!

• Limits on the size of the UDP packets

  I can't receive packets UDP only larger than the size of 8192 bytes. I can receive packets that are lower (or equal) of 8192 bytes.

  Also if a 8193 bytes packet is sent from the server not only make time trying to receive (i/o operation has expired), but I can't receive all the smaller packages later. It's like this big package breaks any subsequent extraction. I keep time after him. I tried to increase the timeout, but it doesn't help.

  I was under the assumption that the limit of a UDP packet is 65507 (this is the output of datagramConnectionBase.getMaximumLength ()). Is there something that I am missing, or is this a limit?

  Here is a snippet of the code I use:

  private DatagramConnectionBase datagramConnectionBase;
  private Datagram udpDatagram = null;
  

  //Init UDP
  String url = "datagram://:" + getConnectionSuffix();
  datagramConnectionBase = (DatagramConnectionBase) Connector.open(url, Connector.READ_WRITE, true);
  
  //Send UDP
  String data = "HELLO UDP SERVER! [" + System.currentTimeMillis() + "]";
  byte[] buffer = data.getBytes();
  
  url = "datagram://" + txtHost.getText() + ":" + txtHostPort.getText() + getConnectionSuffix();
  udpDatagram = datagramConnectionBase.newDatagram(buffer, data.length(), url);
  datagramConnectionBase.send(udpDatagram);
  

  In a thread:

  datagramConnectionBase.setTimeout(1000);
  udpDatagram = datagramConnectionBase.newDatagram(datagramConnectionBase.getMaximumLength());
  
  datagramConnectionBase.receive(udpDatagram);
  byte[] b = udpDatagram.getData();
  
  logThis("Bytes: " + udpDatagram.getLength());
  

  Just to close this message. In the end, I never found any official or unofficial word on the maximum UDP packet size.

  The solution we have implemented was ventilation packets sent in 508 bytes and reassemble at destination. This seems to work great although it seems that there are times that the unit is being overwhelmed with packages it to drop some... but that's for another post.

• UDP receive default buffer size

  Hello

  I have a question about receiving data via UDP:

  Description of the problem:

  An application of part 3 is extract to a PACS + 2400 Hz measurement data.

  All samples are then sent to a UDP port locally.

  I then use a labview application to read the data and perform a treatment.

  The question is, at 2400 Hz I loose a lot of UDP packets because of receive buffer overflow, i.e. new data appear before all the old data is read.

  It's BI data ' in irregular bursts, 10 - 20 times every second.

  I tried increasying the Protocol UDP receive buffer according to this size:

  http://digital.NI.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D

  And it seems to fix the problem.

  But here is another question:

  If I change the size of the UDP buffer during execution of the application of the 3rd part, the 3rd team application will crash.

  So my question is:

  Is it possible to change the value default UDP receive buffer size in windows?

  Such that when the UDP connection is open, it will have a buffer size of 32768 for example, regardless of which application that accesses the UDP connection first?

  Y at - he got another code inside your task of reading as a ms of waiting? Is the task of reading as lean and mean as possible? When you increase the size of the buffer?

  I found this registry key. It may be worth a try. The post was old, it cannot apply to Win7.

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters \DefaultReceiveWindow (REG_DWORD) = 16384 (decimal)

• Help the analysis of UDP packets

  Hello, I am new to Labview and working on a program to read the UDP packets. I was looking at the example UDP receive Labview and read also older messages. The data consists of 1-Header Word (32 bits), 24-data words (each word is 32 - bits), and the rest of the data is data filling which is all zeros. Each package is the same size.  Far by the UDP Receiver.vi example I am able to receive the data and could probably push on with what I have, but I would like to know if there is an easier way to analyze a UDP data packet? I have read others who used a Cluster and the TypeCast but can't seem to make it work. When I try to connect to my Cluster until the TypeCast it wire goes to the dotted line.

  If anyone has any suggestions on the easiest ways to analyze a UPD packet please let me know.

  Thank you

  Joe

  
  

• I am connected but the network properties window does not show the size of the packets to all the

  I am connected but the network properties window does not show the size of the packets to all the

  Hi asaimas,

  You can follow this link & check if it helps:

  Configure the Option of configuring server network packet size

  Hope the helps of information.

• Camera GigE of NI VBAI lost packets

  We run VBAI on a fast PC with an Intel Pro/1000 card and a switch GigE of jumbo-frame to a large number of Basler Ace GigE cameras.

  It is understandable that multiple cameras cannot transfer complete images to the PC to the full flow of 1000 MHz because of the limited bandwidth between the PC and the Switch simultaneously.

  A way around this is to strangle the maximum for each camera down data flow so that the sum is not greater than 1,000 MHz.

  However, this means that transfers images always take more time, even if only a single camera to enter service, a large part of the time.

  What is a fundamental limitation of GigE Vision, or are smart enough work as soon as possible of the GigE Vision cameras... via returns package loses casual?

  Nelson

  We have found a solution.

  The problem is that the cameras, switch, network card and VisionBuiilder cannot treat all cases where more than one camera sends images to VisionBuilder where the total of the rates of data for these cameras is never more than 1 GB of band bandwidth network card.

  (It would be nice if someone did a network switch that has a little more package buffer memeory...) 100 MB?... so that the images of the garbage does not have the occasional collision while allowing most of the captures operate at maximum speed.)

  Solution:

  (1) we have added 3 ports on network 1 Gb additional to our pc of mink.

  (2) in order to redistribute traffic camera in more than one network port, we assigned to each network adapter and corresponding cameras, to a different subnet.

  (3) we have lowered the rate of data for less urgent cameras.

  Even after the lowering of the data rates for multiple cameras in NOR-MAX up to 200 Mb/s such as lost packets should no longer be possible, we stil seen.

  After a detailed examination, we found that the stages of acquisition image VisionBuilder are not careful the data rates that you assign to NOR-MAX and always default to 1000 MB/s maximum rate, so saturated flow and lost packets.

  The solution to this problem proves to be explicitly set to the flow desired in each stage of the acquisition of Image VisionBuilder, using the attributes tab.  While you're there, you should also check other critical parameters, such as the packet size, are also correct and update if not.

  After you explicitly fix rates given in every stage of image acquisition, we ran a stress test of capture image that ran all the process of vision (several programs running at the same time) about 10 times faster than necessary and observed no lost in all packets.

  Problem solved.

• How to choose right for the WAN Interface MTU size?

  Hello

  I would like to know How to determine the right size MTU to set in the properties of the WAN interface (in my case, NSA appliances).

  First of all. I noticed that with SonicOS Enhanced 5.9.x, there is a Tool of diagnosis called PMTU discovery:

  

  This tool is not available with SonicOS Enhanced 5.8.x.

  I guess using this built-in tool is a way to determine the right MTU size to apply.

  Second, for SonicOS versions that do not have this tool and to understand just how to manually determine the size MTU, I would like to know what is the method to follow.

  On the Internet, I found this method by using the ping-f-l command. Once you have determined the largest possible packet size, it ask you to Add 28 to that number and you get the MTU size to define the interface.

  Case study:

  In my business, there are 2 sites: 1 in China and 1 in South Korea. Both have a firewall SonicWALL NSA.

  To determine the MTU size that is applicable from the Chinese site, I get the same results with the 2 methods mentioned above.

  With the help of the PMTU discovery:

  I get 2 IPs: 8.8.8.8 and the Korean FW IP WAN. I get the same result: 1500.

  

  

  However, I noticed that the MTU size should be set to its maximum (1500) of size on the properties of the interface WAN for this test to work properly. Indeed, when I put in 1404 to test, PMTU discovery find 1404 such as MTU size:

  

  

  With the help of ping - f - l:

  When you use the ping with FW Korea WAN IP method, I found 1472 as the maximum packet size:

  

  According to the method I've read on the Internet, adding 28 will make me a MTU of 1500, same size as the PMTU discovery method.

  My question is: can you confirm that these 2 methods are correct determine the MTU size to set the WAN interface? Especially the one with the ping command? If not, how do?

  Thanks in advance for your comments.

  I can tell you that as technicians, we use the way to CMD line to adjust the MTU on WAN interfaces. We saw this as a number to work with.

  Thank you
  Ben D
  #Iwork4Dell

• Package IPSec - SHA256 digest size calculator?

  Hello

  I recently discovered the IPSec packet size calculator in this forum (see attachment).

  It is very useful calculate overhead when using IPSec, esp. DMVPN.

  Unforunately it contains no options for the following hashes:

  Hmac-sha256-ESP the ESP by using HMAC-SHA256 auth transformation

  The ESP by using HMAC-SHA384 auth hmac-sha384-ESP processing

  The ESP by using HMAC-SHA512 auth hmac-sha512-ESP processing

  Where can I get information on how great collection will be when you use 'hmac-sha256-esp' in my game of transformation?

  Someone is able and willing to implement these new options in the calculator?

  Thank you

  This has just been released a week ago:

  https://cway.Cisco.com/tools/IPSec-overhead-Calc/IPSec-overhead-Calc.html

  Thank you

  Wen

• PIX does not allow packets loarge

  I can ping with l - 992, but fail with-l 993.

  Ping 172.16.17.1 with 992 bytes of data:

  Reply from 172.16.17.1: bytes = 992 time = 1ms TTL = 254

  Reply from 172.16.17.1: bytes = 992 time = 1ms TTL = 254

  Reply from 172.16.17.1: bytes = 992 time = 1ms TTL = 254

  Reply from 172.16.17.1: bytes = 992 time = 1ms TTL = 254

  Ping statistics for 172.16.17.1:

  Packets: Sent = 4, received = 4, lost = 0 (0% loss),

  Time approximate round trip in milli-seconds:

  Minimum = 1ms, Maximum = 1ms, average = 1ms

  Ping 172.16.17.1 with 993 bytes of data:

  Request timed out.

  Request timed out.

  Request timed out.

  Request timed out.

  Ping statistics for 172.16.17.1:

  Packets: Sent = 4, received = 0, lost = 4 (100% loss),

  I also see that attached to the devices in the DMZ are taken excessively long time.

  The MTU size on all interfaces is always the default value of 1500.

  Hi Jimmysturn:

  Which is likely happened here is that you have ID political attack linked to your external interface with the action 'drop' or 'reset' all packages that match the signature in the category of the attack.

  Signature 2151 (large ICMP) will drop packets hit the PIX off interface or those who pass through the PIX outside interface when you ping with large packet size (+ 993 bytes):

  From your post, you must have had the following policy of IDS on your PIX:

  IP audit name attackpolicy attack action fall

  (or

  IP audit name attackpolicy action fall attack alarm

  or

  attack IP audit name attackpolicy raz action alarm

  or both)

  If you want to ping with big package, there are several things you can do:

  (1) remove the policy of "attackpolicy" completely from your external interface. It will turn off all of the IDS signatures in the category of the attack.

  Carefully look at this and see if it's what you want to do.

  To achieve the above, issue the following command:

  "no interface verification ip outside of attackpolicy"

  (2) turn off the signature 2151 by running the command:

  "disable signature verification ip 2151.

  That would disable only the big signing of ICMP attack while leaving the other signatures of attacks in the category of GIS attack ON.

  (3) set signature action to open a session (a syslog server or the internal buffer) large ICMP packets instead of dropping. Again, this should be determined carefully as option 1.

  To achieve the above goal, issue the following command:

  IP audit alarm action name attackpolicy attack

  It will be useful.

  Please indicate the position accordingly if you find it useful.

  Sincerely,

  Binh

• vmkping cannot send packets larger than 504 bytes? IGB driver broken?

  Hi all

  I have a HP ProLiant DL360e Gen8 with 96 GB RAM Server installed.

  There are 4 1Gbit NIC (igb driver used)

  ~ # esxcfg - NICS - l

  Name PCI Driver link speed Duplex MAC address MTU Description

  vmnic0 0000:02:00.00 igb up to 1000Mbps Full 38:63:bb:2 c: a5:b8 1500 Intel Corporation I350 Gigabit Network Connection

  vmnic1 0000:02:00.01 igb up to 1000Mbps Full 38:63:bb:2 c: a5:b9 9000 Intel Corporation I350 Gigabit Network Connection

  IGB 0000:02:00.02 vmnic2 low 0Mbps half 38:63:bb:2 c: a5:ba 1500 Intel Corporation I350 Gigabit Network Connection

  IGB 0000:02:00.03 vmnic3 low 0Mbps half 38:63:bb:2 c: a5:bb 1500 Intel Corporation I350 Gigabit Network Connection

  ~ #

  I use ESXi 5.5 U2:

  ~ # esxcli get version system

  Product: VMware ESXi

  Version: 5.5.0

  Build: Releasebuild-2718055

  Update: 2

  ~ #

  There are 2 local vSwitches:

  ~ # esxcfg - vswitch - l

  Switch name Num used Ports configured Ports MTU rising ports

  2432 4 128 1500 vmnic0 vSwitch0

  Name PortGroup VLAN ID used rising Ports

  The VM network 0 0 vmnic0

  0 1 vmnic0 Mgmt

  Switch name Num used Ports configured Ports MTU rising ports

  2432 4 128 9000 vmnic1 vSwitch1

  Name PortGroup VLAN ID used rising Ports

  San 1 950 vmnic1

  ~ #

  ~ # esxcfg - vmknic - l

  Port Group/DVPort/Opaque IP IP family network interface address Netmask Broadcast MAC address MTU TSO MSS active Type

  vmk0 mgmt IPv4 192.168.4.232 255.255.255.0 192.168.4.255 38:63:bb:2 c: a5:bb 1500 65535 true STATIC

  vmk1 san IPv4 172.25.50.232 255.255.255.0 172.25.50.255 00:50:56:67:28:d2 9000 65535 true STATIC

  ~ #

  The VMKernel vmk1 interface is configured to connect to the NFS data store (using separate nic vmnic1 and VLANS separated 950). But there was time-out problems when you try to access the NFS datastore.

  What I realized is that I'm not able to ping to NFS datastore (and vice versa) with the larger than 504 bytes... packet size:

  ~ # vmkping - I vmk1 d 172.25.50.233

  PING 172.25.50.233 (172.25.50.233): 56 data bytes

  64 bytes from 172.25.50.233: icmp_seq = 0 ttl = 64 time = 0.296 ms

  64 bytes from 172.25.50.233: icmp_seq = 1 ttl = 64 time = 0,235 ms

  64 bytes from 172.25.50.233: icmp_seq = 2 ttl = 64 time = 0,236 ms

  -172.25.50.233 - ping statistics

  3 packets transmitted, 3 packets received, 0% packet loss

  round-trip min/avg/max = 0.235/0.256/0.296 ms

  ~ # vmkping - I vmk1 s 504 - d 172.25.50.233

  PING 172.25.50.233 (172.25.50.233): 504-data bytes

  512 bytes from 172.25.50.233: icmp_seq = 0 ttl = 64 time = 0,338 ms

  512 bytes from 172.25.50.233: icmp_seq = 1 ttl = 64 time = 0,268 ms

  512 bytes from 172.25.50.233: icmp_seq = 2 ttl = 64 time = 0,234 ms

  -172.25.50.233 - ping statistics

  3 packets transmitted, 3 packets received, 0% packet loss

  round-trip min/avg/max = 0.234/0.280/0.338 ms

  ~ # vmkping - I vmk1 s - 505D 172.25.50.233

  PING 172.25.50.233 (172.25.50.233): 505-data bytes

  -172.25.50.233 - ping statistics

  3 packets transmitted, 0 packets received, 100% packet loss

  ~ #

  What more, I ran pktcap-uw tool to look at packets on a network interface:

  for:
  # vmkping - I-c - 1 d 172.25.50.233 vmk1

  There are visible packages:

  12:17:14.50741 [6] captured at point EtherswitchDispath, TSO do not activated, Checksum not unloaded and not checked, 950, length 98 brand VLAN.

  Segment [0] - 98 bytes:

  0x0000: 0050 5667 28 d 2 0cc4 7a 18 0800 4500 3bd4

  0 x 0010: 0054 1e4e 4000 4001 ac19 32e9 ac19 5e57

  0 x 0020: 32e8 0000 e6af 0000 4699 555d CCCA 0000

  0 x 0030: c58b 0809 0a0b 0c0d 1011 1213 1415 0e0f

  0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 x 0

  0 x 0050: 2627 2829 2a2b 3031 3233 3435 2e2f 2c2d

  0 x 0060: 3637

  but for:

  # vmkping - I vmk1-c 1 s - 505D 172.25.50.233

  There is nothing visible on the physical interface.

  The package is visible on the layer "vmk1":

  ~ # pktcap - uw - vmk vmk1

  The name of the key vmk is vmk1

  No server specified, port select 39635 as port

  The news of package to the output console.

  CID local 2

  Listen on port 39635

  Accept... Vsock connection port 1028 cid 2

  12:19:52.182469 [1] captured at PortInput point, OSI not activated, not unloaded and not verified Checksum, length 547.

  Segment [0] - 547 bytes:

  0x0000: 0cc4 7a 18 0050 5667 28 2 0800 4500 d 3bd4

  0 x 0010: 0215 1ac7 4000-4001-601 d ac19 32e8 ac19

  0 x 0020: 32e9 0800 0000 555d cd68 0002 de9a b1a5

  0 x 0030: c87a 0809 0a0b 0c0d 1011 1213 1415 0e0f

  0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 x 0

  0 x 0050: 2627 2829 2a2b 3031 3233 3435 2e2f 2c2d

  0 x 0060: 3637 3839 4041 4243 4445 3e3f 3c3d 3a3b

  0 x 0070: 4647 4849 4a4b 4c4d 5051 5253 5455 4e4f

  0 x 0080: 5657 5859 5a5b 5c5d 6061 6263 6465 5e5f

  0 x 0090: 6667 6869 6a6b 6c6d 6e6f 7071 7273 7475

  0x00a0: 7677 7879 7a7b 7c7d 7e7f 8081 8283 8485

  0x00b0: 8687 8889 8a8b 8c8d 9091 9293 9495 8e8f

  0x00c0: 9697-9899 9a9b 9c9d 9e9f a0a1 a2a3 a4a5

  0x00d0: a6a7 a8a9 aaab acad b0b1 b2b3 b4b5 aeaf

  0x00e0: b6b7 b8b9 bebf c0c1 c4c5 c2c3 CHB babb

  0x00f0: CACB RCC cecf d2d3 d4d5 d0d1 c8c9 c6c7

  0x0100: d6d7 d8d9 David e0e1 e4e5 e2e3 dcdd dadb

  0 x 0110: e6e7 e8e9 eaeb eced eeef f0f1 f2f3 f4f5

  0 x 0120: f6f7 f8f9 with fcfd 0001 0203 0405 feff

  0 x 0130: 0607 0809 0a0b 0c0d 1011 1213 1415 0e0f

  0140: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 x 0

  0 x 0150: 2627 2829 2a2b 3031 3233 3435 2e2f 2c2d

  0 x 0160: 3637 3839 4041 4243 4445 3e3f 3c3d 3a3b

  0 x 0170: 4647 4849 4a4b 4c4d 5051 5253 5455 4e4f

  0 x 0180: 5657 5859 5a5b 5c5d 6061 6263 6465 5e5f

  0 x 0190: 6667 6869 6a6b 6c6d 6e6f 7071 7273 7475

  0x01a0: 7677 7879 7a7b 7c7d 7e7f 8081 8283 8485

  0x01b0: 8687 8889 8a8b 8c8d 9091 9293 9495 8e8f

  0x01c0: 9697-9899 9a9b 9c9d 9e9f a0a1 a2a3 a4a5

  0x01d0: a6a7 a8a9 aaab acad b0b1 b2b3 b4b5 aeaf

  0x01e0: b6b7 b8b9 bebf c0c1 c4c5 c2c3 CHB babb

  0x01F0: CACB RCC cecf d2d3 d4d5 d0d1 c8c9 c6c7

  0 x 0200: d6d7 d8d9 David e0e1 e4e5 e2e3 dcdd dadb

  0 x 0210: e6e7 e8e9 eaeb eced eeef f0f1 f2f3 f4f5

  0 x 0220: f8 f6f7

  If I understand correctly, packets are lost somewhere between vmk1 and vmnic1 interfaces?

  I tried to change the interfaces physical, but all the same behavior.

  What is my broken hardware?

  Is the driver of the igb broken?

  See you soon

  Marek

  The problem is resolved.

  The question was in the configuration of switch HP (HP Procurve 2530 - 24g). There was a line in the config:

  back-filter

  After you turn off the back of the filter (# filterless back) all started to work.

  Marek

• VMWare View 4.6 PCoIP tunneling problem. UDP is not get tunnel

  
  Hello

  I have the black screen "classic" - question.
  So, when I try to connect to a virtual desktop, I am well auhtenticated, I can select a pool of offices, but once the bureau is launching,
  I just get a black screen and afterawhile it times out.

  I read the manuals, the document http://communities.VMware.com/docs/doc-14974 , written by Mark benson; Watched the video; Checked and re-checked the 3 magic steps;
  Blog reading Sláger, Paul http://paulslager.com/?p=1300 and still I'm stuck. I read the (some the) logs from the login view, view Security Server, View Client and Agent of the view server.
  None of the newspapers I read gave me all significant errors that would have solved this for me. Admitted, 'full' newspapers - trace State, there's a lot that wasn't exactly clear to me.

  I have simplified our mitigation debugging environment to be as follows:

  See connection to the server,
  running on Windows Server 2008 R2 (Datacenter) 64-bit VMware View Server connection 4.6.0 - 366101,.
  Checkboxes for both "Tunnel secure HTTPS: connection to Tunnel secure usage on the desktop" and "PCoIP Secure Gateway: use PCoIP PCoIP Gateway Secure connections to desktop" have been checked.

  View secure server,
  running on Windows Server 2008 R2 (Datacenter) 64-bit VMware View Server Security 4.6.0 - 366101,.
  has been paired with the login server and the two aswell "HTTPS Secure Tunnel: external URL" as "PCoIP Secure Gateway: PCoIP external URL" has been set to a virtual IP address in the firewall external dmz with a dst - nat on the real IP address of the Security Server.

  The reviews are pointing to the virtual IP address of the Server Secure View.

  Since it is not a production environment, I installed a bunch of Wireshark to see traffic;
  I ran traffic snooping on the view connection server, see Security Server, View Client and the virtual desktop connected
  at the same time and have verified that traffic TCP PCoIP on get 4172 port of talked about between my security server host <>client - and the
  securityserver <>- virtual desktop just fine. TCP traffic seems to be in the tunnel. But what bothers me is the wireshark on the virtual office reveals that the virtual office is trying
  to talk subject port 4172 - UDP back directly to my reviews host IP traffic. Because this is not allowed by the firewall, the virtual office propably does not work...

  But all scenarios describe only the Security server could handle all pcoip-traffic with the agent of the view (as shown in the documentation of the Architecture in Figure 5-6), so that no direct connection between the Client of the view and the view Agent is necessary... I can't work. But it is possible, right?

  Any ideas what I could do wrong?

  Help really appreciated.

  It works in the way that you described in your original post. There is no obligation for the virtual office send UDP responses to the client. They will be sent on the Security Server, which will forward them to turn to the customer.

  Something must be configured incorrectly.

  Check very carefully the UDP traffic in your wireshark traces. The client, you should see 4172 TCP for the VIP of your SS. You should then see 4172-UDP to the same VIP. You should see the UDP of SS response to the customer data. The destination for this data answer UDP port must be the source port used for the UDP request. The source for the response data port must be 4172.

  Then check your wireshark SS track. You should see the same customer traffic and you should see a similar PCoIP conversation between the SS and the virtual office. From the virtual desktop, the SS looks like a customer. PCoIP UDP must be sent to the SS, when it is properly configured.

  Client - TCP 4172-> SS - TCP 4172-> Virtual Office

  Customer - UDP 4172-> SS - UDP 4172-> Virtual Office

  Customer<-UDP 4172--="" ss=""><-UDP 4172--="" virtual="" desktop="" (the="" 4172="" here="" is="" src="" port,="" the="" dst="" udp="" port="" will="" be="" the="" source="" port="" of="" the="" udp="" request="" packets="" above)="" 4172--="" virtual="" desktop="" (the="" 4172="" here="" is="" src="" port,="" the="" dst="" udp="" port="" will="" be="" the="" source="" port="" of="" the="" udp="" request="" packets="">

  If you have verified that you can connect to the same virtual desktop with PCoIP then this problem will not be something to do with the virtual office or agent of view etc.

  Check your display settings, network, firewall and NAT.

  Select this option.