Re: An interesting anomaly in NFS client...

On Nov 7, 2024, at 2:09 PM, Mark Johnston wrote: > > On Thu, Nov 07, 2024 at 07:28:59AM +0200, Andriy Gapon wrote: >> On 07/11/2024 02:43, George Neville-Neil wrote: >>> Howdy, >>> >>> We've been digging into an interesting possible issue in the FreeBSD NFS >>> client. Here is the scenario. I ha

Re: Discarding inbound ICMP REDIRECT by default

On Jun 13, 2024, at 6:39 AM, Rodney W. Grimes wrote: > >> I propose that we start dropping inbound ICMP REDIRECTs by default, by >> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >> changing the associated rc.conf machinery). I've opened a Phabricator >> review at https://re

Re: Question about netinet6/in6.h

On Apr 26, 2024, at 8:41 PM, Warner Losh wrote: > > > > On Fri, Apr 26, 2024, 9:33 PM Bakul Shah wrote: > > > > On Apr 26, 2024, at 5:02 PM, Mike Karels wrote: > > > > On 26 Apr 2024, at 18:06, Warner Losh wrote: > > > >> On Fri, Apr 26,

Re: Question about netinet6/in6.h

> On Apr 26, 2024, at 5:02 PM, Mike Karels wrote: > > On 26 Apr 2024, at 18:06, Warner Losh wrote: > >> On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote: >> >>> On 26 Apr 2024, at 15:49, Mike Karels wrote: >>> On 26 Apr 2024, at 15:01, Warner Losh wrote: > This has to be a

Re: Is there a FreeBSD equivalent of 'tcpdump -i any' from Linux?

Not quite what you asked for but I recently found https://github.com/gcla/termshark -- it seems to be like wireshark but for a terminal window. Like tcpdump it has the -D option that will return a list of interfaces. If you are handy with go programming, you may wish to consider enhancing it to

Re: Is there a way to deterministically bring up two usb ethernet interfaces?

On Jun 21, 2022, at 1:12 PM, Hans Petter Selasky wrote: > > Hi, > > On 6/21/22 22:01, Bakul Shah wrote: >> I think the problem is that the two interfaces don't always come up in the >> right sequence so which is ue0 and which is ue1 changes but they are >

Is there a way to deterministically bring up two usb ethernet interfaces?

I think the problem is that the two interfaces don't always come up in the right sequence so which is ue0 and which is ue1 changes but they are connected to specific networks. Thanks

Re: 60+% ping packet loss on Pi3 under -current and stable-13

This is due to tcpdump. > On May 2, 2022, at 8:53 AM, bob prohaska wrote: > > One new oddity is seeing in the daily security report the lines > www.zefox.org kernel log messages: > +ue0: promiscuous mode enabled > +ue0: promiscuous mode disabled > +ue0: promiscuous mode e

Re: 60+% ping packet loss on Pi3 under -current and stable-13

On May 1, 2022, at 11:12 AM, bob prohaska wrote: > The "oui unknown" looks like some sort of failure. Just ignore. tcpdump couldn't identify the vendor. Your tcpdump trace didn't give me anything useful. One suggestion is to use -n flag so that tcpdump doesn't do DNS resolution! Better, just

Re: 60+% ping packet loss on Pi3 under -current and stable-13

On Apr 29, 2022, at 7:12 PM, bob prohaska wrote: > > Since about December of 2021 I've been noticing problems with > wired network connectivity on a pair of raspberry pi 3 machines > using wired network connections. One runs stable-13.1, the other > runs -current, both are up to date as of a few

Re: bind(2) fails on 13.0-STABLE when sin_family is 0

On May 28, 2021, at 3:12 PM, Mark Johnston wrote: > > On Fri, May 28, 2021 at 02:40:26PM -0700, Bakul Shah wrote: >> ttcp runs fine on 13.0-RELEASE but fails on -stable. >> >> The culprit seems to be bind(2). Running ttcp under gdb: >> >> $ gdb a.out >>

bind(2) fails on 13.0-STABLE when sin_family is 0

ttcp runs fine on 13.0-RELEASE but fails on -stable. The culprit seems to be bind(2). Running ttcp under gdb: $ gdb a.out Reading symbols from a.out... (gdb) b 295 Breakpoint 1 at 0x203127: file ttcp.c, line 295. (gdb) run -s -r Starting program: /usr/ports/benchmarks/ttcp/work/ttcp-1.12_2/a.out

Re: localhost woes -- help requested

On Mon, 17 Jun 2019 13:15:22 -0700 "Ronald F. Guilmette" wrote: Ronald F. Guilmette writes: > Adam wrote: > > >On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette > >wrote: > >> ... except for the browsers, and also one other thing (nmh outbound > >> email handling). Now, both Firefox and Ope

Re: IP packet header visualization software

On Thu, 02 Nov 2017 00:46:25 +0300 DES <3...@inx.su> wrote: DES writes: > Hello FreeBSD-Net, > > does anybody remember, around year 2004, there was a software > application available (either as port, or package). Unfortunately I do > not recall the application name and I'm not able to find it ag

Re: Only last IP frag sent if ARP entry absent

RFC 826 is the one that says this: If it does not, it probably informs the caller that it is throwing the packet away (on the assumption the packet will be retransmitted by a higher network layer) Not worth fixing for the reasons you mention. > On Aug 17, 2017, at 8:33 PM, Mike Kare

Re: pf & NAT issue

I finally had some time to look at the sources & noticed /sys/netpfil/pf/pf.c:pf_purge_thread now runs 10 times a second instead of once a second, which gave me the idea of increasing "interval" timeout by a factor of 10 and this seems to have mostly fixed the problem. But I don't know where the ac

Re: pf & NAT issue

On Fri, 20 Jan 2017 13:12:07 PST =?UTF-8?Q?Ermal_Lu=C3=A7i?= wrote: > --001a1148cecc40685805468d1ad2 > Content-Type: text/plain; charset=UTF-8 > > On Fri, Jan 20, 2017 at 12:59 PM, Bakul Shah wrote: > > > On Fri, 20 Jan 2017 21:43:33 +0100 "Kristof Provost"

Re: pf & NAT issue

On Fri, 20 Jan 2017 12:59:33 PST Bakul Shah wrote: > On Fri, 20 Jan 2017 21:43:33 +0100 "Kristof Provost" wrote: > > On 20 Jan 2017, at 21:31, Bakul Shah wrote: > > >> 11:56:28.168693 IP 192.168.125.7.65042 > 149.20.1.200.21: Flags [P.], > > >> s

Re: pf & NAT issue

On Fri, 20 Jan 2017 21:43:33 +0100 "Kristof Provost" wrote: > On 20 Jan 2017, at 21:31, Bakul Shah wrote: > >> 11:56:28.168693 IP 192.168.125.7.65042 > 149.20.1.200.21: Flags [P.], > >> seq 1:10, ack 55, win 1026, options [nop,nop,TS val 198426 ecr >

Re: pf & NAT issue

On Fri, 20 Jan 2017 08:47:43 MST Alan Somers wrote: > On Fri, Jan 20, 2017 at 3:48 AM, Kristof Provost wrote: > > On 20 Jan 2017, at 9:35, Bakul Shah wrote: > >> > >> pf seems to drop NAT connections quite a bit. This seems to > >> happen much more frequentl

pf & NAT issue

pf seems to drop NAT connections quite a bit. This seems to happen much more frequently if there are delays involved (slow server or interactive use). Almost seems like pf losing track of NATted connections due to an uninitialized variable Often a retry or two works. Connecting from outside to

Re: close(2) while accept(2) is blocked

On Sat, 30 Mar 2013 09:14:34 PDT John-Mark Gurney wrote: > > As someone else pointed out in this thread, if a userland program > depends upon this behavior, it has a race condition in it... > > Thread 1 Thread 2Thread 3 >

Re: close(2) while accept(2) is blocked

On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro wrote: > > In other operating systems, such as Solaris and MacOS X, closing the > descriptor causes blocked system calls to return with an error. What happens if you select() on a socket and another thread closes this socket? Ideally select() should

Re: Replace bcopy() to update ether_addr

On Mon, 20 Aug 2012 13:05:51 MDT Warner Losh wrote: > > On Aug 20, 2012, at 10:48 AM, Wojciech Puchar wrote: > > >> #if defined(__i386__) || defined(__amd64__) > >> *dst =3D *src; > >> #else > >> bcopy(src, dst, ETHER_ADDR_LEN); > > #else > > short *tmp1=3D((*short)src),*tmp2=3D((*short)dst

Strange DNS problem

I am running a local dns server (bind9). It works ok for the most part but a number of domains do not resolve and I have not been able to detect any pattern. For instance $ host weather.com Host weather.com not found: 3(NXDOMAIN) Here is the tcpdump output (on the internal side): 21:45:14.6622

Re: tap dhcp

On Mon, 28 Sep 2009 15:21:17 CDT Adam Vande More wrote: > Am I doing something wrong here? > > kldload if_tap if_bridge > sysctl net.link.tap.user_open=1 > ifconfig tap0 create > ifconfig bridge create > ifconfig bridge0 addm tap0 addm em0 > > it# dhclient tap0 > DHCPDISCOVER on tap0 to 255.255

Re: A more pliable firewall

Thanks to everyone who responded. Looks like all the pieces to do this exist. All I have to do is to package it all in one program "sheriff" that watches various log files and pulls the trigger on the bad guy(s) at appropriate time. I think I will add a program to keep running stats on *all* the

A more pliable firewall

I am wondering if there is a more dynamic and scriptable firewall program. The idea is to send it alerts (with sender host address) whenever a dns probe fails or ssh login fails or smtpd finds it has been fed spam or your website is fed bad urls. This program will then update the firewall after a

Re: Problem with Bridging ... and bge devices under FreeBSD 7.x?

On Wed, 29 Oct 2008 01:38:38 -0300 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > > I only have one VM running on one server ... Ok. Here are some debugging suggestions. - /etc/sysctl.conf should have the following; net.link.tap.user_open=1 net.link.tap.up_on_open=1 run sysctl manu

Re: Problem with Bridging ... and bge devices under FreeBSD 7.x?

On Wed, 29 Oct 2008 00:35:35 -0300 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > netstat -nr on the 192 server shows the IP to be at: > > > netstat -nr | grep 168.1.100 > 192.168.1.100 52:54:00:12:34:56 UHLW11 fxp0 1128 > > which is very odd, as that MAC address is n

Re: tap devices ... restricting IP?

On Wed, 22 Oct 2008 01:01:39 -0300 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > Is it possible to assign an IP to a tap device, used by something like QEMU, > such that someone *inside* the QEMU environment can't modify? Or, if they do > modify their own IP, the network inside of QEMU will b

Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94)

Not sure where I got that idea. On Tue, 15 Jul 2008 16:17:04 PDT Julian Elischer <[EMAIL PROTECTED]> wrote: > Bakul Shah wrote: > > ... > > Presumably kqueue has a lower cpu usage until the system gets > > loaded at which point polling might win. > > I don&#x

Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94)

On Tue, 15 Jul 2008 15:39:09 PDT JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]> wrote: > At Tue, 15 Jul 2008 15:12:31 -0700, > Bakul Shah <[EMAIL PROTECTED]> wrote: > > > > Besides, I guess that the P1 versions severely suffer from he

Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94)

On Tue, 15 Jul 2008 14:18:41 PDT JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]> wrote: > At Tue, 15 Jul 2008 23:09:30 +0200, > Kris Kennaway <[EMAIL PROTECTED]> wrote: > > > > If that's regularly happening, I'm afraid recent P1 versions don't > > > handle that well, a

Re: arplookup x.x.x.x failed: host is not on local network

> Possibly, I'm seeing packet leakage from the switches and that is > confusing FreeBSD - definitely the first packet above should not be > visible. Even if the switch broadcasts on all ports (effectively becoming a hub) that should not cause the symptom you are seeing. If the switch sent arp res

Re: IP-forwarding (help)

On 05 Jun 2008 01:33:05 +0200 "Arno J. Klaassen" <[EMAIL PROTECTED]> wrote: > Petar Bogdanovic <[EMAIL PROTECTED]> writes: > > > On Wed, Jun 04, 2008 at 11:06:01PM +0200, Arno J. Klaassen wrote: > > > > > > Hello, > > > > > > this is probably a FAQ and/or I'm to tired, but I'd be pleased > > >

Re: multiple routing tables review patch ready for simple testing.

On Wed, 30 Apr 2008 18:56:07 BST "Bruce M. Simpson" <[EMAIL PROTECTED]> wrote: > > 2) If that decision is taken by a a packet 'classifier', > >isn't it in effect doing the job of a FIB (deciding the > >next hop, which happens to be a local FIB)? Recall that > >basically a packet passe

Re: multiple routing tables review patch ready for simple testing.

On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer <[EMAIL PROTECTED]> wrote: > > Interfaces are not however assigned to FIB instance. each FIB may > contain entries for each interface, and by default they do, but you > can delete teh entries associated with a particular interface from > a particu

Re: bikeshed for all!

Here is another idea spurred by this: > I understand that this feature is something which swaps in a different > forwarding table for the application one is currently running? > > And that it works in a manner similar to chroot()? Swapping in a different forwarding table is very much like swapp

Re: bikeshed for all!

> >> and the command should be called "" > > > > We called it vhost since to all other hosts it behaved like a > > host on a network. In our implementation each virtual host > > had a set of interfaces and one routing table and you could > > actually "route" packets between these hosts among

Re: bikeshed for all!

> I need a word to use to describe the network view one is currently on.. > > setuniverse 1 netstat -rn > [shows table 1] > setuniverse 2 route add 10.0.0.0/24 192.168.2.1 > setuinverse 1 route add 10.0.0.0/24 192.168.3.1 > setuniverse 2 route -n get 10.0.0.3 > [shows 192.168.2.1] > setuniver

Re: OS choice for an edge router

> This is not the case. Flood ping doesn't reach the limit in any > way. Have a look at the ping man page and flood ping description. Ah yes, I was forgetting about the strict synchrony. > Stock FreeBSD 6.2 or 7.0 can easily do 500kpps with good network > cards and fastforwarding enabled. On a

Re: OS choice for an edge router

> One of my concern is on the native forwarding capability of FreeBSD OS and the > execution of critical userland processes. I have experience before that a > FreeBSD box configured as router appears to slow down the userland processes > when the traffic load is high. I have verified this lately on

Re: walking (and cleaning) the routing table on mask change?

> what do you think about cleaning the routing table on mask change? I think it would be far easier and more correct to not allow just the mask change (which is never really needed). $ ifconfig tap0 10.1.1.0/24 $ netstat -nr | grep tap0 10.1.1.0/24link#6 UC 0

Re: iwi leaks memory?

> ok doesn't seem to have anything strange, nor there > seem to be any memory leak in iwi_init_locked... > > will keep the problem in mind, but right now i have no > ideas on what could happen. One data point: when I see a iwi0: could not allocate firmware DMA memory I close memory hog progra

Re: Looking for switch recommendations ...

> > For 100Mbps ports, the max packet rate in one direction is 10^8/672 == > > 148809 pps (packets per sec) per port. So for 24 port full duplex ports > > you get an aggregate maximum throughput of 148809*24*2 = 7738068 = > > 7.14Mpps (Million pps). For a 48 port switch it is 14.29Mpps. > > so, t

Re: Looking for switch recommendations ...

> What is the difference between Layer2 and Layer3, and what does that > affect? Layer3 == routing (based on IP destination address) Layer2 == switching (based on enet dest. address) Layer3 is probably not important for you. > HP: > Throughput: 2650 - 10.1 mpps (64-byte packets) 2626 - 6.6 mpps

Re: support of iso networking

> Any company which is going to have to modify an operating system to run > on their routers who ignores an operating system with a reputable network > stack merely because it lacks in-tree support for a particular protocol > isn't worth hte money. I am afraid it is not that simple. By using as m

Re: Problem in High Speed and Long Delay with FreeBSD

> Your suggestion of increasing the -l seems to have made a positive > impact -- tests this morning with a higher buffer length size of 8192 > gave us a better throughput of 44Mbps. Now the time sequence plot > shows a window usage of 1.5MB as opposed to the previous 1MB usage. > > We still don't

Re: Consistency of cached routes

I said: > If your problem is a cached route used for forwarding, you > ought to run something more recent than 19-Mar-2002 (which is > when Ruslan put in the fix in sys/netinet/in_rmx.c). I didn't look carefully enough. This bug fix was put in in_rmx.c rev 1.39. It didn't get merged back to -st

Re: Consistency of cached routes

> I saw your thread on Consistency of cached routes, and I'm having the same pr > oblem with my setup of bsd machines. When a new route is discovered, the out > dated cached route is still in the table and it doesn't expire fast enough. If your problem is a cached route used for forwarding, yo

Re: IP checksup update

> > > (c) -= (u_int16_t) *((u_int16_t *) (np)); \ > ^^ hmm should that be "+=" ? I believe your original code is correct. See the paragraph right before section 6 on Page 4, rfc1624. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" i

Re: IP checksup update

> to update a checksum when changing a word > > #define FIXSUM16(c, op, np) \ > do { \ > (c) -= (u_int16_t) ~*((u_int16_t *) (op)); \ > if ((c) < 0) {

Re: arp X moved from Y to Z messages

> > The gateway's IP address actually refers to two different machines. > > Naturally the gateway is used quite a bit, and the syslog fills up with "arp > > X moved from Y to Z on fxp0" messages. > > That's really not the right way to do it, and probably doesn't balance > the load as well as you m

Re: fastforwarding?

> This discussion has devolved into yet another idiotic bikeshed. Nobody > claimed anwhere along the line that fastforwarding was a solution to > all routing ills, suitable for use in a core router, or acceptable for > any of the wildly esoteric CRAP espoused in the past 10 or 12 messages > in t