Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Feb 2009 15:15:46 -0500
From:      John Nielsen <lists@jnielsen.net>
To:        Faizan ul haq Muhammad <faizi62@hotmail.com>
Cc:        FreeBSD Questions <freebsd-questions@freebsd.org>
Subject:   Re: ping stucks/hangs on PCI 3com NIC sk0 interface but works on builtin NIC
Message-ID:  <200902251515.47094.lists@jnielsen.net>
In-Reply-To: <BLU149-W748054287E4E4FA47DA500B6AC0@phx.gbl>
References:  <BLU149-W4690F7B871E6EB8BF6159B6AC0@phx.gbl> <200902251306.14765.lists@jnielsen.net> <BLU149-W748054287E4E4FA47DA500B6AC0@phx.gbl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 25 February 2009 01:11:42 pm Faizan ul haq Muhammad wrote:
> > From: lists@jnielsen.net
> > On Wednesday 25 February 2009 12:35:23 pm Faizan ul haq Muhammad 
wrote:
> > > Hi
> > > I have two PCI NICs and one builtin NIC on freebsd 7.0
> > > ifconfig shows information somthing like:
> > >
> > > bge0: flags=8843<UP, broadcast, runing, simplex, multicast>metric 0
> > > mtu 1500 options=9b<RXCSUM,TXCSUM, VLAN_HWTAGGING. VLAN_HWCSUM>
> > > ether 00:13:21:f8:7e:56
> > > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
> > > media: Ethernet autoselect (none) status: no carrier
> >
> > This is NIC doesn't appear to be plugged in.
>
> no it is not plugged into any other yet and if i plug it and ping it
> from an external machine, it works

That's good.

> > > sk0: flags=8843<UP, broadcast, runing, simplex, multicast>metric 0
> > > mtu 1500 options=b<RXCSUM,TXCSUM, VLAN_MTU>
> > > ether 00:0a:5e:1a:69:25
> > > inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
> > > media: Ethernet autoselect (none) status: no carrier
> >
> > Neither is this one.
>
> You are right, but it does not reply to ping even if i plug this to an
> external system with crossover cable and ping from that PC.

Still not surprising. See below.

> that is the difference in behaviour of both NICs
>
> > > Note: bge0 is builtin NIC
> > > sk0 is 3com PCI NIC
> > >
> > > now after configuration of IPV4 Addresses, when i verify the
> > > configuration with ping
> > >
> > > if i ping bge0(ping 192.168.0.1) i get the response of success
> > > but when i ping sk0 (ping 192.168.0.2) Ping gets stuck and gives no
> > > response, neither it gives success or host unreachable or denied
> > > kinda errors..
> >
> > Why do you want both interfaces to be configured on the same subnet?
>
> that is not required as such, I am just preparing the setup to use this
> machine a bridge and configure dummynet on this machine.

You might try a different configuration for your testing. I suspect if you 
changed the IP address of sk0 to 192.168.1.2 or similar it would behave 
as you are expecting.

> > > it just hangs over there.. and i can juz see one line of ping
> > > not proceeding anyway. and if I terminate it via CTRL C then i get
> > > statistics sumthing like 3 packets sent, 0 received and 100%
> > > loss...
> >
> > This is probably expected behavior. What does "netstat -rn" show? My
> > guess is that the route for 192.168.0.0/24 is "link#1" aka bge0 and
> > since it's not plugged in to anything that's as far as it gets.
>
> btu it does not show any other interface in netstat printout with this
> -rn switch
>
> and can you explain, how this is the expected behavior then..?

There can only be one route at any time for any given network. When you 
bring up bge0 with 192.168.0.1 a route is automatically created for 
192.168.0.0 pointing to that interface. When you then bring up sk0 with 
192.168.0.2 no additional route can be added for 192.168.0.0 since there 
is already one present. Therefore ALL traffic destined for the 
192.168.0.0 network will go out via bge0.

In order to be able to ping 192.168.0.2 _locally_ you'd either need to 
connect the interfaces with a crossover cable (well, crossover isn't 
strictly necessary since gigabit ethernet adapters can figure it out on 
their own..) OR plug both interfaces into a switch/hub. Ping packet goes 
out bge0 (according to the route), across the wire and comes in on sk0 
(destination address). The response would be delivered directly to bge0 
(without going over the wire).

Similarly, in order to be able to ping 192.168.0.2 from a second machine 
all _three_ interfaces would need to be connected to the same network 
segment (via a switch/hub, etc). Ping packet goes out from peer, across 
the wire and in on sk0 (destination address). Response goes out bge0 
(according to route), across the other wire and back to the peer.

I hope this helps you make sense of things.

JN




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200902251515.47094.lists>