Description of problem: When a federated connection comes in, this happens and sends a 404 back to the user: =INFO REPORT==== 2007-12-18 16:32:39 === I(<0.230.0>:ejabberd_listener:90): (#Port<0.1803>) Accepted connection {{0,0,0,0,0,65535,53493,54370},59294} -> {{0,0,0,0,0,65535,49320,1},5269} =INFO REPORT==== 2007-12-18 16:32:39 === I(<0.8395.0>:ejabberd_s2s_in:105): started: {gen_tcp,#Port<0.1803>} =INFO REPORT==== 2007-12-18 16:32:39 === I(<0.8395.0>:ejabberd_s2s_in:222): starttls =INFO REPORT==== 2007-12-18 16:32:39 === I(<0.8395.0>:ejabberd_s2s_in:519): terminated: {undef, [{'PKIX1Explicit88',decode, ['X520CommonName', <<20,12,42,46,106,97,98, 98,101,114,46,111,114, 103>>]}, {ejabberd_s2s_in, '-get_cert_domains/1-fun-0-', 1}, {lists,flatmap,2}, {lists,flatmap,2}, {ejabberd_s2s_in, get_cert_domains,1}, {ejabberd_s2s_in, wait_for_feature_request,2}, {gen_fsm,handle_msg,7}, {proc_lib,init_p,5}]} =ERROR REPORT==== 2007-12-18 16:32:39 === ** State machine <0.8395.0> terminating ** Last event in was {xmlstreamelement, {xmlelement,"auth", [{"xmlns","urn:ietf:params:xml:ns:xmpp-sasl"}, {"mechanism","EXTERNAL"}], [{xmlcdata,<<"amFiYmVyLm9yZw==">>}]}} ** When State == wait_for_feature_request ** Data == {state,{tlssock,#Port<0.1803>,#Port<0.1805>}, tls,<0.8396.0>,"560872400",s2s_shaper,true,true, [{certfile,"/etc/ejabberd/ejabberd.pem"}], false,undefined, {dict,0,16,16,8,80,48, {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[], []}, {{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[], []}}}, #Ref<0.0.0.27313>} ** Reason for termination = ** {'module could not be loaded', [{'PKIX1Explicit88',decode, ['X520CommonName', <<20,12,42,46,106,97,98,98,101,114,46,111,114,103>>]}, {ejabberd_s2s_in,'-get_cert_domains/1-fun-0-',1}, {lists,flatmap,2}, {lists,flatmap,2}, {ejabberd_s2s_in,get_cert_domains,1}, {ejabberd_s2s_in,wait_for_feature_request,2}, {gen_fsm,handle_msg,7}, {proc_lib,init_p,5}]} Suspiciously, this is the same module as was replaced in the new erlang. Rebuilding ejabberd-1.1.4-3 fixes this. Version-Release number of selected component (if applicable): ejabberd-1.1.4-1.fc8
Oh no, it doesn't look like this is fixed by a simple recompile. I am getting it again today. =SUPERVISOR REPORT==== 19-Dec-2007::14:01:39 === Supervisor: {local,ejabberd_s2s_in_sup} Context: child_terminated Reason: {undef, [{'PKIX1Explicit88',decode, ['X520CommonName', <<20,12,42,46,106,97,98,98,101,114,46,111,114,103>>]}, {ejabberd_s2s_in,'-get_cert_domains/1-fun-0-',1}, {lists,flatmap,2}, {lists,flatmap,2}, {ejabberd_s2s_in,get_cert_domains,1}, {ejabberd_s2s_in,wait_for_feature_request,2}, {gen_fsm,handle_msg,7}, {proc_lib,init_p,5}]} Offender: [{pid,<0.2348.0>}, {name,undefined}, {mfa, {ejabberd_s2s_in,start_link, [{gen_tcp,#Port<0.1094>}, [{shaper,s2s_shaper}, {max_stanza_size,131072}, inet6]]}}, {restart_type,temporary}, {shutdown,brutal_kill}, {child_type,worker}]
Try to rebuild with the patch mentioned here: http://support.process-one.net/browse/EJAB-446 - does it fix your problem?
Created attachment 292620 [details] The patch for Fedora SRPM
Created attachment 292621 [details] Updated spec file that applies the patch
Created attachment 292622 [details] Updated SRPM for Fedora Core 7 Try to rebuild and install this SRPM and tell if it fixes your problem. You can also take the existing Fedora SRPM for Fedora Core 7 and add the attached ssl.patch and ejabberd.spec - the result will be the same.
This appears to be working, so far. I will update when I have tested for a while.
ejabberd-2.0.0-0.3.rc1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ejabberd'. You can provide feedback for this update here: http://admin.fedoraproject.org/F8/FEDORA-2008-1042
ejabberd-2.0.0-0.3.rc1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
ejabberd-2.0.0-0.3.rc1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.