Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Two computers cannot access the same site at the same time
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Fri Nov 30, 2012 6:00 pm    Post subject: Two computers cannot access the same site at the same time Reply with quote

A weird thing happened today. I plugged in a new gentoo amd-64 into the network and everything worked except one site. It happens to be the most important host. It's difficult to even describe the problem.

When eth1 (dhcp) on gentoo-amd64 is up:

case 1
I can curl to the specific site from gentoo-amd64 in this case the network Linux router will stop curl (couldn't connect) to this site, though the pings will be
accepted if I stop eth1 on gentoo-amd64 - after some time I can curl from the Linux router to the specific site

case 2
I cannot curl to the specific site (couldn't connect) from gentoo-amd64 but can ping it and the router can curl to the specific site

It's either one or the second. I did try almost everything. tcpdump shows nothing or I couldn't find anything suspicious. The ip router feature is off.
There is more. A windows computer connected to the same router as gentoo-amd64 can always connect to the specific site. No matter if gentoo-amd64 cannot curl to it or Linux router cannot curl to it.

It's just like two Linux computers cannot connect to the specific site at the same time. The specific site is Linux driven, I can manage it too. Nothing in the logs out there.

* the specific site has nothing to do with that, I checked it, the problem is in the Linux router

Any ideas?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54028
Location: 56N 3W

PostPosted: Fri Nov 30, 2012 10:12 pm    Post subject: Reply with quote

lanthruster,

Please post the following information from each PC showing issues.
Output of [code]hostname -vif[/code
Content of /etc/resolv.conf
Output of[code]route -n[/code]
Output of[code]ifconfig -a[/code]

If you have public IPs there and wish to obscure them, please substitute digits with a letter and may the digits to the same letter everywhere.
Preserving the pattern is important but not the IPs, yet.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
faemin
n00b
n00b


Joined: 16 Oct 2012
Posts: 22

PostPosted: Sat Dec 01, 2012 6:57 am    Post subject: Re: Two computers cannot access the same site at the same ti Reply with quote

...

Last edited by faemin on Sun Dec 02, 2012 9:51 pm; edited 2 times in total
Back to top
View user's profile Send private message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Sun Dec 02, 2012 11:48 am    Post subject: Reply with quote

NeddySeagoon wrote:
lanthruster,

Please post the following information from each PC showing issues.
Output of [code]hostname -vif[/code
Content of /etc/resolv.conf
Output of[code]route -n[/code]
Output of[code]ifconfig -a[/code]

If you have public IPs there and wish to obscure them, please substitute digits with a letter and may the digits to the same letter everywhere.
Preserving the pattern is important but not the IPs, yet.


router:
gw igor # hostname -vif
gethostname()=`gw'
Resolving `gw' ...
Result: h_name=`gw.mp3.loc'
Result: h_aliases=`gw'
Result: h_aliases=`localhost'
Result: h_aliases=`silicon'
Result: h_addr_list=`127.0.0.1'
gw.mp3.loc


w_c3po igor # cat /etc/resolv.conf
\# Generated by dhcpcd
# /etc/resolv.conf.head can replace this line
# /etc/resolv.conf.tail can replace this line
#nameserver 8.8.8.8
nameserver 192.168.1.6


gw igor # route -n
Kernel IP routing table
[code]Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.60.39 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.22 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.20 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.4 192.168.60.4 255.255.255.255 UGH 0 0 0 eth1
192.168.60.21 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.64 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.18 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.3 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.65 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.50 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.34 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.19 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.49 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.48 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.47 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.14 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.45 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.28 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.42 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.8 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.40 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.9 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
X.X.X.0 0.0.0.0 255.255.255.240 U 0 0 0 eth0
192.168.69.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.69.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.62.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.62.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.68.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.68.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.63.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.63.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.60.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.70.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.70.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.61.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.61.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.65.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.65.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.64.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.64.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.67.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.67.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
192.168.66.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.66.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 x.x.x.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.60.6 0.0.0.0 UG 1 0 0 eth1[/code]


eth0 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.2 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:770175 errors:0 dropped:0 overruns:0 frame:0
TX packets:648943 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:229457632 (218.8 Mb) TX bytes:223728773 (213.3 Mb)
Interrupt:16

eth0:1 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.3 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:2 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.4 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:3 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.5 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:4 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.6 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:5 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.7 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:6 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.8 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:7 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.9 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:8 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.10 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:9 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.11 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:10 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.12 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:11 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.13 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth0:12 Link encap:Ethernet HWaddr 00:18:F3:CC:C5:68
inet addr:x.x.x.14 Bcast:x.x.x.15 Mask:255.255.255.240
UP BROADCAST RUNNING 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:16

eth1 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.1.6 Bcast:192.168.1.127 Mask:255.255.255.128
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1801472 errors:0 dropped:0 overruns:0 frame:0
TX packets:1802489 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:308803874 (294.4 Mb) TX bytes:633859778 (604.4 Mb)
Interrupt:17

eth1:1 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.60.6 Bcast:192.168.60.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth1:2 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.61.6 Bcast:192.168.61.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth1:3 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.62.6 Bcast:192.168.62.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth1:4 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.63.6 Bcast:192.168.63.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth1:5 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.64.6 Bcast:192.168.64.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth1:6 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.65.6 Bcast:192.168.65.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth1:7 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.66.6 Bcast:192.168.66.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth1:8 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.67.6 Bcast:192.168.67.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth1:9 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.68.6 Bcast:192.168.68.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth1:10 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.69.6 Bcast:192.168.69.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth1:11 Link encap:Ethernet HWaddr 00:17:31:75:21:1B
inet addr:192.168.70.6 Bcast:192.168.70.127 Mask:255.255.255.128
UP BROADCAST RUNNING 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:17

eth2 Link encap:Ethernet HWaddr 00:A0:C5:B2:2F:83
BROADCAST NOTRAILERS 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:0xc800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1843872 errors:0 dropped:0 overruns:0 frame:0
TX packets:1843872 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:132083181 (125.9 Mb) TX bytes:132083181 (125.9 Mb)

tunl0 Link encap:IPIP Tunnel HWaddr
NOARP MTU:1480 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)


amd64:

Thanks for answering. The problem is still there.
w_c3po igor # hostname -vif
gethostname()=`w_c3po'
Resolving `w_c3po' ...
hostname: Unknown host

cat /etc/resolv.conf
\# Generated by dhcpcd
# /etc/resolv.conf.head can replace this line
# /etc/resolv.conf.tail can replace this line
#nameserver 8.8.8.8
nameserver 192.168.1.6


w_c3po igor # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.60.3 0.0.0.0 UG 1 0 0 eth0
127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo
192.168.60.0 0.0.0.0 255.255.255.128 U 1 0 0 eth0

ifconfig -a
eth0 Link encap:Ethernet HWaddr 90:e6:ba:f5:f0:57
inet addr:192.168.60.64 Bcast:192.168.60.127 Mask:255.255.255.128
inet6 addr: fe80::92e6:baff:fef5:f057/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6649 errors:0 dropped:0 overruns:0 frame:0
TX packets:3933 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5978639 (5.7 MiB) TX bytes:635351 (620.4 KiB)

eth1 Link encap:Ethernet HWaddr 00:14:d1:10:ea:0b
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:103 errors:0 dropped:0 overruns:0 frame:0
TX packets:60 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:124004 (121.0 KiB) TX bytes:4585 (4.4 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)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 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)


Last edited by lanthruster on Sun Dec 02, 2012 2:38 pm; edited 2 times in total
Back to top
View user's profile Send private message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Sun Dec 02, 2012 11:56 am    Post subject: Re: Two computers cannot access the same site at the same ti Reply with quote

faemin wrote:
lanthruster wrote:
A weird thing happened today. I plugged in a new gentoo amd-64 into the network and everything worked except one site. It happens to be the most important host. It's difficult to even describe the problem.
<snip>
Any ideas?


It sounds like a problem with the subnet your new system is on and your router rule is not generic enough in regards to that site. The other possiblity is ip collision, are you sure you have assigned the system different ip's on the subnet managed by the router?


Yes, such things as the same IPs are out of question.

I can't understand the connection between just one site and the problem. If I don't curl to the specific resource from amd64 (wan) the router can access this resource. Once I curled - alas, the router cannot curl to this specific resource, while I can curl to it from other PC, and from amd64. The pings from router are OK but not TCP. Once the net interface is down @ amd 64 the router can again curl to the resource.

Or may be it's realtek.... It looks like a hardware bug but excluded everything. The L3 switches, it's between this specific host and the router. How it can happens - beats me I tried many things.

Next thing to try is to re-assemble the kernel without the routing capabilities and to use a different network adapter.

gw igor # lspci
00:00.0 Host bridge: Intel Corporation E7230 Memory Controller Hub (rev 81)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01)
00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller IDE (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
01:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 21)
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 21)

amd64
w_c3po ~ # lspci
00:00.0 Host bridge: Intel Corporation 4 Series Chipset DRAM Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 4 Series Chipset PCI Express Root Port (rev 03)
00:1a.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4
00:1a.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5
00:1a.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6
00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2
00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller
00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1
00:1c.4 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 5
00:1c.5 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 6
00:1d.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1
00:1d.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2
00:1d.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3
00:1d.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90)
00:1f.0 ISA bridge: Intel Corporation 82801JIB (ICH10) LPC Interface Controller
00:1f.2 IDE interface: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller #1
00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller
00:1f.5 IDE interface: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller #2
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
01:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
03:00.0 IDE interface: JMicron Technology Corp. JMB368 IDE controller
05:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)


Last edited by lanthruster on Sun Dec 02, 2012 12:46 pm; edited 1 time in total
Back to top
View user's profile Send private message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Sun Dec 02, 2012 12:05 pm    Post subject: Reply with quote

It feels like somehow the routing table on gateway is changed when amd64 host is in the network and only for the specific resource. I tried writing direct routing rules - no help. And it only happens when I access a WAN resource which is WAN but on co-location on with same ISP I have an optic fiber from. It is the only thing that I can see in common. But I don't see any problem in tcpdump or I can't understand it.
From the standpoint of curl or ssh - when the host is accessed from amd64, the gw curl - couldn't connect. I shutdown interface on amd64 - after about 10-15 seconds the connection is restored. It doesn't disappear immediately too, usually it takes about 4-5 seconds.

And one more thing. I tried Live CD and the effect is the same. I might try earlier versions...

I have other Linux Hosts on the same network but with the different network drivers and the different kernel version - they work no problem.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54028
Location: 56N 3W

PostPosted: Sun Dec 02, 2012 12:41 pm    Post subject: Reply with quote

lanthruster,

Code:
0.0.0.0  x.x.x.x 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.60.6 0.0.0.0 UG 1 0 0 eth1


Thats two default routes - thats bound to end in tears, since only one of them can ever be used.
Rewriting your routing table in terms of subnets would make it easier to read and debug.
e.g.
192.168.60.0 192.168.1.1 255.255.255.0 takes care of the entire 192.168.60.0/24 subnet.

Code:
192.168.69.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.69.0 0.0.0.0     255.255.255.128  U 0 0 0 eth1
These routing rules are contradictory.
You either need to use the gateway at 192.168.1.1 or you don't.

As routing rules are applied from the top down, the gateway will be used and no packets will ever reach the second rule.
Similarly for your default gateway(s), only 89.208.21.1 will ever be used.

Please describe the network topology you need so we can look at routing rules from the beginning.

I tried to add code tags to your post to make it easier for me to read but they won't render.

Edit to remove default route gateway IP at the request of the OP
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.


Last edited by NeddySeagoon on Sun Dec 02, 2012 2:50 pm; edited 1 time in total
Back to top
View user's profile Send private message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Sun Dec 02, 2012 2:44 pm    Post subject: Reply with quote

NeddySeagoon wrote:
lanthruster,



Thank you for your reply. There is nothing wrong having two default routes each per different interface. I understand the * looks ugly but the second route will not work. It's just a garbage. I removed it, just to close this:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.60.39 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.22 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.20 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.4 192.168.60.4 255.255.255.255 UGH 0 0 0 eth1
192.168.60.21 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.64 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.18 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.3 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.65 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.50 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.34 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.19 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
Cvetkova.mp3.lo 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.48 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.47 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.14 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.45 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.28 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.12 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.42 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.8 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.60.40 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
video.stal.loca 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
X.X.X.0 * 255.255.255.240 U 0 0 0 eth0
192.168.69.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.62.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.68.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.63.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.60.0 * 255.255.255.128 U 0 0 0 eth1
192.168.70.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.61.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.65.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.64.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.67.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
192.168.1.0 * 255.255.255.128 U 0 0 0 eth1
192.168.66.0 192.168.1.1 255.255.255.128 UG 0 0 0 eth1
loopback * 255.0.0.0 U 0 0 0 lo
default X.X.X.1 0.0.0.0 UG 0 0 0 eth0
default gw.mp3.loc 0.0.0.0 UG 1 0 0 eth1

No, it doesn't work this way too.

And now it's clear that it doesn't depend on interface driver. I booted from an old LiveCD x86 and the problem is still there but this time I cannot curl to the host from x86 LiveCD and it will not affect Gateway (it will always curl to the host).

And I did try the different NIC, no - the same problem.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54028
Location: 56N 3W

PostPosted: Sun Dec 02, 2012 3:17 pm    Post subject: Reply with quote

lanthruster,

Your routing table make my head hurt.

Kernel IP routing table
Code:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.60.39   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.22   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.20   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.4    192.168.60.4    255.255.255.255 UGH   0      0        0 eth1
192.168.60.21   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.64   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.18   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.3    192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.65   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.50   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.34   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.19   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
Cvetkova.mp3.lo 192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.48   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.47   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.14   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.45   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.28   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.12   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.42   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.8    192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.60.40   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
video.stal.loca 192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
X.X.X.0         *               255.255.255.240 U     0      0        0 eth0
192.168.69.0    192.168.1.1     255.255.255.128 UG    0      0        0 eth1
192.168.62.0    192.168.1.1     255.255.255.128 UG    0      0        0 eth1
192.168.68.0    192.168.1.1     255.255.255.128 UG    0      0        0 eth1
192.168.63.0    192.168.1.1     255.255.255.128 UG    0      0        0 eth1
192.168.60.0    *               255.255.255.128 U     0      0        0 eth1
192.168.70.0    192.168.1.1     255.255.255.128 UG    0      0        0 eth1
192.168.61.0    192.168.1.1     255.255.255.128 UG    0      0        0 eth1
192.168.65.0    192.168.1.1     255.255.255.128 UG    0      0        0 eth1
192.168.64.0    192.168.1.1     255.255.255.128 UG    0      0        0 eth1
192.168.67.0    192.168.1.1     255.255.255.128 UG    0      0        0 eth1
192.168.1.0     *               255.255.255.128 U     0      0        0 eth1
192.168.66.0    192.168.1.1     255.255.255.128 UG    0      0        0 eth1
loopback        *               255.0.0.0       U     0      0        0 lo
default         X.X.X.1         0.0.0.0         UG    0      0        0 eth0
default         gw.mp3.loc      0.0.0.0         UG    1      0        0 eth1
You may not usefully have more than one default route as it matches any IP addresses. In your case, you only used default route is over eth0, which is I guess, what you want.

The rule
Code:
 192.168.60.0    *               255.255.255.128 U     0      0        0 eth1
can be rewritten as to reach 192.168.60.0/25 no route is required.
So why all of the host routes in the 192.168.60.0/25 subnet via 192.168.1.1 ?
They can't both be required but they may both work, since 192.168.1.1 could have a route back again. As your routing table is structured, the host routes will be applied before the 192.168.60.0/25 rule.

Please explain to network layout. Clearly the outside world is on eth0 and lots of other machines are on eth1.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Sun Dec 02, 2012 4:13 pm    Post subject: Reply with quote

NeddySeagoon wrote:
lanthruster,

Your routing table make my head hurt.



192.168.1.1 is L3 switch and it is it's gateway interface.

The problem has nothing to do with 192.168.1.1, I did connect amd64 to the GW through L1 switch, making static routes and IPs - the same result.

192.168.60.0
192.168.70.0
etc.

are VLANs

The packets from this linux box, by reasons unknown are stopped by GW (iptables are OK)

Please note that another PC is connected to the same switch with gentoo and it can curl to the host and the connection won't cause any problems with the gateway. It's just Linux to Linux problem.

PS I'm not sure if it is related. A few days ago there was an IP address conflict with this linux box. But from that moment all the hardware was rebooted and the amd64 box got another IP address.

The problem is weird. Just one WAN host is affected. I can curl from amd64 to any other host. The pings are working, but TCP/IP is not.

I wonder if it's possible to debug the problem somehow.
Back to top
View user's profile Send private message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Sun Dec 02, 2012 4:43 pm    Post subject: Reply with quote

If I disable eth0 @ amd64 and re-assign the very same IP address to the windows box - it works, the problematic host is accessible.

It can't be a gateway problem. With tcpdump I see packets coming from the host and through eth1 and eth0 to the IP address but they somehow disappear.
amd64 doesn't receive it (amd64 iptables are off)
Back to top
View user's profile Send private message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Sun Dec 02, 2012 6:32 pm    Post subject: Finally the problem is localized Reply with quote

After investigating tcpdumps produced by different computers:

Windows - no problem
Linux x86 - no problem
Linux amd64 - problem

I turned off

net.ipv4.tcp_timestamps = 0

and the problem with a specific host disappeared....

May be this will shed a light on the problem.

Windows computer, no problem with the specific host:

22:02:16.077709 IP GW > HOST.ssh: S 1109178155:1109178155(0) win 65535 <mss 1460,nop,nop,sackOK>
22:02:16.078728 IP HOST.ssh > GW.1290: S 549154129:549154129(0) ack 1109178156 win 5840 <mss 1460,nop,nop,sackOK>

Linux computer, no problem with the specific host:

22:02:29.663330 IP GW.53796 > HOST.ssh: S 575166345:575166345(0) win 5840 <mss 1460,sackOK,timestamp 453604576[|tcp]>
22:02:29.664414 IP HOST.ssh > GW.53796: S 758293313:758293313(0) ack 575166346 win 5792 <mss 1460,sackOK,timestamp 1398599312[|tcp]>

Linux amd64 computer, problem!!

22:07:32.494526 IP GW.33502 > HOST.ssh: S 1282756678:1282756678(0) win 14600 <mss 1460,sackOK,timestamp 802248[|tcp]>

I noticed that the timestamp value in case of a problematic Linux amd64 is short, in windows - there is no timestamp at all and non-problematic Linux is using longer timestamp.

I disabled timestamp in sysctl.conf and would you know it - it worked. You may noticed an unusually huge tcp/ip windows size for the problematic linux amd64.

The next question to answer is why this happens.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54028
Location: 56N 3W

PostPosted: Sun Dec 02, 2012 6:56 pm    Post subject: Reply with quote

lanthruster,

The timestamp being short suggests that the clock is slow.
For messages sent fro different systems at the same time, the timestamps should be identical.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Sun Dec 02, 2012 7:03 pm    Post subject: Reply with quote

NeddySeagoon wrote:
lanthruster,

The timestamp being short suggests that the clock is slow.
For messages sent fro different systems at the same time, the timestamps should be identical.


Hm... do yo have any ideas how the timestamps could rise this problem? I'll ask our noc tomorrow. The problem is 100% re-reproducible - timestamps ON - no connection, off - OK.

Thanks for your help!
Back to top
View user's profile Send private message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Sun Dec 02, 2012 8:05 pm    Post subject: Reply with quote

NeddySeagoon wrote:
lanthruster,

The timestamp being short suggests that the clock is slow.
For messages sent fro different systems at the same time, the timestamps should be identical.


BTW I think you hit the point. Do you remember I told you that I tried different boot CDs and the problem was the same. The only way this could happen if
the problem is MB specific. Somewhere at the route between the host and amd64 there is a problematic gateway, it has a bug handling the small timestamps. The motheboard that is used was P5Q SE Plus.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54028
Location: 56N 3W

PostPosted: Sun Dec 02, 2012 8:10 pm    Post subject: Reply with quote

lanthruster,

Timestamps must not be small, they are taken from the system time.
If the timestamp is wrong, its probably a real time clock issue.

Do you use ntp-client and ntpd in the default runlevel?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
lanthruster
n00b
n00b


Joined: 01 Jan 2012
Posts: 60

PostPosted: Sun Dec 02, 2012 8:52 pm    Post subject: Reply with quote

NeddySeagoon wrote:
lanthruster,

Timestamps must not be small, they are taken from the system time.
If the timestamp is wrong, its probably a real time clock issue.

Do you use ntp-client and ntpd in the default runlevel?


Yes, on amd64 they are emerged but neither of them started. The date on amd64 is accurate down to the seconds.
But should the local time stop packets from reaching the target anyway? Do you mean if you now set the clock to something different - you'll go offline?
It looks like a gateway on the way to the HOST problem.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum