Re: Packet loss when using multiple IP addresses

2010-07-31 Thread Frank Bartels 
On Fri, Jul 30, 2010 at 17:15:16 +0200, Julian H. Stacey wrote:
 my problem, please answer. Maybe a single keyword is enough. :)
 
 Check: Heat ? Voltages ?
 ( I've had a few bits of hardware die the last few weeks, it's been
   hot the last few weeks here in Munich where Frank  I are )
 Electrolytic capacitors when hotter dry  degrade faster ..
 Just a guess / last straw to clutch at  check ? . Good luck.

right now I check cpu, hdd and gfx card temperatures using munin
and there are no peaks or high values. The server is running in a
data center.

Also, running mtr on the host (I've put it into /etc/ttys now)
cures the problem instantly (0.2% packet loss for an incoming
mtr).

Thanks for your input,
Knarf


smime.p7s
Description: S/MIME cryptographic signature

Re: Atheros ale problems

2010-07-31 Thread Andrea Venturoli 

Il 07/02/10 00:41, Pyun YongHyeon ha scritto:


Hello.


I'm having problems with 8.0/amd64 with the following card:

a...@pci0:1:0:0:class=0x02 card=0x83041043 chip=0x10261969
rev=0xb0 hdr=0x00
vendor = 'Attansic (Now owned by Atheros)'
device = 'PCI-E ETHERNET CONTROLLER  (AR8121/AR8113 )'
class  = network
subclass   = ethernet

This is connected to a 100Mb/s Full Duplex switch with no fancy features.



Sometimes, while connected through ssh to this box, I get kicked out with:
Disconnecting: Corrupted MAC on input.
or:
Disconnecting: Bad packet length 1686869659.

At the same time on the server's log and console, I see:

kernel: ale0: watchdog timeout -- resetting
kernel: ale0: could not disable Tx/Rx MAC(0x0008)!
kernel: ale0: link state changed to DOWN
kernel: ale0: link state changed to UP

I'm setting up this box, so I can't speak of other
protocols/applications yet.



I saw some threads about this dating back to 2008 and related to EEEPCs,
but this was supposed to be fixed.

Any help?


Show me the output of ifconfig ale0 and sysctl dev.ale.0.stats.
And see whether your switch also agrees on resolved speed/duplex of
established link.


Sorry for taking so long: the machine had been shut down nad was moved 
in production and powered back up only yesterday.
So far I didn't see that problem again, but I don't think it is 
sustaining as much traffic as when I was installing everything.
Also the switch it was connected to at the time was a 100Mb/s one; the 
one it's connected to now is 1000Mb/s.


In both case it is/was a dumb switch and I had no physical access, so I 
could not check the lights.


So I doubt the data you asked for can help, however:

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

options=319aTXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC
ether 00:26:18:d6:6a:e5
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT full-duplex)
status: active

# sysctl dev.ale.0.stats
dev.ale.0.stats.rx.good_frames: 213391
dev.ale.0.stats.rx.good_bcast_frames: 159179
dev.ale.0.stats.rx.good_mcast_frames: 140
dev.ale.0.stats.rx.pause_frames: 1288
dev.ale.0.stats.rx.control_frames: 0
dev.ale.0.stats.rx.crc_errs: 0
dev.ale.0.stats.rx.len_errs: 0
dev.ale.0.stats.rx.good_octets: 18379370
dev.ale.0.stats.rx.good_bcast_octets: 13706715
dev.ale.0.stats.rx.good_mcast_octets: 13375
dev.ale.0.stats.rx.runts: 0
dev.ale.0.stats.rx.fragments: 0
dev.ale.0.stats.rx.frames_64: 264057
dev.ale.0.stats.rx.frames_65_127: 15812
dev.ale.0.stats.rx.frames_128_255: 43486
dev.ale.0.stats.rx.frames_256_511: 11514
dev.ale.0.stats.rx.frames_512_1023: 129
dev.ale.0.stats.rx.frames_1024_1518: 167
dev.ale.0.stats.rx.frames_1519_max: 0
dev.ale.0.stats.rx.trunc_errs: 0
dev.ale.0.stats.rx.fifo_oflows: 0
dev.ale.0.stats.rx.rrs_errs: 0
dev.ale.0.stats.rx.align_errs: 0
dev.ale.0.stats.rx.filtered: 120486
dev.ale.0.stats.tx.good_frames: 71638
dev.ale.0.stats.tx.good_bcast_frames: 2
dev.ale.0.stats.tx.good_mcast_frames: 0
dev.ale.0.stats.tx.pause_frames: 0
dev.ale.0.stats.tx.control_frames: 0
dev.ale.0.stats.tx.excess_defers: 0
dev.ale.0.stats.tx.defers: 0
dev.ale.0.stats.tx.good_octets: 66527894
dev.ale.0.stats.tx.good_bcast_octets: 0
dev.ale.0.stats.tx.good_mcast_octets: 0
dev.ale.0.stats.tx.frames_64: 3611
dev.ale.0.stats.tx.frames_65_127: 14373
dev.ale.0.stats.tx.frames_128_255: 3796
dev.ale.0.stats.tx.frames_256_511: 2106
dev.ale.0.stats.tx.frames_512_1023: 3108
dev.ale.0.stats.tx.frames_1024_1518: 44644
dev.ale.0.stats.tx.frames_1519_max: 0
dev.ale.0.stats.tx.single_colls: 0
dev.ale.0.stats.tx.multi_colls: 0
dev.ale.0.stats.tx.late_colls: 0
dev.ale.0.stats.tx.excess_colls: 0
dev.ale.0.stats.tx.abort: 0
dev.ale.0.stats.tx.underruns: 0
dev.ale.0.stats.tx.desc_underruns: 0
dev.ale.0.stats.tx.len_errs: 0
dev.ale.0.stats.tx.trunc_errs: 120



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

Re: DNS server: gateway_enable option in rc.conf?

2010-07-31 Thread satellites 

 

 Okay thanks for the reply.  I thought about the sysctl setting after I had 
already posted.  Many thanks!


 

 

-Original Message-
From: Bakul Shah ba...@bitblocks.com
To: satelli...@inorbit.com
Sent: Sun, Aug 1, 2010 1:20 am
Subject: Re: DNS server: gateway_enable option in rc.conf? 


On Sat, 31 Jul 2010 14:55:33 EDT satelli...@inorbit.com  wrote:

 should I omit the gateway_enable option in the /etc/rc.conf file if I am

  already establishing those routes

 via the zone files?



You need it because as it sets sysctl net.inet.ip.forwarding

to 1.  Without it the box won't forward anything.


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

Re: usb/149039: [uhso] Binding problem with uhso

2010-07-31 Thread perryh 
 The following reply was made to PR usb/149039; it has been noted
 by GNATS.

 From: Fredrik Lindberg f...@shapeshifter.se
 To: bug-follo...@freebsd.org, pilzablei...@web.de
 Cc: Hans Petter Selasky hsela...@c2i.net
 Subject: Re: usb/149039: [uhso] Binding problem with uhso
 Date: Sat, 31 Jul 2010 15:00:07 +0200

  I apparently missed some interface flags (that really doesn't make
  sense for this device, it's configured with a /32 mask so broadcast
  etc can only be to itself) that the network stack wants to work
  properly.

Is a /32 mask even legal?  Unless there's a special case involved,
it ought to mean that there are no interfaces on the subnet other
than this one, thus this interface has no peer to communicate with
and might as well not exist.

Adding net@ in hopes someone there knows what should happen.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org