Re: Client Networking Issues / NIC Lab

[Gary Palmer]

On Thu, Apr 22, 2021 at 10:22:30PM -0700, Kevin Bowling wrote:
> Aquantia has an out of tree driver in net/aquantia-atlantic-kmod.  The
> code is not currently in a place where I'd like to see it in the tree.
> I am not really sure how common these are, the company was acquired by
> Marvell which is still producing them as a client networking option
> while they have other IP for higher end/speed.

Aquantia seems to be used in more and more motherboards to provide 
>1Gbps network interfaces (2.5Gbps or 10Gbps).  Particularly consumer
oriented motherboards

Regards,

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

Re: SFP+ on PRO/10GbE

[Gary Palmer]

On Sun, Mar 22, 2020 at 05:11:20PM -0400, Dan Langille wrote:
> On Sun, Mar 22, 2020, at 4:43 PM, sth...@nethelp.no wrote:
> > > Partial success.  The card is now able to use an SFP+ optic.  It warns me
> > > when the optic is installed:
> > > 
> > > Mar 22 16:49:45 r720-01 kernel: WARNING: Intel (R) Network Connections 
> > > are quality tested using Intel (R) Ethernet Optics. Using untested 
> > > modules is not supported and may cause unstable operation or damage to 
> > > the module or the adapter. Intel Corporation is not responsible for any 
> > > harm caused by using untested modules.
> > > 
> > > I cannot use an SFP+ optic at the switch.  The connection just does not 
> > > happen.
> > > 
> > > If I go back to the original SFP optic, the connection occurs, as 
> > > expected at 1G.
> > > 
> > > On the switch side, I've tried a known good optic from an existing 
> > > connection.
> > > 
> > > I could install an PRO/10GbE instead, that has a built-in transceiver. I 
> > > have
> > > two of those in use now, both working on 10G.
> > 
> > Have you tried connected it to something other than the Unifi switch?
> 
> The only SFP+ capable switches I have are Unifi.
> 
> I just tried the other switch (US-48) which had one SFP+ port free.  Same 
> issues there.

Did the Unifi switch see the SFP+ optics on the switch end?

What happens if you take the SFP+ module from the server and put it in the
other Unifi switch and try establishing a link between the two switches?

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

Re: Compiling iwm as module

[Gary Palmer]

On Thu, Sep 13, 2018 at 06:39:36PM +0200, Goran Meki?? wrote:
> Hello,
> 
> My wife decided to give FreeBSD a try, but her laptop has iwm driver,
> which is not yet in GENERIC on 11.2-RELEASE. Is there a way to compile
> only mentioned driver and not the whole kernel/world? If it isn't, can
> I compile only kernel given I take good care which sources I download?
> I'd like to provide her as smooth FreeBSD experience as I can, and for
> her it means less compiling when she update's her system. Thanx!

Hi,

Do you not have /boot/kernel/if_iwm.ko already?  It should have
shipped with the release.  If you put

if_iwm_load="YES"
iwm3160fw_load="YES"
iwm7260fw_load="YES"
iwm7265fw_load="YES"
iwm8000Cfw_load="YES"

in /boot/loader.conf and reboot the modules should load and the
device should be found

You probably don't need all the FW modules, you can trim it down
to the one you need

Regards,

Gary

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

Re: Fw: 100.chksetuid handging on nfs mounts

[Gary Palmer]

On Fri, Aug 31, 2018 at 08:29:33AM +0200, Gerrit K?hn wrote:
> On Thu, 30 Aug 2018 08:07:52 -0600 Alan Somers  wrote
> about Re: Fw: 100.chksetuid handging on nfs mounts:
> 
> > Well that's not very illuminating.  I was wondering if it had weird mount
> > options or something.  Are you sure that's why find is hanging?  What
> > happens if you unmount and repeat the command?
> 
> I just tried these things:
> 
> find command with nfs mounted and connection working: runs fine
> find command with nfs unmounted: runs fine
> find command with nfs mounted and nfs-nic down: hangs
> 
> As soon as I "up" the interface again, find continues to run:
> 
> ---
> root@crest:/ # find -sx / /dev/null \( ! -fstype local
> \) -prune -o -type f \( \( ! -perm +010 -and -perm +001 \) -or \( ! -perm
> +020 -and -perm +002 \) -or \( ! -perm +040 -and -perm +004 \) \) -exec ls
> -liTd \{\} \+
> nfs server hellpool:/samqfs/FC5/Gerrit: not responding
> nfs server hellpool:/samqfs/FC5/Gerrit: is alive again
> root@crest:/ # 


You might want to retry the experiment but look at the state of the 
find process using "ps alxww" or similar, or use ktrace to figure out
what it is doing.  With the '-x' flag to not cross mount points I suspect
it is using stat(2) on the mount point to check to see if the st_dev
field changes, and then skip that directory if it is different.  With
the NFS server unreachable the stat(2) cannot complete.

Regards,

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

Re: Unrecognized Inifiniband HCA

[Gary Palmer]

On Thu, May 10, 2018 at 09:21:10AM +, Grzegorz Junka wrote:
> 
> On 08/05/2018 23:41, Justin Clift wrote:
> > On 2018-05-08 21:59, Grzegorz Junka wrote:
> >> Hi All,
> >>
> >> pciconf -lv
> >>
> >> gives me
> >>
> >> none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 
> >> chip=0x634015b3
> >> rev=0xa0 hdr=0x00
> >> ?? vendor = 'Mellanox Technologies'
> >> ?? device = 'MT25408 [ConnectX VPI - IB SDR / 10GigE]'
> >> ?? class?? = serial bus
> >>
> >> Does it mean that my card is unrecognized? It supposed to be 10GB x 2
> >> Infiniband PCI-E HCA 500EX-D Dual-Port Card Mellanox Firmware.
> >> Currently the card doesn't show when doing ifconfig. What should I do
> >> to have the proper device name instead of none1 or for the card to
> >> appear in ifconfig?
> >>
> >> # kldstat
> >> Id Refs Address?? Size Name
> >> ??1 28 0x8020 1f67a88?? kernel
> >> ??2?? 1 0x82169000 316708 zfs.ko
> >> ??3?? 2 0x8248 cb78 opensolaris.ko
> >> ??4?? 1 0x8248d000 42c28?? mps.ko
> >> ??5?? 1 0x82621000 bdb0 if_lagg.ko
> >> ??6?? 1 0x8262d000 3650 ums.ko
> >> ??7?? 1 0x82631000 6679 nullfs.ko
> >> ??8?? 1 0x82638000 bdfe unionfs.ko
> >> ??9?? 2 0x82644000 2094f?? mlx5.ko
> >> 10?? 2 0x82665000 103e1?? linuxkpi.ko
> >> 11?? 1 0x82676000 15965?? mlx5en.ko
> >
> > That's probably a ConnectX (series 1) Mellanox card.?? Those can 
> > operate in
> > either Infiniband mode, or Ethernet mode.
> >
> > Which mode are you wanting it to run in? :)
> >
> > As a thought, the FreeBSD wiki page has a bit of info:
> >
> > ?? https://wiki.freebsd.org/InfiniBand
> >
> > For that card to be recognised at all, it'll need the mlx4 driver(s) 
> > to load.
> >
> > I don't remember the exact one off hand (it's been a while), but some 
> > searching
> > online for mlx4 and FreeBSD should turn up the right bits.
> 
> Many thanks Justin. This is the first time I am hearing about an 
> Infiniband card operating in Ethernet mode. These cards come with two 
> CX4/SFF 8470 ports. It's not possible to connect standard Ethernet 
> cables that I know of (not even SFP modules). Do you mean that they can 
> operate in Ethernet mode over the CX4 cable?

You can get CX4 to SFP+ cables, so I would assume so

Regards

Gary

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

Re: Missing mlx4, was Re: Unrecognized Inifiniband HCA

[Gary Palmer]

On Thu, May 10, 2018 at 08:36:44AM +, Grzegorz Junka wrote:
> 
> On 09/05/2018 00:39, Rodney W. Grimes wrote:
> >> On Tue, May 08, 2018 at 08:59:20PM +, Grzegorz Junka wrote:
> >>> Hi All,
> >>>
> >>> pciconf -lv
> >>>
> >>> gives me
> >>>
> >>> none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 
> >>> chip=0x634015b3
> >>> rev=0xa0 hdr=0x00
> >>>   ?? vendor = 'Mellanox Technologies'
> >>>   ?? device = 'MT25408 [ConnectX VPI - IB SDR / 10GigE]'
> >>>   ?? class?? = serial bus
> >>>
> >>> Does it mean that my card is unrecognized? It supposed to be 10GB x 2
> >>> Infiniband PCI-E HCA 500EX-D Dual-Port Card Mellanox Firmware. Currently
> >>> the card doesn't show when doing ifconfig. What should I do to have the
> >>> proper device name instead of none1 or for the card to appear in ifconfig?
> >>>
> >>> # kldstat
> >>> Id Refs Address?? Size Name
> >>>   ??1 28 0x8020 1f67a88?? kernel
> >>>   ??2?? 1 0x82169000 316708 zfs.ko
> >>>   ??3?? 2 0x8248 cb78 opensolaris.ko
> >>>   ??4?? 1 0x8248d000 42c28?? mps.ko
> >>>   ??5?? 1 0x82621000 bdb0 if_lagg.ko
> >>>   ??6?? 1 0x8262d000 3650 ums.ko
> >>>   ??7?? 1 0x82631000 6679 nullfs.ko
> >>>   ??8?? 1 0x82638000 bdfe unionfs.ko
> >>>   ??9?? 2 0x82644000 2094f?? mlx5.ko
> >>> 10?? 2 0x82665000 103e1?? linuxkpi.ko
> >>> 11?? 1 0x82676000 15965?? mlx5en.ko
> >> mlx5en is for ConnectX-4.  I think that's an older card.  Try mlx4en,
> >> which supports ConnectX-2 and ConnectX-3.
> >  From a quick grep this infact should be supported by the mlx4/mlx5en
> > drivers:
> > net/mlx4/main.c:/* MT25408 "Hermon" SDR */
> > net/mlx4/main.c:/* MT25408 "Hermon" DDR */
> > net/mlx4/main.c:/* MT25408 "Hermon" QDR */
> > net/mlx4/main.c:/* MT25408 "Hermon" DDR PCIe gen2 */
> > net/mlx4/main.c:/* MT25408 "Hermon" QDR PCIe gen2 */
> > net/mlx4/main.c:/* MT25408 "Hermon" EN 10GigE */
> > net/mlx4/main.c:/* MT25408 "Hermon" EN 10GigE PCIe gen2 */
> >
> 
> Thank you Gary and Rod for your quick reply. I don't seem to have mlx4 
> in my /boot/kernel. I unloaded mlx5 and mlx5en and tried to load mlx 
> instead, but strangely, it says mlx is already loaded. How?
> 
> # kldload mlx
> kldload: can't load mlx: module already loaded or in kernel
> 
> # kldstat
> Id Refs Address?? Size Name
>  ??1 22 0x8020 1f67a88?? kernel
>  ??2?? 1 0x82169000 316708 zfs.ko
>  ??3?? 2 0x8248 cb78 opensolaris.ko
>  ??4?? 1 0x8248d000 42c28?? mps.ko
>  ??5?? 1 0x82621000 bdb0 if_lagg.ko
>  ??6?? 1 0x8262d000 3650 ums.ko
>  ??7?? 1 0x82631000 6679 nullfs.ko
>  ??8?? 1 0x82638000 bdfe unionfs.ko
> 
> # ls -l /boot/kernel/mlx
> mlx.ko*?? mlx5.ko* mlx5en.ko*
> 
> Anyways, mlx seems to be rather unrelated to this problem: 
> https://www.freebsd.org/cgi/man.cgi?query=mlx
> 
> Looks like mlx4 is available in the kernel: 
> https://github.com/freebsd/freebsd/tree/master/sys/modules/mlx4
> 
> However, it seems that it may not compile: 
> https://forums.freebsd.org/threads/mellanox-mt26448.64350/
> 
> Does it mean, that mlx4 is no longer compiled in the default kernel and 
> I would need to compile the kernel manually? Can I just compile the 
> mlx4/en/ib kernel module without having to compile the whole kernel?

You either need to put "options OFED" into your kernel and recompile
to get the mlx4 module, or go to /sys/modules/mlx4 and run
"make all install"

(more details on the wiki that someone else posted earlier)

Regards,

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

Re: Unrecognized Inifiniband HCA

[Gary Palmer]

On Tue, May 08, 2018 at 08:59:20PM +, Grzegorz Junka wrote:
> Hi All,
> 
> pciconf -lv
> 
> gives me
> 
> none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 chip=0x634015b3 
> rev=0xa0 hdr=0x00
>  ?? vendor = 'Mellanox Technologies'
>  ?? device = 'MT25408 [ConnectX VPI - IB SDR / 10GigE]'
>  ?? class?? = serial bus
> 
> Does it mean that my card is unrecognized? It supposed to be 10GB x 2 
> Infiniband PCI-E HCA 500EX-D Dual-Port Card Mellanox Firmware. Currently 
> the card doesn't show when doing ifconfig. What should I do to have the 
> proper device name instead of none1 or for the card to appear in ifconfig?
> 
> # kldstat
> Id Refs Address?? Size Name
>  ??1 28 0x8020 1f67a88?? kernel
>  ??2?? 1 0x82169000 316708 zfs.ko
>  ??3?? 2 0x8248 cb78 opensolaris.ko
>  ??4?? 1 0x8248d000 42c28?? mps.ko
>  ??5?? 1 0x82621000 bdb0 if_lagg.ko
>  ??6?? 1 0x8262d000 3650 ums.ko
>  ??7?? 1 0x82631000 6679 nullfs.ko
>  ??8?? 1 0x82638000 bdfe unionfs.ko
>  ??9?? 2 0x82644000 2094f?? mlx5.ko
> 10?? 2 0x82665000 103e1?? linuxkpi.ko
> 11?? 1 0x82676000 15965?? mlx5en.ko

mlx5en is for ConnectX-4.  I think that's an older card.  Try mlx4en,
which supports ConnectX-2 and ConnectX-3.

Regards,

Gary

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

Re: Ipv6 / DNS questions

[Gary Palmer]

On Fri, Jun 02, 2017 at 09:56:28AM +0100, Matthew Seaman wrote:
> On 06/02/17 02:49, Karl Denninger wrote:
> > Is there a dynamic DNS update method associated with Ipv6's address
> > assignment system?  Since the assignment is "stateless" it obviously
> > (and does, in my experience!) move.  I can deal with it via a couple of
> > shell scripts, and there are only a couple of hosts where it matters,
> > but this would dramatically simplify the IPv4 gameplaying that's
> > necessary to have something behind a gateway router while on a "globally
> > visible", but possibly changing "at whim", IpV6 address.
> 
> Assuming that you always get the same /64 assigned to your gateway, then
> the address SLAAC assigns to your server will be constant so long as
> you're on the same hardware, since the SLAAC address is generated from
> the network prefix and the MAC address of the NIC.  In that case, it
> often suffices to update the DNS manually.

Only if

ipv6_privacy="YES"

is not set.

Regards,

Gary

> 
> If that doesn't work for you, then while there isn't a DNS update
> mechanism built into SLAAC, there is one in DHCP6.  That relies on the
> dhcp server being able to make dynamic DNS updates via nsupdate(1).  Of
> course, if you have all the keys etc. set up to be able to use
> nsupdate(1) you could fairly easily add a 'dns-update' rc script on your
> host to push the hosts' IPv6 address into the DNS.
> 
> The other fairly common approach would be to use a network configuration
> system like ansible or puppet that can gather facts about a machine
> (such as the IPv6 address) write them into a DNS zone file.
> 
>   Cheers,
> 
>   Matthew
> 



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

Re: vmx bug?

[Gary Palmer]

On Thu, May 18, 2017 at 08:39:24AM +0300, Andrew Vylegzhanin wrote:
> I will test this VM with Linux tomorrow.
> 
> Just for information, here is part of .vmx file with pci related conifg:
> 
> pciBridge0.present = "TRUE"
> 
> pciBridge4.present = "TRUE"
> pciBridge4.virtualDev = "pcieRootPort"
> pciBridge4.functions = "8"
> pciBridge5.present = "TRUE"
> pciBridge5.virtualDev = "pcieRootPort"
> pciBridge5.functions = "8"
> pciBridge6.present = "TRUE"
> pciBridge6.virtualDev = "pcieRootPort"
> pciBridge6.functions = "8"
> pciBridge7.present = "TRUE"
> pciBridge7.virtualDev = "pcieRootPort"
> pciBridge7.functions = "8"
> pciBridge0.pciSlotNumber = "17"
> pciBridge4.pciSlotNumber = "21"
> pciBridge5.pciSlotNumber = "22"
> pciBridge6.pciSlotNumber = "23"
> pciBridge7.pciSlotNumber = "24"
> vmci0.pciSlotNumber = "33"
> ethernet0.pciSlotNumber = "192"
> ethernet1.pciSlotNumber = "224"
> ethernet2.pciSlotNumber = "256"
> ethernet3.pciSlotNumber = "1184"  <== vmx0 !!!


Out of curiosity, if you install sysutils/dmidecode from ports and 
run

dmidecode -t 41

does it help at all?

Some PC vendors have taken to doing odd things with their PCI layout
which produce unexpected results with device naming (so port 1 on the
back of the server is not the first interface in the OS) and introduced
DMI type 41 as a "fix"

e.g. see 
https://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf

Regards,

Gary


> 2017-05-18 6:52 GMT+03:00 Ryan Stone :
> >
> > On Wed, May 17, 2017 at 7:32 PM, Andrew Vylegzhanin 
> wrote:
> >>
> >>
> >> vmx0@pci0:4:0:0: class=0x02 card=0x07b015ad chip=0x07b015ad rev=0x01
> hdr=0x00
> >>
> >> vendor = 'VMware'
> >>
> >> device = 'VMXNET3 Ethernet Controller'
> >>
> >> class  = network
> >>
> >> subclass   = ethernet
> >>
> >> vmx1@pci0:11:0:0: class=0x02 card=0x07b015ad chip=0x07b015ad
> rev=0x01 hdr=0x00
> >>
> >> vendor = 'VMware'
> >>
> >> device = 'VMXNET3 Ethernet Controller'
> >>
> >> class  = network
> >>
> >> subclass   = ethernet
> >>
> >> vmx2@pci0:19:0:0: class=0x02 card=0x07b015ad chip=0x07b015ad
> rev=0x01 hdr=0x00
> >>
> >> vendor = 'VMware'
> >>
> >> device = 'VMXNET3 Ethernet Controller'
> >>
> >> class  = network
> >>
> >> subclass   = ethernet
> >>
> >> vmx3@pci0:27:0:0: class=0x02 card=0x07b015ad chip=0x07b015ad
> rev=0x01 hdr=0x00
> >>
> >> vendor = 'VMware'
> >>
> >> device = 'VMXNET3 Ethernet Controller'
> >>
> >> class  = network
> >>
> >> subclass   = ethernet
> >
> >
> >  Everything appears to be enumerated in the proper order.  Do other OSes,
> say Linux, somehow enumerate in a different order?
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: sonewconn: pcb [...]: Listen queue overflow to human-readable form

[Gary Palmer]

On Thu, Dec 15, 2016 at 05:27:02PM +0200, Artem Viklenko wrote:
> 2016-12-15 14:28, Eugene Grosbein ??:
> > On 15.12.2016 19:23, Eugene M. Zheganin wrote:
> > 
> >> but at the time of investigation the socket is already closed and lsof
> >> cannot show me the owner. I wonder if the kernel can itself decode 
> >> this
> >> output and write it in the human-readable form ?
> > 
> > Until that's not implemented, you can monitor "netstat -Lan" output and
> > continuously save it for later analisys and/or draw graphs.
> > 
> 
> netstat -LanA -f inet ?

That's only IPv4 sockets (or sockets that are listening on both families
at the same time).  If you are dual stack with IPv6, you'd probably also
need to capture

netstat -LanA -f inet6

Regards,

Gary

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

Re: Closed port RST: Any way to find out what port(s)?

[Gary Palmer]

On Mon, May 16, 2016 at 12:31:02PM -0500, Larry Rosenman wrote:
> I'm seeing tons of:
> Limiting closed port RST response from 201 to 200 packets/sec
> in my log.  Is there any way to see what port(s) are being pounded?

sysctl net.inet.tcp.log_in_vain=1

I expect you would get a ton of spam from that, so my suggestion would
be tcpdump.  e.g.

tcpdump -i  -n 'tcp[tcpflags] & (tcp-rst) != 0'

Regards,

Gary

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

Re: Bridge Interfaces and ARPs

[Gary Palmer]

On Fri, Dec 04, 2015 at 03:27:20PM -0500, Jason Van Patten wrote:
> On 12/4/15 2:06 AM, Aleksandr A Babaylov wrote:
> >
> > sysctl net.link.ether.inet.proxyall=1
> 
> This looks like it's working; thanks a bunch!  Whoda'thunk you could use 
> something like proxy arp to un-break a broken network?  It appears as 
> though the above sysctl keeps resetting itself to 0 with *any* network 
> interface changes.  And from what I can see, that's as by design?  Is 
> there any way to get it to stay 1?  The problem is that sysctl does its 
> think during boot-up, before the interfaces and routing are all set in 
> /etc/rc.conf.  So I have to come back in and manually set it to 1.  I 
> suppose I can write an RC script to do that for me, but it's still 
> suboptimal.
> 
> Any guidance or suggestions on that one?
> 
> Thanks again!

Try:

sysrc arpproxy_all=YES

You can remove the sysctl setting as that's what that option does.

Regards,

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

Re: IPFW blocked my IPv6 NTP traffic

[Gary Palmer]

On Tue, Dec 01, 2015 at 12:00:47PM -0600, Mark Felder wrote:
> 
> 
> On Tue, Dec 1, 2015, at 09:16, wishmaster wrote:
> >  
> >  --- Original message ---
> >  From: "Mark Felder" 
> >  Date: 1 December 2015, 17:05:35
> >   
> > 
> > > 
> > > 
> > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote:
> > > > 
> > > > Hi, Mark.
> > > > 
> > > > 
> > > > > I'm hoping someone can explain what happened here and this isn't a 
> > > > > bug,
> > > > > but if it is a bug I'll gladly open a PR.
> > > > > 
> > > > > I noticed in my ipfw logs that I was getting a log of "DENY" entries 
> > > > > for
> > > > > an NTP server
> > > > > 
> > > > > Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP
> > > > > [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via 
> > > > > gif0
> > > > > 
> > > > > Strange... I looked at ntpq output and sure enough I was trying to
> > > > > communicate with that server. But why was it getting blocked? I don't
> > > > > have a rule to allow IPv4 input from source port 123. I expected IPFW 
> > > > > to
> > > > > handle this for me. I know UDP is stateless, but firewalls are usually
> > > > > able to "keep state" for UDP. I looked at my v4 rules which and I have
> > > > > keep-state on there:
> > > > > 
> > > > > # Allow all outgoing, skip to NAT
> > > > > ##
> > > > > $cmd 01300 skipto 5000 tcp from any to any out via $pif $ks
> > > > > $cmd 01310 skipto 5000 udp from any to any out via $pif $ks
> > > > > $cmd 01320 skipto 5000 icmp from any to any out via $pif
> > > > > ##
> > > > > 
> > > > > I noticed my outbound IPv6 didn't have $ks for udp, so I added it.
> > > > > However, that had no effect. The solution was to add an incoming rule:
> > > > > 
> > > > > $cmd 03755 allow udp from any to any src-port 123 in via $pif6 $ks
> > > > > 
> > > > > This seems wrong. Thoughts?
> > > > > 
> > > > 
> > > > What is your 5000 rule?
> > > > 
> > > 
> > > $cmd 05000 nat 1 ip4 from any to any out via $pif
> > 
> >  Hey. As I understand, there is a problem in connection clients from Inet
> >  with your NTP server. If yes, why do you use NAT rule?
> > 
> > 
> 
> That's the NAT rule for my home network for outbound IPv4. It's working
> as expected.
> 
> Outbound NTP traffic on high ports (not 123) works fine with IPv4. The
> reply from the NTP server is allowed through, presumably from the
> keep-state rule on outbound UDP traffic.
> 
> Outbound NTP traffic on high ports with IPv6 is allowed outbound but the
> replies denied inbound. This has been my source of confusion and concern
> considering it should have been allowed by keep-state.

Have you looked at the ipfw state tables to see if a state is recorded?

ipfw -d list

I think

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

Re: Outgoing packets being sent via wrong interface

[Gary Palmer]

On Wed, Nov 25, 2015 at 09:21:45AM +0100, Daniel Bilik wrote:
> On Sun, 22 Nov 2015 13:02:40 +0100
> Daniel Bilik  wrote:
> 
> > Well, even though pf may play some role in the problem, I tend to suspect
> > the routing table as the main trigger. There are several facts to support
> > this...
> 
> It happened again, yesterday, and I can now definitely confirm that it's
> related to default route.
> 
> In this case, affected address was 192.168.2.33. This host was unable to
> connect to 192.168.2.15 (jail on the router), and router itself was unable
> to even ping the affected host...
> 
> PING 192.168.2.33 (192.168.2.33): 56 data bytes
> ping: sendto: Operation not permitted
> ping: sendto: Operation not permitted
> 
> ... because again it was pushing outgoing packets wrong way, via public
> interface, where it's dropped by pf...
> 
> 00:00:07.091814 rule 53..16777216/0(match): block out on re0: 82.x.y.50 > 
> 192.168.2.33: ICMP echo request, id 12037, seq 0, length 64
> 00:00:01.011536 rule 53..16777216/0(match): block out on re0: 82.x.y.50 > 
> 192.168.2.33: ICMP echo request, id 12037, seq 1, length 64
> 
> I've tried to just delete default route and enter it back to routing table.
> In one tmux session ping was running, in another session I've performed
> this...
> 
> # route delete default ; sleep 1 ; route add default 82.x.y.29
> 
> ... and voila, ping started to communicate with affected host...
> 
> ping: sendto: Operation not permitted
> ping: sendto: Operation not permitted
> 64 bytes from 192.168.2.33: icmp_seq=12 ttl=128 time=0.535 ms
> 64 bytes from 192.168.2.33: icmp_seq=13 ttl=128 time=0.264 ms
> 
> Touching nothing else (pf etc.), not rebooting, just "refreshing" the
> default route entry, and the problem disappeared.

When the problem happens, what does the output of

route -n get 

show?  It would also be worth checking the arp table.

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

Re: realtek interface not working

[Gary Palmer]

On Fri, Sep 11, 2015 at 10:57:36PM -0700, Sreenath Battalahalli wrote:
> Hi Marius,
> 
> Thanks for the patch. I manually made changes to the two files, and after 
> building the kernel and installing it,
> I can see the re0 interface. I am now sending this email using the new laptop.
> 
> However, I am a bit confused by the dmesg output. I see two sets of lines 
> pertaining to the re0 device.
> 
> $dmesg | grep -i re0
> 
> re0:  port 
> 0x3000-0x30ff mem 0xb0604000-0xb0604fff,0xb060-0xb0603fff irq 18 at 
> device 0.0 on pci2
> re0: Using 1 MSI-X message
> re0: turning off MSI enable bit.
> re0: ASPM disabled
> re0: Chip rev. 0x5400
> re0: MAC rev. 0x0010
> re0: Unknown H/W revision: 0x5400
> device_attach: re0 attach returned 6
> re0:  port 
> 0x3000-0x30ff mem 0xb0604000-0xb0604fff,0xb060-0xb0603fff irq 18 at 
> device 0.0 on pci2
> re0: Using 1 MSI-X message
> re0: ASPM disabled
> re0: Chip rev. 0x5400
> re0: MAC rev. 0x0010
> miibus0:  on re0
> re0: Using defaults for TSO: 65518/35/2048
> re0: Ethernet address: 2c:60:0c:92:0f:c2
> 
> seems the driver attempted to initialize the device twice?
> 
> Anyway, it is working now.

The kernel dmesg buffer can be preserved over a reboot, so it's possible
the lines up to and including "device_attach: re0 attach returned 6" are
from the reboot before you installed the patch.  Rather than just grep for
re0, do "dmesg | less" or "dmesg | more" and check the context of the 
"device_attach: re0 attach returned 6" error and see if there are any 
indications of a reboot between that line and the next re0 probe lines, e.g.
"Copyright (c) 1992-2015 The FreeBSD Project"

Regards,

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

Re: ssh over WAN: TCP window too small

[Gary Palmer]

On Wed, Aug 26, 2015 at 02:30:07PM -0700, Chris Stankevitz wrote:
  ktrace -i ssh params...
 
 Thank you, this is awesome.  Is there a way for me to ktrace 'b' in this 
 example: `a | b | c`?  I tried `ktrace a | b | c` and `ktrace test.sh` 
 (which included a|b|c) but neither seemed to work.  I'm using stream 
 redirection now but it doesn't afford me the bs control of dd.  Perhaps 
 named pipes is the solution.


a | ktrace b | c

or

ktrace -di test.sh

(I suspect only -i is needed, but I've gotten so used to using both flags)

You can also start ktrace on an existing process if you know its PID

ktrace -p pid

To stop all ongoing tracing:

ktrace -C 

Regards,

Gary

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

Re: Routing IPv6 over tun0 (PPPoE) issue

[Gary Palmer]

On Sun, Aug 23, 2015 at 05:48:28PM +0100, Gary Palmer wrote:
 On Sun, Aug 23, 2015 at 04:37:56PM +0100, Matthew Seaman wrote:
  On 23/08/2015 16:04, Gary Palmer wrote:
   However if I configure other IPs on other interfaces from the netblock 
   that
   has been delegated to me and either source the traffic from those IPs or
   try the traceroute from another computer using IPs in that netblock, I
   don't even see the traffic leaving tun0 with tcpdump, let alone get any
   replies.
  
  I have a similar setup.  Looks to me as if there's a problem with your
  routing internally.
  
  My routing table looks like this (excluding the ff01::, ff02:: and
  ff03:: routes and anything that's a host specific route):
  
  % netstat -rn -f inet6 | grep -vE '(UH|ff0)'
  Routing tables
  
  Internet6:
  Destination Gateway   Flags  Netif Expire
  ::/96   ::1   UGRSlo0
  default fe80::203:97ff:fe19:8000%tun0 UGStun0
  :::0.0.0.0/96   ::1   UGRSlo0
  2001:8b0:151:1::/64 link#1U   em0  ---**
  fe80::/10   ::1   UGRSlo0
  fe80::%em0/64   link#1U   em0
  fe80::%re0/64   link#2U   re0
  fe80::%lo0/64   link#3U   lo0
  fe80::%tun0/64  link#5U  tun0
  
  Here em0 is the interface onto my internal network, and any addresses
  from my assigned IPv6 netblock are configured on that interface or the
  network directly attached to it. You should have a route equivalent to
  the one marked with the arrow.
  
  Note that tun0 uses link-local addresses for the IPv6 tunnelling, not
  addresses from my assigned range.  Depending on how your ISP has
  configured things you may need a real IPv6 address on your tun0
  interface, but this should be from a distinct subnet to the block you're
  using internally.
 
 Hi Matthew,
 
 Thanks for the reply.  I may have messed up manually masking the
 network data so let me do it by sed this time so I don't mess up.
 
 ::: is the /64 prefix used for the connection
 :: is the /48 used for internal IPs
 
 The tunnelbroker IPs are also configured but I've removed them as they
 shouldn't be relevant.  I've checked gif0 and none of the traffic is
 going out that interface either.
 
 tun0 shows:
 
 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492
 options=8LINKSTATE
 inet6 fe80::200:24ff:fec9:5bbc%tun0 prefixlen 64 scopeid 0xa 
 inet a.b.c.d -- e.f.g.h netmask 0x 
 inet6 ::::200:24ff:fec9:5bbc prefixlen 64 autoconf 
 nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL
 Opened by PID 1038
 
 vr0 shows:
 
 vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 options=8280bRXCSUM,TXCSUM,VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE
 ether 00:00:24:c9:5b:bc
 inet i.j.k.l netmask 0xff00 broadcast i.j.k.m
 inet6 fe80::200:24ff:fec9:5bbc%vr0 prefixlen 64 scopeid 0x1 
 inet6 :::1::1 prefixlen 64 
 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
 media: Ethernet autoselect (100baseTX full-duplex)
 status: active
 
 IPv6 routing table:
 
 Routing tables
 
 Internet6:
 Destination   Gateway   Flags  
 Netif Expire
 ::/96 ::1   UGRS
 lo0 =
 default   fe80::230:88ff:fe16:ec4f%tun0 UG 
 tun0
 ::1   link#9UH  
 lo0
 :::0.0.0.0/96 ::1   UGRS
 lo0
 :::1::/64 link#1U   
 vr0
 :::1::1   link#1UHS 
 lo0
 :::2::/64 link#3U   
 vr2
 :::2::1   link#3UHS 
 lo0
 :::::/64 link#10   U  
 tun0
 ::::200:24ff:fec9:5bbc link#10   UHS  
lo0
 
 traceroute from tun0 IP (first 4 hops only shown)
 
 traceroute6 to wfe0.ysv.freebsd.org (2001:1900:2254:206a::50:0) from 
 ::::200:24ff:fec9:5bbc, 4 hops max, 12 byte packets
  1  :::3:0:0:2  29.318 ms  29.860 ms  28.065 ms
  2  ::0:301::  28.724 ms  29.064 ms  29.421 ms
  3  ::0:4::1  29.881 ms  29.189 ms  28.254 ms
  4  ::0:3::1  35.764 ms  36.488 ms  36.054 ms
 
 traceroute from vr0 IP using 'traceroute6 -s' 
 
 traceroute6 to wfe0.ysv.freebsd.org (2001:1900:2254:206a::50:0) from 
 :::1::1, 4 hops max, 12 byte packets
  1  * * *
  2  * * *
 
 
  Hmmm you do have

Re: Routing IPv6 over tun0 (PPPoE) issue

[Gary Palmer]

On Sun, Aug 23, 2015 at 04:37:56PM +0100, Matthew Seaman wrote:
 On 23/08/2015 16:04, Gary Palmer wrote:
  However if I configure other IPs on other interfaces from the netblock that
  has been delegated to me and either source the traffic from those IPs or
  try the traceroute from another computer using IPs in that netblock, I
  don't even see the traffic leaving tun0 with tcpdump, let alone get any
  replies.
 
 I have a similar setup.  Looks to me as if there's a problem with your
 routing internally.
 
 My routing table looks like this (excluding the ff01::, ff02:: and
 ff03:: routes and anything that's a host specific route):
 
 % netstat -rn -f inet6 | grep -vE '(UH|ff0)'
 Routing tables
 
 Internet6:
 Destination Gateway   Flags  Netif Expire
 ::/96   ::1   UGRSlo0
 default fe80::203:97ff:fe19:8000%tun0 UGStun0
 :::0.0.0.0/96   ::1   UGRSlo0
 2001:8b0:151:1::/64 link#1U   em0  ---**
 fe80::/10   ::1   UGRSlo0
 fe80::%em0/64   link#1U   em0
 fe80::%re0/64   link#2U   re0
 fe80::%lo0/64   link#3U   lo0
 fe80::%tun0/64  link#5U  tun0
 
 Here em0 is the interface onto my internal network, and any addresses
 from my assigned IPv6 netblock are configured on that interface or the
 network directly attached to it. You should have a route equivalent to
 the one marked with the arrow.
 
 Note that tun0 uses link-local addresses for the IPv6 tunnelling, not
 addresses from my assigned range.  Depending on how your ISP has
 configured things you may need a real IPv6 address on your tun0
 interface, but this should be from a distinct subnet to the block you're
 using internally.

Hi Matthew,

Thanks for the reply.  I may have messed up manually masking the
network data so let me do it by sed this time so I don't mess up.

::: is the /64 prefix used for the connection
:: is the /48 used for internal IPs

The tunnelbroker IPs are also configured but I've removed them as they
shouldn't be relevant.  I've checked gif0 and none of the traffic is
going out that interface either.

tun0 shows:

tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492
options=8LINKSTATE
inet6 fe80::200:24ff:fec9:5bbc%tun0 prefixlen 64 scopeid 0xa 
inet a.b.c.d -- e.f.g.h netmask 0x 
inet6 ::::200:24ff:fec9:5bbc prefixlen 64 autoconf 
nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL
Opened by PID 1038

vr0 shows:

vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=8280bRXCSUM,TXCSUM,VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE
ether 00:00:24:c9:5b:bc
inet i.j.k.l netmask 0xff00 broadcast i.j.k.m
inet6 fe80::200:24ff:fec9:5bbc%vr0 prefixlen 64 scopeid 0x1 
inet6 :::1::1 prefixlen 64 
nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
media: Ethernet autoselect (100baseTX full-duplex)
status: active

IPv6 routing table:

Routing tables

Internet6:
Destination   Gateway   Flags  
Netif Expire
::/96 ::1   UGRSlo0 
=
default   fe80::230:88ff:fe16:ec4f%tun0 UG tun0
::1   link#9UH  lo0
:::0.0.0.0/96 ::1   UGRSlo0
:::1::/64 link#1U   vr0
:::1::1   link#1UHS lo0
:::2::/64 link#3U   vr2
:::2::1   link#3UHS lo0
:::::/64 link#10   U  
tun0
::::200:24ff:fec9:5bbc link#10   UHS
 lo0

traceroute from tun0 IP (first 4 hops only shown)

traceroute6 to wfe0.ysv.freebsd.org (2001:1900:2254:206a::50:0) from 
::::200:24ff:fec9:5bbc, 4 hops max, 12 byte packets
 1  :::3:0:0:2  29.318 ms  29.860 ms  28.065 ms
 2  ::0:301::  28.724 ms  29.064 ms  29.421 ms
 3  ::0:4::1  29.881 ms  29.189 ms  28.254 ms
 4  ::0:3::1  35.764 ms  36.488 ms  36.054 ms

traceroute from vr0 IP using 'traceroute6 -s' 

traceroute6 to wfe0.ysv.freebsd.org (2001:1900:2254:206a::50:0) from 
:::1::1, 4 hops max, 12 byte packets
 1  * * *
 2  * * *


 Hmmm you do have 'gateway_enable=YES' and
 'ipv6_gateway_enable=YES' in your /etc/rc.conf ?

gateway_enable=YES
ipv6_gateway_enable=YES

Yes.  v4 continues to work fine.

Thanks,

Gary

Routing IPv6 over tun0 (PPPoE) issue

[Gary Palmer]

Hi,

I'm trying to set up IPv6 now that my ISP has decided to start offering
native V6.  I've been using a tunnelbroker setup until now.  I have

ipv6_gateway_enable=YES
ipv6_cpe_wanif=tun0

set in /etc/rc.conf and PPP has enable ipv6cp set.  OS is 
FreeBSD 9.3-RELEASE-p21

When the system boots up I get

tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492
options=8LINKSTATE
inet6 fe80::200:24ff:fec9:5bbc%tun0 prefixlen 64 scopeid 0xa 
inet 217.155.53.182 -- 62.3.83.6 netmask 0x 
inet6 :::2:200:24ff:fec9:5bbc prefixlen 64 autoconf 
nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL
Opened by PID 1038

Routing is

# netstat -nr -f inet6
Routing tables

Internet6:
Destination   Gateway   Flags  
Netif Expire
::/96 ::1   UGRSlo0 
=
default   fe80::230:88ff:fe16:ec4f%tun0 UG tun0
::1   link#9UH  lo0
etc


traceroute6 www.freebsd.org works when the traffic is sourced from the
tun0 interface IP

# traceroute6 www.freebsd.org
traceroute6 to wfe0.ysv.freebsd.org (2001:1900:2254:206a::50:0) from 
:::2:200:24ff:fec9:5bbc, 64 hops max, 12 byte packets
 1  :::3:0:0:2  29.030 ms  28.782 ms  29.205 ms
 2  ::0:301::  29.414 ms  28.967 ms  29.232 ms
 3  ::0:4::1  28.750 ms  29.253 ms  82.200 ms
 4  ::0:3::1  36.181 ms  35.352 ms  35.330 ms
etc

However if I configure other IPs on other interfaces from the netblock that
has been delegated to me and either source the traffic from those IPs or
try the traceroute from another computer using IPs in that netblock, I
don't even see the traffic leaving tun0 with tcpdump, let alone get any
replies.

I do have PF running, but all my rules that stop traffic are logged
and I don't see any hits in pflog.  Also, I tried turning pf off once
and didn't have any luck either, although I must admit I didn't leave it
off long for obvious reasons, so maybe I missed something in my test.

Any ideas?  Is it because I am routing to a link local address rather
than a routable IP?  Unfortunately the returned packets from the first
hop aren't in the subnet I was given for the link so I can't use that
as a gateway.

Thanks,

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

RFC7084 Basic Requirements for IPv6 Customer Edge Routers

[Gary Palmer]

Hi,

Does anyone know if FreeBSD 9.3 is compliant with RFC7034?  

Thanks,

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

Re: Exposing full 32bit RSS hash from card for ixgbe(4)

[Gary Palmer]

On Wed, Aug 05, 2015 at 02:10:09PM +, Barney Cordoba via freebsd-net wrote:
  
 
 
  On Wednesday, August 5, 2015 2:19 AM, Olivier Cochard-Labb?? 
 oliv...@cochard.me wrote:

 
  On Wed, Aug 5, 2015 at 1:15 AM, Barney Cordoba via freebsd-net 
 freebsd-net@freebsd.org wrote:
 
  What's the point of all of this gobbledygook anyway? Seriously, 99% of the
  world needs a driver that passes packets in the most efficient way, and
  every time I look at igb and ixgbe it has another 2 heads. It's up to 8
  heads, and none of the things wrong with it have been fixed. This is now
  even uglier than Kip Macy's cxgb abortion.
  I'm not trying to be snarky here. I wrote a simple driver 3 years ago that
  runs and runs and uses little cpu; maybe 8% for a full gig load on an E3.
 
 
 ???Hi,
 
 I will be very happy to bench your simple driver. Where can I download the
 sources ?
 
 Thanks,
 
 Olivier
 ___
 
 Another unproductive dick head on the FreeBSD team? Figures.

Barney,

Please refrain from swearing and ad hominem attacks on the FreeBSD lists.

Thank you

___
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: lagg of em0/em1 + VLAN = lower MTU?

[Gary Palmer]

On Mon, Jul 13, 2015 at 10:29:48AM +0100, Karl Pielorz wrote:
 
 
 --On 13 July 2015 10:51 +0200 Steve Read steve.r...@stormshield.eu wrote:
 
  Think about what it means.  The MTU on the lagg0 interface is the
  largest packet it can send for you or for its VLAN interfaces.  The MTU
  on the lagg0.10 (VLAN) interface is the largest packet *it* can send for
  you.  The VLAN tag is added to the packet that you give to lagg0.10, and
  so the MTU of lagg0.10 must be smaller than the MTU of lagg0.
 
 Ok, I understand all that (despite a bad cold!) - but looking at other 
 peoples ifconfig outputs found on google, they show:
 
  - Underlying interface, MTU 1500
  - LAGG interface, MTU 1500
  - VLAN sub interface, MTU 1500
 
 I don't get that - from the same ifconfig-uration I get:
 
  - Underlying interface, MTU 1500
  - LAGG interface, MTU 1500
  - VLAN sub interface, MTU 1496
 
 I thought if cards natively support VLAN's the VLAN tag was handled 'behind 
 the scenes' - e.g. if I go setup em3.10 - I wouldn't see the MTU drop to 
 1496.
 
 In fact, I've just done this with em3 on that machine...
 
 ifconfig em3.10 create
 ifconfig em3.10 inet 10.12.13.1 netmask 255.255.255.0
 ifconfig em3 inet 10.13.14.1 netmask 255.255.255.0
 
 ifconfig em3
 em3: flags=8c02BROADCAST,OACTIVE,SIMPLEX,MULTICAST metric 0 mtu 1500
 
 ifconfig em3.10
 em3.10: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 
 I realise the packets sent by em3.10 will now be 1504 bytes MTU - and if 
 your switch doesn't support VLAN's (and/or can only cope with strict 1500 
 byte packets you're probably in trouble) - but the above is doing what I'd 
 expect to happen for the LAGG case.
 
 I could understand losing the 4 bytes maybe if the card didn't support 
 native VLAN's (or having to do it if your switch can't cope with 1500+4 
 byte frames) - but not if they're supported.
 
  Note that the packet given to lagg0 is four bytes bigger than the packet
  given to lagg0.10, and this is always true.  If you make the MTU of
  lagg0.10 equal to the MTU of lagg0, then lagg0.10 will end up generating
  packets that are oversize for lagg0, and you don't want that.
 
 Yes, I get that - but as I said I thought 'native VLAN' tagging was handled 
 differently - as shown by the example above with em3.
 
 afaik - Lagging interfaces has no effect on MTU, but something behind the 
 scenes is treating lagg0.10 differently from, say em0.10 as far as MTU 
 configuration goes?
 
 Ultimately the question is - why are other people running the same ifconfig 
 (admittedly on different FreeBSD versions / cards) and getting what I'd 
 expect [a working system], but I don't?

Have you read the HARDWARE section of vlan(4)?

Regards,

Gary
___
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: Same NIC name to MAC mapping on FreeBSD

[Gary Palmer]

On Wed, Jul 01, 2015 at 11:42:43AM +0800, Julian Elischer wrote:
 On 7/1/15 6:56 AM, Adrian Chadd wrote:
  Hi,
 
  If we don't support this as part of the interface renaming stuff, it
  would certainly be good to.
 
 
  a-
 
 
  On 29 June 2015 at 21:36, Wei Hu w...@microsoft.com wrote:
  -Original Message-
  From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
  n...@freebsd.org] On Behalf Of Paul S.
  Sent: Monday, June 29, 2015 7:53 PM
  To: freebsd-net@freebsd.org
  Subject: Re: Same NIC name to MAC mapping on FreeBSD
 
  On my production systems, I've never seen it deviate without hardware
  changes.
 
  Are you seeing otherwise?
 
  In Hyper-V, if say three NICs were assigned to the VM, I got following 
  mapping
  Initially:
 
  Hn0 - MAC 0
  Hn1 - MAC 1
  Hn2 - MAC2
 
  Then if I remove the NIC with MAC 1 and reboot, I want the other two 
  interfaces to keep the same
  Names instead of reassigning hn1 to MAC2. This is a requirement from 
  virtual appliance
  Vendor to retain such mappings.  I am wondering if there is any way to do 
  this without
  Asking customer or manually editing any config files.
 do interface arrivals show up in devd? if so they could be renamed on 
 arrival
 I vaguely remember being able to do this some years ago but I can't 
 remember the details.

I believe they do, yes.  In fact I seem to remember a discussion on this
in the last year and someone shared either a devd or an rc.d script to 
ensure static NIC names, however searching the web archvies I couldn't
find it

Regards,

Gary
___
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: net.inet.ip.forwarding is mysteriously set to 0

[Gary Palmer]

On Sat, Apr 25, 2015 at 01:47:50AM +0900, Paul S. wrote:
 Can confirm that anything to do with netif restart on a forwarding 
 interface also creates the same problem.
 
 On 4/25/2015 ?? 01:46, Nikos Vassiliadis wrote:
  Hi,
 
  Just saw this. Can somebody re-produce this?
 
  root@m4fh2:~ # sysctl net.inet.ip.forwarding
  net.inet.ip.forwarding: 1
  root@m4fh2:~ # ifconfig bridge0 create
  root@m4fh2:~ # sysctl net.inet.ip.forwarding
  net.inet.ip.forwarding: 0
 
  That's on GENERIC 10-STABLE from the day before yesterday.
 
  Thanks,
  Nikos

What is your setting for gateway_enable in /etc/rc.conf?

Gary
___
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: What is this?

[Gary Palmer]

On Wed, Feb 25, 2015 at 09:30:49PM +1100, Ian Smith wrote:
 This snippet is from an old linux 2.4 router/firewall/proxy box, usually 
 clockwork.  Clipped this while monitoring one night, saved it, forgot, 
 but still find it curious and haven't seen anything similar before or
 since.  31.13.70.1  173.252.102.24 are facebook, our guy 192.168.9.21
 
 25/9/2014 what?  rpc?  no rpc here even internally.  .21 is a win7 box.
 
 22:34:15.753436 IP 31.13.70.1.443  192.168.9.21.3721: . 21784:23236(1452) 
 ack 15573 win 65340
 22:34:15.753560 IP 31.13.70.1.443  192.168.9.21.3721: P 23236:23661(425) ack 
 15573 win 65340
 22:34:15.754017 IP 192.168.9.21.3721  31.13.70.1.443: . ack 23661 win 65535
 22:34:15.828235 IP 173.252.102.24.3660741704  192.168.9.21.2049: 735 
 proc-3090265999
 22:34:15.837027 IP 192.168.9.21.2049  173.252.102.24.3355443200: reply 
 Unknown rpc response code=239244857 1452
 22:34:15.837031 IP 192.168.9.21.2049  173.252.102.24.1494367229: reply 
 Unknown rpc response code=3295742795 33
 22:34:15.875408 IP 31.13.70.1.443  192.168.9.21.3721: . 23661:25113(1452) 
 ack 15573 win 65340
 22:34:15.875552 IP 31.13.70.1.443  192.168.9.21.3721: P 25113:25677(564) ack 
 15573 win 65340
 22:34:15.875976 IP 192.168.9.21.3721  31.13.70.1.443: . ack 25677 win 65535
 22:34:16.114979 IP 173.252.102.24.443  192.168.9.21.2049: . ack 3841 win 
 64670
 22:34:16.116361 IP 173.252.102.24.443  192.168.9.21.2049: . ack 3874 win 
 64670
 22:34:16.117679 IP 173.252.102.24.4046617672  192.168.9.21.2049: 758 
 proc-685943137
 22:34:16.124011 IP 192.168.9.21.2049  173.252.102.24.2483027968: reply 
 Unknown rpc response code=255805058 1177
 22:34:16.44 IP 173.252.102.24.443  192.168.9.21.2049: . ack 5051 win 
 64670
 22:34:20.928488 IP 173.252.102.24.2100460616  192.168.9.21.2049: 1410 
 proc-3156600121
 22:34:20.935755 IP 192.168.9.21.2049  173.252.102.24.2483027968: reply 
 Unknown rpc response code=269780798 1177
 22:34:21.211544 IP 173.252.102.24.443  192.168.9.21.2049: . ack 6228 win 
 64670
 
 Kick me downstairs if it's just some old linux thing, especially the 2-3 
 giga(what?) port numbers, but otherwise, what is this about?

Supposition: whatever you are using on Linux is seeing the 2049 port
number and trying to decode the packet as NFS traffic even though
it's not, and the port number isn't a port number at all but a NFS handle
or something, but it isn't really, it's just some data from the packet
contents that is in the location where the handle would be if the packet
were truly NFS.

Regards,

Gary
___
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: dropped due to the socket

[Gary Palmer]

On Mon, Oct 27, 2014 at 09:31:04AM -0200, Tiago Felipe wrote:
 Maybe, but do not believe it, because when you turn it on, the counter


Turn what on, exactly?


 dropped due to the socket has gradually increased, this machine acts


Please provide the exact output from the netstat -s -s command that
you are talking about.  There is no such statistic
dropped due to the socket.


 as pppoe concentrator, mpd5 and netgraph ..
 I have clients with public IP and nat44.
 
 I'm doing tests yet, but I've read a lot about and looked for similar
 problems, could not come to a conclusion ...


If you are referring to dropped due to no socket it means that 
a UDP packet arrived for a port that had no socket listening on it.

If you are referring to another statistic please provide the *exact*
statistic

If you want to see what UDP requests are being dropped due to no
socket then run this as root:

sysctl net.inet.udp.log_in_vain=1

it may produce a LOT of logs, so to turn it off again to:

sysctl net.inet.udp.log_in_vain=0

The log_in_vain output should go to the console and anywhere in syslog
you have configured to receive kern.info syslog events.

If you have an idle system where the counter is not incrementing
and it is passing no traffic (a VM with no network would be ideal)
you can test the behaviour of the dropped due to no socket statistic 
yourself.

Run:

netstat -s -s | grep 'dropped due to no socket'
traceroute localhost
netstat -s -s | grep 'dropped due to no socket'

The 'dropped due to no socket' count should go up by 3, for the 3
traceroute packets that tried to connect to a port that had no listening
socket.  You can use the net.inet.udp.log_in_vain sysctl to see the 3
traceroute packets during the test if you are interested. 

If you aren't running any firewalls, then as Steve mentioned the most
likely reason is people scanning your box looking for vulnerabilities. 
e.g. I see people try to hit the SIP port (UDP 5060) every day on IPs
that don't run any SIP services.  It's also possible that some
customer equipment is hitting ports on your PPPOE termination boxes
as the box is the other end of the PPPOE session and the customer
equipment is trying to use that other end for services, e.g. DNS, NTP
or similar, even if your PPP session points them elsewhere for those
services

Regards,

Gary

 
 
 Thank you
 
 On 27/10/14 09:21, Steven Hartland wrote:
  I assume you mean dropped due to *no *socket which means your seeing
  requests to a port which isn't open, possibly due to being port scanned?
  
  On 27/10/2014 11:00, Tiago Felipe wrote:
  Good afternoon!
 
  I have seen dropped due to the socket on multiple servers with
  Freebsd, this case is a Release 10.
  # Netstat -s -s
  ...
  4614884 dropped due to the socket
  ...
 
  In this case the current flow is 700mbits download and 80mbits upload,
  averaging 130kpps.
 
  I've done many changes in sysctl.conf and loader.conf, swapped hardware
  and have not had many improvements.
 
  Can anyone tell me the reason? I'm looking for it to weeks, but still no
  result.
 
 
  Thank you so much.
 
 
  
  ___
  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
 
 -- 
 []s
 


___
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: Juniper Secure Access SSL VPN access from FreeBSD?

[Gary Palmer]

On Mon, Sep 15, 2014 at 07:30:33PM +0400, Lev Serebryakov wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 
  If I want to connect to my workstation at $work, I'm forced to use
 Juniper Secure Access SSL VPN + rdesktop. I connect to our office
 JunOS gateway with browser, and run RDesktop from it. But it requires
 to use supported OS (Windows / MacOS X / Linux), as tunnel is created
 via binary browser plugin.
 
  Is it possible to emulate this on FreeBSD? rdesktop from ports should
 work as client, as I access standard Windows system, but I need some
 way to emulate this VPN tunnel. Is it possible?

Did you try any of the results from Google?  Search for
juniper ssl vpn open source (without the quotes) seems to show up
some possibilities.

Regards,

Gary
___
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: Juniper Secure Access SSL VPN access from FreeBSD?

[Gary Palmer]

On Mon, Sep 15, 2014 at 08:12:51PM +0400, Lev Serebryakov wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 On 15.09.2014 20:02, Gary Palmer wrote:
 
  If I want to connect to my workstation at $work, I'm forced to
  use Juniper Secure Access SSL VPN + rdesktop. I connect to our
  office JunOS gateway with browser, and run RDesktop from it. But
  it requires to use supported OS (Windows / MacOS X / Linux), as
  tunnel is created via binary browser plugin.
  
  Is it possible to emulate this on FreeBSD? rdesktop from ports
  should work as client, as I access standard Windows system, but I
  need some way to emulate this VPN tunnel. Is it possible?
  
  Did you try any of the results from Google?  Search for juniper
  ssl vpn open source (without the quotes) seems to show up some
  possibilities.
  Yep, but all of them based on fact, that it works under Linux. For
 example, here are script (jvpn.pl), which emulates browser, but it
 loads Linux-specific share object from browser plugin (libncui.so) and
 calls Linux binary (ncsvc), and it will not natively work under FreeBSD.
 
  Linux emulator is my last resort, but maybe, here are some other ways?


Not that work reliably.  I know someone who had to use a Juniper VPN
solution and got it working under Linux without any binary plugins,
but he went on vacation and when he came back a couple of weeks later 
he couldn't get it working again and struggled for days before giving up
and running Windows in a VM.

As best I understand it, it's a standard IPSEC VPN, but getting past the
authentication to get to the IPSEC session is the tricky part.

Regards,

Gary
___
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: Juniper Secure Access SSL VPN access from FreeBSD?

[Gary Palmer]

On Mon, Sep 15, 2014 at 05:20:05PM +0100, Gary Palmer wrote:
 On Mon, Sep 15, 2014 at 08:12:51PM +0400, Lev Serebryakov wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA512
  
  On 15.09.2014 20:02, Gary Palmer wrote:
  
   If I want to connect to my workstation at $work, I'm forced to
   use Juniper Secure Access SSL VPN + rdesktop. I connect to our
   office JunOS gateway with browser, and run RDesktop from it. But
   it requires to use supported OS (Windows / MacOS X / Linux), as
   tunnel is created via binary browser plugin.
   
   Is it possible to emulate this on FreeBSD? rdesktop from ports
   should work as client, as I access standard Windows system, but I
   need some way to emulate this VPN tunnel. Is it possible?
   
   Did you try any of the results from Google?  Search for juniper
   ssl vpn open source (without the quotes) seems to show up some
   possibilities.
   Yep, but all of them based on fact, that it works under Linux. For
  example, here are script (jvpn.pl), which emulates browser, but it
  loads Linux-specific share object from browser plugin (libncui.so) and
  calls Linux binary (ncsvc), and it will not natively work under FreeBSD.
  
   Linux emulator is my last resort, but maybe, here are some other ways?
 
 
 Not that work reliably.  I know someone who had to use a Juniper VPN
 solution and got it working under Linux without any binary plugins,
 but he went on vacation and when he came back a couple of weeks later 
 he couldn't get it working again and struggled for days before giving up
 and running Windows in a VM.
 
 As best I understand it, it's a standard IPSEC VPN, but getting past the
 authentication to get to the IPSEC session is the tricky part.
 
 Regards,
 
 Gary

You might want to try https://www.shrew.net/download/ike - it claims to
support Juniper secure gateways and runs on FreeBSD.  I have no idea if it
works or not.

Regards,

Gary
___
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: Gateway?

[Gary Palmer]

On Sat, May 17, 2014 at 04:17:12PM -0700, Ronald F. Guilmette wrote:
 
 Forgive me, please for such a rudimentary sort of question.  I've
 been doing IP networking for more than 15 years, but I never really
 plumbed the depths, and thus I only know the basics.
 
 Quite simply, I'd like to know if the defaultrouter= IPv4 address
 specified in my /etc/rc.conf file should be the same as whatever
 I normally see as the first hop in an outgoing traceroute.  I ask
 because for me these two are apparently not the same.  Here's what
 I have:
 
 defaultrouter=69.62.255.254
 
 and here is one example of a recent outgoing traceroute:
 
 % traceroute 74.125.239.148
 traceroute to 74.125.239.148 (74.125.239.148), 64 hops max, 52 byte packets
  1  86.255-62-69.res.dyn.surewest.net (69.62.255.86)  28.884 ms  31.395 ms  
 30.024 ms
  2  216.0.55.209 (216.0.55.209)  26.486 ms  26.024 ms  25.850 ms
  3  ae1d0.mcr1.roseville-ca.us.xo.net (216.156.1.77)  25.384 ms  27.298 ms  
 27.060 ms
  4  vb1510.rar3.sanjose-ca.us.xo.net (216.156.0.153)  27.289 ms  34.022 ms  
 36.213 ms
  5  207.88.14.226.ptr.us.xo.net (207.88.14.226)  26.993 ms  26.567 ms  25.568 
 ms
  6  216.156.84.30.ptr.us.xo.net (216.156.84.30)  24.800 ms  26.432 ms  25.845 
 ms
  7  209.85.249.5 (209.85.249.5)  26.033 ms  110.066 ms  28.663 ms
  8  66.249.95.31 (66.249.95.31)  26.985 ms  25.285 ms  28.066 ms
  9  nuq05s02-in-f20.1e100.net (74.125.239.148)  26.895 ms  27.434 ms  27.063 
 ms

They could be using some kind of HSRP or VRRP, and the above behaviour would
be normal (at least it was the last time I ran HSRP).  You set the route to
the failover address, but traceroute sees the response from the actual 
interface address on whichever gateway handles the packet.

e.g. 

router 1 interface 0 has IP x.x.x.2 and is the HSRP master
router 2 interface 0 has IP x.x.x.3 and is the HSRP backup
HSRP IP is x.x.x.1

Traceroute out and you normally see the answer from the first hop as x.x.x.2

There are other tricks they could be doing as well which would also
give the above behaviour.  

Regards,

Gary
___
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: ipfilter(4) needs maintainer

[Gary Palmer]

On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
 Is it possible to move ipfilter into a port?

That may work short term, but the ENOMAINTAINER problem will quickly creep
up again as kernel APIs change.  If the author has lost interest in
maintaining the FreeBSD port of ipfilter then unless someone steps forward
to carry on the work, I don't see much of a future for ipfilter in
FreeBSD

Do we honestly need three packet filters?

Regards,

Gary
___
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: Default route destination changing without warning follow-up

[Gary Palmer]

On Thu, Oct 04, 2012 at 07:36:51PM +0200, Krzysztof Barcikowski wrote:
 W dniu 2012-10-04 18:02, John-Mark Gurney pisze:
  Alexander V. Chernikov wrote this message on Mon, Oct 01, 2012 at 01:07 
  +0400:
  On 01.10.2012 00:59, Dominic Blais wrote:
  It's all about IPv4 in my case.
  It will be great to supply some more details (e.g. like FreeBSD version,
  interfaces configuration, netstat -rn output).
 
  How often does this happen ?
  (e.g. while true; do echo -n `date` ; route -n get default | grep gate;
  sleep 1; done can help)
 
  If this is reproducible, what actions precedes this change?
  Maybe some ARP traffic on that interface, or interface
  creation/deletion, or.. ?
 
  Is route monitor completely silent when the change happens?
  Just for refernece, Dominic brought this up in an earlier thread:
  http://www.freebsd.org/cgi/mid.cgi?2de61b0869b7484997bca012845482c7ebe62dd...@win2008.domnt.abi.ca
 
  and at least on other person seems to have the same issue...
 
  quick question for you Dominic, do you see the correct number of routes,
  but a new wrong one appear?  or does the route just simply disapear? or
  does a new one seem to replace the old one?
 
  The reason I ask is that if a new wrong one appears, it could be memory
  corruption, but if a new one replaces the old one, for some reason when
  allocating a new route, it could accidentatlly be replacing the default
  route...
 
  Just some thoughts...
 
 
 Hi,
 
 I don't see a second new route appearing in my case, just the default or 
 static route is replaced.
 I'm not conviced of memory corruption, as it happens on 3 different 
 physical machines.

Sorry for jumping into the middle of the thread (and apologies if this was
asked/answered previously), however what are the settings for the following
sysctls?

net.inet.icmp.log_redirect
net.inet.icmp.drop_redirect

and potentially

net.inet6.ip6.redirect
net.inet6.icmp6.rediraccept

Gary
___
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: kern/161899: Repeating RTM_MISS packets causing high CPU load for ntpd

[Gary Palmer]

On Wed, Feb 08, 2012 at 01:44:56PM -, Steven Hartland wrote:
 - Original Message - 
 From: Gleb Smirnoff gleb...@freebsd.org
  Any update on this, would have been nice to see a fix hit before
  9.0. If you need any more information please let me know.
 
 AFAIK, this is no longer a problem in 9.0-RELEASE or in HEAD.
 
 The cause for this number of misses is absense of a route for
 IPv4 mapped block in IPv6 routing table.
 
 Here it is:
 
 # netstat -rn -f inet6 
 Routing tables
 
 Internet6:
 Destination   Gateway   Flags  
 Netif Expire
 ::/96 ::1   UGRS   
 lo0
 
 Some rc.d script installs this prefix in 9.0 and 10.0. If it hasn't
 been merged to stable/8, then it needs to be found and merged.
 
 Thanks Gleb!
 
 Running the following commands does indeed stop this
 route add -inet6 :::0.0.0.0 -prefixlen 96 ::1 -reject
 route add -inet6 ::0.0.0.0 -prefixlen 96 ::1 -reject
 
 I found these in /etc/rc.d/network_ipv6 but I can't see why
 these wouldnt be run on a machine that doesn't have an IPv6
 address, they seem to be added correctly on machines that do.

Speculation: the machine(s) which didn't have the routes maybe
didn't have

ipv6_enable=YES

in /etc/rc.conf?

Gary
___
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: em0 hangs on 8-STABLE again

[Gary Palmer]

On Wed, Feb 01, 2012 at 01:50:23PM -0800, Jack Vogel wrote:
 Huh? I MFC'd into stable/8 does that show up as RELENG?

I suspect different SCMs here is causing terminology confusion.  RELENG_8
is the CVS version of the stable/8 branch in SVN.

Gary

___
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: [urtw] Wifi link dying randomly. reboot required to reconnect.

[Gary Palmer]

On Wed, Oct 05, 2011 at 11:56:41PM -0500, Chuck Burns wrote:
 On Wednesday, October 05, 2011 11:47:01 PM Adrian Chadd wrote:
  On 6 October 2011 07:50, Chuck Burns brea...@gmail.com wrote:
   Ok, it crashed this evening.. Got a snapshot of it with my wife's digital
   camera..
   
   http://imageshack.us/photo/my-images/851/kernelcrash.jpg/
   
   There is a small flash dot as the camera's flash went off, but 99% of
   it is readable. (thought I'd turned off the flash).
   
   Also, as a side note, the machine has a large enough swapfile for a crash
   dump.. and it didnt reboot reboot on it's own even though it says it
   will..
  
  So it didn't crashdump?
  
  Unless data[] is completely invalid (eg NULL), I can't see how that
  function would panic..
  
  
  Adrian
 No.. it claimed there was no valid dump device configured..

Do you have a /dev/dumpdev symbolic link pointing to a swap partition?
If not, the dump device may not have been configured.

Also, apologies if you said this earlier, but which version of FreeBSD
are you running?

Gary
___
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: [urtw] Wifi link dying randomly. reboot required to reconnect.

[Gary Palmer]

On Thu, Oct 06, 2011 at 07:02:15PM -0500, Chuck Burns wrote:
  Do you have a /dev/dumpdev symbolic link pointing to a swap partition?
  If not, the dump device may not have been configured.
  
  Also, apologies if you said this earlier, but which version of FreeBSD
  are you running?
  
  Gary
 
 I didn't have that link, but I just linked it to my 6G swap partition (I have 
 4G of ram) at /dev/ada0p2 - using GPT, and zfs-on-root.

Actually, that won't be enough.  Sorry if I gave that idea.  If you check
/etc/rc.d/dumpon then you'll see that if the script succeeds in telling
the kernel to dump on a given swap partition then it creates the
symlink in the /dev directory.  I couldn't see any other easy way to
check if your kernel had been configured to dump to the swap partition or
not.

Do you have a dumpdev setting in /etc/rc.conf?  Does /etc/fstab list
/dev/ada0p2 as a swap partition?

Thanks for the configuration info.  

Gary
___
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: [urtw] Wifi link dying randomly. reboot required to reconnect.

[Gary Palmer]

On Tue, Oct 04, 2011 at 09:32:52PM -0500, Chuck Burns wrote:
 On Tuesday, October 04, 2011 8:54:33 PM Chuck Burns wrote:
 snip
  I'm not sure how to rebuild just the module with that option URTW_DEBUG
  enabled.. I'm being told by some to just add the device to my kernel config
  along with the line option URTW_DEBUG .. but if there's a better way, let
  me know please.
  
  Also, I suppose that means if I want the any I sysctl
  hw.usb.urtw.debug=0x right? Still a bit green with regards to
  debugging.
 
 I wound up adding #define URTW_DEBUG to the top of the if_urtw.c file and 
 make install'ing the module from the proper subdirectory..

Just wanted to make sure that you unloaded and reloaded the module after
the make install?

Gary
___
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: gif interface not passing IPv6 packets

[Gary Palmer]

On Mon, Sep 26, 2011 at 10:27:53AM +0100, Matt Smith wrote:
 I have a very strange problem with a gif interface that has been
 confusing me all weekend. For the last six months I have had a gif
 tunnel setup to an ipv6 tunnel broker which has worked without any
 issues. On Friday I had a power cut. The power returned, the server
 restarted, and the tunnel has been down since. I have checked and
 rechecked the configuration and it all looks identical to what I would
 expect. I've even gone as far as running a buildworld/kernel in case
 the power outage corrupted something.
 
 The problem is that the gif interface doesn't appear to be processing
 any IPv6 packets at all, though it works fine with IPv4. I can't ping
 my side of the tunnel. For example:
 
 root@tao[~]# ifconfig gif0
 gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280
 tunnel inet 192.168.1.2 -- 77.75.104.126
 inet6 fe80::240:63ff:fee8:793e%gif0 prefixlen 64 scopeid 0x5
 inet6 2a01:348:6:45c::2 -- 2a01:348:6:45c::1 prefixlen 128 deprecated
 nd6 options=3PERFORMNUD,ACCEPT_RTADV
 options=1ACCEPT_REV_ETHIP_VER
 
 root@tao[~]# ping6 2a01:348:6:45c::2
 PING6(56=40+8+8 bytes) 2a01:348:6:45c::2 -- 2a01:348:6:45c::2
 
 root@tao[~]# tcpdump -i gif0
 listening on gif0, link-type NULL (BSD loopback), capture size 96 bytes
 10:15:12.545930 IP6 cl-1117.lon-02.gb.sixxs.net 
 cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 0, length 16
 10:15:13.546316 IP6 cl-1117.lon-02.gb.sixxs.net 
 cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 1, length 16
 10:15:14.546220 IP6 cl-1117.lon-02.gb.sixxs.net 
 cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 2, length 16
 
 I've deleted other lines from the tcpdump like neighbour solicitation
 and only shown the pings. But there is no ping response, only the
 request.

Do you have access to any other IPv6 hosts on a separate link?  If so,
I would suggest trying a ping or traceroute back to your IP or
IPs across the tunnel and see if the packets are getting back to you.
It may be a problem at the other end somewhere.  Check with tcpdump
of both the IPv4 and IPv6 layers to see if the packets are getting
to the kernel but not to the gif interface.  Also see if your router
is passing packets.  If you had a power cut the router may have had
some issues and may not be passing the protocol 41 packets.

Also, check the sixxs.net docs to make sure you're allowing through
necessary packets.  I use tunnelbroker.net and they require (or say
they do) some packets to get through for the tunnel to stay up, e.g.
an IPv4 ping.

Gary
___
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: gif interface not passing IPv6 packets

[Gary Palmer]

On Mon, Sep 26, 2011 at 02:49:15PM +0100, Matt Smith wrote:
 On 26 September 2011 14:29, Gary Palmer gpal...@freebsd.org wrote:
  On Mon, Sep 26, 2011 at 10:27:53AM +0100, Matt Smith wrote:
  Do you have access to any other IPv6 hosts on a separate link? ?If so,
  I would suggest trying a ping or traceroute back to your IP or
  IPs across the tunnel and see if the packets are getting back to you.
  It may be a problem at the other end somewhere. ?Check with tcpdump
  of both the IPv4 and IPv6 layers to see if the packets are getting
  to the kernel but not to the gif interface. ?Also see if your router
  is passing packets. ?If you had a power cut the router may have had
  some issues and may not be passing the protocol 41 packets.
 
  Also, check the sixxs.net docs to make sure you're allowing through
  necessary packets. ?I use tunnelbroker.net and they require (or say
  they do) some packets to get through for the tunnel to stay up, e.g.
  an IPv4 ping.
 
 
 The router is configured to just send all incoming traffic to
 192.168.1.2, DMZ mode. This includes all protocols. I then use ipfw on
 the server to firewall it, though even flushing all rules and
 completely opening the firewall it still doesn't work. I think you're
 missing the main issue I have here, which is that the local side
 doesn't work. If the local side doesn't work then the remote side is
 irrelevant right now.
 
 Point is try this on any FreeBSD box and it will work (I did this
 earlier today on a friends FreeBSD server to verify):
 
 ifconfig gif0 create
 ifconfig gif0 tunnel local_lan_ip 1.2.3.4
 ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128
 ping6 2abc::2
 ifconfig gif0 destroy
 
 With that config you should be able to talk locally to 2abc::2 because
 that's just a local IP on your box. The rest of the config or the
 state of the internet connection/NAT etc doesn't matter because you're
 talking to a non existent IP anyway.
 
 On my box this doesn't work since the power cut but worked perfectly
 well before. tcpdump of gif0 shows ping requests but no ping
 responses. It's as if all IPv6 traffic into gif0 is blackholed.
 However if I configure an IPv4 address on it with ifconfig gif0
 10.1.1.2 10.1.1.1 then I can happily ping 10.1.1.2. So this just
 affects IPv6.

Sorry, I missed that as I didn't look closely enough at the IP
you were pinging and with DNS resolution left on in the tcpdump
I just assumed that sixxs.net has a weird DNS setup.

Smells like a routing table problem or similar configuration problem. 
On my tunnel endpoint, admitedly running 7.4 not 8.x or head, pings
to the LOCAL endpoint of the gif0 tunnel go over lo0, not the external
interface (gif0).  I believe that is true for all IPv4 or IPv6 traffic.

e.g.

# ifconfig gif0 
ifconfig: interface gif0 does not exist
# ifconfig gif0 create
# ifconfig gif0 tunnel 10.10.242.10 1.2.3.4
# ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128
# ping6 2abc::2
PING6(56=40+8+8 bytes) 2abc::2 -- 2abc::2
16 bytes from 2abc::2, icmp_seq=0 hlim=64 time=0.290 ms
16 bytes from 2abc::2, icmp_seq=1 hlim=64 time=0.183 ms
^C
--- 2abc::2 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.183/0.236/0.290/0.054 ms

# ifconfig gif0 destroy

In another window on the same host

# tcpdump -n -p -i lo0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes
15:18:20.611469 IP6 2abc::2  2abc::2: ICMP6, echo request, seq 0, length 16
15:18:20.611524 IP6 2abc::2  2abc::2: ICMP6, echo reply, seq 0, length 16
15:18:21.611673 IP6 2abc::2  2abc::2: ICMP6, echo request, seq 1, length 16
15:18:21.611752 IP6 2abc::2  2abc::2: ICMP6, echo reply, seq 1, length 16
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

Regards,

Gary
___
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: gif interface not passing IPv6 packets

[Gary Palmer]

On Mon, Sep 26, 2011 at 04:04:00PM +0100, Matt Smith wrote:
 On 26 September 2011 15:21, Gary Palmer gpal...@freebsd.org wrote:
  Smells like a routing table problem or similar configuration problem.
  On my tunnel endpoint, admitedly running 7.4 not 8.x or head, pings
  to the LOCAL endpoint of the gif0 tunnel go over lo0, not the external
  interface (gif0). ?I believe that is true for all IPv4 or IPv6 traffic.
 
 Interesting. You could be right then. But I still don't understand
 what could have changed as the rc.conf configuration for this is
 identical to what it was before the power cut. The deprecated part
 just makes the outgoing source address algorithm favour the vr0
 address, but the same happens no matter if I include that or not.

Not sure, however an experiment may be in order

# ifconfig gif0 
ifconfig: interface gif0 does not exist
# ifconfig gif0 create
# ifconfig gif0 tunnel lan IP 1.2.3.4
# ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128
# netstat -nr -f inet6 | grep 2abc
2abc::1   link#8UHLgif0
2abc::2   link#8UHL lo0
# ifconfig gif0 destroy

See if your routing table is correct after the test you proposed earlier.

Gary
___
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: system locks up with vr driver on alix board

[Gary Palmer]

On Wed, Aug 17, 2011 at 09:15:34AM +0100, Andrew Stevenson wrote:
 
 On 17 Aug 2011, at 02:39, Ask Bj?rn Hansen wrote:
 
  How many PPS or interrupts do you see from vr interface under high
  network load?
  
  Honestly I'm not sure.  I only know how to see the interrupt busy 
  percentage from top ?Is there a cheap way to get those numbers?If 
  so then I'll log them every second or two and see if it catches anything.
 
 systat -vmstat shows interrupts per second per device. Some use of awk or 
 sed may be required.

vmstat -i is probably closer to what the OP is looking for

Regards,

Gary
___
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: Debugging dropped shell connections over a VPN

[Gary Palmer]

On Tue, Jul 26, 2011 at 01:35:16PM -0500, Paul Keusemann wrote:
 On 07/26/11 08:05, Gary Palmer wrote:
 On Tue, Jul 26, 2011 at 06:53:59AM -0500, Paul Keusemann wrote:
 Again, sorry for the sluggish response.
 
 On 07/20/11 15:15, Gary Palmer wrote:
 On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote:
 On 07/07/11 14:39, Chuck Swiger wrote:
 On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote:
 My setup is something like this:
 - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris
 machines running various OS versions.
 - My gateway / firewall  machine is running FreeBSD-8.1-RELEASE-p1 
 with
 ipfw, nat and racoon for the firewall and VPN.
 
 The problem is that rlogin, ssh and telnet connections over the VPN 
 get
 dropped after some period of inactivity.
 You're probably getting NAT timeouts against the VPN connection if it 
 is
 left idle.  racoon ought to have a config setting called natt_keepalive
 which sends periodic keepalives-- see whether that's disabled.
 
 Regards,
 Thanks for the suggestions Chuck, sorry it's taken so long to respond
 but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in
 order to try this out.
 
 One thing that I did not explicitly mention before is that I am routing
 a network over the VPN.
 Hi Paul,
 
 Even if you are not being NAT'd on the VPN there may be a firewall (or
 other active network component like a load balancer) with an
 overflowing state table somewhere at the remote end.  We see this
 frequently where I work with customer networks and the 
 firewall/VPN/network
 admin denies that its a time out issue so there is likely some device in
 the network that has a state table and if the connection is idle for a
 few minutes it gets dropped.
 Hmmm,  this seems likely.  Have you had any luck in finding the culprit
 and resolving the problem?
 Unfortunately no.  We know the problem exists but as a vendor we have
 very little success in getting the customer to identify the problematic
 device inside their network as it only seems to affect our connections
 to them when we are helping them with problems, so there is almost
 always something more important going on and the timeout issue gets put
 on the back burner and forgotten.  We've worked around it in some
 places by using the ssh 'ServerAliveInterval' directive to make ssh
 send packets and keep the session open even if we're idle, but that
 doesn't always work.
 
 OK, I found the ClientAliveInterval, and ClientAliveCountMax setting in 
 the ssh_config man page.  I assume these are what you are referring to.  
 I tried setting ClientAliveInterval to 15 seconds with 
 ClientAliveCountMax set to 3 and this seems to help.  I've only tried 
 this a couple of times but I have seen an ssh session stay alive for 
 over an hour.  The bad news is that the sessions are still getting 
 dropped, at least now I know when it happens.  Now I'm getting the 
 following message:
 
 Received disconnect from 10.64.20.69: 2: Timeout, your session not 
 responding.
 
 From a quick perusal of the openssh source, it is not obvious whether 
 this message is coming from the client or the server side.   Initially, 
 because the keep alive timer is a server side setting, I assumed the 
 message was coming from the server side but if the session is not 
 responding how is the message getting to the client?  If it is a client 
 side problem, then I have much more flexibility to fix.  All I can do is 
 whine about server side problems.


Hi Paul,

ServerAliveInterval is actually a client setting.  e.g.  put this in
your ~/.ssh/config file

host *
ServerAliveInterval 15

will set the client to ping the server every 15 seconds and try to
keep the connection alive.  You can replace '*' you want to be more
targeted in your configuration.

I've never played with the server side settings for various reasons.

Regards,

Gary
___
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: Debugging dropped shell connections over a VPN

[Gary Palmer]

On Tue, Jul 26, 2011 at 06:53:59AM -0500, Paul Keusemann wrote:
 Again, sorry for the sluggish response.
 
 On 07/20/11 15:15, Gary Palmer wrote:
 On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote:
 On 07/07/11 14:39, Chuck Swiger wrote:
 On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote:
 My setup is something like this:
 - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris
 machines running various OS versions.
 - My gateway / firewall  machine is running FreeBSD-8.1-RELEASE-p1 with
 ipfw, nat and racoon for the firewall and VPN.
 
 The problem is that rlogin, ssh and telnet connections over the VPN get
 dropped after some period of inactivity.
 You're probably getting NAT timeouts against the VPN connection if it is
 left idle.  racoon ought to have a config setting called natt_keepalive
 which sends periodic keepalives-- see whether that's disabled.
 
 Regards,
 Thanks for the suggestions Chuck, sorry it's taken so long to respond
 but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in
 order to try this out.
 
 One thing that I did not explicitly mention before is that I am routing
 a network over the VPN.
 Hi Paul,
 
 Even if you are not being NAT'd on the VPN there may be a firewall (or
 other active network component like a load balancer) with an
 overflowing state table somewhere at the remote end.  We see this
 frequently where I work with customer networks and the firewall/VPN/network
 admin denies that its a time out issue so there is likely some device in
 the network that has a state table and if the connection is idle for a
 few minutes it gets dropped.
 
 Hmmm,  this seems likely.  Have you had any luck in finding the culprit 
 and resolving the problem?

Unfortunately no.  We know the problem exists but as a vendor we have
very little success in getting the customer to identify the problematic
device inside their network as it only seems to affect our connections
to them when we are helping them with problems, so there is almost
always something more important going on and the timeout issue gets put
on the back burner and forgotten.  We've worked around it in some
places by using the ssh 'ServerAliveInterval' directive to make ssh
send packets and keep the session open even if we're idle, but that
doesn't always work.

Gary
___
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: Debugging dropped shell connections over a VPN

[Gary Palmer]

On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote:
 On 07/07/11 14:39, Chuck Swiger wrote:
 On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote:
 My setup is something like this:
 - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris 
 machines running various OS versions.
 - My gateway / firewall  machine is running FreeBSD-8.1-RELEASE-p1 with 
 ipfw, nat and racoon for the firewall and VPN.
 
 The problem is that rlogin, ssh and telnet connections over the VPN get 
 dropped after some period of inactivity.
 You're probably getting NAT timeouts against the VPN connection if it is 
 left idle.  racoon ought to have a config setting called natt_keepalive 
 which sends periodic keepalives-- see whether that's disabled.
 
 Regards,
 
 Thanks for the suggestions Chuck, sorry it's taken so long to respond 
 but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in 
 order to try this out.
 
 One thing that I did not explicitly mention before is that I am routing 
 a network over the VPN.

Hi Paul,

Even if you are not being NAT'd on the VPN there may be a firewall (or
other active network component like a load balancer) with an
overflowing state table somewhere at the remote end.  We see this 
frequently where I work with customer networks and the firewall/VPN/network
admin denies that its a time out issue so there is likely some device in
the network that has a state table and if the connection is idle for a
few minutes it gets dropped.

Regards,

Gary
___
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: netstat fix

[Gary Palmer]

On Tue, May 17, 2011 at 12:20:34PM -0400, Jason Hellenthal wrote:
 
 Michael,
 
 On Sun, May 08, 2011 at 07:23:37PM +0200, Michael Tuexen wrote:
  Dear all,
  
  fwip0  1500 Link#19 00:30:05:b3:50:0b:40:e4:0a:02:ff:fe:00:00:00:00   
   0 0 0  00 0  0 0
  
 
 I agree with your patch but on another note. You probably know better
 than I, Is it common for fwip* to have a MAC(hardware address) that long
 ?

Yes. My FreeBSD 7.4 box:

% ifconfig fwip0
fwip0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500
lladdr 80.5b.6.0.46.c.bd.0.a.2.ff.fe.0.0.0.0
% netstat -ni -I fwip0
NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
fwip0  1500 Link#5  80:5b:06:00:46:0c:bd:00:0a:02:ff:fe:00:00:00:00   
 0 00 0 0

Pretty sure I remember long MAC addresses on fwip0 as long as I've had the
FireWire card

Regards,

Gary
___
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: SNMP Network Auto Discovery software ... ?

[Gary Palmer]

On Wed, Apr 27, 2011 at 03:55:11PM -0300, Marc G. Fournier wrote:
 
 Would like to find something that runs on FreeBSD that I can use to map 
 our network, preferrably dumping to a database, and grabbing 
 information like: interface / ip / cpus / hostname, etc ...
 
 Server needs to run on FreeBSD ... needs to be able to commuicate, via 
 SNMP, with Windows, Cisco, Linux, FreeBSD, NetApp Filers, etc ...
 
 Would like it to be able to generate an overall map of our network, but, 
 also, be able to use it as a basis for keeping stuff liek nagios / cacti 
 up to date ...
 
 Web based interface into the database would be nice ...
 
 Is there anything like this available that runs on FreeBSD that ppl are 
 happily using?


net-mgmt/scotty3 in ports used to have a network discovery mode. Haven't
used it in years but it may be worth a look.

Gary
___
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: natd starting after firewall rules are loaded

[Gary Palmer]

On Sun, Apr 17, 2011 at 03:55:59PM +, rondzie...@comcast.net wrote:
 One other thing that's missing since 4.9 (and this probably needs 
 to go to some other list) is the kernel LINT file. Unless you already 
 know about these firewall options there is no where you can go 
 to find them. The documentation makes some mention about them, 
 but not all of them. I was lucky because I still had my old system lying 
 around that I could look at, but I found these options in the first 
 place because I looked at the LINT file and added any options 
 that I thought were pertinent. 
 
 man, i sound like my dad... back when I was your age, we had a 
 kernel LINT file, you kids these days don't know anything... :-)) 

/sys/conf/NOTES and /sys/arch/conf/NOTES

Regards,

Gary
___
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: 7-STABLE NFS: fatal: select lock: Permission denied

[Gary Palmer]

On Mon, Apr 04, 2011 at 06:44:21PM -0700, Chuck Swiger wrote:
 If you can, anyway-- but maildir is becoming more commonly used with the 
 growing popularity of Cyrus and Dovecot compared with UWash IMAP (which did 
 mbox and mbx).

Avoid UWash IMAP like the plague is my suggestion.  It has locking issues
even on local disk.  (e.g. one client opens folder read-only, another client
opens read-write, it is really easy to get complete garbage on the read-only
session if the read-write client deletes a message).  I've seen this happen.

Regards,

Gary

___
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: how to use freebsd8 dial the adsl for shuffering?

[Gary Palmer]

On Fri, Sep 10, 2010 at 01:54:10PM +0600, ??  
(Dmitriy Zamuraev) wrote:
  set device PPPoE:fx0
 
 is this correct ? maybe fxp0

If they have an ethernet to ADSL bridge on fxp0 then that is correct.  I
have a Linksys ADSL modem in brdiging mode and that syntax works for me.
In my case it says:

 set device PPPoE:vr1

Regards,

Gary

___
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: Does not work resolving IPv6 addresses via IPv4 DNS-server

[Gary Palmer]

On Sun, Aug 08, 2010 at 01:56:05PM +0900, Hiroki Sato wrote:
 Vladislav V. Prodan univers...@ukr.net wrote
   in 4c5e33bb.50...@ukr.net:
 
 un # host -6 2001:5c0:1000:b::599b 8.8.8.8
 un socket.c:1859: internal_send: :::8.8.8.8#53: Invalid argument
 un socket.c:1859: internal_send: :::8.8.8.8#53: Invalid argument
 un ;; connection timed out; no servers could be reached
 
  The above command specifies IPv4 as the transport to 8.8.8.8.

I believe you mean that the -6 flag specifies that the utility use 
IPv6 as the transport to reach the IPv4 address 8.8.8.8

Regards,

Gary
___
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: sockstat / netstat output 8.x vs 7.x

[Gary Palmer]

On Tue, May 11, 2010 at 12:20:02PM -0700, Wes Peters wrote:
 The output header is instructive:
 
 USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS
 www  httpd  18423 3  tcp4 6 *:80  *:*
 www  httpd  18423 4  tcp4   *:*   *:*
 www  httpd  25184 3  tcp4 6 *:80  *:*
 www  httpd  25184 4  tcp4   *:*   *:*
 
 Same as 7, it's the foreign address.  This is normally only useful for
 connected sockets.

Wes,

Your example has 2 LOCAL ADDRESS values of *:* in addition to the
*:* in the FOREIGN ADDRESS column.  I must admit I share Mike's puzzlement
as to the meaning of *:* as the local address of a listening socket for a
daemon

Regards,

Gary
___
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: 7.1-PRERELEASE : bad network performance (nfe0)

[Gary Palmer]

On Sun, Sep 28, 2008 at 01:43:12PM -0400, [EMAIL PROTECTED] wrote:
 I have the same problem on a Dell Poweredge SC440 when I transferred over
 50GB
 from a FreeBSD 5.4 box to my new Dell running 7.1.  Used a crossover cable
 and
 the link was 1000 full duplex, but could only get about 10M/s.  Very odd.
 Did a
 tcpdump and saw lots of bad checksum errors.
 
 What other troubleshooting steps can we take?  What could be the problem?

Please post the first few lines of ifconfig for bge0.  I'm suspecting
you'll see something like

em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING

(yes, I know thats an em, not bge, but I don't have any bge's around
 here)

Note that the options line say that receive and transmit checksum
offloading is enabled.  This means that for packets transmitted
by this system, tcpdump will show checksum errors as the kernel
is not generating the checksums, the ethernet card will.  Since
tcpdump is seeting the packet before the ethernet card does its
magic, you get the checksum errors on transmit.  Received packets
should be fine though.

Regards,

Gary
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Testing lagg

[Gary Palmer]

On Thu, May 29, 2008 at 11:05:18PM +0200, Andrea Venturoli wrote:
 Gary Palmer ha scritto:
 
 Does the switch have spanning tree enabled?
 
 Yes.
 Should it be?

It can be left on but if you can disable it on the ports that you
are using for lagg then that should help.  If you can't turn it off on
a per-port basis and you don't have a meshed switch topology then just
turn spanning tree off.  I think whats happening
is spanning tree is seeing a topology change and forcing a
renegotiation of the tree, which has the side effect of stopping
packet forwarding.  You could also turn down the spanning tree timers,
but there would still be a pause in the forwarding of packets

Regards,

Gary
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Testing lagg

[Gary Palmer]

On Wed, May 28, 2008 at 05:28:34PM +0200, Andrea Venturoli wrote:
 Hello.
 
 I've got a new box which features two gigabit ports and I though I'd try 
 lagg with LACP.
 
 On the box I put the following in /etc/rc.conf:
 
 ifconfig_em0=up
 ifconfig_em1=up
 ifconfig_lagg0=laggproto lacp laggport em0 laggport em1 192.168.100.101 
 netmask 255.255.255.0
 
 
 Then I aggregated the ports on the switch (3com).
 
 
 This seems to work fine, although I see a 30 seconds delay from the 
 moment a network cable is unplugged and the moment the network works again.
 Is this normal? Can this time be reduced?
 Any other hint or gotcha?

Does the switch have spanning tree enabled?

Regards,

Gary
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

if_vr MFC?

[Gary Palmer]

Hi,

Just wondering if if_vr is going to be merged back to RELENG_7 at any
point?  Its been in CURRENT for about a month at this point so it
should be OK I think?  I've been using your patch against RELENG_7
on a Soekris NET-5501 in testing for a few weeks now, no real traffic
but no problems either.

Thanks,

Gary
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: OS choice for an edge router

[Gary Palmer]

On Sat, Sep 08, 2007 at 01:32:25AM +0200, Christopher Arnold wrote:
 
 
 On Sat, 8 Sep 2007, Andre Oppermann wrote:
 
 There are no NICs known that can do packet forwarding offload.
 And neither is there support in FreeBSD for that.  You're probably
 confusing this with checksum offloading or TSO (TCP segmentation
 offloading) which isn't an issue with packet forwarding at all.
 
 This was my understanding to until the original poster inspired be to 
 google yet another time for a card supporting packet forwarding offload.
 
 To my suprise i found one!
 
 http://netfpga.org/

This might also prove a good routing platform:

http://www.tilera.com/products/boards.php


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

Re: OS choice for an edge router

[Gary Palmer]

Kirc Gover wrote:

Hi Gary, Thanks for your response.

Yes, the bus architecture would be either PCI-X or PCI-Express. Host CPU would 
be a high performance multi-core such as Xeon and NICs would be Intel.

One of my concern is on the native forwarding capability of FreeBSD OS and the execution 
of critical userland processes. I have experience before that a FreeBSD box configured as 
router appears to slow down the userland processes when the traffic load is high. I have 
verified this lately on 6.1, running on Athlon64 with 1G NIC cards with PF and ALTQ 
(queuing) enabled. I'm not  so sure if this is caused by PF or ALTQ. Looking at the 
processes using top, it could see that swi(x) net process is almost as near 
100% cpu utilization. At this state, the box can still forward traffic (not sure yet if 
the was a change in throughput) but I could notice the userland processes to be very 
slow, like  invoking any command from the shell (e.g. ls) will take so long to be 
executed and completed. Is this a know limitation or bug?
  


I'm probably not the best person to address that, but its my 
understanding that interrupts will preempt other activity such as 
userland processing.  Since there is often a requirement to service 
interrupts as a matter of priority (e.g. before the receive buffer in 
the NIC overflows) I'm not sure theres a way around it.  The performance 
improvements in 7.x, especially relating to multi-core/CPU environments 
might help.  The complexity of the PF / ALTQ rules can also have an 
impact, although I'm a little surprised that they counted towards 
interrupt activity, which your message seems to imply.


Gary

P.S.  Please don't top post.


Thanks a lot.
Kirc

Gary Palmer [EMAIL PROTECTED] wrote: On Fri, Sep 07, 2007 at 03:06:54AM 
+1000, Kirc Gover wrote:
  

We are in the stage of planning and research for a commercial development of an 
edge router that will be based mostly on OpenSource software. I would like to 
solicit for information and recommendation if FreeBSD is a suitable OS. The 
router is expected to withstand forwarding of sustained traffic from 10Mbps to 
1Gbps and maybe more than that. Are there any known limitations of FreeBSD in 
terms of architecture and performance? Can I just take out a FreeBSD as is and 
put it with the hardware without any specific or major refinements in its code? 
I'm  very much concerned with its capability in forwarding heavy sustained 
traffic. Packet loss should be at minimum and critical userland processes 
should working normally  even under heavy load. Are there any known specific 
limitations of FreeBSD? I have browsed through the archives and found a lot of 
hangups, deadlocks and freeze issues. What is the usual or minimum hardware 
requirement? Is soekris box enough, or dual core or ASIC
 based platforms? I'm aware that there are so many FreeBSD based routers and 
network based devices in the market. Is this a way to go over realtime and 
embedded OS such as VxWorks and others (mostly commercial) without putting the 
licensing cost in picture? I really appreciate any help, suggestions and 
recommendations. More power to FreeBSD!



Kirc,

There are two factors to consider:

- bus architecture (PCI, PCI-X, PCI-Express, etc) will dictate the
  maximum throughput in bits/sec.  Allow some overhead for bus arbitration
  activities, and remember that the packet crosses the bus twice, once
  on the inbound leg and once on the outbound leg.

- Host CPU (and perhaps to a limited extent the interface cards used)
  will dictate the packets per second (PPS)

Most commercial routers run out of packets per second (in real-world
situations, not lab mockups) long before the theoretical maximum
throughput is achieved. Thinks like ICMP ping packets and TCP RST
packets are small (less than 100 bytes usually) but normally take as much
CPU to process  route as a 1500 byte (or larger) packet.

The more you put in the processing path (e.g. packet filters, complex
routing tables) the more you reduce the PPS.

Gary


   
-

Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. Get it 
now.
  




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

Re: DDoS attacks ... identifying destination ...

[Gary Palmer]

On Thu, Sep 06, 2007 at 03:48:37PM -0300, Marc G. Fournier wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 Today, I got hit by an attack, but haven't been able to easily determine whom 
 was being attacked ...
 
 I run ipaudit to monitor bandwidth usage, so I have 'source / destination' 
 information, but I'm not finding any particularly easy way to narrow down 
 whom 
 was being attacked ...
 
 I run mrtg on the switch so that I know which *server* is being attacked, so 
 I 
 need some method of being able to see whom is being attacked so that I can 
 put 
 appropriate blocks in place ...
 
 Is there either a command line command, or ports tool, that I can use similar 
 to top, or systat -iostat, that will help identify the IP that is being 
 attacked?
 
 Thank you ...

net/trafshow will show throughput on various protocols on a host in a more
user friendly format than raw tcpdump alone.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: OS choice for an edge router

[Gary Palmer]

On Fri, Sep 07, 2007 at 03:06:54AM +1000, Kirc Gover wrote:
 We are in the stage of planning and research for a commercial development of 
 an edge router that will be based mostly on OpenSource software. I would like 
 to solicit for information and recommendation if FreeBSD is a suitable OS. 
 The router is expected to withstand forwarding of sustained traffic from 
 10Mbps to 1Gbps and maybe more than that. Are there any known limitations of 
 FreeBSD in terms of architecture and performance? Can I just take out a 
 FreeBSD as is and put it with the hardware without any specific or major 
 refinements in its code? I'm  very much concerned with its capability in 
 forwarding heavy sustained traffic. Packet loss should be at minimum and 
 critical userland processes should working normally  even under heavy load. 
 Are there any known specific limitations of FreeBSD? I have browsed through 
 the archives and found a lot of hangups, deadlocks and freeze issues. What is 
 the usual or minimum hardware requirement? Is soekris box enough, or dual 
 core or ASIC
  based platforms? I'm aware that there are so many FreeBSD based routers and 
 network based devices in the market. Is this a way to go over realtime and 
 embedded OS such as VxWorks and others (mostly commercial) without putting 
 the licensing cost in picture? I really appreciate any help, suggestions and 
 recommendations. More power to FreeBSD!

Kirc,

There are two factors to consider:

- bus architecture (PCI, PCI-X, PCI-Express, etc) will dictate the
  maximum throughput in bits/sec.  Allow some overhead for bus arbitration
  activities, and remember that the packet crosses the bus twice, once
  on the inbound leg and once on the outbound leg.

- Host CPU (and perhaps to a limited extent the interface cards used)
  will dictate the packets per second (PPS)

Most commercial routers run out of packets per second (in real-world
situations, not lab mockups) long before the theoretical maximum
throughput is achieved. Thinks like ICMP ping packets and TCP RST
packets are small (less than 100 bytes usually) but normally take as much
CPU to process  route as a 1500 byte (or larger) packet.

The more you put in the processing path (e.g. packet filters, complex
routing tables) the more you reduce the PPS.

Gary
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Add socket related statistics to netstat(1)?

[Gary Palmer]

On Wed, Aug 29, 2007 at 02:39:57PM +0100, Robert Watson wrote:
 
 On Wed, 29 Aug 2007, Igor Sysoev wrote:
 
 On Wed, Aug 29, 2007 at 02:48:57PM +0800, LI Xin wrote:
 
 Here is a proof-of-concept patch that adds sockets related statistics to 
 netstat(1)'s -m option, which could make SA's life easier.  Inspired by a 
 local user's suggestion.
 
 Comments?
 
 I think socket info should be groupped together:
 
 The netstat -m output is getting quite cluttered these days, isn't it.  I 
 wonder if we should be laying it out a bit more consistently, perhaps 
 something like:
 
  current   cachetotalmax
 mbufs2407  1058 3465 -
 mbuf clusters  1117  797  1914 98304
 mbufs + clusters   1117  90   --
 4k jumbo clusters  761   417  1178 0
 ...
 
 It's less compact but possibly quite a bit more readable...

We'll need to leave the old format there for a while as there are probably
quite a few programs depending on the old format out there.  Maybe add
-mh which has the user-friendly format Robert suggested? (the 'h' for
Human friendly)

Gary

 Robert N M Watson
 Computer Laboratory
 University of Cambridge
 
 
 2407/1058/3465 mbufs in use (current/cache/total)
 1117/797/1914/98304 mbuf clusters in use (current/cache/total/max)
 1117/90 mbuf+clusters out of packet secondary zone in use (current/cache)
 761/417/1178/0 4k (page size) jumbo clusters in use 
 (current/cache/total/max)
 0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
 0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
 5879K/3526K/9406K bytes allocated to network (current/cache/total)
 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
 0/0/0 requests for jumbo clusters denied (4k/9k/16k)
 15333/15537/30870/204800 socket UMA in use (current/cache/total/max)
 5929K bytes allocated to socket
 0 request for socket UMA denied
 104/264/6656 sfbufs in use (current/peak/max)
 0 requests for sfbufs denied
 0 requests for sfbufs delayed
 135834 requests for I/O initiated by sendfile
 0 calls to protocol drain routines
 
 Second, I think socket memory calculation should include
 tcpcb, udpcb, inpcb, unpcb and probably tcptw items.
 
 
 -- 
 Igor Sysoev
 http://sysoev.ru/en/
 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to [EMAIL PROTECTED]
 
 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to [EMAIL PROTECTED]
 
 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Question about bce driver

[Gary Palmer]

On Thu, Jul 12, 2007 at 10:31:41AM +0100, Tom Judge wrote:
 Julian Elischer wrote:
 Tom Judge wrote:
 Josh Paetzel wrote:
 On Wednesday 11 July 2007, Tom Judge wrote:
 Hi Paul,
 
  From the testing that I have been doing for the last few months
 the driver in 6.2 is stable if you are not using jumbo frames and
 there is a light-moderate network load.
 
 However if you want to use Jumbo frames the driver is very
 unstable.  I posted a patch against 6.2 which should fix some load
 based issues in the driver with standard frame sizes.
 
 Tom
 
 Paul, I was never able to solve the link up/link down problems with 
 the driverI was using the drivers from STABLE for a while, and 
 without jumbo frames everything worked somewhat ok most of the 
 timethe ultimate solution was to just get the intel PCI-X card 
 and stop using the broadcoms.
 
 
 
 We have basically come to the same conclusion today,  unfortunately 
 this is 35 machines, but if it makes them stable at least we can use 
 them.
 
 I'm not seeing any problems on our 2950s running 6.1 plus some backpatches.

 I am very surprised at that. The driver in 6.1 was un-usable in our 
 environment. 6.2 makes it usable with standard frames under moderate 
 load. However use jumbo frames and it all falls apart, and unfortunately
 the network these systems are plugged into is GigE only with a 8192 
 Jumbo mtu.

I wouldn't be surprised if you were running different rev motherboards.
Although the Dell chassis/model number is the same, they frequently rev
the motherboard without any externally visible changes.  I'd be more
surprised if you had the same mobo part number and PCI ID's for the
Broadcom chips.

Gary
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: A query about a missing file opt_sctp.h

[Gary Palmer]

On Mon, Jun 25, 2007 at 03:40:52PM -0400, Randall Stewart wrote:
 opt_sctp.h
 
 Is one created by the config program when you run
 config with
 
 options SCTP
 
 in your list of things you want..
 
 So for example I do
 
 cd /usr/src/sys/i386/conf
 config mymachine
 cd ../compile/mymachine
 
 and if I do
 
 ls -l opt_sctp.h
 
 I will see it there...
 
 That is of course assuming that I have
 SCTP in my config ;-D


Surely it would still be there, as an empty file, even without SCTP?  Adding

options SCTP

would add something like

#define SCTP 1

to the file AFAIK (at least on 6.x, I doubt config is that much changed
in -current)


 sazzadur rahman wrote:
 Hello, In FreeBSD CVS, 
 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/?copt=1hidecvsroot=0hidenonreadable=1sortby=hideattic=1logsort=datef=u
 
 
 under src/sys/netinet tree, the header file sctp_os_bsd.h includes
 another header file named opt_sctp.h from version 1.6.
 Unfortunately I didn't find this file anywhere in the CVS. Is it
 possible to direct me how I can get the file opt_sctp.h?
 
 Thanks in advance Sazzad 
 ___ 
 freebsd-net@freebsd.org mailing list 
 http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe,
 send any mail to [EMAIL PROTECTED]
 
 
 
 -- 
 Randall Stewart
 NSSTG - Cisco Systems Inc.
 803-345-0369 or 803-317-4952 (cell)
 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to [EMAIL PROTECTED]
 
 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Diagnose co-location networking problem

[Gary Palmer]

On Wed, Dec 27, 2006 at 10:08:25PM -0800, Stephan Wehner wrote:
 Ok, this is a little unfortunate: I can't run traceroute from the client PC 
 (the service provider doesn't seem to like it). (Nor can I use ping)

/usr/ports/net/tcptraceroute

You should normally be able to use tcptraceroute to get path information
to systems that are listening on a TCP port (e.g. a web or mail server).
You can try ports that aren't open on the other end, but that may be
less useful.
 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: trunk on re0 interface

[Gary Palmer]

On Tue, Dec 26, 2006 at 06:20:28PM +0100, Sylvie DUPUY wrote:
 Hi,
 
 I got a FreeBSD (6.1) connected to a Cisco switch 2950 (12.1).
 The speed on the re0 interface is 100 Mbps full duplex but when it get
 connected to the Cisco it turns out 10baseT half-duplex ?

If you have the re0 locked at 100 full duplex, you implicitly turn off
autonegotiation and the other end of the link doesn't know what to do.
Either use autonegotiation on both ends, or fix the speed and duplex on 
both ends.


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

Re: blocking a string in a packet using ipfw

[Gary Palmer]

On Thu, Sep 14, 2006 at 03:29:14PM +0200, Willem Jan Withagen wrote:
 I received a call from a customer this morning that all of his websites were
 no longer on line. So After some resetting and more I turnout that there 
 was a
 serious overload on his server. Over 500 clients connected. (norm is 50) and
 they were all trying to get this file 777.gif. (Which is not on any of the 
 sites).

Why not just create a 0 length file 777.gif and let people fetch it?  Its
probably a lot less work for the server.  
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: blocking a string in a packet using ipfw

[Gary Palmer]

On Thu, Sep 14, 2006 at 05:14:55PM +0200, Willem Jan Withagen wrote:
 I had several suggestions this direction. And it does help a little.
 The math is however against me.
 
 I had over 50 request/sec for this file. Now if the virus uses anything 
 which leaves the connection open for regular timeout, and the server uses 
 keepAlive. Then you are running into trouble because you soon run out of 
 server slots. And even if you were to up with the standard apache settings 
 for 15 secs, you have to set it at 750 serverslots.
 
 A serverslot takes about 13Mb virtual memory of which is about 8M resident.
 The machine has 512mb real memory, so after about 60 servers the machine 
 starts to swap. Which works until about 100-150 serverslots (empirical 
 prove).
 Now imagine what 500 would do, which is the initial setting for the number 
 of MaxServers. The machine comes to a grinding halt. Which was what we also 
 painfully found out.
 
 So solutions here are:
   either a very short keepalive timeout
   or no keepalive at all.
 
 Note that since this morning over 45.000 infected systems tried to access 
 this server.

puts on evil hat

Configure Apache to issue a HTTP 302 redirect to some big file on
microsoft.com

You might even be able to get them to download the Windows Defender
thing to clean up their systems

/puts on evil hat

You might still have to turn off keepalives :-(

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

Re: ARP behavior in FreeBSD vs Linux

[Gary Palmer]

Pieter de Boer wrote:


Is there any advantage/disadvantage in ARP implementation on FreeBSD
over that of Linux? Thanks.


I was unhappily surprised by this 'feature'. I find it pretty 
counter-intuitive. I expect two interfaces to be seperated inside a 
kernel, but Linux more or less binds them together. Incoming traffic 
on the 'wrong' interface will gladly be accepted, too. This broke 
things for me, because I didn't want to have that certain IP-address 
accessible.


That said, this happens only when you have two interfaces connected to 
the same subnet, which is a bit evil anyhow. It may be beneficial for 
Linux to do things this way, perhaps for redundancy-purposes (two 
interfaces, one IP-address, IP reachable over both interfaces, when 
one fails, the other takes over.. no idea if that works out-of-the-box).



There is another side effect, which comes into view with certain 
configurations behind load balancers.  Foundry has an option (I believe 
called DSR for Direct Server Return) which just fiddles with the MAC 
address of the destination.  Other companies load balancers will 
probably have the same option, but I've no idea what they'll call it. 
For the connection to be accepted, all servers which are expected to 
answer for a particular load balanced IP address have to have that IP 
configured on one of their interfaces, typically loopback.  The host 
sees that the connection is for one of its interfaces, accepts the 
connection and life is happy.  The return path from the host to the 
originator bypasses the load balancer, and effectively halves the 
traffic that the LB is having to process and do table lookups on, etc.  
This obviously greatly increases the available capacity of the LB.


With a Linux box answering ARP as described above, it is possible that 
the upstream router (or routers) COULD learn that the load balanced IP 
actually belongs on one of the servers rather than the load balancer.  
If that happens, your load balanced farm will quickly degrade and you'll 
be scratching your head for hours to try and figure out whats going on.  
Or the LB and the Linux box will get into an ARP war and random TCP 
connections will get RSTs from the Linux box.


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