Darn.
It does seem we are using different versions of the Joplin desktop app and it looks like you're running under Windows. For what it's worth, my installations are on MacOS (as previously mentioned) but I also had success with my Linux setup (under PopOS).
On both of those setups, the rollback to Clipper v2.8.1 solved the problem. Also, both Mac and Linux installations failed with Clipper v. 2.10.11.
It says this when trying to start the server, so it looks like something is preventing it on your computer. Maybe an antivirus or firewall:
connect ETIMEDOUT 127.0.0.1:41184
Thanks Laurent!
I had noticed this message and already tried to restart the app without any firewall nor antivirus, but the result is the same... Moreover, after the latest mandatory security Windows updates, the clipper was OK, so I really suspect some issue with Joplin.
I'm willing to help on this issue, so do not hesitate to send instructions if I can log more things!
Thanks again for your help!
You might want to try on a windows forum and ask what could block a local server, as this is not specific to Joplin.
You can show the above error message as it's a generic one.
you can try to check if another process is using the same port with the following command.
netstat -ano | find "41184"The marked number is the PID of the process
3. Check in the task manager which process has this PID.
In my example it's Joplin
Thanks for the tip!
As expected, once Joplin is closed, the netstat command returns an empty string, meaning no other process has grabbed the 41184 port... What I need to understand is which process is preventing Joplin from running the internal webserver: any idea on the tools I could use?
Could you check and see if you can start some other server on your computer? Any of these would do:
Maybe the Power Shell one if you're on Windows:
$Hso=New-Object Net.HttpListener;$Hso.Prefixes.Add("http://+:8000/");$Hso.Start();While ($Hso.IsListening){$HC=$Hso.GetContext();$HRes=$HC.Response;$HRes.Headers.Add("Content-Type","text/plain");$Buf=[Text.Encoding]::UTF8.GetBytes((GC (Join-Path $Pwd ($HC.Request).RawUrl)));$HRes.ContentLength64=$Buf.Length;$HRes.OutputStream.Write($Buf,0,$Buf.Length);$HRes.Close()};$Hso.Stop()
Hi Laurent,
Running the Powershell server on port 8000 = OK
Running the Powershell server on port 41184 = OK too, while Joplin is running
This drives us back to the application having trouble to launch its embedded webserver, non?
Hi Laurent,
Did it provide any information to you? Do you have any hint to troubleshoot the issue? Still willing to help, as the clipper is of utmost importance to me!
Thanks in advance for your help!
No sorry I have no idea. Again you might have more luck on a Windows forum where they might now how to debug such network issues
Hi Laurent,
I ran Wireshark over the localhost loop connection and found out that:
I wonder how I can determine which process is listening on port 54553: is this the web clipper?
Thanks in advance for any help!
Query:
Frame 65: 56 bytes on wire (448 bits), 56 bytes captured (448 bits) on interface \Device\NPF_Loopback, id 0
Null/Loopback
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 54553, Dst Port: 41184, Seq: 0, Len: 0
Source Port: 54553
Destination Port: 41184
[Stream index: 0]
[Conversation completeness: Incomplete (37)]
[TCP Segment Len: 0]
Sequence Number: 0 (relative sequence number)
Sequence Number (raw): 3196503279
[Next Sequence Number: 1 (relative sequence number)]
Acknowledgment Number: 0
Acknowledgment number (raw): 0
1000 .... = Header Length: 32 bytes (8)
Flags: 0x002 (SYN)
Window: 65535
[Calculated window size: 65535]
Checksum: 0x7d79 [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
[Timestamps]
Reply:
Frame 102: 44 bytes on wire (352 bits), 44 bytes captured (352 bits) on interface \Device\NPF_Loopback, id 0
Null/Loopback
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 41184, Dst Port: 54553, Seq: 1, Ack: 1, Len: 0
Source Port: 41184
Destination Port: 54553
[Stream index: 0]
[Conversation completeness: Incomplete (37)]
[TCP Segment Len: 0]
Sequence Number: 1 (relative sequence number)
Sequence Number (raw): 0
[Next Sequence Number: 1 (relative sequence number)]
Acknowledgment Number: 1 (relative ack number)
Acknowledgment number (raw): 3196503280
0101 .... = Header Length: 20 bytes (5)
Flags: 0x014 (RST, ACK)
Window: 0
[Calculated window size: 0]
[Window size scaling factor: -1 (unknown)]
Checksum: 0xb85c [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
[Timestamps]
[SEQ/ACK analysis]
The server listens on port 41184.
The other port 54553 I don't know, I think it's part of the protocol and it's random but perhaps someone who knows more about TCP can help
Hi Laurent,
I upgraded Joplin to v2.10.19 but still have the same issue. It seems a shadow process is incorrectly requesting Joplin's server (last time from port 30168) but I couldn't identify the culprit: listing all processes and their ports doesn't show any process with the querying port! 
I didn't get much information from Microsoft forums where the guys point me back to here...
I'm lost and despaired: do you think a complete re-installation could solve the issue (I'm afraid of losing the hundreds of notes I already created)?
Thanks in advance for any help!
Maybe reinstalling would help, and you wouldn't lose your notes because they are in a separate directory. Just to be safe though, export everything as JEX first as a backup.
Another thing to try is the portable version
Interestingly, Joplin Portable displays exactly the same issue: when the application launches, the clipper service briefly starts then goes idle. Wireshark reveals the same (malformed) exchange I described in Web Clipper cannot connect to the app anymore - #31 by jlgarnier (from a different port) and I can't identify which process is "pinging" Joplin...
This issue is probably not on Joplin's side, however the app was not sensitive to the malformed query before... Seems the query just shuts down the embedded server, no?
If there's something sending malformed requests, could it possibly be some malware scanning all the ports and sending data?
Hi Laurent,
I launched a deep scan of the whole system, deactivated most of the background-running services and yet couldn't find any suspicious activity. The clipper still falls to idle state seconds after it launches.
By the way, as my printer was stuck on a corrupted PDF file, I had to restart the machine, which I already did tens of time since the issue appeared. This time, this "unlocked" the clipper which now displays "État : Démarré sur le port 41184"!
I LOVE MIRACLES! But I do prefer when I understand how they pop up...
I'm afraid we'll never know what was the root cause of the issue, but warmly thank you anyway for your constant support!
Glad it's finally working, but indeed it would be nice to know what the issue was!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.