I did some work to transplant TCP/IP stack to MCU. Through GPRS, MCU can connect internet.
However, I met with some trouble during LCP negotiation.The following is my solution referring networking material
In order to make MCU PPP simpler.The LCP option request will be respond with rejection.
Server:7e ff 03 c0 21 01 01 00 14 02 06 00 00 00 00 05 06 b0 70 9c c3 07 02 08 02 54 06 7e
MCU:7e ff 03 c0 21 04 01 00 04 02 06 00 00 00 00 05 06 b0 70 9c c3 07 02 08 02 69 78 7e
A authentication request is expected in the second step. But i get a none LCP option request.
Server:7e ff 03 c0 21 01 02 00 04 b5 5a 7e
This means server forces MCU to start LCP negotiation.I am missing.
I send a authentication option request to server so that forcing server to start authentication option negotiation.Server respond me two packets.One is a ACK packet for authentication request.The another still is the none LCP option.
MCU:7e ff 03 c0 21 01 05 00 08 03 04 C0 23 ac 56 7e
Server:7e ff 03 c0 21 02 05 00 08 03 04 C0 23 bd 34 7e
Server:7e ff 03 c0 21 01 02 00 04 b5 5a 7e
After several "none option" request, The negotiation over. What should I do? I am l
(My english is not good .I hope you can understand my means.)
When you respond with Configure-Reject when modem sends Configure-Request. Then modem will send a new modified Configure-Request. See RFC1661 chapter 6.4.
So you should respond with Configure-Ack when Configure-Request contains suitable values for you. So you should send Configure-Ack after the second Configure-Request.
Related
I have two different UICCs with USIM applications installed.
With the first card, I can access the USIM EFs without needing to first select the application if I know the file ID of the ADF (which this particular case is 7FF0).
00 A4 08 0C 04 7FF0 6F07 (select by path from MF)
I found the file ID by looking at the FCP template for the ADF.
SELECT EF-DIR
Command: 00 A4 00 0C 02 2F00
SW: 9000
READ RECORD
Command: 00 B2 00 02 00 (next record)
SW: 6C26
61 18
4F 10 A0000000871002FFFFFFFF8903050001 AID
50 04 5553494D USIM
SELECT AID
Command: 00 A4 04 0C 10 A0000000871002FFFFFFFF8903050001
SW: 9000
STATUS (after selecting AID)
Command: 80 F2 01 00 00
SW: 6C38
62 36
82 02 7821 File descriptor
83 02 7FF0 File identifier
84 10 A0000000871002FFFFFFFF8903050001 DF name (AID)
8A 01 05 Life cycle indicator
8B 03 2F0609 Security attributes
C6 0C PIN status template DO
90 01 60
83 01 01
83 01 81
83 01 0A
81 04 00002C48
However, when I try and do the same with the second card, I found that the FCP template does not include a file ID, and I need to first select the application, and then select the EF.
00 A4 04 0C 0C A0000000871002FF49FF0589 (select by DF name)
00 A4 00 0C 02 6F07 (Select by file ID)
SELECT EF-DIR
Command: 00 A4 00 0C 02 2F00
SW: 9000
READ RECORD
Command: 00 B2 00 02 00 (next record)
SW: 6C26
61 14
4F 0C A0000000871002FF49FF0589 AID
50 04 5553494D USIM
SELECT AID
Command: 00 A4 04 0C 0C A0000000871002FF49FF0589
SW: 9000
STATUS (after selecting AID)
Command: 80 F2 01 00 00
SW: 6C2A
62 28
82 02 7821 File descriptor
84 0C A0000000871002FF49FF0589 DF name (AID)
8A 01 05 Life cycle indicator
8B 03 2F0601 Security attributes
C6 0C PIN status template DO
90 01 A0
83 01 81
83 01 01
83 01 0A
My questions are:
Why are the two USIM applications configured differently, where one allows access to the application's files directly by specifying a path from the MF, and the other does not; only allowing access relative to the ADF after first selecting the application?
Are there security benefits to not allowing direct access?
Does one method better facilitate access to files in a multi-application environment?
I use Nginx 1.19.6 and OpenSSL 1.1.1i.
But I checked my server support client-initiated secure renegotiation... (https://www.immuniweb.com/ssl/?id=Ek4FSF6C)
I don't know why my server supports client-initiated secure renegotiation.
Check Code:
openssl s_client -connect gjan.info:443 -msg -tls1_2
Result:
---
R
RENEGOTIATING
>>> ??? [length 0005]
16 03 03 00 f6
>>> TLS 1.2, Handshake [length 00de], ClientHello
01 00 00 da 03 03 cb bf ab b8 6f a1 31 14 2d fb
ad 63 aa d2 15 c6 5d fc 8c 19 fc db 4c 7f 5b d8
f1 f1 fd f3 29 fa 00 00 36 c0 2c c0 30 00 9f cc
a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00
6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0
13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 01
00 00 7b ff 01 00 0d 0c 1b a5 84 2c 92 28 da 6e
0c 84 5f c4 00 00 00 0e 00 0c 00 00 09 67 6a 61
6e 2e 69 6e 66 6f 00 0b 00 04 03 00 01 02 00 0a
00 0c 00 0a 00 1d 00 17 00 1e 00 19 00 18 00 23
00 00 00 16 00 00 00 17 00 00 00 0d 00 30 00 2e
04 03 05 03 06 03 08 07 08 08 08 09 08 0a 08 0b
08 04 08 05 08 06 04 01 05 01 06 01 03 03 02 03
03 01 02 01 03 02 02 02 04 02 05 02 06 02
<<< ??? [length 0005]
15 03 03 00 1a
<<< TLS 1.2, Alert [length 0002], warning no_renegotiation
01 64
>>> ??? [length 0005]
15 03 03 00 1a
>>> TLS 1.2, Alert [length 0002], fatal handshake_failure
02 28
547636304368:error:14094153:SSL routines:ssl3_read_bytes:no renegotiation:../ssl/record/rec_layer_s3.c:1560:
Is just ImmuniWeb error or really my web server supported? If supported how can I disable?
It's just immuniweb. Qualys/ssllabs correctly shows
Secure Renegotiation Supported
Secure Client-Initiated Renegotiation No
Insecure Client-Initiated Renegotiation No
The first means the RFC5746 negotiation during handshake works; the second and third mean actual renegotiation initiated by the client fails.
PS: this isn't really a programming question or problem, but as long as others haven't voted to close I won't bother.
It might not be possible to use a setting in nginx to solve this security issue. However, you might refer nginx developers to this answer so they can make proper changes in their codebase. This is NOT just immuniweb as the other answer indicates.
The SSL_OP_NO_RENEGOTIATION option were added in OpenSSL 1.1.1. To make immuniweb give you the same score as we have (A+) you need to set SSL_OP_NO_RENEGOTIATION in order to disable all renegotiation in TLSv1.2 and earlier. This needs to be set where the SSL_CTX is created. You might also need to make additional changes in order to get the wanted scoring.
SSL_CTX *ssl_ctx = SSL_CTX_new(TLS_method());
...
SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_RENEGOTIATION);
Source: SSL_CTX_set_options man 1.1.1
It's currently 04:40 AM and I am stuck on something I simply do not understand. I am trying to look up a domain's nameservers directly by using the DNS protocol. If I send a host -t ns google.com 1.1.1.1 and monitor it with Wireshark, I can see the full query of the DNS query. However, I cannot figure out, why some ASCII characters are used one time, but not another time. Here is an example:
0000 70 4d 7b 94 dd e0 00 d8 61 a9 c5 ec 08 00 45 00 pM{.....a.....E.
0010 00 38 d6 ff 00 00 80 11 9f 50 c0 a8 01 bb 01 01 .8.......P......
0020 01 01 e8 40 00 35 00 24 a0 19 9e f7 01 00 00 01 ...#.5.$........
0030 00 00 00 00 00 00 06 67 6f 6f 67 6c 65 03 63 6f .......google.co
0040 6d 00 00 02 00 01 m.....
In this DNS query, I am looking up the nameservers for google.com. The actual query starts at 06 07.
06 in ASCII is ACK/Acknowledgment.
Now, if we take a look at gmail.com instead:
0000 70 4d 7b 94 dd e0 00 d8 61 a9 c5 ec 08 00 45 00 pM{.....a.....E.
0010 00 37 d7 00 00 00 80 11 9f 50 c0 a8 01 bb 01 01 .7.......P......
0020 01 01 e8 58 00 35 00 23 8f cc 6f e2 01 00 00 01 ...X.5.#..o.....
0030 00 00 00 00 00 00 05 67 6d 61 69 6c 03 63 6f 6d .......gmail.com
0040 00 00 02 00 01 .....
the query starts at 05 67 instead.
05 is ENQ/Enquiry.
Why are they different? If I try to send 06 instead of 05 the DNS server gives me no response but Wireshark tells me:
Unknown extended label
I've seen 05, 06, and 09 so far. 09 is my biggest "wat" of all time, because it's a HT/Horizontal Tab.
Anyone with a lot of DNS knowledge who can help me here? I'm not looking for "just use dig/nslookup/host command". I'm currently trying to research a bit on the DNS protocol, and this is a thing I do not understand.
Good read where I got a lot of help: http://dev.lab427.net/dns-query-wth-netcat.html
For a binary protocols like this, you can't assume each byte corresponds to the matching ASCII character.
Take a look at section 4.1.2 of the DNS RFC (https://www.ietf.org/rfc/rfc1035.txt).
The domain name in a DNS request is broken up into "labels". For each label, the first byte is the length of the label, then the bytes for the string are written.
For your Google.com example, the labels are "google" and "com". The 06 is the number of bytes in the first label. This is followed by the bytes for "google". Then the 03 is the number of bytes in the "com" label. After the "com" bytes, the 00 byte is the NULL label to mark the end.
Hello Every one
I'm currently working on a project that takes data from patients monitors and send them to another system that we built (Not the central station -which display all monitors- which is already working but it is closed source.).
The monitor is supplied with an Ethernet card and it sends data over the UDP protocol. But when we need to read real data which is in the application layer we understand nothing.
Here is a small frame we get from the traffic when the monitor talks to the central station.
0000 ff ff ff ff ff ff 66 76 84 00 18 73 08 00 45 00
0010 00 2e 00 00 40 00 40 11 7a 03 c0 a8 00 14 ff ff
0020 ff ff a4 10 1f 42 00 1a 04 45 ff d0 00 02 00 fe
0030 00 0a 32 01 02 03 04 05 0b 32 33 50
When I but it on wireshark it analyze until the UDP protocol and stop, it doesn't understand the application layer data.
Here is a sample application layer data.
ff d0 00 02 00 fe 00 0a 32 01 02 03 04 05 0b 32 33 50
Another one:
ff da 7f f1 00 04 00 0c 02 18 0d 0f 60 0c 04 0b 0b 10 00 00
Are there any standard protocols that used in medical field to transport data like ECG, respiration, etc.? And is there a protocol that is compatible with the form above?
Please stop there!
Get the specification or documentation from the vendor and do not reverse engineer the protocol. If you are unable to do so, leave this thing alone.
If you get it wrong you are endangering patients. Doctor may rely on your information which you are guessing as it seems.
Even if it something well documented like HL7 oder DICOM read the documentation and talk with the vendor.
Depending on jurisdiction there may be a myriad of legal problems ahead.
It may be transmitting in HL7
http://www.hl7.org/index.cfm
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I've recorded some network traffic in my home that only appear up while running BitTorrent or uTorrent.
I've been reading the bittorrent protocol descriptions, but I am stuck trying to figure out a particular network flow.
Can someone help me identify what the following bittorrent network traffic is exactly?
It lasts quite a long time, even after stopping downloads.
All packets are in one direction - from my local machine running Bittorrent to a remote machine.
Here is data payload of one packet (copied from Wireshark):
00000000 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000010 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000020 20 5a 01 45 bd 13 b1 65 01 04 44 4a e7 d5 04 04 Z.E...e ..DJ....
00000030 01 00 00 00 05 02 ea cf ........
All the packets in the network flow are similar, here are two more:
00000038 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000048 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000058 20 5a 01 45 bd 13 b1 65 01 04 08 8e 35 9f 04 04 Z.E...e ....5...
00000068 01 00 00 00 05 02 ea cf ........
00000070 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000080 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000090 20 5a 01 45 bd 13 b1 65 01 04 12 3e ba 6c 04 04 Z.E...e ...>.l..
000000A0 01 00 00 00 05 02 ea cf ........
These bittorrent packets are typically several seconds apart, and this flow seems to go on indefinitely. Which one of the bittorrent protocols describes this network flow?
I just sent a response to you on our mailing list, but I'm gonna post here too in case anyone else stumbles across it and finds it useful.
They're Teredo packets (with no payload). Wireshark can decode these
but it doesn't do so without coercion.
http://en.wikipedia.org/wiki/IPv6_packet
http://en.wikipedia.org/wiki/Teredo_tunneling
One of your packets dissected:
IP Version: 6
Traffic Class: 0 0
Flow Label: 0 00 00
Payload Length: 00 00
Next Header: 3b (indicates that there is no payload present)
Hop Limit: 15
Source: 20 01 00 00 9d 38 6a b8 04 b9 18 bf 9c 90 d8 81
Destination: 20 01 00 00 9d 38 6a b8 20 5a 01 45 bd 13 b1 65
The source and destination also encode the source and destination
public ipv4 addresses and ports.
The hop-by-hop options header (in type-length-value format) follows in
this case. The possible types can be found here:
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
So we have this:
01 04: c3 ae 60 38 ("PadN", random bytes)
04 04: 01 00 00 00 ("Tunnel Encapsulation Limit")
05 02: ea cf ("Router Alert")
No clue what the value of the router alert field is here. I would
expect it to be listed here:
http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xml
But it looks like either that's out of date or the Teredo
implementation you're using is doing something non-standard (or
there's something I've missed).
Anyways, these are clearly keep-alive packets. We're not directly
triggering them in the client as far as I know. I believe they're sent
by your Teredo driver to keep your tunnels open.