ipv6 only host and no IPV4 in jail?

[Benoit Chesneau]

Hi all,

I have a weird issue there,

I have an ipv6 only host aon which I am starting a jail.Jalil have a vnet 
interface through a bridge created on the host:

For some reason the jail can't get access and is not accessible to internet 
when I setup an IPV4 on it (and right gateway). Is this something expected? 
SHould the Host be also IPV4 aware?

Host config:

Host:
```
vlan200bridge: flags=8843 metric 0 mtu 
9000
ether 58:9c:fc:10:fc:41
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: e0a_bastille4 flags=143
ifmaxaddr 0 port 8 priority 128 path cost 2000
member: tap0 flags=143
ifmaxaddr 0 port 9 priority 128 path cost 200
member: tap1 flags=143
ifmaxaddr 0 port 10 priority 128 path cost 200
member: vlan200 flags=143
ifmaxaddr 0 port 6 priority 128 path cost 800 groups: bridge

e0a_bastille4: flags=8963 
metric 0 mtu 9000
description: vnet host interface for Bastille jail fpcouchdb
options=8
ether 02:20:9c:4c:84:f0
hwaddr 02:c4:b5:3a:91:0a
groups: epair
media: Ethernet 10Gbase-T (10Gbase-T )
status: active nd6 options=29
```

Guest

```
# ifconfig vnet0
vnet0: flags=8863 metric 0 mtu 1500
options=8
ether 0e:20:9c:4c:84:f0
hwaddr 02:c4:b5:3a:91:0b
inet6 :::200::30 prefixlen 64
inet6 fe80::c20:9cff:fe4c:84f0%vnet0 prefixlen 64 scopeid 0x2
inet 10.200.1.8 netmask 0xff00 broadcast 10.200.1.255
groups: epair
media: Ethernet 10Gbase-T (10Gbase-T )
status: active nd6 options=21
# netstat -rn4
Routing tables

Internet:
Destination Gateway Flags Netif Expire
default 10.200.1.1 UGS vnet0
10.200.1.0/24 link#2 U vnet0
10.200.1.8 link#2 UHS lo0127.0.0.1 link#1 UH lo0

```

Benoît Chesneau, Enki Multimedia
—
t. +33608655490

Sent with [Proton Mail](https://proton.me/) secure email.

Re: ipv6 only host and no IPV4 in jail?

[felix . reichenberger]

Hi,

since your VNET jail has its own network stack, it shouldn't matter that your 
host is IPv6-only.
I myself run dual-stack Bastille jails on IPv6-only hosts without any problems.

What kind of errors do you get when trying to access the internet via IPv4 from 
your jail, and does it work with IPv6?

Regards


2. Okt. 2023, 11:55 von beno...@enki-multimedia.eu:

> Hi all, 
>
> I have a weird issue there,
>
> I have an ipv6 only host aon which I am starting a jail.Jalil have a vnet 
> interface  through a bridge created on the host:
>
> For some reason the jail can't get access and is not accessible to internet 
> when I setup an IPV4 on it (and right gateway). Is this something expected? 
> SHould the Host be also IPV4 aware?
>
> Host config:
>
> Host:
> ```
> vlan200bridge: flags=8843 metric 0 
> mtu 9000
> ether 58:9c:fc:10:fc:41
> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> member: e0a_bastille4 flags=143
>        ifmaxaddr 0 port 8 priority 128 path cost 2000
> member: tap0 flags=143
>        ifmaxaddr 0 port 9 priority 128 path cost 200
> member: tap1 flags=143
>        ifmaxaddr 0 port 10 priority 128 path cost 200
> member: vlan200 flags=143
>        ifmaxaddr 0 port 6 priority 128 path cost 800
> groups: bridge
>
> e0a_bastille4: flags=8963 
> metric 0 mtu 9000
> description: vnet host interface for Bastille jail fpcouchdb
> options=8
> ether 02:20:9c:4c:84:f0
> hwaddr 02:c4:b5:3a:91:0a
> groups: epair
> media: Ethernet 10Gbase-T (10Gbase-T )
> status: active
> nd6 options=29
> ```
>
> Guest
>
> ```
> # ifconfig vnet0
> vnet0: flags=8863 metric 0 mtu 1500
> options=8
> ether 0e:20:9c:4c:84:f0
> hwaddr 02:c4:b5:3a:91:0b
> inet6 :::200::30 prefixlen 64
> inet6 fe80::c20:9cff:fe4c:84f0%vnet0 prefixlen 64 scopeid 0x2
> inet 10.200.1.8 netmask 0xff00 broadcast 10.200.1.255
> groups: epair
> media: Ethernet 10Gbase-T (10Gbase-T )
> status: active
> nd6 options=21
> # netstat -rn4
> Routing tables
>
> Internet:
> Destination        Gateway            Flags     Netif Expire
> default            10.200.1.1         UGS       vnet0
> 10.200.1.0/24      link#2             U         vnet0
> 10.200.1.8         link#2             UHS         lo0
> 127.0.0.1          link#1             UH          lo0
> ```
>
> Benoît Chesneau, Enki Multimedia
> —
> t. +33608655490 
>
> Sent with > Proton Mail >  secure email.
>

[Bug 274009] in_pcblookup_hash_locked: invalid local address panic on sendto(2) to ipv4-mapped

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274009

--- Comment #9 from Benjamin Jacobs  ---
(In reply to Mark Johnston from comment #6)

Hi, yes it does seem to be that same issue.

(In reply to Michael Tuexen from comment #8)

My 2 cents: the version flag is indeed tricky because - as noted by
Mark in its revision - an AF_INET6 UDP socket can transition back and
forth between v4 and v6 (either by using connect() and/or sendto). I'm
not sure either that getting rid of it is the right approach because
the code ends up having to pass around an extra flag argument all over
the place. But there are also some unclear locking rules, as stated in
the comment around the in_pcb stuff, which makes the whole concept far
from trivial for me to understand :)

Nonetheless, I made a patch in a way for me to have something
working. But it does seem all very hacky and ugly to carry an argument
for "it is actually a v4-mapped" flag to all callers, and callers of
callers, of the in_pcb_lport_dest. Also I did not completely
understood the implication w.r.t. the handling of wildcard
addresses. And possible concurrency issues are likely not addressed.
Anyway, that might be of interest to you.

Side note: it is trivial to trigger the bug using "sysctl
net.inet6.ip6.v6only=0; drill @:::8.8.8.8 freebsd.org"

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 274009] in_pcblookup_hash_locked: invalid local address panic on sendto(2) to ipv4-mapped

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274009

--- Comment #10 from Benjamin Jacobs  ---
Created attachment 245375
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=245375&action=edit
Adds a flag argument to in_pcb_lport_dest to support v4-mapped

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 274009] in_pcblookup_hash_locked: invalid local address panic on sendto(2) to ipv4-mapped

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274009

--- Comment #11 from Gleb Smirnoff  ---
What about adding extra inp_vflag for mapped pcbs? So that in_pcb.c code can
tell regular IPv4 inpcb from mapped one?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 264014] QinQ not working with a lot of switches

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264014

--- Comment #1 from Zhenlei Huang  ---
The IEEE 802.1AD published at May 26,2006 [1]. That is about 17 years ago at
the time writing.

> There are a lot of switches on the market with QinQ support, but not all 
> support
> QinQ according to IEEE 802.1AD. This is because of historical reasons. Before 
> IEEE 
> finished 802.1AD, vendores implemented pre-802.1AD standards, often called 
> 802.1QinQ
> or something like that. 

To be honest, it does not require much effort to support them in FreeBSD net
stack. But I am *personally* not willing to do so, as these devices are
manufactured at ancient times. Probably they are EOL and out of support event
by the vendors.

> Today, you can still buy modern switches with legacy/proprietary QinQ
> implementation. Those use EhterTypes like 0x9100 for example. Some but not 
> much 
> switches allow to modify the EtherType to  0x88A8 according to 802.1AD or set 
> the 
> EtherType of QinQ to custom values (for example Dell OS6 allows both).

So the default EtherType should be 0x88A8 (802.1AD). 0x9100 should be chosen
only for interoperability with ancient devices.

1. https://www.ieee802.org/1/pages/802.1ad.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 264014] QinQ not working with a lot of switches

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264014

--- Comment #2 from Layer8  ---
Thanks for reqly, Zhenlei Huang.

The assumption that only old devices which are End of Life use non 802.1AD
compliant Ethertypes is unfortunately not correct. 

Because I dont know every switch OS on the market, I cant tell how many
Switch-OS use non compliant QinQ Ethertypes. But:

I personally work with Dell Power Switch switches which have Dell OS6
installed. This is a switch OS from Dell, which is old and matured, but still
under development. I was invited to a Dell event in the end of 2022 where the
have shown a roadmap. According to this information, they are not planning to
end support or development of this OS, because its the default Switch OS on
Dell Access Level switches which is included if you buy a Dell Switch (they
also support some other Open Network Operating Systems). 

This is the user guide of the last last major version of Dell OS6 v6.8: 

https://dl.dell.com/content/manual20646349-dell-networking-n-series-switches-user-guide-version-6-8-0.pdf?language=en-us

On page 677 you will find the information, that they are still using 9100 for Q
in Q.

The last update is 6.8.1.3 from August 24 2023. 

They still release new switch series which are supported by OS6 (the last is
the N3200E switch series which was released 2022).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 264014] QinQ not working with a lot of switches

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264014

--- Comment #3 from Layer8  ---
Oh, forgot to add the following information:

Yes, its possible to change the QinQ Ethertype in Dell OS6, but we have
customers with grown environments where they dont want to change the ethertype
because of legacy applications.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 274009] in_pcblookup_hash_locked: invalid local address panic on sendto(2) to ipv4-mapped

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274009

--- Comment #12 from Michael Tuexen  ---
(In reply to Gleb Smirnoff from comment #11)
Why? Don't we know the state right now from inp_vflag? We just adapt the value
to the usage of the inp.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 206544] sendmsg(2) (sendto(2) too?) can fail with EINVAL; isn't documented in manpage

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206544

Peter Jeremy  changed:

   What|Removed |Added

 CC||pet...@freebsd.org

--- Comment #7 from Peter Jeremy  ---
I've bumped into the lack of documentation as well, though the triggers were
hidden far more deeply in the kernel:
1) An incorrect cmsg_len will typically trigger EINVAL.
2) Using IPv6-level messages (i.e. cmsg_level==IPPROTO_IPV6) with at
IPv4-mapped IPv6 connection will trigger EINVAL in at least some cases.

This appears to be a duplicate of bug 99356.  I won't close it as a duplicate
because there's different analysis in both bugs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.