I am doing a small SMS receive utility,i have a SMS messages which I can not understand how to decode its sender id, here is the output of reading the message in PDU mode:
+CMGL: 0,1,,86 0791021197003899440ED0657A7A1E6687E93408610192016390004205000365030106440642062F002006270633062A064706440643062A0020064306440020062706440648062D062F0627062A0020062706440645062C06270646064A
and in text mode:
+CMGL: 0,"REC READ","1011161051159710897116",,"16/10/29,10:36:09+00" 06440642062F002006270633062A064706440643062A0020064306440020062706440648062D062F0627062A0020062706440645062C06270646064A
and i read this message through mobile phone and i found that the sender alphanumeric code "1011161051159710897116" is equal to "etisalat" which is the name of service provider, i want to understand what encoding they use. and how to decode it ?
It's encoded as ASCII as decimal semi-octets:
1011161051159710897116 =
101 = &65 = e
116 = &74 = t
105 = &69 = i
115 = &73 = s
97 = &61 = a
108 = &6C = l
97 = &61 = a
116 = &74 = t
To read this from PDU data, you have to swap the semi-octets and if the length is odd you have to add an extra 'F' to make it even to get the proper octet string.
The specs for SMS PDU's can be found here: GSM 03.40
Related
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 11 months ago.
Improve this question
I'm trying to map devices found using LLDP on a switch to a specific interface on that switch.
If I SSH into the switch, I can tell there is a device on its port 6 (interface 6).
If I run snmpwalk looking at the lldpRemEntry, I can see the same device.
snmpwalk -c community -v 2c $IP 1.0.8802.1.1.2.1.4.1.1 | grep 0.6
iso.0.8802.1.1.2.1.4.1.1.4.0.6.32 = INTEGER: 5
iso.0.8802.1.1.2.1.4.1.1.5.0.6.32 = Hex-STRING: 01 0A 63 29 07
iso.0.8802.1.1.2.1.4.1.1.6.0.6.32 = INTEGER: 7
iso.0.8802.1.1.2.1.4.1.1.7.0.6.32 = STRING: "0008303043F4:P1"
iso.0.8802.1.1.2.1.4.1.1.8.0.6.32 = STRING: "SW PORT"
iso.0.8802.1.1.2.1.4.1.1.9.0.6.32 = STRING: "SEP0008303043F4"
iso.0.8802.1.1.2.1.4.1.1.10.0.6.32 = STRING: "Cisco IP Phone 7965G,V11, SCCP45.9-4-2SR4-3S"
iso.0.8802.1.1.2.1.4.1.1.11.0.6.32 = Hex-STRING: 24 00
iso.0.8802.1.1.2.1.4.1.1.12.0.6.32 = Hex-STRING: 24 00
However, when looking at the ifIndex of the same switch, I don't see the same value (I'm expecting 6). Instead, I see these values for the interface id.
snmpwalk -c community -v 2c $IP 1.3.6.1.2.1.2.2.1.1
iso.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.1.10 = INTEGER: 10
iso.3.6.1.2.1.2.2.1.1.30 = INTEGER: 30
iso.3.6.1.2.1.2.2.1.1.41 = INTEGER: 41
iso.3.6.1.2.1.2.2.1.1.999 = INTEGER: 999
iso.3.6.1.2.1.2.2.1.1.5179 = INTEGER: 5179
iso.3.6.1.2.1.2.2.1.1.5180 = INTEGER: 5180
iso.3.6.1.2.1.2.2.1.1.5181 = INTEGER: 5181
iso.3.6.1.2.1.2.2.1.1.10101 = INTEGER: 10101
iso.3.6.1.2.1.2.2.1.1.10102 = INTEGER: 10102
iso.3.6.1.2.1.2.2.1.1.10103 = INTEGER: 10103
iso.3.6.1.2.1.2.2.1.1.10104 = INTEGER: 10104
iso.3.6.1.2.1.2.2.1.1.10105 = INTEGER: 10105
iso.3.6.1.2.1.2.2.1.1.10106 = INTEGER: 10106
iso.3.6.1.2.1.2.2.1.1.10107 = INTEGER: 10107
iso.3.6.1.2.1.2.2.1.1.10108 = INTEGER: 10108
iso.3.6.1.2.1.2.2.1.1.10109 = INTEGER: 10109
iso.3.6.1.2.1.2.2.1.1.10110 = INTEGER: 10110
iso.3.6.1.2.1.2.2.1.1.10111 = INTEGER: 10111
iso.3.6.1.2.1.2.2.1.1.10112 = INTEGER: 10112
iso.3.6.1.2.1.2.2.1.1.10113 = INTEGER: 10113
iso.3.6.1.2.1.2.2.1.1.10114 = INTEGER: 10114
iso.3.6.1.2.1.2.2.1.1.10115 = INTEGER: 10115
iso.3.6.1.2.1.2.2.1.1.10116 = INTEGER: 10116
iso.3.6.1.2.1.2.2.1.1.10117 = INTEGER: 10117
iso.3.6.1.2.1.2.2.1.1.10118 = INTEGER: 10118
iso.3.6.1.2.1.2.2.1.1.10119 = INTEGER: 10119
iso.3.6.1.2.1.2.2.1.1.10120 = INTEGER: 10120
iso.3.6.1.2.1.2.2.1.1.10121 = INTEGER: 10121
iso.3.6.1.2.1.2.2.1.1.10122 = INTEGER: 10122
iso.3.6.1.2.1.2.2.1.1.10123 = INTEGER: 10123
iso.3.6.1.2.1.2.2.1.1.10124 = INTEGER: 10124
iso.3.6.1.2.1.2.2.1.1.10125 = INTEGER: 10125
iso.3.6.1.2.1.2.2.1.1.10126 = INTEGER: 10126
iso.3.6.1.2.1.2.2.1.1.10201 = INTEGER: 10201
iso.3.6.1.2.1.2.2.1.1.10202 = INTEGER: 10202
iso.3.6.1.2.1.2.2.1.1.14001 = INTEGER: 14001
iso.3.6.1.2.1.2.2.1.1.14002 = INTEGER: 14002
With these for the names (ifName):
snmpwalk -c community -v 2c $IP 1.3.6.1.2.1.31.1.1.1.1
iso.3.6.1.2.1.31.1.1.1.1.1 = STRING: "Vl1"
iso.3.6.1.2.1.31.1.1.1.1.10 = STRING: "Vl10"
iso.3.6.1.2.1.31.1.1.1.1.30 = STRING: "Vl30"
iso.3.6.1.2.1.31.1.1.1.1.41 = STRING: "Vl41"
iso.3.6.1.2.1.31.1.1.1.1.999 = STRING: "Vl999"
iso.3.6.1.2.1.31.1.1.1.1.5179 = STRING: "StackPort1"
iso.3.6.1.2.1.31.1.1.1.1.5180 = STRING: "StackSub-St1-1"
iso.3.6.1.2.1.31.1.1.1.1.5181 = STRING: "StackSub-St1-2"
iso.3.6.1.2.1.31.1.1.1.1.10101 = STRING: "Gi1/0/1"
iso.3.6.1.2.1.31.1.1.1.1.10102 = STRING: "Gi1/0/2"
iso.3.6.1.2.1.31.1.1.1.1.10103 = STRING: "Gi1/0/3"
iso.3.6.1.2.1.31.1.1.1.1.10104 = STRING: "Gi1/0/4"
iso.3.6.1.2.1.31.1.1.1.1.10105 = STRING: "Gi1/0/5"
iso.3.6.1.2.1.31.1.1.1.1.10106 = STRING: "Gi1/0/6"
iso.3.6.1.2.1.31.1.1.1.1.10107 = STRING: "Gi1/0/7"
iso.3.6.1.2.1.31.1.1.1.1.10108 = STRING: "Gi1/0/8"
iso.3.6.1.2.1.31.1.1.1.1.10109 = STRING: "Gi1/0/9"
iso.3.6.1.2.1.31.1.1.1.1.10110 = STRING: "Gi1/0/10"
iso.3.6.1.2.1.31.1.1.1.1.10111 = STRING: "Gi1/0/11"
iso.3.6.1.2.1.31.1.1.1.1.10112 = STRING: "Gi1/0/12"
iso.3.6.1.2.1.31.1.1.1.1.10113 = STRING: "Gi1/0/13"
iso.3.6.1.2.1.31.1.1.1.1.10114 = STRING: "Gi1/0/14"
iso.3.6.1.2.1.31.1.1.1.1.10115 = STRING: "Gi1/0/15"
iso.3.6.1.2.1.31.1.1.1.1.10116 = STRING: "Gi1/0/16"
iso.3.6.1.2.1.31.1.1.1.1.10117 = STRING: "Gi1/0/17"
iso.3.6.1.2.1.31.1.1.1.1.10118 = STRING: "Gi1/0/18"
iso.3.6.1.2.1.31.1.1.1.1.10119 = STRING: "Gi1/0/19"
iso.3.6.1.2.1.31.1.1.1.1.10120 = STRING: "Gi1/0/20"
iso.3.6.1.2.1.31.1.1.1.1.10121 = STRING: "Gi1/0/21"
iso.3.6.1.2.1.31.1.1.1.1.10122 = STRING: "Gi1/0/22"
iso.3.6.1.2.1.31.1.1.1.1.10123 = STRING: "Gi1/0/23"
iso.3.6.1.2.1.31.1.1.1.1.10124 = STRING: "Gi1/0/24"
iso.3.6.1.2.1.31.1.1.1.1.10125 = STRING: "Gi1/0/25"
iso.3.6.1.2.1.31.1.1.1.1.10126 = STRING: "Gi1/0/26"
iso.3.6.1.2.1.31.1.1.1.1.10201 = STRING: "Te1/0/1"
iso.3.6.1.2.1.31.1.1.1.1.10202 = STRING: "Te1/0/2"
iso.3.6.1.2.1.31.1.1.1.1.14001 = STRING: "Nu0"
iso.3.6.1.2.1.31.1.1.1.1.14002 = STRING: "Fa0"
So I can tell by looking that the index 10106 is the one that has the device on it because it's name matches the local interface name seen when I SSH into the switch. But how do I link these programmatically only using SNMP commands? I tried using the dot1dBasePortIfIndex, but it for some reason doesn't provide all the interfaces to me.
snmpwalk -c community -v 2c $IP 1.3.6.1.2.1.17.1.4.1.2
iso.3.6.1.2.1.17.1.4.1.2.2 = INTEGER: 10102
iso.3.6.1.2.1.17.1.4.1.2.7 = INTEGER: 10107
iso.3.6.1.2.1.17.1.4.1.2.8 = INTEGER: 10108
iso.3.6.1.2.1.17.1.4.1.2.10 = INTEGER: 10110
iso.3.6.1.2.1.17.1.4.1.2.13 = INTEGER: 10113
iso.3.6.1.2.1.17.1.4.1.2.14 = INTEGER: 10114
iso.3.6.1.2.1.17.1.4.1.2.15 = INTEGER: 10115
iso.3.6.1.2.1.17.1.4.1.2.16 = INTEGER: 10116
iso.3.6.1.2.1.17.1.4.1.2.17 = INTEGER: 10117
iso.3.6.1.2.1.17.1.4.1.2.18 = INTEGER: 10118
iso.3.6.1.2.1.17.1.4.1.2.19 = INTEGER: 10119
iso.3.6.1.2.1.17.1.4.1.2.20 = INTEGER: 10120
iso.3.6.1.2.1.17.1.4.1.2.21 = INTEGER: 10121
iso.3.6.1.2.1.17.1.4.1.2.23 = INTEGER: 10123
iso.3.6.1.2.1.17.1.4.1.2.24 = INTEGER: 10124
iso.3.6.1.2.1.17.1.4.1.2.25 = INTEGER: 10125
iso.3.6.1.2.1.17.1.4.1.2.26 = INTEGER: 10126
iso.3.6.1.2.1.17.1.4.1.2.27 = INTEGER: 10201
iso.3.6.1.2.1.17.1.4.1.2.28 = INTEGER: 10202
I'm missing something, but I just don't know what it is. Thanks for the help.
LLDP-MIB contains the following in the description of the LldpPortNumber type:
A port number has no mandatory relationship to an
InterfaceIndex object (of the interfaces MIB, IETF RFC 2863).
If the LLDP agent is a IEEE 802.1D, IEEE 802.1Q bridge, the
LldpPortNumber will have the same value as the dot1dBasePort
object (defined in IETF RFC 1493) associated corresponding
bridge port. If the system hosting LLDP agent is not an
IEEE 802.1D or an IEEE 802.1Q bridge, the LldpPortNumber
will have the same value as the corresponding interface's
InterfaceIndex object.
It looks like you have discovered this fact, as you mentioned you checked the dot1dBasePortIfIndex. The key thing that you are missing is that Cisco uses something called "community string indexing" for some MIBs, including BRIDGE-MIB. You can find more information at this link if you are interested. In short, you have to incorporate the VLAN number into the community string in order to view the entries for the ports on that VLAN. So if your community string is public and your port is on VLAN 100, then you would need to use public#100 for your community string in order to see the dot1dBasePortIfIndex for that port.
As #TallChuck pointed out, there's no relationship between those indexes. However for at least Cisco IOS devices, including the one you're working on, you can tie that index of 6 using LLDP-MIB::lldpLocPortDesc (or .1.0.8802.1.1.2.1.3.7.1.4). The fields returned are the full names of the interfaces, and match the fields returned from IF-MIB::ifDescr (or .1.3.6.1.2.1.2.2.1.2)
$snmpwalk -v2c -c community 10.10.10.10 LLDP-MIB::lldpLocPortDesc
LLDP-MIB::lldpLocPortDesc.1 = STRING: GigabitEthernet1/0/1
LLDP-MIB::lldpLocPortDesc.2 = STRING: GigabitEthernet1/0/2
...
$snmpwalk -v2c -c community 10.10.10.10 IF-MIB::ifDescr
IF-MIB::ifDescr.10101 = STRING: GigabitEthernet1/0/1
IF-MIB::ifDescr.10102 = STRING: GigabitEthernet1/0/2
...
So in my case, an LLDP neighbor with an index of 2 can be tied to the switch's interface index 10102 via the string GigabitEthernet1/0/2.
One last note, dot1dBasePortIfIndex is a separate indexing system from LLDP, and only indexes layer2 interfaces. This is probably why you didn't see all interfaces listed.
I am trying to decode UDP packet data from an application which encoded the data using Qt's QDataStream methods, but having trouble when trying to decode string fields. The docs say the data was encoded in utf8. The python QDataStream module only has a readQString() method. Numbers seem to decode fine, but the stream pointer gets messed up when the first strings decode improperly.
How can i decode these UTF8 Strings?
I am using some documentation from the source project interpret the encoding:
wsjtx-2.2.2.tgz
NetworkMessage.hpp Description in the header file
Header:
32-bit unsigned integer magic number 0xadbccbda
32-bit unsigned integer schema number
There is a status message for example with comments like this:
Heartbeat Out/In 0 quint32
Id (unique key) utf8
Maximum schema number quint32
version utf8
revision utf8
example data from the socket when a status message is received:
b'\xad\xbc\xcb\xda\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x06WSJT-X\x00\x00\x00\x03\x00\x00\x00\x052.1.0\x00\x00\x00\x0624fcd1'
def jt_decode_heart_beat(i):
"""
Heartbeat Out/In 0 quint32
Id (unique key) utf8
Maximum schema number quint32
version utf8
revision utf8
:param i: QDataStream
:return: JT_HB_ID,JT_HB_SCHEMA,JT_HB_VERSION,JT_HB_REVISION
"""
JT_HB_ID = i.readQString()
JT_HB_SCHEMA = i.readInt32()
JT_HB_VERSION = i.readQString()
JT_HB_REVISION = i.readQString()
print(f"HB:ID={JT_HB_ID} JT_HB_SCHEMA={JT_HB_SCHEMA} JT_HB_VERSION={JT_HB_VERSION} JT_HB_REVISION={JT_HB_REVISION}")
return (JT_HB_ID, JT_HB_SCHEMA, JT_HB_VERSION, JT_HB_REVISION)
while 1:
data, addr = s.recvfrom(1024)
b = QByteArray(data)
i = QDataStream(b)
JT_QT_MAGIC_NUMBER = i.readInt32()
JT_QT_SCHEMA_NUMBER = i.readInt32()
JT_TYPE = i.readInt32()
if JT_TYPE == 0:
# Heart Beat
jt_decode_heart_beat(i)
elif JT_TYPE == 1:
jt_decode_status(i)
Long story short the wsjtx udp protocol I was reading did not encode the strings using the the QDataString type, so it was wrong to expect that i.readQString() would work.
Instead the data was encoded using a QInt32 to define the string length, followed by the UTF8 characters encoded in QByteArray.
I successfully encapsulated this functionality in a function:
def jt_decode_utf8_str(i):
"""
strings are encoded with an int 32 indicating size
and then an array of bytes in utf-8 of length size
:param i:
:return: decoded string
"""
sz = i.readInt32()
b = i.readRawData(sz)
return b.decode("utf-8")
I have a scenario that includes a single car node and a single RSU node. the car sends a beacon message every 1s. when the RSU receives a beacon message, it should reply back to the sender (the car) with a wave short message.
I create a WSM once the RSU receives a BSM, and I set the receiver's ID to the bsm sender ID (as I want the RSU to send the message only to a specific node). the problem is that the wsm in never received by the car (onWSM function is never called).
here is the code:
void RSUApp::onBSM(BasicSafetyMessage* bsm)
{
/*this fn is called when rsu receives a beacon*/
/*after receiving beacon, send the value of the current speed*/
WaveShortMessage* msg= new WaveShortMessage("speed");
msg->setSenderAddress(this->myId);
msg->setWsmData(std::to_string(this->currentSpeed).c_str());
int Id = bsm->getSenderAddress();
populateWSM(msg,Id,0);
sendDown(msg);
}
when I replace the receiver's ID by -1 (send broadcast message instead of sending to specific node), the car APP can handle the WSM without problems.
populateWSM(msg,-1,0);
I am using veins 4.7 and this is the ini file contents:
*.rsu[0].mobility.x = 500
*.rsu[0].mobility.y = 50
*.rsu[0].mobility.z = 3
*.rsu[*].applType = "iteration6.src.RSUApp"
*.rsu[*].appl.headerLength = 80 bit
*.rsu[*].appl.sendBeacons = false
*.rsu[*].appl.dataOnSch = false
*.connectionManager.sendDirect = true
*.connectionManager.maxInterfDist = 2600m
*.connectionManager.drawMaxIntfDist = true
*.**.nic.mac1609_4.useServiceChannel = false
*.**.nic.mac1609_4.txPower = 20mW
*.**.nic.mac1609_4.bitrate = 6Mbps
*.**.nic.phy80211p.sensitivity = -89dBm
*.**.nic.phy80211p.useThermalNoise = true
*.**.nic.phy80211p.thermalNoise = -110dBm
*.**.nic.phy80211p.decider = xmldoc("config.xml")
*.**.nic.phy80211p.analogueModels = xmldoc("config.xml")
*.**.nic.phy80211p.usePropagationDelay = true
*.node[*].applType = "iteration6.src.carApp"
*.node[*].appl.headerLength = 80 bit
*.node[*].appl.sendBeacons = true
*.node[*].appl.dataOnSch = false
*.node[*].appl.beaconInterval = 1s
can anyone help me with that problem?
It seems like you are using the wrong id for the recipient. Instead of
int Id = bsm->getSenderModuleId();
you should rather use
int Id = bsm->getSenderAddress();
This should do the trick.
See the following sources for more details:
WaveShortMessage
populateWSM
The newer version of veins returns MAC based myId while previous versions returned Module Identifier. This needs to be kept in mind while assigning addresses to nodes.
I am implementing an encryption in a project that I has in another java project.
The code in java project is this:
public static String cifraDES(String chave, String dado) throws Exception {
DESKeySpec keySpec = new DESKeySpec(hexStringToByteArray(chave));
SecretKeyFactory kf = SecretKeyFactory.getInstance("DES");
SecretKey passwordKey = kf.generateSecret(keySpec);
Cipher c = Cipher.getInstance("DES");
c = Cipher.getInstance("DES/ECB/NoPadding");
c.init(Cipher.ENCRYPT_MODE, passwordKey);
return bytesToHex(c.doFinal(hexStringToByteArray(dado)));
}
In Ruby project i want implement this encrypt too. But this dont work:
dado = "53495A45303030386E6F7661313031305858585858585858"
chave = "3455189635541968"
des = OpenSSL::Cipher.new('des-ecb').encrypt
des.key = chave
s = des.update(dado) + des.final
Base64.encode64(s).gsub(/\n/, "")
In terminal I recive this message:
'key' be must 8 bytes
And i need this return: b42e3dbfffd4bb5487a27fd702f079e287e6325767bfdd20
View:
http://des.online-domain-tools.com/link/1145159gOjlrPNRkaT/
You haven’t converted the key and data from hex strings, you can do that using pack:
dado = ["53495A45303030386E6F7661313031305858585858585858"].pack('H*')
(When you do this to the key, it is converted from 16 hexidecimal characters to 8 bytes, so not doing this step is causing the error are getting).
You haven’t specified no padding:
des.padding = 0
And you want the result hex encoded, not base 64. You can use unpack:
puts s.unpack('H*')[0]
Putting it all together:
dado = ["53495A45303030386E6F7661313031305858585858585858"].pack('H*')
chave = ["3455189635541968"].pack('H*')
des = OpenSSL::Cipher.new('des-ecb').encrypt
des.key = chave
des.padding = 0
s = des.update(dado) + des.final
puts s.unpack('H*')[0]
Result is b42e3dbfffd4bb5487a27fd702f079e287e6325767bfdd20.
The error seems pretty clear to me. The key you're using chave is 16 bytes. Your key has to be 8 bytes. So reduce the length of the key to 8 chars then try.
I have signed up for an account with Mblox. I would like to use Kannel as my SMPP application to send SMS messages to U.S. phone numbers.
I can bind in, but my submits fail (usually with an error code of 0x042A). I am using the following HTTP request (to my Kannel application) to send a test message to my Verizon phone (just using 14085551212 as an example phone number).
http://localhost:13013/cgi-bin/sendsms?username=tester&password=foobar&to=14085551212&priority=1&text=Test+message+to+VZW
I am also using the following config file. Has anyone encountered this before and been able to solve it?
My current config file:
#---------------------------------------------
# CORE
#
group = core
admin-port = 13000
smsbox-port = 13001
wapbox-port = 13002
admin-password = bar
box-allow-ip = "127.0.0.1"
#---------------------------------------------
# SMSC CONNECTIONS
#
group = smsc
smsc = smpp
smsc-id = smsc1
connect-allow-ip = 127.0.0.1
host = "smpp.psms.us.mblox.com"
transceiver-mode = true
smsc-username = (my account name)
smsc-password = (my password)
port = 3204
enquire-link-interval = 30
system-type = "mbloxclient1"
service-type = -1
interface-version = 34
bind-addr-ton = 0x02
bind-addr-npi = 0x08
my-number = (my short code)
msg-id-type = 0x00
source-addr-ton = 0x03
source-addr-npi = 0x08
dest-addr-ton = 0x02
dest-addr-npi = 0x08
esm-class = 0
#---------------------------------------------
# SMSBOX SETUP
#
group = smsbox
bearerbox-host = localhost
sendsms-port = 13013
global-sender = (my short code)
log-level = 0
#---------------------------------------------
# WAPBOX SETUP
#
group = wapbox
bearerbox-host = 127.0.0.1
syslog-level = none
#---------------------------------------------
# SEND-SMS USERS
#
group = sendsms-user
username = tester
password = foobar
#user-deny-ip = ""
#user-allow-ip = ""
#---------------------------------------------
# SMS SERVICES
#
group = sms-service
keyword = default
text = "No service specified"
I see a few things that need to change. First, you need to include the operator, tariff, and service ID when sending to certain US carriers (such as Verizon and T-Mobile).
To send to Verizon, you'll need to first include a TLV section in your config file with these vendor-specific parameters.
#----------------------------------------
# TLV TAGS
group = smpp-tlv
name = SERVICE_ID
tag = 0x1407
type = octetstring
length = 5
group = smpp-tlv
name = OPERATOR_ID
tag = 0x1402
type = octetstring
length = 5
group = smpp-tlv
name = TARIFF
tag = 0x1403
type = octetstring
length = 5
Note that this will require installing Kannel version 1.4.4 or higher (within the 1.4.x branch - the 1.5.0 development version does not seem to support TLVs as of this posting).
Once this is set up, you can use the following format to send SMS messages through Mblox with the required TLVs:
http://localhost:13013/cgi-bin/sendsms?username=tester&password=foobar&to=14085551212&priority=1&meta-data=?smpp?SERVICE_ID=12345%26OPERATOR_ID=31003%26TARIFF=0&text=Test+message+to+VZW
(You'll have to change the phone number, service ID, and operator ID to the appropriate values.)
For carriers other than Verizon and T-Mobile (i.e., AT&T, Sprint, Cricket, US Cellular, etc.), you should leave out the service ID parameter.
If you are using Sure Route, you will not need the operator ID or tariff parameter.
Good luck! Note that, even with these instructions, it will still likely take a bit of trial and error, and modification to get everything working correctly.
(Disclaimer: Question and answer both provided by an Mblox advocate.)