Search Results

Search found 1671 results on 67 pages for 'packets'.

Page 2/67 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

• UDP packets to IP addresses other than specific ones not arriving and not shown in Wireshark

  - by Max

  I'm writing a service using UDP, but I can't manage to reply to the client. When sending to the client via the DHCP-assigned IP (192.168.1.143) Wireshark shows no sent packets. The server receives and Wireshark shows any packet sent by the client (broadcasted). If I send to a random, unassigned IP Wireshark doesn't show it. I thought the NIC would happily send it, since there is a router in the way - shouldn't Wireshark show it, even though it cannot possibly be received by a remote endpoint? If I send to either the router IP or another (specific, there is only one other) computer, the packet is shown in Wireshark. I am running Windows 7, the firewall is turned off using the control panel. Does the fact that wireshark doesn't show these packets mean that they aren't sent? What reason could there be for showing packets to one IP, but not another, on the same subnet?

  Read the article

• iptables rule to submit packets matching a specific negative rule

  - by Aditya Sehgal

  I am using netfilter_queue to pick up certain packets from the kernel and do some processing on them. To, the netfilter queue, I need all packets from a particular source except UDP packets with src port 2152 & dst port 2152. I try to add the iptable rule as iptables -A OUTPUT ! s 192.168.0.3 ! -p udp ! --sport 2905 ! --dport 2905 -j NFQUEUE --queue-num 0 iptables throw up an error of Invalid Argument. Querying dmesg, I see the following error print ip_tables: udp match: only valid for protocol 17 I have tried the following variation with the same error thrown. iptables -A OUTPUT ! s 192.168.0.3 ! -p udp --sport 2905 --dport 2905 -j NFQUEUE --queue-num 0 Can you please advise on the correct usage of the iptables command for my case.

  Read the article

• Is Winpcap able to capture all packets going through a Gigabit NIC without missing any packets?

  - by Patrick L

  I want to use Winpcap to capture all network packets going through a Gigabit NIC of a server. Assuming that I am able to utilize the network link up to 100%, the maximum network speed is 1000Mbps. If we exclude the TCP/IP headers, the maximum TCP data rate should be roughly 940Mbps. Let's say I send a 1GB file through the NIC at 940Mbps using TCP destination port 6000. I use Winpcap to capture all network packets going through the NIC and then dump it to a pcap file. If I use Wireshark to analyze the pcap file and then check the sum of packet size for all network packets sent to TCP port 6000, am I able to get exactly 1GB from the pcap file? Thanks.

  Read the article

• new ubuntu server installation - java server not receiving packets

  - by James

  I have developed a Java server which listens for UDP packets which come from mobile devices. At the moment, it works correctly if I run my Server on my windows PC. I can receive and respond to the UDP packets sent from my phone (over 3g, not wifi). However, I am trying to run the Server on a different computer which I found lying around my house. I have basically done a clean install of Ubuntu Server edition, updated it, installed the java run time environment and configured port forwarding to allow connections on the appropriate port. I have also tried to disable the firewall. The problem is, it doesn't appear as if the server is receiving any packets and I've exhausted my brain thinking on how to solve/debug the problem. Can anyone suggest to me what the problem might be? or more likely something I can do to help me find out more information about what is going wrong.

  Read the article

• Wireshark Not Displaying Packets From Other Network Devices, Even in Promisc Mode

  - by eb80

  System Setup: 1. MacBook running Mountain Lion. 2. Wireshark installed and capturing packets (I have "capture all in promiscuous mode" checked) 3. I filter out all packets with my source and destination IP using the following filter ("ip.dst != 192.168.1.104 && ip.src != 192.168.1.104") 4. On the same network as the MacBook, I use an Android device (connecting via WiFi) to make HTTP requests. Expected Results: 1. Wireshark running on the MacBook sees the HTTP request from the Android device. Actual Results: 1. I only see SSDP broadcasts from 192.168.1.1 Question: What do I need to do so that Wireshark, like Firesheep, can see and use the packets (particularly HTTP) from other network devices on the same network?

  Read the article

• TCP 30 small packets per second flood connection with server

  - by Denis Ermolin

  I'm testing connection with flash client and cloud server(boost::asio for software) over TCP connection. My connection with server already is really poor - 120 ms ping in average. I found when i start to send packets with 2 bytes size (without tcp header) with speed 30 packets/s - ping grow to 170-200 average. I think that it's really bad and my bad connection and bad cloud provider is reason for this high ping without any load. What do you think? (I tested my software - it can compute about 50k small packets/s so software is not a problem). I measure my ping through flash client - send packet with timestamp and immediatly send from server to client.

  Read the article

• Network flooded with seemingly empty packets

  - by Adam Particka

  Let me preface this with the fact that I'm just a web developer at my company with little networking knowledge. Earlier today there was a department that lost all of their network connections so I popped open Wireshark and observed the influx of packets to my machine. There was normal traffic (ARP requests, etc.) coming in at ~50 packets every second. Then all of a sudden the log was flooded with packets arriving ~5000 a second. It looks as though they all contain the same data, just a looped sequence. We have someone here looking at it but I thought I would ask if anyone had seen anything like this before. Here's a selection from one of the captures in Wireshark. http://www.cloudshark.org/captures/06f950725c74

  Read the article

• Why would one server be sending DUP ACK packets to one PC, which is responding with HTTP RST packets?

  - by IronicMuffin

  I'm not a network profressional, so please excuse any wrong language. I was debugging why my DNS traffic was a constant 160Kbps on our corporate network. I opened up a wireshark trace, and I see one PC of a coworker broadcasting HTTP [RST] packets to one of our DMZ servers at the rate of 1000 a second. He restarted his machine, and as soon as it went offline, the server started broadcasting [DUP] [ACK] packets, until he came back online. It then resumed the HTTP [RST] packets. Apparently this server has been doing this kind of behavior since it went live. I believe it did this with a printer and an access point as well. Can anyone explain why this behavior is occurring? Any solutions? The initial research was done because there have been "bandwidth issues" and I wonder if this is contributing.

  Read the article

• cannot receive UDP broadcast packets

  - by user292792

  Hello I have 2 boxes: - an embedded device (ARM Omap with linux) which I'll call "Omap". - a PC (can either be Windows or linux). Scenario 1 Both boxes are in the same network (example: my office). The Omap gets its address from a DHCP server (ex: 192.168.10.110). The PC has always the same address (ex. 192.168.10.104). I can successfully exchange UDP broadcast packets on any port. Success. Scenario 2 The 2 boxes are in a network withOUT a DHCP server. The PC has a static IP address (example: 10.10.10.20). The Omap boots, looks for a DHCP server, doesn't find it, and is in what I call "bad IP address" state. Now... Broadcasting UDP packets from the Omap works: the PC can see them. The opposite doesn't work: UDP packets broadcasted by the PC are not seen by the Omap. I am using Wireshark on another PC to verify that the packets are being sent. Failure. I tried to change the Omap ip address (with ifconfig)... no luck. What am I missing? To complete the picture, when the Omap is in Scenario 2, if I run udhcpc ... it can communicate with the DHCP server and get an IP address. I also see the packets with Wireshark. So this means that the DHCP client is able to broadcast UDP packets. (Yes, I tried to use DHCP ports 67/68 but it doesn't work). I am using Boost C++ Asio UDP sockets. Specifically, I took the multicast examples and changed them to do broadcasting. Any help is appreciated. Thanks, Benedetto

  Read the article

• iphone problem receiving UDP packets

  - by SooDesuNe

  I'm using sendto() and recvfrom() to send some simple packets via UDP over WiFI. I've tried using two phones, and a simulator, the results I'm getting are: Packets sent from phones - recieved by simulator Packets sent from simulator - simulator recvfrom remains blocking. Packets sent from phones - other phone recvfrom remains blocking. I'm not sure how to start debugging this one, since the simulator/mac is able to receive the the packets, but the phones don't appear to be getting the message. A slight aside, do I need to keep my packets below the MTU for my network? Or is fragmentation handled by the OS or some other lower level software? UPDATE: I forgot to include the packet size and structure. I'm transmitting: typedef struct PacketForTransmission { int32_t packetTypeIdentifier; char data[64]; // size to fit my biggest struct } PacketForTransmission; of which the char data[64] is: typedef struct PacketHeader{ uint32_t identifier; uint32_t datatype; } PacketHeader; typedef struct BasePacket{ PacketHeader header; int32_t cardValue; char sendingDeviceID[41]; //dont forget to save room for the NULL terminator! } BasePacket; typedef struct PositionPacket{ BasePacket basePacket; int32_t x; int32_t y; } PositionPacket; sending packet is like: PositionPacket packet; bzero(&packet, sizeof(packet)); //fill packet with it's associated data PacketForTransmission transmissionPacket; transmissionPacket.packetTypeIdentifier = kPositionPacketType; memcpy(&transmissionPacket.data, (void*)&packet, sizeof(packet)); //put the PositionPacket into data[64] size_t sendResult = sendto(_socket, &transmissionPacket, sizeof(transmissionPacket), 0, [address bytes], [address length]); NSLog(@"packet sent of size: %i", sendResult); and recieving packets is like: while(1){ char dataBuffer[8192]; struct sockaddr addr; socklen_t socklen = sizeof(addr); ssize_t len = recvfrom(_socket, dataBuffer, sizeof(dataBuffer), 0, &addr, &socklen); //continues blocking here NSLog(@"packet recieved of length: %i", len); //do some more stuff }

  Read the article

• UFW blocking random packets on 443

  - by s2jcpete

  All, I have UFW setup to allow traffic on port 443. It works as expected, though I have a large amount of UFW Block log entries. To Action From -- ------ ---- 80 ALLOW Anywhere 443 ALLOW Anywhere 22222 ALLOW Anywhere 80 ALLOW Anywhere (v6) 443 ALLOW Anywhere (v6) 22222 ALLOW Anywhere (v6) However in my syslog file I see this: [UFW BLOCK] IN=eth0 OUT= MAC=XXX SRC=<foreignip> DST=<serverip> LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=22025 DF PROTO=TCP SPT=49622 DPT=443 WINDOW=0 RES=0x00 ACK RST URGP=0 About 30 or so seconds later pound (which I'm using for SSL decryption and port redirection) throws a connection timed out messsage. I'm assuming this is because UFW is blocking the packet. I'm at a loss as to an explination. Could the packet be malformed or something, is this normal? Edit - I have since changed the /etc/defaults/ufw and set ipv6=no, so the v6 rules are no longer in the mix. The server is still showing the block / connection timed out behavior though. The new ufw status output is: Status: active Logging: on (low) Default: deny (incoming), allow (outgoing) New profiles: skip To Action From -- ------ ---- 80 ALLOW IN Anywhere 443 ALLOW IN Anywhere 22222 ALLOW IN Anywhere

  Read the article

• VMWare capacity planner and monitoring network packets/second

  - by j t

  My client requested that we provide him 'packets/second' statistics for all servers monitored using Capacity Planner. Does anybody knows if it is possible and how to do that? I can get the bytes/second without trouble but not the packets.

  Read the article

• pretty-printing IP packets

  - by pts

  I'm receiving IP packets using the SLIP protocol, and I'd like to pretty-print them similarly to how tcpdump does it. My program is able to decode the SLIP protocol and create a single string containing an IP packet if necessary. I couldn't find any relevant tcpdump command-line flags except for -r. The file format is documented at http://www.tcpdump.org/pcap/pcap.html , but it looks a bit too complicated. Is there a Linux tool for pretty-printing raw IP packets?

  Read the article

• Cisco adaptive security appliance is dropping packets where SYN flag is not set

  - by Brett Ryan

  We have an apache instance sitting inside our DMZ which is configured to proxy requests to an internal NATed tomcat instance inside our network. It works fine, but then all of a sudden requests from apache to the tomcat instance stop getting through with the following in the apache logs: [error] (70007)The timeout specified has expired: ajp_ilink_receive() can't receive header Investigating into the Cisco log viewer reveals the following: Error Message %ASA-6-106015: Deny TCP (no connection) from IP_address/port to IP_address/port flags tcp_flags on interface interface_name. Explanation The adaptive security appliance discarded a TCP packet that has no associated connection in the adaptive security appliance connection table. The adaptive security appliance looks for a SYN flag in the packet, which indicates a request to establish a new connection. If the SYN flag is not set, and there is not an existing connection, the adaptive security appliance discards the packet. Recommended Action None required unless the adaptive security appliance receives a large volume of these invalid TCP packets. If this is the case, trace the packets to the source and determine the reason these packets were sent. All are machines are virtualised using VMware, and by default machines have been using the Intel E1000 emulated NIC. Our network administrator has changed this to a VMXNET3 driver in an attempt to correct the problem, we just have to wait and see if the problem persists as it's an intermittent problem. Is there something else that could be causing this problem? This isn't the first service where we have had similar issues. Our apache host is running Ubuntu 11.10 with a kernel version of 3.0.0-17-server. We have also had this issue on RHEL5 (5.8) running kernel 2.6.18-308.16.1.el5, this machine also has the E1000 NIC. NOTE: I am not a network administrator and am a software architect and analyst programmer responsible for these systems.

  Read the article

• Linux server: Dropped packets

  - by Lars

  I see dropped packets using ifconfig on my eth0 interface: eth0 Link encap:Ethernet HWaddr 00:15:17:0d:03:ca inet addr:10.0.1.2 Bcast:10.0.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:30268348 errors:0 dropped:70721 overruns:0 frame:0 TX packets:133076885 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8699434077 (8.6 GB) TX bytes:194937313025 (194.9 GB) Interrupt:16 Memory:feae0000-feb00000 When i use ethtool -S i dont see anything wrong: NIC statistics: rx_packets: 30267138 tx_packets: 133074510 rx_bytes: 8699356158 tx_bytes: 194934147340 rx_broadcast: 35296 tx_broadcast: 5435 rx_multicast: 0 tx_multicast: 0 rx_errors: 0 tx_errors: 0 tx_dropped: 0 multicast: 0 collisions: 0 rx_length_errors: 0 rx_over_errors: 0 rx_crc_errors: 0 rx_frame_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 0 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 tx_restart_queue: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 5757001 tx_tcp_seg_failed: 0 rx_flow_control_xon: 8649 rx_flow_control_xoff: 62072 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_long_byte_count: 8699356158 rx_csum_offload_good: 30212111 rx_csum_offload_errors: 0 rx_header_split: 10857552 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 rx_dma_failed: 0 tx_dma_failed: 0 I am running Ubuntu 12.04 with kernel 3.2.0-30-generic #48-Ubuntu SMP I have pinged every device on my internal network for about 24 hours, without packet loss. Also checked my router and my interface to the WAN, also no errors there. Does anyone have any clue?

  Read the article

• vSphere Promiscuous mode only receiving packets one way from network switch

  - by steve.lippert

  We have two network switches, a POE switch (SwitchA) to power our phones / users computers and a non-POE switch (SwitchB for the rest network.) Each switch is setup to do port mirroring to support our VoIP recording system. SwitchA does port mirroring on specific ports if we need to record a user. SwitchB mirrors one port to monitor our work at home users (Internet comes in from managed router, to switch, back out to our firewall.) These two port mirroring setups feed into one vmware vSphere 4.1 server, it has four total physical cards. The other two NICs feed into an unmanaged switch for connecting to the rest of the network. Once into the vSphere server all network ports go into a vSwitch, and then one of the servers (Windows 2008 R2) sniffs them out and does its thing. Everything is working fine and dandy from SwitchB. But on SwitchA we only receive one side of the VoIP packets (going out to the phone, nothing coming in from the phone). Troubleshooting steps I have taken so far: I hooked up my laptop to the monitor port on SwitchB and I see both sides of the packets. I swapped which network interface is plugged into the monitor port on SwitchA. Because everything feeds into one vSwitch / vNetwork and both sides of the conversation arrive just fine from SwitchB I believe everything is configured correctly on the vSphere server/guest. What could be causing one way packets to arrive on my guest machine from only one interface, but not the other? Could a bad cable be causing the problems from SwitchB?

  Read the article

• Many clients on a wireless AP for UDP broadcast packets

  - by distorteddisco

  I asked this question on StackOverflow and was directed over here, so I'd appreciate any advice. I'm deploying a smartphone application as part of a live music performance that depends on receiving UDP broadcast packets from a wireless access point. I'm guessing that between 20 and 50 clients will be connected at any one time. I'm aware that a maximum of 20 clients per access point is advised, but as the UDP broadcast packets are ground through the LAN, how would I be able to link multiple APs together? I'm looking for recommendations on a suitable AP for this. The actual data transmission rates are very low - only a few kB/s - as I'm just sending small messages to the smartphone apps, and there will be no WAN internet connection. I tried it with a few connected peers on an adhoc wireless connection without any problems, but ran into dropped packet issues on an old WRT54G running ddwrt, though it's in pretty rough shape. What's the best way to do this? I suppose I could limit concurrent wireless connections to 20 clients... but more would be nice. EDIT: I should also say that it's purely one-way communication; the smartphone application is only receiving broadcast packets, not sending anything.

  Read the article

• Network programming and Packets interactions.

  - by Eyla

  Greeting, This month I will start working on my master thesis. My thesis's subject is about network security. I need to deal with network interfaces and packets. I've used shappcap before to interact with packets but I'm not sure if C# is the most powerful language to deal with network programing and packets. I worked a bit with winshark and I saw how powerful it is and as you know winsharp is open source developed using C++. I'm not sure if I should use C# or C++ for network security programming and I want your through about the best language might be for network programming and packets interaction. should I use C#, C++, or java or some thing else? please give me your advice. Thank you,

  Read the article

• capturing dns packets using java

  - by rgksugan

  I want to log the websites visited in a system. So i decided to record the packets send by the system. I am using Jpcap API. I am able to record a lot of packets. Now what i want to do is i want to filter only DNS packets. I think that will be able to log the websites. I want a way to filter the DNS packets. How can I do it?

  Read the article

• Impact of Changing IP Address of Outgoing IP Packets From My Network

  - by iamrohitbanga

  If I modify the source ip address of all outgoing ip packets from my network to an ip address belonging to someone else (while ensuring that the checksum is correct) then what will happen. Assume that I have a public IP address connected by a point-to-point link to an ISP. Will the ISP check that the IP address in my IP packets is correct or will it just forward the packets. I believe that ISP should just forward the packets. what mechanisms are present in the Internet that prevent this from happening?

  Read the article

• TCP packets larger than 4 KB don't get a reply from Linux

  - by pts

  I'm running Linux 3.2.51 in a virtual machine (192.168.33.15). I'm sending Ethernet frames to it. I'm writing custom software trying to emulate a TCP peer, the other peer is Linux running in the virtual machine guest. I've noticed that TCP packets larger than about 4 KB are ignored (i.e. dropped without an ACK) by the Linux guest. If I decrease the packet size by 50 bytes, I get an ACK. I'm not sending new payload data until the Linux guest fully ACKs the previous one. I've increased ifconfig eth0 mtu 51000, and ping -c 1 -s 50000 goes through (from guest to my emulator) and the Linux guest gets a reply of the same size. I've also increased sysctl -w net.ipv4.tcp_rmem='70000 87380 87380 and tried with sysctl -w net.ipv4.tcp_mtu_probing=1 (and also =0). There is no IPv3 packet fragmentation, all packets have the DF flag set. It works the other way round: the Linux guest can send TCP packets of 6900 bytes of payload and my emulator understands them. This is very strange to me, because only TCP packets seem to be affected (large ICMP packets go through). Any idea what can be imposing this limit? Any idea how to do debug it in the Linux kernel? See the tcpdump -n -vv output below. tcpdump was run on the Linux guest. The last line is interesting: 4060 bytes of TCP payload is sent to the guest, and it doesn't get any reply packet from the Linux guest for half a minute. 14:59:32.000057 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [S], cksum 0x8da0 (correct), seq 10000000, win 14600, length 0 14:59:32.000086 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44) 192.168.33.15.22 > 192.168.33.1.36522: Flags [S.], cksum 0xc37f (incorrect -> 0x5999), seq 1415680476, ack 10000001, win 19920, options [mss 9960], length 0 14:59:32.000218 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0xa752 (correct), ack 1, win 14600, length 0 14:59:32.000948 IP (tos 0x10, ttl 64, id 53777, offset 0, flags [DF], proto TCP (6), length 66) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], cksum 0xc395 (incorrect -> 0xfa01), seq 1:27, ack 1, win 19920, length 26 14:59:32.001575 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0xa738 (correct), ack 27, win 14600, length 0 14:59:32.001585 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 65) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], cksum 0x48d6 (correct), seq 1:26, ack 27, win 14600, length 25 14:59:32.001589 IP (tos 0x10, ttl 64, id 53778, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.15.22 > 192.168.33.1.36522: Flags [.], cksum 0xc37b (incorrect -> 0x9257), ack 26, win 19920, length 0 14:59:32.001680 IP (tos 0x10, ttl 64, id 53779, offset 0, flags [DF], proto TCP (6), length 496) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], seq 27:483, ack 26, win 19920, length 456 14:59:32.001784 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0xa557 (correct), ack 483, win 14600, length 0 14:59:32.006367 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 1136) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], seq 26:1122, ack 483, win 14600, length 1096 14:59:32.044150 IP (tos 0x10, ttl 64, id 53780, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.15.22 > 192.168.33.1.36522: Flags [.], cksum 0xc37b (incorrect -> 0x8c47), ack 1122, win 19920, length 0 14:59:32.045310 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 312) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], seq 1122:1394, ack 483, win 14600, length 272 14:59:32.045322 IP (tos 0x10, ttl 64, id 53781, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.15.22 > 192.168.33.1.36522: Flags [.], cksum 0xc37b (incorrect -> 0x8b37), ack 1394, win 19920, length 0 14:59:32.925726 IP (tos 0x10, ttl 64, id 53782, offset 0, flags [DF], proto TCP (6), length 1112) 192.168.33.15.22 > 192.168.33.1.36522: Flags [.], seq 483:1555, ack 1394, win 19920, length 1072 14:59:32.925750 IP (tos 0x10, ttl 64, id 53784, offset 0, flags [DF], proto TCP (6), length 312) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], seq 1555:1827, ack 1394, win 19920, length 272 14:59:32.927131 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x9bcf (correct), ack 1555, win 14600, length 0 14:59:32.927148 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x9abf (correct), ack 1827, win 14600, length 0 14:59:32.932248 IP (tos 0x10, ttl 64, id 53785, offset 0, flags [DF], proto TCP (6), length 56) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], cksum 0xc38b (incorrect -> 0xd247), seq 1827:1843, ack 1394, win 19920, length 16 14:59:32.932366 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x9aaf (correct), ack 1843, win 14600, length 0 14:59:32.964295 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 104) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], seq 1394:1458, ack 1843, win 14600, length 64 14:59:32.964310 IP (tos 0x10, ttl 64, id 53786, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.15.22 > 192.168.33.1.36522: Flags [.], cksum 0xc37b (incorrect -> 0x85a7), ack 1458, win 19920, length 0 14:59:32.964561 IP (tos 0x10, ttl 64, id 53787, offset 0, flags [DF], proto TCP (6), length 88) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], seq 1843:1891, ack 1458, win 19920, length 48 14:59:32.965185 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x9a3f (correct), ack 1891, win 14600, length 0 14:59:32.965196 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 104) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], seq 1458:1522, ack 1891, win 14600, length 64 14:59:32.965233 IP (tos 0x10, ttl 64, id 53788, offset 0, flags [DF], proto TCP (6), length 88) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], seq 1891:1939, ack 1522, win 19920, length 48 14:59:32.965970 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x99cf (correct), ack 1939, win 14600, length 0 14:59:32.965979 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 568) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], seq 1522:2050, ack 1939, win 14600, length 528 14:59:32.966112 IP (tos 0x10, ttl 64, id 53789, offset 0, flags [DF], proto TCP (6), length 520) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], seq 1939:2419, ack 2050, win 19920, length 480 14:59:32.970059 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x95df (correct), ack 2419, win 14600, length 0 14:59:32.970089 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 616) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], seq 2050:2626, ack 2419, win 14600, length 576 14:59:32.981159 IP (tos 0x10, ttl 64, id 53790, offset 0, flags [DF], proto TCP (6), length 72) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], cksum 0xc39b (incorrect -> 0xa84f), seq 2419:2451, ack 2626, win 19920, length 32 14:59:32.982347 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x937f (correct), ack 2451, win 14600, length 0 14:59:32.982357 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 104) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], seq 2626:2690, ack 2451, win 14600, length 64 14:59:32.982401 IP (tos 0x10, ttl 64, id 53791, offset 0, flags [DF], proto TCP (6), length 88) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], seq 2451:2499, ack 2690, win 19920, length 48 14:59:32.982570 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x930f (correct), ack 2499, win 14600, length 0 14:59:32.982702 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 104) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], seq 2690:2754, ack 2499, win 14600, length 64 14:59:33.020066 IP (tos 0x10, ttl 64, id 53792, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.15.22 > 192.168.33.1.36522: Flags [.], cksum 0xc37b (incorrect -> 0x7e07), ack 2754, win 19920, length 0 14:59:33.983503 IP (tos 0x10, ttl 64, id 53793, offset 0, flags [DF], proto TCP (6), length 72) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], cksum 0xc39b (incorrect -> 0x2aa7), seq 2499:2531, ack 2754, win 19920, length 32 14:59:33.983810 IP (tos 0x10, ttl 64, id 53794, offset 0, flags [DF], proto TCP (6), length 88) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], seq 2531:2579, ack 2754, win 19920, length 48 14:59:33.984100 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x92af (correct), ack 2531, win 14600, length 0 14:59:33.984139 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x927f (correct), ack 2579, win 14600, length 0 14:59:34.022914 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 104) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], seq 2754:2818, ack 2579, win 14600, length 64 14:59:34.022939 IP (tos 0x10, ttl 64, id 53795, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.15.22 > 192.168.33.1.36522: Flags [.], cksum 0xc37b (incorrect -> 0x7d77), ack 2818, win 19920, length 0 14:59:34.023554 IP (tos 0x10, ttl 64, id 53796, offset 0, flags [DF], proto TCP (6), length 88) 192.168.33.15.22 > 192.168.33.1.36522: Flags [P.], seq 2579:2627, ack 2818, win 19920, length 48 14:59:34.027571 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.33.1.36522 > 192.168.33.15.22: Flags [.], cksum 0x920f (correct), ack 2627, win 14600, length 0 14:59:34.027603 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 4100) 192.168.33.1.36522 > 192.168.33.15.22: Flags [P.], seq 2818:6878, ack 2627, win 14600, length 4060

  Read the article

• DHCP reply packets do not make it into KVM instance in OpenStack

  - by Lorin Hochstein

  I'm running a KVM instance inside of OpenStack, and it isn't getting an IP address from the DHCP server. Using tcpdump, I can see the request and reply packets on vnet0 of the compute host: # tcpdump -i vnet0 -n port 67 or port 68 tcpdump: WARNING: vnet0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vnet0, link-type EN10MB (Ethernet), capture size 65535 bytes 19:44:56.176727 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:46:f6:11, length 300 19:44:56.176785 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:46:f6:11, length 300 19:44:56.177315 IP 10.40.0.1.67 > 10.40.0.3.68: BOOTP/DHCP, Reply, length 319 19:45:02.179834 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:46:f6:11, length 300 19:45:02.179904 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:46:f6:11, length 300 19:45:02.180375 IP 10.40.0.1.67 > 10.40.0.3.68: BOOTP/DHCP, Reply, length 319 However, if I do the same thing on eth0 inside the KVM instance, I only see the request packets, not the reply packets. What would prevent the packets from making it from vnet0 of the host to eth0 of the guest? My host is running Ubuntu 12.04 and my guest is running CentOS 6.3. Note that I have added this rule in my iptables, but it doesn't resolve the issue: -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill The instance corresponds to vnet0 and is connected via br100: # brctl show bridge name bridge id STP enabled interfaces br100 8000.54781a8605f2 no eth1 vnet0 vnet1 virbr0 8000.000000000000 yes Here's the full iptables-save: # Generated by iptables-save v1.4.12 on Tue Apr 2 19:47:27 2013 *nat :PREROUTING ACCEPT [8323:2553683] :INPUT ACCEPT [7993:2494942] :OUTPUT ACCEPT [6158:461050] :POSTROUTING ACCEPT [6455:511595] :nova-compute-OUTPUT - [0:0] :nova-compute-POSTROUTING - [0:0] :nova-compute-PREROUTING - [0:0] :nova-compute-float-snat - [0:0] :nova-compute-snat - [0:0] :nova-postrouting-bottom - [0:0] -A PREROUTING -j nova-compute-PREROUTING -A OUTPUT -j nova-compute-OUTPUT -A POSTROUTING -j nova-compute-POSTROUTING -A POSTROUTING -j nova-postrouting-bottom -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE -A nova-compute-snat -j nova-compute-float-snat -A nova-postrouting-bottom -j nova-compute-snat COMMIT # Completed on Tue Apr 2 19:47:27 2013 # Generated by iptables-save v1.4.12 on Tue Apr 2 19:47:27 2013 *mangle :PREROUTING ACCEPT [7969:5385812] :INPUT ACCEPT [7905:5363718] :FORWARD ACCEPT [158:48190] :OUTPUT ACCEPT [6877:8647975] :POSTROUTING ACCEPT [7035:8696165] -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill COMMIT # Completed on Tue Apr 2 19:47:27 2013 # Generated by iptables-save v1.4.12 on Tue Apr 2 19:47:27 2013 *filter :INPUT ACCEPT [2196774:15856921923] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [2447201:1170227646] :nova-compute-FORWARD - [0:0] :nova-compute-INPUT - [0:0] :nova-compute-OUTPUT - [0:0] :nova-compute-inst-19 - [0:0] :nova-compute-inst-20 - [0:0] :nova-compute-local - [0:0] :nova-compute-provider - [0:0] :nova-compute-sg-fallback - [0:0] :nova-filter-top - [0:0] -A INPUT -j nova-compute-INPUT -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A FORWARD -j nova-filter-top -A FORWARD -j nova-compute-FORWARD -A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT -A FORWARD -i virbr0 -o virbr0 -j ACCEPT -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A OUTPUT -j nova-filter-top -A OUTPUT -j nova-compute-OUTPUT -A nova-compute-FORWARD -i br100 -j ACCEPT -A nova-compute-FORWARD -o br100 -j ACCEPT -A nova-compute-inst-19 -m state --state INVALID -j DROP -A nova-compute-inst-19 -m state --state RELATED,ESTABLISHED -j ACCEPT -A nova-compute-inst-19 -j nova-compute-provider -A nova-compute-inst-19 -s 10.40.0.1/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT -A nova-compute-inst-19 -s 10.40.0.0/16 -j ACCEPT -A nova-compute-inst-19 -p tcp -m tcp --dport 22 -j ACCEPT -A nova-compute-inst-19 -p icmp -j ACCEPT -A nova-compute-inst-19 -j nova-compute-sg-fallback -A nova-compute-inst-20 -m state --state INVALID -j DROP -A nova-compute-inst-20 -m state --state RELATED,ESTABLISHED -j ACCEPT -A nova-compute-inst-20 -j nova-compute-provider -A nova-compute-inst-20 -s 10.40.0.1/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT -A nova-compute-inst-20 -s 10.40.0.0/16 -j ACCEPT -A nova-compute-inst-20 -p tcp -m tcp --dport 22 -j ACCEPT -A nova-compute-inst-20 -p icmp -j ACCEPT -A nova-compute-inst-20 -j nova-compute-sg-fallback -A nova-compute-local -d 10.40.0.3/32 -j nova-compute-inst-19 -A nova-compute-local -d 10.40.0.4/32 -j nova-compute-inst-20 -A nova-compute-sg-fallback -j DROP -A nova-filter-top -j nova-compute-local COMMIT # Completed on Tue Apr 2 19:47:27 2013

  Read the article

• Route packets from one VPN to another

  - by Mike

  I have two OpenVPN servers (10.8.0.0 and 10.9.0.0) set up on my OpenSUSE server. Within one network, each computer is visible to any other one, but I'd like to make it so that computers are visible across networks. I'd like to route the packets like this: when a user (say 10.8.0.6) pings an address on the other VPN (10.9.0.6), the packets are routed to the 10.9.0.1 and then to the appropriate computer in this VPN. How do I achieve this using iptables or a different tool? I tried the commands at the end of this section with no avail.

  Read the article

• Packets marked INVALID in FORWARD rule

  - by Raphink

  I have a firewall that has 3 IP aliases on 1 physical interface. Packets get dropped between these 3 interfaces (either ICMP, HTTP, or anything else). We tracked it down to these packets being marked INVALID in the FORWARD rule and dropped due to the this rule: chain FORWARD { policy DROP; # connection tracking mod state state INVALID LOG log-prefix 'INVALID FORWARD DROP: '; mod state state INVALID DROP; mod state state (ESTABLISHED RELATED) ACCEPT; } (That is, we see the INVALID FORWARD DROP logs in dmesg) What could be causing this?

  Read the article

• When I ping Internet addresses like yahoo or Google, I get 2 reply packets and 2 lost packets.

  - by navi

  I have Airtel broadband and a Tata broadband connection. i have around 50 PCs connecting through an airtel broadband connection. Both are dsl connections with my phone line going into dsl modems and an Ethernet cable going from dsl modem directly into a switch. Currently, only airtel connection is connected with static IP on my private lan and using the airtel ISP DNS servers as DNS IP address and the default gateway is 192.168.1.1 (IP add. of the dsl modem). All PCs are connected in a work group. When in full use, my users complain of certain web pages are not opening. When I ping Internet addresses like Yahoo or Google I get 2 reply packets and 2 lost packets. I suspect that a single broadband connection is not able to sustain 50 simultaneous downloads/browsing. Is there any device which connect to both DSL and make one line so that its give me high speed simultaneous browsing. Help needed urgently. Thank you all to those who reply.

  Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >