ISO - not getting appropriate response - iso

I have used JPOS library for creating ISO message but I am not getting any response, The call which I have initiated is SIGN-ON. The code which i have implemented and request is mentioned below.
length 42
0x0000: 4500 005e 4448 4000 4006 8842 0a14 5140 E..^DH#.#..B..Q#
0x0010: 0a5f 085d 952e 30c8 5cdb c683 49e6 692d ._.]..0....I.i-
0x0020: 8018 01f6 6e60 0000 0101 080a 0775 0600 ....n`.......u..
0x0030: 889f a492 3038 3030 8220 0100 0000 0000 ....0800........
0x0040: 0400 0000 0000 0000 3132 3234 3139 3035 ........12241905
0x0050: 3136 3132 3033 3437 3030 3130 3033 16120347001003
channel.setHost("xx.xx.xx.xx", xxxxx);
channel.connect();
ISOMsg isoMsg = new ISOMsg();
isoMsg.setPackager(packager);
isoMsg.setMTI("0800");
isoMsg.set(7, "1224190516");
isoMsg.set(11, "120347");
isoMsg.set(24, "001");
isoMsg.set(70, "003");
byte[] send_PackedRequestData = isoMsg.pack();
channel.send(send_PackedRequestData);```

For once, you have to set the packager to the channel and send the isoMsg object not the bytes:
channel.setPackager(packager);
...
channel.send(isoMsg);
Additionally I don't see you calling channel.receive();
And if you did there are many possible reasons why you wouldn't receive a response, among others:
Unmatched channel/packager between client and server
Server not responding for some internal error

Related

Is there a way to check the Socket Priority with Wireshark or Tcpdump?

I am doing some changes in the SO_PRIORITY of the socket that sends UDP packets, using the command setsockopt, is there a way to see that changes with Wireshark or Tcpdump.
I read that can be DSF (Differentiated Services Field), but I am not sure because when I make the changes I see that this field is 00.
I am running a Linux Mint 19.3
It is part of the 802.1Q header. For ex:
> 802.1Q Virtual LAN, PRI: 5, DEI: 0, ID: 4
101. .... .... .... = Priority: Voice, < 10ms latency and jitter (5)
...0 .... .... .... = DEI: Ineligible
.... 0000 0000 0100 = ID: 4
Type: IPv6 (0x86dd)

Decode raw Scapy data to human readable

I'm trying to switch to using Scapy instead of Wireshark, but am having trouble decoding the data I'm getting. In Wireshark I can easily see the last layer for filtered packets labeled as "Distributed Interactive Simulation", but in Scapy the last layer is "Raw". I'm trying to get the data from this layer in the same human readable format. So far I've gotten:
# Capture with Scapy
from scapy.all import sniff
capture = sniff(filter="dst 10.6.255.255 and port 3000", count=5)
packet = capture[0]
raw = pkt.lastlayer()
print(raw)
<Raw load='\x068\x14\x05L\x88nK\x00x\x00\x00\x00\x94\x08\x88\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x9f\x00\x00\x02 \x00\x01sj\x9b\xf4\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x04p\x00\x08\x00\x00\x00\x00\x00\x00d\xe9Y<\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x04\x8c\x00\x00\x113\x00\x00\x00\x01\x00\x02\x0c\x00\x00\x00\x01\x02\x00\x00\x00\x041187\x00\x00\x00\x00\x00' |>
Could someone show me how to make this human readable?
First, you have an error in your script. raw = pkt.lastlayer() should be raw = packet.lastlayer().
Try adding print(packet.show()) to your script for a more readable format which will give you something similar to this:
###[ Ethernet ]###
dst = 94:c6:91:1c:68:c3
src = 94:c6:91:1c:68:1d
type = 0x800
###[ IP ]###
version = 4
ihl = 5
tos = 0x0
len = 84
id = 49689
flags = DF
frag = 0
ttl = 64
proto = icmp
chksum = 0x1938
src = 192.168.111.4
dst = 192.168.111.2
\options \
###[ ICMP ]###
type = echo-request
code = 0
chksum = 0xb468
id = 0x6d3
seq = 0xab
###[ Raw ]###
load = '\x0e\x85\x96[\x00\x00\x00\x00\xd2e\x06\x00\x00\x00\x00\x00\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !"#$%&\'()*+,-./01234567'
None
You can also use hexdump command to show the raw load in a more readable format.
from scapy.utils import hexdump
raw = packet.lastlayer()
hexdump(raw)
Which will output something like this:
0000 D091965B0000000080FD0E0000000000 ...[............
0010 101112131415161718191A1B1C1D1E1F ................
0020 202122232425262728292A2B2C2D2E2F !"#$%&'()*+,-./
0030 3031323334353637 01234567
0000 063814054CC2886E4B0078000000C294 .8..L..nK.x.....
0010 08C2880000C3BFC3BFC3BFC3BF000000 ................
0020 00000000000000000000000000000100 ................
0030 0000C29F000002200001736AC29BC3B4 ....... ..sj....
0040 00000000000000000000000470000800 ............p...
0050 000000000064C3A9593C000000000000 .....d..Y<......
0060 0000000004C28C000011330000000100 ..........3.....
0070 020C0000000102000000043131383700 ...........1187.
0080 00000000 ....
readable_payload = bytes(packet[TCP].payload).decode('UTF8','replace')

IPv6 encapsuling on Azure ILPIP

Use of IPv6 tunnels (like tunnelbroker.net) is possible on Azure VM, via ILPIP (Instance Level Public IP)?
I tried to use it, but I don't get replies for ping packets to IPv6 gateway.
Internet Protocol Version 4, Src: 100.90.204.79, Dst: 216.66.84.46
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 124
Identification: 0x33d7 (13271)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: IPv6 (41)
Header checksum: 0xea66 [validation disabled]
[Good: False]
[Bad: False]
Source: 100.90.204.79
Destination: 216.66.84.46
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Protocol Version 6, Src: 2001:470:1f14:105a::2, Dst: 2001:470:1f14:105a::1
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 1001 0111 0111 0110 1010 = Flowlabel: 0x0009776a
Payload length: 64
Next header: ICMPv6 (58)
Hop limit: 64
Source: 2001:470:1f14:105a::2
Destination: 2001:470:1f14:105a::1
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol v6
Type: Echo (ping) request (128)
Code: 0
Checksum: 0xd3f8 [correct]
Identifier: 0x5016
Sequence: 1
[No response seen]
[Expert Info (Warn/Sequence): No response seen to ICMPv6 request in frame 212]
[No response seen to ICMPv6 request in frame 212]
[Severity level: Warn]
[Group: Sequence]
Data (56 bytes)
Data: 8bb5ed56000000006ed40d00000000001011121314151617...
[Length: 56]
I suspect that Azure is rejecting IPv4 protocol 41, am I correct?
The following is documented:
Microsoft has played a leading role in helping customers to smoothly transition from IPv4 to IPv6 for the past several years. To date, Microsoft has built IPv6 support into many of its products and solutions like Windows 8 and Windows Server 2012 R2. Microsoft is committed to expanding the worldwide capabilities of the Internet through IPv6 and enabling a variety of valuable and exciting scenarios, including peer-to-peer and mobile applications. The foundational work to enable IPv6 in the Azure environment is well underway. However, we are unable to share a date when IPv6 support will be generally available at this time.

STM32F0-Discovery: no tty

I am currently trying to send data to my STM32F0308 board via USART.
The data is supposed to be sent by a Python script using PySerial.
However, when I plug in the board, I cannot find the corresponding /dev/ttyXXXX.
The board is branched and I can flash code on it (STLink via USB), but there is no port visible.
dmesg shows that the computer is aware of the board:
[10364.101554] usb 1-3: USB disconnect, device number 10
[10368.044231] usb 1-3: new full-speed USB device number 12 using xhci_hcd
[10368.173948] usb 1-3: New USB device found, idVendor=0483, idProduct=3748
[10368.173956] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10368.173959] usb 1-3: Product: STM32 STLink
[10368.173962] usb 1-3: Manufacturer: STMicroelectronics
[10368.173965] usb 1-3: SerialNumber: VÿnIxRT68\xffffffc2\xffffff87
Here is the output of lsusb:
Bus 001 Device 012: ID 0483:3748 STMicroelectronics ST-LINK/V2
Here's the output of ls /dev/tty*:
tty tty12 tty17 tty21 tty26 tty30 tty35 tty4 tty44 tty49 tty53 tty58 tty62 ttyprintk ttyS12 ttyS17 ttyS21 ttyS26 ttyS30 ttyS7
tty0 tty13 tty18 tty22 tty27 tty31 tty36 tty40 tty45 tty5 tty54 tty59 tty63 ttyS0 ttyS13 ttyS18 ttyS22 ttyS27 ttyS31 ttyS8
tty1 tty14 tty19 tty23 tty28 tty32 tty37 tty41 tty46 tty50 tty55 tty6 tty7 ttyS1 ttyS14 ttyS19 ttyS23 ttyS28 ttyS4 ttyS9
tty10 tty15 tty2 tty24 tty29 tty33 tty38 tty42 tty47 tty51 tty56 tty60 tty8 ttyS10 ttyS15 ttyS2 ttyS24 ttyS29 ttyS5
tty11 tty16 tty20 tty25 tty3 tty34 tty39 tty43 tty48 tty52 tty57 tty61 tty9 ttyS11 ttyS16 ttyS20 ttyS25 ttyS3 ttyS6
And here is my the function to initialize the serial port:
#function to initialize the serial port
def init_serial():
global ser #must be declared in each function
#set serial: port, baudrate, timeout (port does not hang)
ser = serial.Serial(port="/dev/ttyS3", baudrate=9600, timeout=5)
if ser.isOpen():
ser.close()
#open the serial port
ser.open()
#print: port is open or closed
if ser.isOpen():
print("Port open: " + ser.portstr)
else:
print("Port not open: We have a problem!")
#function ends here
I am using Ubuntu 15.04, but it also did not work on another computer using Debian.
According to ST, the STM32F0x0 line supports USB.
Edit:
As requested, the output of lsusb -v:
Bus 001 Device 003: ID 0483:3748 STMicroelectronics ST-LINK/V2
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0483 STMicroelectronics
idProduct 0x3748 ST-LINK/V2
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
The device gets discovered and it's a ST-Link debug interface.
The STM32F0308-Discovery does not have a USB UART interface and the ST-Link does not include UART functionality as far as I can see. What you are trying to do appears to be impossible without extra hardware. You would have to get one of those USB UART interfaces with separate connectors and wire it up to the USART pins exposed on the headers.

What's the redundant data in TCP packet?

I am reading "Unix Network Programming" and tcpdump the packet generate by the example. The example is just send out a packet contain string "liha".
I read the TCP/IP RFC and found normal IP header is 20B. and normal TCP header except data is 24B.
So, there are 8B before string "liha" in the captured packet. Are "0121 3d2a 0120 b43e" useless?
11:00:51.690949 IP localhost.40163 > localhost.9877: Flags [P.], seq 94:99, ack 95, win 513, options [nop,nop,TS val 18955562 ecr 18920510], length 5
0x0000: 4500 0039 ddc6 4000 4006 5ef6 7f00 0001 E..9..#.#.^.....
0x0010: 7f00 0001 9ce3 2695 8465 e35c 8466 58ca ......&..e.\.fX.
0x0020: 8018 0201 fe2d 0000 0101 080a 0121 3d2a .....-.......!=*
0x0030: 0120 b43e 6c69 6861 0a ...>liha.
Those are the TCP options. And your analyzer already parsed them for you:
options [nop,nop,TS val 18955562 ecr 18920510],
They are generally important and used by communication sides to negotiate which extra enhancements can be used for the TCP connection.

Resources