I have read the RFC1928 several times and still couldn't understand what a compliant SOCKS 5 server is supposed to reply in case of failure. This doubt comes from the fact that the ATYP, BND.ADDR and BND.PORT fields from a SOCKS reply simply don't make sense if, for instance, a request with an invalid command is received. Must the server not send these fields or just send blanks?
I just red putty source code, and found out that, when there is an error in reply (REP != 0) ATYP is IPv4 (1) BND.ADDR and BND.PORT are all NULL bytes.
I guess this behavior helps developpers to parse requests ?
In a failure reply, only the VER and REP fields are meaningful. The other fields may be present but are not used. You don't even need to look at those bytes unless REP is zero.
Related
I am using spring-amqp and testing RabbitListener#AcknowledgeMode.
When i set RabbitListener#AcknowledgeMode#AUTO,I triggered the nack reponse by thorwing a exception in my RabbitListener.
When i set defaultRequeueRejected to true(it means message will requeue), package by wireshark:
It looks like the last two bits represent these two properties.
And When i set defaultRequeueRejected to false(it means message will not requeue), package by wireshark:
Requeue should be false.So is this a wireshark bug? Or do I understand something wrong?
It looks like a wireshark bug to me 0x03 Vs. 0x01.
I just looked at the code in the client lib and the multiple bit is the LSB and the requeued bit is the next bit.
I'm trying to securely connect ESP8266 to MQTT Azure Protocol Gateway broker on cloud or local computer (tried both) like this (not important - connection works correctly):
m = mqtt.Client("{deviceId}", "3600", "{iotHub}/{deviceId}", "{SASToken}")
...
m:on("message", function(conn, top, data)
print(data) -- EMPTY string here!
end)
...
m:connect({IP}, 8883, 1, function(conn)
m:subscribe("devices/{deviceId}/messages/devicebound/#", 1, function(conn)
...
end)
end)
ESP connects to server and handshake is completed successfully. When I publish some data, I can read it on server properly, it is OK. I subscribe to topic without problems. When I send data in cloud-to-device message from server to ESP to subscribed topic, 'on message' event is called but data attribute passed to the function is EMPTY string.
I'm using latest NodeMCU master build based on 1.4.0 SDK (tried both integer and float version). I can't turn on debugging, because i don't have NodeMCU developer yet.
I tried following:
dev version - not help
free memory up to 32kB - not help
captured packets with WireShark: packets contain encrypted data with some lenght, so it is not empty and packet size is less than 2kB buffer size
Can someone please advise me where could be a problem or how to debug it for more info? I would approciate any ideas. Thank you.
EDIT:
I've tried debug mode, and there is nothing interesting on output:
enter mqtt_socket_received.
MQTT_DATA: type: 3, qos: 0, msg_id: 0, pending_id: 0
enter deliver_publish.
string
userdata: 3fff3e88
devices/ESP/messages/devicebound
<- here should be printed data
On
leave deliver_publish.
receive, queue size: 0
leave mqtt_socket_received.
enter mqtt_socket_timer.
timer, queue size: 0
keep_alive_tick: 71
leave mqtt_socket_timer.
enter mqtt_socket_received.
MQTT_DATA: type: 7, qos: 1, msg_id: 8813, pending_id: 0
receive, queue size: 0
leave mqtt_socket_received.
This may be stupid but sometimes lua expects specific names in some functions.
Change this
function(conn, top, data)
for this
function(conn, topic, data)
I have worked previously with mqtt in lua with password protection, and i had to drop it beacuse i wasnt recieving the message content either, however i think mine was due to the amount of messages i was recieving/delivering. I also changed broker from mosquitto to mosca.
I hope you find a fix soon and please share it we might be able to use it to :)
I have to send HL7 message to web service. I am adding CHAR(13) (carriage return or \r) as segment terminator in stored procedure and calling a web service to send the HL7 message. When the service receives the message they are saying I am adding extra CHAR(10) (line feed or \n ) in my segment terminators. I have looked into my values and just before sending it only has \r as segment terminators. How to make sure that the service also receives it as only \r without extra \n. I have looked around but haven't found any solution so far.
Have you looked at the message in Fiddler or TCP Spy depending on how you are sending your message?
It will at least prove if you are providing anything other than the /r
I've been caught by messages having multiple ways of breaking the line. \r, \n and also a combo of the 2.
Have you tried redirecting the message to somewhere you can actually read yourself at different stages of the processing? It's getting changed somewhere and reading it out at different stages caught the error for me. Or just a series of the below at different stages.
content = hl7message.read()
if "\n" in content:
print "ERROR"
I posted this to the Squeak Beginners list too - I'll be sure to make sure any answers from there get here :)
I'm using Squeak 4.2 and working on the smalltalk end of a named pipe connection, which sends a message to the named pipe server with:
msg := 'Here''s Johnny!!!!'.
pipe nextPutAll: msg; flush.
It should then receive an acknowledgement, which will be a 32-byte md5 hash of the received message (which the smalltalk app can then verify). It's possible the named pipe server may have gone away or otherwise been unable to deal with the request, and so I'd like to set a timeout on reading the acknowledgement. I've tried using this:
ack := [ pipe next: 32 ] valueWithin: (Duration seconds: 3) onTimeout: [ 'timeout'. ].
and then made the pipe server pause artificially to test the code. But the smalltalk thread blocks on the read and doesn't carry on (even after the timeout), although if I then get the pipe server to send the correct response (after a 5 second delay, for example), the value of 'ack' is 'timeout'. Obviously the timeout did what it's supposed to do, but couldn't 'unblock' the blocking read on the pipe.
Is there a way to accomplish this even with a blocking FileStream read? I'd rather avoid a busy wait on there being 32 characters available if at all possible.
This one may come in handy but not on Windows I am afraid.
http://www.samadhiweb.com/blog/2013.07.27.unixdomainsockets.html
I know that using * in IMAP FETCH Command either defines all or one mail but does
"*:*" also defines all mails in the selected folder? Does it defines something else too? Asking cause my company is implementing its own IMAP server, and I couldn't find any reference to *:* in the RFC 3501 and 4466.
If possible, please also cite the RFC.
* does not mean all mail. As a number, * means "the last message in the folder". More generally, 42 means "message 42", 42:50 means "messages 42 to 50 inclusive", 42:* "messages 42 to the last one", and * means "the last message", see? *:* is another way to say "just the last message".
But *.* doesn't mean anything in particular. I can't think of any case where that is even syntactically valid.
: would mean just the last message. You can check for rfc 791. Check www.tools.ietf.org