Search Results

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

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

• How does Router know where to forward packet

  - by kornelijepetak

  If several computers with local addresses (192.168.0.#) are connected to a router and each computer opens a web browser and requests a page over HTTP, when these TCP:80 packets are sent out, the router switches the local address with the static IP of the router (i.e. Provider given IP) so the server can reply to the appropriate address. But how does the router know to which computer to forward the HTTP reply, since the TCP header does not contain the local IP address (does it?), and all computers are using port 80? Does this have anything to do with the MAC addresses? How exactly does this work?

  Read the article

• wireshark not seeing all packets on WiFi

  - by Caffeine Coma

  I'm using Wireshark on OSX, trying to sniff my home network over WiFi. While I can see packets that are sent to/from the host I'm sniffing on, I'm not seeing anything else that goes over the WiFi. It's like I'm not in promiscuous mode or something (the promiscuous mode box is in fact checked). The router is an Apple Airport Extreme, protected by WPA2. I'm attached to the network I'm trying to sniff, so I'm confused about why I can't see other traffic. Edit: I solved this by the following: Plug Macbook directly into the Airport Extreme router Enable "internet sharing" on Macbook, with no password. Bind wireless device (the one I wanted to sniff) to the WiFi hotspot generated by Internet sharing in step 2. Run Wireshark on the Macbook, bound to device en1. Don't forget to disable sharing after you're done. :-)

  Read the article

• length of captured packets more than MTU

  - by kumar

  Hi, I m running iperf between two machines (linux) and I can observe the mtu of both the interfaces connected is 1500. I ran tcpdump to capture packets and I observed some packets have "length as 2962"....how come this is possible with mtu as only 1500? Please clarify. Thanks! Note: flags field is set as DF. and proto is TCP

  Read the article

• Flow of packets in network

  - by user58859

  I can't visualize in my mind the network traffic flow. eg. If there are 15 pc's in a LAN When packet goes from router to local LAN, do it passes all the computers? Does it go to the ethernet card of every computer and those computers accept the packet based on their physical address? To which pc the packet will go first? To the nearest to the router? What happens if that first pc captures that packet(though it is not for it)? What happens when a pc broadcast a message? Do it have to generate 14 packets for all the pc's or only one packet reach to all pc's? If it is one packet and captured by first pc, how other pc's can get that? I can't imagine how this traffic is exactly flows? May be my analogy is completely wrong. Can anybody explain me this?

  Read the article

• Sniff packets using tcpdump

  - by denisk

  I have a completely noob question. I want to see all packets that come to my computer from particular site (google.com). So I start tcpdump sudo tcpdump -i eth0 host google.com and enter google.com in a browser and hit enter - nothing gets captured. I can't figure out why it happen. What do I do wrong? Edit It appeared that I was listening to the wrong interface. I had changed eth0 to any and it worked. It was ppp1 that needed listening. Thanks for your answers!

  Read the article

• Why are some UDP packets getting blocked?

  - by Tom

  In our organization, we have two test machines running Windows XP. While attempting to test a roll-my-own UDP message server, I found that both could receive small messages (under 2k) just fine. However, when I test sending large packets to both of these machines, one receives them fine, while the other can't receive them at all. Both machines have SP3 and both have their Windows Firewall shut off, but one still isn't working. Can anyone tell me where to look for anything that might be blocking or limiting the packet size on a Windows Machine? Thanks.

  Read the article

• Port forwarding with DNAT and SNAT without touching other packets

  - by w00t

  I have a Linux gateway with iptables which does routing and port forwarding. I want the port forwarding to happen independent of the routing. To port forward, I add this to the nat table: iptables -t nat -A "$PRE" -p tcp -d $GW --dport $fromPort -j DNAT --to-destination $toHost:$toPort iptables -t nat -A "$POST" -p tcp -d $toHost --dport $toPort -j SNAT --to $SRC $PRE and POST are actually destination-specific chains that I jump to from the PREROUTING and POSTROUTING chains respectively so I can keep the iptables clean. $SRC is the IP address I'm SNATing to which is different from the gateway IP $GW. The problem with this setup is that regular routed packets that were not DNATed but happen to go to the same $toHost:$toPort combo will also be SNATed. I wish to avoid this. Any clever things I can do?

  Read the article

• Mark packets across computers?

  - by eudemo

  I use Transmission on Ubuntu and I'm having this issue, which basically says that QoS is broken because there is no way to limit which outgoing ports uses. I was thinking of doing a dirty and ugly hack and create an interface alias and define QoS based on source address, but was wondering if is there another way. Is it possible to mark the packets on the original machine in some way, using the owner and mark modules of iptables and sending this to the router who does the QoS? From what I understand, mark on iptables only applies to the local machine, so this will not work, but is there another way?

  Read the article

• Stop sending packets to private IPs

  - by SlasherZ

  I have a problem that my server got locked down because it was sending packets to private IPs. My question is, what is the best solution to stop that? Here is the log that I got from my hosting provider: [Mon Jun 2 00:04:36 2014] forward-to-private:IN=br0 OUT=br0 PHYSIN=vm-44487.0 PHYSOUT=eth0 MAC=78:fe:3d:47:3d:20:00:1c:14:01:4e:cd:08:00 SRC=78.46.198.21 DST=192.168.249.128 LEN=1454 TOS=0x00 PREC=0x00 TTL=64 ID=58859 DF PROTO=UDP SPT=41366 DPT=41234 LEN=1434 [Mon Jun 2 00:17:15 2014] forward-to-private:IN=br0 OUT=br0 PHYSIN=vm-44487.0 PHYSOUT=eth0 MAC=78:fe:3d:47:3d:20:00:1c:14:01:4e:cd:08:00 SRC=78.46.198.21 DST=192.168.249.128 LEN=1456 TOS=0x00 PREC=0x00 TTL=64 ID=52234 DF PROTO=UDP SPT=55430 DPT=41234 LEN=1436

  Read the article

• Mirror network packets from WiFi to Ethernet in an ASUS Router RT N53

  - by fazineroso

  I have an ASUS RT N53 router, running the default firmware (Linux 2.6.22 with busybox and uclibc). I need to capture data packets from some Wi-Fi devices I have connected to that router (iPad and some smartphones), but the router is not forwarding any package coming from Wi-Fi devices to the Ethernet Ports. Any idea how can I proceed? Available tools in the router are iptables (no tee option, though), ebtables, brctl... Currently the ethernet and Wifi devices are forming a bridge: # brctl show bridge name bridge id STP enabled interfaces br0 8000.50465dc06be2 no vlan0 eth1 No ebtables rules: # ebtables -L Bridge table: filter Bridge chain: INPUT, entries: 0, policy: ACCEPT Bridge chain: FORWARD, entries: 0, policy: ACCEPT Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

  Read the article

• Multiple network interfaces and UDP packets distribution

  - by Robert Kubrick

  I have a Linux server with 2 1Gb network interfaces eth1 and eth2. If I start 2 clients listening to the same multicast address and each client connects through a different NIC (say client 1 listens to the multicast through eth1 and client 2 through eth2), then client 2 gets duplicate UDP packets. If both clients use the same interface eth1 on the other hand, both clients work fine. I have already tried to set arp_filter and proxy_arp to 1 (arp flux issue) but it hasn't solved the issue. Is this a Linux kernel problem? Or is there another way to setup the interfaces correctly?

  Read the article

• Linux router: ping doesn't route back

  - by El Barto

  I have a Debian box which I'm trying to set up as a router and an Ubuntu box which I'm using as a client. My problem is that when the Ubuntu client tries to ping a server on the Internet, all the packets are lost (though, as you can see below, they seem to go to the server and back without problem). I'm doing this in the Ubuntu Box: # ping -I eth1 my.remote-server.com PING my.remote-server.com (X.X.X.X) from 10.1.1.12 eth1: 56(84) bytes of data. ^C --- my.remote-server.com ping statistics --- 13 packets transmitted, 0 received, 100% packet loss, time 12094ms (I changed the name and IP of the remote server for privacy). From the Debian Router I see this: # tcpdump -i eth1 -qtln icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 7, length 64 IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 8, length 64 IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 8, length 64 IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 9, length 64 IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 9, length 64 IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 10, length 64 IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 10, length 64 IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 11, length 64 IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 11, length 64 ^C 9 packets captured 9 packets received by filter 0 packets dropped by kernel # tcpdump -i eth2 -qtln icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 213, length 64 IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 213, length 64 IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 214, length 64 IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 214, length 64 IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 215, length 64 IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 215, length 64 IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 216, length 64 IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 216, length 64 IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 217, length 64 IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 217, length 64 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel And at the remote server I see this: # tcpdump -i eth0 -qtln icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 1, length 64 IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 1, length 64 IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 2, length 64 IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 2, length 64 IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 3, length 64 IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 3, length 64 IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 4, length 64 IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 4, length 64 IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 5, length 64 IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 5, length 64 IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 6, length 64 IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 6, length 64 IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 7, length 64 IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 7, length 64 IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 8, length 64 IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 8, length 64 IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 9, length 64 IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 9, length 64 18 packets captured 228 packets received by filter 92 packets dropped by kernel Here "X.X.X.X" is my remote server's IP and "Y.Y.Y.Y" is my local network's public IP. So, what I understand is that the ping packets are coming out of the Ubuntu box (10.1.1.12), to the router (10.1.1.1), from there to the next router (192.168.1.1) and reaching the remote server (X.X.X.X). Then they come back all the way to the Debian router, but they never reach the Ubuntu box back. What am I missing? Here's the Debian router setup: # ifconfig eth1 Link encap:Ethernet HWaddr 94:0c:6d:82:0d:98 inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::960c:6dff:fe82:d98/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:105761 errors:0 dropped:0 overruns:0 frame:0 TX packets:48944 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:40298768 (38.4 MiB) TX bytes:44831595 (42.7 MiB) Interrupt:19 Base address:0x6000 eth2 Link encap:Ethernet HWaddr 6c:f0:49:a4:47:38 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::6ef0:49ff:fea4:4738/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:38335992 errors:0 dropped:0 overruns:0 frame:0 TX packets:37097705 errors:0 dropped:0 overruns:0 carrier:1 collisions:0 txqueuelen:1000 RX bytes:4260680226 (3.9 GiB) TX bytes:3759806551 (3.5 GiB) Interrupt:27 eth3 Link encap:Ethernet HWaddr 94:0c:6d:82:c8:72 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:20 Base address:0x2000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3408 errors:0 dropped:0 overruns:0 frame:0 TX packets:3408 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:358445 (350.0 KiB) TX bytes:358445 (350.0 KiB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:2767779 errors:0 dropped:0 overruns:0 frame:0 TX packets:1569477 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:3609469393 (3.3 GiB) TX bytes:96113978 (91.6 MiB) # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 127.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 lo 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth2 10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth2 # arp -n # Note: Here I have changed all the different MACs except the ones corresponding to the Ubuntu box (on 10.1.1.12 and 192.168.1.12) Address HWtype HWaddress Flags Mask Iface 192.168.1.118 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.72 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.94 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.102 ether NN:NN:NN:NN:NN:NN C eth2 10.1.1.12 ether 00:1e:67:15:2b:f0 C eth1 192.168.1.86 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.2 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.61 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.64 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.116 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.91 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.52 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.93 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.87 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.92 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.100 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.40 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.53 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.1 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.83 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.89 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.12 ether 00:1e:67:15:2b:f1 C eth2 192.168.1.77 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.66 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.90 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.65 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.41 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.78 ether NN:NN:NN:NN:NN:NN C eth2 192.168.1.123 ether NN:NN:NN:NN:NN:NN C eth2 # iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination # iptables -L -n -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 10.1.1.0/24 !10.1.1.0/24 MASQUERADE all -- !10.1.1.0/24 10.1.1.0/24 Chain OUTPUT (policy ACCEPT) target prot opt source destination And here's the Ubuntu box: # ifconfig eth0 Link encap:Ethernet HWaddr 00:1e:67:15:2b:f1 inet addr:192.168.1.12 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::21e:67ff:fe15:2bf1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:28785139 errors:0 dropped:0 overruns:0 frame:0 TX packets:19050735 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:32068182803 (32.0 GB) TX bytes:6061333280 (6.0 GB) Interrupt:16 Memory:b1a00000-b1a20000 eth1 Link encap:Ethernet HWaddr 00:1e:67:15:2b:f0 inet addr:10.1.1.12 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::21e:67ff:fe15:2bf0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:285086 errors:0 dropped:0 overruns:0 frame:0 TX packets:12719 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:30817249 (30.8 MB) TX bytes:2153228 (2.1 MB) Interrupt:16 Memory:b1900000-b1920000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:86048 errors:0 dropped:0 overruns:0 frame:0 TX packets:86048 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11426538 (11.4 MB) TX bytes:11426538 (11.4 MB) # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 10.1.1.1 0.0.0.0 UG 100 0 0 eth1 10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.8.0.0 192.168.1.10 255.255.255.0 UG 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 # arp -n # Note: Here I have changed all the different MACs except the ones corresponding to the Debian box (on 10.1.1.1 and 192.168.1.10) Address HWtype HWaddress Flags Mask Iface 192.168.1.70 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.90 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.97 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.103 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.13 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.120 (incomplete) eth0 192.168.1.111 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.118 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.51 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.102 (incomplete) eth0 192.168.1.64 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.52 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.74 (incomplete) eth0 192.168.1.94 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.121 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.72 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.87 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.91 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.71 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.78 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.83 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.88 (incomplete) eth0 192.168.1.82 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.98 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.100 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.93 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.73 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.11 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.85 (incomplete) eth0 192.168.1.112 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.89 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.65 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.81 ether NN:NN:NN:NN:NN:NN C eth0 10.1.1.1 ether 94:0c:6d:82:0d:98 C eth1 192.168.1.53 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.116 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.61 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.10 ether 6c:f0:49:a4:47:38 C eth0 192.168.1.86 (incomplete) eth0 192.168.1.119 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.66 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.1 ether NN:NN:NN:NN:NN:NN C eth0 192.168.1.1 ether NN:NN:NN:NN:NN:NN C eth1 192.168.1.92 ether NN:NN:NN:NN:NN:NN C eth0 # iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination # iptables -L -n -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination Edit: Following Patrick's suggestion, I did a tcpdump con the Ubuntu box and I see this: # tcpdump -i eth1 -qtln icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 1, length 64 IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 1, length 64 IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 2, length 64 IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 2, length 64 IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 3, length 64 IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 3, length 64 IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 4, length 64 IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 4, length 64 IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 5, length 64 IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 5, length 64 IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 6, length 64 IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 6, length 64 ^C 12 packets captured 12 packets received by filter 0 packets dropped by kernel So the question is: if all packets seem to be coming and going, why does ping report 100% packet loss?

  Read the article

• KVM/Libvirt bridged/routed networking not working on newer guest kernels

  - by SharkWipf

  I have a dedicated server running Debian 6, with Libvirt (0.9.11.3) and Qemu-KVM (qemu-kvm-1.0+dfsg-11, Debian). I am having a problem getting bridged/routed networking to work in KVM guests with newer kernels (2.6.38). NATted networking works fine though. Older kernels work perfectly fine as well. The host kernel is at version 3.2.0-2-amd64, the problem was also there on an older host kernel. The contents of the host's /etc/network/interfaces (ip removed): # Loopback device: auto lo iface lo inet loopback # bridge auto br0 iface br0 inet static address 176.9.xx.xx broadcast 176.9.xx.xx netmask 255.255.255.224 gateway 176.9.xx.xx pointopoint 176.9.xx.xx bridge_ports eth0 bridge_stp off bridge_maxwait 0 bridge_fd 0 up route add -host 176.9.xx.xx dev br0 # VM IP post-up mii-tool -F 100baseTx-FD br0 # default route to access subnet up route add -net 176.9.xx.xx netmask 255.255.255.224 gw 176.9.xx.xx br0 The output of ifconfig -a on the host: br0 Link encap:Ethernet HWaddr 54:04:a6:8a:66:13 inet addr:176.9.xx.xx Bcast:176.9.xx.xx Mask:255.255.255.224 inet6 addr: fe80::5604:a6ff:fe8a:6613/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20216729 errors:0 dropped:0 overruns:0 frame:0 TX packets:19962220 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:14144528601 (13.1 GiB) TX bytes:7990702656 (7.4 GiB) eth0 Link encap:Ethernet HWaddr 54:04:a6:8a:66:13 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:26991788 errors:0 dropped:12066 overruns:0 frame:0 TX packets:19737261 errors:270082 dropped:0 overruns:0 carrier:270082 collisions:1686317 txqueuelen:1000 RX bytes:15459970915 (14.3 GiB) TX bytes:6661808415 (6.2 GiB) Interrupt:17 Memory:fe500000-fe520000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:6240133 errors:0 dropped:0 overruns:0 frame:0 TX packets:6240133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:6081956230 (5.6 GiB) TX bytes:6081956230 (5.6 GiB) virbr0 Link encap:Ethernet HWaddr 52:54:00:79:e4:5a inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:225016 errors:0 dropped:0 overruns:0 frame:0 TX packets:412958 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16284276 (15.5 MiB) TX bytes:687827984 (655.9 MiB) virbr0-nic Link encap:Ethernet HWaddr 52:54:00:79:e4:5a BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) vnet0 Link encap:Ethernet HWaddr fe:54:00:93:4e:68 inet6 addr: fe80::fc54:ff:fe93:4e68/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:607670 errors:0 dropped:0 overruns:0 frame:0 TX packets:5932089 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:83574773 (79.7 MiB) TX bytes:1092482370 (1.0 GiB) vnet1 Link encap:Ethernet HWaddr fe:54:00:ed:6a:43 inet6 addr: fe80::fc54:ff:feed:6a43/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:922132 errors:0 dropped:0 overruns:0 frame:0 TX packets:6342375 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:251091242 (239.4 MiB) TX bytes:1629079567 (1.5 GiB) vnet2 Link encap:Ethernet HWaddr fe:54:00:0d:cb:3d inet6 addr: fe80::fc54:ff:fe0d:cb3d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9461 errors:0 dropped:0 overruns:0 frame:0 TX packets:665189 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:4990275 (4.7 MiB) TX bytes:49229647 (46.9 MiB) vnet3 Link encap:Ethernet HWaddr fe:54:cd:83:eb:aa inet6 addr: fe80::fc54:cdff:fe83:ebaa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1649 errors:0 dropped:0 overruns:0 frame:0 TX packets:12177 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:77233 (75.4 KiB) TX bytes:2127934 (2.0 MiB) The guest's /etc/network/interfaces, in this case running Ubuntu 12.04 (ip removed): # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 176.9.xx.xx netmask 255.255.255.248 gateway 176.9.xx.xx # Host IP pointopoint 176.9.xx.xx # Host IP dns-nameservers 8.8.8.8 8.8.4.4 The output of ifconfig -a on the guest: eth0 Link encap:Ethernet HWaddr 52:54:cd:83:eb:aa inet addr:176.9.xx.xx Bcast:0.0.0.0 Mask:255.255.255.255 inet6 addr: fe80::5054:cdff:fe83:ebaa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14190 errors:0 dropped:0 overruns:0 frame:0 TX packets:1768 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2614642 (2.6 MB) TX bytes:82700 (82.7 KB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:954 errors:0 dropped:0 overruns:0 frame:0 TX packets:954 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:176679 (176.6 KB) TX bytes:176679 (176.6 KB) Output of ping -c4 on the guest: PING google.nl (173.194.35.151) 56(84) bytes of data. 64 bytes from muc03s01-in-f23.1e100.net (173.194.35.151): icmp_req=1 ttl=55 time=14.7 ms From static.174.82.xx.xx.clients.your-server.de (176.9.xx.xx): icmp_seq=2 Redirect Host(New nexthop: static.161.82.9.176.clients.your-server.de (176.9.82.161)) 64 bytes from muc03s01-in-f23.1e100.net (173.194.35.151): icmp_req=2 ttl=55 time=15.1 ms From static.198.170.9.176.clients.your-server.de (176.9.170.198) icmp_seq=3 Destination Host Unreachable From static.198.170.9.176.clients.your-server.de (176.9.170.198) icmp_seq=4 Destination Host Unreachable --- google.nl ping statistics --- 4 packets transmitted, 2 received, +2 errors, 50% packet loss, time 3002ms rtt min/avg/max/mdev = 14.797/14.983/15.170/0.223 ms, pipe 2 The static.174.82.xx.xx.clients.your-server.de (176.9.xx.xx) is the host's IP. I have encountered this problem with every guest OS I've tried, that being Fedora, Ubuntu (server/desktop) and Debian with an upgraded kernel. I've also tried compiling the guest kernel myself, to no avail. I have no problem with recompiling a kernel, though the host cannot afford any downtime. Any ideas on this problem are very welcome. EDIT: I can ping the host from inside the guest.

  Read the article

• Cisco ASA: Routing packets based on where the connections started from

  - by DrStalker

  We have a Cisco ASA 5505 (version 8.2(2)) with three interfaces: outside: IP address 11.11.11.11, this is the default route inside: IP address 10.1.1.1, this is the local subnet newlink: 22.22.22.22, this is a new internet connection. We need to move VPN users from the 11.11.11.11 address to the 22.22.22.22 address, and we're using SSH on the ASA as to test and sort out the routing. The problem we have is this: If we define a particular IP as being on a static route out the newlink interface then it can SSH to 22.22.22.22 fine. If we do not define a static route then the traffic hits the ASA, but the return traffic does not come back over newlink; presumably it gets sent over the outside interfcae as that is the default route. We can't define a static route for each remote endpoint because there are dialup VPN users, who obviously change IP a lot What we need to do is configure the ASA so if a connection comes in on the newlink interface then the outgoing packets for that go over the newlink interface, not the default route. With iptables this should be do-able by marking the connection and doing mark-routing, but what is the equivalent for a Cisco ASA?

  Read the article

• Cisco Catalyst 3750 connected to Cisco ASA 5505 and dropping packets

  - by Bo102010

  (Cross posted from Super User per suggestion there) At the office, I have inherited a network that I am still trying to fully comprehend. I have a problem today with a new connection between: A port on a Cisco Catalyst 3750 [WS-C3750G-48TS-S running C3750-IPSERVICESK9-M version 12.2(53)SE1] A port on a Cisco ASA 5505 [ASA Software version 8.3(2)] The 3750 is home to a Vlan that has a few ports assigned to it. interface Vlan3 description Internal network (172.18.160.0/24) ip address 172.18.160.1 255.255.255.0 I have a host (outside of my control) that needs to be in this VLAN (i.e it must have an address 172.18.160.something/24) that also needs to access the Internet. To accomplish this, I ran a link from the Catalyst (Gi1/0/13) to the ASA (Ethernet 0/5). I configured the Catalyst port like so: interface GigabitEthernet1/0/13 description To ASA, 172.18.160.69 switchport access vlan 3 switchport mode access speed 100 duplex full I configured the ASA like so: interface Vlan1 nameif inside security-level 100 ip address 172.18.160.69 255.255.255.0 interface Ethernet0/5 speed 100 duplex full Then I plugged the host into Ethernet 0/4 on the ASA and instructed its owner to make its default gateway 172.18.160.69. I made a NAT rule in the ASA and set up some rules, and it's able to access the Internet without issue. However, I noticed that the Catalyst reports a ton of packets being dropped toward the ASA. Catalyst3750#show interfaces GigabitEthernet 1/0/13 | include counters|drops Last clearing of "show interface" counters 00:28:13 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 136909347 This is a huge number of drops, since there's not much traffic on this VLAN at all. I tried these things: Make sure speed and duplex agree on both sides (100 Mbps / Full) Set no cdp enable on the Catalyst Gi10/13 Set no keepalive on the Catalyst Gi10/13 Checked for excessive CPU usage on both Checked for excessive traffic on both Am I missing something? Any help would be appreciated.

  Read the article

• Weird PCI bug: lots of missed packets, or data comes in "bursts"

  - by Thomas O

  I have an ABIT KN9 motherboard. It has one PCI-e x16 slot, three PCI-e x4 slots and two legacy PCI. My problem is with the legacy PCI (which I shall just call "PCI".) I currently have an Nvidia GeForce 8600 GT (a low end card) installed in the x16 slot and a TV card in PCI #1; the x4 slots are unused, as is PCI #2. I plan to upgrade the graphics card soon, the current card was spare. I sometimes install a USB expander in PCI #2 but it causes a lot of problems - see below. The problem is under Linux (Ubuntu 10.10, Linux 2.6.35-22-generic), but probably under all operating systems (I have not yet been able to test Windows, but I suspect it will do the same as the problems occur on the BIOS/POST side too, e.g. when using a USB keyboard on the expander the keyboard will not work at all) PCI has an enourmous delay, and packets arrive in large chunks. For example, when using the USB expander, my USB mouse lags and jumps in large steps every second or so, while using the motherboard USB does not present this problem. My TV card will only do one or two frames per second, and the program (xawtv) usually times out and crashes. In dmesg, I'm getting messages like: bttv0: timeout: drop=74, irq=154/100476, risc=31f6256c, bits: VSYNC HSYNC OFLOW RISCI for my TV card, and similar timeout issues for my USB expander with a mouse. I received the motherboard, processor and RAM second hand and have only just got around to building it, so I don't know if this problem has always existed, or if it's a result of my set up. If anyone has any hints or solutions it would be appreciated - this is kind of a show-stopper for me.

  Read the article

• Packets being dropped by iptables

  - by Shadyabhi

  I am trying to create a Software Access Point in linux. I followed the blog here. Steps I performed: Started dhcp server on wlan0. Properly configured hostapd.conf Enabled packet forwarding & masquerading. Two commands executed regarding iptables: iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE iptables --append FORWARD --in-interface wlan0 -j ACCEPT I enabled logging on iptables & I get this in everything.log Jun 29 19:42:03 MBP-archlinux kernel: [10480.180356] IN=eth0 OUT=wlan0 MAC=c8:bc:c8:9b:c4:3c:00:13:80:40:cd:80:08:00 SRC=195.143.92.150 DST=10.0.0.3 LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=38025 PROTO=TCP SPT=80 DPT=53570 WINDOW=46185 RES=0x00 ACK URGP=0 Jun 29 19:42:03 MBP-archlinux kernel: [10480.389102] IN=eth0 OUT=wlan0 MAC=c8:bc:c8:9b:c4:3c:00:13:80:40:cd:80:08:00 SRC=195.143.92.150 DST=10.0.0.3 LEN=308 TOS=0x00 PREC=0x00 TTL=52 ID=14732 PROTO=TCP SPT=80 DPT=53570 WINDOW=46185 RES=0x00 ACK PSH URGP=0 Jun 29 19:42:03 MBP-archlinux kernel: [10480.389710] IN=eth0 OUT=wlan0 MAC=c8:bc:c8:9b:c4:3c:00:13:80:40:cd:80:08:00 SRC=195.143.92.150 DST=10.0.0.3 LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=14988 PROTO=TCP SPT=80 DPT=53570 WINDOW=46185 RES=0x00 ACK FIN URGP=0 Jun 29 19:42:03 MBP-archlinux kernel: [10480.621118] IN=eth0 OUT=wlan0 MAC=c8:bc:c8:9b:c4:3c:00:13:80:40:cd:80:08:00 SRC=195.143.92.150 DST=10.0.0.3 LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=63378 PROTO=TCP SPT=80 DPT=53570 WINDOW=46185 RES=0x00 ACK FIN URGP=0 I have almost no knowledge of iptables, all I did was through googling. So, can anyone help me in making me understand what wrong is happening here? I have tried running tcpdump on wlan0 & http packets are being sent from wlan0.

  Read the article

• Website latency and bad tcp packets

  - by Mistero Lupo

  I have multiple websites hosted on a Linode VPS and I'm having an issue with one of them: every page that I try to load has about 10 seconds latency. Apache logs are clean and the other websites on the same machine are running well. At a first glance I tought it was a memory problem since the VPS has got only 512M, but from the linode dashboard CPU and Disk I/O are normal. Anyway here we have the ram status: $ free -m total used free shared buffers cached Mem: 487 463 23 0 2 55 -/+ buffers/cache: 404 82 Swap: 255 155 100 Only 23M free, but if it was a memory problem why other websites are going as usual? I took a live capture with wireshark, and there are some duplicates SYN ACK packets just before the 10 seconds gap. I'm out of ideas, looking for some clues. Wireshark live capture screenshot As you can see from the image, the gap is after the last bad tcp. Thank you in advance. UPDATE I've checked Apache2 logs in debug error level, and this is where something is appening: 151.97.156.191 - - [14/Nov/2012:11:19:40 +0100] [www.fmaisi.it/sid#7f32c625a220][rid#7f32c6801578/subreq] (3) [perdir /home/fmaisi/sites/www.fmaisi.it/public_html/] applying pattern '^index\.php$' to uri 'index.php' 151.97.156.191 - - [14/Nov/2012:11:19:40 +0100] [www.fmaisi.it/sid#7f32c625a220][rid#7f32c6801578/subreq] (1) [perdir /home/fmaisi/sites/www.fmaisi.it/public_html/] pass through /home/fmaisi/sites/www.fmaisi.it/public_html/index.php 151.97.156.191 - - [14/Nov/2012:11:19:54 +0100] [www.fmaisi.it/sid#7f32c625a220][rid#7f32c6537c78/initial] (3) [perdir /home/fmaisi/sites/www.fmaisi.it/public_html/] strip per-dir prefix: /home/fmaisi/sites/www.fmaisi.it/public_html/wp-content/plugins/wp-filebase/wp-filebase_css.php -> wp-content/plugins/wp-filebase/wp-filebase_css.php 151.97.156.191 - - [14/Nov/2012:11:19:54 +0100] [www.fmaisi.it/sid#7f32c625a220][rid#7f32c6537c78/initial] (3) [perdir /home/fmaisi/sites/www.fmaisi.it/public_html/] applying pattern '^index\.php$' to uri 'wp-content/plugins/wp-filebase/wp-filebase_css.php' As you can see there is a gap of 14 seconds after the pass through of index.php. Any suggestions? I'm out of ideas again.

  Read the article

• Flush kernel's TCP buffer with `MSG_MORE`-flagged packets

  - by timn

  send()'s man page reveals the MSG_MORE flag which is asserted to act like TCP_CORK. I have a wrapper function around send(): int SocketConnection_Write(SocketConnection *this, void *buf, int len) { errno = 0; int sent = send(this->fd, buf, len, MSG_NOSIGNAL); if (errno == EPIPE || errno == ENOTCONN) { throw(exc, &SocketConnection_NotConnectedException); } else if (errno == ECONNRESET) { throw(exc, &SocketConnection_ConnectionResetException); } else if (sent != len) { throw(exc, &SocketConnection_LengthMismatchException); } return sent; } Assuming I want to use the kernel buffer, I could go with TCP_CORK, enable whenever it is necessary and then disable it to flush the buffer. But on the other hand, thereby the need for an additional system call arises. Thus, the usage of MSG_MORE seems more appropriate to me. I'd simply change the above send() line to: int sent = send(this->fd, buf, len, MSG_NOSIGNAL | MSG_MORE); According to lwm.net, packets will be flushed automatically if they are large enough: If an application sets that option on a socket, the kernel will not send out short packets. Instead, it will wait until enough data has shown up to fill a maximum-size packet, then send it. When TCP_CORK is turned off, any remaining data will go out on the wire. But this section only refers to TCP_CORK. Now, what is the proper way to flush MSG_MORE packets? I can only think of two possibilities: Call send() with an empty buffer and without MSG_MORE being set Re-apply the TCP_CORK option as described on this page Unfortunately the whole topic is very poorly documented and I couldn't find much on the Internet. I am also wondering how to check that everything works as expected? Obviously running the server through strace' is not an option. So the only simplest way would be to usenetcat' and then look at its `strace' output? Or will the kernel handle traffic differently transmitted over a loopback interface?

  Read the article

• xen debian: domU can't get out side

  - by iftol

  hi every body. i'm a trainee as a sysAdmin, it is my first expérience with virtualization. i have a server setup debian xen 3 with 2 physical interfaces. eth 0 for local network 10.0.0.1 and eth1 for internet (194.X.X.4). i created 3 VMs (web server, mail server and dabase server) with local ip addresses 172.10.0.x/24. the problem i had first is that domU can't ping dom0. i asked the sysAdmin of our ISP and he sais that he fogot to setup the bridginb. so he ceated a bridge with 172.10.0.1/24 after that i was able to ping the real server (194.X.X.4). but i can't go out side from my VMs, how can i fixe this issue? real or physical server ifconfig eth0 Link encap:Ethernet HWaddr 23:26:34:84:ce:xe inet adr:10.1.3.12 Bcast:10.1.3.255 Masque:255.255.255.0 adr inet6: fe80::226:b9ff:fe84:ceb4/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:412006 errors:0 dropped:0 overruns:0 frame:0 TX packets:411296 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:31410957 (29.9 MiB) TX bytes:31178370 (29.7 MiB) Interruption:36 Mémoire:d6000000-d6012100 eth1 Link encap:Ethernet HWaddr 23:26:34:84:ce:xe inet adr:194.x.x.4 Bcast:194.254.167.255 Masque:255.255.255.0 adr inet6: fe80::226:b9ff:fe84:ceb6/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25872332 errors:0 dropped:0 overruns:0 frame:0 TX packets:414578 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:2642278343 (2.4 GiB) TX bytes:35436775 (33.7 MiB) lo Link encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 adr inet6: ::1/128 Scope:Hôte UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1308073 errors:0 dropped:0 overruns:0 frame:0 TX packets:1308073 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:109871395 (104.7 MiB) TX bytes:109871395 (104.7 MiB) peth1 Link encap:Ethernet HWaddr 23:26:34:84:ce:xe UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:31818694 errors:0 dropped:0 overruns:0 frame:0 TX packets:414818 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:5197318822 (4.8 GiB) TX bytes:37904897 (36.1 MiB) Interruption:48 Mémoire:d8000000-d8012100 vif281.0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff adr inet6: fe80::fcff:ffff:feff:ffff/64 Scope:Lien UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:207 errors:0 dropped:0 overruns:0 frame:0 TX packets:298 errors:0 dropped:2 overruns:0 carrier:0 collisions:0 lg file transmission:32 RX bytes:24629 (24.0 KiB) TX bytes:28404 (27.7 KiB) vif281.1 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff adr inet6: fe80::fcff:ffff:feff:ffff/64 Scope:Lien UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:45 errors:0 dropped:47063 overruns:0 carrier:0 collisions:0 lg file transmission:32 RX bytes:0 (0.0 B) TX bytes:4449 (4.3 KiB) vif282.0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff adr inet6: fe80::fcff:ffff:feff:ffff/64 Scope:Lien UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:78 errors:0 dropped:0 overruns:0 frame:0 TX packets:13 errors:0 dropped:1 overruns:0 carrier:0 collisions:0 lg file transmission:32 RX bytes:5041 (4.9 KiB) TX bytes:714 (714.0 B) xenbr0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff inet adr:172.10.0.1 Bcast:172.10.0.255 Masque:255.255.255.0 adr inet6: fe80::5c72:c6ff:fe49:7fe/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7180 errors:0 dropped:0 overruns:0 frame:0 TX packets:8615 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:756804 (739.0 KiB) TX bytes:791206 (772.6 KiB) brtcl show bridge name bridge id STP enabled interfaces eth1 8000.0026b984ceb6 no peth1 vif281.1 xenbr0 8000.feffffffffff no vif281.0 vif282.0 network-multi-bridge /etc/xen/scripts/network-virtual start vifnum="0" bridgeip="172.10.0.1/24" brnet="172.10.0.0/24" VM webserver eth0 Link encap:Ethernet HWaddr 00:16:3E:42:33:70 inet addr:172.10.0.2 Bcast:172.10.0.255 Mask:255.255.255.0 inet6 addr: fe80::216:3eff:fe42:3370/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:27 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:126 (126.0 b) TX bytes:2036 (1.9 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Thank you for your help.

  Read the article

• Reciving UDP packets on iPhone

  - by Eli

  I'm trying to establish UDP communication between a MAC OS and an iPod through Wi-Fi, at this point I'm able to send packets from the iPod and I can see those packets have the right MAC and ip addresses (I'm using wireshark to monitor the network) but the MAC receives the packets only when the wireshark is on, otherwise recvfrom() returns -1. When I try to transmit from MAC to iPhone I have the same result, I can see the packets are sent but the iPhone doesn't seem to get them. I'm using the next code to send: struct addrinfo hints; int rv; memset(&hints, 0, sizeof hints); hints.ai_family = AF_UNSPEC; hints.ai_socktype = SOCK_DGRAM; if ((rv = getaddrinfo(IP, SERVERPORT, &hints, &servinfo)) != 0) { fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(rv)); return 1; } // loop through all the results and make a socket for(p = servinfo; p != NULL; p = p->ai_next) { if ((sockfd = socket(p->ai_family, p->ai_socktype, p->ai_protocol)) == -1) { perror("talker: socket"); continue; } break; } if (p == NULL) { fprintf(stderr, "talker: failed to bind socket\n"); return 2; } while (cond) sntBytes += sendto(sockfd, message, strlen(message), 0, p->ai_addr, p->ai_addrlen); return 0; and this code to receive: struct addrinfo hints, *p; int rv; memset(&hints, 0, sizeof hints); hints.ai_family = AF_UNSPEC; // set hints.ai_socktype = SOCK_DGRAM; hints.ai_flags = AI_PASSIVE; // use to AF_INET to force IPv4 my IP if ((rv = getaddrinfo(NULL, MYPORT, &hints, &servinfo)) != 0) { fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(rv)); return 1; } // loop through all the results and bind to the first we can for(p = servinfo; p != NULL; p = p->ai_next) { if ((sockfd = socket(p->ai_family, p->ai_socktype, p->ai_protocol)) == -1) { perror("listener: socket"); continue; } if (bind(sockfd, p->ai_addr, p->ai_addrlen) == -1) { close(sockfd); perror("listener: bind"); continue; } break; } if (p == NULL) { fprintf(stderr, "listener: failed to bind socket\n"); return 2; } addr_len = sizeof their_addr; fcntl(sockfd, F_SETFL,O_NONBLOCK); int rcvbuf_size = 128 * 1024; // That's 128Kb of buffer space. setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &rcvbuf_size, sizeof(rcvbuf_size)); printf("listener: waiting to recvfrom...\n"); while (cond) rcvBytes = recvfrom(sockfd, buf, MAXBUFLEN-1 , 0, (struct sockaddr *)&their_addr, &addr_len); return 0; What am I missing?

  Read the article

• Networking Client Server Packet logic (How they communicate)

  - by Trixmix

  I want to know what is the logic behind server client communication through packets for a real time game. for example the server sends x packets then the client receives x packets and processes them.. Basically what is the process to keep the client and server in sync and able to receive and send packets. more in depth example of what I want to know: client step 1 wait for a packet step 2 read x packets step 3 process x packets step 4 send x packets and so on... I need to know the very basic outline of the communication. Big questions are: 1) do I send and read packets all at one time? i.e for loop though the incoming packets array list and read them all or one every server loop or what... 2) what order should I do things i.e first receive then read then process then send etc.. 3) what I asked above a step by step of what the server / client should do.. Thanks!

  Read the article

• Home ADSL Modem Dropping Packets?

  - by Cody

  I know this is supposed to be a "pro" forum, but I'm hoping someone can help since my ISP isn't doing much to try and fix things. My ISP has given me a DSL modem / Router combo - a ADB / Pirelli P.DG A2100N and I have a 4096 / 767 kbps connection. I use it purely as modem and router, and have the wireless AP feature turned off. I run it to a Ubiquiti Networks Toughswitch and use a Ubiquiti UAP as the wireless access point - although I've ran tests directly wired to the router with nothing else connected, and still see the same issues. I've been having issues where latency suddenly spikes from 8ms to google.com to 250+ if someone does anything on the internet. If I run a speedtest or something, I can see latencies above 3000ms. Regularly when downloading something, even if the speed is throttled to , it can get random drops to 0kbps every few seconds. Online gaming is impossible because I notice the sudden lag-outs in the connection, and video streams or VoIP drop out as well - it's not at all consistent. I managed to find the password to my modem and I don't think I see anything wrong with the settings - but I looked for the logs and found this: Jun 6 17:10:30 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:10:30 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:10:31 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:10:40 user warn kernel: __ratelimit: 63 callbacks suppressed Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:22 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:23 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:24 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:24 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:24 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:24 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:24 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:25 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:25 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:25 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:29 user warn kernel: __ratelimit: 15 callbacks suppressed Jun 6 17:11:29 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:29 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:30 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:11:30 user warn kernel: nf_conntrack: table full, dropping packet. Jun 6 17:55:26 user warn kernel: bcmxtmcfg: OAM loopback response not received on VCC 1.1.3 Jun 6 17:55:27 user warn kernel: bcmxtmcfg: OAM loopback response not received on VCC 1.1.4 So, as I understand it, it appears the router is dropping packets? If that's the case, is there anything in the config that I can change? Or should I buy a new router, a new modem, or both?

  Read the article

• Linux, some packets are not being NAT

  - by user70932

  Hi, I'm trying to NAT HTTP traffic, I'm new to this and facing some issues. What i'm trying to do is NAT client HTTP requests to a webserver. CLIENT - NAT BOX - WEBSERVER When the client open the IP of the NAT BOX, the request should be pass to the web server. But I'm getting "HTTP request sent, awaiting response..." and then wait serveral minutes before the request is done. Looking at the tcpdump output, it looks like the first Syn packet on (10:48:54) is being NAT but not the second, third, fourth... ACK or PSH packets, and wait until (10:52:04) it starts NAT again on the ACK packet. The iptables command I'm using is: iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 \ -j DNAT --to-destination WEBSERVER I'm wondering what could have caused this behavior? Thanks alot. 10:48:54.907861 IP (tos 0x0, ttl 49, id 16395, offset 0, flags [DF], proto: TCP (6), length: 48) CLIENT.61736 > NATBOX.http: S, cksum 0x6019 (correct), 1589600740:1589600740(0) win 5840 <mss 1460,nop,wscale 8> 10:48:54.907874 IP (tos 0x0, ttl 48, id 16395, offset 0, flags [DF], proto: TCP (6), length: 48) CLIENT.61736 > WEBSERVER.http: S, cksum 0xb5d7 (correct), 1589600740:1589600740(0) win 5840 <mss 1460,nop,wscale 8> 10:48:55.102696 IP (tos 0x0, ttl 49, id 16397, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x2727 (correct), ack 2950613896 win 23 10:48:55.102963 IP (tos 0x0, ttl 49, id 16399, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:48:58.103078 IP (tos 0x0, ttl 49, id 16401, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:48:58.366344 IP (tos 0x0, ttl 49, id 16403, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x26af (correct), ack 1 win 23 10:49:04.103204 IP (tos 0x0, ttl 49, id 16405, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:49:04.363943 IP (tos 0x0, ttl 49, id 16407, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x26af (correct), ack 1 win 23 10:49:16.101583 IP (tos 0x0, ttl 49, id 16409, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:49:16.363475 IP (tos 0x0, ttl 49, id 16411, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x26af (correct), ack 1 win 23 10:49:40.100796 IP (tos 0x0, ttl 49, id 16413, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:49:40.563898 IP (tos 0x0, ttl 49, id 16415, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x26af (correct), ack 1 win 23 10:50:28.099396 IP (tos 0x0, ttl 49, id 16417, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:50:28.761678 IP (tos 0x0, ttl 49, id 16419, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x26af (correct), ack 1 win 23 10:52:04.093668 IP (tos 0x0, ttl 49, id 16421, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:52:04.093678 IP (tos 0x0, ttl 48, id 16421, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > WEBSERVER.http: P 1589600741:1589600861(120) ack 2950613896 win 23 10:52:04.291021 IP (tos 0x0, ttl 49, id 16423, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x25d3 (correct), ack 217 win 27 10:52:04.291028 IP (tos 0x0, ttl 48, id 16423, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: ., cksum 0x7b91 (correct), ack 217 win 27 10:52:04.300708 IP (tos 0x0, ttl 49, id 16425, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x253c (correct), ack 368 win 27 10:52:04.300714 IP (tos 0x0, ttl 48, id 16425, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: ., cksum 0x7afa (correct), ack 368 win 27 10:52:04.301417 IP (tos 0x0, ttl 49, id 16427, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: F, cksum 0x253b (correct), 120:120(0) ack 368 win 27 10:52:04.301438 IP (tos 0x0, ttl 48, id 16427, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: F, cksum 0x7af9 (correct), 120:120(0) ack 368 win 27 10:52:04.498875 IP (tos 0x0, ttl 49, id 16429, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x253a (correct), ack 369 win 27 10:52:04.498881 IP (tos 0x0, ttl 48, id 16429, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: ., cksum 0x7af8 (correct), ack 369 win 27

  Read the article

• Weird UPD packets on incoming FTP MLSD command

  - by FractalizeR

  Hello. I am developing a firewall script for my server. So far it is working fine, except for FTP. Server is dedicated, CentOS based with static IP. There is no NAT between me and server. IPTables is a firewall. Here is a script I use to configure iptables: http://pastebin.com/f54a70fec I allow all RELATED and ESTABLISHED connections in it and load all conn_track modules. I supposed it to be sufficient in order FTP to work with iptables. The problem is that FTP is not working either in passive or active mode. FileZilla and TotalCommander just hangs on MLSD FTP command. In the server log at the exact moment of FTP connection some weird packets are dropped by firewall: Dec 20 15:37:09 server ntpd[12329]: synchronized to 81.200.8.213, stratum 5 Dec 20 15:37:14 server proftpd[30526]: gsmforum.ru (::ffff:95.24.7.25[::ffff:95.24.7.25]) - FTP session opened. Dec 20 12:37:14 server proftpd[30526]: gsmforum.ru (::ffff:95.24.7.25[::ffff:95.24.7.25]) - Preparing to chroot to directory '/home/gsmforum' Dec 20 15:37:23 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1a:64:6b:1d:67:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=306 TOS=0x00 PREC=0x00 TTL=128 ID=32566 DF PROTO=UDP SPT=68 DPT=67 LEN=286 Dec 20 15:37:25 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1f:29:63:03:de:08:00 SRC=89.111.189.17 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=13480 PROTO=UDP SPT=1052 DPT=1947 LEN=48 Dec 20 15:37:26 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=61798 PROTO=TCP SPT=4178 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:26 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1a:64:9c:50:e7:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=306 TOS=0x00 PREC=0x00 TTL=128 ID=50015 DF PROTO=UDP SPT=68 DPT=67 LEN=286 Dec 20 15:37:26 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=62305 PROTO=TCP SPT=4178 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:26 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:bb:eb:c6:e1:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=30 ID=5245 PROTO=UDP SPT=68 DPT=67 LEN=308 Dec 20 15:37:27 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=63285 PROTO=TCP SPT=4178 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:29 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=391 PROTO=TCP SPT=4183 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:29 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=707 PROTO=TCP SPT=4178 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:30 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=975 PROTO=TCP SPT=4183 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:30 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:15:17:10:c5:9b:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=30 ID=28799 PROTO=UDP SPT=68 DPT=67 LEN=308 Dec 20 15:37:30 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=2020 PROTO=TCP SPT=4187 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:31 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=2383 PROTO=TCP SPT=4183 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:31 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=2533 PROTO=TCP SPT=4187 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:32 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=3271 PROTO=TCP SPT=4190 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:32 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=77.35.184.49 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=14501 DF PROTO=TCP SPT=1355 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:32 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=3700 PROTO=TCP SPT=4187 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:32 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=3769 PROTO=TCP SPT=4196 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:32 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=4034 PROTO=TCP SPT=4190 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:33 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=4522 PROTO=TCP SPT=4196 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:33 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=4657 PROTO=TCP SPT=4183 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Can you please suggest what is the problem? Everything is working fine except for this damn FTP.

  Read the article

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