I use latest java mail api. I want to rename an IMAP folder which contains children (subfolders). Suppose we have inbox and inbox has one subfolder inbox.folder1.
The folder1 has one subfolder its full name is inbox.folder1.subfolder1
I want to rename folder1 to folder2 and i want that to see:
inbox.folder2.subfolder1
but after the code
// folder instance corresponds to folder1
newFolder = folder.getFolder(newName); //newName = "folder2"
folder.renameTo(newFolder);
i have if you connect using outlook or thunderbird
inbox.folder1.subfolder1
inbox.folder2
we have two folders, but i expect one. And also subfolder1 still sitting in folder1. And you can not enter folder or subfolder1, they generate error message: Reason Given: Mailbox does not exist, or must be subscribed to.
Should i use setSubscripbed(true/false)? Do I have to handle subfolders separately by iterating each one?
I solved. First i turned on debugging mode of thunderbird as stated in:
https://wiki.mozilla.org/MailNews:Logging#Environment_Variables_to_set
Then i renamed a folder which contained many subfolders.
As you see, you have to call subscribe to folders with new name and unscribe with old name with the order specified in the log file.
Without calling the subscribe/unsubscribe method calls, you get the message in the mail server console
68 OK Folder renamed.
but it is not enough and you have corrupted folder structure.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 68 rename "INBOX.folder1" "INBOX.folder2"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=23 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 68 OK Folder renamed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 69 subscribe "INBOX.folder2"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=26 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 69 OK Folder subscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 70 unsubscribe "INBOX.folder1"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=28 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 70 OK Folder unsubscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 71 subscribe "INBOX.folder2.subfolder1.subsubfolder1.subsubsubfolder1b"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=26 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 71 OK Folder subscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 72 unsubscribe "INBOX.folder1.subfolder1.subsubfolder1.subsubsubfolder1b"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=28 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 72 OK Folder unsubscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 73 subscribe "INBOX.folder2.subfolder1.subsubfolder1.subsubsubfolder1a"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=26 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 73 OK Folder subscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 74 unsubscribe "INBOX.folder1.subfolder1.subsubfolder1.subsubsubfolder1a"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=28 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 74 OK Folder unsubscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 75 subscribe "INBOX.folder2.subfolder3.subsubfolder3"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=26 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 75 OK Folder subscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 76 unsubscribe "INBOX.folder1.subfolder3.subsubfolder3"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=28 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 76 OK Folder unsubscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 77 subscribe "INBOX.folder2.subfolder3"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=26 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 77 OK Folder subscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 78 unsubscribe "INBOX.folder1.subfolder3"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=28 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 78 OK Folder unsubscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 79 subscribe "INBOX.folder2.subfolder1.subsubfolder1"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=26 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 79 OK Folder subscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 80 unsubscribe "INBOX.folder1.subfolder1.subsubfolder1"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=28 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 80 OK Folder unsubscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 81 subscribe "INBOX.folder2.subfolder2"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=26 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 81 OK Folder subscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 82 unsubscribe "INBOX.folder1.subfolder2"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=28 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 82 OK Folder unsubscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 83 subscribe "INBOX.folder2.subfolder1"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=26 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 83 OK Folder subscribed.
9944[ab79a70]: 7cea000:192.168.0.104:A:SendData: 84 unsubscribe "INBOX.folder1.subfolder1"
9944[ab79a70]: ReadNextLine [stream=a6db068 nb=28 needmore=0]
9944[ab79a70]: 7cea000:192.168.0.104:A:CreateNewLineFromSocket: 84 OK Folder unsubscribed.
Related
I'm trying to resolve the following performance problem. There is a database which is synchronously replicated to a remote location via TCP. Currently, everything works great. But it's being migrated to new hardware, and a test load shows that everything slows down roughly by a factor of 2. Basically, the current setup supports sustained transfer rates of 200-300 MB/s whereas the new one gets 100-150MB/s at best, and it's not good enough for us.
There is nothing obviously wrong from the database side. Database instrumentation says that the source database is busy sending data on the network (by large chunks, tens of MB at a time), and the destination one is busy receiving it on the network. So I'm looking at the TCP packet capture in Wireshark and I notice a few things that look a bit odd in the new setup -- see a sample below.
AFAIK the window scaling factor is 7 for this conversation so receive window gets a x128 factor which means most of the time it's not a limiting factor.
First of all, most of the time there is only 1 packet in flight per every ACK which is not the case for the existing setup where I can see multiple bursts of tens of outgoing packets. Is this Nagle algorithm in action or something else? It's supposed to be off (there is a tcp nodelay option on the application level) but it's still a bit suspicious.
Second, I don't understand the timings. It's almost as if something is controlling the rate of outgoing packets and keeps it roughly to 1 packet every 50 us (sometimes a bit more, sometimes a bit less), rather than leaving within a couple of microseconds after getting an ACK. Could there be some sort of burst control in place or am I imagining things?
Third, segment size. Most of segments are 8kB as compared to existing setup where they are 64kB. We experimented with the application settings but we can't seem to be able to make a difference -- 64kB segments are there, but they are rare. Is there a way in Linux to strongly encourage larger segments?
36 2022-09-01 15:02:45.267111 192.168.240.122 192.168.240.115 TCP 8210 45508 → 1600 [PSH, ACK] Seq=2162935757 Ack=3197136358 Win=6166 Len=8156
37 2022-09-01 15:02:45.267115 192.168.240.115 192.168.240.122 TCP 54 1600 → 45508 [ACK] Seq=3197136358 Ack=2162943913 Win=24525 Len=0
38 2022-09-01 15:02:45.267162 192.168.240.122 192.168.240.115 TCP 8210 45508 → 1600 [PSH, ACK] Seq=2162943913 Ack=3197136358 Win=6166 Len=8156
39 2022-09-01 15:02:45.267166 192.168.240.115 192.168.240.122 TCP 54 1600 → 45508 [ACK] Seq=3197136358 Ack=2162952069 Win=24525 Len=0
40 2022-09-01 15:02:45.267212 192.168.240.122 192.168.240.115 TCP 8210 45508 → 1600 [PSH, ACK] Seq=2162952069 Ack=3197136358 Win=6166 Len=8156
41 2022-09-01 15:02:45.267215 192.168.240.115 192.168.240.122 TCP 54 1600 → 45508 [ACK] Seq=3197136358 Ack=2162960225 Win=24525 Len=0
42 2022-09-01 15:02:45.267261 192.168.240.122 192.168.240.115 TCP 8210 45508 → 1600 [PSH, ACK] Seq=2162960225 Ack=3197136358 Win=6166 Len=8156
43 2022-09-01 15:02:45.267265 192.168.240.115 192.168.240.122 TCP 54 1600 → 45508 [ACK] Seq=3197136358 Ack=2162968381 Win=24525 Len=0
44 2022-09-01 15:02:45.267313 192.168.240.122 192.168.240.115 TCP 8210 45508 → 1600 [PSH, ACK] Seq=2162968381 Ack=3197136358 Win=6166 Len=8156
45 2022-09-01 15:02:45.267318 192.168.240.115 192.168.240.122 TCP 54 1600 → 45508 [ACK] Seq=3197136358 Ack=2162976537 Win=24525 Len=0
46 2022-09-01 15:02:45.267342 192.168.240.122 192.168.240.115 TCP 8210 45508 → 1600 [PSH, ACK] Seq=2162976537 Ack=3197136358 Win=6166 Len=8156
47 2022-09-01 15:02:45.267346 192.168.240.115 192.168.240.122 TCP 54 1600 → 45508 [ACK] Seq=3197136358 Ack=2162984693 Win=24525 Len=0
48 2022-09-01 15:02:45.267391 192.168.240.122 192.168.240.115 TCP 8210 45508 → 1600 [PSH, ACK] Seq=2162984693 Ack=3197136358 Win=6166 Len=8156
Any suggestions are greatly appreciated.
Thanks!
Update: I've shared packet capture files on sender and receiver sides for both current setup and old setup at https://drive.google.com/drive/folders/1ktBDjRHOUCfia1kTfdVIQdS-Q1k4B3qn
Update2: I've written a blog entry about this investigation for those interested: https://savvinov.com/2022/09/20/use-of-packet-capture-and-other-advanced-tools-in-network-issues-troubleshooting/
Best regards,
Nikolai
While I couldn't find answers to all of my questions, I found the ones that mattered most.
It turned out that the TCP stack was sending data in 8kB segments because the "application" send it that way to it. By "application" I mean the replication software (Oracle Data Guard) that picked up a stream of database changes on the source database and wrote it to the remote standby.
So eventually I traced tcp_sendmsg using BCC trace.py utility and found that its segment size argument was about 8kB (8156 bytes to be more specific). Then I traced the network stack on the "application" level, forcing the connection to be re-established during the tracing, and it turned out to be that the parameter controlling the size of the transmission (SDU or session data unit) was supposed to be 64kB in settings, but in fact the new connection was using a smaller value, 8kB.
Further research showed that there was a number of oddities around the way this parameter is set, and also that the documentation around it was inaccurate.
When the correct way to set the value was found by trial and error, the throughput became immediately much better and all the bottlenecks that bothered us disappeared.
Best regards,
Nikolai
I have a self managed Kubernetes cluster consisting of one master node and 3 worker nodes. I use the Cluster Network Interface flannel within the cluster.
On all my machines I can see the following kind of kernel messages:
Apr 12 04:22:24 worker-7 kernel: [278523.379954] iptables[6260]: segfault at 88 ip 00007f9e69fefe47 sp 00007ffee4dff356 error 4 in libnftnl.so.11.3.0[7f9e69feb000+16000]
Apr 12 04:22:24 worker-7 kernel: [278523.380094] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 <48> 8b 87 88 00 00 00 48 81 c7 78 00 00 00 48 39 f8 74 0b 85 f6 74
Apr 12 05:59:10 worker-7 kernel: [284329.182667] iptables[13978]: segfault at 88 ip 00007fb799fafe47 sp 00007fff22419b36 error 4 in libnftnl.so.11.3.0[7fb799fab000+16000]
Apr 12 05:59:10 worker-7 kernel: [284329.182774] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 <48> 8b 87 88 00 00 00 48 81 c7 98 00 00 00 48 39 f8 74 0b 85 f6 74
Apr 12 08:29:25 worker-7 kernel: [293343.999073] iptables[16041]: segfault at 88 ip 00007fa40c7f7e47 sp 00007ffe04ba9886 error 4 in libnftnl.so.11.3.0[7fa40c7f3000+16000]
Apr 12 08:29:25 worker-7 kernel: [293343.999165] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 <48> 8b 87 88 00 00 00 48 81 c7 98 00 00 00 48 39 f8 74 0b 85 f6 74
I narrowed it down that the messages originated in the kube-flannel-ds pods. I have log messages like this one:
Failed to ensure iptables rules: Error checking rule existence: failed to check rule existence: running [/sbin/iptables -t filter -C FORWARD -s 10.244.0.0/16 -j ACCEPT --wait]: exit status -1:
Failed to ensure iptables rules: Error checking rule existence: failed to check rule existence: running [/sbin/iptables -t nat -C POS TROUTING -s 10.244.0.0/16 ! -d 224.0.0.0/4 -j MASQUERADE --random-fully --wait]: exit status -1:
Can someone explain what this kind of messages are indicating? Can this be a hardware problem? Does it make sense to switch form flannel to another kuberentes container network interface (CNI) - e.g. Calico?
As already mentioned in the comments debian buster uses nftables backed instead of iptables:
NOTE: iptables is being replaced by nftables starting with Debian Buster - reference here
Unfortunately the nftables are not compatible at this moment with kubernetes.
In Linux, nftables is available as a modern replacement for the kernel’s iptables subsystem. The iptables tooling can act as a compatibility layer, behaving like iptables but actually configuring nftables. This nftables backend is not compatible with the current kubeadm packages: it causes duplicated firewall rules and breaks kube-proxy. You could try to switch to legacy option like described here but I'm not sure about this solution as I don't have a way to test it with your Os. I solved similar case with debian with this here.
Alternative way would to switch to Calico which actually supports nftbacked with FELIX_IPTABLESBACKEND. This parameter controls which variant of iptables binary Felix uses. Set this to Auto for auto detection of the backend. If a specific backend is needed then use NFT for hosts using a netfilter backend or Legacy for others. [Default: Auto].
When installing calico with containerd please also have a look a this case.
I am trying to configure ColdFusion to send emails using 1&1's servers (smtp.1and1.com) and even though I have set the username and password it keeps failing.
This is what I've done so far:
Set outgoing server to smtp.1and1.com
set username and password
set port to 587
selected Use TLS checkbox
selected Verify Settings box
when I click Save I get the message "Connection Verification Failed!"
In the ColdFusion log files in the mail.log I see this error:
"Error","scheduler-1","03/22/16","19:39:21",,"Can't send command to
SMTP host"
I ran WireShark and captured some packets and it seems it does connect to the server, some communication goes back and forth, and then it aborts.
Below is a sample of the capture:
No Time Protocol Length Info
1 0.000000 TCP 66 49858 ? 587 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
2 0.000567 TCP 66 587 ? 49858 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=512
3 0.000611 TCP 54 49858 ? 587 [ACK] Seq=1 Ack=1 Win=131328 Len=0
4 0.007028 SMTP 112 S: 220 perfora.net (mreueus002) Nemesis ESMTP Service ready
5 0.015100 SMTP 70 C: EHLO vm229CAC8
6 0.015556 TCP 60 587 ? 49858 [ACK] Seq=59 Ack=17 Win=29696 Len=0
7 0.015697 SMTP 159 S: 250 perfora.net Hello vm229CAC8 [**.**.**.**] | 250 SIZE 69920427 | 250 AUTH LOGIN PLAIN | 250 STARTTLS
8 0.019485 SMTP 64 C: STARTTLS
9 0.021416 SMTP 62 S: 220 OK
10 0.058490 TLSv1 132 Client Hello
11 0.059244 TLSv1 1514 Server Hello
12 0.059246 TCP 1514 [TCP segment of a reassembled PDU]
13 0.059283 TCP 54 49858 ? 587 [ACK] Seq=105 Ack=3092 Win=131328 Len=0
14 0.059308 TLSv1 710 Certificate
15 0.070314 TLSv1 61 Alert (Level: Fatal, Description: Certificate Unknown)
16 0.070368 TCP 54 49858 ? 587 [FIN, ACK] Seq=112 Ack=3748 Win=130560 Len=0
17 0.070858 TLSv1 61 Alert (Level: Fatal, Description: Internal Error)
18 0.070905 TCP 54 49858 ? 587 [RST, ACK] Seq=113 Ack=3755 Win=0 Len=0
19 0.071198 TCP 60 587 ? 49858 [FIN, ACK] Seq=3755 Ack=113 Win=29696 Len=0
All of which makes me think that there is something with the certificate (since it aborts before it even bothers with the username and password).
I've saved the 3 certificates from packet 14 and looked at them and they all seem fine - validity is OK, Thawte is the root CA - checked and confirmed the included one is OK, etc.
What am I missing? And are there any other log files that might shed some more light on this issue?
Thanks
I found it. It was the certificate.
ColdFusion runs on top of Java. Java has its own set of trusted root certificates. This server's root certificate wasn't there (hence why it wasn't trusted).
Solution essentially boiled down to:
Save the root certificate in a file
import it into the ColdFusion's java run-machine' trusted root certificates
restart ColdFusion so that it picks up the changes
The first step was easy - I expanded the 14th packet within WireShark, there were 3 certificates in it, saved them as 1.cer 2.cer and 3.cer files (it was 3.cer which had just the root one). I guess I could've visited any of 1&1's web pages via https and grabbed it, but wasn't sure if they'll use the same root CA. So extracting it from the actual packet seemed like the safer option.
ColdFusion was installed in C:\ColdFusion\ and to find out which Java runtime it starts I looked under C:\ColdFusion\bin\cfstart.bin which had was referring to ..\runtime\bin\jrun -start coldfusion.
Its Java run-machine had the certificates stored in C:\ColdFusion\runtime\jre\lib\security\cacerts
What remained was how to import it in that keystore - I used portecle as suggested here.
After restarting ColdFusion and asking it politely to verify the settings it confirmed them and I saw the below log in WireShark:
No. Time Protocol Length Info
104 3.895581 TCP 66 55157 ? 587 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
105 3.896180 TCP 66 587 ? 55157 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=512
106 3.896229 TCP 54 55157 ? 587 [ACK] Seq=1 Ack=1 Win=131328 Len=0
107 3.902608 SMTP 112 S: 220 perfora.net (mreueus003) Nemesis ESMTP Service ready
108 3.903791 SMTP 70 C: EHLO vm229CAC8
109 3.904271 TCP 60 587 ? 55157 [ACK] Seq=59 Ack=17 Win=29696 Len=0
110 3.904390 SMTP 159 S: 250 perfora.net Hello vm229CAC8 [**.**.**.**] | 250 SIZE 69920427 | 250 AUTH LOGIN PLAIN | 250 STARTTLS
111 3.904532 SMTP 64 C: STARTTLS
112 3.906347 SMTP 62 S: 220 OK
118 4.112009 TCP 62 [TCP Retransmission] 587 ? 55157 [PSH, ACK] Seq=164 Ack=27 Win=29696 Len=8
119 4.112057 TCP 66 55157 ? 587 [ACK] Seq=27 Ack=172 Win=131072 Len=0 SLE=164 SRE=172
120 4.115457 TLSv1 132 Client Hello
121 4.116154 TLSv1 1514 Server Hello
122 4.116157 TCP 1514 [TCP segment of a reassembled PDU]
123 4.116158 TLSv1 710 Certificate
124 4.116201 TCP 54 55157 ? 587 [ACK] Seq=105 Ack=3748 Win=131328 Len=0
125 4.156467 TLSv1 321 Client Key Exchange
127 4.196201 TCP 60 587 ? 55157 [ACK] Seq=3748 Ack=372 Win=30720 Len=0
128 4.196237 TLSv1 97 Change Cipher Spec, Encrypted Handshake Message
129 4.196799 TCP 60 587 ? 55157 [ACK] Seq=3748 Ack=415 Win=30720 Len=0
130 4.197005 TLSv1 97 Change Cipher Spec, Encrypted Handshake Message
131 4.197742 TLSv1 91 Application Data
132 4.198262 TLSv1 166 Application Data
133 4.198550 TLSv1 87 Application Data
134 4.199201 TLSv1 93 Application Data
135 4.199677 TLSv1 117 Application Data
136 4.200122 TLSv1 93 Application Data
137 4.200345 TLSv1 101 Application Data
138 4.240137 TCP 60 587 ? 55157 [ACK] Seq=3981 Ack=595 Win=30720 Len=0
143 4.448738 TLSv1 105 Application Data
154 4.652126 TCP 105 [TCP Retransmission] 587 ? 55157 [PSH, ACK] Seq=3981 Ack=595 Win=30720 Len=51
155 4.652153 TCP 66 55157 ? 587 [ACK] Seq=595 Ack=4032 Win=131072 Len=0 SLE=3981 SRE=4032
and also tried sending a few test emails and everything worked as expected.
Thanks for everyone's help and suggestions! :)
p.s. And I found also the backup option. Turns out 1&1 does support TLS but does not require it. Plain old SMTP with no TLS worked just fine on port 587.
I discovered this accidentally - it is probably a bug in ColdFusion (version 9 in my case). In ColdFusion's Server Settings > Mail > Undelivered Mail I told it to resend a failed email. And it did - but without attempting the TLS part.
I'm migrating some java+maven projects to scala+sbt but I've been having some troubles to make sbt work with my maven repository.
I'm using sbt 0.13.5 and my build.sbt looks like this:
name := "test"
version := "0.0.1"
resolvers += "uqbar-repo" at "ftp://mvn+uqbar-wiki.org:<my_password>#ftp.uqbar-wiki.org/releases"
libraryDependencies += "uqbar" % "uqbar-commons" % "1.1"
As you may see, my dependencies are hosted in an ftp server (ssh is not available so just ftp, NOT sftp) and there seems to be no problem to access them from maven, but running sbt yields the following error:
[info] Updating {file:/home/nicolas/Dev/test/}test...
[info] Resolving uqbar#uqbar-commons;1.1 ...
[warn] module not found: uqbar#uqbar-commons;1.1
[warn] ==== local: tried
[warn] /home/nicolas/.ivy2/local/uqbar/uqbar-commons/1.1/ivys/ivy.xml
[warn] ==== public: tried
[warn] http://repo1.maven.org/maven2/uqbar/uqbar-commons/1.1/uqbar-commons-1.1.pom
[warn] ==== uqbar-repo: tried
[warn] ftp://mvn+uqbar-wiki.org:<my_password>#ftp.uqbar-wiki.org/releases/uqbar/uqbar-commons/1.1/uqbar-commons-1.1.pom
[info] Resolving jline#jline;2.11 ...
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: UNRESOLVED DEPENDENCIES ::
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: uqbar#uqbar-commons;1.1: not found
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[trace] Stack trace suppressed: run last *:update for the full output.
[error] (*:update) sbt.ResolveException: unresolved dependency: uqbar#uqbar-commons;1.1: not found
I found this weird, since the files are there (pom can be accessed from the url sbt tried, even from a browser) so I used a sniffer to check what was actually being send and receive. The output I got was:
25 2.887053000 31.22.4.33 192.168.1.109 FTP 386 Response: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
27 2.887536000 192.168.1.109 31.22.4.33 FTP 91 Request: USER mvn+uqbar-wiki.org
29 3.135330000 31.22.4.33 192.168.1.109 FTP 117 Response: 331 User mvn+uqbar-wiki.org OK. Password required
30 3.135590000 192.168.1.109 31.22.4.33 FTP 84 Request: PASS <my_password>
32 3.424510000 31.22.4.33 192.168.1.109 FTP 109 Response: 230 OK. Current restricted directory is /
33 3.424825000 192.168.1.109 31.22.4.33 FTP 74 Request: TYPE I
35 3.665227000 31.22.4.33 192.168.1.109 FTP 96 Response: 200 TYPE is now 8-bit binary
36 3.665449000 192.168.1.109 31.22.4.33 FTP 80 Request: CWD releases
37 3.897858000 31.22.4.33 192.168.1.109 FTP 106 Response: 250 OK. Current directory is /releases
38 3.898170000 192.168.1.109 31.22.4.33 FTP 77 Request: CWD uqbar
39 4.132531000 31.22.4.33 192.168.1.109 FTP 112 Response: 250 OK. Current directory is /releases/uqbar
40 4.132765000 192.168.1.109 31.22.4.33 FTP 85 Request: CWD uqbar-commons
43 4.365921000 31.22.4.33 192.168.1.109 FTP 126 Response: 250 OK. Current directory is /releases/uqbar/uqbar-commons
44 4.366217000 192.168.1.109 31.22.4.33 FTP 75 Request: CWD 1.1
45 4.606673000 31.22.4.33 192.168.1.109 FTP 130 Response: 250 OK. Current directory is /releases/uqbar/uqbar-commons/1.1
46 4.606921000 192.168.1.109 31.22.4.33 FTP 76 Request: EPSV ALL
47 4.842167000 31.22.4.33 192.168.1.109 FTP 87 Response: 500 Unknown command
48 4.842374000 192.168.1.109 31.22.4.33 FTP 72 Request: PASV
49 5.076465000 31.22.4.33 192.168.1.109 FTP 114 Response: 227 Entering Passive Mode (31,22,4,33,187,254)
54 5.309929000 192.168.1.109 31.22.4.33 FTP 94 Request: RETR uqbar-commons-1.1.pom
55 5.547075000 31.22.4.33 192.168.1.109 FTP 96 Response: 150 Accepted data connection
64 5.550301000 31.22.4.33 192.168.1.109 FTP 161 Response: 226-File successfully transferred
66 5.550465000 192.168.1.109 31.22.4.33 FTP 72 Request: QUIT
69 5.789052000 31.22.4.33 192.168.1.109 FTP 133 Response: 221-Goodbye. You uploaded 0 and downloaded 2 kbytes.
Now, my ftp is a little rusty, but that log seems to indicate that sbt found and download the pom.
In case it is of any use, here is the pom content:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>uqbar</groupId>
<artifactId>uqbar-commons</artifactId>
<version>1.1</version>
<packaging>jar</packaging>
<name>uqbar-commons</name>
<parent>
<groupId>uqbar</groupId>
<artifactId>uqbar-parent-project</artifactId>
<version>1.4</version>
</parent>
<properties>
<scm.svnPath>svn/uqbar/commons/uqbar-commons</scm.svnPath>
</properties>
<scm>
<connection>scm:svn:http://uqbar.no-ip.org/svn/uqbar/commons/uqbar-commons/tags/uqbar-commons-1.1</connection>
<developerConnection>scm:svn:http://uqbar.no-ip.org/svn/uqbar/commons/uqbar-commons/tags/uqbar-commons-1.1</developerConnection>
<url>http://uqbar.no-ip.org/svn/uqbar/commons/uqbar-commons/tags/uqbar-commons-1.1</url>
</scm>
<dependencies>
<!-- UQBAR -->
<dependency>
<groupId>com.uqbar</groupId>
<artifactId>uqbar-class-descriptor</artifactId>
<version>1.1</version>
</dependency>
<dependency>
<groupId>uqbar</groupId>
<artifactId>uqbar-bttf</artifactId>
<version>2.3</version>
</dependency>
<!-- /UQBAR -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.7.0</version>
</dependency>
<dependency>
<groupId>cglib</groupId>
<artifactId>cglib</artifactId>
<version>2.2</version>
</dependency>
</dependencies>
</project>
I've search the documentation but found nothing and I have no idea where the problem may be, so any hint is welcome.
Thanks in advance!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I'm trying to configure my Windows 7 PC to wake on lan (S4 and S5), but it just doesn't work. I have followed all the steps.
Changed my network adapter settings to wake on magic packet
Opened UDP port 7 on my windows firewall
Port forwarded my router on UDP port 7 to my PC
Configured BIOS (my motherboard - Intel DH67BL) to wake on LAN
I'm sending the magic packet through an android app (name: wake on lan). I used a sniffer utility on my PC to check if it was receiving the magic packet. Below is the packet details. I have a doubt here, the packet details show MAC address (as below). But, my adapter's MAC address is different. And I have set the correct MAC address while sending the magic packet. Is the app changing the MAC address before sending? Please help!
---------------------------Wake-On-LAN Magic Packet---------------------------
Time received:
09/15/12 12:13:34
UDP Header:
|-Source IP : 157.56.106.184
|-Destination IP : 192.168.1.2
|-Source Port : 3544
|-Destination Port : 52146
|-UDP Length : 117
|-UDP Checksum : 675
MAC Address:
FF FF 00 00 00 00
Raw Data (109 bytes):
00 01 00 00 8C 37 59 92 1E 68 49 48 00 00 00 34
4D 8A 27 66 D1 60 00 00 00 00 30 3A FF FE 80 00
00 00 00 00 00 80 00 F2 27 62 C7 95 47 FE 80 00
00 00 00 00 00 00 00 FF FF FF FF FF FE 86 00 64
9D 00 00 00 00 00 00 3A 98 00 00 07 D0 03 04 40
40 FF FF FF FF FF FF FF FF 00 00 00 00 20 01 00
00 9D 38 6A B8 FF 00 00 00 00 20 01 00
Thanks,
Sharath
3) Port forwarded my router on UDP port 7 to my PC
You need to forward UPD 7 and/or UDP 9 to LAN broadcast address, not to your PC's IP address.
The reason why is because when your PC is turned off, it doesn't have an IP address assigned, so the router does not have the binding with MAC address <=> IP adress in the ARP table, and can't forward the packet.
Reason: Because you don't Bind Your MAC to Your Local IP
Solution: Access to your router, use MAC Bing (or similar feature)
Note: if you use 2 or more router before your PC, you have to Mac binding and and Port forwarding on ALL router