Re: ACK filtering?

[Rozhuk Ivan]

On Tue, 18 Jul 2023 00:03:59 -0400
Mason Loring Bliss  wrote:

> I'm likely going to have to move to an Internet connection with
> asymmetric bandwidth soon, and I want to be proactive with the
> firewalling to avoid the connection choking on itself.
> 
> There's a fair amount of documentation out there for bumping the
> priority on acks with pf and altq, and that seems reasonable, but is
> there anything equivalent I can do with ipfw? I'd prefer ipfw if
> possible, but I'll switch if I need to.
> 

You can use ng_bpf for matching TCP ACK (if ipfw can not, I have no idea about 
ipfw).
https://reviews.freebsd.org/D30175
http://netlab.dhis.org/wiki/software:freebsd:igmpproxy_on_netgraph

ipfw can work with netgraph so you may adop these samples from raw ethernet
frames to ip packets.

Next step is put all non TCP ACKs to dumminet with limit to 90% of upstream 
bandwith
and pass TCP ACKs to upstream directly.


Also DNS, ICMP good to have high prio.
For links > 10mbps probably you will not see diff.
I stop play with that years ago )

Re: Bug in MAC filter on IGB/if_vlan?

[Rozhuk Ivan]

On Tue, 9 Nov 2021 13:30:46 -0500
Ryan Stone  wrote:

> You're trying to use different MACs with each vlan.  I don't believe
> that this is really a support configuration in our stack, although
> putting the interface into promiscuous I guess works.

I try to look into if_vlan code and if I understand correct it try to set
MAC to parent adapter and read parent adapter MAC change.

But it must add/remove MAC addr to/from H/W MAC filter, not change only one.
It done for multicast join/leave, but not done for if_vlan and probably some 
other cases.

Re: Bug in MAC filter on IGB/if_vlan?

[Rozhuk Ivan]

On Tue, 9 Nov 2021 08:39:12 -0600
Kevin Bowling  wrote:

> > I have in rc.conf:
> >
> > =
> > vlans_igb0="vlan77 vlan86 vlan87"
> > create_args_vlan87="vlan 87"
> > create_args_vlan86="vlan 86"
> > create_args_vlan77="vlan 77"
> > ifconfig_vlan87="inet 185.44.68.92 netmask 255.255.252.0 mtu 1500
> > down up" ifconfig_vlan87_alias0="link 00:aa:fa:dd:44:55"
> > ifconfig_vlan86="DHCP mtu 1500"
> > ifconfig_vlan86_alias0="link 00:ff:fa:dd:44:55"
> > ifconfig_vlan77="inet 192.168.0.254 netmask 255.255.255.0"
> > ifconfig_vlan77_alias0="link 00:0f:43:48:67:fe"
> > ifconfig_vlan77_ipv6="inet6 2001:470:2345:555::1/64 prefixlen 64
> > auto_linklocal"
> > ifconfig_igb0="-lro -tso -vlanhwtso mtu 9000 down up"
> >
> > =
> >
> > There is 4 different MAC addresses.
> > System is unavailable after boot until: ifconfig igb0 promisc down
> > up
> >
> > FreeBSD 13 build from fresh sources.
> >
> >
> > Is this a bug or this is normal?  
> 
> 
> Which chip?  Please post uname -a or git rev.

igb0@pci0:8:0:0:class=0x02 rev=0x03 hdr=0x00 vendor=0x8086 
device=0x1539 subvendor=0x1849 subdevice=0x1539
vendor = 'Intel Corporation'
device = 'I211 Gigabit Network Connection'
class  = network
subclass   = ethernet

514a095250b178ad81319bf8c30938c3f08dd16f
few days old build from 13 branch.


> Why do you have “down up” in the stateful config, please remove
> “down” and the MTU change and report back findings

It from some posts that recomend to use
ifconfig em0 mtu 2345 down up
to force mtu apply.

if_vlan allow to set incorrect mtu

[Rozhuk Ivan]

Hi!


Why if_vlan allow to set same MTU size or bigger as on parrent nic?


Setup:
- workstation with MTU 9000 and IPv4 on h/w nic
- server with MTU 9000 on h/w nic and IPv4 on vlan nic with MTU 9000 (set by 
defauil on iface creation)

This setup have issue:
- big packets from server->wks - OK
- big packets from wks->server - FAIL.

Server init sequence:
1. Create vlans
2. Set MTU lower than default on parent nic

Result: vlan have bigger or same MTU as parrent nic, but parrent nic reports 
IFCAP_VLAN_MTU.
Probably this is if_em driver issue or iflib.



This is rc.conf, vlan77 - where I got MTU 9000 and fail to receive packets:
=
vlans_igb0="vlan77 vlan86 vlan87"
create_args_vlan87="vlan 87"
create_args_vlan86="vlan 86"
create_args_vlan77="vlan 77"
ifconfig_vlan87="inet 15.44.77.2 netmask 255.255.252.0 mtu 1500 down up"
ifconfig_vlan87_alias0="link 00:aa:fa:dd:44:55"
ifconfig_vlan86="DHCP mtu 1500"
ifconfig_vlan86_alias0="link 00:ff:fa:dd:44:55"
ifconfig_vlan77="inet 192.168.0.254 netmask 255.255.255.0"
ifconfig_vlan77_alias0="link 00:0f:43:48:67:fe"
ifconfig_vlan77_ipv6="inet6 2001:470:2345:555::1/64 prefixlen 64 auto_linklocal"
ifconfig_igb0="-lro -tso -vlanhwtso mtu 9000 down up"
=

Bug in MAC filter on IGB/if_vlan?

[Rozhuk Ivan]

Hi!

I have in rc.conf:
=
vlans_igb0="vlan77 vlan86 vlan87"
create_args_vlan87="vlan 87"
create_args_vlan86="vlan 86"
create_args_vlan77="vlan 77"
ifconfig_vlan87="inet 185.44.68.92 netmask 255.255.252.0 mtu 1500 down up"
ifconfig_vlan87_alias0="link 00:aa:fa:dd:44:55"
ifconfig_vlan86="DHCP mtu 1500"
ifconfig_vlan86_alias0="link 00:ff:fa:dd:44:55"
ifconfig_vlan77="inet 192.168.0.254 netmask 255.255.255.0"
ifconfig_vlan77_alias0="link 00:0f:43:48:67:fe"
ifconfig_vlan77_ipv6="inet6 2001:470:2345:555::1/64 prefixlen 64 auto_linklocal"
ifconfig_igb0="-lro -tso -vlanhwtso mtu 9000 down up"
=

There is 4 different MAC addresses.
System is unavailable after boot until: ifconfig igb0 promisc down up

FreeBSD 13 build from fresh sources.


Is this a bug or this is normal?

Re: TCP connection ignore RST

[Rozhuk Ivan]

On Tue, 7 Sep 2021 10:47:01 +0200
Michael Tuexen  wrote:

> >>> I have strange case: FreeBSD 12.2 ignore TCP RST from windows host
> >>> and continue retransmitting packets. sockstat show that socket
> >>> connected even after many tcp rst packets received.
> >>> 
> >>> Any ideas how to fix it?
> >> Where is the trace taken? On the Windows side or on the FreeBSD
> >> side or somewhere else? Could you provide the .pcap file?
> >>   
> > 
> > From FreeBSD side.
> > 
> > https://reviews.freebsd.org/D28142
> > e82353f84c58da9a5c38bd471a09936c16a5b6ea
> > https://reviews.freebsd.org/D28143
> > d05d908d6d3c85479c84c707f931148439ae826b sysctl
> > net.inet.tcp.tolerate_missing_ts=1 this fixes issue for me.  
> That was my first guess, but after double checking, this code is not
> present in FreeBSD 12.2. However, it is present in stable/12.
> So could it be that you are using stable/12 and not 12.2?
> 

System build from:
commit 8c01699f9194cfa3805ac734ae912529a10c063a
CommitDate: Wed Jan 20 14:40:13 2021 +0100
Add some examples to script.1...

It is not "clean" 12.2, and it is a bit early than commits with fixes.

Re: TCP connection ignore RST

[Rozhuk Ivan]

On Sat, 4 Sep 2021 13:19:52 +0200
Michael Tuexen  wrote:

> > On 4. Sep 2021, at 01:37, Rozhuk Ivan  wrote:
> > 
> > Hi!
> > 
> > 
> > I have strange case: FreeBSD 12.2 ignore TCP RST from windows host
> > and continue retransmitting packets. sockstat show that socket
> > connected even after many tcp rst packets received.
> > 
> > Any ideas how to fix it?  
> Where is the trace taken? On the Windows side or on the FreeBSD side
> or somewhere else? Could you provide the .pcap file?
> 

From FreeBSD side.

https://reviews.freebsd.org/D28142 e82353f84c58da9a5c38bd471a09936c16a5b6ea
https://reviews.freebsd.org/D28143 d05d908d6d3c85479c84c707f931148439ae826b
sysctl net.inet.tcp.tolerate_missing_ts=1
this fixes issue for me.

TCP connection ignore RST

[Rozhuk Ivan]

Hi!


I have strange case: FreeBSD 12.2 ignore TCP RST from windows host and continue 
retransmitting packets.
sockstat show that socket connected even after many tcp rst packets received.

Any ideas how to fix it?


System build from:
commit 8c01699f9194cfa3805ac734ae912529a10c063a
CommitDate: Wed Jan 20 14:40:13 2021 +0100
Add some examples to script.1...


root@sa# sockstat -P tcp -v -s -S -p 389
USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS   
PATH STATE   CONN STATE   STACK   
as  2583  35 tcp4   192.168.33.89:62284   192.168.33.200:389
 ESTABLISHED  freebsd



root@sa# tcpdump -n - -i vmx0 tcp port 389
tcpdump: listening on vmx0, link-type EN10MB (Ethernet), capture size 262144 
bytes
01:32:19.128521 IP (tos 0x0, ttl 128, id 40117, offset 0, flags [none], proto 
TCP (6), length 60)
192.168.33.89.62284 > 192.168.33.200.389: Flags [S], cksum 0xc4a0 
(incorrect -> 0x4ba5), seq 3223907587, win 65535, options [mss 1460,nop,wscale 
10,sackOK,TS val 3640114415 ecr 0], length 0
01:32:19.128918 IP (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto TCP 
(6), length 60)
192.168.33.200.389 > 192.168.33.89.62284: Flags [S.], cksum 0xca32 
(correct), seq 1489249264, ack 3223907588, win 8192, options [mss 
1460,nop,wscale 8,sackOK,TS val 124116297 ecr 3640114415], length 0
01:32:19.128949 IP (tos 0x0, ttl 128, id 42613, offset 0, flags [none], proto 
TCP (6), length 52)
192.168.33.89.62284 > 192.168.33.200.389: Flags [.], cksum 0xc498 
(incorrect -> 0x10ff), seq 1, ack 1, win 2049, options [nop,nop,TS val 
3640114415 ecr 124116297], length 0
01:32:19.129431 IP (tos 0x0, ttl 128, id 24596, offset 0, flags [none], proto 
TCP (6), length 86)
192.168.33.89.62284 > 192.168.33.200.389: Flags [P.], cksum 0xc4ba 
(incorrect -> 0xe4b3), seq 1:35, ack 1, win 2049, options [nop,nop,TS val 
3640114415 ecr 124116297], length 34
01:32:19.130310 IP (tos 0x0, ttl 128, id 1, offset 0, flags [DF], proto TCP 
(6), length 74)
192.168.33.200.389 > 192.168.33.89.62284: Flags [P.], cksum 0x35bb 
(correct), seq 1:23, ack 35, win 260, options [nop,nop,TS val 124116297 ecr 
3640114415], length 22
01:32:19.131230 IP (tos 0x0, ttl 128, id 54687, offset 0, flags [none], proto 
TCP (6), length 163)
192.168.33.89.62284 > 192.168.33.200.389: Flags [P.], cksum 0xc507 
(incorrect -> 0x37f8), seq 35:146, ack 23, win 2049, options [nop,nop,TS val 
3640114415 ecr 124116297], length 111
01:32:19.131560 IP (tos 0x0, ttl 128, id 2, offset 0, flags [DF], proto TCP 
(6), length 585)
192.168.33.200.389 > 192.168.33.89.62284: Flags [P.], cksum 0x943d 
(correct), seq 23:556, ack 146, win 259, options [nop,nop,TS val 124116297 ecr 
3640114415], length 533
01:32:19.133323 IP (tos 0x0, ttl 128, id 50714, offset 0, flags [none], proto 
TCP (6), length 198)
192.168.33.89.62284 > 192.168.33.200.389: Flags [P.], cksum 0xc52a 
(incorrect -> 0x0ba5), seq 146:292, ack 556, win 2049, options [nop,nop,TS val 
3640114415 ecr 124116297], length 146
01:32:19.133861 IP (tos 0x0, ttl 128, id 3, offset 0, flags [DF], proto TCP 
(6), length 471)
192.168.33.200.389 > 192.168.33.89.62284: Flags [P.], cksum 0x3b5d 
(correct), seq 556:975, ack 292, win 259, options [nop,nop,TS val 124116298 ecr 
3640114415], length 419
01:32:19.135305 IP (tos 0x0, ttl 128, id 43284, offset 0, flags [none], proto 
TCP (6), length 115)
192.168.33.89.62284 > 192.168.33.200.389: Flags [P.], cksum 0xc4d7 
(incorrect -> 0xac6a), seq 292:355, ack 975, win 2049, options [nop,nop,TS val 
3640114415 ecr 124116298], length 63
01:32:19.135900 IP (tos 0x0, ttl 128, id 4, offset 0, flags [DF], proto TCP 
(6), length 1500)
192.168.33.200.389 > 192.168.33.89.62284: Flags [.], cksum 0x5ffb 
(correct), seq 975:2423, ack 355, win 258, options [nop,nop,TS val 124116298 
ecr 3640114415], length 1448
01:32:19.135913 IP (tos 0x0, ttl 128, id 5, offset 0, flags [DF], proto TCP 
(6), length 299)
192.168.33.200.389 > 192.168.33.89.62284: Flags [P.], cksum 0x7cb3 
(correct), seq 2423:2670, ack 355, win 258, options [nop,nop,TS val 124116298 
ecr 3640114415], length 247
01:32:19.135935 IP (tos 0x0, ttl 128, id 32903, offset 0, flags [none], proto 
TCP (6), length 52)
192.168.33.89.62284 > 192.168.33.200.389: Flags [.], cksum 0xc498 
(incorrect -> 0x0530), seq 355, ack 2670, win 2048, options [nop,nop,TS val 
3640114415 ecr 124116298], length 0
01:32:19.139239 IP (tos 0x0, ttl 128, id 64896, offset 0, flags [none], proto 
TCP (6), length 148)
192.168.33.89.62284 > 192.168.33.200.389: Flags [P.], cksum 0xc4f8 
(incorrect -> 0xd163), seq 355:451, ack 2670, win 2049, options [nop,nop,TS val 
3640114425 ecr 124116298], length 96
01:32:19.139753 IP (tos 0x0, ttl 128, id 6, offset 0, flags [DF], proto TCP 
(6), length 1218)
192.168.33.200.389 > 192.168.33.89.62284: Flags [P.], cksum 0x1c85 
(correct), seq 2670:3836, ack 451, win 258, options 

Re: How to run script on network address change?

[Rozhuk Ivan]

On Tue, 22 Jun 2021 09:52:18 -0600
Warner Losh  wrote:

> These two patches appear to be good (I’ll need to do a little testing)
> 
> But, can you update devd.conf(5) man page to include these new events
> in the IFNET section? If so, I’ll land this in the tree...
> 

This is updated version, they add param name for last arg, so:
"!system=IFNET subsystem=lan0 type=RENAME lan1" -> "!system=IFNET 
subsystem=lan0 type=RENAME name=lan1"
"!system=IFNET subsystem=lan0 type=ADDR_ADD 192.168.1.1" -> "!system=IFNET 
subsystem=lan0 type=ADDR_ADD address=192.168.1.1"

https://reviews.freebsd.org/D30839
https://reviews.freebsd.org/D30840

Re: How to run script on network address change?

[Rozhuk Ivan]

On Sun, 20 Jun 2021 08:42:46 -0600
Ian Lepore  wrote:

> > I have FreeBSD 13@amd64 router with DHCP client on uplink.
> > 
> > How to run script on IP address change?
> > 
> > 
> > I do not see events from devd, only:
> > !system=IFNET subsystem=em3 type=LINK_DOWN
> > !system=IFNET subsystem=em3 type=LINK_UP
> > 
> >   
> 
> You could use /etc/dhclient-exit-hooks script to take action after an
> IP address is bound.  See the manpage for dhclient-script for more
> info.


Thanks, I see some forum posts with this.

Re: How to run script on network address change?

[Rozhuk Ivan]

On Sun, 20 Jun 2021 16:23:38 +0200
"dmilith ."  wrote:

> Have you tried `route monitor`?
 
No, and I do not want keep running some daemon that will parse output.

But thanks, I found good place to add devctl_notify() calls.
Now devd have new events.


run:
ifconfig lan0 alias 192.168.1.1/24
ifconfig lan0 -alias 192.168.1.1
ifconfig lan0 inet6 ::

devd output:
!system=IFNET subsystem=lan0 type=ADDR_ADD 192.168.1.1
!system=IFNET subsystem=lan0 type=ADDR_DEL 192.168.1.1
!system=IFNET subsystem=lan0 type=ADDR_ADD ::


And even for netif rename:
ifconfig lan0 name lan1
ifconfig lan1 name lan0

devd output:
!system=IFNET subsystem=lan0 type=RENAME lan1
!system=IFNET subsystem=lan1 type=RENAME lan0
>From 18a08c5f17d3b54f029a4e8c9ffbcd1370dbf3b1 Mon Sep 17 00:00:00 2001
From: Rozhuk Ivan 
Date: Sun, 20 Jun 2021 19:10:36 +0300
Subject: [PATCH] sys/net/if.c: add RENAME devctl event

!system=IFNET subsystem=lan0 type=RENAME lan1
!system=IFNET subsystem=lan1 type=RENAME lan0
---
 sys/net/if.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sys/net/if.c b/sys/net/if.c
index f6926c43ef9..8c8a7f6f4f0 100644
--- a/sys/net/if.c
+++ b/sys/net/if.c
@@ -2681,6 +2681,7 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t data, struct thread *td)
 		EVENTHANDLER_INVOKE(ifnet_departure_event, ifp);
 
 		if_printf(ifp, "changing name to '%s'\n", new_name);
+		devctl_notify("IFNET", ifp->if_xname, "RENAME", new_name);
 
 		IF_ADDR_WLOCK(ifp);
 		strlcpy(ifp->if_xname, new_name, sizeof(ifp->if_xname));
>From ece5aba37afe51e7ffa1ec14b4cf9b3430a608b4 Mon Sep 17 00:00:00 2001
From: Rozhuk Ivan 
Date: Sun, 20 Jun 2021 19:22:55 +0300
Subject: [PATCH] sys/net/route.c: add devctl event handler

ifconfig lan0 alias 192.168.1.1/24
ifconfig lan0 -alias 192.168.1.1

output:
!system=IFNET subsystem=lan0 type=ADDR_ADD 192.168.1.1
!system=IFNET subsystem=lan0 type=ADDR_DEL 192.168.1.1
---
 sys/net/route.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/sys/net/route.c b/sys/net/route.c
index f07cb3f6581..4c1fed90caa 100644
--- a/sys/net/route.c
+++ b/sys/net/route.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -67,6 +68,7 @@
 
 #include 
 #include 
+#include 
 
 VNET_PCPUSTAT_DEFINE(struct rtstat, rtstat);
 
@@ -693,6 +695,8 @@ rt_maskedcopy(struct sockaddr *src, struct sockaddr *dst, struct sockaddr *netma
 int
 rt_addrmsg(int cmd, struct ifaddr *ifa, int fibnum)
 {
+	struct sockaddr *sa = ifa->ifa_addr;
+	struct ifnet *ifp = ifa->ifa_ifp;
 
 	KASSERT(cmd == RTM_ADD || cmd == RTM_DELETE,
 	("unexpected cmd %d", cmd));
@@ -701,6 +705,24 @@ rt_addrmsg(int cmd, struct ifaddr *ifa, int fibnum)
 
 	EVENTHANDLER_DIRECT_INVOKE(rt_addrmsg, ifa, cmd);
 
+#ifdef INET
+	if (sa->sa_family == AF_INET) {
+		char addrstr[INET_ADDRSTRLEN];
+		inet_ntoa_rstruct sockaddr_in*)sa)->sin_addr),
+		addrstr);
+		devctl_notify("IFNET", ifp->if_xname,
+		(cmd == RTM_ADD) ? "ADDR_ADD" : "ADDR_DEL", addrstr);
+	}
+#endif
+#ifdef INET6
+	if (sa->sa_family == AF_INET6) {
+		char addrstr[INET6_ADDRSTRLEN];
+		ip6_sprintf(addrstr, IFA_IN6(ifa));
+		devctl_notify("IFNET", ifp->if_xname,
+		(cmd == RTM_ADD) ? "ADDR_ADD" : "ADDR_DEL", addrstr);
+	}
+#endif
+
 	if (V_rt_add_addr_allfibs)
 		fibnum = RT_ALL_FIBS;
 	return (rtsock_addrmsg(cmd, ifa, fibnum));

How to run script on network address change?

[Rozhuk Ivan]

Hi!


I have FreeBSD 13@amd64 router with DHCP client on uplink.

How to run script on IP address change?


I do not see events from devd, only:
!system=IFNET subsystem=em3 type=LINK_DOWN
!system=IFNET subsystem=em3 type=LINK_UP

Re: TCP Connection hang - MSS again

[Rozhuk Ivan]

On Mon, 5 Apr 2021 13:04:19 +0200
tue...@freebsd.org wrote:

> > As I understand, in some cases remote host does not reply with MSS
> > option, and host behind router continue use mss 8960, that dropped
> > by router.  
> If the peer does not provide an MSS option, your local FreeBSD based
> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is
> 536. So I don't think this should be a problem.

Thats it!
Thanks, it was ~64k in mine config.

___
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: TCP Connection hang - MSS again

[Rozhuk Ivan]

On Mon, 5 Apr 2021 17:23:39 +0700
Eugene Grosbein  wrote:

> > Is any other other options to work around this?  
> 
> Yes. Each entry in the routing table has "mtu" attribute limiting TCP
> MSS, too. You should use default route with -mtu 1500 attribute. For
> example, in /etc/rc.conf:
> 
> defaultroute="X.X.X.X -mtu 1500"
> 

This help only if I do this on all hosts in network, this is to many management.


___
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: TCP Connection hang - MSS again

[Rozhuk Ivan]

On Mon, 5 Apr 2021 12:44:50 +0300
Rozhuk Ivan  wrote:


> FreeBSD 13 desktop have no known problems with other websites.
> Only with one remonte FreeBSD 12 with same sysctl.conf and mtu 9k.

Forgot.
FreeBSD 12 reply with MSS 8960, and I fix it in PF:
> scrub in on $ext_v4_if0 all max-mss 1400

so only https://online.sberbank.ru/CSAFront/index.do#/
time to time reply without mss option.
___
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"

TCP Connection hang - MSS again

[Rozhuk Ivan]

Hi!


TCP Connection hang then I try to open 
https://online.sberbank.ru/CSAFront/index.do#/

FreeBSD 13 desktop + FreeBSD 13 router (pf).
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/base/etc/sysctl.conf
FreeBSD 13 desktop have no known problems with other websites.
Only with one remonte FreeBSD 12 with same sysctl.conf and mtu 9k.
If I set mtu to 1500 on desktop - issue is gone.

Router pf.conf contain:
scrub out on $ext_v4_if0 all random-id min-ttl 128 max-mss 1400
scrub in on $ext_v4_if0 all max-mss 1400


Android 9 and FreeBSD 12.2 have no this issue (both @WiFi).


As I understand, in some cases remote host does not reply with MSS option, and 
host behind
router continue use mss 8960, that dropped by router.

(pf scrub rules disabled for this log), tcpdump | grep mss:
176.99.179.102.60903 > 194.54.14.131.443: Flags [S], cksum 0xd0a2 
(correct), seq 3696980106, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 3763275954 ecr 0], length 0
176.99.179.102.60719 > 194.54.14.131.443: Flags [S], cksum 0xd796 
(correct), seq 232307963, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1963519951 ecr 0], length 0
176.99.179.102.50146 > 194.54.14.131.443: Flags [S], cksum 0x1aa9 
(correct), seq 3968469659, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 3417199378 ecr 0], length 0
176.99.179.102.50646 > 194.54.14.131.443: Flags [S], cksum 0xb3ba 
(correct), seq 3774081696, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1089629786 ecr 0], length 0
176.99.179.102.56843 > 194.54.14.131.443: Flags [S], cksum 0xc4dd 
(correct), seq 647662718, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 4054756545 ecr 0], length 0
194.54.14.131.443 > 176.99.179.102.56843: Flags [S.], cksum 0x35dd 
(correct), seq 186241788, ack 647662719, win 65535, options [mss 
1380,nop,wscale 3,nop,nop,sackOK,nop,nop,TS val 2541298941 ecr 4054756545], 
length 0
176.99.179.102.65364 > 194.54.14.131.443: Flags [S], cksum 0x17a0 
(correct), seq 1603248650, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1794142451 ecr 0], length 0
176.99.179.102.59862 > 194.54.14.131.443: Flags [S], cksum 0x2736 
(correct), seq 4000339086, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 4084903147 ecr 0], length 0
176.99.179.102.60915 > 194.54.14.131.443: Flags [S], cksum 0xd964 
(correct), seq 95236311, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1297197380 ecr 0], length 0
176.99.179.102.58717 > 194.54.14.131.443: Flags [S], cksum 0xf92e 
(correct), seq 1785704794, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1392944917 ecr 0], length 0
194.54.14.131.443 > 176.99.179.102.58717: Flags [S.], cksum 0xe020 
(correct), seq 2800465814, ack 1785704795, win 65535, options [mss 
1380,nop,wscale 3,nop,nop,sackOK,nop,nop,TS val 2541366941 ecr 1392944917], 
length 0
176.99.179.102.53377 > 194.54.14.131.443: Flags [S], cksum 0x8fdd 
(correct), seq 3235103847, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1359134165 ecr 0], length 0


Is it possible to force FreeBSD always ask with tcp mss option?
Is any other other options to work around this?






Full connections log:

12:06:44.205766 70:85:c2:43:67:5b > 78:da:6e:28:c9:c0, ethertype IPv4 (0x0800), 
length 74: (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto TCP (6), length 
60)
176.99.179.102.54064 > 194.54.14.131.443: Flags [S], cksum 0xca3f 
(correct), seq 980200339, win 65535, options [mss 1400,nop,wscale 10,sackOK,TS 
val 1268859625 ecr 0], length 0
12:06:44.206997 78:da:6e:28:c9:c0 > 70:85:c2:43:67:5b, ethertype IPv4 (0x0800), 
length 60: (tos 0x0, ttl 59, id 57535, offset 0, flags [none], proto TCP (6), 
length 40)
194.54.14.131.443 > 176.99.179.102.54064: Flags [S.], cksum 0x5d05 
(correct), seq 2754330417, ack 980200340, win 0, length 0
12:06:44.207126 70:85:c2:43:67:5b > 78:da:6e:28:c9:c0, ethertype IPv4 (0x0800), 
length 54: (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto TCP (6), length 
40)
176.99.179.102.54064 > 194.54.14.131.443: Flags [.], cksum 0x5d06 
(correct), seq 1, ack 1, win 65535, length 0
12:06:44.210824 78:da:6e:28:c9:c0 > 70:85:c2:43:67:5b, ethertype IPv4 (0x0800), 
length 60: (tos 0x0, ttl 59, id 45037, offset 0, flags [DF], proto TCP (6), 
length 40)
194.54.14.131.443 > 176.99.179.102.54064: Flags [.], cksum 0x5d06 
(correct), seq 1, ack 1, win 65535, length 0
12:06:44.211130 70:85:c2:43:67:5b > 78:da:6e:28:c9:c0, ethertype IPv4 (0x0800), 
length 571: (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto TCP (6), 
length 557)
176.99.179.102.54064 > 194.54.14.131.443: Flags [P.], cksum 0x7667 
(correct), seq 1:518, ack 1, win 65535, length 517
12:06:44.214366 78:da:6e:28:c9:c0 > 70:85:c2:43:67:5b, ethertype IPv4 (0x0800), 
length 60: (tos 0x0, ttl 53, id 45320, offset 0, flags [DF], proto TCP (6), 
length 40)
194.54.14.131.443 > 176.99.179.102.54064: Flags [.], cksum 0x5d06 
(correct), seq 1, 

Re: Multicast issue, interface not leaving Mutlicast Group

[Rozhuk Ivan]

On Fri, 7 Aug 2020 15:25:25 +0200
Abelenda Diego  wrote:

> Hello,
> 
> I have discovered that I had a multicast issue for years I did not
> know about. I use a FreeBSD (opnsense) setup as router for my home
> network and have igmpproxy for IPTV. Somehow everything seems to
> work, until I realized that my ISP was making a DoS with multicast.
> It is pretty much what was described years ago here:
> https://forum.netgate.com/topic/62591/igmp-issues-causing-isp-to-perform-multicast-dos-on-my-pfsense/7.
> But the solution of not using FreeBSD seem weird. So dug a lot
> learning about Multicast IGMPv{2,3} etc in the process. Here is an
> abstract of what I found:
> 
> 
> igmpproxy is performing "correctly" in that it will act upon to
> IGMPv2 Join request from the TV box by joining the multicast groups
> correctly. When the TV Box sends an IGMPv2 Leave request, igmpproxy
> will remove the source IP from the multicast table on the interface
> (the code is here
> https://github.com/pali/igmpproxy/blob/b7940fc75b36d5bcc3a07654fc1af76f179302a9/src/mcgroup.c#L58-L60
> this same call is used for joining and leaving).
> 

You can drop all this and just forward (bridge) all multicast:
http://netlab.dhis.org/wiki/ru:software:freebsd:igmpproxy_on_netgraph
https://lists.freebsd.org/pipermail/freebsd-net/2011-December/030643.html
___
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"

WiFi with AC on FreeBSD

[Rozhuk Ivan]

Hi!

For peoples who want to use linux WiFi drivers on FreeBSD with minimum support 
overhead :)

This "how-to" (draft) describes how to use OpenWRT as driver with web GUI for 
WiFi adapters.
No more pain with slow speed, no strange wpa_supplicant gui tools :)

This upgrades WiFi speed from
media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11a
to 866Mbps on my notebook with intel 8265.


Resourses required:
- 256 Mb ram
- 128 Mb on hard drive
- IOMMU support
- FreeBSD AMD64


1. Download EFI based build.
WWW: https://openwrt.org/docs/guide-developer/uefi-bootable-image
cd /root/
fetch 
https://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-generic-squashfs-combined-efi.img.gz
gunzip openwrt-x86-64-generic-squashfs-combined-efi.img.gz


2. Install sysutils/bhyve-firmware from ports.
CSM not required.
Patch required to build port (last attached):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211074


3. Configure system:
WWW:
https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html
https://wiki.freebsd.org/bhyve/pci_passthru

echo 'net.link.tap.up_on_open=1' >> /etc/sysctl.conf


/etc/rc.conf:
kld_list="nmdm vmm"
cloned_interfaces="tap0"
ifconfig_tap0_name="wifi0"
ifconfig_wifi0="DHCP up"
ifconfig_wifi0_ipv6="inet6 accept_rtadv auto_linklocal -ifdisabled"


/boot/loader.conf
# bhyve PCI device passthru.
# "1/0/0" - PCI dev ident, see: pciconf -lv
pptdevs="1/0/0"

# For AMD systems
hw.vmm.amdvi.enable="1"


4. Start OpenWRT

/usr/sbin/bhyvectl --destroy --vm=owrt
/usr/sbin/bhyve \
-A \
-H \
-c 2 \
-m 256M \
-S \
-s 0:0,hostbridge \
-s 1:0,lpc -l com1,stdio \
-s 3:0,ahci-hd,openwrt-x86-64-generic-squashfs-combined-efi.img \
-s 5:0,e1000,tap0,mac=00:be:fa:76:45:01 \
-s 7,passthru,1/0/0 \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
owrt

To disable output remove: "-l com1,stdio"
"1/0/0" - PCI dev ident, same as in loader.conf.


5. Configure OpenWRT:
uci set network.lan.ipaddr='172.16.0.49'
uci set network.lan.netmask='255.255.255.0'
uci set network.lan.gateway='172.16.0.254'
uci add_list network.lan.dns='172.16.0.254'
uci commit network
/etc/init.d/network restart

opkg update
opkg install luci

Now web GUI can be used to install wpad*, hostapd*, WiFi driver and other staff.

If you want use OpenWRT as bridge - read this: 
https://openwrt.org/docs/guide-user/network/wifi/relay_configuration
Better to start with simple rourer+nat mode.



___
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: Multicast/SSDP not working (on VLAN interface)

[Rozhuk Ivan]

On Mon, 19 Mar 2018 16:11:05 -0700 (PDT)
"Rodney W. Grimes"  wrote:

> Are you running with "firewall_type="simple""?
> If so it is set to block all 224/4 packets, see this part
> of /etc/rc.firewall:
> # And stop draft-manning-dsua-03.txt (1 May 2000) nets
> (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST
> (class D), and class E) # on the outside interface
> ${fwcmd} table ${BAD_ADDR_TBL} add 0.0.0.0/8
> ${fwcmd} table ${BAD_ADDR_TBL} add 169.254.0.0/16
> ${fwcmd} table ${BAD_ADDR_TBL} add 192.0.2.0/24
> ${fwcmd} table ${BAD_ADDR_TBL} add 224.0.0.0/4
> ${fwcmd} table ${BAD_ADDR_TBL} add 240.0.0.0/4
> 
>   ${fwcmd} add deny all from any to "table($BAD_ADDR_TBL)" via
> ${oif}
> 
> Your route effected this as your packets are no longer trying to
> use an all interfaces path, but a specific interface, and that is
> probably not ${oif} of your firewall.
> 

One more fw tip: pf by default drops all IP packets with options, so IGMP does 
not work.
___
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: Multicast/SSDP not working (on VLAN interface)

[Rozhuk Ivan]

On Mon, 19 Mar 2018 22:29:12 +0100
Andreas Scherrer  wrote:

> Now, if I (manually) add a static route for 224.0.0.0/4 via the 
> interface the M-SEARCH messages are coming in, everything starts to
> work!
> 
> route add -net 224.0.0.0/4 -iface re1.32
> 
> The (main) problem here is that I have multiple networks with clients
> in them. So a static route does not REALLY solve my problem.
> 
> Also I do not (yet?) understand why the route should be required.
> 
> What I see is that ifmcstat -f inet -i re1.32 does not list a
> membership for 239.255.255.250 when it is not working, but does list
> the membership when it is working...

That is because many software use old dumb multicast socket api.
It requres that use add route to mc net via one net iface.
If no mc route present then OS will send all mc packets to default gw, using 
unicast gw mac addr instead of specific mc mac addr.
On linux all same.

Mine https://github.com/rozhuk-im/ssdpd can send and receive mc packet via many 
net ifaces.
___
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: upnp/dlna

[Rozhuk Ivan]

On Fri, 15 Jan 2016 14:52:25 +0100
Gerrit Kühn  wrote:

> So I have the strange feeling that my FreeBSD boxes ignore multicast
> packages on the receiving end. The only thing that works is sending a
> multicast package from the box. I did not change the default
> configuration of the network devices in any way, and actually they
> appear to be ok (I think):

...
You can also try my SSDP announcer: 
http://www.netlab.linkpc.net/wiki/en:software:ssdpd:index
It can announce any server, but you need to download xml from mediatomb with 
services description and pass in to config file.

At my home SSDPd + nginx + php = DLNA server works fine.


___
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: upnp/dlna

[Rozhuk Ivan]

On Fri, 15 Jan 2016 14:52:25 +0100
Gerrit Kühn  wrote:

> I have two FreeBSD boxes running mediatomb and minidlna. I also have a
> couple of clients, mostly internet radios by different manufacturers
> (Sangean, Philips, Renkforce...).
> I have the (weird) issue that neither mediatomb nor minidlna appears
> to see the multicasts discovery messages (not even with tcpdump!)
> sent by the clients. Subsequently they never answer them and are not
> found by the client devices.

PF by default drop all ip packets with options.
IGMP use ip options -> pf drop all igmp.


pass in quick inet6 proto icmp6 no state allow-opts # mld (igmp6) also here
pass out quick inet6 proto icmp6 no state allow-opts # mld (igmp6) also here

pass out quick inet proto udp to 224.0.0.0/4 no state allow-opts
pass out quick inet proto igmp to 224.0.0.0/4 no state allow-opts
pass out quick inet proto icmp no state allow-opts
pass out quick inet6 proto udp to ff00::/8 no state allow-opts # Allow send 
multicast
pass out quick inet6 proto icmp6 no state allow-opts # mld (igmp6) also here
pass out quick flags S/SA allow-opts

## Rules exception
pass in quick inet proto udp to 224.0.0.0/4 no state # Allow receive multicast
pass in quick inet proto igmp to 224.0.0.0/4 no state allow-opts
pass in quick inet proto icmp no state
pass in quick inet6 proto udp to ff00::/8 no state # Allow receive multicast
pass in quick inet6 proto icmp6 no state allow-opts # mld (igmp6) also here

___
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"

LAGG on netgraph + rc.d script

[Rozhuk Ivan]

Hi!


if_lagg together with two multicast igb at more than 100 megabits led
to 100% CPU interrupts one of the igb.
The problem is not reproduced on other systems without igb adapters.
So I gathered on lagg netgraph and with him there is no problem.


Manual on russian: 
http://netlab.dhis.org/wiki/ru:software:freebsd:lagg_on_netgraph


ng_lagg script
http://netlab.linkpc.net/download/software/FreeBSD/ng_lagg/ng_lagg.sh

Example
Create: ng_lagg.sh start xxxLAGG em0 em1 igb0
Destroy: ng_lagg.sh stop ngeth0
Add network adapter: ng_lagg.sh if_add xxxLAGG igb1
Remove network adapter: ng_lagg.sh if_del em0


rc.d script
http://netlab.linkpc.net/download/software/FreeBSD/ng_lagg/ng_lagg

Example:
ng_lagg_enable=YES
ng_lagg_interfaces=lagg0 xyzlagg
ng_lagg_lagg0=em0 em1
ng_lagg_xyzlagg=xl0 igb1
ifconfig_lagg0=inet 192.168.11.77 netmask 255.255.255.0
ifconfig_xyzlagg=inet 192.168.22.77 netmask 255.255.255.0

vlans_lagg0=vlan1234
create_args_vlan1234=vlan 1234
ifconfig_vlan1234=inet 192.168.0.77 netmask 255.255.255.0

___
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_vlan improvements

[Rozhuk Ivan]

Diffs

 
--
Rozhuk Ivan
  




ng_vlan.h.orig.patch
Description: Binary data


ng_vlan.c.orig.patch
Description: Binary data
___
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

kern/152141: [vlan] encapsulate vlan in ng_ether before output to if

[Rozhuk Ivan]

Hi!


This is a patch for ng_ether_rcv_lower function in ng_ether.c to encapsulate
vlan before send to net.

 
--
Rozhuk Ivan
  



ng_ether.patch
Description: Binary data
___
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

struct sockaddr_in6 ia_net - unused

[Rozhuk Ivan]

Hi!

/usr/src/sys/netinet6/in6_var.h:struct  sockaddr_in6 ia_net;/*
network number of interface */

Looks like unused in inet6: defined but never used in code.



firewall# grep -r ia_net /usr/src/sys

grep: warning: /usr/src/sys/modules/netgraph/viface/@: recursive directory
loop
/usr/src/sys/netinet/in.c:  if ((i  ia-ia_netmask) ==
ia-ia_net) {
/usr/src/sys/netinet/in.c:  ia-ia_netmask = IN_CLASSA_NET;
/usr/src/sys/netinet/in.c:  ia-ia_netmask = IN_CLASSB_NET;
/usr/src/sys/netinet/in.c:  ia-ia_netmask = IN_CLASSC_NET;
/usr/src/sys/netinet/in.c:  ia-ia_subnetmask = ia-ia_netmask;
/usr/src/sys/netinet/in.c:  ia-ia_netmask = ia-ia_subnetmask;
/usr/src/sys/netinet/in.c:  ia-ia_net = i  ia-ia_netmask;
/usr/src/sys/netinet/in.c:  ia-ia_netbroadcast.s_addr =
/usr/src/sys/netinet/in.c:  htonl(ia-ia_net | ~
ia-ia_netmask);
/usr/src/sys/netinet/in.c:   in.s_addr ==
ia-ia_netbroadcast.s_addr ||
/usr/src/sys/netinet/in.c:   t == ia-ia_subnet || t ==
ia-ia_net) 
/usr/src/sys/netinet/in_debug.c:IA_DB_RPINTF(0x%08lx, ia_net);
/usr/src/sys/netinet/in_debug.c:IA_DB_RPINTF(0x%08lx, ia_netmask);
/usr/src/sys/netinet/in_debug.c:IA_DB_RPINTF(0x%08x,
ia_netbroadcast.s_addr);
/usr/src/sys/netinet/in_var.h:  u_long  ia_net; /* network
number of interface */
/usr/src/sys/netinet/in_var.h:  u_long  ia_netmask; /* mask of
net part */
/usr/src/sys/netinet/in_var.h:  struct  in_addr ia_netbroadcast; /* to
recognize net broadcasts */
/usr/src/sys/netinet/ip_input.c:if
(ia-ia_netbroadcast.s_addr == ip-ip_dst.s_addr) {
/usr/src/sys/netinet6/in6_var.h:struct  sockaddr_in6 ia_net;/*
network number of interface */
/usr/src/sys/netipx/ipx_if.h:   struct  sockaddr_ipx ia_netmask;/*
space for my network mask */

 
--
Rozhuk Ivan
  



___
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

kern/152141: [vlan] encapsulate vlan in ng_ether before output to if

[Rozhuk Ivan]

This is a patched version of original function

code
/*
 * If underlying interface can not do VLAN tag insertion itself
 * then attach a packet tag that holds it.
 */
if ((m-m_flags  M_VLANTAG) 
(ifp-if_capenable  IFCAP_VLAN_HWTAGGING) == 0) {
m = ether_vlanencap(m, m-m_pkthdr.ether_vtag);
if (m == NULL) {
ifp-if_oerrors++;
return (ENOBUFS);
}
m-m_flags = ~M_VLANTAG;
}


was added

 
--
Rozhuk Ivan
  



___
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