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 5 years ago.
Improve this question
Suddenly I was not able to ssh to any machine. I thought it to be my router/network issue & I tried it with different network but the result was same. I took tcp dump on both server & client and found that the checksum is incorrect. Client is on MacOS 10.12.6 & server is running Ubuntu.
Below is the TCP dump of both server and client.
server
sudo tcpdump -n -vvv -n dst host 59.90.xxx.xxx
06:51:41.285561 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x0b7d), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107257724 ecr 875004811,nop,wscale 7], length 0
06:51:42.287868 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x0a82), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107257975 ecr 875004811,nop,wscale 7], length 0
06:51:42.288005 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x0a82), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107257975 ecr 875004811,nop,wscale 7], length 0
06:51:43.361309 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x0976), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107258243 ecr 875004811,nop,wscale 7], length 0
06:51:44.343178 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x0881), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107258488 ecr 875004811,nop,wscale 7], length 0
06:51:45.302310 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x0791), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107258728 ecr 875004811,nop,wscale 7], length 0
06:51:46.302969 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x0697), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107258978 ecr 875004811,nop,wscale 7], length 0
06:51:48.303906 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x04a2), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107259479 ecr 875004811,nop,wscale 7], length 0
06:51:48.316328 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x049f), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107259482 ecr 875004811,nop,wscale 7], length 0
06:51:52.367888 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x00aa), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107260495 ecr 875004811,nop,wscale 7], length 0
Client
sudo tcpdump -n -vvv port 22
12:21:41.114101 IP (tos 0x0, ttl 64, id 53772, offset 0, flags [DF], proto TCP (6), length 64)
192.168.1.5.54341 > 35.193.xx.xx.22: Flags [S], cksum 0x3816 (correct), seq 3542782444, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875004811 ecr 0,sackOK,eol], length 0
12:21:42.117525 IP (tos 0x0, ttl 64, id 29056, offset 0, flags [DF], proto TCP (6), length 64)
192.168.1.5.54341 > 35.193.xx.xx.22: Flags [S], cksum 0x342e (correct), seq 3542782444, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875005811 ecr 0,sackOK,eol], length 0
12:21:43.123706 IP (tos 0x0, ttl 64, id 27897, offset 0, flags [DF], proto TCP (6), length 64)
192.168.1.5.54341 > 35.193.xx.xx.22: Flags [S], cksum 0x3046 (correct), seq 3542782444, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875006811 ecr 0,sackOK,eol], length 0
12:21:44.126723 IP (tos 0x0, ttl 64, id 15522, offset 0, flags [DF], proto TCP (6), length 64)
192.168.1.5.54341 > 35.193.xx.xx.22: Flags [S], cksum 0x2c5e (correct), seq 3542782444, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875007811 ecr 0,sackOK,eol], length 0
12:21:45.130005 IP (tos 0x0, ttl 64, id 52435, offset 0, flags [DF], proto TCP (6), length 64)
192.168.1.5.54341 > 35.193.xx.xx.22: Flags [S], cksum 0x2876 (correct), seq 3542782444, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875008811 ecr 0,sackOK,eol], length 0
12:21:46.133002 IP (tos 0x0, ttl 64, id 39289, offset 0, flags [DF], proto TCP (6), length 64)
192.168.1.5.54341 > 35.193.xx.xx.22: Flags [S], cksum 0x248e (correct), seq 3542782444, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875009811 ecr 0,sackOK,eol], length 0
12:21:48.143329 IP (tos 0x0, ttl 64, id 36640, offset 0, flags [DF], proto TCP (6), length 64)
192.168.1.5.54341 > 35.193.xx.xx.22: Flags [S], cksum 0x1cbe (correct), seq 3542782444, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 875011811 ecr 0,sackOK,eol], length 0
I noticed that the length is different (60 vs 64). Can this be the cause of wrong checksum?
Related
I have a tcpdump command that captures tcp handshake (0x16) and cipher change (0x14) packets. I'd like to be able to look at the output and see which ones are the handshake and which ones are the cipher change. Is there any way to alter the format of the output to show that information?
I could save it to a file and look at it in wireshark but I want to see that information in the CLI output.
tcpdump -i eth -nn -v port 48240 and '((tcp[((tcp[12] & 0xf0) >>2)] = 0x16) or (tcp[((tcp[12] & 0xf0) >>2)] = 0x14))'
dropped privs to tcpdump
tcpdump: listening on eth, link-type EN10MB (Ethernet), capture size 262144 bytes
10:03:31.999584 IP (tos 0x0, ttl 64, id 57840, offset 0, flags [DF], proto TCP (6), length 85)
10.118.192.12.2182 > 10.118.192.11.48240: Flags [P.], cksum 0x93d2 (correct), seq 3711068413:3711068446, ack 1143145831, win 16993, options [nop,nop,TS val 1192314306 ecr 1000785770], length 33
10:03:32.000338 IP (tos 0x0, ttl 64, id 4324, offset 0, flags [DF], proto TCP (6), length 326)
10.118.192.11.48240 > 10.118.192.12.2182: Flags [P.], cksum 0x96d4 (incorrect -> 0x8a16), seq 1:275, ack 33, win 16923, options [nop,nop,TS val 1000786035 ecr 1192314306], length 274
10:03:32.000802 IP (tos 0x0, ttl 64, id 57842, offset 0, flags [DF], proto TCP (6), length 190)
10.118.192.12.2182 > 10.118.192.11.48240: Flags [P.], cksum 0x2745 (correct), seq 33:171, ack 275, win 16993, options [nop,nop,TS val 1192314307 ecr 1000786035], length 138
10:03:32.000903 IP (tos 0x0, ttl 64, id 57843, offset 0, flags [DF], proto TCP (6), length 82)
10.118.192.12.2182 > 10.118.192.11.48240: Flags [P.], cksum 0x3df9 (correct), seq 171:201, ack 275, win 16993, options [nop,nop,TS val 1192314307 ecr 1000786035], length 30
10:03:32.000961 IP (tos 0x0, ttl 64, id 57844, offset 0, flags [DF], proto TCP (6), length 97)
10.118.192.12.2182 > 10.118.192.11.48240: Flags [P.], cksum 0x10ed (correct), seq 201:246, ack 275, win 16993, options [nop,nop,TS val 1192314307 ecr 1000786035], length 45
10:03:32.001095 IP (tos 0x0, ttl 64, id 4326, offset 0, flags [DF], proto TCP (6), length 82)
10.118.192.11.48240 > 10.118.192.12.2182: Flags [P.], cksum 0x95e0 (incorrect -> 0x796b), seq 275:305, ack 246, win 16923, options [nop,nop,TS val 1000786036 ecr 1192314307], length 30
10:03:32.001135 IP (tos 0x0, ttl 64, id 4327, offset 0, flags [DF], proto TCP (6), length 97)
10.118.192.11.48240 > 10.118.192.12.2182: Flags [P.], cksum 0x95ef (incorrect -> 0x6ae6), seq 305:350, ack 246, win 16923, options [nop,nop,TS val 1000786036 ecr 1192314307], length 45
10:07:43.518141 IP (tos 0x0, ttl 64, id 6012, offset 0, flags [DF], proto TCP (6), length 26896)
10.118.192.11.48240 > 10.118.192.12.2182: Flags [.], cksum 0xfe9e (incorrect -> 0x208f), seq 3235659:3262503, ack 3057000, win 16923, options [nop,nop,TS val 1001037553 ecr 1192565825], length 26844
SSL works from a VPN client but fails over the GCP-PaloAlto VPN tunnel.
The server is an on-prem Keycloak (version 13.0.0)
Attempt from VPN Client (Successful)
# openssl s_client -connect fqdn:443 -servername fqdn -tls1_2 --prexit
CONNECTED(00000005)
[...]
depth=0 CN = <fqdn>
verify return:1
---
Certificate chain
0 s:CN = <fqdn>
[...]
---
Server certificate
[...]
subject=CN = <fqdn>
issuer=C = US, O = Let's Encrypt, CN = R3
---
[...]
---
SSL handshake has read 4672 bytes and written 311 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
[...]
---
closed
---
Certificate chain
0 s:CN = <fqdn>
[...]
---
Server certificate
[...]
subject=CN = <fqdn>
issuer=C = US, O = Let's Encrypt, CN = R3
[...]
tcpdump from the working client
19:32:09.582389 IP CLIENT.51013 > SERVER.https: Flags [S], seq 3647907685, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 350978343 ecr 0,sackOK,eol], length 0
19:32:09.582551 IP SERVER.https > CLIENT.51013: Flags [S.], seq 3495009322, ack 3647907686, win 65160, options [mss 1460,sackOK,TS val 2099619205 ecr 350978343,nop,wscale 7], length 0
19:32:09.596385 IP CLIENT.51013 > SERVER.https: Flags [.], ack 1, win 2064, options [nop,nop,TS val 350978356 ecr 2099619205], length 0
19:32:09.596385 IP CLIENT.51013 > SERVER.https: Flags [P.], seq 1:219, ack 1, win 2064, options [nop,nop,TS val 350978356 ecr 2099619205], length 218
19:32:09.596502 IP SERVER.https > CLIENT.51013: Flags [.], ack 219, win 508, options [nop,nop,TS val 2099619219 ecr 350978356], length 0
19:32:09.596976 IP SERVER.https > CLIENT.51013: Flags [P.], seq 1:2697, ack 219, win 508, options [nop,nop,TS val 2099619219 ecr 350978356], length 2696
19:32:09.597009 IP SERVER.https > CLIENT.51013: Flags [P.], seq 2697:4097, ack 219, win 508, options [nop,nop,TS val 2099619219 ecr 350978356], length 1400
19:32:09.599161 IP SERVER.https > CLIENT.51013: Flags [P.], seq 4097:4415, ack 219, win 508, options [nop,nop,TS val 2099619221 ecr 350978356], length 318
19:32:09.612262 IP CLIENT.51013 > SERVER.https: Flags [.], ack 1349, win 2043, options [nop,nop,TS val 350978368 ecr 2099619219], length 0
19:32:09.612262 IP CLIENT.51013 > SERVER.https: Flags [.], ack 2697, win 2022, options [nop,nop,TS val 350978368 ecr 2099619219], length 0
19:32:09.612262 IP CLIENT.51013 > SERVER.https: Flags [.], ack 4045, win 2000, options [nop,nop,TS val 350978368 ecr 2099619219], length 0
19:32:09.612262 IP CLIENT.51013 > SERVER.https: Flags [.], ack 4097, win 2000, options [nop,nop,TS val 350978368 ecr 2099619219], length 0
19:32:09.612262 IP CLIENT.51013 > SERVER.https: Flags [.], ack 4097, win 2048, options [nop,nop,TS val 350978368 ecr 2099619219], length 0
19:32:09.614194 IP CLIENT.51013 > SERVER.https: Flags [.], ack 4415, win 2043, options [nop,nop,TS val 350978369 ecr 2099619221], length 0
19:32:09.614194 IP CLIENT.51013 > SERVER.https: Flags [P.], seq 219:312, ack 4415, win 2048, options [nop,nop,TS val 350978370 ecr 2099619221], length 93
19:32:09.614248 IP SERVER.https > CLIENT.51013: Flags [.], ack 312, win 508, options [nop,nop,TS val 2099619236 ecr 350978370], length 0
19:32:09.614711 IP SERVER.https > CLIENT.51013: Flags [P.], seq 4415:4673, ack 312, win 508, options [nop,nop,TS val 2099619237 ecr 350978370], length 258
19:32:09.626178 IP CLIENT.51013 > SERVER.https: Flags [.], ack 4673, win 2043, options [nop,nop,TS val 350978384 ecr 2099619237], length 0
19:33:09.651599 IP SERVER.https > CLIENT.51013: Flags [P.], seq 4673:4704, ack 312, win 508, options [nop,nop,TS val 2099679274 ecr 350978384], length 31
19:33:09.651690 IP SERVER.https > CLIENT.51013: Flags [F.], seq 4704, ack 312, win 508, options [nop,nop,TS val 2099679274 ecr 350978384], length 0
19:33:09.678658 IP CLIENT.51013 > SERVER.https: Flags [.], ack 4704, win 2047, options [nop,nop,TS val 351038150 ecr 2099679274], length 0
19:33:09.678806 IP CLIENT.51013 > SERVER.https: Flags [.], ack 4705, win 2047, options [nop,nop,TS val 351038150 ecr 2099679274], length 0
19:33:09.680749 IP CLIENT.51013 > SERVER.https: Flags [P.], seq 312:343, ack 4705, win 2048, options [nop,nop,TS val 351038150 ecr 2099679274], length 31
19:33:09.680749 IP CLIENT.51013 > SERVER.https: Flags [F.], seq 343, ack 4705, win 2048, options [nop,nop,TS val 351038150 ecr 2099679274], length 0
19:33:09.680824 IP SERVER.https > CLIENT.51013: Flags [R], seq 3495014027, win 0, length 0
19:33:09.680888 IP SERVER.https > CLIENT.51013: Flags [R], seq 3495014027, win 0, length 0
Attempt from GCP Instance (Unsuccessful)
# openssl s_client -connect fqdn:443 -servername fqdn -tls1_2 --prexit
CONNECTED(00000003)
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 212 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
[...]
SSL-Session:
Protocol : TLSv1.2
[...]
---
tcpdump from the client that doesn't work
19:36:01.818130 IP CLIENT.55282 > SERVER.https: Flags [S], seq 3880590205, win 65320, options [mss 1350,sackOK,TS val 3904950778 ecr 0,nop,wscale 7], length 0
19:36:01.818241 IP SERVER.https > CLIENT.55282: Flags [S.], seq 1198318204, ack 3880590206, win 65160, options [mss 1460,sackOK,TS val 2676835275 ecr 3904950778,nop,wscale 7], length 0
19:36:01.829890 IP CLIENT.55282 > SERVER.https: Flags [.], ack 1, win 511, options [nop,nop,TS val 3904950791 ecr 2676835275], length 0
19:37:01.890295 IP SERVER.https > CLIENT.55282: Flags [F.], seq 1, ack 1, win 510, options [nop,nop,TS val 2676895347 ecr 3904950791], length 0
19:37:02.105125 IP SERVER.https > CLIENT.55282: Flags [F.], seq 1, ack 1, win 510, options [nop,nop,TS val 2676895562 ecr 3904950791], length 0
19:37:02.321181 IP SERVER.https > CLIENT.55282: Flags [F.], seq 1, ack 1, win 510, options [nop,nop,TS val 2676895778 ecr 3904950791], length 0
19:37:02.753156 IP SERVER.https > CLIENT.55282: Flags [F.], seq 1, ack 1, win 510, options [nop,nop,TS val 2676896210 ecr 3904950791], length 0
19:37:03.617211 IP SERVER.https > CLIENT.55282: Flags [F.], seq 1, ack 1, win 510, options [nop,nop,TS val 2676897074 ecr 3904950791], length 0
19:37:05.345180 IP SERVER.https > CLIENT.55282: Flags [F.], seq 1, ack 1, win 510, options [nop,nop,TS val 2676898802 ecr 3904950791], length 0
19:37:08.769186 IP SERVER.https > CLIENT.55282: Flags [F.], seq 1, ack 1, win 510, options [nop,nop,TS val 2676902226 ecr 3904950791], length 0
19:37:15.681150 IP SERVER.https > CLIENT.55282: Flags [F.], seq 1, ack 1, win 510, options [nop,nop,TS val 2676909138 ecr 3904950791], length 0
Not sure if it matters, but a difference I have observed is the MTU of the networks.
VPN Client can ping the server with up to size 1372
GCP node can ping the server with up to size 1362
Turns out, it was a case of asynchronous routing. Two on-prem sites were advertising the same route but only one of them had the network.
In summary:
SYN: GCP -> SITE A
ACK, SYN: SITE A -> GCP
ACK: GCP -(through SITE B)-> SITE A
FIN: SITE A doesn't like that the ACK came though a different tunnel then the one used to send the SYN.
Terminates the connection and sends a FIN.
Setup:
created a network namespace.
created a veth pair vetha and vethb with vethb end in the
namespace and other in the host.
added an ip 192.168.122.50 to the vethb
Started a redis server in a container in that network namespace
Sending requests to the redis server directly from the client running on same host named as secondaryvm. However, it throws : Failed to connect to Redis: Connection timed out error. Cannot understand why is this happening, so looked at tcpdump stream by sniffing on vetha, same is posted below:
21:48:33.764967 IP (tos 0x0, ttl 64, id 31361, offset 0, flags [DF], proto TCP (6), length 60)
secondaryvm.34540 > 192.168.122.50.6379: Flags [S], cksum 0x75d6 (incorrect -> 0xe169), seq 3863373484, win 64240, options [mss 1460,sackOK,TS val 3417390465 ecr 0,nop,wscale 7], length 0
21:48:38.884975 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.122.50 tell secondaryvm, length 28
21:48:38.885101 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.122.50 is-at 1a:8c:7f:8b:4d:e0 (oui Unknown), length 28
21:49:16.138726 IP (tos 0x0, ttl 64, id 29195, offset 0, flags [DF], proto TCP (6), length 60)
secondaryvm.34544 > 192.168.122.50.6379: Flags [S], cksum 0x75d6 (incorrect -> 0xe563), seq 550142628, win 64240, options [mss 1460,sackOK,TS val 3417432839 ecr 0,nop,wscale 7], length 0
21:49:17.156952 IP (tos 0x0, ttl 64, id 29196, offset 0, flags [DF], proto TCP (6), length 60)
secondaryvm.34544 > 192.168.122.50.6379: Flags [S], cksum 0x75d6 (incorrect -> 0xe169), seq 550142628, win 64240, options [mss 1460,sackOK,TS val 3417433857 ecr 0,nop,wscale 7], length 0
21:49:19.173031 IP (tos 0x0, ttl 64, id 29197, offset 0, flags [DF], proto TCP (6), length 60)
secondaryvm.34544 > 192.168.122.50.6379: Flags [S], cksum 0x75d6 (incorrect -> 0xd989), seq 550142628, win 64240, options [mss 1460,sackOK,TS val 3417435873 ecr 0,nop,wscale 7], length 0
21:49:22.405182 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.122.50 tell secondaryvm, length 28
21:49:22.405262 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.122.50 is-at 1a:8c:7f:8b:4d:e0 (oui Unknown), length 28
21:49:23.429054 IP (tos 0x0, ttl 64, id 29198, offset 0, flags [DF], proto TCP (6), length 60)
secondaryvm.34544 > 192.168.122.50.6379: Flags [S], cksum 0x75d6 (incorrect -> 0xc8e9), seq 550142628, win 64240, options [mss 1460,sackOK,TS val 3417440129 ecr 0,nop,wscale 7], length 0
21:49:31.621030 IP (tos 0x0, ttl 64, id 29199, offset 0, flags [DF], proto TCP (6), length 60)
secondaryvm.34544 > 192.168.122.50.6379: Flags [S], cksum 0x75d6 (incorrect -> 0xa8e9), seq 550142628, win 64240, options [mss 1460,sackOK,TS val 3417448321 ecr 0,nop,wscale 7], length 0
21:49:47.749024 IP (tos 0x0, ttl 64, id 29200, offset 0, flags [DF], proto TCP (6), length 60)
secondaryvm.34544 > 192.168.122.50.6379: Flags [S], cksum 0x75d6 (incorrect -> 0x69e9), seq 550142628, win 64240, options [mss 1460,sackOK,TS val 3417464449 ecr 0,nop,wscale 7], length 0
21:50:20.261084 IP (tos 0x0, ttl 64, id 29201, offset 0, flags [DF], proto TCP (6), length 60)
secondaryvm.34544 > 192.168.122.50.6379: Flags [S], cksum 0x75d6 (incorrect -> 0xeae8), seq 550142628, win 64240, options [mss 1460,sackOK,TS val 3417496961 ecr 0,nop,wscale 7], length 0
21:50:25.381045 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.122.50 tell secondaryvm, length 28
21:50:25.381176 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.122.50 is-at 1a:8c:7f:8b:4d:e0 (oui Unknown), length 28
Redis server is up and the client is getting connected to it according to the terminal output but not according to the tcpdump output. according to tcpdump output, client is trying to connect but didn't achieve the connection establishment successfully.
Terminal output at the client side:
========================100==================================================
terminate called after throwing an instance of 'sw::redis::TimeoutError'
what(): Failed to connect to Redis: Connection timed out
Aborted (core dumped)
Client's code(written in redis-plus-plus):
int main(){
auto redis = Redis("tcp://192.168.122.50:6379);
sleep(5);
int ep = 100;
while(true){
cout<<"===================="<<ep<<"======================\n";
auto pipe = redis.pipeline(false);
for(int i=1; i<=500; i++){
string s = to_string(i);
if(i%2 == 1){
pipe.set(s, s);
}
else {
string st = to_string(i-1);
pipe.get(st);
}
}
auto pipe_replies = pipe.exec();
pipe.discard();
}
According to the terminal's output, it successfully established the connection.
Cannot understand what is happening here.
Is it like line auto redis = Redis("tcp://192.168.122.50:6379"); doesn't establish the connection?
redis-server is surely up then why the connection is not established looking at the tcp stream?
Redis version 6.0.9 and IT IS running on port 6379.
How to prevent this error?
EDIT:
I've followed below steps/commands to set up network namespace:
#!/bin/bash
sudo ip netns ls
sudo ip netns add alpine_network
sudo ip link add name veth-host type veth peer name veth-alpine
sudo ip link set veth-alpine netns alpine_network
sudo ip netns exec alpine_network ip addr add 192.168.122.50/24 dev veth-alpine
sudo ip netns exec alpine_network ip link set veth-alpine up
sudo ip netns exec alpine_network ip link set lo up
sudo ip link set veth-host up
sudo ip route add 192.168.122.50/32 dev veth-host
sudo ip netns exec alpine_network ip route add default via 192.168.122.50 dev veth-alpine
My lab recently procure an HP (Aruba) 2920 24G and I was told to test it out on an OpenDaylight controller.
First, I setup the OpenDaylight Carbon (0.7.2) with dlux features, odl-mdsal-apidocs, odl-restconf, and odl-l2switch-switch installed. The Opendaylight can communicate with my other switches including an SBC running an Open vSwitch, a mininet, Zodiac FX SDN switches, and a Pica8 Switch, but strangely, not with the mentioned HP SDN switch.
I decided to try the HP switch with Opendaylight Hydrogen (the first one), and it worked just fine (though it forced the controller to communicate with OpenFlow 1.0). But I seemed can't make it work with Opendaylight version other than hydrogen (I tried with Carbon, Nitrogen, and Oxygen).
How can I connect that switch, is there anything that I should do before I enable Openflow? Any hints or helps will be appreciated.
Thanks
Here is the TCP dump of my controller
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
05:40:22.762385 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [S], seq 3953235407, win 65535, options [mss 1460,nop,wscale 1,nop,nop,sackOK,nop,nop,TS val 670643980 ecr 0], length 0
05:40:22.762979 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [S.], seq 1719626668, ack 3953235408, win 28960, options [mss 1460,sackOK,TS val 2130420 ecr 670643980,nop,wscale 7], length 0
05:40:22.766268 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [.], ack 1, win 33304, options [nop,nop,TS val 670643980 ecr 2130420], length 0
05:40:22.766515 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1:17, ack 1, win 33304, options [nop,nop,TS val 670643980 ecr 2130420], length 16: OpenFlow
version unknown (0x04), type 0x00, length 16, xid 0x00000154
05:40:22.766559 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 17, win 227, options [nop,nop,TS val 2130421 ecr 670643980], length 0
05:40:23.038345 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 1:25, ack 17, win 227, options [nop,nop,TS val 2130489 ecr 670643980], length 24: OpenFlow
version unknown (0x04), type 0x00, length 16, xid 0x00000015
version unknown (0x04), type 0x05, length 8, xid 0x00000155
05:40:23.241617 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 1:25, ack 17, win 227, options [nop,nop,TS val 2130540 ecr 670643980], length 24: OpenFlow
version unknown (0x04), type 0x00, length 16, xid 0x00000015
version unknown (0x04), type 0x05, length 8, xid 0x00000155
05:40:23.247591 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [.], ack 25, win 33292, options [nop,nop,TS val 670644460 ecr 2130489], length 0
05:40:23.247941 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 17:49, ack 25, win 33292, options [nop,nop,TS val 670644460 ecr 2130489], length 32: OpenFlow
version unknown (0x04), type 0x06, length 32, xid 0x00000155
05:40:23.248228 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 49, win 227, options [nop,nop,TS val 2130541 ecr 670644460], length 0
05:40:23.248247 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [.], ack 25, win 33292, options [nop,nop,TS val 670644460 ecr 2130540], length 0
05:40:23.297400 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 25:33, ack 49, win 227, options [nop,nop,TS val 2130554 ecr 670644460], length 8: OpenFlow
version unknown (0x04), type 0x14, length 8, xid 0x00000000
05:40:23.299582 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 49:57, ack 33, win 33288, options [nop,nop,TS val 670644520 ecr 2130554], length 8: OpenFlow
version unknown (0x04), type 0x15, length 8, xid 0x00000000
05:40:23.299724 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 57, win 227, options [nop,nop,TS val 2130554 ecr 670644520], length 0
05:40:23.854453 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 33:49, ack 57, win 227, options [nop,nop,TS val 2130693 ecr 670644520], length 16: OpenFlow
version unknown (0x04), type 0x12, length 16, xid 0x00000000
05:40:23.858279 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 57:1129, ack 49, win 33280, options [nop,nop,TS val 670645070 ecr 2130693], length 1072: OpenFlow
version unknown (0x04), type 0x13, length 1072, xid 0x00000000
05:40:23.858532 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 1129, win 243, options [nop,nop,TS val 2130694 ecr 670645070], length 0
05:40:25.303081 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 49:97, ack 1129, win 243, options [nop,nop,TS val 2131055 ecr 670645070], length 48: OpenFlow
version unknown (0x04), type 0x12, length 16, xid 0x00000001
version unknown (0x04), type 0x12, length 16, xid 0x00000002
version unknown (0x04), type 0x12, length 16, xid 0x00000003
05:40:25.306476 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 97:105, ack 1129, win 243, options [nop,nop,TS val 2131056 ecr 670645070], length 8: OpenFlow
version unknown (0x04), type 0x14, length 8, xid 0x00000004
05:40:25.307288 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1129:1161, ack 97, win 33256, options [nop,nop,TS val 670646520 ecr 2131055], length 32: OpenFlow
version unknown (0x04), type 0x13, length 32, xid 0x00000001
05:40:25.307606 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 1161, win 243, options [nop,nop,TS val 2131056 ecr 670646520], length 0
05:40:25.307650 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1161:1217, ack 97, win 33256, options [nop,nop,TS val 670646520 ecr 2131055], length 56: OpenFlow
version unknown (0x04), type 0x13, length 56, xid 0x00000002
05:40:25.307686 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 1217, win 243, options [nop,nop,TS val 2131056 ecr 670646520], length 0
05:40:25.307714 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1217:1553, ack 97, win 33256, options [nop,nop,TS val 670646520 ecr 2131055], length 336: OpenFlow
version unknown (0x04), type 0x13, length 336, xid 0x00000003
05:40:25.307732 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 1553, win 260, options [nop,nop,TS val 2131056 ecr 670646520], length 0
05:40:25.308882 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1553:1561, ack 105, win 33252, options [nop,nop,TS val 670646530 ecr 2131056], length 8: OpenFlow
version unknown (0x04), type 0x15, length 8, xid 0x00000004
05:40:25.308989 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 1561, win 260, options [nop,nop,TS val 2131056 ecr 670646530], length 0
05:40:26.528768 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 105:121, ack 1561, win 260, options [nop,nop,TS val 2131361 ecr 670646530], length 16: OpenFlow
version unknown (0x04), type 0x12, length 16, xid 0x00000005
05:40:26.531364 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1561:1649, ack 121, win 33244, options [nop,nop,TS val 670647750 ecr 2131361], length 88: OpenFlow
version unknown (0x04), type 0x13, length 88, xid 0x00000005
05:40:26.531491 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 1649, win 260, options [nop,nop,TS val 2131362 ecr 670647750], length 0
05:40:26.616425 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 121:145, ack 1649, win 260, options [nop,nop,TS val 2131383 ecr 670647750], length 24: OpenFlow
version unknown (0x04), type 0x18, length 24, xid 0x00000006
05:40:26.618757 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1649:1673, ack 145, win 33232, options [nop,nop,TS val 670647840 ecr 2131383], length 24: OpenFlow
version unknown (0x04), type 0x19, length 24, xid 0x00000006
05:40:26.618815 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 1673, win 260, options [nop,nop,TS val 2131384 ecr 670647840], length 0
05:40:26.634375 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 145:169, ack 1673, win 260, options [nop,nop,TS val 2131388 ecr 670647840], length 24: OpenFlow
version unknown (0x04), type 0x18, length 24, xid 0x00000007
05:40:26.636584 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1673:1697, ack 169, win 33220, options [nop,nop,TS val 670647850 ecr 2131388], length 24: OpenFlow
version unknown (0x04), type 0x19, length 24, xid 0x00000007
05:40:26.673259 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 1697, win 260, options [nop,nop,TS val 2131398 ecr 670647850], length 0
05:40:26.757717 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 169:225, ack 1697, win 260, options [nop,nop,TS val 2131419 ecr 670647850], length 56: OpenFlow
version unknown (0x04), type 0x12, length 56, xid 0x00000008
05:40:26.760788 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1697:1889, ack 225, win 33192, options [nop,nop,TS val 670647980 ecr 2131419], length 192: OpenFlow
version unknown (0x04), type 0x13, length 192, xid 0x00000008
05:40:26.761396 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 1889, win 277, options [nop,nop,TS val 2131420 ecr 670647980], length 0
05:40:27.341945 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 225:233, ack 1889, win 277, options [nop,nop,TS val 2131565 ecr 670647980], length 8: OpenFlow
version unknown (0x04), type 0x14, length 8, xid 0x00000009
05:40:27.344842 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1889:1897, ack 233, win 33188, options [nop,nop,TS val 670648560 ecr 2131565], length 8: OpenFlow
version unknown (0x04), type 0x15, length 8, xid 0x00000009
05:40:27.344983 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 1897, win 277, options [nop,nop,TS val 2131565 ecr 670648560], length 0
05:40:27.353082 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 233:249, ack 1897, win 277, options [nop,nop,TS val 2131567 ecr 670648560], length 16: OpenFlow
version unknown (0x04), type 0x12, length 16, xid 0x0000000a
05:40:27.355175 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1897:1913, ack 249, win 33180, options [nop,nop,TS val 670648570 ecr 2131567], length 16: OpenFlow
version unknown (0x04), type 0x13, length 16, xid 0x0000000a
05:40:27.368322 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 249:273, ack 1913, win 277, options [nop,nop,TS val 2131571 ecr 670648570], length 24: OpenFlow
version unknown (0x04), type 0x12, length 24, xid 0x0000000b
05:40:27.370344 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1913:1929, ack 273, win 33168, options [nop,nop,TS val 670648590 ecr 2131571], length 16: OpenFlow
version unknown (0x04), type 0x13, length 16, xid 0x0000000b
05:40:27.379058 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 273:297, ack 1929, win 277, options [nop,nop,TS val 2131574 ecr 670648590], length 24: OpenFlow
version unknown (0x04), type 0x12, length 24, xid 0x0000000c
05:40:27.381262 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1929:1945, ack 297, win 33156, options [nop,nop,TS val 670648600 ecr 2131574], length 16: OpenFlow
version unknown (0x04), type 0x13, length 16, xid 0x0000000c
05:40:27.392610 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 297:321, ack 1945, win 277, options [nop,nop,TS val 2131577 ecr 670648600], length 24: OpenFlow
version unknown (0x04), type 0x12, length 24, xid 0x0000000d
05:40:27.394715 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1945:1961, ack 321, win 33144, options [nop,nop,TS val 670648610 ecr 2131577], length 16: OpenFlow
version unknown (0x04), type 0x13, length 16, xid 0x0000000d
05:40:27.415032 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 321:345, ack 1961, win 277, options [nop,nop,TS val 2131583 ecr 670648610], length 24: OpenFlow
version unknown (0x04), type 0x12, length 24, xid 0x0000000e
05:40:27.417823 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 1961:2537, ack 345, win 33132, options [nop,nop,TS val 670648640 ecr 2131583], length 576: OpenFlow
version unknown (0x04), type 0x13, length 576, xid 0x0000000e
05:40:27.457328 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 2537, win 294, options [nop,nop,TS val 2131594 ecr 670648640], length 0
05:40:27.854786 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [P.], seq 345:353, ack 2537, win 294, options [nop,nop,TS val 2131693 ecr 670648640], length 8: OpenFlow
version unknown (0x04), type 0x14, length 8, xid 0x0000000f
05:40:27.856998 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [P.], seq 2537:2545, ack 353, win 33128, options [nop,nop,TS val 670649070 ecr 2131693], length 8: OpenFlow
version unknown (0x04), type 0x15, length 8, xid 0x0000000f
05:40:27.857080 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 2545, win 294, options [nop,nop,TS val 2131693 ecr 670649070], length 0
05:40:28.077260 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [F.], seq 353, ack 2545, win 294, options [nop,nop,TS val 2131748 ecr 670649070], length 0
05:40:28.080095 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [.], ack 354, win 33127, options [nop,nop,TS val 670649300 ecr 2131748], length 0
05:40:28.080717 IP 10.10.5.91.61524 > 10.10.5.101.6633: Flags [FP.], seq 2545, ack 354, win 33127, options [nop,nop,TS val 670649300 ecr 2131748], length 0
05:40:28.081006 IP 10.10.5.101.6633 > 10.10.5.91.61524: Flags [.], ack 2546, win 294, options [nop,nop,TS val 2131749 ecr 670649300], length 0
someone else recently made a post about HP switches not connecting to ODL, but
I cannot find that post to reference?
I would check the switch logs. the packet capture seems to indicate there is
some communication between the switch and controller:6633.
you can also look for clues in OpenDaylight's karaf.log file
at the end of the day, since your other switches are connecting fine you
probably will have to find HP switch support, more-so that OpenDaylight
support.
I've stumbled across a problem way beyond my area of expertise, and I don't have a mentor to turn to for help with this.
I have a receipt printer I need to interface with through an iOS app. The printer is located on the same network as the device(s), so I can address it through supported "Line Mode commands"
What I'd like to do is keep the code I have already that works cross-platform – i.e. it's a UIView/NSView, and if you're not familiar with OS X/iOS, it's just a standard vanilla view that I can render into PDF/PNG formats. Thankfully, the printer has a "raster graphics" mode that seems to be what I need.
Unfortunately, be it the broken English of the command spec, or my complete lack of knowledge of anything beyond basic C, or my complete lack of knowledge regarding graphics, I have no idea how to even get started from the command specifications I have. I know the printer and my networking works because I can address it over the network and send it basic feed commands. But, I have no idea how to go from a PNG -> whatever the printer needs to make it's 'raster mode' work.
The specification is available at http://www.star-m.jp/eng/service/usermanual/linemode_cm_en.pdf , and the page you'd want to start reading it if you want to help is 3-68, and the specific commands I'm having trouble even getting started with are on 3-78/3-79.
I can give you nothing but a checkmark but I assure you, you'll have my undying gratitude if you can even provide me even a point in the right direction.
Having written a few printer drivers I can confirm that generally the documentation is confusing because of the way printers work. The document that you refer to doesn't actually seem to bad to me.
I think you're right to be printing in raster mode and that overall this is going to give the best results.
From the Star documentation I reckon you'll need to send :
1. \x1b*rR Initialize raster mode
2. \x1b*rA Enter raster mode
3. \x1b*rC Clear raster data
4. \x1b*rml
4. b\x##\x##\xAA\xAA\xAA....<DATA>..........
5. \x1b\x0C\x00 Raster Form feed(??) - should spit out the data.
6. \x1b*rB Clear raster data
Obv. in the above \x1b is the C encoding of ESC (i.e. character 27 0x1b).
From all of the documentation that I've been reading the following is how the images should be formatted in raster mode. When in line mode it is completely different as the vertical & horizontal are swapped. From THERMAL PRINTER PROGRAMMER'S MANUAL (TSP552,TSP552II,TSP2000)
This equates to the following bytes stream.
On the 4th command line it is effectively 'b' followed by two bytes definining the size. This size is computed as the number of pixels contained in the stream % 256 and / 256. So for 320x1 that'd 0x40,0x01
So, taking the above and plugging it into a simple test program you should test with this:
char rasterImage [] = {
0x1b, '*', 'r', 'R', // Initialize raster mode
0x1b, '*', 'r', 'A', // Enter raster mode
0x1b, '*', 'r', 'C', // Clear raster data
// n1 n2 d1 d2..
0x1b, 'b', 0x2, 0, 0x00, 0x00, // data
0x1b, 'b', 0x2, 0, 0x1F, 0xF8,
0x1b, 'b', 0x2, 0, 0x3F, 0xFC,
0x1b, 'b', 0x2, 0, 0x77, 0xEE,
0x1b, 'b', 0x2, 0, 0xF8, 0x1F,
0x1b, 'b', 0x2, 0, 0xF8, 0x1F,
0x1b, 'b', 0x2, 0, 0xF8, 0x1F,
0x1b, 'b', 0x2, 0, 0x0F, 0xF0,
0x1b, 'b', 0x2, 0, 0x1F, 0xF8,
0x1b, 'b', 0x2, 0, 0x1F, 0xF8,
0x1b, 'b', 0x2, 0, 0x3E, 0x7C,
0x1b, 'b', 0x2, 0, 0x38, 0x1C,
0x1b, 'b', 0x2, 0, 0x79, 0x9E,
0x1b, 'b', 0x2, 0, 0x73, 0xCE,
0x1b, 'b', 0x2, 0, 0x73, 0xCE,
0x1b, 'b', 0x2, 0, 0xF9, 0x9F,
0x1b, 'b', 0x2, 0, 0xF8, 0x1F,
0x1b, 'b', 0x2, 0, 0xFE, 0x7F,
0x1b, 'b', 0x2, 0, 0xFF, 0xFF,
0x1b, 'b', 0x2, 0, 0xFF, 0xFF,
0x1b, 'b', 0x2, 0, 0x00, 0x00,
0x1b, 'b', 0x2, 0, 0x00, 0x00,
0x1b, 'b', 0x2, 0, 0x00, 0x00,
0x1b, 'b', 0x2, 0, 0x00, 0x00};
[self.currentDataBeingSent appendBytes:rasterImage length:sizeof(rasterImage)];
Simply squirt that out to the printer and you should get a picture as above. This is where you can easily tweak and play about with the exact commands to get something that's working. Often this is the only way I've ever managed to figure out what should be done.
rev.3
Ref. comments.
If you have a byte per pixel then you will need to merge these into a series of bits; the following should do the job based on your pastebin code. I've also changed the char* to be unsigned as it is signed can cause problems when bit manipulating.
NSUInteger bitmapBytePerRow = width/8;
NSUInteger bytesPerRow = 3 + bitmapBytePerRow;
[self.currentDataBeingSent = [NSMutableData dataWithLength:bytesPerRow * height];
[self.currentDataBeingSent appendBytes:initializeRaster length:sizeof(initializeRaster)];
[self.currentDataBeingSent appendBytes:enterRaster length:sizeof(enterRaster)];
NSUInteger byteOffset = 0;
for (NSUInteger y = 0; y < height; y++)
{
unsigned char *rasterCommandForRow = (unsigned char *)calloc(bytesPerRow, sizeof(char));
unsigned char *current_raster = rasterCommandForRow;
*current_raster++ = '\x6B';
*current_raster++ = (width*height) % 256;
*current_raster++ = (width*height) / 256;
unsigned char mask = '\x80' ;
unsigned char out = 0 ;
for (NSUInteger x = 0; x < width; x++)
{
if (*(data + (byteOffset * sizeof(char))))
out |= mask ;
byteOffset++;
mask >>= 1 ;
if( 0 == mask )
{
mask = '\x80' ;
*current_raster++ = out ;
if( out )
lastDot = nextOut ;
out = 0 ;
}
}
// handle partially finished byte .
if( ( '\x80' != mask ) && ( 0 != out ) )
*current_raster++ = out ;
[self.currentDataBeingSent appendBytes:rasterCommandForRow length:bytesPerRow];
}
rev.3a
Looking at the Mac CUPS support from Star it's got the source code for the driver which contains a lot of clues about how this should be done. Sometimes code is so much easier to read than documentation.
starcupsdrv-3.1.1_mac_20100423.zip\starcupsdrv-3.1.1_mac\SourceCode\
contains starcupsdrv-src-3.1.1.tar.gz\ sub folder starcupsdrv\src\
View rastertostar.c, the important bit is the calculation of the n1 / n2 values. These aren't at all X & Y but based on the pixel count, lastBlackPixel is the count of pixels from the source.
putchar('b');
putchar((char) ((lastBlackPixel > 0)?(lastBlackPixel % 256):1));
putchar((char) (lastBlackPixel / 256));
I've modified the code above to include the fixes, hopefully that'll be closer. If not post a scan of what comes out of the printer, it will be useful to diagnose what's happening.
For reference The code between 580:650 from jsStarUSB.cpp seems to me to be along the lines of what you need to produce a buffer (stored in nextOut) that contains the raster data in the format to be sent directly to the printer.
rev. 4 (2023)
Joshua May advises in the comments that rasterImage doesn't need the ESC (0x1b) on each row - only the 'b' and that by just removing the 0x1b "worked for me".
I have a hunch this might be the same as the old Seiko printers, only yours is network enabled. If so, have a look at the C code here. It tries to output to a serial port /dev/cua, where it thinks the printer is.
But if the commands are the same, the code should help you. It takes as input the Portable Bitmap Format, which is plain ASCII text.
But I don't know. Microsoft indicates Star Micronics works the same as Epson LQ, in which case there is ample documentation.
Related links:
ESC/POS PDF Documentation, hundreds of pages
Command codes from the STAR website
Update! ;-) Try this, totally untested code:
/* Call with grayscale images of height 256, width 256. */
- (void) outputraster(char* pixels, int rows)
{
const char initializeRaster[] = "\x1B\x2A\x72\x52";
const char enterRaster[] = "\x1B\x2A\x72\x41";
const char formFeed[] = "\x1B\x0C\x00";
const char clearRaster[] = "\x1B\x2A\x72\x43";
const char exitRaster[] = "\x1B\x2A\x72\x42";
/* The FF means 255 lines: */
char setRasterPageLength[] "\x1B\x2A\x72\x50\xFF\x0";
/* The FF FF means 256 lines and 256 rows: */
char sendRasterData[] = "\x62\xFF\xFF";
[self sendBytes:initializeRaster ofLength:sizeof(initializeRaster)];
[self sendBytes:enterRaster ofLength:sizeof(enterRaster)];
[self sendBytes:clearRaster ofLength:sizeof(clearRaster)];
[self sendBytes:setRasterPageLength ofLength:sizeof(setRasterPageLength)];
[self sendBytes:sendRasterData ofLength:sizeof(sendRasterData)];
while (rows)
{
for (int x = 0; x < 255; x++)
{
[self sendBytes:pixels[x] ofLength:256];
}
rows --;
}
}
Update!
I was looking at the docs at night, and stumbled upon how you can print out a prestored logo. Then I looked at how to define that logo, and that part of the documentation looked a lot more thorough:
Explanations of bitmap format for a similar printer:
Also, look at pages 34 and on for an explanation of the bitmap format of a Star printer.
I hope this helps someone, but I was trying to use the code from Richard Harrison above to print the phone raster in Python...
I on my system I can run python3 raster.py > /dev/usb/lp0 and I get the expected output!! Hopefully it shows what you need. I cross refrenced the bytes of a file that would print, and also the graphical mode manual.
import sys
buf = [
0x1b, ord('*'), ord('r'), ord('A'), # enter raster mode
0x1b, ord('*'), ord('r'), ord('P'), ord('0'), 0x00, # continuous mode
ord('b'), 0x2, 0, 0x00, 0x00,
ord('b'), 0x2, 0, 0x1F, 0xF8,
ord('b'), 0x2, 0, 0x3F, 0xFC,
ord('b'), 0x2, 0, 0x77, 0xEE,
ord('b'), 0x2, 0, 0xF8, 0x1F,
ord('b'), 0x2, 0, 0xF8, 0x1F,
ord('b'), 0x2, 0, 0xF8, 0x1F,
ord('b'), 0x2, 0, 0x0F, 0xF0,
ord('b'), 0x2, 0, 0x1F, 0xF8,
ord('b'), 0x2, 0, 0x1F, 0xF8,
ord('b'), 0x2, 0, 0x3E, 0x7C,
ord('b'), 0x2, 0, 0x38, 0x1C,
ord('b'), 0x2, 0, 0x79, 0x9E,
ord('b'), 0x2, 0, 0x73, 0xCE,
ord('b'), 0x2, 0, 0x73, 0xCE,
ord('b'), 0x2, 0, 0xF9, 0x9F,
ord('b'), 0x2, 0, 0xF8, 0x1F,
ord('b'), 0x2, 0, 0xFE, 0x7F,
ord('b'), 0x2, 0, 0xFF, 0xFF,
ord('b'), 0x2, 0, 0xFF, 0xFF,
ord('b'), 0x2, 0, 0x00, 0x00,
ord('b'), 0x2, 0, 0x00, 0x00,
ord('b'), 0x2, 0, 0x00, 0x00,
ord('b'), 0x2, 0, 0x00, 0x00,
0x1b, ord('*'), ord('r'), ord('b') # end raster mode
]
blob = bytearray(buf)
sys.stdout.buffer.write(blob)
EDIT: Off the back of this, I created a Python library that will take an image and convert it into the required raster commands... https://pypi.org/project/StarTSPImage/