[SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

vonlinuxnaut · 2014-03-30 20:05:40

Hello,

EDIT: explanation updated for clarity!!

Originally I wanted to connect my arch desktop to my raspberry pi via ethernet so I could access it through ssh as described in this unhelpful guide.

However, I quickly realized I had no idea what i was doing, and decided that this was the motivation I needed to finally learn more about networking. I began reading TCP/IP guide till I felt I had enough understanding of networking principles/technologies to try agian.

Currently, for the purposes of education and fun, I am trying to connect my arch desktop to my ubuntu laptop via ethernet, and it is this connection that I am asking for help troubleshooting.

Why not use the rpi? Because my keyboard is not usb and my monitor is not hdmi, and the only alternative is using my friends usb keyboard and my home theatre projector, which is too frustrating a setup for optimal learning.

I don't have a crossover cable but I checked my ethernet controllers and they apparently both have auto MDIX capabilities.

So anyway I assigned both ethernet interfaces with ip addresses 2.2.2.1 and 2.2.2.2 respectively with

ip addr add 2.2.2.2/24 dev eth0 
ip addr add 2.2.2.1/24 dev eth0

However when I try to ping my laptop from my arch box with

 ping -c3 -I eth0 2.2.2.1

I get

From 2.2.2.2 icp_seq=1 Destination Host Unreachable

And similar if I try from my laptop.

Afterwards my arp cache shows the following entry

 2.2.2.1 dev eth0  FAILED

Interestingly, trying to ping 127.0.0.1 works but if I try to specify EITHER my ethernet OR wireless interfaces I get

 Destination Host Unreachable

Any tips on how to troubleshoot would be greatly appreciated.

Last edited by vonlinuxnaut (2014-04-05 19:16:01)

scar · 2014-03-31 06:42:29

are you sure, that your ethernet interfaces are called "eth0"?
(pinging 127.0.0.1 should almost always work, as "lo" is only a loopback device)

magum · 2014-03-31 08:47:26

Hi scar,

so I assume you have one raspberry (with raspbian or so?) and an archlinux pc. Both are directly connected with a single cable, right?

Now first of all using 2.2.2.1/2 addresses is a bad idea, because those are global adresses, that is there might be a host in the internet having exactly this address. Instead use something starting with 10.x.x.x or 192.168.x.x. Okay but probably this is not the real problem.

It would be great if you could provide the output of the following commands (best on both machines):

ip addr show
ip route show

With those we should be able to pinpoint the problem quickly

PS: To troubleshoot any problem on the network level tcpdump and wireshark are great to see what packets actually arrive and where the problems could be. So learning them at some point is a good idea!

Zeddi · 2014-03-31 09:18:59

Is there a link between both "computers"? Are the lights Flashing?

Perhaps the network cards (or one of them) is not auto-negoation capable - then you should use a switch or a crossover-cable.

vonlinuxnaut · 2014-04-01 00:15:59

Arch box:

$ip addr show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:25:11:3f:8b:17 brd ff:ff:ff:ff:ff:ff
3: wlp0s26f7u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 34:08:04:9b:d7:fd brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.13/24 brd 192.168.0.255 scope global wlp0s26f7u2
       valid_lft forever preferred_lft forever
    inet6 fe80::3608:4ff:fe9b:d7fd/64 scope link 
       valid_lft forever preferred_lft forever

$ip route show

192.168.0.0/24 dev wlp0s26f7u2  proto kernel  scope link  src 192.168.0.13  metric 303

Ubuntu laptop:

$ip addr show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether e8:03:9a:db:a2:5e brd ff:ff:ff:ff:ff:ff
    inet 2.2.2.1/24 scope global eth0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether e8:03:9a:fb:3b:e2 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ea03:9aff:fefb:3be2/64 scope link 
       valid_lft forever preferred_lft forever

$ip route show

default via 192.168.0.1 dev wlan0  proto static 
169.254.0.0/16 dev wlan0  scope link  metric 1000 
192.168.0.0/24 dev wlan0  proto kernel  scope link  src 192.168.0.22  metric 9

/edited bad copy paste of the output

Last edited by vonlinuxnaut (2014-04-01 00:43:41)

vonlinuxnaut · 2014-04-01 00:55:03

Zeddi wrote:

Is there a link between both "computers"? Are the lights Flashing?
Perhaps the network cards (or one of them) is not auto-negoation capable - then you should use a switch or a crossover-cable.

If you mean the ethernet ports then there is no light. Do all ethernet ports light up when there is a connection? Unfortunately I do not have a crossover cable right now to try it out.

I did look up the ethernet controllers of both systems, and (although the specs were a bit confusing) both seemed to have auto negotiation.

Arch box:

$lspci | grep Ethernet
00:19.0 Ethernet controller: Intel Corporation 82567V-2 Gigabit Network Connection

Laptop:

$lspci | grep Ethernet
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06)

vonlinuxnaut · 2014-04-01 01:03:46

scar wrote:

are you sure, that your ethernet interfaces are called "eth0"?
(pinging 127.0.0.1 should almost always work, as "lo" is only a loopback device)

Only the ubuntu laptop is eth0, arch is enp0s25 (does it matter?)

I know ping should work with 127.0.0.1 and it does unless I specify an interface with the -I option:

$ping -c3 -I wlp0s26f7u2 127.0.0.1  //for wireless
PING 127.0.0.1 (127.0.0.1) from 192.168.0.13 wlp0s26f7u2: 56(84) bytes of data.

--- 127.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2008ms

I CAN however ping my router with

$ping -c3 -I wlp0s26f7u2 192.168.0.1

The above refers only to my arch system. I have no idea what is causing this.

Last edited by vonlinuxnaut (2014-04-01 01:06:43)

Gcool · 2014-04-01 05:40:55

vonlinuxnaut wrote:

Ubuntu laptop:

$ip addr show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether e8:03:9a:db:a2:5e brd ff:ff:ff:ff:ff:ff
    inet 2.2.2.1/24 scope global eth0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether e8:03:9a:fb:3b:e2 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ea03:9aff:fefb:3be2/64 scope link 
       valid_lft forever preferred_lft forever

The <NO-CARRIER> of your eth0 interface indicates that it's not even detecting a link (aka a cable being plugged in). Simple as this may sound, make sure it's plugged in correctly (or if so, try with another cable).

ewaller · 2014-04-01 06:02:55

A couple things. You might need a cross over cable. Not all network interfaces can handle a tx/rx reversal.
You might try the command sudo ip link set dev enp0s25 up (replace enp0s25 with eth0 on the Ubuntu box)
Note the difference between enp0s25: <BROADCAST,MULTICAST> on the RP, and eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> on the Ubuntu box. The ip set up may help.
You will need to set a route on each machine (see man ip route)
You should not use 2.x.x.x. It will cause issues with default routes on your other interfaces you are using to connect to the Internet. You should use a private network address:
10.x.x.x/8
172.16.x.x/12
192.168.x.x/16

Finally, we are bending the rules here. I am allowing this only because we provide some Arch Arm support. Technically, they are a different distribution and you might ultimately need to ask there. As to the Ubuntu box, you definitely need to take support issues to the Ubuntu forums. For now, as long as we focus on the Arch part, I'll leave this open.

magum · 2014-04-01 09:58:16

Hi vonlinuxnaut,

as Gcool points out there is very likely a problem with your cable. However there are additionally a couple of problems with your setup.

Let's start with the Ubuntu laptop. Normally the ip address you set up should correspond to a route.

So if I call

ip addr add 2.2.2.1/24 dev eth0

The ip address will be attached to the interface as is happening in your case AND a corresponding route should appear telling the kernel to send out all packets to 2.2.2.0/24 via eth0. You can add it manually with

ip route add 2.2.2.0/24 dev eth0

Ok so now to the Archbox.

As you can see there is no interface called "eth0" but "enp0s25" (see here), so when you assigned the IP address 2.2.2.2/24 you should have received an error message! Lets do it for good this time:

ip addr add 2.2.2.2/24 dev enp0s25

Now a route should appear when you run

ip route show
> 2.2.2.0/24 dev enp0s25  proto kernel  scope link  src 2.2.2.2

If not add it manually as shown above for the Ubuntu laptop.

Lets do the test:
First first check if the addresses are assigned to the right interfaces. Second check if corresponding routes appear (similar to the above).

Third, if this is the case do a ping without the "-I eth0" argument. You have configured the right routes, so this is not necessary. (Plus I found it creating more problems than helping)

ping 2.2.2.1

Fourth, if you still don't get a connection, try another cable.
Fifth, if another cable doesn't help post your setup again.

@ewaller: It is not really possible to debug a network problem by just looking at one side. I added some wiki links, hope that makes it more acceptable.

vacant · 2014-04-01 12:59:50

As my Arch laptop acts as an nfs server to a raspberry pi via ethernet (i.e. the exact setup vonlinuxnaut wants), I am waiting to see vonlinuxnaut respond to using 2.2.2.2 and 2.2.2.1 before jumping in. Perhaps these Internet addresses are assign to OP? We don't know.

ewaller · 2014-04-01 14:57:21

I should have been a bit more direct about the NO-CARRIER bit. Until both sides detect a carrier as indicated by the output of ip link and by the link active LEDs at both machines, everything else is moot. Focus on that before you deal with routes, IP addresses and pings.

Once that works, work on a reasonable address scheme. Don't use something in the ICAN public space:

ewaller$@$odin ~ 1018 %whois 2.2.2.2
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '2.0.0.0 - 2.15.255.255'

% Abuse contact for '2.0.0.0 - 2.15.255.255' is 'gestionip.ft@orange.com'

inetnum:        2.0.0.0 - 2.15.255.255
netname:        FR-TELECOM-20100712
descr:          Orange S.A.
country:        FR
org:            ORG-FT2-RIPE
admin-c:        AB5579-RIPE
tech-c:         PG5119-RIPE
tech-c:         ML2808-RIPE
status:         ALLOCATED PA
mnt-by:         RIPE-NCC-HM-MNT
mnt-lower:      RAIN-TRANSPAC
mnt-lower:      FT-BRX
mnt-routes:     FT-BRX
mnt-routes:     RAIN-TRANSPAC
mnt-domains:    RAIN-TRANSPAC
source:         RIPE # Filtered

organisation:   ORG-FT2-RIPE
org-name:       Orange S.A.
org-type:       LIR
address:        Orange Labs
address:        Alain BIDRON OLNC/OLN/AQS/NAN
address:        48 rue Camille Desmoulins
address:        92791
address:        Issy-les-Moulineaux Cedex 9
address:        FRANCE
phone:          +33157361724
fax-no:         +33146427632
admin-c:        AB5579-RIPE
admin-c:        PG5119-RIPE
admin-c:        BP2199-RIPE
admin-c:        BRX1-RIPE
admin-c:        ML2808-RIPE
mnt-ref:        OLEANE-NOC
mnt-ref:        FT-BRX
mnt-ref:        RAIN-TRANSPAC
mnt-ref:        RIPE-NCC-HM-MNT
mnt-by:         RIPE-NCC-HM-MNT
abuse-c:        BRX1-RIPE
source:         RIPE # Filtered

person:         Alain Bidron
address:        France Telecom
address:        FT/ ROSI/ ITNPS/ NAD/ EAS
address:        48 rue Camille Desmoulins
address:        92791 ISSY LES MOULINEAUX Cedex
address:        France
phone:          +33 1 57 36 17 24
nic-hdl:        AB5579-RIPE
mnt-by:         FT-BRX
source:         RIPE # Filtered

person:         Marc Lapeyre
address:        France Telecom
address:        ROSI/DRSA/DOR/CSS
address:        13, quai Gailleton - BP 2216
address:        69214 LYON CEDEX 02
phone:          +33 4 72 87 10 25
fax-no:         +33 4 72 87 10 15
nic-hdl:        ML2808-RIPE
mnt-by:         FT-BRX
source:         RIPE # Filtered

person:         Philippe Gheeraert
address:        France Telecom
address:        ROSI/DRSA/DOR/CSS
address:        13, quai Gailleton - BP 2216
address:        69214 LYON CEDEX 02
phone:          +33 4 72 87 10 47
fax-no:         +33 4 72 87 10 15
nic-hdl:        PG5119-RIPE
mnt-by:         FT-BRX
source:         RIPE # Filtered

% Information related to '2.2.0.0/16AS3215'

route:          2.2.0.0/16
descr:          France Telecom Orange
origin:         AS3215
mnt-by:         RAIN-TRANSPAC
mnt-by:         FT-BRX
source:         RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.72 (DBC-WHOIS4)


ewaller$@$odin ~ 1019 %

It will bite you in the buttocks.

Last edited by ewaller (2014-04-01 15:00:18)

vonlinuxnaut · 2014-04-01 19:17:26

ewaller wrote:

You should not use 2.x.x.x. It will cause issues with default routes on your other interfaces you are using to connect to the Internet. You should use a private network address:
10.x.x.x/8
172.16.x.x/12
192.168.x.x/16

My mistake. I thought that my mini network between the two ethernet interfaces was logically isolated from my wireless interfaces and the internet and that therefore it didn't matter what IP I used. It is clear to me now that it is best practise to use a private IP address regardless.

I have switched to 10.0.0.1 for my arch box and 10.0.0.2 for my laptop.

ewaller wrote:

It will bite you in the buttocks.

Im curious, what kind of biting and how hard?

On a related note:

ewaller wrote:

Finally, we are bending the rules here. I am allowing this only because we provide some Arch Arm support. Technically, they are a different distribution and you might ultimately need to ask there. As to the Ubuntu box, you definitely need to take support issues to the Ubuntu forums. For now, as long as we focus on the Arch part, I'll leave this open.

Thanks for accomodating me. Is there a more general forum I should maybe take a question like this two in the future? I admit part of the reason I came here is habit. I don't use the laptop anymore really, and the only reason it has ubuntu on it is because I bunged up the transition to systemd (it was terrible) and wanted be able to use my machine and recover files before I got around to a full (and laborious) arch reinstall

Last edited by vonlinuxnaut (2014-04-01 19:19:12)

vonlinuxnaut · 2014-04-01 20:06:43

Gcool wrote:

The <NO-CARRIER> of your eth0 interface indicates that it's not even detecting a link (aka a cable being plugged in). Simple as this may sound, make sure it's plugged in correctly (or if so, try with another cable).

ewaller wrote:

I should have been a bit more direct about the NO-CARRIER bit. Until both sides detect a carrier as indicated by the output of ip link and by the link active LEDs at both machines, everything else is moot. Focus on that before you deal with routes, IP addresses and pings.

Thanks guys, this is very helpful. I will try a different network cable and a crossover cable as soon as I can and update.

vonlinuxnaut · 2014-04-01 20:39:14

Also, I believe there is some confusion as to my setup as I was initially unclear in the pursuit of brevity. I have edited the original post.

Originally I wanted to connect my arch desktop to my raspberry pi via ethernet so I could access it through ssh as described in this unhelpful guide.

However, I quickly realized I had no idea what i was doing, and decided that this was the motivation I needed to finally learn more about networking. I began reading TCP/IP guide till I felt I had enough understanding of networking principles/technologies to try agian.

Currently, for the purposes of education and fun, I am trying to connect my arch desktop to my ubuntu laptop via ethernet, and it is this connection that I am asking for help troubleshooting.

Why not use the rpi? Because my keyboard is not usb and my monitor is not hdmi, and the only alternative is using my friends usb keyboard and my home theatre projector, which is too frustrating a setup for optimal learning.

Last edited by vonlinuxnaut (2014-04-01 20:41:59)

ewaller · 2014-04-02 15:54:02

vonlinuxnaut wrote:

I thought that my mini network between the two ethernet interfaces was logically isolated from my wireless interfaces and the internet and that therefore it didn't matter what IP I used..

Im curious, what kind of biting and how hard?

The issue was there was a second network card in one of the hosts (wireless, IIRC). If a packet were to originate from that machine, which network should be used? Did you mean the RP a couple meters away? Or did you mean the guy in France? What if you really meant to talk to the guy in France? If you meant to talk to the RP, and there is something wrong with your routing tables, does some poor unsuspecting guy in France get spammed by your machine? What do they do with those packets? Bounce them? Drop them? How does your Arch (or Ubuntu) box interpret that, and what does it tell you? Will it mislead you because you think you are talking to the RP?

Now, turn on NAT on Arch. By using routable addresses, LAN packets could escape your network and, rather than being squashed (as they should be if a private network address escapes a LAN), these "Local" addresses now get routed through the wild. Again, if the Arch box with NAT is badly configured, you can get into a mode where packets go around in circles never reaching an intended (or unintended) end point. Only the TTL (Time To Live) parameter will make them ever go away.

In your case, the bite would probably only be a little nip -- unless you were to enable NAT, the only thing you might notice is that a small sub net in France becomes unreachable from your Arch Box. You might never notice. Or, some day, a year from now, some multi player game will not work for some reason you will not be able to fathom.

Last edited by ewaller (2014-04-02 15:55:12)

Alber · 2014-04-02 17:52:17

Very instructive post!

Maybe this link could help (if you didn't view it yet):
https://wiki.archlinux.org/index.php/Internet_sharing

vonlinuxnaut · 2014-04-05 18:53:08

So I switched cables and the <NO-CARRIER> bit went away. Not sure what was wrong with my first cable but I guess it's junk.

Here is my setup now:

Arch

$ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp0s26f7u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 34:08:04:9b:d7:fd brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.13/24 brd 192.168.0.255 scope global wlp0s26f7u2
       valid_lft forever preferred_lft forever
    inet6 fe80::3608:4ff:fe9b:d7fd/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:25:11:3f:8b:17 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::225:11ff:fe3f:8b17/64 scope link 
       valid_lft forever preferred_lft forever

$ip route show
default via 192.168.0.1 dev wlp0s26f7u2  metric 302 
192.168.0.0/24 dev wlp0s26f7u2  proto kernel  scope link  src 192.168.0.13  metric 302

Ubuntu

$ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether e8:03:9a:db:a2:5e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ea03:9aff:fedb:a25e/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e8:03:9a:fb:3b:e2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.22/24 brd 192.168.0.255 scope global wlan0
    inet6 fe80::ea03:9aff:fefb:3be2/64 scope link 
       valid_lft forever preferred_lft forever

$ip route show
default via 192.168.0.1 dev wlan0  proto static 
169.254.0.0/16 dev wlan0  scope link  metric 1000 
192.168.0.0/24 dev wlan0  proto kernel  scope link  src 192.168.0.22  metric 9

I also added permanent entries in my arp caches for the respective machines:
Arch

$ip neigh show
10.0.0.2 dev enp0s25 lladdr e8:03:9a:db:a2:5e PERMANENT
192.168.0.1 dev wlp0s26f7u2 lladdr 18:59:33:f8:15:e5 REACHABLE

Ubuntu

$ip neigh show
10.0.0.1 dev eth0 lladdr 00:25:11:3f:8b:17 PERMANENT
192.168.0.1 dev wlan0 lladdr 18:59:33:f8:15:e5 REACHABLE

Last edited by vonlinuxnaut (2014-04-05 19:02:19)

Arch Linux

#1 2014-03-30 20:05:40

[SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#2 2014-03-31 06:42:29

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#3 2014-03-31 08:47:26

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#4 2014-03-31 09:18:59

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#5 2014-04-01 00:15:59

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#6 2014-04-01 00:55:03

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#7 2014-04-01 01:03:46

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#8 2014-04-01 05:40:55

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#9 2014-04-01 06:02:55

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#10 2014-04-01 09:58:16

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#11 2014-04-01 12:59:50

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#12 2014-04-01 14:57:21

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#13 2014-04-01 19:17:26

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#14 2014-04-01 20:06:43

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#15 2014-04-01 20:39:14

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#16 2014-04-02 15:54:02

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#17 2014-04-02 17:52:17

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

#18 2014-04-05 18:53:08

Re: [SOLVED W/ NEW CABLE]Connecting 2 pcs with ethernet

Board footer