[Bug 261711] net/wireguard-kmod: Cannot send data over VXLAN / vtnet
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261711 Alfa changed: What|Removed |Added CC||burak...@outlook.com --- Comment #8 from Alfa --- Hi, I had same issue, vxlan traffic not passed thruogh wireguard kmod on FreeBSD 12.2 and 13.0 STABLE I have found that the FreeBSD's wireguard kernel implementation is the problem itself. I removed Kernel implementation and installed go user space implementation it worked on FreeBSD 12.2 STABLE bot tried for 13.0. Now i tried vxlan over wg on FreebSD 14 CURRENT 20220923 AMD64 build this time both wireguard kmod & go implementation didn't work. Configuration: wireguard freebsd 14 machine wg0 interface ip :192.168.199.1/24 wireguard linux machine wg0 iface ip : 192.168.199.250/24 wireguard peers connected each other successfully and available to ping one by one but when i added vxlan like this : ifconfig vxlan700 create vxlanid 700 vxlanlocal 192.168.199.1 vxlanremote 192.168.199.250 ifconfig vxlan700 192.168.88.1/24 and i configured linux machine to meet this vxlan700 there was no traffic enters vxlan700 on bsd side The traffic doesn't pass from wireguard to vxlan when i listened wg interface "udp port vxlan unreachable" error occurs here is FreeBSD side logs: peer: >secret< endpoint: >secret<:10626 allowed ips: 192.168.199.250/32 latest handshake: Now transfer: 145.32 KiB received, 181.92 KiB sent persistent keepalive: every 25 seconds root@freebsd14:~ # tcpdump -i vxlan700 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vxlan700, link-type EN10MB (Ethernet), capture size 262144 bytes >>> there is no traffic root@freebsd14:~ # tcpdump -i wg0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wg0, link-type NULL (BSD loopback), capture size 262144 bytes 17:21:11.801802 IP 192.168.199.250.47705 > 192.168.199.1.vxlan: VXLAN, flags [I] (0x08), vni 700 ARP, Request who-has 192.168.88.1 tell 192.168.88.2, length 46 17:21:11.801832 IP 192.168.199.1 > 192.168.199.250: ICMP 192.168.199.1 udp port vxlan unreachable, length 104 17:21:12.825053 IP 192.168.199.250.47705 > 192.168.199.1.vxlan: VXLAN, flags [I] (0x08), vni 700 ARP, Request who-has 192.168.88.1 tell 192.168.88.2, length 46 There was same problem for freebsd 12.2 and 13 stable versions wg kmod implementations i have created a topic shown below . I was solved installing go implementation but this not worked for freebsd 14 . https://forums.freebsd.org/threads/vxlan-works-only-on-freebsd-11-2-but-not-works-on-12-2-and-13-stable.81833/#post-566850 i used latest freebsd 14 current image https://download.freebsd.org/snapshots/amd64/amd64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-amd64-20220923-00d8a28f19b-258155-memstick.img.xz -- You are receiving this mail because: You are on the CC list for the bug.
Re: getaddrinfo error for existing host without requested address family
Mike, Just commenting to clarify what seems to be unclear about some RFC's. Rod > I recently noticed the following behavior: > > % ping6 redrock > ping6: Name does not resolve > % host redrock > redrock.karels.net has address 10.0.2.2 > redrock.karels.net mail is handled by 10 mail.karels.net. > % ping6 nonexistenthost > ping6: Name does not resolve > > The first error message is misleading, because the name *does* resolve, > but has no record, and it is the same error message as for a name > that truly does not exist. The problem comes from the set of error > codes that getaddrinfo() returns in these two cases. The problem did > not exist with gethostbyname(), which has separate error codes for the > two (although gethostbyname did not have provision for IPv6, it handled > cases like domain names and mail domains without IPv4 addresses). > > getaddrinfo() uses a richer set of error codes than gethostbyname(), but > still misses this case. However, looking at , I see > > #if 0 > /* Obsoleted on RFC 2553bis-02 */ > #define EAI_ADDRFAMILY 1 /* address family for hostname not > supported */ > #endif > ... > #if 0 > /* Obsoleted on RFC 2553bis-02 */ > #define EAI_NODATA 7 /* no address associated with hostname > */ > #endif > > I don't know why these two were omitted from the update to RFC 2553, but > the first seems to me to be the correct error for an existing name without > an address for the requested address family. Also, that is the error > message produced by Linux (Ubuntu 22.04.1). > > NetBSD and OpenBSD produce the second of these two errors for a host > without the requested address. But they also produce the same error > when a name does not exist. > > RFC 2553bis-02 has timed out, and is replaced by RFC 3493, which is also > missing EAI_ADDRFAMILY. These are informational RFCs, not specifying an > Internet standard. RFC2553bis-02 is an old version of a draft that went to -09, this draft existed from May 2000 to March 2003, when it was changed to RFC3493 and published. When looking at RFC versions and history please use the IETF datatracker to help one find history and latest versions: https://datatracker.ietf.org/doc/rfc3493/ https://datatracker.ietf.org/doc/rfc2553/ Says obsolete by rfc3493 https://datatracker.ietf.org/doc/rfc2553bis/ redirects to rfc3493 Sadly goggle often sends one to a html version of a rfc/draft when one searches there for it. The html version does have a link in the banner to the proper datatracker page though. Use of and reference to IETF drafts in comments of the FreeBSD code and implementing them is full of the perils that there is rarely anyone tracking the work and keeping things up to date as the draft evolves and we end up with stale comments, and even stale implementations. rfc3493 still does not define EAI_ADDRFAMILY, one would have to search the mailing list archives to find what the rational for its removal was. Sadly that this is not summarized in section 9 of rfc3493, it should of been. > > I propose re-enabling EAI_ADDRFAMILY and using it for the situation > where a name exists but does not have an address in the requested family. > This would make the error in the example less misleading, and would behave > the same as Linux in this regard. The change to netdb.h is trivial, but > getaddrinfo() needs a little more work because it uses the NS_* errors > from internally and then translates. But it will benefit > from greater accuracy in other cases as well (e.g. "out of memory" > rather than "Name does not resolve"). > > Comments? I have a change in progress, but wanted to float the idea > before I finish it and put it into review. > > Mike > > -- Rod Grimes rgri...@freebsd.org
[Bug 252165] usb network and mii bus media status race condition
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252165
--- Comment #24 from Ali Abdallah ---
Created attachment 236901
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=236901&action=edit
dtrace ure usb traces
I got another machine on which I didn't apply the workaround, running 13.1,
with a USB Lan adapter that uses if_ure, I used the following dtrace probes.
dtrace -n
'fbt:miibus:mii_pollstat:*,fbt:uether:ue_tick_task:*,fbt:if_ure:ure_tick:*,fbt:if_ure:ure_ifmedia_sts:*,fbt:miibus:mii_tick:*,fbt:miibus:miibus_linkchg:*,
fbt:usb:* { printf("%p", curthread); }'
You can see from the attached debug log (numbered lines)
1 48573ure_ifmedia_sts:entry fe00dc75c720
1 48475 mii_pollstat:entry fe00dc75c720
But before exit entry of re_ifmedia_sts:return of thread fe00dc75c720, you
can see:
1052 0 48573ure_ifmedia_sts:entry fe00e00271e0
1053 2 27791usb_command_wrapper:entry fe0082a17ac0
1054 2 27738 usbd_callback_wrapper:entry fe0082a17ac0
1055 0 48475 mii_pollstat:entry fe00e00271e0
And that exactly when the link up/down happened.
So thread fe00e00271e0 managed to go ahead and call mii_pollstat, acquiring
the sc mutex, despite that thread fe00dc75c720 didn't release it yet, you
can see that the return from "polling the media state" on thread
fe00dc75c720 comes way after the ure_ifmedia_sts:entry of thread
fe00e00271e0
1517 3 48476 mii_pollstat:return fe00dc75c720
1518 3 48574 ure_ifmedia_sts:return fe00dc75c720
__snip if_ure__
ure_ifmedia_sts
{
...
URE_LOCK(sc);
mii_pollstat(mii);
ifmr->ifm_active = mii->mii_media_active;
ifmr->ifm_status = mii->mii_media_status;
URE_UNLOCK(sc);
}
__snip__
The mutex locked/released by URE_LOCK, is the same mutex used in if_ure, USB
xfer and USB transfer, so I guess something is not playing well in the
release/acquire sequence...
Will try if time permits to dig more into the USB transfer/process code, but I
have to say that I'm extremely surprised that this bug didn't attract much
attention, it actually renders any USB Ethernet device unusable on FreeBSD...
--
You are receiving this mail because:
You are the assignee for the bug.
