I hope this is the correct location for a question like I am asking here (I am new to asking questions on stackoverflow)
I am working on a project with a processor to access the registers of an SFP (connected to the I2C-bus of the processor).
Obviously it is not working (at least not always), but to clarify I want to mention what is working ... The setup fo the processor and the I2C bus is working properly. Other devices on the bus work flawlessly.
At the moment I am using a Raspberry Pi and its I2C capabilities to troubleshoote my project.
The hardware to connect the SFP-interface to the I2C pins of the Raspberry Pi I built myself (and there may be some error in it), but as I am trying different SFPs I see some are working properly.
These are working:
GLC-T, GLC-SX-MM
The following did not work (with an i2detect command from the RPi it does not see any responding device):
GLC-SX-MMD, SFP-10G-SR, PAN-SFP-PLUS-SR-CMT (The last one is from PaloAlto, all others are from Cisco)
I tried to follow the specifications from INF-8074 (https://www.10gtek.com/templates/wzten/pdf/INF-8074.pdf) to make the proper connections and for some SFPs it seems to be working. Even though I cannot verify all the registers' accuracy, there are parts (like the description of the SFP) which show up clearly ... below is the output of the GCL-T:
mordin#ubuntu:~$ sudo i2cdump -y 1 0x50
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 03 04 00 00 00 00 08 00 00 00 00 01 0d 00 00 00 ??....?....??...
10: 00 00 64 00 43 49 53 43 4f 2d 4d 45 54 48 4f 44 ..d.CISCO-METHOD
20: 45 20 20 20 01 00 00 00 53 50 37 30 34 31 5f 52 E ?...SP7041_R
30: 65 76 5f 46 20 20 20 20 46 20 20 20 41 0c c1 5a ev_F F A??Z
40: 00 10 00 00 30 30 30 30 30 4d 54 43 31 35 33 39 .?..00000MTC1539
50: 30 31 45 51 31 31 30 39 32 31 30 31 00 00 00 3c 01EQ11092101...<
60: 00 00 0e fa 99 1c 0a 21 57 89 b6 80 c0 8a 20 a0 ..?????!W????? ?
70: f7 c2 a9 00 00 00 00 00 00 00 00 00 46 a1 08 57 ???.........F??W
80: 43 4e 53 38 54 55 54 41 41 42 33 30 2d 31 34 31 CNS8TUTAAB30-141
90: 30 2d 30 33 00 00 00 00 00 00 00 00 00 00 00 c3 0-03...........?
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 47 4c 43 2d 54 20 20 20 20 20 20 20 20 20 20 20 GLC-T
d0: 20 20 20 20 ff ff ff ff ff ff ff ff ff ff ff ff ............
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
There are multiple projects online ... and they all describe their workflow, and it sounds like as long as you make proper physical connections (power, I2C-pins) it should "just work" to have access to the registers of the connected SFP.
Now I am not sure ... did I miss something when I made my physical connections and some SFPs are just working accidently?
Just for "fun" I tried to pin the "TX Disable" to GND (I was thinking maybe the line disables the whole SFP-module and not only the TX-part), but it did not make any difference.
If someone has a suggestion (or a hint what I could try) why I am not able to access many SFPs via I2C while some work just fine, I would be grateful.
Thanks,
Mordin
PS.: apparently I am not allowed to use "sfp" as a tag ... weird
Related
I need to be able to inspect ts packets (looking at video PID 481) and determine whether the packet contains an IDR frame. My understanding is that I need to look for a NAL unit start code, and then something else after that to signify it's the start of an IDR frame. Please can someone clarify?
Here's an example of a packet that I think is an IDR frame, but need to be able to prove it from the payload data:
* Packet 2
---- TS Header ----
PID: 481 (0x01E1), header size: 12, sync: 0x47
Error: 0, unit start: 1, priority: 0
Scrambling: 0, continuity counter: 1
Adaptation field: yes (8 bytes), payload: yes (176 bytes)
Discontinuity: 1, random access: 1, ES priority: 0
PCR: 0x000000013A5
---- PES Header ----
Stream id: 0xE0 (Video 0)
PES packet length: 0 (unbounded)
---- Full TS Packet Content ----
47 41 E1 31 07 D0 00 00 00 08 7E E5 00 00 01 E0 00 00 84 C0 0A 31 00 05
E5 CD 11 00 05 AD 8D 00 00 00 01 09 10 00 00 00 01 67 64 00 29 AC D9 40
78 04 4F DE 02 94 04 04 05 00 00 03 00 01 00 00 03 00 32 E6 80 00 F4 24
00 04 F5 8A 49 30 0F 8B 16 CB 00 00 00 01 68 FA A7 CB 00 00 01 06 00 05
95 6C 60 E4 85 80 00 00 01 06 05 FF FF F5 DC 45 E9 BD E6 D9 48 B7 96 2C
D8 20 D9 23 EE EF 78 32 36 34 20 2D 20 63 6F 72 65 20 31 34 38 20 2D 20
48 2E 32 36 34 2F 4D 50 45 47 2D 34 20 41 56 43 20 63 6F 64 65 63 20 2D
20 43 6F 70 79 72 69 67 68 74 20 32 30 30 33 2D 32 30 31 36
Its not possible to tell from that packet. It is however VERY likely it is an IDR. I say its likely, because looking at the NALUs, I can see an AUD 00 00 00 01 09, an SPS 00 00 00 01 67 a PPS 00 00 00 01 68 then an SEI 00 00 01 06
The SEI however takes the remaining bytes of the packet, You will need to continue reading packets from that PID until you fine the next NALU and see if its an IDR.
I'm demuxing one program stream file and I can't figure out what one PES packet is carrying. (see picture below).
Stream ID is 0xE0, so it is a video stream. Since I'm reading a program stream file, it is the only video stream. As you can see, the packet length is 0x9C, the next byte 0x80 tells us that first two bits are '10', as expected and PES_scrambling_control, PES_priority, data_alignment_indicator, copyright and original_or_copy are all 0 (not set). The next byte 0x09 tells us that we have DSM_trick_mode_flag and PES_extension_flag set. The next byte 0x78 is PES header length. If we skip PES header, we will be at the first byte in the framed area containing 33 bytes. It begins with 00 37 B0... These 33 bytes should be skipped when demuxing, but I can't figure out why. Any comment or suggestion is very welcome.
PES packet picture
PES packet hex values as text:
00 00 01 e0 00 9c 80 09 78 00 52 40 09 ac 00 3f
40 00 22 00 d7 c0 00 e2 00 da 20 04 8a 00 62 60
02 36 00 46 10 0e a1 00 28 50 01 b9 00 d9 d0 09
cd 00 67 30 0f a3 00 44 b0 04 6b 00 8f b0 0d e7
00 64 f0 00 57 00 41 70 09 d7 00 a7 70 0d 5f 00
73 f0 0c 40 80 f8 88 00 b0 80 23 88 06 68 80 38
88 0b a8 80 be 08 07 b0 80 b3 f0 0a 10 80 67 70
08 90 80 b6 70 03 10 80 7f b0 09 00 80 f1 b0 0f
2f 00 37 b0 09 77 00 a4 70 0e 37 00 ca 70 07 47
00 b1 b0 03 33 00 3e 30 06 bd 00 77 50 05 2d 00
15 50
I sent 80 50 00 00 08 00 00 00 00 00 00 00 00 [INITILIZE UPDATE Command] via opensc-tool to my java card and received 00 00 11 60 01 00 8A 79 0A F9 FF 02 00 11 79 11 36 5D 71 00 A5 A5 EC 63 BB DC 05 CC [Init Response] as its response from the card.
As you see:
In the command,I send 00 00 00 00 00 00 00 00 as Host Challenge, And in the response :
00 00 11 60 01 00 8A 79 0A F9 = Key diversification data
FF 02 = Key information
00 11 79 11 36 5D 71 00 = Card challenge
A5 A5 EC 63 BB DC 05 CC = Card cryptogram
Now I want to check myself,if the card cryptogram is OK or not. How I can do it? for example I encrypt 00 00 00 00 00 00 00 00 in this site under a 3DES cryptography algorithm [with keys of my card = 4041...4F], but the output is not equal with card cryptogram that I wrote above. Why?
And the next question is, if I want to send EXTERNAL AUTHENTICATION command to the card, what is its data field (after the above INITILIZE UPDATE)?
Update:
This is GPJ output :
C:\Users\ghasemi\Desktop\gpj-20120310>GPJ
C:\Users\ghasemi\Desktop\gpj-20120310>java -jar gpj.jar
Found terminals: [PC/SC terminal ACS CCID USB Reader 0]
Found card in terminal: ACS CCID USB Reader 0
ATR: 3B 68 00 00 00 73 C8 40 12 00 90 00
.
.
.
DEBUG: Command APDU: 00 A4 04 00 08 A0 00 00 00 03 00 00 00
DEBUG: Response APDU: 6F 10 84 08 A0 00 00 00 03 00 00 00 A5 04 9F 65 01 FF 90 00
Successfully selected Security Domain OP201a A0 00 00 00 03 00 00 00
DEBUG: Command APDU: 80 50 00 00 08 7F 41 A9 E7 19 37 83 FA
DEBUG: Response APDU: 00 00 11 60 01 00 8A 79 0A F9 FF 02 00 1B 9B 95 B9 5E 5E BC BA 51 34 84 D9 C1 B9 6E 90 00
DEBUG: Command APDU: 84 82 00 00 10 13 3B 4E C5 2C 9E D8 24 50 71 83 3A 78 AE 75 23
DEBUG: Response APDU: 90 00
DEBUG: Command APDU: 84 82 00 00 08 13 3B 4E C5 2C 9E D8 24
DEBUG: Response APDU: 90 00
C:\Users\ghasemi\Desktop\gpj-20120310>
So :
Host_Challenge :: 7F41A9E7193783FA
Diversification_Data :: 0000116001008A790AF9
Key_Information :: FF02
Sequence_Counter :: 001B
Card_Challenge :: 9B95B95E5EBC
Card_Cryptogram :: BA513484D9C1B96E
Host_Cryptogram[16,24] = 13 3B 4E C5 2C 9E D8 24
Now,lets make our Host_Cryptogram Manually :
Derivation_data=derivation_const_ENC|sequence_counter|0000 0000 0000 0000 0000 0000
Derivation_Data = 0182001B000000000000000000000000
k_ENC :: 404142434445464748494A4B4C4D4E4F
IV = 00 00 00 00 00 00 00 00
S_ENC = encrypt(TDES_CBC, K_ENC, IV, derivation_data)
So :
I used http://tripledes.online-domain-tools.com/ and its output for above values was :
S_ENC = 448b0a5967ca246d058703ff0c694f15
And :
Padding_DES = 80 00 00 00 00 00 00 00
Host_auth_data = sequence_counter | card_challenge | host_challenge | padding_DES
IV = Card_Cryptogram :: BA513484D9C1B96E
host_cryptogram = encrypt(TDES_CBC, S_ENC, IV, host_auth_data)
So :
Host_Authentication_Data : 001B9B95B95E5EBC7F41A9E7193783FA8000000000000000
Again, I used http://tripledes.online-domain-tools.com/
and :
Host_Cryptogram : 3587b531db71ac52392493c08cff189ce7b9061029c63b62
So :
Host_Cryptogram[16,24] = e7b9061029c63b62
Why these two way [manually and GPJ output] give us two host cryptogram?
From the INITIALIZE UPDATE command you send, you get
host_challenge = 00 00 00 00 00 00 00 00
In response to the INITIALIZE UPDATE command, you get
diversification_data = 00 00 11 60 01 00 8A 79 0A F9
key_information = FF 02
sequence_counter = 00 11
card_challenge = 79 11 36 5D 71 00
card_cryptogram = A5 A5 EC 63 BB DC 05 CC
The key information indicates SCP02 (02). The key diversification data may be used to derive the card-specific K_ENC. Lets assume we have a K_ENC like this
K_ENC = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
We can then derive the session encryption key like this
derivation_const_ENC = 01 82
derivation_data = derivation_const_ENC | sequence_counter | 00 00 00 00 00 00 00 00 00 00 00 00
IV = 00 00 00 00 00 00 00 00
S_ENC = encrypt(TDES_CBC, K_ENC, IV, derivation_data)
Next, we can assemble the authentication data used to calculate the host cryptogram:
padding_DES = 80 00 00 00 00 00 00 00
host_auth_data = sequence_counter | card_challenge | host_challenge | padding_DES
Then we can use the session encryption key to encrypt the authentication data:
IV = 00 00 00 00 00 00 00 00
host_cryptogram = encrypt(TDES_CBC, S_ENC, IV, host_auth_data)
The last 8 bytes of the encrypted authentication data are the actual host cryptogram that we would send to the card:
EXTERNAL_AUTHENTICATE_data = host_cryptogram[16, 24]
Now we can assemble the EXTERNAL AUTHENTICATE command:
EXTERNAL_AUTHENTICATE = 84 82 03 00 08 | EXTERNAL_AUTHENTICATE_data
We can then calculate the S_MAC key (analoguous to getting the S_ENC above) and the MAC over that command and append it to the command data to get the full EXTERNAL AUTHENTICATE command that can be sent to the card:
EXTERNAL_AUTHENTICATE = 84 82 03 00 10 | EXTERNAL_AUTHENTICATE_data | MAC
Update
Using http://tripledes.online-domain-tools.com/ to reproduce the results of GPJ
Your K_ENC is 404142434445464748494A4B4C4D4E4F. The online tools does not properly support 2-key-3DES, so you have to convert the key into its 3-key form first:
K_ENC = 404142434445464748494A4B4C4D4E4F4041424344454647
Use this key and a zero IV to encrypt the derivation data (0182001B000000000000000000000000). You get
S_ENC = fb063cc2e17b979b10e22f82110234b4
In 3-key notation, this is
S_ENC = fb063cc2e17b979b10e22f82110234b4fb063cc2e17b979b
Use this key and a zero IV to encrypt the host authentication data (001b9b95b95e5ebc7f41a9e7193783fa8000000000000000):
HOST_CRYPTOGRAM = 773e790c91acce3167d99f92c60e2afd133b4ec52c9ed824
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
How to calculate time duration by using awk for the following file:
02 0F 00 80 C9 CD AB 00 00 48 CF 00 00 00 00 00 00 6B E7 01 07 1A 16 1B 36 00 with Timestamp2014-03-12 18:46:59.986000
02 0F 00 80 CA CD AB 00 00 48 CF 00 00 00 00 00 00 6B E7 01 07 1A 14 DB 39 00 with Timestamp2014-03-12 18:47:02.446279
02 13 23 C8 B0 CD AB 00 00 FF FF E2 75 AC 21 4E 83 00 00 01 83 6C E7 01 11 1A 36 DD 39 00 with Timestamp2014-03-12 18:47:02.455278
02 03 12 00 B0 6B E7 01 03 1A FF FF FF FF with Timestamp2014-03-12 18:47:02.457279
02 17 00 80 CB CD AB 00 00 48 CF 00 10 E2 75 AC 21 4E 83 00 00 00 00 00 00 6B E6 01 07 1A 10 9B 3D 00 with Timestamp2014-03-12 18:47:06.196279
02 10 63 C8 B1 CD AB 00 00 E2 75 AC 21 4E 83 00 00 04 6A E6 01 0F 1A 14 9D 3D 00 with Timestamp2014-03-12 18:47:06.205278
02 03 12 00 B1 6C E6 01 03 1A FF FF FF FF with Timestamp2014-03-12 18:47:06.206279
In other words, last line timestamp value minus first line timestamp values.
Is this what you want (using GNU awk for mktime())?
$ cat tst.awk
sub(/.*Timestamp/,"") {
split($0,t,/[-:. ]/)
time[++nr] = mktime(t[1]" "t[2]" "t[3]" "t[4]" "t[5]" "t[6]) "." t[7]
}
END { print time[nr] - time[1] }
$ awk -f tst.awk file
6.22028
Thanks a lot #Ed Morton; it is not working with this example:
Number of saved packets= 373
Protocol: IEEE 802.15.4
Packet #0 :02 0F 00 80 C9 CD AB 00 00 48 CF 00 00 00 00 00 00 6B E7 01 07 1A 16 1B 36 00 with Timestamp2014-03-12 18:46:59.986000
###################################################################################
Packet #1 :02 0F 00 80 CA CD AB 00 00 48 CF 00 00 00 00 00 00 6B E7 01 07 1A 14 DB 39 00 with Timestamp2014-03-12 18:47:02.446279
###################################################################################
Packet #2 :02 13 23 C8 B0 CD AB 00 00 FF FF E2 75 AC 21 4E 83 00 00 01 83 6C E7 01 11 1A 36 DD 39 00 with Timestamp2014-03-12 18:47:02.455278
###################################################################################
Packet #3 :02 03 12 00 B0 6B E7 01 03 1A FF FF FF FF with Timestamp2014-03-12 18:47:02.457279
###################################################################################
Packet #4 :02 17 00 80 CB CD AB 00 00 48 CF 00 10 E2 75 AC 21 4E 83 00 00 00 00 00 00 6B E6 01 07 1A 10 9B 3D 00 with Timestamp2014-03-12 18:47:06.196279
###################################################################################
Packet #5 :02 10 63 C8 B1 CD AB 00 00 E2 75 AC 21 4E 83 00 00 04 6A E6 01 0F 1A 14 9D 3D 00 with Timestamp2014-03-12 18:47:06.205278
###################################################################################
Packet #6 :02 03 12 00 B1 6C E6 01 03 1A FF FF FF FF with Timestamp2014-03-12 18:47:06.206279
I've installed VSS 2005 and added a VS 2008 project. If I try to open the project by choosing File --> Open Project, then selecting Source Safe on the left and navigating to the either the .sln or the .vbproj, Visual Studio instantly quits with no errors in the event log.
I tried doing a devenv /clean and then /safemode and then I get an error dialog with the following entry in the event viewer:
Event Type: Error
Event Source: Microsoft Visual Studio
Event Category: None
Event ID: 1000
Date: 7/18/2011
Time: 3:33:21 PM
User: N/A
Computer: PKCUSESBLTVPEPE
Description:
Faulting application devenv.exe, version 9.0.21022.8, stamp 47317b3d, faulting module comdlg32.dll, version 6.0.2900.5512, stamp 4802a0c9, debug? 0, fault address 0x00001ff0.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 00 70 00 70 00 6c 00 A.p.p.l.
0008: 69 00 63 00 61 00 74 00 i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00 i.o.n. .
0018: 46 00 61 00 69 00 6c 00 F.a.i.l.
0020: 75 00 72 00 65 00 20 00 u.r.e. .
0028: 20 00 64 00 65 00 76 00 .d.e.v.
0030: 65 00 6e 00 76 00 2e 00 e.n.v...
0038: 65 00 78 00 65 00 20 00 e.x.e. .
0040: 39 00 2e 00 30 00 2e 00 9...0...
0048: 32 00 31 00 30 00 32 00 2.1.0.2.
0050: 32 00 2e 00 38 00 20 00 2...8. .
0058: 34 00 37 00 33 00 31 00 4.7.3.1.
0060: 37 00 62 00 33 00 64 00 7.b.3.d.
0068: 20 00 69 00 6e 00 20 00 .i.n. .
0070: 63 00 6f 00 6d 00 64 00 c.o.m.d.
0078: 6c 00 67 00 33 00 32 00 l.g.3.2.
0080: 2e 00 64 00 6c 00 6c 00 ..d.l.l.
0088: 20 00 36 00 2e 00 30 00 .6...0.
0090: 2e 00 32 00 39 00 30 00 ..2.9.0.
0098: 30 00 2e 00 35 00 35 00 0...5.5.
00a0: 31 00 32 00 20 00 34 00 1.2. .4.
00a8: 38 00 30 00 32 00 61 00 8.0.2.a.
00b0: 30 00 63 00 39 00 20 00 0.c.9. .
00b8: 66 00 44 00 65 00 62 00 f.D.e.b.
00c0: 75 00 67 00 20 00 30 00 u.g. .0.
00c8: 20 00 61 00 74 00 20 00 .a.t. .
00d0: 6f 00 66 00 66 00 73 00 o.f.f.s.
00d8: 65 00 74 00 20 00 30 00 e.t. .0.
00e0: 30 00 30 00 30 00 31 00 0.0.0.1.
00e8: 66 00 66 00 30 00 0d 00 f.f.0...
00f0: 0a 00 ..
Has any experienced this problem before or have any solutions? Tried the usual places, but have come up empty handed so far.
Thanks!
I had the same issue and installed the VSS2005 update (available at http://www.microsoft.com/en-gb/download/details.aspx?id=291).
This resolved the issue.