[Lee, Jae Ho] Re: Korean keyboard support
( I redirect following post originally posted at freebsd-drivers to -current. ) Lee, Jae Ho wrote this message on Fri, Jul 24, 2015 at 09:33 +0900: This is probably better suited for -current, so I have redirected the question there... Dear John-Mark, thank you so much for your concern! I think I should send the original message to current. It looks like FreeBSD may not have a keymap for Korean keyboards. You can check by running kbdmap from the console... If you look at /usr/share/syscons/keymaps (older syscons), or /usr/share/vt/keymaps (current vt, which supports UTF-8 fonts and more), you can define your own keyboard map... It could be that I'm missing what you're trying to do... Hope this helps! Well as far as the keymap, there has never been one for Korean keymap. I *think* the reason why for that is Korean keyboard shares exactly same keymap with us.kbd map and only uses xim applications such as korean/ko-uim to translate each alphabet input to Korean charactors. But only difference with Korean and us.kbd(US keymap) is those two toggle keys I mentioned in prior (original) message: Hangul(0xF2), Hanja(0xF1). The problem is, since those two keys have unique (but standard in Korean regulations or ISO ) key scancodes, default FreeBSD system/kernel may not detect those. I checked that by using misc/kbdscan program to see if those keys are detected by default system but did not print any keycodes. Also those keys could not even wake the system up when system screen is in powersave mode. So basically I think it's about driver problem rather about keymaps, and that is why I looked up sys/dev/atkbdc/atkbd.c. In short, those two unique keys in Korean keyborad are needed to be recognized by FreeBSD kernel first before we reorganize the keymaps file, to use Korean keyboard in FreeBSD. More detailed informations about scancodes , kernel patch info from linux and other features of those two keys are mentioned in original (prior) post, if anybody needs. Thank you very much again for your concern, and I hope you have a nice day. :~) (Below are original post at -drivers) = Hello. I am Lee, Jaeho from South Korea. ( not North lol ) I am trying to ask you about the Korean keyboard support in FreeBSD. The Korean keyborad is featured as below. The Korean keyboard has two keys, the Korean/Chinese and the Korean/English toggles, that generate scancodes f1 and f2 (respectively) when pressed, and nothing when released. They do not repeat. The keycaps are hancha and han/yong (written in Hangul). Hancha (hanja) means Chinese character, and Han/Yong is short for Hangul/Yongcha (Korean/English). They are located left and right of the space bar. ( From : http://www.win.tue.nl/~aeb/linux/kbd/scancodes-9.html ) Basically, on the Korean 103/106 (Korean Government Standard), there are two additional keys as Hangul(scancode of 0xf2) and Hanja(scancode of 0xf1) to the US 101/104 keyborad. and they don't have release signals if they are ps/2 type. USB keborad does have release signals. I tried look in src/sys/dev/atkbdc/atkbd.c and tried to make a patch on my own which I inspired by the patch from the linux kernel : https://bugzilla.kernel.org/show_bug.cgi?id=6642 , but since I am not well experienced yet in freebsd programing so I eventually came to ask for your help. I am ready to give you answers and informations to any kind of questions about Korean keybord specifications or other things related that you might want to know. :) As you can guess, the keyboard support is quite evident and will be really important and helpful to many Korean FreeBSD users. Thank you in advance. :) = ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Segmentation fault running ntpd
On Sun, Jul 19, 2015 at 11:36:00AM -0700, David Wolfskill wrote: On Sun, Jul 19, 2015 at 10:24:11AM -0600, Ian Lepore wrote: ... Was there anything (at all) in /var/log/messages about ntpd? Even the routine messages (such as what interfaces it binds to) might give a bit of a clue about how far it got in its init before it died. Sorry; there might have been something yesterday... If I do get another recurrence, I'll try to gather a bit more information. OK; got another one. This time, I have the complete /var/log/messages for a verbose boot, from that boot to just a bit after the ntpd crash; it's in http://www.catwhisker.org/~david/FreeBSD/head; as of the moment, that contains: [PARENTDIR] Parent Directory - [ ] CANARY 2015-03-22 10:03 15K [ ] CANARY.gz 2015-03-22 10:03 6.3K [ ] ntpd.core 2015-07-24 05:31 13M [ ] ntpd.core.gz2015-07-24 05:31 124K [TXT] ntpd_crash_msgs.txt 2015-07-24 05:40 138K [ ] ntpd_crash_msgs.txt.gz 2015-07-24 05:40 19K This was running: FreeBSD g1-245.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #133 r285836M/285836:1100077: Fri Jul 24 05:24:41 PDT 2015 r...@g1-245.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 Trying gdb /usr/obj/usr/src/usr.sbin/ntp/ntpd/ntpd ntpd.core still doesn't help much: This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Core was generated by `ntpd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. ... Loaded symbols for /libexec/ld-elf.so.1 #0 0x0008011cd6a0 in sbrk () from /lib/libc.so.7 [New Thread 801c07400 (LWP 100133/unknown)] [New Thread 801c06400 (LWP 100132/unknown)] (gdb) bt #0 0x0008011cd6a0 in sbrk () from /lib/libc.so.7 #1 0x0008ccbd4f34 in ?? () #2 0x0005 in ?? () #3 0x000801800448 in ?? () #4 0x0008011ca888 in sbrk () from /lib/libc.so.7 #5 0x0008018000c8 in ?? () #6 0x0008018000c0 in ?? () #7 0x0208 in ?? () #8 0x000801c32fb0 in ?? () #9 0x0001 in ?? () #10 0x000801cc20c8 in ?? () #11 0x0030 in ?? () #12 0x000801cc20c8 in ?? () #13 0x7fffe480 in ?? () #14 0x0008011cd240 in sbrk () from /lib/libc.so.7 #15 0x0280 in ?? () #16 0x0008014bbc70 in malloc_message () from /lib/libc.so.7 #17 0x0008018000c0 in ?? () #18 0x000801800448 in ?? () #19 0x0032 in ?? () #20 0x000801800458 in ?? () #21 0x0008014bbc68 in malloc_message () from /lib/libc.so.7 #22 0x000801cc2000 in ?? () #23 0x0008014bba60 in malloc_message () from /lib/libc.so.7 #24 0x000801cc20d8 in ?? () #25 0x00a0 in ?? () #26 0x0208 in ?? () #27 0x7fffe4d0 in ?? () #28 0x0008011bdd7a in _malloc_thread_cleanup () from /lib/libc.so.7 Previous frame inner to this frame (corrupt stack?) (gdb) I am presently suspecting that it's a bit dependent on ... well, timing. I have my ~/.xsession set up so that once I've entered the passphrase(s) for my SSH private key(s), scripts start running to establish connections to other machines -- e.g., open an xterm locally, ssh over to my mailhub and (re-)establish a tmux session on that machine where I run mutt to read write email (such as this message). While that almost always Just Works in stable/10, it's rather ... spottier ... in head -- I'd say it's about a 50% probability that it will work, vs. the ssh connection attempt hanging, and eventually timing out. But if I've waited (say) 30 seconds or so, I can establish such a connection easily. Granted, I am using wireless (802.11), but I get a sense that things are claimed to be ready to go a bit prematurely -- at least sometimes. Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgptpn4GcpGjF.pgp Description: PGP signature
Re: IPSEC stop works after r285336
On 23.07.2015 10:38, Alexandr Krivulya wrote: I have IPSEC tunnel inside l2tp tunnel via mpd. After r285536 I see only outgoing esp packets on ng interface: What FreeBSD version do you use? Please check https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192774 and your security policies configuration. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
RFC: ichwd TCO v3 support
Hello, Please find a review for a patch submitted by Cas-well for ichwd TCO v3 support (Bay Trail, Rangeley,…) https://reviews.freebsd.org/D3186 Feedback welcome Fabien ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: IPSEC stop works after r285336
Alexandr Krivulya wrote this message on Thu, Jul 23, 2015 at 10:38 +0300: I have IPSEC tunnel inside l2tp tunnel via mpd. After r285536 I see only outgoing esp packets on ng interface: This change is -stable, not -current, but the change referenced below is -current... Which one are you running? Also, the only ipsec related change after r285535 is r285770, though that probably won't effect it... Could you possibly narrow the change that broke things? root@thinkpad:/usr/src # tcpdump -i ng0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ng0, link-type NULL (BSD loopback), capture size 262144 bytes 10:35:27.331886 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a5), length 140 10:35:28.371707 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a6), length 140 10:35:29.443536 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a7), length 140 10:35:30.457370 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a8), length 140 10:35:31.475606 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a9), length 140 10:35:31.622315 IP 10.10.10.1.isakmp 10.10.10.2.isakmp: isakmp: phase 2/others ? inf[E] 10:35:31.622544 IP 10.10.10.2.isakmp 10.10.10.1.isakmp: isakmp: phase 2/others ? inf[E] 10:35:31.622658 IP 10.10.10.2.isakmp 10.10.10.1.isakmp: isakmp: phase 2/others ? inf[E] 10:35:31.623933 IP 10.10.10.1.isakmp 10.10.10.2.isakmp: isakmp: phase 2/others ? inf[E] 10:35:32.492349 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9aa), length 140 10:35:33.509346 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9ab), length 140 10:35:34.527187 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9ac), length 140 10:35:35.539600 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9ad), length 140 With r285535 all works fine. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD_HEAD_amd64_gcc4.9 - Build #235 - Failure
FreeBSD_HEAD_amd64_gcc4.9 - Build #235 - Failure:
Build information:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/235/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/235/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/235/console
Change summaries:
285845 by emaste:
readelf: avoid division by zero on section entry size
ELF Tool Chain tickets #439, #444, #445, #467
Reported by:Alexander Cherepanov chere...@mccme.ru (#467)
Reported by:antiAgainst (others)
Reviewed by:brooks
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2338
285844 by emaste:
ar: add -U (unique) option to disable -D (deterministic) mode
This is required in order for us to support deterministic mode by
default. If multiple -D or -U options are specified on the command
line, the final one takes precedence. GNU ar also uses -U for this.
An equivalent change will be applied to ELF Tool Chain's version of ar.
PR: 196929
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3175
285843 by marius:
- Since r253161, uart_intr() abuses FILTER_SCHEDULE_THREAD for signaling
uart_bus_attach() during its test that 20 iterations weren't sufficient
for clearing all pending interrupts, assuming this means that hardware
is broken and doesn't deassert interrupts. However, under pressure, 20
iterations also can be insufficient for clearing all pending interrupts,
leading to a panic as intr_event_handle() tries to schedule an interrupt
handler not registered. Solve this by introducing a flag that is set in
test mode and otherwise restores pre-r253161 behavior of uart_intr(). The
approach of additionally registering uart_intr() as handler as suggested
in PR 194979 is not taken as that in turn would abuse special pccard and
pccbb handling code of intr_event_handle(). [1]
- Const'ify uart_driver_name.
- Fix some minor style bugs.
PR: 194979 [1]
Reviewed by:marcel (earlier version)
MFC after: 3 days
285842 by emaste:
truss: follow pdfork()ed descendents with -f
PR: 201276
Reported by:David Drysdale
Reviewed by:oshogbo
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2976
285841 by emaste:
Add RISC-V ELF machine type definition
EM_RISCV is now officially registered as e_machine 243.
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
285840 by marius:
- In mpt_send_handshake_cmd(), use bus_space_write_stream_4(9) for writing
raw data to the doorbell offset in order to clarify the intent and for
avoiding unnecessarily converting the endianess back and forth.
Unfortunately, the same can't be done in mpt_recv_handshake_reply() as
16-bit data needs to be read using 32-bit bus accessors.
- In mpt_recv_handshake_reply(), get rid of a redundant variable.
MFC after: 1 fortnight
285839 by marius:
o Revert the other functional half of r239864, i. e. the merge of r134227
from x86 to use smp_ipi_mtx spin lock not only for smp_rendezvous_cpus()
but also for the MD cache invalidation, TLB demapping and remote register
reading IPIs due to the following reasons:
- The cross-IPI SMP deadlock x86 otherwise is subject to can't happen on
sparc64. That's because on sparc64, spin locks don't disable interrupts
completely but only raise the processor interrupt level to PIL_TICK. This
means that IPIs still get delivered and direct dispatch IPIs such as the
cache invalidation etc. IPIs in question are still executed.
- In smp_rendezvous_cpus(), smp_ipi_mtx is held not only while sending an
IPI_RENDEZVOUS, but until all CPUs have processed smp_rendezvous_action().
Consequently, smp_ipi_mtx may be locked for an extended amount of time as
queued IPIs (as opposed to the direct ones) such as IPI_RENDEZVOUS are
scheduled via a soft interrupt. Moreover, given that this soft interrupt
is only delivered at PIL_RENDEZVOUS, processing of smp_rendezvous_action()
on a target may be interrupted by f. e. a tick interrupt at PIL_TICK, in
turn leading to the target in question trying to send an IPI by itself
while IPI_RENDEZVOUS isn't fully handled, yet, and, thus, resulting in a
deadlock.
o As mentioned in the commit message of r245850, on least some sun4u platforms
concurrent sending of IPIs by different CPUs is fatal. Therefore, hold the
reintroduced MD ipi_mtx also while delivering cross-traps via MI helpers,
i. e. ipi_{all_but_self,cpu,selected}().
o Akin to x86, let the last CPU to process cpu_mp_bootstrap() set smp_started
instead of the BSP in cpu_mp_unleash(). This ensures that all APs actually
are started, when smp_started is no longer 0.
o In all MD and MI IPI helpers, check for smp_started == 1 rather than for
smp_cpus 1 or
FreeBSD_HEAD_amd64_gcc4.9 - Build #236 - Fixed
FreeBSD_HEAD_amd64_gcc4.9 - Build #236 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/236/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/236/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/236/console Change summaries: 285847 by trasz: Add missing SIGUSR1 description. MFC after: 2 weeks Sponsored by: The FreeBSD Foundation 285846 by trasz: Add missing capitalization. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: IPSEC stop works after r285336
25.07.2015 00:38, John-Mark Gurney пишет: Alexandr Krivulya wrote this message on Thu, Jul 23, 2015 at 10:38 +0300: I have IPSEC tunnel inside l2tp tunnel via mpd. After r285536 I see only outgoing esp packets on ng interface: This change is -stable, not -current, but the change referenced below is -current... Which one are you running? Also, the only ipsec related change after r285535 is r285770, though that probably won't effect it... Could you possibly narrow the change that broke things? root@thinkpad:/usr/src # tcpdump -i ng0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ng0, link-type NULL (BSD loopback), capture size 262144 bytes 10:35:27.331886 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a5), length 140 10:35:28.371707 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a6), length 140 10:35:29.443536 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a7), length 140 10:35:30.457370 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a8), length 140 10:35:31.475606 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a9), length 140 10:35:31.622315 IP 10.10.10.1.isakmp 10.10.10.2.isakmp: isakmp: phase 2/others ? inf[E] 10:35:31.622544 IP 10.10.10.2.isakmp 10.10.10.1.isakmp: isakmp: phase 2/others ? inf[E] 10:35:31.622658 IP 10.10.10.2.isakmp 10.10.10.1.isakmp: isakmp: phase 2/others ? inf[E] 10:35:31.623933 IP 10.10.10.1.isakmp 10.10.10.2.isakmp: isakmp: phase 2/others ? inf[E] 10:35:32.492349 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9aa), length 140 10:35:33.509346 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9ab), length 140 10:35:34.527187 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9ac), length 140 10:35:35.539600 IP 10.10.10.2 10.10.10.1: ESP(spi=0x03081e58,seq=0x9ad), length 140 With r285535 all works fine. Right commit is in subject - r285336. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD_HEAD-tests - Build #1216 - Unstable
On Sat, Jul 25, 2015 at 02:24:00AM +, jenkins-ad...@freebsd.org wrote: FreeBSD_HEAD-tests - Build #1216 - Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1216/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1216/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1216/console Change summaries: No changes Can we please stop this noise, masking *real* problems? Glen pgpSDbb0spxu8.pgp Description: PGP signature
FreeBSD_HEAD-tests - Build #1216 - Unstable
FreeBSD_HEAD-tests - Build #1216 - Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1216/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1216/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1216/console Change summaries: No changes The end of the build log: [...truncated 4410 lines...] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_1x1_512_vhd - passed [2.437s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_1x1_512_vhdf - passed [0.658s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_1x1_512_vmdk - passed [1.501s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_4096_qcow - passed [1.634s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_4096_qcow2 - passed [2.282s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_4096_raw - passed [2.373s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_4096_vhd - passed [2.611s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_4096_vhdf - passed [4.530s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_4096_vmdk - passed [3.085s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_512_qcow - passed [1.639s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_512_qcow2 - passed [1.868s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_512_raw - passed [1.093s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_512_vhd - passed [2.055s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_512_vhdf - passed [2.388s] [192.168.10.2] out: usr.bin/mkimg/mkimg:gpt_63x255_512_vmdk - passed [2.389s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_4096_qcow - passed [0.946s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_4096_qcow2 - passed [2.123s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_4096_raw - passed [3.432s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_4096_vhd - passed [3.910s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_4096_vhdf - passed [2.163s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_4096_vmdk - passed [3.114s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_512_qcow - passed [3.895s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_512_qcow2 - passed [4.333s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_512_raw - passed [1.417s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_512_vhd - passed [1.957s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_512_vhdf - passed [3.756s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_1x1_512_vmdk - passed [2.323s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_4096_qcow - passed [2.283s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_4096_qcow2 - passed [2.962s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_4096_raw - passed [2.474s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_4096_vhd - passed [2.567s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_4096_vhdf - passed [4.558s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_4096_vmdk - passed [4.741s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_512_qcow - passed [1.819s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_512_qcow2 - passed [1.367s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_512_raw - passed [1.487s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_512_vhd - passed [4.614s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_512_vhdf - passed [3.406s] [192.168.10.2] out: usr.bin/mkimg/mkimg:mbr_63x255_512_vmdk - passed [1.704s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_4096_qcow - passed [2.777s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_4096_qcow2 - passed [1.758s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_4096_raw - passed [1.932s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_4096_vhd - passed [2.222s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_4096_vhdf - passed [4.191s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_4096_vmdk - passed [4.733s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_512_qcow - passed [2.370s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_512_qcow2 - passed [1.243s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_512_raw - passed [4.549s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_512_vhd - passed [4.587s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_512_vhdf - passed [3.280s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_1x1_512_vmdk - passed [4.690s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_63x255_4096_qcow - passed [4.935s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_63x255_4096_qcow2 - passed [4.779s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_63x255_4096_raw - passed [2.188s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_63x255_4096_vhd - passed [3.155s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_63x255_4096_vhdf - passed [2.360s] [192.168.10.2] out: usr.bin/mkimg/mkimg:pc98_63x255_4096_vmdk - passed [3.181s] [192.168.10.2] out:
Re: IPSEC stop works after r285336
24.07.2015 13:19, Andrey V. Elsukov пишет: On 23.07.2015 10:38, Alexandr Krivulya wrote: I have IPSEC tunnel inside l2tp tunnel via mpd. After r285536 I see only outgoing esp packets on ng interface: What FreeBSD version do you use? Please check https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192774 and your security policies configuration. I think it is not my situation. I'm using latest CURRENT r285833 with rules: root@thinkpad:/usr/src # setkey -DP 0.0.0.0/0[any] 10.10.10.2[any] any in ipsec esp/tunnel/10.10.10.1-10.10.10.2/require spid=3 seq=1 pid=14609 refcnt=1 10.10.10.2[any] 0.0.0.0/0[any] any out ipsec esp/tunnel/10.10.10.2-10.10.10.1/require spid=4 seq=0 pid=14609 refcnt=1 In that bug L2TP use IPSEC in transport mode, but in my scenario IPSEC in tunnel mode inside L2TP. And it works fine prior to r285536. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: IPSEC stop works after r285336
On 24.07.2015 15:10, Alexandr Krivulya wrote: In that bug L2TP use IPSEC in transport mode, but in my scenario IPSEC in tunnel mode inside L2TP. And it works fine prior to r285536. But r285536 didn't touch head's source. This is commit into stable/10. So, it can't break something in 11.0-CURRENT. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPSEC stop works after r285336
24.07.2015 15:13, Andrey V. Elsukov пишет: On 24.07.2015 15:10, Alexandr Krivulya wrote: In that bug L2TP use IPSEC in transport mode, but in my scenario IPSEC in tunnel mode inside L2TP. And it works fine prior to r285536. But r285536 didn't touch head's source. This is commit into stable/10. So, it can't break something in 11.0-CURRENT. I mean this commit: https://svnweb.freebsd.org/base?view=revisionrevision=285336 Sorry for my mistake ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
