ipfw during 13.0 -> 13.1 fbsd-update - loss of ipv4 connection ?

2022-07-31 Thread Kurt Jaeger
Hello, see also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265532 I had several cases where an freebsd-upgrade from 13.0 -> 13.1 with an active ipfw ruleset: # firewall, ipfw based firewall_enable="YES" firewall_type="OPEN" caused the host after reboot to loose ipv4 connectivity due to

Building driver for BCM57504 from Broadcom?

2022-06-24 Thread Kurt Jaeger
Hi! For more details, see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263046 Problem: Getting a BCM57504 card to work on FreeBSD Current state of affairs: There's a driver from Broadcom: https://www.broadcom.com/products/ethernet-connectivity/network-adapters/p425g as version

BCM57504 NetXtreme-E drivers ?

2022-04-04 Thread Kurt Jaeger
Hello, does anyone know of drivers for BCM57504 NetXtreme-E quad-port NICs ? Thanks! -- p...@freebsd.org +49 171 3101372 Now what ?

Re: why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?

2021-12-04 Thread Kurt Jaeger
Hi! > > rtr1 runs frr, has full route, either with or without default route. > > If that makes no difference then something else is wrong. I agree, but we have to find out, what is wrong... > > > (b) At the time this happens does rtr1 have a route to z.z.z.z ? > > > route -4 get z.z.z.z >

Re: why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?

2021-12-04 Thread Kurt Jaeger
Hi! > > 10:20:16.889185 IP x.x.x..1 > y.y.y.1: ICMP redirect z.z.z.z to host > > 0.0.0.0, length 48 > > whoops. > > This has been stopped by net.inet.ip.redirect=0 on rtr1, but my question is: > > > > Why is rtr1 sending those multi-hop icmp redirects at all ? > > Could you elaborate on: >

why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?

2021-12-04 Thread Kurt Jaeger
Hi! We (AS12502) recently upgraded one router from 12.2.x to 13.0.x. This caused some surprising effect, with the router sending out icmp redirects to 0.0.0.0 over multiple hops: Example: inet -- wan:rtr1:lan -- rtr2 -- wan:host x.x.x.1y.y.y.1

Workaround: Re: dtrace to trace incoming connection not suceeding ?

2021-11-19 Thread Kurt Jaeger
Hi! > > > There's one small diff between the two that I do not understand: > > > - 18040 times no signature provided by segment > > > + 18045 times no signature provided by segment > > > > This means, that received TCP segment has not TCP-MD5 signature, but > > listen socket expects

Re: dtrace to trace incoming connection not suceeding ?

2021-11-14 Thread Kurt Jaeger
Hi! > > There's one small diff between the two that I do not understand: > > > > - 18040 times no signature provided by segment > > + 18045 times no signature provided by segment > > This means, that received TCP segment has not TCP-MD5 signature, but > listen socket expects it.

Re: dtrace to trace incoming connection not suceeding ?

2021-11-12 Thread Kurt Jaeger
Hello, > > Background: a fbsd 13.0p4 amd64 box, with a frr-7.4_4 (or 7.5.1_3) > > fails to act on incoming ipv4 tcp 179 connections. That box above (c5) fails to speak to a 12.2-RELEASE-p7 box (c1). I have a second case, between a 12.2-RELEASE-p1 and this 12.2-RELEASE-p7 box (c9), same failure.

Re: dtrace to trace incoming connection not suceeding ?

2021-11-12 Thread Kurt Jaeger
Hi! > >> OK. Can you provide the output of > >> netstat -sptcp > >> after some packets were dropped. > Not sure why you provide two outputs. I did on the dest host: netstat -sptcp then a few telnet 179 then a second netstat -sptcp That's why I provided two outputs. There's one small

Re: dtrace to trace incoming connection not suceeding ?

2021-11-12 Thread Kurt Jaeger
Hi! > >>> The basic ipfw firewall is active, but > >> Does it work, if you disable ipfw? > > No, unfortunatly not. > OK. Can you provide the output of > netstat -sptcp > after some packets were dropped. https://people.freebsd.org/~pi/logs/netstat-t1.txt

Re: dtrace to trace incoming connection not suceeding ?

2021-11-12 Thread Kurt Jaeger
Hi! Changing interface flags does not change the status as well: $ ifconfig ix0 ix0: flags=8943 metric 0 mtu 1500 options=8000a8 -- p...@freebsd.org +49 171 3101372 Now what ?

Re: dtrace to trace incoming connection not suceeding ?

2021-11-12 Thread Kurt Jaeger
Hi! > > The basic ipfw firewall is active, but > Does it work, if you disable ipfw? No, unfortunatly not. -- p...@freebsd.org +49 171 3101372 Now what ?

Re: dtrace to trace incoming connection not suceeding ?

2021-11-12 Thread Kurt Jaeger
Hello, > The basic ipfw firewall is active, but but set to 'firewall_type="OPEN"' in /etc/rc.conf -- p...@freebsd.org +49 171 3101372 Now what ?

dtrace to trace incoming connection not suceeding ?

2021-11-12 Thread Kurt Jaeger
Hello, I'm trying to investigate tcp-179 connection issues with the local frr setup. See below for more background. The question is: What can I do to find the cause of the failing connection ? Is there a way to trace the incoming packet to see if it ever ends up at bgpd process ? Background: a

Re: source of ether address for tap0 ?

2021-04-21 Thread Kurt Jaeger
Hi! > > does anyone know how the system selects the MAC/ether adress of a > > newly-created tap0 device ? > > > > ifconfig tap0 create [...] > > How is that selected ? > > We had a case where two devices selected the same ether/MAC... > > tap MACs are derived from the hostid (/etc/hostid) --

source of ether address for tap0 ?

2021-04-20 Thread Kurt Jaeger
Hello, does anyone know how the system selects the MAC/ether adress of a newly-created tap0 device ? ifconfig tap0 create has this: tap0: flags=8802 metric 0 mtu 1500 options=8 ether 58:9c:fc:10:98:02 groups: tap media: Ethernet autoselect status: no

Re: Which cpu/mainboard for fast routing (bgp, full tables) ?

2021-03-28 Thread Kurt Jaeger
Hi! > That class of processor has fairly limited memory bandwidth. An E5 v3 or > greater should get you what you want, although finding a system that makes > good use of available PCIe lanes with a single socket configuration can > sometimes be maddening. AMD may have a variety of nice parts

Which cpu/mainboard for fast routing (bgp, full tables) ?

2021-03-27 Thread Kurt Jaeger
Hi! We currently operate routers (FreeBSD 12.x, frr7) with Xeon(R) CPU E3-1230 v6 @ 3.50GHz CPUs and 10g links. They get to around 5-6 gbit/s throughput. What kind of hardware can you all suggest, if we stay in the generic PC area, to improve the routing throughput ? -- p...@freebsd.org

Re: test suite for NIC features...

2020-07-20 Thread Kurt Jaeger
Hi! > Has anyone compiled a script/test suite for testing various NIC > features to make sure they work/function properly? > > That is, being able to run a couple interfaces back to back, and turn > off the features off on one, and make sure things like checksum offload > and the like work

Re: 10g IPsec ?

2019-11-07 Thread Kurt Jaeger
Hi! > At Stormshield we have various patches related to that topic that we can > share. > > On the flow id part, we have a patch that recompute a new flowid for the > IPsec flow after encapsulation based on the spi. > This force the usage of the same transmit queue on the network card side for

10g IPsec ?

2019-11-04 Thread Kurt Jaeger
Hi! Has anyone experience with operating a highspeed IPsec connection up to 10gigabit/s between 2 FreeBSD hosts ? Is that speed achievable ? How much tuning is necessary ? -- p...@opsec.eu+49 171 3101372One year to go !

Re: Bad DHCP Checksums over VLANs

2018-09-16 Thread Kurt Jaeger
Hi! > >> ifconfig igb0 -rxcsum -txcsum -wol -tso4 -vlanmtu -vlanhwtag > >> -vlanhwcsum -vlanhwtso > >> > >> Try to disable everything that can be disabled, e.g. LRO etc. > > > > Disabling vlanhwtag works around the problem. > > > > Also note that only DHCP traffic has this problem. If I assign

Re: Bad DHCP Checksums over VLANs

2018-09-15 Thread Kurt Jaeger
Hi! > The server NIC is common (I211), so maybe it's easy to reproduce. I'll > help as much as I can, of course. Can you disable all the options of the NIC ? ifconfig igb0 -rxcsum -txcsum -wol -tso4 -vlanmtu -vlanhwtag -vlanhwcsum -vlanhwtso Try to disable everything that can be disabled,

Re: NFS via IPv6 between 11.2-REL amd64 and larger (>45 files) directories?

2018-08-31 Thread Kurt Jaeger
Hi! > As Rick told me there's a ongoing debate on this, here's a copy > from my mail to stable@: PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231050 -- p...@freebsd.org +49 171 3101372 2 years to go ! ___

Re: NFS via IPv6 between 11.2-REL amd64 and larger (>45 files) directories?

2018-08-31 Thread Kurt Jaeger
Hi! As Rick told me there's a ongoing debate on this, here's a copy from my mail to stable@: I've seen a strange effect: NFS via IPv6 between 11.2-REL amd64 boxes failed for directories with more than 45 files or directories. Small directories worked. It seems to be an issue with ipv6

Re: A web server behind two gateways?

2017-07-17 Thread Kurt Jaeger
Hi! > I have a jail running a web server in LAN. There are two routers/WANs > that can connect LAN to the internet. I enabled NAT and port forwarding > to the web server on both routers. [...] > Can I configure either router/host/jail so that the web server sends the > response back to the IP

Re: BACnet on FreeBSD ?

2015-08-04 Thread Kurt Jaeger
Hi! Has anyone ever worked with BACnet on FreeBSD ? [...] There's a protocol stack (which needs more massaging to build on FreeBSD): http://sourceforge.net/projects/bacnet/ https://github.com/stargieg/bacnet-stack I don't know of anyone working on this actively. Are you going to

GPON SFP, any technical ideas ?

2014-11-04 Thread Kurt Jaeger
Hi! I got my hands on an GPON G.984.2 ClassB SFP and want to find a way to operate it using FreeBSD. What type of NIC with SFP slots can be recommended for this exotic use case ? It's data sheet: http://www.allnet.de/fileadmin/transfer/products/113608.pdf It's asymmetric with these specs:

Re: Intel 82574 issue reported on Slashdot

2013-02-09 Thread Kurt Jaeger
Hi! We don't even have the tool tcpreplay in the ports mentioned in that BLOG. net-mgmt/tcpreplay is not the same ? -- p...@opsec.eu+49 171 3101372 7 years to go ! ___ freebsd-net@freebsd.org mailing list

Re: ports/124825: tcpdump/print-pfsync feature request submitted to tcpdump on sourceforge

2012-09-02 Thread Kurt Jaeger
Hi! I added some pointer to your PR at: https://sourceforge.net/tracker/?func=detailatid=469576aid=3467532group_id=53066 The answer to that pointer was from http://sourceforge.net/users/guy_harris/ I, at least, have no plan to include anything that requires that, in order to build

Re: ports/124825: tcpdump/print-pfsync feature request submitted to tcpdump on sourceforge

2012-09-02 Thread Kurt Jaeger
Hi! So, if /usr/src/sbin/pfctl/Makefile would install pfctl.h and pfctl_parser.h into /usr/include/net, the tcpdump people would include print-pfsync.c. Any chance for this ? -- p...@opsec.eu+49 171 3101372 8 years to go !

Re: MPLS in freebsd

2012-05-06 Thread Kurt Jaeger
Hello, is there any on-job work on MPLS support in FreeBSD? Do you know this site ? It points to some svn repository with mpls patches. http://freebsd.mpls.in/ -- p...@opsec.eu+49 171 3101372 8 years to go ! ___

Re: Subject: ethernet Q-in-Q ?

2011-09-01 Thread Kurt Jaeger
Hi! Here's ugly patch against in 8.2-RELEASE (see attachment) that makes vlan nesting possible. Don't know about possible side effects though. I suppose it doesn't play well wth bridges etc. Is there an PR for that ? Should I create one 8-) ? Any comments on the side effects from other

ng_vlan since 8.x, was: Re: ethernet Q-in-Q ?

2011-09-01 Thread Kurt Jaeger
Hi! Ivan wrote: With ng_vlan nesting is also possible, but since 8.0 I had to comment out this node name check in ng_ether.c: if ((node = ng_name2noderef(NULL, ifp-if_xname)) != NULL) { NG_NODE_UNREF(node); return; About the ng_vlan approach -- 4 years

Re: ethernet Q-in-Q ?

2011-08-30 Thread Kurt Jaeger
Hi! What about 802.1q VLANs encapsulated in another 802.1q VLAN ? I found ng_vlan(4), mentioned in http://lists.freebsd.org/pipermail/freebsd-current/2005-December/058882.html Now I have to find out how to use it 8-) -- p...@opsec.eu+49 171 3101372 9

Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot

2010-07-21 Thread Kurt Jaeger
Hi! State-Changed-Why: Would you try the patch at the following URL and let me know whether it makes any difference? http://people.freebsd.org/~yongari/alc/alc.link.patch The system hanged @boot with this entry in /etc/rc.conf: ifconfig_alc0=inet 192.168.5.10 netmask 255.255.255.0 After

Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot

2010-07-21 Thread Kurt Jaeger
Hi! A reboot with connected cable follows this evening. A reboot with connected cable was booting successfully. -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-net@freebsd.org mailing list

Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot

2010-07-21 Thread Kurt Jaeger
Hi! A reboot with connected cable follows this evening. A reboot with connected cable was booting successfully. Would you show me verbose dmesg output? With verbose boot alc(4) will show additional information which may help to narrow down the issue.

Re: kern/148772: alc0 does not send/receive packets if not plugged in during boot

2010-07-19 Thread Kurt Jaeger
The following reply was made to PR kern/148772; it has been noted by GNATS. From: Kurt Jaeger fbsd...@opsec.eu To: freebsd-gnats-sub...@freebsd.org, freebsd-b...@freebsd.org Cc: Subject: Re: kern/148772: alc0 does not send/receive packets if not plugged in during boot Date: Mon, 19 Jul 2010 22

Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load

2010-05-23 Thread Kurt Jaeger
The following reply was made to PR kern/146792; it has been noted by GNATS. From: Kurt Jaeger p...@opsec.eu To: bug-follo...@freebsd.org, n...@gtelecom.ru Cc: Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load Date: Sun, 23 May 2010 16:19:25 +0200 Hi! I observe

Re: IPSec VPN NATD (problem with alias_address vs redirect_addr ess)

2003-11-16 Thread Kurt Jaeger
be willing/capable to add this to the code, if someone else (maybe LF.net?) would pay for the expense ? -- MfG/Best regards, Kurt Jaeger 17 years to go ! LF.net GmbHfon +49 711 90074-23 [EMAIL PROTECTED] Ruppmannstr. 27fax +49 711 90074-33 D-70565