Unable to see the LLMNR query response? - networking

I am sending the (llmnr) query over my local network, i can see the query in packet capturing tool(wire shark).But never seen/got any LLMNR response query.i have quarried for win 10 system and one hp printer.so the question is does ever LLMNR query get response because i tried to capture the LLMNR traffic in multiple networks and i have never seen any response packets
Pasting the code here :
class LLMNRQuery(Packet):
name = "Link Local Multicast Node Resolution - Query"
fields_desc = [ShortField("id", 0),
BitField("qr", 0, 1),
BitEnumField("opcode", 0, 4, {0: "QUERY"}),
BitField("c", 0, 1),
BitField("tc", 0, 2),
BitField("z", 0, 4),
BitEnumField("rcode", 0, 4, {0: "ok"}),
DNSRRCountField("qdcount", None, "qd"),
DNSRRCountField("ancount", None, "an"),
DNSRRCountField("nscount", None, "ns"),
DNSRRCountField("arcount", None, "ar"),
DNSQRField("qd", "qdcount"),
DNSRRField("an", "ancount"),
DNSRRField("ns", "nscount"),
DNSRRField("ar", "arcount", 0)]
overload_fields = {UDP: {"sport": 5355, "dport": 5355}}
bind_bottom_up(UDP, LLMNRQuery(), dport=5355)
bind_bottom_up(UDP, LLMNRQuery(), sport=5355)
bind_layers(UDP, LLMNRQuery(), sport=5355, dport=5355)
def hashret(self):
return struct.pack("!H", self.id)
def qtype_sendPacket(qname='localhost', qtype='A'):
packet = IP(src='192.168.1.10', dst="224.0.0.252")/UDP() / LLMNRQuery(id=RandShort(), qd=DNSQR(qname=qname, qtype=qtype))
send(packet, verbose=False)
##################
qtypelist = ["ANY", "AAAA", "PTR", "SRV", "A", "TXT"]
for i in qtypelist:
qtype_sendPacket('SAHAYRU', i)

Related

urequests.get cant get answer anymore

I was running code on my NodeMCU esp8266 for switching light in my fish tank according to sunset and sunrise. Today code frozen on line 8, and I spend few hours to figure out but it seems I can't find solution. I tried to add headers and proxies to
r = requests.get(url) but no success
boot.py
import network
ssid = 'SSID'
password = 'PASS'
station = network.WLAN(network.STA_IF)
station.active(True)
station.connect(ssid, password)
while station.isconnected() == False:
pass
main.py
import urequests as requests
import ujson, ntptime, utime
import ssd1306
from machine import Pin, PWM, SoftI2C
from utime import time, sleep
url = 'https://api.sunrise-sunset.org/json?lat=50.147240&lng=18.838700&formatted=0'
r = requests.get(url)
timezone_hour = 2 # timezone offset (hours)
Blue = PWM(Pin(14), 1000)
Red = PWM(Pin(12), 1000)
White_1 = PWM(Pin(13), 1000)
i2c = SoftI2C(scl=Pin(5), sda=Pin(4))
while True:
ntptime.settime()
now = utime.localtime()
day = now[0],now[1],now[2]
hours = now[3]+timezone_hour,now[4]
data = ujson.loads(r.content)
sunrise = data['results']['sunrise']
sunset = data['results']['sunset']
sunrise_time = int(sunrise[11:13])+timezone_hour, int(sunrise[14:16])
sunset_time = int(sunset[11:13])+timezone_hour, int(sunset[14:16])
hours_string = str(hours)
sunrise_time_string = str(sunrise_time)
sunset_time_string = str(sunset_time)
oled_width = 128
oled_height = 64
oled = ssd1306.SSD1306_I2C(oled_width, oled_height, i2c)
if hours > sunrise_time and hours < sunset_time:
Blue.duty(1024)
Red.duty(1024)
White_1.duty(1024)
oled.fill(0)
oled.text(hours_string, 0, 0)
oled.text(sunrise_time_string, 0, 10)
oled.text(sunset_time_string, 0, 20)
oled.text("sunrise", 0, 30)
oled.show()
print(hours_string)
else:
Blue.duty(5)
Red.duty(0)
White_1.duty(0)
oled.fill(0)
oled.text(hours_string, 0, 0)
oled.text(sunrise_time_string, 0, 10)
oled.text(sunset_time_string, 0, 20)
oled.text("sunset", 0, 30)
oled.show()
sleep(60)
if str(sunrise[0:10]) != str(day):
r = requests.get(url)
errors:
Traceback (most recent call last):
File "<stdin>", line 8, in <module>
File "urequests.py", line 116, in get
File "urequests.py", line 62, in request
OSError: -40

"You have to specify either input_ids or inputs_embeds", but I did specify the input_ids

I trained a BERT based encoder decoder model (EncoderDecoderModel) named ed_model with HuggingFace's transformers module.
I used the BertTokenizer named as input_tokenizer
I tokenized the input with:
txt = "Some wonderful sentence to encode"
inputs = input_tokenizer(txt, return_tensors="pt").to(device)
print(inputs)
The output clearly shows that a input_ids is the return dict
{'input_ids': tensor([[ 101, 5660, 7975, 2127, 2053, 2936, 5061, 102]], device='cuda:0'), 'token_type_ids': tensor([[0, 0, 0, 0, 0, 0, 0, 0]], device='cuda:0'), 'attention_mask': tensor([[1, 1, 1, 1, 1, 1, 1, 1]], device='cuda:0')}
But when I try to predict, I get this error:
ed_model.forward(**inputs)
ValueError: You have to specify either input_ids or inputs_embeds
Any ideas ?

Well, apparently this is a known issue, for example: This issue of T5
The problem is that there's probably a renaming procedure in the code, since we use a encoder-decoder architecture we have 2 types of input ids.
The solution is to explicitly specify the type of input id
ed_model.forward(decoder_input_ids=inputs['input_ids'],**inputs)
I wish it was documented somewhere, but now you know :-)

how to config CNMI to receive delivary message?

I have a d-link gsm modem (DWM-156) and i want to config CNMI to receive delivery reports after sending a text message.
The support CNMI mode on my modem returns:
+CNMI: (0-3), (0-3), (0,2,3), (0,1), (0,1)
The default mode returns:
+CNMI: 2, 1, 0, 0, 1
When i send a message i do not receive a delivery report.
I tried changing my CNMI to
2, 1, 2, 1, 0
but my sim card and d-link modem storage still have not stored any messages.
This process has worked on my (Huawei) modem that had this CNMI:
"AT+CNMI=2,1,2,2,0"
I tested these CNMI configs on my D-Link modem but it did not works
2, 1, 0, 0, 1
2, 1, 0, 1, 1
2, 1, 2, 0, 1
2, 1, 1, 1, 1
2, 1, 3, 0, 1
2, 1, 3, 1, 1

Old question but..
I am using AT+CSMS=1;+CNMI=2,1,0,1,1, have tried this on some Telit modems.
I get the SMS-STATUS-REPORT directly over the serial port, it isn't stored as such in the modem. There is no reference to a memory storage in the message, only the length of the PDU.
When I get the report it looks like this :
+CDS: 24
<pdu>
Also, when I receive a SMS-STATUS-REPORT I need to send ACKnowledge to the modem/mobile network using the AT+CNMA command.

you can try this
AT+CNMI=1,2,0,0,0

Get same output as R console in Java using JRI

When I enter the following commands directly into the R console
library("xts")
mySeries <- xts(c(1.0, 2.0, 3.0, 5.0, 6.0), order.by=c(ISOdatetime(2001, 1, 1, 0, 0, 0), ISOdatetime(2001, 1, 2, 0, 0, 0), ISOdatetime(2001, 1, 3, 0, 0, 0), ISOdatetime(2001, 1, 4, 0, 0, 0), ISOdatetime(2001, 1, 5, 0, 0, 0)))
resultingSeries <- to.monthly(mySeries)
resultingSeries
I will get an output like this
mySeries.Open mySeries.High mySeries.Low mySeries.Close
Jan 2001 1 6 1 6
When I look into the attributes, I see the following output
attributes(resultingSeries)
$dim
[1] 1 4
$dimnames
$dimnames[[1]]
NULL
$dimnames[[2]]
[1] "mySeries.Open" "mySeries.High" "mySeries.Low" "mySeries.Close"
$index
[1] 978307200
attr(,"tclass")
[1] "yearmon"
$tclass
[1] "POSIXct" "POSIXt"
$tzone
[1] ""
$class
[1] "xts" "zoo"
$.indexCLASS
[1] "yearmon"
This is the same I get in Java. I'm wondering where the magic happens so that I see the nice output I get in R. I have no access to the event loop, since I'm using JRI like this (since, it's the recommended way and simplifies error handling):
REngine engine = REngine.engineForClass("org.rosuda.REngine.JRI.JRIEngine");
REXP result = engine.parseAndEval(...)
/edit
In Java I execute each command from above as follows:
REXP result = engine.parseAndEval("resultingSeries") // or any other command
What I get is
org.rosuda.REngine.REXPDouble#4ac66122+[12]
The payload being doubles: 1, 6, 1, 6
The attributes are the same as specified above.
Now R does some magic to display the output above. Is there a way I can get the same output without having to create it manually by myself? Where's the implementation stored, that R gets the above mentioned output?

Here is a piece of code that will work, here i extracted the first element of the field mySeries.Open from the object resultingSeries (which i converted to a data frame) which is equal to 1, notice that you can't pass all of the resultingSeries object strait into Java, you will need to break it down.
package stackoverflow;
import org.rosuda.JRI.REXP;
import org.rosuda.JRI.Rengine;
/**
*
* #author yschellekens
*/
public class StackOverflow {
public static void main(String[] args) throws Exception {
String[] Rargs = {"--vanilla"};
Rengine rengine = new Rengine( Rargs, false, null);
rengine.eval("library('xts')");
rengine.eval("mySeries <- xts(c(1.0, 2.0, 3.0, 5.0, 6.0), order.by=c(ISOdatetime(2001, 1, 1, 0, 0, 0), ISOdatetime(2001, 1, 2, 0, 0, 0), ISOdatetime(2001, 1, 3, 0, 0, 0), ISOdatetime(2001, 1, 4, 0, 0, 0), ISOdatetime(2001, 1, 5, 0, 0, 0)))");
rengine.eval("resultingSeries <- to.monthly(mySeries)");
rengine.eval("resultingSeries<-as.data.frame(resultingSeries)");
REXP result= rengine.eval("resultingSeries$mySeries.Open");
System.out.println("Greeting from R: "+result.asDouble());
}
}
And the Java output:
run:
Greeting from R: 1.0

I figured out the following workaround. The solution is far from perfect.
R offers a command to save its console output as characters vector.
capture.output( {command} )
We can access the output using
REXPString s = rengine.parseAndEval("capture.output( to.monthly(mySeries))")
String[] output = result.asStrings()
The variable output will contain all output lines
[0] mySeries.Open mySeries.High mySeries.Low mySeries.Close
[1]Jan 2001 1 6 1 6
Alternatively you coud use JRIEngine and attack yourself to the event loop, which it did not want in my case (due to the more complicated error handling).

imap_client_buffer not being obeyed on nginx

I have imap_client_buffer set to 64k(as required by imap protocol) in the nginx.conf file
However when an imap client sends a very long command, post authentication, the length gets truncated at 4k(the default page size of the linux operating system)
how can i debug this problem? i have stepped through the code using gdb. as far as i can see, in mail_proxy module, the value of the conf file(120000 for testing) was correctly seen
gdb) p p->upstream.connection->data
$24 = (void *) 0x9e4bd48
(gdb) p s
$25 = (ngx_mail_session_t *) 0x9e4bd48
(gdb) p p->buffer->end
Cannot access memory at address 0x1c
(gdb) p s->buffer->end - s->buffer->last
$26 = 120000
(gdb) p s
$27 = (ngx_mail_session_t *) 0x9e4bd48
(gdb) n
205 pcf = ngx_mail_get_module_srv_conf(s, ngx_mail_proxy_module);
(gdb) n
207 s->proxy->buffer = ngx_create_temp_buf(s->connection->pool,
(gdb) p pcf
$28 = (ngx_mail_proxy_conf_t *) 0x9e3c480
(gdb) p *pcf
$29 = {enable = 1, pass_error_message = 1, xclient = 1, buffer_size = 120000,
timeout = 86400000, upstream_quick_retries = 0, upstream_retries = 0,
min_initial_retry_delay = 3000, max_initial_retry_delay = 3000,
max_retry_delay = 60000}
When the command below is sent using telnet, only 4 k of data is accepted, then nginx hangs until i hit enter on keyboard......after which the truncated command is sent to the upstream imap server.
I am using nginx 0.78, is this a known issue?
This is the command sent
HP1L UID FETCH 344990,344996,344998,345004,345006,345010:345011,345015,345020,345043,345046,345049:345050,345053,345057:345059,345071,345080,345083,345085,345090,345092:345093,345096,345101:345102,345106,345112,345117,345136,345140,345142:345144,345146:345147,345150,345161,345163,345167,345174:345176,345195,345197,345203,345205,345207:345209,345214,345218,345221,345224,345229,345231,345233,345236,345239,345248,345264,345267,345272,345285,345290,345292,345301,345305,345308,345316,345320,345322,345324,345327,345358,345375,345384,345386,345391,345409,345427:345428,345430:345432,345434:345435,345437,345439,345443,345448,345450,345463,345468:345470,345492,345494,345499,345501,345504,345506,345515:345519,345522,345525,345535,345563,345568,345574,345577,345580,345582,345599,345622,345626,345630,345632:345633,345637,345640,345647:345648,345675,345684,345686:345687,345703:345704,345714:345717,345720,345722:345724,345726,345730,345734:345737,345749,345756,345759,345783,345785:345787,345790,345806:345807,345812,345816,345720,345722:345724,345726,345730,345734:345737,345749,345756,345759,345783,345785:345787,345790,345806:345807,345812,345817,345902,345919,345953,345978,345981,345984,345990,345997,346004,346008:346009,346011:346012,346022,346039,346044,346050,346061:346062,346066:346067,346075:346076,346081,346088,346090,346093,346096,346098:346099,346110,346140,346170,346172:346174,346187,346189,346193:346194,346197,346204,346212,346225,346241,346244,346259,346323,346325:346328,346331:346332,346337:346338,346342,346346,346353,346361:346362,346364,346420,346426,346432,346447,346450:346451,346453:346454,346456:346457,346459:346460,346466:346468,346474,346476,346479,346483,346496,346498:346501,346504,346530,346539,346546,346576,346589:346590,346594:346595,346601,346607:346609,346612,346614:346615,346617:346618,346625,346631,346638,346641,346654,346657,346661,346665,346671,346687:346688,346693,346695,346734:346735,346741,346747:346748,346755,346757,346777,346779,346786:346788,346791,346793,346801,346815,346821:346822,346825,346828,346837,346839,346843,346848,346857:346858,346860,346862:346863,346866,346868:346869,346877,346883,346895:346897,346899,346923,346927,346945,346948,346961,346964:346966,346968,346970,346974,346987,346989:346990,346992,347000,347003,347008:347011,347013,347021,347028,347032:347034,347036,347049,347051,347058,347076,347079,347081,347083,347085,347092,347096,347108,347130,347145:347148,347150,347155:347158,347161,347163:347164,347181,347184,347187:347189,347204,347210:347211,347215,347217:347220,347227:347228,347234,347244,347246,347251,347253,347263:347264,347266,347268,347275,347292,347294,347304,347308,347317:347320,347322,347325:347327,347340:347341,347346,347352:347353,347357,347360:347361,347375,347379,347382:347386,347389,347392,347402,347405:347406,347411,347433:347434,347438,347440:347441,347443:347444,347448,347459:347460,347465,347468:347469,347476:347479,347490,347497,347506,347526,347530,347545,347547,347555:347556,347601:347605,347632,347634,347641,347643:347646,347649,347653,347660,347668,347676,347707,347719,347722,347724,347727:347732,347735,347746,347754,347756:347757,347761,347776,347779,347791,347798,347800,347805,347816:347817,347822,347837,347841,347843,347846,347848,347851,347879,347885,347892:347894,347903,347907:347911,347915:347916,347918,347950,347952:347953,347981,347986:347988,348001,348037:348038,348049,348052,348056:348058,348061,348072,348074,348077:348078,348080,348082,348100,348105,348109,348111:348116,348119:348123,348131:348132,348138,348150:348151,348153,348157,348161:348163,348166,348168:348169,348171,348173,348176,348178,348180:348181,348201,348204,348208,348218:348219,348222,348226,348229:348230,348235,348238:348240,348244:348247,348249,348251:348253,348256:348257,348263,348285,348288:348289,348293,348298:348299,348301:348302,348305:348306,348310,348327,348332:348337,348340,348342,348344,348348,348351:348353,348356:348357,348360,348366,348377,348386,348390,348398,348400:348401,348406:348407,348419,348422,348424,348427:348428,348430,348432:348433,348439,348444,348447:348448,348450:348451,348454,348456,348459:348460,348473,348493,348497:348498,348504,348506,348508,348516,348520,348527,348530,348532,348546:348547,348551,348560:348563,348567,348570:348572,348574,348577,348581,348588,348595,348610,348632,348636,348642,348646,348667,348672:348673,348679,348703,348713:348714,348716,348718:348722,348728:348729,348731,348735,348743:348745,348749,348751:348752,348759,348768,348773,348780:348781,348784:348791 (UID FLAGS)

Resources