Re: r288951: ifconfig -alias, arp not removed

2015-10-30 Thread Eric van Gyzen 
On 10/29/2015 16:56, Bryan Drewery wrote:
> On 10/29/2015 9:46 AM, Bryan Drewery wrote:
>> On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>>> On 10/29/2015 11:25, Bryan Drewery wrote:
 # ifconfig
 igb0: flags=8843 metric 0 mtu 1500

 options=403bb
 ether c8:0a:a9:04:39:78
 inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
 inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
 inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
 nd6 options=23
 media: Ethernet autoselect (1000baseT )
 status: active

 # ifconfig igb0 inet 10.10.0.9 -alias
 # arp -an|grep 10.10.0.9
 ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
 # arp -d 10.10.0.9
 arp: writing to routing socket: Operation not permitted

 I swear this is not normal. I'm on an older build as well, r288951.
>>>
>>> That definitely looks abnormal.  See what "route get" says.  I think
>>> that's the error you get when there is a route for that address.
>>>
>>
>> # netstat -rn|grep 10.10.0.9
>> # route get 10.10.0.9
>>route to: lapbox
>> destination: 10.10.0.0
>>mask: 255.255.0.0
>> fib: 0
>>   interface: igb0
>>   flags: 
>>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>>0 0 0 0  1500 1 0
>> # route get 5.5.5.5
>>route to: 5.5.5.5
>> destination: default
>>mask: default
>> gateway: router.asus.com
>> fib: 0
>>   interface: igb0
>>   flags: 
>>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>>0 0 0 0  1500 1 0
>>
>> For more context, this current system had 10.10.0.9 added to it. I
>> started up a VM which also started using 10.10.0.9 and managed to "win"
>> on the local network for owning it. (I don't know arp and this stuff
>> well). I then came to this system to remove the alias and the arp entry
>> to allow me to connect from it and have gotten into this situation.
>>
> 
> Just saw this in dmesg, which is what I described:
> 
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0

The kernel should have removed the arp entry when you removed the alias.
 I just played with this on r289837 (one week old), and I could not
reproduce the failure.  In particular, r289501 sounds interesting, even
though your interface is up.

Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r288951: ifconfig -alias, arp not removed

2015-10-30 Thread Alexander V . Chernikov 
30.10.2015, 00:57, "Bryan Drewery" :
> On 10/29/2015 9:46 AM, Bryan Drewery wrote:
>>  On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>>>  On 10/29/2015 11:25, Bryan Drewery wrote:
  # ifconfig
  igb0: flags=8843 metric 0 mtu 1500

  
 options=403bb
  ether c8:0a:a9:04:39:78
  inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
  inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
  inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
  nd6 options=23
  media: Ethernet autoselect (1000baseT )
  status: active

  # ifconfig igb0 inet 10.10.0.9 -alias
  # arp -an|grep 10.10.0.9
  ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
  # arp -d 10.10.0.9
  arp: writing to routing socket: Operation not permitted

  I swear this is not normal. I'm on an older build as well, r288951.
Well, there were changes on arpscrub procedures in r287789.
(There was one bug fixed in r289501, but I think it is not relevant).
Could you consider trying more recent HEAD and check if this is still 
reproducible?
I was not able to reproduce that behavior.
>>>
>>>  That definitely looks abnormal. See what "route get" says. I think
>>>  that's the error you get when there is a route for that address.
>>
>>  # netstat -rn|grep 10.10.0.9
>>  # route get 10.10.0.9
>> route to: lapbox
>>  destination: 10.10.0.0
>> mask: 255.255.0.0
>>  fib: 0
>>    interface: igb0
>>    flags: 
>>   recvpipe sendpipe ssthresh rtt,msec mtu weight expire
>> 0 0 0 0 1500 1 0
>>  # route get 5.5.5.5
>> route to: 5.5.5.5
>>  destination: default
>> mask: default
>>  gateway: router.asus.com
>>  fib: 0
>>    interface: igb0
>>    flags: 
>>   recvpipe sendpipe ssthresh rtt,msec mtu weight expire
>> 0 0 0 0 1500 1 0
>>
>>  For more context, this current system had 10.10.0.9 added to it. I
>>  started up a VM which also started using 10.10.0.9 and managed to "win"
>>  on the local network for owning it. (I don't know arp and this stuff
>>  well). I then came to this system to remove the alias and the arp entry
>>  to allow me to connect from it and have gotten into this situation.
>
> Just saw this in dmesg, which is what I described:
>
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
>
> --
> Regards,
> Bryan Drewery
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r288951: ifconfig -alias, arp not removed

2015-10-29 Thread Bryan Drewery 
# ifconfig
igb0: flags=8843 metric 0 mtu 1500

options=403bb
ether c8:0a:a9:04:39:78
inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
nd6 options=23
media: Ethernet autoselect (1000baseT )
status: active

# ifconfig igb0 inet 10.10.0.9 -alias
# arp -an|grep 10.10.0.9
? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
# arp -d 10.10.0.9
arp: writing to routing socket: Operation not permitted

I swear this is not normal. I'm on an older build as well, r288951.

-- 
Regards,
Bryan Drewery
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r288951: ifconfig -alias, arp not removed

2015-10-29 Thread Bryan Drewery 
On 10/29/15 9:42 AM, Eric van Gyzen wrote:
> On 10/29/2015 11:25, Bryan Drewery wrote:
>> # ifconfig
>> igb0: flags=8843 metric 0 mtu 1500
>>
>> options=403bb
>> ether c8:0a:a9:04:39:78
>> inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
>> inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
>> inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
>> nd6 options=23
>> media: Ethernet autoselect (1000baseT )
>> status: active
>>
>> # ifconfig igb0 inet 10.10.0.9 -alias
>> # arp -an|grep 10.10.0.9
>> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
>> # arp -d 10.10.0.9
>> arp: writing to routing socket: Operation not permitted
>>
>> I swear this is not normal. I'm on an older build as well, r288951.
> 
> That definitely looks abnormal.  See what "route get" says.  I think
> that's the error you get when there is a route for that address.
> 

# netstat -rn|grep 10.10.0.9
# route get 10.10.0.9
   route to: lapbox
destination: 10.10.0.0
   mask: 255.255.0.0
fib: 0
  interface: igb0
  flags: 
 recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
   0 0 0 0  1500 1 0
# route get 5.5.5.5
   route to: 5.5.5.5
destination: default
   mask: default
gateway: router.asus.com
fib: 0
  interface: igb0
  flags: 
 recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
   0 0 0 0  1500 1 0

For more context, this current system had 10.10.0.9 added to it. I
started up a VM which also started using 10.10.0.9 and managed to "win"
on the local network for owning it. (I don't know arp and this stuff
well). I then came to this system to remove the alias and the arp entry
to allow me to connect from it and have gotten into this situation.


-- 
Regards,
Bryan Drewery
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r288951: ifconfig -alias, arp not removed

2015-10-29 Thread Eric van Gyzen 
On 10/29/2015 11:25, Bryan Drewery wrote:
> # ifconfig
> igb0: flags=8843 metric 0 mtu 1500
> 
> options=403bb
> ether c8:0a:a9:04:39:78
> inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
> inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
> inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
> nd6 options=23
> media: Ethernet autoselect (1000baseT )
> status: active
> 
> # ifconfig igb0 inet 10.10.0.9 -alias
> # arp -an|grep 10.10.0.9
> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
> # arp -d 10.10.0.9
> arp: writing to routing socket: Operation not permitted
> 
> I swear this is not normal. I'm on an older build as well, r288951.

That definitely looks abnormal.  See what "route get" says.  I think
that's the error you get when there is a route for that address.

Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r288951: ifconfig -alias, arp not removed

2015-10-29 Thread Bryan Drewery 
On 10/29/2015 9:46 AM, Bryan Drewery wrote:
> On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>> On 10/29/2015 11:25, Bryan Drewery wrote:
>>> # ifconfig
>>> igb0: flags=8843 metric 0 mtu 1500
>>>
>>> options=403bb
>>> ether c8:0a:a9:04:39:78
>>> inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
>>> inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
>>> inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
>>> nd6 options=23
>>> media: Ethernet autoselect (1000baseT )
>>> status: active
>>>
>>> # ifconfig igb0 inet 10.10.0.9 -alias
>>> # arp -an|grep 10.10.0.9
>>> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
>>> # arp -d 10.10.0.9
>>> arp: writing to routing socket: Operation not permitted
>>>
>>> I swear this is not normal. I'm on an older build as well, r288951.
>>
>> That definitely looks abnormal.  See what "route get" says.  I think
>> that's the error you get when there is a route for that address.
>>
> 
> # netstat -rn|grep 10.10.0.9
> # route get 10.10.0.9
>route to: lapbox
> destination: 10.10.0.0
>mask: 255.255.0.0
> fib: 0
>   interface: igb0
>   flags: 
>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>0 0 0 0  1500 1 0
> # route get 5.5.5.5
>route to: 5.5.5.5
> destination: default
>mask: default
> gateway: router.asus.com
> fib: 0
>   interface: igb0
>   flags: 
>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>0 0 0 0  1500 1 0
> 
> For more context, this current system had 10.10.0.9 added to it. I
> started up a VM which also started using 10.10.0.9 and managed to "win"
> on the local network for owning it. (I don't know arp and this stuff
> well). I then came to this system to remove the alias and the arp entry
> to allow me to connect from it and have gotten into this situation.
> 

Just saw this in dmesg, which is what I described:

arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
on igb0
arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
on igb0
arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
on igb0
arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
on igb0



-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

ifconfig alias

2011-11-24 Thread Cy Schubert 
Sometime between Nov 9 and yesterday (Nov 23 at approximately noon PST) 
ifconfig alias has stopped working. Here's uname -a

FreeBSD bob 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r227907M: Thu Nov 24 
13:04:39 PST 2011 root@bob:/usr/obj/dsk03/src/svn-current/sys/BREAK  
i386


Here's the problem (interface doesn't matter -- on this machine vr0 and sk0 
are affected).

bob# ifconfig vr0
vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=82808VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE
ether 00:16:17:8e:65:fe
inet6 fe80::216:17ff:fe8e:65fe%vr0 prefixlen 64 scopeid 0x6 
inet 10.1.2.7 netmask 0xff00 broadcast 10.1.2.255
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: Ethernet autoselect (100baseTX full-duplex)
status: active
bob# ifconfig vr0 10.1.2.2 netmask 0x alias
bob# ifconfig vr0
vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=82808VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE
ether 00:16:17:8e:65:fe
inet6 fe80::216:17ff:fe8e:65fe%vr0 prefixlen 64 scopeid 0x6 
inet 10.1.2.2 netmask 0x broadcast 10.1.2.2
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: Ethernet autoselect (100baseTX full-duplex)
status: active
bob# 



A sample 8.2 system, showing how it should work:

FreeBSD cwsys 8.2-STABLE FreeBSD 8.2-STABLE #0: Wed Nov 23 20:29:36 PST 
2011 root@cwsys:/export/obj/opt/src/svn-stable8/sys/KQLARGE  i386

cwsys# ifconfig nfe0
nfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

options=c219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MA
GIC,VLAN_HWTSO,LINKSTATE
ether 00:1e:8c:3e:1b:da
inet 10.1.2.1 netmask 0xff00 broadcast 10.1.2.255
media: Ethernet autoselect (100baseTX 
full-duplex,flowcontrol,rxpause,txpa
use)
status: active
cwsys# ifconfig nfe0 inet 10.1.2.99 netmask 0x alias
cwsys# ifconfig nfe0
nfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

options=c219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MA
GIC,VLAN_HWTSO,LINKSTATE
ether 00:1e:8c:3e:1b:da
inet 10.1.2.1 netmask 0xff00 broadcast 10.1.2.255
inet 10.1.2.99 netmask 0x broadcast 10.1.2.99
media: Ethernet autoselect (100baseTX 
full-duplex,flowcontrol,rxpause,txpa
use)
status: active
cwsys# 


-- 
Cheers,
Cy Schubert cy.schub...@komquats.com
FreeBSD UNIX:  c...@freebsd.org   Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ifconfig alias

2011-11-24 Thread Gleb Smirnoff 
On Thu, Nov 24, 2011 at 10:12:12PM -0800, Cy Schubert wrote:
C Sometime between Nov 9 and yesterday (Nov 23 at approximately noon PST) 
C ifconfig alias has stopped working. Here's uname -a

The problam had been introduced in r227830 and had been fixed in r227958.

Sorry for that.

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ifconfig alias

2011-11-24 Thread Sergey V. Dyatko 
On Thu, 24 Nov 2011 22:12:12 -0800
Cy Schubert cy.schub...@komquats.com wrote:

 Sometime between Nov 9 and yesterday (Nov 23 at approximately noon
 PST) ifconfig alias has stopped working. Here's uname -a
 
 FreeBSD bob 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r227907M: Thu Nov 24 
 13:04:39 PST 2011
 root@bob:/usr/obj/dsk03/src/svn-current/sys/BREAK i386
 
 
 Here's the problem (interface doesn't matter -- on this machine vr0
 and sk0 are affected).
 
 bob# ifconfig vr0
 vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
 1500 options=82808VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE
   ether 00:16:17:8e:65:fe
   inet6 fe80::216:17ff:fe8e:65fe%vr0 prefixlen 64 scopeid 0x6 
   inet 10.1.2.7 netmask 0xff00 broadcast 10.1.2.255
   nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
   media: Ethernet autoselect (100baseTX full-duplex)
   status: active
 bob# ifconfig vr0 10.1.2.2 netmask 0x alias
 bob# ifconfig vr0
 vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
 1500 options=82808VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE
   ether 00:16:17:8e:65:fe
   inet6 fe80::216:17ff:fe8e:65fe%vr0 prefixlen 64 scopeid 0x6 
   inet 10.1.2.2 netmask 0x broadcast 10.1.2.2
   nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
   media: Ethernet autoselect (100baseTX full-duplex)
   status: active
 bob# 
 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162806


-- 
wbr, tiger
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 3c905B stops responding during ifconfig alias

1999-02-11 Thread Bill Paul 
Of all the gin joints in all the towns in all the world,
tc...@staff.circle.net had to walk into mine and say:

[...] 
 During an ifconfig xl0 alias, the xl0 interface drops packets.
 It does NOT generate errors (netstat -in).
 In fact, on several occasions I've seen it go completely
 unresponsive (not responding to arp requests) until kicked back
 to life by outbound packets.
[...]

My apologies for not replying to you on this sooner; it took me a while
to locate a machine with which I could do some testing (all the 3c905B
hardware I have is in the form of embedded chipsets in Dell desktop
machines, and they've been moving around on me a lot).
  
 This does NOT happen on the:
 xl0: 3Com 3c905 Fast Etherlink XL 10/100BaseTX rev 0x00 int a irq 10
on

I think I found the problem. Currently, xl_stop() and xl_init() both
issue RX and TX resets. Seems logical doesn't it? I mean, the purpose
of xl_init() is to put the NIC into a known good state, and the purpose
of xl_stop() is to slap it in the face and make it shut up ASAP. The
difference between the 3c905 and the 3c905B (well, the important
difference in this case) is that the 3c905B's chipset has a built-in PHY,
while the 3c905 requires an external one (3Com uses a DP83840A for the
3c905 boards, judging by the one sample 3c905 card I have). Apparently,
issuing the RX and TX reset commands on the 3c905B causes it to also
reset the PHY, which causes the PHY to restart its autonegotiation session
with its link partner. It takes a few seconds for the autoneg session to
finish, and during this time the 3c905B stops receiving packets.

This doesn't happen on the 3c905 because issuing the RX and TX reset
commands does not have any affect on the external PHY: the only way
to reset the PHY is by writing to the PHY's basic mode control register
via the MII management interface.

I'm including a patch which should fix this problem. It just disables
the code that does the reset in both xl_stop() and xl_init(). Please
try this and let me know if it helps.

To apply the patch, do the following:

- Make sure you have the kernel source code installed under /usr/src.
- Save this message to a file, i.e. /tmp/xl.patch
- Become root.
- Run the following commands:
# cd /sys/pci
# patch  /tmp/xl.patch
- Compile a new kernel and boot it.

This patch was generated using a version of if_xl.c from FreeBSD-current,
but it should work on any version of the driver with only a couple of
mild warnings.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: wp...@ctr.columbia.edu | Center for Telecommunications Research
Home:  wp...@skynet.ctr.columbia.edu | Columbia University, New York City
=
Mulder, toads just fell from the sky! I guess their parachutes didn't open.
=

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

RE: 3c905B stops responding during ifconfig alias

1999-02-11 Thread tcobb 
Bill,
Your patch worked perfectly.  THANK YOU!

By the way, I'd be happy to fedex a 3c905B to
you for your use in testing these sorts of things
if that would be helpful.  We have a fairly large
commitment to this card now (40+) and I'd do this
happily to facilitate continuing performance 
enhancements or other improvements to it.

Sincerely,

-Troy Cobb
 Circle Net, Inc.
 http://www.circle.net

   -Original Message-
   From: wp...@ctr.columbia.edu [mailto:wp...@ctr.columbia.edu]
   My apologies for not replying to you on this sooner; it 
   took me a while
   to locate a machine with which I could do some testing (all 
   the 3c905B
   hardware I have is in the form of embedded chipsets in Dell desktop
   machines, and they've been moving around on me a lot).
 
This does NOT happen on the:
xl0: 3Com 3c905 Fast Etherlink XL 10/100BaseTX rev 0x00 
   int a irq 10 on
   
   I think I found the problem. Currently, xl_stop() and xl_init() both
   issue RX and TX resets. Seems logical doesn't it? I mean, 
   the purpose
   of xl_init() is to put the NIC into a known good state, and 
   the purpose
   of xl_stop() is to slap it in the face and make it shut up ASAP. The
   difference between the 3c905 and the 3c905B (well, the important
   difference in this case) is that the 3c905B's chipset has a 
   built-in PHY,
   while the 3c905 requires an external one (3Com uses a 
   DP83840A for the
   3c905 boards, judging by the one sample 3c905 card I have). 
   Apparently,
   issuing the RX and TX reset commands on the 3c905B causes it to also
   reset the PHY, which causes the PHY to restart its 
   autonegotiation session
   with its link partner. It takes a few seconds for the 
   autoneg session to
   finish, and during this time the 3c905B stops receiving packets.
   
   This doesn't happen on the 3c905 because issuing the RX and TX reset
   commands does not have any affect on the external PHY: the only way
   to reset the PHY is by writing to the PHY's basic mode 
   control register
   via the MII management interface.
   
   I'm including a patch which should fix this problem. It 
   just disables
   the code that does the reset in both xl_stop() and xl_init(). Please
   try this and let me know if it helps.
   
   To apply the patch, do the following:
   
   - Make sure you have the kernel source code installed under 
   /usr/src.
   - Save this message to a file, i.e. /tmp/xl.patch
   - Become root.
   - Run the following commands:
   # cd /sys/pci
   # patch  /tmp/xl.patch
   - Compile a new kernel and boot it.
   
   This patch was generated using a version of if_xl.c from 
   FreeBSD-current,
   but it should work on any version of the driver with only a 
   couple of
   mild warnings.
   
   -Bill
   
   -- 
   
   =
   -Bill Paul(212) 854-6020 | System Manager, 
   Master of Unix-Fu
   Work: wp...@ctr.columbia.edu | Center for 
   Telecommunications Research
   Home:  wp...@skynet.ctr.columbia.edu | Columbia University, 
   New York City
   
   =
   Mulder, toads just fell from the sky! I guess their 
   parachutes didn't open.
   
   =
   
   *** ../CVSWORK/sys_pci/if_xl.c  Mon Feb  1 16:25:52 1999
   --- if_xl.c Thu Feb 11 18:34:39 1999
   ***
   *** 2363,2373 
   --- 2363,2375 
   for (i = 0; i  3; i++)
   CSR_WRITE_2(sc, XL_W2_STATION_MASK_LO + (i * 2), 0);
 
   + #ifdef notdef
   /* Reset TX and RX. */
   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_RESET);
   xl_wait(sc);
   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_RESET);
   xl_wait(sc);
   + #endif
 
   /* Init circular RX list. */
   if (xl_list_rx_init(sc) == ENOBUFS) {
   ***
   *** 2715,2724 
   --- 2717,2728 
   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_DISABLE);
   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_COAX_STOP);
   DELAY(800);
   + #ifdef notdef
   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_RESET);
   xl_wait(sc);
   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_RESET);
   xl_wait(sc);
   + #endif
   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_INTR_ACK|XL_STAT_INTLATCH);
 
   /* Stop the stats updater. */
   

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

3c905B stops responding during ifconfig alias

1999-02-06 Thread tcobb 
This happens in -current and -stable.

Machine:
CPU: Pentium II (quarter-micron) (350.80-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x652  Stepping=2
 
Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,
CM
OV,PAT,PSE36,MMX,b24
real memory  = 402653184 (393216K bytes)
config quit
avail memory = 388808704 (379696K bytes
...
xl0: 3Com 3c905B Fast Etherlink XL 10/100BaseTX rev 0x30 int a irq 9 on
pci0.18.0
...

During an ifconfig xl0 alias, the xl0 interface drops packets.
It does NOT generate errors (netstat -in).
In fact, on several occasions I've seen it go completely
unresponsive (not responding to arp requests) until kicked back
to life by outbound packets.

This does NOT happen on the:
xl0: 3Com 3c905 Fast Etherlink XL 10/100BaseTX rev 0x00 int a irq 10 on
pci0.1
8.0

Here's a quick test program that I use:

#!/usr/bin/perl

# call this as just_alias.pl class_c num_ips
$ip_base=$ARGV[0] || 209.95.67.;
$num=$ARGV[1] || 250;

for (1..$num)
{
print aliasing for $ip_base.$_.\n;
system (ifconfig xl0 alias $ip_base.$_. netmask
255.255.255.255);
  # the sleep command allows us to see the problem more
  # clearly, though it does happen w/o the sleep here...
sleep 1;
}


-Troy Cobb
 Circle Net, Inc.
 http://www.circle.net

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message