Thank you very much for you reply Markus, I think I saw that page once on the beginning of my research, but I tought that it must have been fixed by today, since it is almost 5 years old. I am very suprised by the fact that it hasn't been fixed in all this years. You are right, this would really be a killer app. I tought it was, since there is no way to know about this bug until you implement the whole redundant system. This problem should be clearly stated in the man page, it would save me a week. It looks like some trivial bug, since it is clear from the logs that master sends the sad's, but slave is not able to install them: sasyncd[26685]: pfkey_queue_message: pfkey ADD len 504 seq 2 sasyncd[26685]: pfkey: msg ADD write() failed on socket 5: Invalid argument
but later when renegotiation occurs, it installs them succesfully: sasyncd[26685]: pfkey_queue_message: pfkey ADD len 416 seq 149 sasyncd[26685]: pfkey_queue_message: pfkey ADD len 416 seq 150 I wonder what could be different in the first try? Do you still use sasyncd? Have you found any workaround for this? I have advskew 10 on master and 20 on slave. If I want to reboot the master, I demote its carp group and while it reboots, I do: for i in `ls /etc/ | grep carp | cut -d . -f 2`; do ifconfig $i advskew 1; done on the slave. That way, master doesnt take over when it comes back. Maybe it could be done with turning off the preemtion, but haven't tried that yet. Anyhow, after that, I have to wait for all tunnels to renegotiate so I can demote the slave and make the master - master, again. Since you reported problem 5 years ago, are we the only ones who use sasyncd? :) Thanks again -----Original Message----- From: Markus Wernig [mailto:liste...@wernig.net] Sent: Tuesday, January 12, 2010 9:24 PM To: M ihajlo Manojlov Cc: misc@openbsd.org Subject: Re: sasyncd syncs only newly created sad's Hi Mihajlo Yes, this feature (re-sychronization after master failure) has been missing from the day sasyncd came out (http://archives.neohapsis.com/archives/openbsd/2005-09/0818.html). When I gave that speech in Switzerland (the one you found the PDF of), I was confident that it would be implemented within a couple of months or so ... the whole thing being a sponsored development, I figured that the sponsor would want this program to be usable. But, alas, it wasn't. Pity, really. With a little more time at my hands and a little more wit in my brains I would love to pick this up. It would be SUCH a killer application. Hakan Olsson, the original developper, did once say he would look into it, butI haven't heard of him since. krgds & sorrynohelphere /markus Mihajlo Manojlov wrote: > Hi again, > > there is no feedback.. could someone who runs sasyncd check this for me? > Please, just restart sasyncd on slave(or master), and see if it syncs the > SAD's? > > This behaviour renders my redundant routers - non redundant. If I reboot > master, when it comes back and become master again, all VPN tunnels are down > because no SAD's are synced. > > Thank you very much. > > -----Original Message----- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of > Mihajlo Manojlov > Sent: Wednesday, January 06, 2010 11:10 PM > To: misc@openbsd.org > Subject: sasyncd syncs only newly created sad's > > Hi to all, > > I have two carped boxes and I want to use sasyncd for vpn redundancy, but > only > newly created sad's get synced. For example, I reboot the slave box, and when > it comes up again, sasyncd only sets flows, not the sad's. Maybe this is > normal behaviour? > > log from master: > Jan 6 21:59:23 openbsd1 sasyncd[25895]: net: peer "10.23.6.2" connected > Jan 6 21:59:23 openbsd1 sasyncd[25895]: net_ctl: peer "10.23.6.2" state > change to SLAVE > Jan 6 21:59:25 openbsd1 sasyncd[25895]: monitor_get_pfkey_snap: got 2016 > bytes SADB, 1392 bytes SPD > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_send_flush: sending FLUSH to > peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SADB data > 020a00023f00000000000000000000000200010088f180d7100103030400000004000200 > 00000000000000000000000015f7444b0000000000000000000000000400040000000000 > 000000000000000038040000000000000000000000000000040003000000000000000000 > 00000000b004000000000000000000000000000003000500000000001002000059d44c6d > 000000000000000003000600000000001002000059d45bb2000000000000000005000a00 > 01000000000000000000000038392e3231322e37362e3130392f33320000000000000000 > 05000b0001000000000000000000000038392e3231322e39312e3137382f333200000000 > 0000000004000800a00000009884229af8684722ecf09bfe79c0d8eef96b3cfb00000000 > 04000900c0000000e73eb8f1c43d90bdfaf40fb3abfe879d28e74cf8e870dd0b01001400 > 0101000001001300000000000300150000000000100200000a0000000000000000000000 > 030011000000000010020000ffffff000000000000000000030016000000000010020000 > 0a0708000000000000000000030012000000000010020000ffffff000000000000000000 > 02002100080000007465737476706e000000000000000000000000000000000000000000 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca800 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca9f8 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccabf0 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccade8 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SPD data > 021000021d000000000000000000000003000600000000001002000059d44c6d00000000 > 00000000010014000101000001001300000000000300150000000000100200000a000000 > 0000000000000000030011000000000010020000ffffff00000000000000000003001600 > 00000000100200000a0708000000000000000000030012000000000010020000ffffff00 > 000000000000000005000a0001000000000000000000000038392e3231322e39312e3137 > 382f3332000000000000000005000b0001000000000000000000000038392e3231322e37 > 362e3130392f33320000000000000000021000021d000000000000000000000003000600 > 000000001002000059d44c6d000000000000000001001400030200000100130000000000 > 0300150000000000100200000a0708000000000000000000030011000000000010020000 > ffffff0000000000000000000300160000000000100200000a0000000000000000000000 > 030012000000000010020000ffffff00000000000000000005000a000100000000000000 > 0000000038392e3231322e39312e3137382f3332000000000000000005000b0001000000 > 000000000000000038392e3231322e37362e3130392f3332000000000000000002100002 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca000 > len 232 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca0e8 > len 232 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca1d0 > len 232 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca2b8 > len 232 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca3a0 > len 232 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca488 > len 232 to peer 10.23.6.2 > > It looks to me like everything is ok? > > log from slave: > Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: add peer 10.23.6.3 > Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: interface carp3 > Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: group carp > Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: 32 byte shared hex key > Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: shared key set > Jan 6 22:52:09 openbsd2 sasyncd[3384]: carp_init: initializing runstate to > SLAVE > Jan 6 22:52:09 openbsd2 sasyncd[3384]: listening on 0.0.0.0 port 500 fd 6 > Jan 6 22:52:09 openbsd2 sasyncd[3384]: net_connect: peer "10.23.6.3" > connected, fd 7 > Jan 6 22:52:09 openbsd2 sasyncd[26685]: net_ctl: peer "10.23.6.3" state > change to MASTER > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey FLUSH len > 16 seq 1 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey ADD len > 504 seq 2 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey ADD len > 504 seq 3 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey: msg ADD write() failed on > socket 5: Invalid argument > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey ADD len > 504 seq 4 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey: msg ADD write() failed on > socket 5: Invalid argument > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey ADD len > 504 seq 5 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey: msg ADD write() failed on > socket 5: Invalid argument > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey X_ADDFLOW > len 232 seq 6 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey: msg ADD write() failed on > socket 5: Invalid argument > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey X_ADDFLOW > len 232 seq 7 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey X_ADDFLOW > len 232 seq 8 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey X_ADDFLOW > len 232 seq 9 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey X_ADDFLOW > len 232 seq 10 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey X_ADDFLOW > len 232 seq 11 > > I've searched the web for "pfkey: msg ADD write() failed on socket 5: Invalid > argument", but I've only found openswan related info. > I went through all google results for "sasyncd", and only clue I've got from > this link: http://www.lugbe.ch/action/reports/BSDCluster.pdf > where it says for sasyncd: > Known bugs: Resynchronisation des Master nach Reboot > which, I assume, have something to do with this problem. But I couldn't find > anything else about that bug > > When a new SAD is created on the master, it is normaly synced with slave. > I am runnig 4.6-stable > I will send more info If it is needed. > > Thank you very much
