Re: 13.0-BETA1: ipfw regression?
On Wednesday, February 10, 2021 7:46:25 AM CET Helge Oldach wrote: > Hi, > > Stefan Ehmann wrote on Tue, 09 Feb 2021 23:23:32 +0100 (CET): > > I'm having issues with stale TCP connections after the upgrade from 12.2 > > to > > 13.0-BETA1. > > > > Symptoms: > > Outgoing TCP connections no longer receive data after being idle. > > > > I can do more testing later, but I think these ipfw rules trigger the > > problem: - check-state > > - allow tcp from me to any setup keep-state > > - deny ip from any to any > > > > After establishing an outgoing connection (e.g, via netcat), I see a new > > dynamic rule and the 300s counter running down via > > # ipfw -Da list > > > > net.inet.ip.fw.dyn_keepalive is set to 1, so the timer should be refreshed > > via keep-alive on idle connections. > > > > Don't know if it's deterministic, but from what I've seen so far: > > - When counter gets low the first time, it is reset to 300 as expected. > > - When the counter nears zero for the second time, the dynamic rule is > > deleted and I get ipfw denies. > > I am afraid I can't reproduce. I have followed your test case however > I'm seeing that a TCP keepalive reliably triggers a timer refresh. For > example (sleep 1 loop over ipfw -Da list | grep): Tested in VirtualBox with amd64.vmdk from: https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-BETA1/ Terminal 1: kldload ipfw ipfw add check-state ipfw allow tcp from me to any setup keep-state /bin/sh (I don't speek csh) while true; do sleep 1; ipfw -Da list; done Terminal 2: nc 12345 On nc -l 12345 is running Updated to 187492ef639f, but nothing changed. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: DHCP and chnaging the MAC address on a network card
11.02.2021 6:26, Pete French wrote: > I have a machine runnign 12-STABLE, which gets its upstream IP address from > my ISP using DHCP over a cable modem. What I just tried to do was to set the > MAC address on that interface at boot time, but if I do that then it no > longer acquires a DHCP address from the upstream. > > Is there something going on here I dont understand ? > > The interfaces are 'bge' and I have a file called /etc/start_if.bge0 whcih > contains: > > /sbin/ifconfig $1 ether d0:bf:9c:46:a3:7c > > and this works (have tried it on bge1 and another machine) in changing the > MAC address. But if i do that on the DHCP interface then it doesnt get an IP > address. > > Any hints ? > > -pete. > > PS: reason am doing this is my ISP will (in future) be able to give me a > static IP address basd on the MAC address. Which is lovely, but I have a > spare server I use when this one goes down, so was hoping to have the same > MAC address if I boot the same drive, to avoid any issues caused by the MAc > address chnaging if I chnage the hardware. But it doesnt work. :) Try changing your command a bit: /sbin/ifconfig $1 ether d0:bf:9c:46:a3:7c up ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
DHCP and chnaging the MAC address on a network card
I have a machine runnign 12-STABLE, which gets its upstream IP address from my ISP using DHCP over a cable modem. What I just tried to do was to set the MAC address on that interface at boot time, but if I do that then it no longer acquires a DHCP address from the upstream. Is there something going on here I dont understand ? The interfaces are 'bge' and I have a file called /etc/start_if.bge0 whcih contains: /sbin/ifconfig $1 ether d0:bf:9c:46:a3:7c and this works (have tried it on bge1 and another machine) in changing the MAC address. But if i do that on the DHCP interface then it doesnt get an IP address. Any hints ? -pete. PS: reason am doing this is my ISP will (in future) be able to give me a static IP address basd on the MAC address. Which is lovely, but I have a spare server I use when this one goes down, so was hoping to have the same MAC address if I boot the same drive, to avoid any issues caused by the MAc address chnaging if I chnage the hardware. But it doesnt work. :) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Ugly black bars in dialog processor
Will it be likely/possible that the dialog processor in the base will be updated to include the fixes that have already appeared in the cdialog port? This has been an issue since day one or 13.0-CURRENT. Thanks for any assistance that you can provide. David Boyd. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 13.0-BETA1: ipfw regression?
On Wednesday, February 10, 2021 7:46:25 AM CET Helge Oldach wrote: > Hi, > > Stefan Ehmann wrote on Tue, 09 Feb 2021 23:23:32 +0100 (CET): > > I'm having issues with stale TCP connections after the upgrade from 12.2 > > to > > 13.0-BETA1. > > > > Symptoms: > > Outgoing TCP connections no longer receive data after being idle. > > > > I can do more testing later, but I think these ipfw rules trigger the > > problem: - check-state > > - allow tcp from me to any setup keep-state > > - deny ip from any to any > > > > After establishing an outgoing connection (e.g, via netcat), I see a new > > dynamic rule and the 300s counter running down via > > # ipfw -Da list > > > > net.inet.ip.fw.dyn_keepalive is set to 1, so the timer should be refreshed > > via keep-alive on idle connections. > > > > Don't know if it's deterministic, but from what I've seen so far: > > - When counter gets low the first time, it is reset to 300 as expected. > > - When the counter nears zero for the second time, the dynamic rule is > > deleted and I get ipfw denies. > > I am afraid I can't reproduce. I have followed your test case however > I'm seeing that a TCP keepalive reliably triggers a timer refresh. For > example (sleep 1 loop over ipfw -Da list | grep): > [...] Repeated my tests with tcpdump on remote host. What I see: First the timer goes down to ~20s and is reset to 300s (as expected). The remote host sees a keep-alive-packet at that point. On second run, there's no keep-alive packet seen on the remote host. Timer expires and rule is removed. Expected at this point since there was no keep-alive exchange. The connection is still working at this point (deny rule was deleted). > This is amd64 stable/13-n244495-7d9e00cd8bd which is slightly more > recent than BETA1 I believe. Can you share the git commit please I'm on releng/13.0 (just updated to 0b54d2764737). There are some additional commits in stable/13 (including sys/net). I can try stable later. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
mergemaster and etcupdate
Hi, I've used mergemaster for years like this: 1. mergemaster -p after the make installkernel step 2. mergemaster -Ui after the make installworld step Although I've seen nothing announced making etcupdate mandatory, I guess etcupdate will be the new way of doing things. My questions are: [a] what are the etcupdate equivalents of the above mergemaster commands? [b] do I need to do any prep before running make buildworld, or with any other step in the buildworld/installworld process? [c] when will mergemaster stop working? context: amd64 stable/13 thanks, -- J. signature.asc Description: PGP signature
Re: stable/13 and zfs <> openzfs
On Tue, Feb 09, 2021 at 03:40:43PM -0700, Alan Somers wrote: The new ZFS is backwards compatible with the old one. So your 12.2-p3 system will be able to zfs send, and the stable/13 will be able to zfs recv. You can go the other direction too, if you're careful to create the new pool using the old format, and don't turn on any of the new features. /etc/rc.conf shouldn't need any changes. Your upgrade plan sounds fine. But for the "backup all data" step, I would recommend using zfs send/recv to do the backup. That will do a better job of ensuring your files' integrity than something like rsync or cp. Hi, thanks for confirming. -- J. signature.asc Description: PGP signature
Re: 13.0-BETA1: ipfw regression?
On 10.02.2021 10:40, Dewayne Geraghty wrote: > Stefan, Would you check that you have net.inet.tcp.always_keepalive=1, > and perhaps that net.inet.tcp.keepidle and net.inet.tcp.keepintvl are > reasonable to ensure that the expected keep alives are running. I don't > have a FreeBSD 13 to view the defaults, but Helge might be right that > "it" is already fixed :) > Regards, Dewayne. ipfw does send its own keep-alive packets for TCP connections when state's lifetime expires. But if remote host doesn't reply this doesn't help. To check what happened Stefan needs to capture packet dump and inspect it. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
