Backporting if_wg to FreeBSD 12
Hello to all! As I know, if_wg support was added into freebsd head. Are there any plans for backporting if_wg support to FreeBSD 12? -- MATPOCKuH ___ 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: uchcom update
Thank You, Andriy! It solved the problem for me too. Also this can be applied without reboot via command: sysctl hw.usb.no_cs_fail=1 вс, 28 февр. 2021 г. в 14:21, Andriy Gapon : > On 28/02/2021 11:03, KOT MATPOCKuH wrote: > > Hello! > > > > I'm using FreeBSD 12.2-STABLE r368656 and got usb-to-rs232 with this > > controller. > > I see /dev/cuaU0 after plugging in adapter, I can attach to serial line > > using cu, but after sending any symbol to device I have device > reconnection: > > uchcom0 on uhub0 > > uchcom0: on usbus0 > > uchcom0: CH340 detected > > uchcom0: at uhub0, port 9, addr 17 (disconnected) > > uchcom0: detached > > uchcom0 on uhub0 > > uchcom0: on usbus0 > > uchcom0: CH340 detected > > I have this in my loader.conf: > > # Ignore result of "clear stall" (clearing halt on endpoints) > # CH340 USB<->RS232 requires this > # and it seems that Linux and Windows do this by default > hw.usb.no_cs_fail=1 > > I recall that without that tuning I had a similar problem. > > > вт, 5 июн. 2018 г. в 15:05, Ian FREISLICH >: > > > >> On 05/22/2018 09:44 AM, Andriy Gapon wrote: > >>> Yesterday I committed some changes to uchcom (so far, only in CURRENT). > >>> Commits are r333997 - r334002. > >>> > >>> If you have a CH340/341 based USB<->RS232 adapter and it works for you, > >> could > >>> you please test that it still does? > >>> If you tried your adapter in the past and it did not work, there is a > >> chance it > >>> might start working now. Could you please test that as well? > >> > >> ugen5.4: at usbus5, cfg=0 md=HOST spd=FULL > >> (12Mbps) pwr=ON (96mA) > >> ugen5.4.0: uchcom0: > >> > >> It's not made it any worse. I'm not using this adapter by choice - it's > >> a USB to Maxim (Dallas) one-wire bus adapter. The manual used to state > >> that these are possibly the worst chips ever. Is that still the > >> prevailing opinion? > > > -- > Andriy Gapon > -- MATPOCKuH ___ 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: uchcom update
Hello! I'm using FreeBSD 12.2-STABLE r368656 and got usb-to-rs232 with this controller. I see /dev/cuaU0 after plugging in adapter, I can attach to serial line using cu, but after sending any symbol to device I have device reconnection: uchcom0 on uhub0 uchcom0: on usbus0 uchcom0: CH340 detected uchcom0: at uhub0, port 9, addr 17 (disconnected) uchcom0: detached uchcom0 on uhub0 uchcom0: on usbus0 uchcom0: CH340 detected вт, 5 июн. 2018 г. в 15:05, Ian FREISLICH : > On 05/22/2018 09:44 AM, Andriy Gapon wrote: > > Yesterday I committed some changes to uchcom (so far, only in CURRENT). > > Commits are r333997 - r334002. > > > > If you have a CH340/341 based USB<->RS232 adapter and it works for you, > could > > you please test that it still does? > > If you tried your adapter in the past and it did not work, there is a > chance it > > might start working now. Could you please test that as well? > > ugen5.4: at usbus5, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON (96mA) > ugen5.4.0: uchcom0: > > It's not made it any worse. I'm not using this adapter by choice - it's > a USB to Maxim (Dallas) one-wire bus adapter. The manual used to state > that these are possibly the worst chips ever. Is that still the > prevailing opinion? > > Ian > > -- > > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- MATPOCKuH ___ 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: route based ipsec
Hello! вс, 5 мая 2019 г. в 13:50, Andrey V. Elsukov : > > 0.The ipsec-tools port currently does not have a maintainer (C) > portmaster > > ... Does this solution really supported? Or I should switch to use > another > > IKE daemon? > I think it is unmaintained in upstream too. > But why it still recommended in FreeBSD handbook? > 1. racoon was 3 times crashed with core dump (2 times on one host, 1 times > > on another host): > > (gdb) bt > > #0 0x0024417f in isakmp_info_recv () > > #1 0x002345f4 in isakmp_main () > > #2 0x002307d0 in isakmp_handler () > > #3 0x0022f10d in session () > > #4 0x0022e62a in main () > > > > 2. racoon generated 2 SA for each traffic direction (from hostA to > hostB). > > IMHO one SA for one each traffic direction should be enough. > > Probably you have something wrong in your configuration. > I'm misunderstand what in my configuration can result core dumps a running daemon... I'm attached a sample racoon.conf. Can You check for possible problems? Also on one host I got a crash in another function: (gdb) bt #0 0x0024717f in privsep_init () #1 0x002375f4 in inscontacted () #2 0x002337d0 in isakmp_plist_set_all () #3 0x0023210d in isakmp_ph2expire () #4 0x0023162a in isakmp_ph1delete () #5 0x0023110b in isakmp_ph2resend () #6 0x0008002aa000 in ?? () #7 0x in ?? () Note, that if_ipsec(4) interfaces has own security policies and you need > to check that racoon doesn't create additional policies. Also, > if_ipsec(4) uses "reqid" parameter to distinguish IPsec SAs between > interfaces. I made a patch to add special parameter for racoon, so it is > possible to use several if_ipsec(4) interfaces. I think it should be in > port. > https://lists.freebsd.org/pipermail/freebsd-net/2018-May/050509.html > This patch already applied to the ports tree. But it's not enough in my case :( > Also you can use strongswan, we use it for some time and have no problems. > Okey. Thanks You! I will try to use strongswan. I'm tried to replace rsasig authentication with psk, but without luck. I'm against got two ipsec sa for each direction -- MATPOCKuH racoon.conf Description: Binary data ___ 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: route based ipsec
Hello! сб, 4 мая 2019 г. в 21:01, Scott Aitken : > > On 5/2/2019 4:16 PM, KOT MATPOCKuH wrote: > > > 0.The ipsec-tools port currently does not have a maintainer (C) > portmaster > > > ... Does this solution really supported? Or I should switch to use > > > another IKE daemon? > > I've just started using IPSEC between a 12.0-RELEASE box, a 11.2-RELEASE-p9 > box and a Cisco IOS router. > What type of peers_identifier are You using? I'm using asn1dn... And today I got a coredump on 3rd host in: #0 0x0024717f in privsep_init () I haven't seen any core dumps or crashes. I run routing between these > devices (using RIPv2 rather than OSPF) - in order to do this you need to > create tunnels between the devices because encrypting routing protocols and > things that use multicast is tricky. I felt that that the handbook example > was lacking - it should have been encrypting the tunnel endpoints and NOT > the > LAN traffic on either side of the tunnel. > I used pointtomultipoint topology and hardcoded peer's IP addresses for OSPF. No multicast => no problems :) > Anyway I built IPENCAP (aka IPinIP) tunnels using gif interfaces and > configured racoon/ipsec-tools to build the SA/SADs using the tunnel > endpoints > and IP protocol 4 (IPENCAP). > I think my next step will be try to use gre tunnels over ipsec with psk authentication. If you want the configs let me know. > No, thanks You! :) -- MATPOCKuH ___ 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"
route based ipsec
Hello! I'm trying to make a full mesh vpn using route based ipsec between four hosts under FreeBSD 12. I'm used racoon from security/ipsec-tools (as it recommended in https://www.freebsd.org/doc/handbook/ipsec.html) Result looks work, but I got some problems: 0.The ipsec-tools port currently does not have a maintainer (C) portmaster ... Does this solution really supported? Or I should switch to use another IKE daemon? 1. racoon was 3 times crashed with core dump (2 times on one host, 1 times on another host): (gdb) bt #0 0x0024417f in isakmp_info_recv () #1 0x002345f4 in isakmp_main () #2 0x002307d0 in isakmp_handler () #3 0x0022f10d in session () #4 0x0022e62a in main () 2. racoon generated 2 SA for each traffic direction (from hostA to hostB). IMHO one SA for one each traffic direction should be enough. 3. ping and TCP taffic works over ipsec tunnels, but, for example, bird can't establish OSPF neighborhood over some (!) ipsec tunnels. I'm tried to watch traffic on ipsec tunnels and got some strange behavior. For example, ping hostA from hostD: > ping -c 2 192.168.31.9 PING 192.168.31.9 (192.168.31.9): 56 data bytes 64 bytes from 192.168.31.9: icmp_seq=0 ttl=64 time=1.334 ms 64 bytes from 192.168.31.9: icmp_seq=1 ttl=64 time=1.280 ms tcpdump on this hostD: # tcpdump -pni ipsec2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ipsec2, link-type NULL (BSD loopback), capture size 262144 bytes 23:08:53.362318 IP 192.168.31.10 > 192.168.31.9: ICMP echo request, id 29396, seq 0, length 64 23:08:53.363604 IP 192.168.31.9 > 192.168.31.10: ICMP echo reply, id 29396, seq 0, length 64 23:08:54.384518 IP 192.168.31.10 > 192.168.31.9: ICMP echo request, id 29396, seq 1, length 64 23:08:54.385731 IP 192.168.31.9 > 192.168.31.10: ICMP echo reply, id 29396, seq On second side: # tcpdump -pni ipsec2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ipsec2, link-type NULL (BSD loopback), capture size 262144 bytes 23:08:53.362196 IP 192.168.31.9 > 192.168.31.10: ICMP echo reply, id 29396, seq 0, length 64 23:08:54.384441 IP 192.168.31.9 > 192.168.31.10: ICMP echo reply, id 29396, seq 1, length 64 I think it's may be result of two SA's for each direction, and some traffic can be passed to kernel using second SA, but can't be associated with proper ipsecX interface. What You can recommend to solve this problems? PS. Not using IPSec on FreeBSD i as known, but wrong answer :) -- MATPOCKuH ___ 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"
Silent data corruption on em(4) interfaces
Hello! I got silent data corruption when transferring data via em(4) interface on 10.2-STABLE r286912. 1. I got broken large file transferred via ftp (MD5 checksum mismatched); 2. I got disconnects when transferring large data via ssh with messages: Corrupted MAC on input. Disconnecting: Packet corrupt Problem occurs only after few hours of uptime. Immediately after reboot I transferred same file via ftp without any errors. I tried to use: - em0 and em2 interfaces in link aggregation - em1 as clean interface But I got same problem in both cases. Also one time when transferring file I got this messages: em0: Interface stopped DISTRIBUTING, possible flapping em0: Watchdog timeout -- resetting em2: Interface stopped DISTRIBUTING, possible flapping em2: Watchdog timeout -- resetting netstat -in does not see any problems: NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll em01500 Link#1 00:14:4f:01:3f:7a 6689452 0 0 146720 0 0 em11500 Link#2 00:14:4f:01:3f:7b 5732168 0 0 2865912 0 0 em21500 Link#3 00:14:4f:01:3f:7c 501817 0 0 3392333 0 0 Network adapters is build in to the Sun Fire X4100 mother board: em0@pci0:1:1:0: class=0x02 card=0x10118086 chip=0x10108086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82546EB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet TCP_OFFLOAD disabled in kernel's config. Any ideas? -- MATPOCKuH ___ 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: Trouble with drive size detection - 31MB visible size on 1TB drive.
2009/12/12 Alexander Motin m...@freebsd.org: To unlock drive permanently SET MAX ADDRESS ATA command should be used (probably the same as Linux uses) with Volatile bit set, to make it not restore on power cycle. I don't know how to send this command with legacy ata(4), you need some external tool. Who knows this some external tool? :) As I know hdparm is not ported to *BSD. With new CAM-based ATA probably it can be send via `camcontrol cmd ...`. On this machine I'm using FreeBSD 7.x and have no ahci(4) support :( I solved the problem by running hdparm -N p1953525168 sdf from linux livecd, but this is not the fbsd way... -- MATPOCKuH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Trouble with drive size detection - 31MB visible size on 1TB drive.
Hi all! I have a problem with drive size detection. After any power cycle my HDD ST31000340NS detected by FreeBSD 7.2 as 31Mb drive. For example: Dec 9 20:33:12 green kernel: ad14: 31MB Seagate ST31000340NS SN06 at ata7-master SATA300 Dec 9 20:33:12 green kernel: GEOM: ad14: corrupt or invalid GPT detected. Dec 9 20:33:12 green kernel: GEOM: ad14: GPT rejected -- may not be recoverable. # atacontrol cap ad14 [skipped] cylinders 64 heads 16 sectors/track 63 lba supported 65134 sectors lba48 supported 65134 sectors # smartctl -a /dev/ad14 [skipped] User Capacity:33,348,608 bytes I'm tried to reinit/detach/attach drive via atacontrol, but have no result. But after reboot the system in linux and then back to FreeBSD, I have correct disk geometry: ad14: 953869MB Seagate ST31000340NS SN06 at ata7-master SATA300 In linux's dmesg.out I found this messages: [8.984053] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [9.120175] ata6.00: HPA unlocked: 65134 - 1953525168, native 1953525168 [9.120180] ata6.00: ATA-8: ST31000340NS, SN06, max UDMA/133 [9.120183] ata6.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 31/32) [9.179789] ata6.00: configured for UDMA/133 [9.179851] scsi 5:0:0:0: Direct-Access ATA ST31000340NS SN06 PQ: 0 ANSI: 5 [9.179960] sd 5:0:0:0: Attached scsi generic sg5 type 0 [9.179992] sd 5:0:0:0: [sdf] 1953525168 512-byte logical blocks: (1.00 TB/93 1 GiB) [9.180041] sd 5:0:0:0: [sdf] Write Protect is off [9.180044] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 [9.180066] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA What is HPA? Why drive locks HPA? And... Can I unlock HPA from FreeBSD? -- MATPOCKuH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
