FRR ospf6 and bridge interfaces.

[Zaphod Beeblebrox]

So... I have FRR OSPF and OSPF6 up on my lan.  As I've got a few VMs that
(say) act as a VPN sever, I want OSPF and OSPF6 to pick up from the bridge
that serves the VMs.

Both OSPF and OSPF6 work fine on the physical lan interfaces (in fact, on
vlan interfaces that attach to regular lan interfaces).  I'm also familiar
with the rules for OSPF[6] matching the configuration, network and network
length.

But having configured the VM and the host OSPF --- which works fine and
OSPF6 ... which doesn't, I think dumped traffic on the bridge.

no OSPF6 packets on the bridge.  IPV6 pings work.  Host and VM are both
13.1-RELEASE.

Re: Porting OpenBSD MPLS to FreeBSD

[Zaphod Beeblebrox]

I would also like to be on the list of possible beta testers.

On Tue, Dec 7, 2021 at 11:27 AM Santiago Martinez 
wrote:

> Hi Neel, it is exciting to see the topic coming alive again.
>
> Once you think is good/ready for testing, or when you require it,  i can
> avail hardware , routers and traffic generator to take the stack for a
> ride.
>
> Count me in for testing, reporting, etc.
>
> Best regards.
>
> Santi
>
> On 12/6/21 18:40, Rodney W. Grimes wrote:
> > [ Charset UTF-8 unsupported, converting... ]
> >> Hi Alexander,
> >>
> >> On 2021-12-04 10:42, Alexander V. Chernikov wrote:
>  * Is porting OpenBSD MPLS to FreeBSD feasible, or are we better off
>  doing a from-scratch implementation based on netgraph?
> >>> It depends. MPLS implementaiton can be splitted into multiple logical
> >>> parts - dataplane (input, control, output, forward) and control plane
> >>> (programming ip routes+mpls and mpls-only fowarding state). Some parts
> >>> of the former can indeed be imported from OpenBSD. However, most of
> >>> the control plane part have to be written from scratch. Finally, it
> >>> may be desired to maintain an programming interface close to the one
> >>> already implemented in major routing SW (frr, bird) - I guess that
> >>> would be simpler to achieve with native, non-netgraph implementation.
> >> Thanks for your description. I haven't started work yet, but I'd
> >> probably import the dataplane from OpenBSD where I can and do a new
> >> control plane, maybe that with a FRR/Bird-compatible API.
> > When you get to working with FRR let me know, I am a member of
> > the CI infustructure team there and can hook you up directly
> > with very knowledgeable FRR developers.
> >
> >> I wasn't too keen on using netgraph anyways, I felt it was unnecessary
> >> complexity.
> > True, but with that complexity comes an ulmost unlimited flexiablity.
> >
> >> If I were to work on this, would I be better off starting with the
> >> dataplane or control plane?
> > I concur with Alexander on this, dataplace first, with an eye on how
> > FRR/Bird interact with the dataplane.
> >
>  * Would some of the other committers here be willing to mentor/help me
>  if needed?
> >>> I?d love to. Most of my the routing-related stack changes (modular
> >>> lookup framework, nexthops, rtsock cleanups) were done to enable
> >>> efficient kernel-based MPLS implementation.
> >> Thanks!
> >>
> >> -Neel (nc@)
> >>
> >>
>
>

Re: LTE modem?

[Zaphod Beeblebrox]

Most of the cell modems (over the years) that I have seen show up as serial
devices and emulate a basic AT command set.  In most cases, you need to
know the dial string for your carrier --- it's often something goofball
like "ATDT pppservice.mycarrier.com" ... and then, after connecting
speaking ppp ... sometimes even without authentication.  The LTE modem I
picked up for my most recent laptop (and goes in an internal slot) fits
this bill.  IIRC, it shows up as a USB serial device.

On Mon, May 4, 2020 at 9:24 PM Michael Sierchio  wrote:

> I'm looking for solutions to support a 4G (maybe 5G?) backup internet
> connection.  The policy based routing / multiple FIB / firewall rules I
> already have in place.
>
> Any recommendations for an LTE modem?  USB or maybe Ethernet?  I do have a
> PCEngines box with an available miniPCI express slot, but I'd prefer
> something simpler.
>
> Thanks in advance.
>
> --
>
> "Well," Brahmā said, "even after ten thousand explanations, a fool is no
> wiser, but an intelligent person requires only two thousand five hundred."
>
> - The Mahābhārata
> ___
> 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: 10 Gbps NIC - advice needed

[Zaphod Beeblebrox]

I just wanted to say that I got several Intel 10 GBE cards:

vendor = 'Intel Corporation'
device = 'Ethernet Controller 10G X550T'

and while FreeBSD support seems strong, they will not hold a 10G connection
with my UniFi swtich.  The talk 1G just fine, but even with the most
expensive cat6 cables, they won't talk 10GE with the switch.

I have several Asus "AREION" cards that talk just fine to said switch.with
any of the cat 5e+ or better cables... so the switch itself is fine.

For myself, I'm considering getting some SFP for other cards I have around
and using those with fiber (or maybe trying copper).  Some of those cards
are also the IX driver.

On Tue, Sep 3, 2019 at 4:33 PM BulkMailForRudy 
wrote:

>
> I've been using Intel for years and they are great; however, I am
> building a new router and got all Chelsio cards (recommended on various
> tuning posts).
>
> If you just need 2 port copper, get a supermicro board with 10Gbps built
> into the motherboard.
>
> Search for "chelsio freebsd tuning" and just "chelsio freebsd"
>
> Rudy
>
> On 8/29/19 4:41 AM, Robert Heron wrote:
> > Hi,
> >
> > I need to use a 10 Gbps, 2 port NIC (copper RJ-45) with FreeBSD 11.3R
> amd64. Which NIC (manufacturer and model) would you recommend as the most
> trouble-free and reliable?
> > Maybe some Intel?
> >
> > Robert
> >
> >
> > ___
> > 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"
>
___
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: Working around unsupported Ethernet card with PXE or UEFI?

[Zaphod Beeblebrox]

I suppose he could be asking, in his way, about a type of universal driver
(not unlike ndis used to be).  Not knowing anything about the UEFI
environment, but recalling that PXE requires one of the more restrictive
processor modes ... would make that quite a challenge for a universal
driver.

... but yeah... USB ports are pretty ubiquitous.

On Thu, Jun 20, 2019 at 11:07 PM Ronald F. Guilmette 
wrote:

> "Thomas Mueller"  wrote:
>
> >Is it possible to build and install FreeBSD so as to be bootable and
> access
> >the internet with an Ethernet card that doesn't work in FreeBSD?
>
> You're question doesn't make a lot of sense on the face of it.
>
> Why on earth would you either WANT or NEED to install FreeBSD on a system
> with no ethernet adapter?
>
> If it's a matter of money, I have at least a half dozen old 10/100 cards
> lying around collecting dust.  If you send me your address and if it is
> in North America, I'll send you one via snail-mail.  Or you can probably
> get one faster off eBay for about a buck and a half.
>
>
> Regards,
> rfg
>
>
> P.S.  Even if you're constrained by hardware... e.g. no PCIe slots...
> you can always get yourself some supported USB ethernet adapter.  I don't
> know of anything worth owning that could run FreeBSD and that doesn't
> have at least a couple of USB ports.
> ___
> 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"

12.0 RC3 fails to use em0.

[Zaphod Beeblebrox]

So... if I choose live CD and type "ifconfig em0 up" followed by "dhclient
em0" ... everything works... but if I go through the install, select
something that isn't on the media and continue, selecting em0 as my
network, and ipv4->DHCP ... I see "sendmeg on em0: No buffer space
available" ...

If I don't choose anything off-media, but still choose ipv4->DHCP->em0
later, It fails inconsequentially, and on reboot it still says "sendmsg on
em0: No buffer space available" ... but then it succeeds later after
loading uhid.ko (just giving that for ordering... uhid.ko isn't loaded for
the livecd, I don't believe).

The machine is and HP Compaq 8100 Elite with an i5 660 and 4G RAM.
The em0 is on the motherboard and probes as:

em0:  port 0x3100-0x311f mem
0xf040-0xf041,0xf0425000-0xf0425fff irq 19 at device 25.0 on pci0
em0: attach_pre capping queues at 1
em0: using 1024 tx descriptors and 1024 rx descriptors
em0: msix_init qsets capped at 1
em0: Unable to map MSIX table
em0: Using an MSI interrupt
em0: allocated for 1 tx_queues
em0: allocated for 1 rx_queues
em0: Ethernet address: 40:61:86:xx:xx:xx
em0: netmap queues/slots: TX 1/1024, RX 1/1024
em0: link state changed to UP
___
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"

isc-dhcpd refuses access?

[Zaphod Beeblebrox]

So... my home router has a trunked relationship to the home switch.

BGE0.31 is the guest network and has 172.17.31.1/24.

BGE0.221 is the home network and has 192.168.221.1/24.

Now on the switch, the "access" (untagged) VLAN is 1.  This works: BGE0 is
192.168.110.1 and the switch's management is 192.168.110.253.

Recently, I've been playing with a new switch, and only wants to talk on
vlan1.  I can see it's DHCP requests on the untagged port, so I modified my
isc-dhcpd configuration to include a subnet and range for 192.168.110.0/24.

Oddly, however, when restarted, dhcpd says it is listening on bge0.31 and
bge0.221, but ignores bge0.  Help?
___
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: AQtion AQC107 driver status

[Zaphod Beeblebrox]

I'm interested in taking a whack at this.  Where's the Linux driver?  I
tried searching for aquantia in the linux kernel and didn't get a hit.

On Sun, Jun 24, 2018 at 12:51 PM Grzegorz Junka  wrote:

> Hello,
>
> As far as I could check FreeBSD doesn't yet support this card. It's
> supported in Linux kernel though. I heard somewhere that the Linux
> driver doesn't contain any binary blobs and could be ported to FreeBSD.
> Has anyone been looking into this? Or do you know if anyone is planning
> to work on the driver for this card?
>
> https://www.aquantia.com/products/client-connectivity/aqtion-aqc107/
>
> Thanks
> GrzegorzJ
>
> ___
> 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"

FreeBSD11 bge and bce interfaces showing packet loss with older Cisco.

[Zaphod Beeblebrox]

I've been trying to track this problem down for awhile now.  I have two
different router servers with two different chipset on board NICs.  One
server has BGE and the other server has BCE.  Both are running a full
650k-odd route BGP table with quagga and they're joined internally with
OSPF (also quagga).

Anyways, I'm seeing, under load (in the netstat -in output):

bge1   1500   00:19:b9:f9:ad:13 592048810 2127231 0
576341766 0 0

... indicating 2127231 error packets out of 592048810 packets.  Somewhere
around 0.3% in total ... but this rises to about 1% as traffic increases.

My first problem is that I don't see any number of packets in any of the
netstat -s outputs.  How do I track this down to something more specific
than the netstat -i output?

Now the other end of the dedicated, newly purchased cat6 cable is a Cisco
WS-C3550-12G  ...  a 12 port GigE switch with 10 GBICs and two copper
ports.  In my case, it's mostly full of copper GBICs and has one SMF GBIC
for the uplink.

The GBICs show up two ways on the switch: "a-full a-1000 1000BaseTX" for
the "older" ones and "a-full a-1000 10/100/1000BaseTX" for the "newer"
ones.  Since Cisco doesn't allow setting duplex or speed on any of them, I
have the problem server connected to the 1000BaseT-only GBIC and I have the
server hard set to full-duplex and 1000BaseT.  This doesn't seem to change
the nature of the problem for better or worse.  That is to say both "auto"
and hardwired settings have the same failures.

Now... I'm fully willing to swap out the switch, but I also have trouble
believing that anything has changed with GigE 1000BaseT recently... so I'm
also sensitive that it may not be the fix either.

Help?  Suggestions?
___
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: OCD window scaling behavior on local network.

[Zaphod Beeblebrox]

If you'd like a copy, I'm pretty sure I can provide one.

For context, I found this behaviour because I was tracing a BGP problem
with an exchange's Route Server (which I believe is a cisco
something-or-other).  AFAICT, a software upgrade corrected that problem,
but the strange window behavior remains.

On Mon, Nov 6, 2017 at 2:56 PM, Sean Bruno <sbr...@freebsd.org> wrote:

>
>
> On 05/29/17 00:50, Zaphod Beeblebrox wrote:
> > so... I have some really OCD window scaling behavior on a GigE local
> > network.  The protocol is BGP, this is one session recorded.  Nearly
> every
> > payload packet is answered by both an 'ACK' and a 2nd window scaling
> > packet.  I have examined the packet counters: no errors reported by the
> box
> > or the managed switch.  Also, TCP-MD5 is not in use, if that matters.
> >
> > [image: Inline image 1]
> > ___
> > 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"
> >
>
>
> It looks like the attachment was stripped by the mailing list.
>
> sean
>
>
___
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: mbuf_jumbo_9k & iSCSI failing

[Zaphod Beeblebrox]

Don't forget that, generally, as I understand it, the network stack suffers
from the same problem for 9k buffers.

On Sun, Jun 25, 2017 at 12:56 PM, Ben RUBSON  wrote:

> > On 25 Jun 2017, at 17:32, Ryan Stone  wrote:
> >
> > Having looking at the original email more closely, I see that you showed
> an mlxen interface with a 9020 MTU.  Seeing allocation failures of 9k mbuf
> clusters increase while you are far below the zone's limit means that
> you're definitely running into the bug I'm describing, and this bug could
> plausibly cause the iSCSI errors that you describe.
> >
> > The issue is that the newer version of the driver tries to allocate a
> single buffer to accommodate an MTU-sized packet.  Over time, however,
> memory will become fragmented and eventually it can become impossible to
> allocate a 9k physically contiguous buffer.  When this happens the driver
> is unable to allocate buffers to receive packets and is forced to drop
> them.  Presumably, if iSCSI suffers too many packet drops it will terminate
> the connection.  The older version of the driver limited itself to
> page-sized buffers, so it was immune to issues with memory fragmentation.
>
> Thank you for your explanation Ryan.
> You say "over time", and you're right, I have to wait several days (here
> 88) before the problem occurs.
> Strange however that in 2500MB free memory system is unable to find 9k
> physically contiguous. But we never know :)
>
> Let's then wait for your patch !
> (and reboot for now)
>
> Many thx !
>
> Ben
> ___
> 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"

OCD window scaling behavior on local network.

[Zaphod Beeblebrox]

so... I have some really OCD window scaling behavior on a GigE local
network.  The protocol is BGP, this is one session recorded.  Nearly every
payload packet is answered by both an 'ACK' and a 2nd window scaling
packet.  I have examined the packet counters: no errors reported by the box
or the managed switch.  Also, TCP-MD5 is not in use, if that matters.

[image: Inline image 1]
___
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: quagga misinterpreting route.

[Zaphod Beeblebrox]

After upgrading to 10.3p12 and messing about a bit, I found something else
strange.  On another mpd router, the ipv6 route was showing up as being on
an unused port (bce1, in this case).  I have the port connected to the
switch (so it's up) but I'm not using it.  So... I ifconfig'd down bce0.
Then, quagga claims:

my.other.router.ca# sh ipv6 route 1001:abcd:1::1
Routing entry for 1001:abcd:1::/64
  Known via "kernel", distance 0, metric 0, tag 0, vrf 0, best, fib
  >* fe80::212:3fff:fe41:72fd, via lo0

... which is somewhat ridiculous.


On Sun, Nov 13, 2016 at 12:51 AM, Zaphod Beeblebrox <zbee...@gmail.com>
wrote:

> I have an if-up mpd5 rule that says:
>
> route -n6 add $route -iface $interface
>
> where $route is something like 1001:abcd:1::/64 and $interface is
> something like ng2.
>
> When I go into quagga, I see:
>
> my.router.ca# sh ipv6 route 1001:abcd:1::1
> Routing entry for 1001:abcd:1::/64
>   Known via "kernel", distance 0, metric 0, tag 0, vrf 0, best, fib
>   >* fe80::212:3fff:fe41:72fd, via bge0
>
> ... now there's two things wrong with this.  It's not a kernel route and
> it's not via bge0.  This leads the ospf6 advertisement of this route to be:
>
> my.router.ca# sh ipv6 ospf6 route 1001:abcd:1::1
> Destination: ::/0
> Destination type: Network
> Installed Time: 00:13:29 ago
>   Changed Time: 00:13:29 ago
> Lock: 2 Flags: BA--
> Memory: prev: 0x0 this: 0x7026f0 next: 0x704dd0
> Associated Area: 0.0.0.0
> Path Type: External-1
> LS Origin: AS-External Id: 0.0.0.0 Adv: 1.2.3.4
> Options: --|-|-|--|-|--
> Router Bits: 
> Prefix Options: xxx
> Metric Type: 1
> Metric: 20 (0)
> Nexthop:
>   fe80::21a:64ff:fe79:3348 bge0.401
>
> ... which leads other ospf6 routers on the network to not see the route at
> all (invalid?)
>
>
___
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"

quagga misinterpreting route.

[Zaphod Beeblebrox]

I have an if-up mpd5 rule that says:

route -n6 add $route -iface $interface

where $route is something like 1001:abcd:1::/64 and $interface is something
like ng2.

When I go into quagga, I see:

my.router.ca# sh ipv6 route 1001:abcd:1::1
Routing entry for 1001:abcd:1::/64
  Known via "kernel", distance 0, metric 0, tag 0, vrf 0, best, fib
  >* fe80::212:3fff:fe41:72fd, via bge0

... now there's two things wrong with this.  It's not a kernel route and
it's not via bge0.  This leads the ospf6 advertisement of this route to be:

my.router.ca# sh ipv6 ospf6 route 1001:abcd:1::1
Destination: ::/0
Destination type: Network
Installed Time: 00:13:29 ago
  Changed Time: 00:13:29 ago
Lock: 2 Flags: BA--
Memory: prev: 0x0 this: 0x7026f0 next: 0x704dd0
Associated Area: 0.0.0.0
Path Type: External-1
LS Origin: AS-External Id: 0.0.0.0 Adv: 1.2.3.4
Options: --|-|-|--|-|--
Router Bits: 
Prefix Options: xxx
Metric Type: 1
Metric: 20 (0)
Nexthop:
  fe80::21a:64ff:fe79:3348 bge0.401

... which leads other ospf6 routers on the network to not see the route at
all (invalid?)
___
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: FreeBSD10.3-RELEASE. Kernel panic.

[Zaphod Beeblebrox]

While my mp5 servers are possibly less busy (I havn't had common crashes),
I have noticed a "group" of problems.

1. The carrier dropping communication (ie: fiber cut or l2 switch breakage)
of the L2TP streams can leave mpd5 in a state where it will not die and
will not destroy interfaces (requires reboot to clear).
2. There are race conditions between quagga and mpd5 for adding/dropping
routes.
3. if A is a pppoe client and B is the mpd5 server, A cannot access TCP
services on B.  It can access tcp services _beyond_ B, but not on B. (there
is a ticket open for this).

On Wed, Oct 12, 2016 at 10:51 AM, Donald Baud via freebsd-net <
freebsd-net@freebsd.org> wrote:

>
> On 10/12/16 1:13 AM, Julian Elischer wrote:
>
>> On 11/10/2016 8:56 PM, Donald Baud via freebsd-net wrote:
>>
>>> I've been plagued with these =daily= panics until I tried the following
>>> recipes and the server has been up for 30 days so far:
>>>
>>> Normally I should expermient more to see which one of the receipes is
>>> really the fix, but I'm just glad that the server is stable for now.
>>>
>>
>> this is really great information.
>> It makes debugging a lot more possible.
>> I know it is a hard question, but do you have a way to simulate this
>> workload?
>>
>> I have no real way to simulate this kind of workload
>>
>
> Sadly, I don't have a way to simulate the workload but I am very
> interested to help fix these crashes since as Cassiano said, this makes
> mpd5/freebsd useless for pppoe/l2tp termination.
>
> At this point, I would suggest that Cassiano and Андрей confirm that they
> don't get panics when they apply the recipes that I am using.
>
> I am still running many other cisco-vpdn gateways that I would convert
> into mpd5/freebsd but my plan was stalled with the daily crashes.
> I'll wait a couple of weeks to be sure that my recipes are a valid
> workaround before converting my remaining cisco gateways to mpd5.
>
> -Dbaud
>
>
>>>
>>> recipe-1: Don't let mpd5 start automatically when server boots:
>>> i.e. in: /etc/rc.conf
>>> mpd5_enable="NO"
>>> and wait about 5 minutes after server boots then issue:
>>> /usr/local/etc/rc.d/mpd5 onestart
>>>
>>>
>>> recipe-2: recompile the kernel with the NETGRAPH_DEBUG option:
>>> options NETGRAPH
>>> options NETGRAPH_DEBUG
>>> options NETGRAPH_KSOCKET
>>> options NETGRAPH_L2TP
>>> options NETGRAPH_SOCKET
>>> options NETGRAPH_TEE
>>> options NETGRAPH_VJC
>>> options NETGRAPH_PPP
>>> options NETGRAPH_IFACE
>>> options NETGRAPH_MPPC_COMPRESSION
>>> options NETGRAPH_MPPC_ENCRYPTION
>>> options NETGRAPH_TCPMSS
>>> options IPFIREWALL
>>>
>>> recipe-3: recompile the kernel and disable the IPv6 and SCTP options:
>>> nooptions   INET6
>>> nooptions   SCTP
>>>
>>> recipe-4: Don't use any of the sysctl optimizations
>>> in other words I commented out all values in sysctl.conf:
>>> # net.graph.maxdgram=20480  (this is the default)
>>> # net.graph.recvspace=20480  (this is the default)
>>>
>>> recipe-5: Don't use any of the loader.conf optimizations
>>> in other words I commented out all values in loader.conf
>>> # net.graph.maxdata=4096  (this is the default)
>>> # net.graph.maxalloc=4096 (this is the default)
>>>
>>> 
>>> In my case, I had the panics with 10.3 and 11-PRERELEASE
>>> 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #2 r305587
>>>
>>> With those recipes, I have been running without any crash for a month
>>> and counting.  Thats' 300 l2tp tunnels and 1400 l2tp sessions generating
>>> 700Mbit/s.
>>>
>>>
>>> -DBaud
>>>
>>>
>>> On Tuesday, October 11, 2016 7:30 AM, Cassiano Peixoto <
>>> peixotocassi...@gmail.com> wrote:
>>> Hi,
>>>
>>> There are many users complaining about this:
>>>
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114
>>>
>>> I've been dealing with this issue for one year with no solution. mpd5 as
>>> pppoe server on FreeBSD is useless with this bug.
>>>
>>> I really would like to see it working again, i think it's quite important
>>> to both project and many users.
>>>
>>> Thanks.
>>>
>>> On Tue, Oct 11, 2016 at 3:24 AM, Eugene Grosbein 
>>> wrote:
>>>
>>> 11.10.2016 11:02, Андрей Леушкин пишет:

 Hello. I have problem with "FreeBSD nas 10.3-RELEASE FreeBSD
> 10.3-RELEASE
> #0: Fri Oct  7 21:12:56 YEKT 2016 nas@nas:/usr/obj/usr/src/sys/nasv3
>amd64"
>
> Kernel panic is repeated at intervals of 2-3 days. At first I thought
> that
> the problem is in the hardware, but the problem did not go away after
> replacing the server platform.
>
> Coredumps and more info on link
> https://drive.google.com/open?id=0BxciMy2q7ZjTTkIxem9wTE1tM2M
>
> Sorry for my english.
> I'll wait for an answer.
>
> This is known and long-stanging problem in the FreeBSD network stack.
 It shows up when you have lots of network interfaced created/removed
 

Re: IPv6 stacks responds to all node link local multicast NS

[Zaphod Beeblebrox]

Urm ... question: is NS how, then, a client should be getting an IP over
PPP?  I have an l2tp server configured with mpd ... and I've noticed that
mpd will allow me to turn on ipv6, but it won't assign addresses like ipv4.

On Fri, Oct 17, 2014 at 2:28 PM, prabhakar lakhera 
prabhakar.lakh...@gmail.com wrote:

 This probably is more of a compliance issue (or may be not as the NS
 receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62
 does
 not talk about it).

 The neighbor solicitation message format says this:

 http://tools.ietf.org/html/rfc4861#page-22


   Destination Address
  Either the solicited-node multicast address
  corresponding to the target address, or the target
  address.


 Is it safe to assume that this is a MUST?
 If yes, nd6_ns_input right now only checks if the destination is a
 multicast or not (the check is more strict for DAD NS packets) and
 therefore allows all node link local multicast address resolution NS
 packets and process them completely (creates neighbor cache, responds
 with NA etc).

 The fix is simple, however I wanted to know if there was some reason
 to have it like this in the first place?:

 */**
  ** Attaching target link-layer address to the NA?*
  ** (RFC 2461 7.2.4)*
   * NS IP dst is unicast/anycast MUST NOT add*
  ** NS IP dst is solicited-node multicastMUST add** **
  ** In implementation, we add target link-layer address by default.*
  ** We do not add one in MUST NOT cases.** */*
 if (!IN6_IS_ADDR_MULTICAST
 
 http://fxr.watson.org/fxr/source/netinet6/ident?v=FREEBSD10;im=bigexcerpts;i=IN6_IS_ADDR_MULTICAST
 (daddr6))
 tlladdr = 0;
 else
 tlladdr = 1;
 ___
 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

___
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

bug 191975

[Zaphod Beeblebrox]

It seems I'm being outclassed by bug 191975.  Simply put:

1. packet arrives on ngX interface (ng_iface)
2. packet destination is local
3. AFAICT packet disappears.

This is not true of packet destination is non-local.  Routed packets work
as advertised.  Local services (say, ssh) are also working fine from hosts
that connect other than via ngX.  This seems also to be true whether the
packets are directly from the ngX connected hosts, or from routed hosts
beyond the ngX connected host.

Can I draw anyone's attention to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191975 ?
___
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

ng_iface regression from 9.2 to 10.0

[Zaphod Beeblebrox]

I'm going to post again with some new information.  I have a 10.0p6 machine
running mpd5 terminating a bunch of l2tp tunnels from subscribers (not
encrypted).

The specific regression between 9.2 and 10.0 is that hosts on the tunnels
cannot communicate with local services.  They can ping local IPs, and the
server can ping them, but no userland connections can be had.

IE:

[2:15:315]root@owl:~ ifconfig ng29
ng29: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST metric 0
mtu 1436
inet xx.yy.31.6 -- xx.yy.16.50 netmask 0x
inet6 fe80::219:b9ff:fef9:b9e7%ng29 prefixlen 64 scopeid 0x23
nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
[2:16:316]root@owl:~ ping xx.yy.16.50
PING xx.yy.16.50 (xx.yy.16.50): 56 data bytes
64 bytes from xx.yy.16.50: icmp_seq=0 ttl=64 time=11.580 ms
64 bytes from xx.yy.16.50: icmp_seq=1 ttl=64 time=16.515 ms
64 bytes from xx.yy.16.50: icmp_seq=2 ttl=64 time=6.253 ms
^C
--- xx.yy.16.50 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 6.253/11.449/16.515/4.190 ms
[2:17:317]root@owl:~ ssh xx.yy.16.50
ssh: connect to host xx.yy.16.50 port 22: Operation timed out

It's worth noting, too, that all tunnel-connected hosts have full internet
connectivity as does the tunnel server.  Connections from one hop away (ie:
not involving the tunnel server to run the process) work as usual.

It's also worth noting that localhost and local-ip communication on the
server are fine (ie: mpd5 communicates with radiusd running on the same
machine).

For interest's sake, xx.yy.16.50 is running mpd5 on 9.2.
___
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

ngX connected hosts not receiving replies from non-kernel IP services.

[Zaphod Beeblebrox]

I have a network of computers at home.  The gateway/firewall is FreeBSD 9.2
running mpd5.  The host requesting the service is FreeBSD 9.2.  The
misbehaving host is FreeBSD 10.0p6 running mpd5.  So the details:

ssh is listening (output of netstat -an)

tcp4   0  0 *.22   *.*LISTEN
tcp6   0  0 *.22   *.*LISTEN

named is listening (installed from bind99 port)

tcp4   0  0 xx.yy.30.99.53 *.*LISTEN
udp4   0  0 xx.yy.30.99.53 *.*

mpd 5 on the server is up:

[2:35:335]root@owl:~ ifconfig ng29
ng29: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST metric 0
mtu 1436
inet xx.yy.31.6 -- xx.yy.16.50 netmask 0x
inet6 fe80::219:b9ff:fef9:b9e7%ng29 prefixlen 64 scopeid 0x23
nd6 options=21PERFORMNUD,AUTO_LINKLOCAL

ping works:

[1:71:137]root@virtual:/vr2/backup/nozfs/ox/local-etc ping xx.yy.16.3
PING xx.yy.16.3 (xx.yy.16.3): 56 data bytes
64 bytes from xx.yy.16.3: icmp_seq=0 ttl=63 time=7.439 ms
64 bytes from xx.yy.16.3: icmp_seq=1 ttl=63 time=6.756 ms

now tcpdumping from the FreeBSD 10.0p6 server host while I ssh:

[2:29:329]root@owl:~ tcpdump -nvi ng29 host xx.yy.16.3
tcpdump: listening on ng29, link-type NULL (BSD loopback), capture size
65535 bytes
capability mode sandbox enabled
18:14:36.276578 IP (tos 0x0, ttl 63, id 3249, offset 0, flags [none], proto
TCP (6), length 60)
xx.yy.20.52.39218  xx.yy.16.3.22: Flags [S], cksum 0x4aa1 (correct),
seq 3433340283, win 65535, options [mss 1396,nop,wscale 6,sackOK,TS val
435369805 ecr 0], length 0
18:14:39.290104 IP (tos 0x0, ttl 63, id 4999, offset 0, flags [none], proto
TCP (6), length 60)
xx.yy.20.52.39218  xx.yy.16.3.22: Flags [S], cksum 0x3ee9 (correct),
seq 3433340283, win 65535, options [mss 1396,nop,wscale 6,sackOK,TS val
435372805 ecr 0], length 0
18:14:42.502893 IP (tos 0x0, ttl 63, id 6832, offset 0, flags [none], proto
TCP (6), length 60)
xx.yy.20.52.39218  xx.yy.16.3.22: Flags [S], cksum 0x3269 (correct),
seq 3433340283, win 65535, options [mss 1396,nop,wscale 6,sackOK,TS val
435376005 ecr 0], length 0

Similarly tcpdumping from the server while running dig google.ca
@xx.yy.30.99

[2:37:337]root@owl:~ tcpdump -nvi ng29 host xx.yy.30.99
tcpdump: listening on ng29, link-type NULL (BSD loopback), capture size
65535 bytes
capability mode sandbox enabled
18:36:02.841942 IP (tos 0x0, ttl 63, id 30407, offset 0, flags [none],
proto UDP (17), length 66)
xx.yy.20.52.27400  xx.yy.30.99.53: 40608+ [1au] A? google.ca. (38)
18:36:07.838721 IP (tos 0x0, ttl 63, id 33612, offset 0, flags [none],
proto UDP (17), length 66)
xx.yy.20.52.27400  xx.yy.30.99.53: 40608+ [1au] A? google.ca. (38)

Frustratingly, ssh and bind work just fine from hosts that are on the lan
with the server.  It's like some portion of the packet routing machinery is
broken with ngX.

Before y'all ask, too, ip.forwarding is 1.  The ng-connected hosts can use
the rest of the internet ... just not non-kernel services on the host that
breaks up their l2tp.
___
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: No UDP/TCP IPv6 connectivity (only) to router using gif interface - maybe ARM related

[Zaphod Beeblebrox]

Whether you feel it right, or not, net.inet.ip.forwarding must be 1 for gif
to work (even for IPv6).


On Mon, Sep 2, 2013 at 2:42 AM, Martin Laabs mailingli...@martinlaabs.dewrote:

 Hi,

 I tried to set up my raspberry PI as an ipv6 router. As a tunnel broker I
 use sixxs. Now I observed an interesting behavior:

 Every host from my network can reach the ipv6 world. The ipv6 world can
 also reach every host in my network. However - the router itself is unable
 to make udp or tcp connection to the world and is also unable to accept
 connections form the world
 ICMP however works properly.
 I had a look to the tcpdump and when trying to connect i.e. to
 www.kame.net
 the rasperry router sends a syn packet and get a syn/ack packet back. The
 rest of the handshake is missing.
 I tried also some udp with netcat (nc -6 -u -l  on the server and nc -6
 -u server  on the client)
 This works great for internal (ethernet) traffic but when the data should
 go through the tunnel if fails.

 The last test is maybe the most significant to describe the bug:

 Start netcat to listen for UDP packages on an external host:

 external host nc -6 -u -l 

 Connect from the RPI-Router to that host

 RPI nc -6 -u 2001:4dd0::::2 

 Now it is possible to send data from the RPI router to the external host
 but the opposite direction does not work. Tcpdump however shows that the
 udp package arrives but it is not forwarded to the application.
 So for me it seems to be a problem with the handling of the receiving data
 in the gif interface.

 This behavior is independent from net.inet6.ip6.forwarding or
 net.inet6.ip6.redirect status.

 The router system: FreeBSD raspberry-pi.xxx 10.0-CURRENT FreeBSD
 10.0-CURRENT #2 r254984

 Best regards,
  Martin Laabs

 ___
 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

___
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: Intel 4-port ethernet adaptor link aggregation issue

[Zaphod Beeblebrox]

On several machines with large numbers of IGBx interfaces, I've found that
hw.igb.enable_msix=0 is necessary to ensure proper operation.


On Fri, Aug 2, 2013 at 11:49 AM, Freddie Cash fjwc...@gmail.com wrote:

 On Fri, Aug 2, 2013 at 12:36 AM, Steve Read steve.r...@netasq.com wrote:

  On 01.08.2013 20:07, Joe Moog wrote:
 
  We have an iXsystems 1U server (E5) with an Intel 4-port ethernet NIC
  installed, model I350-T4 (manufactured May of 2013). We're trying to
 bind
  the 4 ports on this NIC together into a single lagg port, connected
 LACP to
  a distribution switch (Cisco 4900-series). We are able to successfully
 bind
  the 2 on-board ethernet ports to a single lagg, however the NIC is not
 so
  cooperative. At first we thought we had a bad NIC, but a replacement has
  not fixed the issue. We are thinking there may be a driver limitation
 with
  these Intel ethernet NICs when attempting to bind more than 2 ports to a
  lagg.
 
  FreeBSD version:
  FreeBSD 9.1-PRERELEASE #0 r244125: Wed Dec 12 11:47:47 CST 2012
 
  rc.conf:
  # LINK AGGREGATION
  ifconfig_igb2=UP
  ifconfig_igb3=UP
  ifconfig_igb4=UP
  ifconfig_igb5=UP
  cloned_interfaces=lagg0
  ifconfig_lagg0=laggproto lacp laggport igb2 laggport igb3 laggport igb4
  laggport igb5
  ifconfig_lagg0=inet 192.168.1.14  netmask 255.255.255.0
 
 

  Am I the only one who noticed that you replaced the value of
  $ifconfig_lagg0 that specifies the proto and the ports with one that
  specifies just the address?
 

 Good catch!


  Merge the two ifconfig_lagg0 lines into one, and it will work infinitely
  better, or at least no worse.
 
  ifconfig_lagg0=laggproto lacp laggport igb2 laggport igb3 laggport igb4
  laggport igb5 inet 192.168.1.14  netmask 255.255.255.0
 
  Or, if you want to keep them split into two parts (initialise lagg0, then
 add IP):

 create_args_lagg0=laggproto lacp laggport igb2 laggport igb3 laggport igb4
 laggport igb5

 ifconfig_lagg0=inet 192.168.1.14  netmask 255.255.255.0

 create_args_* are run first, then ifconfig_* are run.  I like this setup,
 as it separates create and initialise from configure for cloned/virtual
 interfaces like vlans, laggs, etc.


 --
 Freddie Cash
 fjwc...@gmail.com
 ___
 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

___
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: Please implement patch in PR180893

[Zaphod Beeblebrox]

On Sat, Jul 27, 2013 at 6:46 PM, Mike Karels m...@karels.net wrote:

  Sure, but it would be nice to file bugs with VMware and such to ensure
  they fix their bugs.


There's quite a bit of chatter about this problem on the VMWare lists.
Linux complains when these packets show up, so it isn't going unnoticed.


 fwiw, I use IPv6 with recent versions of ESXi and VMware Workstation,
 and have not seen this problem.  I'm curious if the problem is in old
 versions or with particular configurations.


I think you're only going to find this on the 'bridged' network type.  When
I tested this problem with other types of VMWare lans, the problem does not
occur.


  Anyone have any issue with this? The issue I have is the if_printf(),
  it should be rate limited at the very least. It would also be nice to
  have a different counter to reflect that kind of dropped packet..

 Agreed to both; I'd rather reserve if_ierrors for NIC-reported errors.
 I also think the message should say from my MAC address (vs IP).


Obviously, it's really easy to modify the if_printf(), but what type of
rate limiting is appropriate here?  For instance, if you send a packet from
an IP on the lan with changing MAC addresses, FreeBSD will printf() a note
about each MAC address change.  AFAICT, the if_printf() here can only be
triggered by something right on the local lan (not by the internet at large
--- even without filters).
___
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

Please implement patch in PR180893

[Zaphod Beeblebrox]

I'd like to advocate implementing
http://www.freebsd.org/cgi/query-pr.cgi?pr=180893

Quoting the PR:

Some errant network equipment (including the simulation of a network
by VMware, as an example) will reflect back multicast packets to the sender.
This breaks protocols such as DAD and makes IPv6 nearly impossible to use
on these networks.

Now, the argument could be made to fix these network elements, but
there is an elegant solution that improves the quality of FreeBSD: To refuse
packets that have a source ethernet address of the receiving interface. If
you consider this notion, you can quickly and easily accept that an
interface
should never receive a packet from it's own MAC address.

This behaviour mirrors Linux behavior and I assume Windows behavior.

I won't claim to be experienced in kernel matters, but I chose the
location for this modification to allow BPF to see the packets (for
network diagnosis). This test, however, could be moved within this function
or even given a sysctl knob.
___
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: Duplicate Address Detection misfire?

[Zaphod Beeblebrox]

Does that mean, then, that the only fix open to some people is to turn off
DAD?  I have another idea:

Require DAD to inspect the sending MAC address.  If the sending MAC address
is _our_ MAC address, then the packet is not an indication of a duplicate
address?


On Tue, Jul 23, 2013 at 2:15 AM, Kimmo Paasiala kpaas...@gmail.com wrote:

 On Tue, Jul 23, 2013 at 8:44 AM, Zaphod Beeblebrox zbee...@gmail.com
 wrote:
  What to do when you don't trust the interface?  VMWare is obviously
  emulating the hardware and their interpretation of what the hardware is
  is possibly different from ours.
 
  If I boot single-user and tcpdump the interface, I see two transmitted
  solicitations.  The kernel claims to have sent one.
 
  My concern: is the vmware interface reflecting the solicitation packet
  because it is a broadcast packet?
 
  To determine this, I've gone over the tcpdump and pcap-filter man pages
 to
  look for a way to only dump packets leaving from or arriving at an
  interface.  Can this be done?
 
  If VMWare is reflecting the packet back, I'm curious as to how we can fix
  this.
 
 

 That sounds exactly like my experience with DAD misbehaving on my
 Zyxel WAP3205 access point. It is reflecting  the multicasts (I hope
 that's the right term) so that any IPv6 equipment on the wireless
 network will think that its address is already in use. For the record,
 the client machines in my case are all OS X. Nice to know I'm not the
 only one with such problems.

 -Kimmo

___
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: Duplicate Address Detection misfire?

[Zaphod Beeblebrox]

Ironically, the win 7 host is using an em series card.  Specifically, an
Intel Gigabit CT.  It is configured in vlan mode and the VMWare bridged
connection is connected to a VLAN.

Regardless, tho, Intel's own drivers are usually not this bad --- and the
driver is up-to-date.


On Tue, Jul 23, 2013 at 10:22 AM, Kevin Day ke...@your.org wrote:

 Sorry for the slow reply.

 We run mainly ESXi (the bare metal version of VMware, not the desktop
 versions) but I do remember seeing something sort of similar on a desktop
 version ages ago. Basically we narrowed it down to a Windows driver bug on
 the host system's ethernet card. It was basically reflecting back
 everything it transmitted into the receive queue. This was before IPv6 was
 in use here, but I remember it breaking a file sharing protocol (SMB? AFP?)
 that also didn't like seeing its own multicasts/broadcasts echoed back to
 itself.

 By any chance is this on a system using WiFi rather than wired ethernet?
 Many routers/access points/wifi adapters have problems with the idea of
 VMware's bridged mode networking - they expect only one MAC per station
 and do not do the right thing in some places.

 I don't have an answer for you, but I'd look at the physical networking
 card/adapter on the host OS first if I were troubleshooting this. Updated
 driver/replace with something else/etc.

 -- Kevin

 On Jul 23, 2013, at 12:44 AM, Zaphod Beeblebrox zbee...@gmail.com wrote:

  What to do when you don't trust the interface?  VMWare is obviously
 emulating the hardware and their interpretation of what the hardware is
 is possibly different from ours.
 
  If I boot single-user and tcpdump the interface, I see two transmitted
 solicitations.  The kernel claims to have sent one.
 
  My concern: is the vmware interface reflecting the solicitation packet
 because it is a broadcast packet?
 
  To determine this, I've gone over the tcpdump and pcap-filter man pages
 to look for a way to only dump packets leaving from or arriving at an
 interface.  Can this be done?
 
  If VMWare is reflecting the packet back, I'm curious as to how we can
 fix this.
 


___
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: Duplicate Address Detection misfire?

[Zaphod Beeblebrox]

Doesn't my original suggestion still stand... regardless of how this
particular problem is fixed?


That is: if the sending MAC address is _our_ MAC address, then the address
is not duplicate.  It seems a simple change (unless the function that
processes the packet would have difficulty determining the MAC address) and
it seems to be infallible logic.  In fact, if we receive a packet from our
own MAC address, shouldn't we drop and log it?
___
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: Duplicate Address Detection misfire?

[Zaphod Beeblebrox]

What to do when you don't trust the interface?  VMWare is obviously
emulating the hardware and their interpretation of what the hardware is
is possibly different from ours.

If I boot single-user and tcpdump the interface, I see two transmitted
solicitations.  The kernel claims to have sent one.

My concern: is the vmware interface reflecting the solicitation packet
because it is a broadcast packet?

To determine this, I've gone over the tcpdump and pcap-filter man pages to
look for a way to only dump packets leaving from or arriving at an
interface.  Can this be done?

If VMWare is reflecting the packet back, I'm curious as to how we can fix
this.



On Mon, Jul 22, 2013 at 1:22 AM, Zaphod Beeblebrox zbee...@gmail.comwrote:

 I've further narrowed this down.  According to the output:

 em0 DAD detected duplicate IPv6 address fe80:2::250:56ff:fe2e:45fd: NS
 in/out=2/1, NA in=0

 ... FreeBSD *thinks* it has transmitted one and received 2 solicitations.
 The packet dump shows two solicitations (which would, if it were not bogus,
 indicate that another machine was booting at the exact same time trying to
 use the same link-local address).

 The question becomes: is vmware duplicating the packet, or is FreeBSD?
 IE: driver problem with em0 and vmware?

 I'm not completely sure how to debug this.



 On Thu, Jul 18, 2013 at 9:21 PM, Zaphod Beeblebrox zbee...@gmail.comwrote:




 On Sun, Jun 30, 2013 at 10:39 PM, Kevin Day ke...@your.org wrote:


 On Jun 30, 2013, at 6:48 PM, Zaphod Beeblebrox zbee...@gmail.com
 wrote:

  I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
  bridged type of networking with VMWare.  It gets it's IPv4 address
 from
  DHCP (successfully) and then fails to initialize IPv6.  The relevant
  rc.conf is:
 
  ipv6_activate_all_interfaces=YES
  ifconfig_em0_ipv6=inet6 accept_rtadv
  ip6addrctl_verbose=YES
 
  The console output says:
 
  em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS
  in/out=2/1, NA in=0
  em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found
  em0: manual intervention required
  em0: possible hardware address duplication deteted, disable IPv6
 
  And subsequently, em0's nd6 has IFDISABLED in it.
 
  With wireshark, I see two ICMPv6 neighbor solicitations that are
 identical
  --- is this the problem?
 
  How do I fix this?

 Did you copy this VM and have both copies running at once? If so, it
 assigned the same MAC address to each VM.

 VMware is suppose to detect this and ask if you copied or moved the
 VM, and if you say copied it will randomly assign a new MAC to the VM. If
 this didn't happen or if you said moved when you actually copied it, just
 go in and delete/re-create the network interface in the VM's settings to
 create a new MAC for it.

 If that's not the issue, we'd probably need more details about your
 configuration.


 To further diagnose, there is only one VM running.  To ensure that there
 were no duplicates, I reassigned the MAC address in the VMWare
 configuration dialogue.  Additionally, I tried stopping rtadvd on my router
 (no effect) and I tried putting the guest on a host-only network
 (basically isolated it) --- this clears the problem --- both the link-local
 and the static address are assigned.

 Frustrated, I dumped the windows interface that is bridged to the VMWare
 guest.  When it boots, I see the following:

 246119:24:16.376027000Vmware_2e:46:fdBroadcastARP
 42Gratuitous ARP for 66.96.20.42 (Request)
 246219:24:16.388241000::ff02::1:ff00:42ICMPv678
 Neighbor Solicitation for 2001:1928:1::42
 246319:24:16.389065000::ff02::1:ff00:42ICMPv678
 Neighbor Solicitation for 2001:1928:1::42
 246419:24:16.44413::ff02::16ICMPv6130
 Multicast Listener Report Message v2
 246519:24:16.444605000::ff02::16ICMPv6130
 Multicast Listener Report Message v2
 246619:24:16.594663000::ff02::1:ff2e:46fdICMPv678
 Neighbor Solicitation for fe80::250:56ff:fe2e:46fd
 246719:24:16.595179000::ff02::1:ff2e:46fdICMPv678
 Neighbor Solicitation for fe80::250:56ff:fe2e:46fd
 275319:24:22.274728000Vmware_2e:46:fdBroadcastARP
 42Who has 66.96.20.33?  Tell 66.96.20.42
 275419:24:22.274902000Intel_bc:6f:87Vmware_2e:46:fdARP60
 66.96.20.33 is at 00:0e:0c:bc:6f:87

 ... and then it goes on to chatter ipv4-wise as expected.  Note that
 there are two of each packet.  Is that normal?  The ethernet source of all
 these packets is my vmware guest (save the who-has reply that I copied in).



___
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: Duplicate Address Detection misfire?

[Zaphod Beeblebrox]

I've further narrowed this down.  According to the output:

em0 DAD detected duplicate IPv6 address fe80:2::250:56ff:fe2e:45fd: NS
in/out=2/1, NA in=0

... FreeBSD *thinks* it has transmitted one and received 2 solicitations.
The packet dump shows two solicitations (which would, if it were not bogus,
indicate that another machine was booting at the exact same time trying to
use the same link-local address).

The question becomes: is vmware duplicating the packet, or is FreeBSD?  IE:
driver problem with em0 and vmware?

I'm not completely sure how to debug this.



On Thu, Jul 18, 2013 at 9:21 PM, Zaphod Beeblebrox zbee...@gmail.comwrote:




 On Sun, Jun 30, 2013 at 10:39 PM, Kevin Day ke...@your.org wrote:


 On Jun 30, 2013, at 6:48 PM, Zaphod Beeblebrox zbee...@gmail.com wrote:

  I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
  bridged type of networking with VMWare.  It gets it's IPv4 address
 from
  DHCP (successfully) and then fails to initialize IPv6.  The relevant
  rc.conf is:
 
  ipv6_activate_all_interfaces=YES
  ifconfig_em0_ipv6=inet6 accept_rtadv
  ip6addrctl_verbose=YES
 
  The console output says:
 
  em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS
  in/out=2/1, NA in=0
  em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found
  em0: manual intervention required
  em0: possible hardware address duplication deteted, disable IPv6
 
  And subsequently, em0's nd6 has IFDISABLED in it.
 
  With wireshark, I see two ICMPv6 neighbor solicitations that are
 identical
  --- is this the problem?
 
  How do I fix this?

 Did you copy this VM and have both copies running at once? If so, it
 assigned the same MAC address to each VM.

 VMware is suppose to detect this and ask if you copied or moved the
 VM, and if you say copied it will randomly assign a new MAC to the VM. If
 this didn't happen or if you said moved when you actually copied it, just
 go in and delete/re-create the network interface in the VM's settings to
 create a new MAC for it.

 If that's not the issue, we'd probably need more details about your
 configuration.


 To further diagnose, there is only one VM running.  To ensure that there
 were no duplicates, I reassigned the MAC address in the VMWare
 configuration dialogue.  Additionally, I tried stopping rtadvd on my router
 (no effect) and I tried putting the guest on a host-only network
 (basically isolated it) --- this clears the problem --- both the link-local
 and the static address are assigned.

 Frustrated, I dumped the windows interface that is bridged to the VMWare
 guest.  When it boots, I see the following:

 246119:24:16.376027000Vmware_2e:46:fdBroadcastARP42
 Gratuitous ARP for 66.96.20.42 (Request)
 246219:24:16.388241000::ff02::1:ff00:42ICMPv678
 Neighbor Solicitation for 2001:1928:1::42
 246319:24:16.389065000::ff02::1:ff00:42ICMPv678
 Neighbor Solicitation for 2001:1928:1::42
 246419:24:16.44413::ff02::16ICMPv6130Multicast
 Listener Report Message v2
 246519:24:16.444605000::ff02::16ICMPv6130Multicast
 Listener Report Message v2
 246619:24:16.594663000::ff02::1:ff2e:46fdICMPv678
 Neighbor Solicitation for fe80::250:56ff:fe2e:46fd
 246719:24:16.595179000::ff02::1:ff2e:46fdICMPv678
 Neighbor Solicitation for fe80::250:56ff:fe2e:46fd
 275319:24:22.274728000Vmware_2e:46:fdBroadcastARP42
 Who has 66.96.20.33?  Tell 66.96.20.42
 275419:24:22.274902000Intel_bc:6f:87Vmware_2e:46:fdARP60
 66.96.20.33 is at 00:0e:0c:bc:6f:87

 ... and then it goes on to chatter ipv4-wise as expected.  Note that there
 are two of each packet.  Is that normal?  The ethernet source of all these
 packets is my vmware guest (save the who-has reply that I copied in).


___
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: Duplicate Address Detection misfire?

[Zaphod Beeblebrox]

On Sun, Jun 30, 2013 at 10:39 PM, Kevin Day ke...@your.org wrote:


 On Jun 30, 2013, at 6:48 PM, Zaphod Beeblebrox zbee...@gmail.com wrote:

  I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
  bridged type of networking with VMWare.  It gets it's IPv4 address from
  DHCP (successfully) and then fails to initialize IPv6.  The relevant
  rc.conf is:
 
  ipv6_activate_all_interfaces=YES
  ifconfig_em0_ipv6=inet6 accept_rtadv
  ip6addrctl_verbose=YES
 
  The console output says:
 
  em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS
  in/out=2/1, NA in=0
  em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found
  em0: manual intervention required
  em0: possible hardware address duplication deteted, disable IPv6
 
  And subsequently, em0's nd6 has IFDISABLED in it.
 
  With wireshark, I see two ICMPv6 neighbor solicitations that are
 identical
  --- is this the problem?
 
  How do I fix this?

 Did you copy this VM and have both copies running at once? If so, it
 assigned the same MAC address to each VM.

 VMware is suppose to detect this and ask if you copied or moved the
 VM, and if you say copied it will randomly assign a new MAC to the VM. If
 this didn't happen or if you said moved when you actually copied it, just
 go in and delete/re-create the network interface in the VM's settings to
 create a new MAC for it.

 If that's not the issue, we'd probably need more details about your
 configuration.


To further diagnose, there is only one VM running.  To ensure that there
were no duplicates, I reassigned the MAC address in the VMWare
configuration dialogue.  Additionally, I tried stopping rtadvd on my router
(no effect) and I tried putting the guest on a host-only network
(basically isolated it) --- this clears the problem --- both the link-local
and the static address are assigned.

Frustrated, I dumped the windows interface that is bridged to the VMWare
guest.  When it boots, I see the following:

246119:24:16.376027000Vmware_2e:46:fdBroadcastARP42
Gratuitous ARP for 66.96.20.42 (Request)
246219:24:16.388241000::ff02::1:ff00:42ICMPv678
Neighbor Solicitation for 2001:1928:1::42
246319:24:16.389065000::ff02::1:ff00:42ICMPv678
Neighbor Solicitation for 2001:1928:1::42
246419:24:16.44413::ff02::16ICMPv6130Multicast
Listener Report Message v2
246519:24:16.444605000::ff02::16ICMPv6130Multicast
Listener Report Message v2
246619:24:16.594663000::ff02::1:ff2e:46fdICMPv678
Neighbor Solicitation for fe80::250:56ff:fe2e:46fd
246719:24:16.595179000::ff02::1:ff2e:46fdICMPv678
Neighbor Solicitation for fe80::250:56ff:fe2e:46fd
275319:24:22.274728000Vmware_2e:46:fdBroadcastARP42
Who has 66.96.20.33?  Tell 66.96.20.42
275419:24:22.274902000Intel_bc:6f:87Vmware_2e:46:fdARP
6066.96.20.33 is at 00:0e:0c:bc:6f:87

... and then it goes on to chatter ipv4-wise as expected.  Note that there
are two of each packet.  Is that normal?  The ethernet source of all these
packets is my vmware guest (save the who-has reply that I copied in).
___
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

Duplicate Address Detection misfire?

[Zaphod Beeblebrox]

I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
bridged type of networking with VMWare.  It gets it's IPv4 address from
DHCP (successfully) and then fails to initialize IPv6.  The relevant
rc.conf is:

ipv6_activate_all_interfaces=YES
ifconfig_em0_ipv6=inet6 accept_rtadv
ip6addrctl_verbose=YES

The console output says:

em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS
in/out=2/1, NA in=0
em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found
em0: manual intervention required
em0: possible hardware address duplication deteted, disable IPv6

And subsequently, em0's nd6 has IFDISABLED in it.

With wireshark, I see two ICMPv6 neighbor solicitations that are identical
--- is this the problem?

How do I fix this?
___
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: VirtualBox + FreeBSD 9-STABLE == Frozen Ethernet

[Zaphod Beeblebrox]

Heh.  VirtualBox has (in my experience) been buggy as heck.  Beyond buggy
as heck.

I have 3 virtualization platforms at my disposal (and the host here is win
7).  VirtualBox, VMWare and Windows Virtual PC.  I can report that under
VirtualBox, every major type of guest caused stability problems with the
host (Windows 7, Windows XP, FreeBSD, Linux).  Stability problems would
include crashing of the guest, crashing of the host, network bogons (from
interfaces resetting to interfaces hanging --- like yours).  I switched
various guests to VMWare (the free player version) and everything was
smooth.  Really smooth.  No problems running guests for _days_.  No
problems running multiple guests.

I don't use virtual PC much --- it runs XP mode ... just because that's
included with Windows 7... but it never causes problems either FWIW.

It seemed to me that every update after Sun passed to Oracle brought more
bugs.  My advice: run away from VirtualBox.



On Mon, May 6, 2013 at 3:12 PM, Marc G. Fournier scra...@hub.org wrote:


 I'm having an odd issue with FreeBSD that I'm not sure how to trace /
 where to look …

 I have 6 servers, all identical RAM / CPU / Ethernet / etc … 4 of them are
 running VirtualBox, 2 are running Jails … one of the 4 I just switched from
 Jail - Virtualbox …

 When running jail(s), the servers are rock solid … as soon as I switch to
 VirtualBox (the one I just switched is running one Vbox with a FreeBSD
 Guest) … nothing else is running on the server … but I will get sporadic
 freezes of the Ethernet.  One ran 46 days before it froze, then after a
 reboot, it happened a few hours later, now its been running several hours
 again without any issues …

 The machine itself is not frozen … I can connect via remote console,
 login, do ps, etc … so its as if the Ethernet (bce device) just went
 offline.

 I was pointed to a wiki about VirtualBox, and my current loader.conf looks
 like:

 ===
 aio_load=YES
 kern.ipc.shm_use_phys=1
 accf_http_load=YES
 if_bridge_load=YES
 if_tap_load=YES
 hw.pci.enable_msix=0
 vboxdrv_load=YES
 net.graph.maxdata=65536
 ===

 I'm running the latest version of 9-STABLE as well as the latest version
 of vBox available in ports … the bce device is an older version of
 Broadcom, so not dealing a new one with new features:

 bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B2)

 And as I say, these work great with jail'd environments ALIASed onto them …

 The vBox environments are all configured for network using:

 --nic1 bridged --bridgeadapter1 bce1

 Maybe I'm setting up the network wrong?  But, it does work for awhile …

 I'm not seeing any errors on the console when the ethernet stops working …
 nothing to indicate an buffer overflowing or something like that … but,
 again, I can login and run commands, so if there is something I can run to
 get more useful details … ?


 ___
 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

___
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

vlan on em0 cannot set MAC address.

[Zaphod Beeblebrox]

I have a FreeBSD-8.3 machine with an em0 interface in it.

em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.4 port 0xd400-0xd43f
mem 0xcffa-0xcffb,0xcff8-0xcff9 irq 12 at device 17.0 on
pci0
em0: [FILTER]
em0: Ethernet address: 00:0e:0c:bc:6f:87

For various reasons, I have more than one DSL interface, and for some time
I have run two PPPoE connections (using mpd4) and I run those PPPoE
connections over VLANs on the em0 interface.  There are two switches on the
path and both switches are sufficiently competent to understand that two
different VLANs include the same MAC address.

I'm convinced that I used to be connected to two separate DSLAM devices and
that after some line trouble, I was reassigned to two ports on a single
device.  This is because using the SAME MAC address on both VLANs stopped
working.

To fix this, I tried setting the MAC address on one of the VLANs.  This
does not work.  em0 no longer transmits the packet.

Expected behavior?  Are there drivers that support different MAC addresses
for different VLAN sub-devices?
___
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: igb network lockups

[Zaphod Beeblebrox]

For everyone having lockup problems with IGB, I'd like to ask if they could
try disabling hyperthreads --- this worked for me on one system but has
been unnecessary on others.
___
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: ipv6 route ignores MTU.

[Zaphod Beeblebrox]

On Thu, Dec 13, 2012 at 2:31 PM, John-Mark Gurney j...@funkthat.com wrote:


  The MTU in this case is set in the ifconfig_em0 rc.conf entry and the
  machine has been rebooted.

 Are you sure that the mtu is set before the ipv6 address is assigned
 to the interface?  The route inherits what ever MTU was on the interface
 when the route was created... It will be clamped if it is lower, but
 will not be increased...  This is so you can set the MTU on a route
 (say you have a broken low memory device that only accept 512 byte packets)
 and it will stay the way you set it..


Ordinarily, I would expect that since the MTU setting is in the
ifconfig_em0 configuration line, this was sufficient.  However, I realize
now that this is not the case.  Putting the MTU into the ipv6_ifconfig line
did the trick.  This is a rather serious violation of POLA --- I would
suggest that some thought should be given to how this is configured and
documented.
___
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

9.1-RC3 IGB dropping connections.

[Zaphod Beeblebrox]

I've got an Intel server motherboard with 4x igb (and 1x em) on it.
The motherboard in question is the S3420GPRX and the IGB's show up as:

igb0: Intel(R) PRO/1000 Network Connection version - 2.3.4 port
0x3020-0x303f mem 0xb1b2-0xb1b3,0xb1bc4000-0xb1bc7fff irq 19
at device 0.0 on pci3
igb0: Using MSIX interrupts with 9 vectors
igb0: Ethernet address: 00:1e:67:3a:d5:40
igb0: Bound queue 0 to cpu 0
igb0: Bound queue 1 to cpu 1
igb0: Bound queue 2 to cpu 2
igb0: Bound queue 3 to cpu 3
igb0: Bound queue 4 to cpu 4
igb0: Bound queue 5 to cpu 5
igb0: Bound queue 6 to cpu 6
igb0: Bound queue 7 to cpu 7

... now... I have this machine (right now) on the local lan with my
windows 7 workstation and putty sees the ssh connection as dropped
often.  I say often --- in that it can happen in a minute or two... it
often seems to happen when there is active output going to the window
(like a download counter running), but I also say often in that...
it seems slightly random... but it _is_ incessant... as in very
often.

This seems like something that we should ship with 9.1...
___
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: 9.1-RC3 IGB dropping connections.

[Zaphod Beeblebrox]

A further update to my problem: it only seems to occur when there is
largely traffic out ie: the window is active with ... but typing in
the window seems to prevent the effect.
___
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: 9.1-RC3 IGB dropping connections.

[Zaphod Beeblebrox]

To Jack Vogel's comment, this problem only seems to occur on systems
that are exceedingly lightly loaded (in this case, not yet in
production and I'm the only one using it).

On Tue, Nov 27, 2012 at 6:21 PM, Andre Oppermann an...@freebsd.org wrote:

 r243570 in CURRENT should likely fix this issue.  It's only 27 hours old
 and hasn't been MFC'd yet.

I'm not sure this addresses what I'm seeing.  It's a pause the the
traffic in the shell that is fixed by causing some traffic on the
return channel (watching for the pause --- and then hitting enter a
few times seems to fix it).  I'd expect that TCP retransmission should
take care of this regularly  ... but in this case, it doesn't... for
whatever reason ...
___
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: 9.1-RC3 IGB dropping connections.

[Zaphod Beeblebrox]

On Tue, Nov 27, 2012 at 9:25 PM, Mike Tancsa m...@sentex.net wrote:

 Are you using pf ? Also, did you confirm it is the igb nic and not
 something more general ? e.g. if you put in a different nic, does the
 problem go away ?

No pf, the motherboard em-driver NIC does not have this problem.

In reply to another message,

igb1@pci0:3:0:1:class=0x02 card=0x34f28086 chip=0x10c98086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82576 Gigabit Network Connection'
class  = network
subclass   = ethernet

Here is /var/log/messages.  The IPv6 chatter is something that
everything on the network has problems with --- duplicate IPv6
addresses that are not duplicate.

Nov 26 12:53:49 ccsw1 newsyslog[1419]: logfile first created
Nov 26 12:53:49 ccsw1 syslogd: kernel boot file is /boot/kernel/kernel
Nov 26 12:53:49 ccsw1 kernel: Copyright (c) 1992-2012 The FreeBSD Project.
Nov 26 12:53:49 ccsw1 kernel: Copyright (c) 1979, 1980, 1983, 1986,
1988, 1989, 1991, 1992, 1993, 1994
Nov 26 12:53:49 ccsw1 kernel: The Regents of the University of
California. All rights reserved.
Nov 26 12:53:49 ccsw1 kernel: FreeBSD is a registered trademark of The
FreeBSD Foundation.
Nov 26 12:53:49 ccsw1 kernel: FreeBSD 9.1-RC3 #0 r242324: Tue Oct 30
00:58:57 UTC 2012
Nov 26 12:53:49 ccsw1 kernel:
r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Nov 26 12:53:49 ccsw1 kernel: CPU: Intel(R) Xeon(R) CPU
X3440  @ 2.53GHz (2533.35-MHz K8-class CPU)
Nov 26 12:53:49 ccsw1 kernel: Origin = GenuineIntel  Id = 0x106e5
Family = 6  Model = 1e  Stepping = 5
Nov 26 12:53:49 ccsw1 kernel:
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Nov 26 12:53:49 ccsw1 kernel:
Features2=0x98e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT
Nov 26 12:53:49 ccsw1 kernel: AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM
Nov 26 12:53:49 ccsw1 kernel: AMD Features2=0x1LAHF
Nov 26 12:53:49 ccsw1 kernel: TSC: P-state invariant, performance statistics
Nov 26 12:53:49 ccsw1 kernel: real memory  = 17179869184 (16384 MB)
Nov 26 12:53:49 ccsw1 kernel: avail memory = 16458309632 (15695 MB)
Nov 26 12:53:49 ccsw1 kernel: Event timer LAPIC quality 400
Nov 26 12:53:49 ccsw1 kernel: ACPI APIC Table: INTEL  S3420GPR
Nov 26 12:53:49 ccsw1 kernel: FreeBSD/SMP: Multiprocessor System
Detected: 8 CPUs
Nov 26 12:53:49 ccsw1 kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) x
2 SMT threads
Nov 26 12:53:49 ccsw1 kernel: cpu0 (BSP): APIC ID:  0
Nov 26 12:53:49 ccsw1 kernel: cpu1 (AP): APIC ID:  1
Nov 26 12:53:49 ccsw1 kernel: cpu2 (AP): APIC ID:  2
Nov 26 12:53:49 ccsw1 kernel: cpu3 (AP): APIC ID:  3
Nov 26 12:53:49 ccsw1 kernel: cpu4 (AP): APIC ID:  4
Nov 26 12:53:49 ccsw1 kernel: cpu5 (AP): APIC ID:  5
Nov 26 12:53:49 ccsw1 kernel: cpu6 (AP): APIC ID:  6
Nov 26 12:53:49 ccsw1 kernel: cpu7 (AP): APIC ID:  7
Nov 26 12:53:49 ccsw1 kernel: ioapic0 Version 2.0 irqs 0-23 on motherboard
Nov 26 12:53:49 ccsw1 kernel: lapic0: Forcing LINT1 to edge trigger
Nov 26 12:53:49 ccsw1 kernel: kbd1 at kbdmux0
Nov 26 12:53:49 ccsw1 kernel: acpi0: INTEL S3420GPR on motherboard
Nov 26 12:53:49 ccsw1 kernel: acpi0: Power Button (fixed)
Nov 26 12:53:49 ccsw1 kernel: cpu0: ACPI CPU on acpi0
Nov 26 12:53:49 ccsw1 kernel: cpu1: ACPI CPU on acpi0
Nov 26 12:53:49 ccsw1 kernel: cpu2: ACPI CPU on acpi0
Nov 26 12:53:49 ccsw1 kernel: cpu3: ACPI CPU on acpi0
Nov 26 12:53:49 ccsw1 kernel: cpu4: ACPI CPU on acpi0
Nov 26 12:53:49 ccsw1 kernel: cpu5: ACPI CPU on acpi0
Nov 26 12:53:49 ccsw1 kernel: cpu6: ACPI CPU on acpi0
Nov 26 12:53:49 ccsw1 kernel: cpu7: ACPI CPU on acpi0
Nov 26 12:53:49 ccsw1 kernel: atrtc0: AT realtime clock port
0x70-0x71,0x74-0x77 irq 8 on acpi0
Nov 26 12:53:49 ccsw1 kernel: Event timer RTC frequency 32768 Hz quality 0
Nov 26 12:53:49 ccsw1 kernel: attimer0: AT timer port
0x40-0x43,0x50-0x53 irq 0 on acpi0
Nov 26 12:53:49 ccsw1 kernel: Timecounter i8254 frequency 1193182 Hz quality 0
Nov 26 12:53:49 ccsw1 kernel: Event timer i8254 frequency 1193182 Hz
quality 100
Nov 26 12:53:49 ccsw1 kernel: hpet0: High Precision Event Timer
iomem 0xfed0-0xfed003ff on acpi0
Nov 26 12:53:49 ccsw1 kernel: Timecounter HPET frequency 14318180 Hz
quality 950
Nov 26 12:53:49 ccsw1 kernel: Event timer HPET frequency 14318180 Hz
quality 550
Nov 26 12:53:49 ccsw1 kernel: Timecounter ACPI-fast frequency
3579545 Hz quality 900
Nov 26 12:53:49 ccsw1 kernel: acpi_timer0: 24-bit timer at
3.579545MHz port 0x408-0x40b on acpi0
Nov 26 12:53:49 ccsw1 kernel: pcib0: ACPI Host-PCI bridge port
0xcf8-0xcff on acpi0
Nov 26 12:53:49 ccsw1 kernel: pci0: ACPI PCI bus on pcib0
Nov 26 12:53:49 ccsw1 kernel: pcib1: ACPI PCI-PCI bridge irq 16 at
device 3.0 on pci0
Nov 26 12:53:49 ccsw1 kernel: pci1: ACPI PCI bus on pcib1
Nov 26 12:53:49 ccsw1 kernel: pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
Nov 26 12:53:49 ccsw1 kernel: pci2: ACPI PCI bus on pcib2
Nov 26 12:53:49 

Re: getting counters for a plenty of vlan ifaces

[Zaphod Beeblebrox]

On Sun, Sep 16, 2012 at 6:00 PM, Mike Tancsa m...@sentex.net wrote:
 On 9/16/2012 10:41 AM, Ivan Alexandrovich wrote:

 We are running freebsd9.0 on a router with
 more than 1000 of subscriber's vlan interfaces.
 Outgoing packet rate is approximately 40 kpps.

 There's a need to collect bytes and packets
 counters for all those vlan interfaces every
 minute (or even twice a minute) and store them

 Hi,
 We approach it a little differently and collect all the data via
 netflow, or in this case argus.  I sample the parent interface and save
 all the flow data which argus is smart enough to parse out at the vlan
 level.  You can then run all sorts of fine grained reports this way.  We
 use it on a system with about 900 ng interfaces.

I know that many people like netflow, but consider you're adding a
processing point per packet to solve a once per minute interface
sample.  Netflow has always struck me as a solution for closed systems
--- giving access to all possible information at moderate expense such
that you would then never have an excuse to want changes in the
operating system of the router.

It strikes me that a little kernel module that provided a kernel call
that (when called) walked the list of interfaces (in kernel) building
a table as described and then shipping that table to userland in one
go would be exceedingly cheep to call.  It would also not be part of
the packet forwarding path and not a potential constant cost during a
DDOS.  If someone wanted me to write a little .ko for that and an
associated userland utility, I'd be happy to do the work.
___
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

Adding CoDel to the stack.

[Zaphod Beeblebrox]

I was wondering if anyone had considered adding CoDel to the queuing
infrastructure in FreeBSD.  The ACM paper on it is
http://queue.acm.org/detail.cfm?id=2209336 .

The short of it is that current TCP behaviour encourages
router/switch buffers to always be full and that other solutions
like RED (Random Early Drop) are difficult to configure properly and
thus disfavoured.  This new solution uses completely different factors
to determine what to drop ... and in doing so is a zero-config
solution  only needing to know the speed of the link.
___
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: Full Cone NAT In PF

[Zaphod Beeblebrox]

On Sun, Apr 29, 2012 at 8:03 PM, Michael MacLeod mikemacl...@gmail.com wrote:

 Every once and a while I run into an issue wherein the symmetric NAT of pf
 causes me grief. I've found some older mailing list entries asking about PF
 and Cone or Full Cone NAT (such as this one from 2005:
 http://www.mail-archive.com/freebsd-pf@freebsd.org/msg00804.html), but I
 haven't seen anything new in a while.

 Almost all discussion I can find suggests to use static-port on the NAT
 rule entry, but this doesn't seem to be entirely the same thing. Adding
 static-port will prevent PF from randomizing the source port used for
 outbound TCP and UDP traffic, but I don't see any mention of it enabling
 actual Cone behaviour with regards to inbound traffic destined for the
 now-not-random port. It appears that a NAT table entry, even with the
 static-port option, will still not accept an inbound packet from external
 IP B when the NAT rule was originally created for external IP A, which I
 gather is the main thrust of cone NAT.

 I understand that cone NAT is a generally terrible and insecure way to do
 NAT, but game and application developers seem hell-bent on depending on
 cone NAT behaviour. Is there a way to make it work with PF?

You might want this because some of your internal machines play video
games.  The unfortunate thing is that some video games are somewhat
smart about getting around NAT and others are exceedingly dumb.  In
the end, what you do will depend on what resources you have.

I found that:

nat on $ext_if inet from $int_net to any - ($ext_if) static-port

is best paired by:

rdr on $ext_if inet from any to $ext_ip - $workstation_ip

now... this works well for one gaming workstation.  Also be clear that
the outside world is free to attack it.  You might want to put in a
bunch of rules to protect it's SMB and whatnot ports.

With just the 'nat' rule as above, CoD will call your NAT strict (in
red).  With both rules, CoD will call your NAT moderate in grey.
With just the first rule and borderlands, you'll be able to join but
not host games.  With both rules, you'll be able to host games.

I don't see an easy way to open only ports that are active with other
traffic on pf.
___
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: PXE Boot vmware 8.x fails after pxeboot.

[Zaphod Beeblebrox]

Replying to my own message again, I tried booting the same
configuration on the raw computer hardware (as opposed to vmware).  On
the raw computer hardware, pxeboot correctly loads a kernel and boots
it.  This seems to imply that pxeboot and vmware 8.x don't play well
together.

On Tue, Apr 3, 2012 at 1:27 AM, Zaphod Beeblebrox zbee...@gmail.com wrote:
 Replying to my own message, I add more below...

 On Sun, Apr 1, 2012 at 8:44 PM, Zaphod Beeblebrox zbee...@gmail.com wrote:
 I have had diskless FreeBSD machines before.  I started this project
 with an eye to booting iscsi disks, but there seems to be no way to
 communicate the root disk path (and parameters) to FreeBSD ---
 something that might be solvable, but I need practical at the moment.
 So I fall back on NFS diskless with PXE boot (I may have used
 etherboot in the past --- it's been awhile).

 Anyways... this attempt is made with FreeBSD-9.0-RELEASE binaries.

 In my network, 192.168.0.1 is the DHCP and TFTP server.  192.168.0.52
 is my NFS server.  The new vmware guest is bridged and gets
 192.168.0.135.  It successfully gets 'pxeboot' onto the vmware guest
 --- pxeboot prints it's banner.  Then the only network traffic I
 observe is DHCP Discover (vmware, presumably the pxeboot binary)
 followed by DHCP Offer (192.168.0.1 again) and this repeats.

 Now the dhcp offer gives a root path of
 192.168.0.52:/vr/diskless/hit ... and I've tried it with and without
 a trailing slash.

 Obviously this is something within the pxeboot's binary as no attempt
 to make the nfs mount occurs.

 ... With a few more variations of this test, I came across a
 configuration where the pxeboot client loaded into the vmware system
 would continue to spam the options next-server host to mount / ...
 interestingly here, it seems to completely ignore options root-path
 ... both the ip address and the path portions alike.

 ... but said behavior only occurs with some set of random
 configuration changes on the returned DHCP packets and/or slightly
 different versions of pxeboot (which I've pulled from various hosts
 from 8.x through the 9.x that I'm trying to boot with.

 It strikes me that the pxeboot process is hanging somewhere ... or
 overwriting memory ... or somesuch ... on this box.

 Has anyone seen or investigated this type of behavior?
___
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: PXE Boot vmware 8.x fails after pxeboot.

[Zaphod Beeblebrox]

Replying to my own message, I add more below...

On Sun, Apr 1, 2012 at 8:44 PM, Zaphod Beeblebrox zbee...@gmail.com wrote:
 I have had diskless FreeBSD machines before.  I started this project
 with an eye to booting iscsi disks, but there seems to be no way to
 communicate the root disk path (and parameters) to FreeBSD ---
 something that might be solvable, but I need practical at the moment.
 So I fall back on NFS diskless with PXE boot (I may have used
 etherboot in the past --- it's been awhile).

 Anyways... this attempt is made with FreeBSD-9.0-RELEASE binaries.

 In my network, 192.168.0.1 is the DHCP and TFTP server.  192.168.0.52
 is my NFS server.  The new vmware guest is bridged and gets
 192.168.0.135.  It successfully gets 'pxeboot' onto the vmware guest
 --- pxeboot prints it's banner.  Then the only network traffic I
 observe is DHCP Discover (vmware, presumably the pxeboot binary)
 followed by DHCP Offer (192.168.0.1 again) and this repeats.

 Now the dhcp offer gives a root path of
 192.168.0.52:/vr/diskless/hit ... and I've tried it with and without
 a trailing slash.

 Obviously this is something within the pxeboot's binary as no attempt
 to make the nfs mount occurs.

... With a few more variations of this test, I came across a
configuration where the pxeboot client loaded into the vmware system
would continue to spam the options next-server host to mount / ...
interestingly here, it seems to completely ignore options root-path
... both the ip address and the path portions alike.

... but said behavior only occurs with some set of random
configuration changes on the returned DHCP packets and/or slightly
different versions of pxeboot (which I've pulled from various hosts
from 8.x through the 9.x that I'm trying to boot with.

It strikes me that the pxeboot process is hanging somewhere ... or
overwriting memory ... or somesuch ... on this box.

Has anyone seen or investigated this type of behavior?
___
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

PXE Boot vmware 8.x fails after pxeboot.

[Zaphod Beeblebrox]

I have had diskless FreeBSD machines before.  I started this project
with an eye to booting iscsi disks, but there seems to be no way to
communicate the root disk path (and parameters) to FreeBSD ---
something that might be solvable, but I need practical at the moment.
So I fall back on NFS diskless with PXE boot (I may have used
etherboot in the past --- it's been awhile).

Anyways... this attempt is made with FreeBSD-9.0-RELEASE binaries.

In my network, 192.168.0.1 is the DHCP and TFTP server.  192.168.0.52
is my NFS server.  The new vmware guest is bridged and gets
192.168.0.135.  It successfully gets 'pxeboot' onto the vmware guest
--- pxeboot prints it's banner.  Then the only network traffic I
observe is DHCP Discover (vmware, presumably the pxeboot binary)
followed by DHCP Offer (192.168.0.1 again) and this repeats.

Now the dhcp offer gives a root path of
192.168.0.52:/vr/diskless/hit ... and I've tried it with and without
a trailing slash.

Obviously this is something within the pxeboot's binary as no attempt
to make the nfs mount occurs.
___
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: nmbclusters: how do we want to fix this for 8.3 ?

[Zaphod Beeblebrox]

It could do some good to think of the scale of the problem and maybe
the driver can tune to the hardware.

First, is 8k packet buffers a reasonable default on a GigE port?
Well... on a GigE port, you could have from 100k pps (packets per
second) at 1500 bytes to 500k pps at around 300 bytes to truly
pathological rates of packets (2M pps at the Ethernet-minimum of 64
bytes).  8k buffers vanish in 1/10th of a second in the 1500 byte case
and that doesn't even really speak to the buffers getting emptied by
other software.

Do you maybe want to have a switch whereby the GigE port is in
performance or non-performance mode?  Do you want to assume that
systems with GigE ports are also not pathologically low in memory?
Perhaps in 10 or 100 megabit mode, the driver should make smaller
rings?

For that matter, if mbufs come in a page's worth at a time, what's the
drawback of scaling them up and down with network vs. memory vs. cache
pressure?
___
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