Cannot send a SMS with gammu (error 500, message reference=-1) - gsm
I've been playing with gammu and Huawei USB modem:
lsusb | grep Huawei
Bus 001 Device 006: ID 12d1:1001 Huawei Technologies Co., Ltd. E169/E620/E800 HSDPA Modem
The modem is capable of receiving SMS, but sending does not work.
Problematic command
gammu sendsms TEXT 728123456 -text "text"
If you want break, press Ctrl+C...
Sending SMS 1/1....waiting for network answer..error 500, message reference=-1
Unknown error.
gammu monitor
According to monitor, signal and other info about network, etc. are fine.
SIM phonebook : 12 used, 238 free
Dialled numbers : 0 used, 10 free
Received numbers : 0 used, 10 free
Missed numbers : 0 used, 10 free
Own numbers : 0 used, 4 free
Phone phonebook : 0 used, 100 free
Battery level : 100 percent
Charge state : powered from battery
Signal strength : -73 dBm
Network level : 60 percent
SIM SMS status : 3 used, 0 unread, 10 locations
Phone SMS status : 0 used, 0 unread, 255 locations
Network state : home network
Network : 230 02 (O2, Czech Republic), LAC 1, CID
Name in phone : "EUROTEL - CZ"
Packet network state : home network
Packet network : 230 02 (O2, Czech Republic), LAC , CID
Name in phone : "EUROTEL - CZ"
GPRS : attached
SIM phonebook : 12 used, 238 free
Dialled numbers : 0 used, 10 free
Received numbers : 0 used, 10 free
Missed numbers : 0 used, 10 free
Own numbers : 0 used, 4 free
Phone phonebook : 0 used, 100 free
Battery level : 100 percent
Charge state : powered from battery
Signal strength : -73 dBm
Network level : 60 percent
SIM SMS status : 3 used, 0 unread, 10 locations
Phone SMS status : 0 used, 0 unread, 255 locations
Network state : home network
Network : 230 02 (O2, Czech Republic), LAC 1, CID
Name in phone : "EUROTEL - CZ"
Packet network state : home network
Packet network : 230 02 (O2, Czech Republic), LAC , CID
Name in phone : "EUROTEL - CZ"
GPRS : attached
Following output is provided by gammu log file with textall Logformat.
gammu log
[Gammu - 1.37.0]
[Connection - "at"]
[Connection index - 0]
[Model type - ""]
[Device - "/dev/ttyUSB0"]
[Running on - Linux, kernel 4.5.2-1-default (#1 SMP PREEMPT Thu Apr 21 09:07:52 UTC 2016 (0454a6e))]
Serial device: DTR is up, RTS is up, CAR is down, CTS is up
Setting speed to 115200
[Module - "auto"]
Escaping SMS mode
SENDING frame type 0x00/length 0x02/2
1B |0D ..
Sending simple AT command to wake up some devices
SENDING frame type 0x00/length 0x03/3
41A|54T|0D AT.
1 "AT"
2 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x09/9
41A|54T|0D |0D |0A |4FO|4BK|0D |0A AT...OK..
Enabling echo
SENDING frame type 0x00/length 0x05/5
41A|54T|45E|311|0D ATE1.
1 "ATE1"
2 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x0B/11
41A|54T|45E|311|0D |0D |0A |4FO|4BK|0D |0A ATE1...OK..
Trying Motorola mode switch
SENDING frame type 0x00/length 0x0A/10
41A|54T|2B+|4DM|4FO|44D|45E|3D=|322|0D AT+MODE=2.
1 "AT+MODE=2"
2 "ERROR"
Checking line: ERROR
AT reply state: 3
RECEIVED frame type 0x00/length 0x13/19
41A|54T|2B+|4DM|4FO|44D|45E|3D=|322|0D |0D |0A |45E|52R|52R|4FO AT+MODE=2...ERRO
52R|0D |0A R..
Seems not to be supported
Enabling CME errors
SENDING frame type 0x00/length 0x0A/10
41A|54T|2B+|43C|4DM|45E|45E|3D=|311|0D AT+CMEE=1.
1 "AT+CMEE=1"
2 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x10/16
41A|54T|2B+|43C|4DM|45E|45E|3D=|311|0D |0D |0A |4FO|4BK|0D |0A AT+CMEE=1...OK..
SENDING frame type 0x00/length 0x09/9
41A|54T|2B+|43C|53S|43C|53S|3F?|0D AT+CSCS?.
1 "AT+CSCS?"
2 "+CSCS: "UCS2""
3 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x20/32
41A|54T|2B+|43C|53S|43C|53S|3F?|0D |0D |0A |2B+|43C|53S|43C|53S AT+CSCS?...+CSCS
3A:|20 |22"|55U|43C|53S|322|22"|0D |0A |0D |0A |4FO|4BK|0D |0A : "UCS2"....OK..
SENDING frame type 0x00/length 0x0A/10
41A|54T|2B+|43C|53S|43C|53S|3D=|3F?|0D AT+CSCS=?.
1 "AT+CSCS=?"
2 "+CSCS: ("IRA","GSM","UCS2")"
3 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x2F/47
41A|54T|2B+|43C|53S|43C|53S|3D=|3F?|0D |0D |0A |2B+|43C|53S|43C AT+CSCS=?...+CSC
53S|3A:|20 |28(|22"|49I|52R|41A|22"|2C,|22"|47G|53S|4DM|22"|2C, S: ("IRA","GSM",
22"|55U|43C|53S|322|22"|29)|0D |0A |0D |0A |4FO|4BK|0D |0A "UCS2")....OK..
Chosen GSM as normal charset
Chosen UCS2 as unicode charset
SENDING frame type 0x00/length 0x0E/14
41A|54T|2B+|43C|53S|43C|53S|3D=|22"|47G|53S|4DM|22"|0D AT+CSCS="GSM".
1 "AT+CSCS="GSM""
2 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x14/20
41A|54T|2B+|43C|53S|43C|53S|3D=|22"|47G|53S|4DM|22"|0D |0D |0A AT+CSCS="GSM"...
4FO|4BK|0D |0A OK..
SENDING frame type 0x00/length 0x09/9
41A|54T|2B+|43C|53S|43C|53S|3F?|0D AT+CSCS?.
1 "AT+CSCS?"
2 "+CSCS: "GSM""
3 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x1F/31
41A|54T|2B+|43C|53S|43C|53S|3F?|0D |0D |0A |2B+|43C|53S|43C|53S AT+CSCS?...+CSCS
3A:|20 |22"|47G|53S|4DM|22"|0D |0A |0D |0A |4FO|4BK|0D |0A : "GSM"....OK..
Getting model
SENDING frame type 0x00/length 0x08/8
41A|54T|2B+|43C|47G|4DM|4DM|0D AT+CGMM.
1 "AT+CGMM"
2 "E1750"
3 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x17/23
41A|54T|2B+|43C|47G|4DM|4DM|0D |0D |0A |45E|311|377|355|300|0D AT+CGMM...E1750.
0A |0D |0A |4FO|4BK|0D |0A ...OK..
[Model name: `E1750']
[Model data: `E1750']
[Model data: `E1750']
[Connected model - "E1750"]
SENDING frame type 0x00/length 0x08/8
41A|54T|2B+|43C|47G|4DM|49I|0D AT+CGMI.
1 "AT+CGMI"
2 "QUALCOMM INCORPORATED"
3 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x27/39
41A|54T|2B+|43C|47G|4DM|49I|0D |0D |0A |51Q|55U|41A|4CL|43C|4FO AT+CGMI...QUALCO
4DM|4DM|20 |49I|4EN|43C|4FO|52R|50P|4FO|52R|41A|54T|45E|44D|0D MM INCORPORATED.
0A |0D |0A |4FO|4BK|0D |0A ...OK..
Manufacturer info received
[Manufacturer: Qualcomm]
Checking for OBEX support
SENDING frame type 0x00/length 0x0B/11
41A|54T|2B+|43C|50P|52R|4FO|54T|3D=|3F?|0D AT+CPROT=?.
1 "AT+CPROT=?"
2 "ERROR"
Checking line: ERROR
AT reply state: 3
RECEIVED frame type 0x00/length 0x14/20
41A|54T|2B+|43C|50P|52R|4FO|54T|3D=|3F?|0D |0D |0A |45E|52R|52R AT+CPROT=?...ERR
4FO|52R|0D |0A OR..
Checking for SYNCML/OBEX support
SENDING frame type 0x00/length 0x0C/12
41A|54T|2B+|53S|59Y|4EN|43C|4DM|4CL|3D=|3F?|0D AT+SYNCML=?.
1 "AT+SYNCML=?"
2 "ERROR"
Checking line: ERROR
AT reply state: 3
RECEIVED frame type 0x00/length 0x15/21
41A|54T|2B+|53S|59Y|4EN|43C|4DM|4CL|3D=|3F?|0D |0D |0A |45E|52R AT+SYNCML=?...ER
52R|4FO|52R|0D |0A ROR..
SENDING frame type 0x00/length 0x0D/13
41A|54T|24$|54T|53S|53S|50P|43C|53S|57W|3D=|3F?|0D AT$TSSPCSW=?.
1 "AT$TSSPCSW=?"
2 "ERROR"
Checking line: ERROR
AT reply state: 3
RECEIVED frame type 0x00/length 0x16/22
41A|54T|24$|54T|53S|53S|50P|43C|53S|57W|3D=|3F?|0D |0D |0A |45E AT$TSSPCSW=?...E
52R|52R|4FO|52R|0D |0A RROR..
[Module - "A2D|iPAQ|at|M20|S25|MC35|TC35|C35i|S65|S300|5110|5130|5190|5210|6110|6130|6150|6190|6210|6250|6310|6310i|6510|7110|8210|8250|8290|8310|8390|8850|8855|8890|8910|9110|9210"]
Escaping SMS mode
SENDING frame type 0x00/length 0x02/2
1B |0D ..
Sending simple AT command to wake up some devices
SENDING frame type 0x00/length 0x03/3
41A|54T|0D AT.
1 "AT"
2 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x09/9
41A|54T|0D |0D |0A |4FO|4BK|0D |0A AT...OK..
Enabling echo
SENDING frame type 0x00/length 0x05/5
41A|54T|45E|311|0D ATE1.
1 "ATE1"
2 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x0B/11
41A|54T|45E|311|0D |0D |0A |4FO|4BK|0D |0A ATE1...OK..
Trying Motorola mode switch
SENDING frame type 0x00/length 0x0A/10
41A|54T|2B+|4DM|4FO|44D|45E|3D=|322|0D AT+MODE=2.
1 "AT+MODE=2"
2 "ERROR"
Checking line: ERROR
AT reply state: 3
RECEIVED frame type 0x00/length 0x13/19
41A|54T|2B+|4DM|4FO|44D|45E|3D=|322|0D |0D |0A |45E|52R|52R|4FO AT+MODE=2...ERRO
52R|0D |0A R..
Seems not to be supported
Enabling CME errors
SENDING frame type 0x00/length 0x0A/10
41A|54T|2B+|43C|4DM|45E|45E|3D=|311|0D AT+CMEE=1.
1 "AT+CMEE=1"
2 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x10/16
41A|54T|2B+|43C|4DM|45E|45E|3D=|311|0D |0D |0A |4FO|4BK|0D |0A AT+CMEE=1...OK..
SENDING frame type 0x00/length 0x09/9
41A|54T|2B+|43C|53S|43C|53S|3F?|0D AT+CSCS?.
1 "AT+CSCS?"
2 "+CSCS: "GSM""
3 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x1F/31
41A|54T|2B+|43C|53S|43C|53S|3F?|0D |0D |0A |2B+|43C|53S|43C|53S AT+CSCS?...+CSCS
3A:|20 |22"|47G|53S|4DM|22"|0D |0A |0D |0A |4FO|4BK|0D |0A : "GSM"....OK..
SENDING frame type 0x00/length 0x0A/10
41A|54T|2B+|43C|53S|43C|53S|3D=|3F?|0D AT+CSCS=?.
1 "AT+CSCS=?"
2 "+CSCS: ("IRA","GSM","UCS2")"
3 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x2F/47
41A|54T|2B+|43C|53S|43C|53S|3D=|3F?|0D |0D |0A |2B+|43C|53S|43C AT+CSCS=?...+CSC
53S|3A:|20 |28(|22"|49I|52R|41A|22"|2C,|22"|47G|53S|4DM|22"|2C, S: ("IRA","GSM",
22"|55U|43C|53S|322|22"|29)|0D |0A |0D |0A |4FO|4BK|0D |0A "UCS2")....OK..
Chosen GSM as normal charset
Chosen UCS2 as unicode charset
SENDING frame type 0x00/length 0x08/8
41A|54T|2B+|43C|47G|4DM|49I|0D AT+CGMI.
1 "AT+CGMI"
2 "QUALCOMM INCORPORATED"
3 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x27/39
41A|54T|2B+|43C|47G|4DM|49I|0D |0D |0A |51Q|55U|41A|4CL|43C|4FO AT+CGMI...QUALCO
4DM|4DM|20 |49I|4EN|43C|4FO|52R|50P|4FO|52R|41A|54T|45E|44D|0D MM INCORPORATED.
0A |0D |0A |4FO|4BK|0D |0A ...OK..
Manufacturer info received
[Manufacturer: Qualcomm]
Checking for OBEX support
SENDING frame type 0x00/length 0x0B/11
41A|54T|2B+|43C|50P|52R|4FO|54T|3D=|3F?|0D AT+CPROT=?.
1 "AT+CPROT=?"
2 "ERROR"
Checking line: ERROR
AT reply state: 3
RECEIVED frame type 0x00/length 0x14/20
41A|54T|2B+|43C|50P|52R|4FO|54T|3D=|3F?|0D |0D |0A |45E|52R|52R AT+CPROT=?...ERR
4FO|52R|0D |0A OR..
Checking for SYNCML/OBEX support
SENDING frame type 0x00/length 0x0C/12
41A|54T|2B+|53S|59Y|4EN|43C|4DM|4CL|3D=|3F?|0D AT+SYNCML=?.
1 "AT+SYNCML=?"
2 "ERROR"
Checking line: ERROR
AT reply state: 3
RECEIVED frame type 0x00/length 0x15/21
41A|54T|2B+|53S|59Y|4EN|43C|4DM|4CL|3D=|3F?|0D |0D |0A |45E|52R AT+SYNCML=?...ER
52R|4FO|52R|0D |0A ROR..
SENDING frame type 0x00/length 0x0D/13
41A|54T|24$|54T|53S|53S|50P|43C|53S|57W|3D=|3F?|0D AT$TSSPCSW=?.
1 "AT$TSSPCSW=?"
2 "ERROR"
Checking line: ERROR
AT reply state: 3
RECEIVED frame type 0x00/length 0x16/22
41A|54T|24$|54T|53S|53S|50P|43C|53S|57W|3D=|3F?|0D |0D |0A |45E AT$TSSPCSW=?...E
52R|52R|4FO|52R|0D |0A RROR..
Setting date & time
SENDING frame type 0x00/length 0x21/33
41A|54T|2B+|43C|43C|4CL|4BK|3D=|22"|322|300|311|366|2F/|300|355 AT+CCLK="2016/05
2F/|311|311|2C,|311|311|3A:|322|355|3A:|322|333|2B+|300|311|22" /11,11:25:23+01"
0D .
1 "AT+CCLK="2016/05/11,11:25:23+01""
2 "ERROR"
Checking line: ERROR
AT reply state: 3
RECEIVED frame type 0x00/length 0x2A/42
41A|54T|2B+|43C|43C|4CL|4BK|3D=|22"|322|300|311|366|2F/|300|355 AT+CCLK="2016/05
2F/|311|311|2C,|311|311|3A:|322|355|3A:|322|333|2B+|300|311|22" /11,11:25:23+01"
0D |0D |0A |45E|52R|52R|4FO|52R|0D |0A ...ERROR..
Getting firmware versions
SENDING frame type 0x00/length 0x08/8
41A|54T|2B+|43C|47G|4DM|52R|0D AT+CGMR.
1 "AT+CGMR"
2 "SSD_M6281A-0.0.1 1 [Oct 02 2008 07:00:00]"
3 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x3E/62
41A|54T|2B+|43C|47G|4DM|52R|0D |0D |0A |53S|53S|44D|5F_|4DM|366 AT+CGMR...SSD_M6
322|388|311|41A|2D-|300|2E.|300|2E.|311|20 |20 |20 |311|20 |20 281A-0.0.1 1
5B[|4FO|63c|74t|20 |300|322|20 |322|300|300|388|20 |300|377|3A: [Oct 02 2008 07:
300|300|3A:|300|300|5D]|0D |0A |0D |0A |4FO|4BK|0D |0A 00:00]....OK..
Received firmware version: "SSD_M6281A-0.0.1 1 [Oct 02 2008 07:00:00]"
Number version is "62810.011022"
[Firmware version - "SSD_M6281A-0.0.1 1 [Oct 02 2008 07:00:00]"]
[Connected]
Checking used: UDH len 0, UsedBytes 0, FreeText 160, UsedText 0, FreeBytes 140
Adding text
Copy 160 (max 4)
Defalt text, length 4 4
Text added
Checking at the end: UDH len 0, UsedBytes 4, FreeText 156, UsedText 4, FreeBytes 136
4 4
Entering GSM_GetSMSC
Getting SMSC
SENDING frame type 0x00/length 0x09/9
41A|54T|2B+|43C|53S|43C|41A|3F?|0D AT+CSCA?.
1 "AT+CSCA?"
2 "+CSCA: "+85290000000",145"
3 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x2C/44
41A|54T|2B+|43C|53S|43C|41A|3F?|0D |0D |0A |2B+|43C|53S|43C|41A AT+CSCA?...+CSCA
3A:|20 |22"|2B+|388|355|322|399|300|300|300|300|300|300|300|22" : "+85290000000"
2C,|311|344|355|0D |0A |0D |0A |4FO|4BK|0D |0A ,145....OK..
SMSC info received
Parsing +CSCA: "+85290000000",145 with +CSCA: #p, #i
Grabbed string from reply: "+85290000000" (parsed 14 bytes)
Parsed phone string "+85290000000"
Phone string decoded as "+85290000000"
Parsed int 145
Leaving GSM_GetSMSC
Entering GSM_SendSMS
Trying SMS PDU mode
SENDING frame type 0x00/length 0x0A/10
41A|54T|2B+|43C|4DM|47G|46F|3D=|300|0D AT+CMGF=0.
1 "AT+CMGF=0"
2 "OK"
Checking line: OK
AT reply state: 1
RECEIVED frame type 0x00/length 0x10/16
41A|54T|2B+|43C|4DM|47G|46F|3D=|300|0D |0D |0A |4FO|4BK|0D |0A AT+CMGF=0...OK..
SMS Submit
Recipient number "728119904"
SMSC number "+85290000000"
SMS class -1
SMS validity ff
TPMR: 00 0
7 bit SMS, length 4, 4
text
Waiting for modem prompt
SENDING frame type 0x00/length 0x0B/11
41A|54T|2B+|43C|4DM|47G|53S|3D=|311|377|0D AT+CMGS=17.
1 "AT+CMGS=17"
2 "> "
Checking line: >
AT reply state: 7
RECEIVED frame type 0x00/length 0x0F/15
41A|54T|2B+|43C|4DM|47G|53S|3D=|311|377|0D |0D |0A |3E>|20 AT+CMGS=17...>
Sending SMS
SENDING frame type 0x00/length 0x32/50
300|377|399|311|355|388|399|322|300|300|300|300|300|300|46F|300 07915892000000F0
311|311|300|300|300|399|388|311|322|377|311|388|399|311|300|399 1100098127189109
46F|344|300|300|300|300|46F|46F|300|344|46F|344|333|322|399|45E F40000FF04F4329E
300|45E 0E
SENDING frame type 0x00/length 0x01/1
1A .
Leaving GSM_SendSMS
1 "AT+CMGS=17"
2 "> 07915892000000F01100098127189109F40000FF04F4329E0E"
3 "+CMS ERROR: 500"
Checking line: +CMS ERROR: 500
AT reply state: 5
RECEIVED frame type 0x00/length 0x56/86
41A|54T|2B+|43C|4DM|47G|53S|3D=|311|377|0D |0D |0A |3E>|20 |300 AT+CMGS=17...> 0
377|399|311|355|388|399|322|300|300|300|300|300|300|46F|300|311 7915892000000F01
311|300|300|300|399|388|311|322|377|311|388|399|311|300|399|46F 100098127189109F
344|300|300|300|300|46F|46F|300|344|46F|344|333|322|399|45E|300 40000FF04F4329E0
45E|0D |0A |0D |0A |2B+|43C|4DM|53S|20 |45E|52R|52R|4FO|52R|3A: E....+CMS ERROR:
20 |355|300|300|0D |0A 500..
Error 500
Sent SMS on device: "/dev/ttyUSB0"
CMS Error 500: "unknown error"
[Terminating]
[Closing]
Thanks,
Martin
So the problem was caused by wrong phone number of my operator's SMS center.
After that, gammu works fine:
If you want break, press Ctrl+C...
Sending SMS 1/1....waiting for network answer..OK, message reference=207
Same error message is caused if the recipient's phone number is invalid. In my country the operator does not accept anything else but numbers, so having dash or whitespace or slashes throw the same error message.
Gammu has been working on my raspberry since 2018 with a 3G-dongle huawei E169. It was along, not connected to any network. He sent and received sms even after a reboot.
Since mid October it stopped working... no more sms in or out. I tested the SIM card with my operator (Free) and it looks ok. I know that 2G-network is almost stopped but my dongle is supposed to be 3G...
I'm now try to make it run on another raspberry3. I start install from stratch and now it looks like :
> sudo gammu identify
Device : /dev/ttyUSB-3G
Manufacturer : Huawei
Model : E169 (E169)
Firmware : 11.314.09.50.00
IMEI : 353xxx
SIM IMSI : 20xxx
Everything looks ok but when i send a sms i get this error :
> gammu -d textall -f /home/pi/TraceSms sendsms TEXT 06xx -text « coucou »
If you want break, press Ctrl+C…
Sending SMS 1/1…waiting for network answer…error 500, message reference=-1
Unknown error.
I got a 394 lines trace with an error but I'm not able to understand... Any help ?
Merci beaucoup ;-)
Related
Deconstructing BPF filter in TCPdump
Trying to deconstruct this TCPdump BPF style filter, and need some help: 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420' Its taken from here Steps that have taken to better understand what is going on: 1. Lets convert the 0x47455420 to ascii ===> GET ===> tcp[((tcp[12:1] & 0xf0) >> 2):4] = GET 2. Examine the inner tcp filter: (tcp[12:1] & 0xf0) ===> the 0xf0 == 0000 0000 1111 0000 ===> I suppose it is save to discard the upper zeros so I can write 1111 0000 ===> tcp[12:1] == 08 (start filtering from byte 13 (0 based indexing, so you could also say start with the byte that has index 12) for 1 byte, so only 13th byte); ===> 08 == 0000 1000 ===> 0000 1000 & 1111 0000 == 0000 (bitwise and = if both are 1 then end result is one) This is where I got confused. The explanation in the hyperlink I provided above is saying multiply it by four ( (tcp[12:1] & 0xf0)>>2 ) which should give the tcp header length Impossible if it is zero. Please: help me find the mistake in my calculations (maybe I'm mixing TCP and IP headers?); provide some guidance whether my logic is correct. This is the packet: 19:10:30.091065 IP (tos 0x0, ttl 63, id 40127, offset 0, flags [DF], proto TCP (6), length 2786) 10.240.35.81.47856 > 172.17.13.201.8080: Flags [P.], cksum 0xf2ef (incorrect -> 0xb8f8), seq 2263020471:2263023205, ack 4187927811, win 28, options [nop,nop,TS val 1906863883 ecr 214445688], length 2734 0x0000: 1a17 8e8a a3a0 026d 627d 049c 0800 4500 .......mb}....E. 0,1 2,3 ... ... ... ... 12,13 ... <=== byte indexes 1,2 3,4 ... ... ... ... 13,14 ... <=== counting how many bytes 0x0010: 0ae2 9cbf 4000 3f06 ac3b 0af0 2351 ac11 ....#.?..;..#Q.. <=== 0x0010 number correctly identifies that the first two diggits are the 16th byte 16,17 ... ... 0x0020: 0dc9 baf0 1f90 86e2 f3b7 f99e b503 8018 ................ 0x0030: 001c f2ef 0000 0101 080a 71a8 6f0b 0cc8 ..........q.o... 0x0040: 2e78 4745 5420 2f69 636f 6e73 2f75 6e6b .xGET./icons/unk 0x0050: 6e6f 776e 2e67 6966 2048 5454 502f 312e nown.gif.HTTP/1. 0x0060: 310d 0a68 6f73 743a 2070 6870 2d6d 696e 1..host:.php-min
tcp[12:1] is the byte at an offset of 12 bytes from the beginning of the TCP header; the 12 is not the offset from the beginning of the packet, it's the offset from the beginning of the TCP header (it's tcp[12:1], not ether[12:1] or something such as that). The "1" is the number of bytes being referred to. According to RFC 793, which is the specification for TCP, the byte at an offset of 12 bytes from the beginning of the TCP header contains the data offset in the upper 4 bits and the lower 4 bits are reserved bits. The data offset is "The number of 32 bit words in the TCP Header", which "indicates where the data begins". The data in the packet is being displayed as a sequence of byte pairs. It's a bit easier to understand if presented as a sequence of individual bytes, so: 0x0000: 1a 17 8e 8a a3 a0 02 6d 62 7d 04 9c 08 00 45 00 eth dest eth src etype IP hdr The first 6 bytes of the packet are the Ethernet destination address. The next 6 bytes of the packet are the Ethernet source address. The 2 bytes after that are the Ethernet type value; it's big-endian, so its value is 0x0800, which is the Ethernet type value for IPv4. The next 2 bytes are the first 2 bytes of the IPv4 header. According to RFC 791, which is the specification for IPv4, the first byte of the IPv4 header contains the IP version in the upper 4 bits and the header length in the lower 4 bits. That byte has a value of 0x45, so the IP version is 4 (as it should be, for IPv4) and the header length is 5. The header length "is the length of the internet header in 32 bit words", so that's 5 32-bit words, or 20 bytes. So, for now, let's skip the IPv4 header and go to the TCP header: 0x0020: 0d c9 ba f0 1f 90 86 e2 f3 b7 f9 9e b5 03 80 18 TCP header 12 13 So byte 12 of the TCP header is 0x80. 0x80 & 0xf0 is 0x80, and 0x80 >> 2 is 0x20, which is 32; this is consistent with the upper 4 bits of that byte being the data offset, in 32-bit words, as 8*4 = 32. tcp[((tcp[12:1] & 0xf0) >> 2):4] is thus, for this packet, tcp[32:4], i.e. the 4 bytes at an offset of 32 from the beginning of the TCP header. 32 bytes from the beginning of the TCP header is: 0x0040: 2e78 4745 5420 2f69 636f 6e73 2f75 6e6b ^ there, and that's the "GET" header of the HTTP request, beginning at the beginning of the TCP segment data. Te 4 bytes in question are "GET ". So the 12 in tcp[12:1] is not the offset from the beginning of the packet, it's the offset from the beginning of the TCP header (it's tcp[12:1], not ether[12:1] or something such as that). And, in answer to the questions about the bytes of the packet and what they are: 0x0000: 1a 17 8e 8a a3 a0: Ethernet destination 02 6d 62 7d 04 9c: Ethernet source 08 00: Ethernet type/length field - 0x0800 = IPv4 So the first 14 (0x000e) bytes of the packet are the Ethernet header. In this packet, the Ethernet type/length field is 0x0800, so the Ethernet payload, following the Ethernet header, is an IPv4 packet, beginning with an IPv4 header: 45: IPv4 version/header length 00: IPv4 Type of Service/Differentiated Service 0x0010: 0a e2: IPv4 total length 9c bf: IPv4 identification 40 00: IPv4 flags/fragment offset 3f: IPv4 time-to-live 06: IPv4 (next) protocol - 6 = TCP ac 3b: IPv4 header checksum 0a f0 23 51: IPv4 source address ac 11: first 2 bytes of IPv4 destination address 0x0020: 0d c9: second 2 bytes of IPv4 destination address The IPv4 header length is 5, so the IPv4 header is 20 bytes. That's the minimum IPv4 header length; it can't be smaller, but it can be larger, if there are IPv4 options after the fixed-length part of the header. There aren't any, in this case. As the protocol field has the value 6, the IPv4 payload is a TCP packet: ba f0: TCP source port (47856) 1f 90: TCP destination port (8080) 86 e2 f3 b7: TCP sequence number f9 9e b5 03: TCP acknowledgment number 80: TCP data offset + reserved bits 18: reserved bits + TCP flags 0x0030: 00 1c: TCP window f2 ef: TCP checksum 00 00: TCP urgent pointer That's the 20-byte fixed-length portion of the TCP header; however, the TCP header length is 32 bytes, so there are an additional 12 bytes of TCP options in the header: 01: TCP No-Operation option 01: TCP No-Operation option 08 0a 71 a8 6f 0b 0c c8: first 8 bytes of TCP Timestamp option 0x0040: 2e 78: last 2 bytes of TCP Timestamp option A TCP header's length must be a multiple of 32 bits, i.e. a multiple of 4 bytes; TCP options might not be a multiple of 4 in length - the TCP Timestamp option is 10 bytes long - so the No-Operation option is used for padding. So those 32 bytes were the TCP header; what follows is the TCP payload. Apparently, this is on an HTTP connection (the packet is being sent to port 8080, which is an alternate HTTP port), and this is the beginning of an HTTP GET request: 47 45 54 20 2f 69 63 6f 6e 73 2f 75 6e 6b 0x0050: 6e 6f 77 6e 2e 67 69 66 20 48 54 54 50 2f 31 2e 0x0060: 31 0d 0a 68 6f 73 74 3a 20 70 68 70 2d 6d 69 6e So: as this was captured either on an Ethernet or on a Wi-Fi network when not in monitor mode (or on some other type of network that either uses Ethernet headers or on which the adapter or driver supplies "fake Ethernet" headers, as with Wi-Fi), the packet will start with an Ethernet header; as the Ethernet type value is 0x0800, it's followed by an IPv4 header; as the IPv4 protocol value is 6, it's followed by a TCP header; as one of the TCP port numbers is a port number typically used by HTTP (8080), it's probably followed by HTTP data of some sort (this isn't guaranteed, however - TCP port numbers are more like hints). For ARP over the same network, you'll again have an Ethernet header (the ffff ffff is the Ethernet broadcast address, so the packet is being broadcast, as ARP requests usually are), with an Ethernet type of 0x0806, which is the Ethernet type value for ARP. For ICMP over the same network, you'll again have an Ethernet header, and you'll also have an IPv4 header, so the Ethernet type will be 0x0800. The value in the protocol field in the IPv4 header will be 1, for ICMP.
Xbee Node Discovery Response
I'm trying to discover devices, from a coordinator, in my network. So I sent an ND command to the coordinator and I'm correctly receiving response from other Xbee. The next step will be to store the information I've received in a web application, in oder to send commands and data. However, what I'm still missing is some parts in the frame respose. So far I've mapped the frame like this: 1 7E start frame ===== =================== MESSAGE LENGHT 2-3 0x00 0x19 -> 25 ===== =================== PACKET TYPE 4 88 -> response to a remote AT command 5 02 frame ID ===== =================== AT COMMAND 6-7 0x4E 0x44 "ND" 8 00 status byte (00 -> OK) ===== =================== MY - Remote Address 9-10 0x17 0x85 ===== =================== SH - SERIAL NUMBER HIGH 11-14 0x00 0x13 0xA2 0x00 ===== =================== SL - SERIAL NUMBER LOW 15-18 0x40 0xB4 0x50 0x23 ===== =================== SIGNAL 19 20 = ======== NI - Node Identifier 20 00 21 FF 22 FE 23 01 24 00 25 C1 26 05 27 10 28 1E ===== ===== CHECKSUM (25th bytes from MESSAGE LENGHT) 29 19 So, where I can find in this response the address of the device ? My guess is in the NI part of the message but, I haven't find any example/information of how the data are organised. Could someone point me in the right direction?
As someone told me in the dig.com forum NI<CR> (Variable length) PARENT_NETWORK ADDRESS (2 Bytes)<CR> DEVICE_TYPE (1 Byte: 0=Coord, 1=Router, 2=End Device) STATUS (1 Byte: Reserved) PROFILE_ID (2 Bytes) MANUFACTURER_ID (2 Bytes So, loking to my frame response: 00 --- Node Identifier variable, (here 1 byte = 00 because no value is set up). FFFE --- parent network address (2 bytes) 01 --- device type 00 --- status C105 --- profile id 101E --- manufacturing id This, afaik, means that in this last part of the frame, no information about address of the device are given. Only information are the SL and SH.
The 16-bit network address is what you've labeled "MY" (0x1785), and the 64-bit MAC address is the combination of SH/SL (00 13 A2 00 40 B4 50 23).
Beagle Bone serial communication
I am working on Beagle Bone Rev A5 and my UART1 and UART2 are working fine with these mux settings: echo 20 > /sys/kernel/debug/omap_mux/uart1_rxd echo 0 > /sys/kernel/debug/omap_mux/uart1_txd echo 1 > /sys/kernel/debug/omap_mux/spi0_d0 echo 21 > /sys/kernel/debug/omap_mux/spi0_sclk Now I want hardware flow control enabled and for that I want to use UART4 and UART5. Can anybody help me enabling Rx,Tx,RTS,CTS of UART 4 & 5? What will be the mux setting for these UARTs?
This page helped me a bit: http://www.jerome-bernard.com/blog/2012/06/04/beaglebone-serial-ports-and-xbees/ You have to set : UART4 - RX /sys/kernel/debug/omap_mux/gpmc_wait0 26 Mode 6 - Input UART4 - TX /sys/kernel/debug/omap_mux/gpmc_wpn 6 Mode 6 - Output UART5 - RX /sys/kernel/debug/omap_mux/lcd_data9 24 Mode 4 - Input UART5 - TX /sys/kernel/debug/omap_mux/lcd_data8 4 Mode 4 - Output
How Convert hex ip from Java?
i used cat /proc/pid/net/udp6 and become: sl local_address remote_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops 63: 00000000000000000000000000000000:D9BF 00000000000000000000000000000000:0000 07 00000000:00000000 00:00000000 00000000 1000 0 181584 2 c16e8d00 0 I know how its structured and the 00000000000000000000000000000000:D9BFmust be local ip. How can I convert it to normal ip format like 127.0.0.1?
InetAddress a = InetAddress.getByAddress(DatatypeConverter.parseHexBinary("0A064156"));
About MPEG-4 headers
I examined some MPEG-4 video headers and saw some byte arrays like below at the beginning: 00 00 01 B0 01 00 00 01 B5 89 13 I know 00 00 01 parts but what exactly B0 B1 and B5 89 13 parts mean? Actually, if I put this byte array infront of an MPEG-4 stream, it works fine. But I don't know if those values works with different mpeg-4 stream sources ?
0x000001B0 -> Visual Object Sequence Start (VOSS) Code 0x000001B5 -> Visual Object Start (VOS) Code You can find the complete MPEG-4 elementary video header details at "ISO/IEC 14496-2" documentation. Here are the details you asked for. Visual Object Sequence Start (VOSS) Code -> 4 bytes visual object sequence start code = long hex value of 0x000001B0 -> 8 bits profile/level indicator = 1 byte unsigned number Visual Object Start (VOS) Code -> 4 bytes visual object start code = long hex value of 0x000001B5 -> 1 bit has id marker flag = 1/4 nibble flag _ID_Marker_Section_ -> 4 bits version id = 1 nibble unsigned value - only if marker is true - version id types are ISO 14496-2 = 1 -> 3 bits visual object priority = 3/4 nibble unsigned value - only if marker is true - priorities are 1 through to 7 -> 4 bits visual object type = 1 nibble unsigned value - types are video = 1 ; still texture = 2 ; mesh = 3 ; face = 4 -> 1 bit video signal type = 1/4 nibble flag - NOTE: if this is false Y has a sample range of 16 through to 235