currently I try to reimplement a C application in go. Part of the C application is to send a string to a multicast group. This produces the following packet captured via tcpdump:
00000000 d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00 |................|
00000010 ff ff 00 00 01 00 00 00 14 81 06 56 47 2c 01 00 |...........VG,..|
00000020 46 00 00 00 46 00 00 00 33 33 00 02 10 01 04 ce |F...F...33......|
00000030 ef ca fe 1a 86 dd 60 00 00 00 00 10 11 01 fe 80 |......`.........|
00000040 00 00 00 00 00 00 06 ce ef ff fe ca fe 1a ff 02 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 02 10 01 be 8f |................|
00000060 03 e9 00 10 99 68 6e 6f 64 65 69 6e 66 6f |.....hnodeinfo|
I tried to replicate the behavior with the following code:
const MultiCastGroup string = "ff02:0:0:0:0:0:2:1001"
const Port int = 1001
const Proto string = "udp6"
const MaxDataGramSize int = 8192
var announcedAddr = &net.UDPAddr{IP: net.ParseIP(MultiCastGroup), Port: Port}
buf := []byte("nodeinfo")
unicastConn, _ := net.ListenUDP(Proto, &net.UDPAddr{IP: net.IPv6zero, Port: 0})
unicastConn.WriteToUDP(buf, announcedAddr)
But the I don't think that it is working, because all I can capture from this via tcpdump is:
00000000 d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00 |................|
00000010 ff ff 00 00 01 00 00 00 |........|
00000018
It doesn't seem that the packet is even send. I tried this on a Debian Wheezy machine. Did anyone if you encounter a similar problem with golang and UDP?
Thanks in advance
Did you try to listen for it on another host?
Go (at least in 1.4) had a hard coded disable of loopback on multicast. Which means that, you can't see your own packets.
You can override this by calling setsockopt on the socket FD itself, or:
The golang.org/x/net/ipv6 library can do this for you.
Or you can take the code from Here (have to poke around to find it)
Related
I want to write to a mifare classic 4k, using the following APDU command (UPDATE BINARY):
APDU = {FF D6 00 20 10 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0Fh}
It seems fine as a get a 90 00 result...
but when i read the card back I always got the following (even with different data...):
sector: 8 (block 32), auth OK
032: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
033: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
034: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
035: 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF
where does this string D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF come from?
Note that i didn't change any setting on the card and was properly authenticated. It was a blank card and i didn't touch the trailer.
I m using a ACR122 reader (this command comes direct from the documentation of the reader...)
Ok i found my problem, i was setting the wrong size for the cbSendLength parameter in SCardTransmit.
Now i set the correct one (the whole size of the APDU command: 21) and it works fine.
Sorry.
I followed this tutorial to the letter, but I'll to explain in detail what steps I took exactly. I have an ECP5-evaluation 85k board.
I soldered bridges on R34/R35 (RX/TX) and R21 (connects LED D1 to RXD)
I used my windows installation to run the latest version of FT_PROG. In FT_PROG I went to FT_EEPROM -> Hardware Specific -> Port B -> Hardware and set it to RS232 and hit program. It completed succesfully according to the software.
Then I forwarded the USB port to my virtual box linux machine. It recognizes the board and I can succesfully run verilog files on it.
I ran ./raw_serial.sh to upload raw_serial.v to my board which is supposed to repeatedly print A to the serial monitor.
I then opened minicom on /dev/ttyUSB1 and it recognizes the device, baudrate is set correctly.
I then tried to use cu as follows: sudo chmod 666 /dev/ttyUSB1 && sudo cu -l /dev/ttyUSB2 -s 115200. It opens a terminal and says it is connected.
Led D1 is lighting up and both terminal programs indicate that the connection is succesful (I tried one of them at a time of course). Nothing is printed to the screen. When I use minicom and reupload raw_serial.v some <?> signs are printed to the screen but that's it. I tried turning echo on and off but nothing seems to work.
The following worked for me and it will probably work for others too. I'm assuming you're using openocd.
Do not use FT_PROG in windows, it doesn't seem to actually flash the FTDI chip. However, it lets you read back the hex dump that was supposed to be flashed to the chip. The hex dump for the unchanged EEPROM as it comes out of the box is as follows:
00000000 01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10 .....`..Àú....š.
00000010 AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00 ª<æ.....V.......
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 02 03 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 10 03 4C 00 61 00 ............L.a.
000000A0 74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00 t.t.i.c.e.<.L.a.
000000B0 74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00 t.t.i.c.e. .E.C.
000000C0 50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00 P.5. .E.v.a.l.u.
000000D0 61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00 a.t.i.o.n. .B.o.
000000E0 61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00 a.r.d...F.T.2.U.
000000F0 59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27 Y.T.J.V.......ü'
I just post this here for future reference, we're not going to use the stock eeprom.
We need to flash the eeprom to RS232-HS mode. To do so, we must first change the hex dump of the eeprom accordingly. To put channel B in RS232-HS mode we need to change the last column of the last row from ' to |. Create a hex file called eeprom_RS232.bin with the following contents:
00000000 01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10 .....`..Àú....š.
00000010 AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00 ª<æ.....V.......
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 02 03 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 10 03 4C 00 61 00 ............L.a.
000000A0 74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00 t.t.i.c.e.<.L.a.
000000B0 74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00 t.t.i.c.e. .E.C.
000000C0 50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00 P.5. .E.v.a.l.u.
000000D0 61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00 a.t.i.o.n. .B.o.
000000E0 61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00 a.r.d...F.T.2.U.
000000F0 59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27 Y.T.J.V.......ü|
Now, we need to flash this eeprom to our ECP5 using Anton's method. To do this, first create a file ftdi_RS232.conf with the following contents:
vendor_id=0x403
product_id=0x6010
filename="eeprom_RS232.bin"
flash_raw=true
With the following command we can flash to our ECP5: ftdi_eeprom --flash-eeprom ftdi_RS232.conf. Should we ever want to revert back to the stock eeprom, we can easily repeat this method with the hex dump given in step 1.
Now it's time to flash the verilog file. However, the device description of the ECP5 has changed from Lattice ECP5 Evaluation Board to Dual RS232-HS. We need to tell openocd to look for that specific device. Start by creating a file ecp5.cfg with the following contents:
# this supports ECP5 Evaluation Board
interface ftdi
ftdi_device_desc "Dual RS232-HS"
ftdi_vid_pid 0x0403 0x6010
# channel 1 does not have any functionality
ftdi_channel 0
# just TCK TDI TDO TMS, no reset
ftdi_layout_init 0xfff8 0xfffb
reset_config none
# default speed
adapter_khz 5000
# ECP5 device - LFE5UM5G-85F
jtag newtap ecp5 tap -irlen 8 -expected-id 0x81113043
Then, create your svf file as you usually do and flash it with the following command:
sudo --preserve-env=PATH env openocd -f ./ecp5.cfg -c "transport select jtag; init; svf raw_serial.svf; exit"
Finally, we can open a terminal to read the serial output of the ECP5. Personally, I like to use minicom: sudo chmod 666 /dev/ttyUSB0 && minicom -D /dev/ttyUSB0.
One more problem with the raw_serial.v example was that it doesn't use a baudrate of 115200 as the readme suggests but 19200. The clock that is connected to the FTDI chip runs at 12 MHz. If you want a baudrate of 115200 you need to send a bit every 12,000,000 / 115,200 ~= 104 ticks. This means you need to change line 14 to if (counter == 104) begin.
See NFC reader "SELECT (by AID)" APDU is not routed to Android device on debugging and eventual results. TL;DR the reader might simply be defunct.
I have ACR122U nfc reader. I try to run this example http://www.nfc-tools.org/index.php?title=Libnfc:APDU_example#apdu_example.c on my Ubuntu machine.
This is the log output I get when I tap my Android device (should be in HCE mode) to the reader:
./apdu_example
debug libnfc.general log_level is set to 3
debug libnfc.general allow_autoscan is set to true
debug libnfc.general allow_intrusive_scan is set to false
debug libnfc.general 0 device(s) defined by user
./apdu_example uses libnfc libnfc-1.7.1
debug libnfc.driver.acr122_usb device found: Bus 001 Device 088 Name ACS ACR122
debug libnfc.general 1 device(s) found using acr122_usb driver
debug libnfc.driver.acr122_usb 3 element(s) have been decoded from "acr122_usb:001:088"
debug libnfc.driver.acr122_usb TX: 62 00 00 00 00 00 00 01 00 00
debug libnfc.driver.acr122_usb RX: 80 02 00 00 00 00 00 00 81 00 3b 00
debug libnfc.driver.acr122_usb ACR122 PICC Operating Parameters
debug libnfc.driver.acr122_usb TX: 6f 05 00 00 00 00 00 00 00 00 ff 00 51 00 00
debug libnfc.driver.acr122_usb RX: 80 01 00 00 00 00 00 02 fe 00 00
debug libnfc.chip.pn53x GetFirmwareVersion
debug libnfc.driver.acr122_usb TX: 6f 07 00 00 00 00 00 00 00 00 ff 00 00 00 02 d4 02
debug libnfc.driver.acr122_usb RX: 80 08 00 00 00 00 00 02 fe 00 d5 03 32 01 06 07 90 00
debug libnfc.chip.pn53x SetParameters
debug libnfc.driver.acr122_usb TX: 6f 08 00 00 00 00 00 00 00 00 ff 00 00 00 03 d4 12 14
debug libnfc.driver.acr122_usb RX: 80 04 00 00 00 00 00 02 fe 00 d5 13 90 00
debug libnfc.general "ACS / ACR122U PICC Interface" (acr122_usb:001:088) has been claimed.
debug libnfc.chip.pn53x ReadRegister
debug libnfc.driver.acr122_usb TX: 6f 11 00 00 00 00 00 00 00 00 ff 00 00 00 0c d4 06 63 02 63 03 63 0d 63 38 63 3d
debug libnfc.driver.acr122_usb RX: 80 09 00 00 00 00 00 02 fe 00 d5 07 00 00 00 00 00 90 00
debug libnfc.chip.pn53x PN53X_REG_CIU_TxMode (Defines the transmission data rate and framing during transmission)
debug libnfc.chip.pn53x PN53X_REG_CIU_RxMode (Defines the transmission data rate and framing during receiving)
debug libnfc.chip.pn53x WriteRegister
debug libnfc.driver.acr122_usb TX: 6f 0d 00 00 00 00 00 00 00 00 ff 00 00 00 08 d4 08 63 02 80 63 03 80
debug libnfc.driver.acr122_usb RX: 80 04 00 00 00 00 00 02 fe 00 d5 09 90 00
debug libnfc.chip.pn53x RFConfiguration
debug libnfc.driver.acr122_usb TX: 6f 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4 32 01 00
debug libnfc.driver.acr122_usb RX: 80 04 00 00 00 00 00 02 fe 00 d5 33 90 00
debug libnfc.chip.pn53x RFConfiguration
debug libnfc.driver.acr122_usb TX: 6f 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4 32 01 01
debug libnfc.driver.acr122_usb RX: 80 04 00 00 00 00 00 02 fe 00 d5 33 90 00
debug libnfc.chip.pn53x RFConfiguration
debug libnfc.driver.acr122_usb TX: 6f 0b 00 00 00 00 00 00 00 00 ff 00 00 00 06 d4 32 05 ff ff ff
debug libnfc.driver.acr122_usb RX: 80 04 00 00 00 00 00 02 fe 00 d5 33 90 00
NFC reader: ACS / ACR122U PICC Interface opened
Polling for target...
debug libnfc.chip.pn53x ReadRegister
debug libnfc.driver.acr122_usb TX: 6f 13 00 00 00 00 00 00 00 00 ff 00 00 00 0e d4 06 63 02 63 03 63 05 63 38 63 3c 63 3d
debug libnfc.driver.acr122_usb RX: 80 0a 00 00 00 00 00 02 fe 00 d5 07 80 80 43 00 10 00 90 00
debug libnfc.chip.pn53x InListPassiveTarget
debug libnfc.chip.pn53x No timeout
debug libnfc.driver.acr122_usb TX: 6f 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4 4a 01 00
debug libnfc.driver.acr122_usb RX: 80 0e 00 00 00 00 00 02 fe 00 d5 4b 01 01 08 03 20 04 01 02 03 04 90 00
Target detected!
=> a4 04 00 07 f0 01 02 03 04 05 06 00
debug libnfc.chip.pn53x InDataExchange
debug libnfc.chip.pn53x Timeout value: 5000
debug libnfc.driver.acr122_usb TX: 6f 14 00 00 00 00 00 00 00 00 ff 00 00 00 0f d4 40 01 a4 04 00 07 f0 01 02 03 04 05 06 00
res from transceive: -6
debug libnfc.chip.pn53x InDataExchange
debug libnfc.chip.pn53x Timeout value: 5000
debug libnfc.driver.acr122_usb TX: 6f 14 00 00 00 00 00 00 00 00 ff 00 00 00 0f d4 40 01 a4 04 00 07 f0 01 02 03 04 05 06 00
Basically I can see that my Android device is seen by the reader as I can see the UID (01 02 03 04) (or another UID if I tap another device). After that transmitting select AID apdu just timeouts and I can see no relevant response in my Android logs.
On the Android device I have an application installed with the AID I am trying to select - f0 01 02 03 04 05 06.
Can this be a problem with this particular reader? There are other ADPUs which also seem to stop the reader from responding, e.g. FF 00 00 00 02 D4 04 just gives me no response. Can I diagnose the hardware somehow?
For an app that has been around for many years, and which has stored the classic Alias records in files, I like to recreate Alias files pointing to the same file now, without having to resolve the Alias first (because the destination may be unavailable at that moment).
Supposedly this should accomplish this:
CFDataRef aliasRecord = ... ; // contains the Alias Record data, see below for an example
CFURLRef url = ... ; // initialized with a file URL
CFDataRef bmData = CFURLCreateBookmarkDataFromAliasRecord (NULL, aliasRecord);
CFError error;
bool ok = CFURLWriteBookmarkDataToFile (bmData, url, 0, &error);
However, the write function fails, and the error says "The file couldn’t be saved."
If I instead create bookmark data using CreateBookmarkData, the write succeeds.
How do I make this work? I'd try writing an old style Alias file with the data in the resource fork if that wasn't so utterly deprecated.
Here's an example alias record I'd have in the aliasRecord object - I can resolve this using the classic Alias Manager FSResolveAlias function, so I know that it is indeed valid.
00 00 00 00 01 12 00 02 00 01 06 54 54 73 4D 42
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 CC 31 2F 12 48 2B 00 00 01 A5
F3 9B 03 74 6D 70 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 01 AC 1C 67 D1 FE B7 D0 00 00 00 00 00 00
00 00 FF FF FF FF 00 00 09 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 07 70 72 69 76 61 74
65 00 00 10 00 08 00 00 CC 31 12 F2 00 00 00 11
00 08 00 00 D1 FE 9B B0 00 00 00 01 00 04 01 A5
F3 9B 00 02 00 13 54 54 73 4D 42 50 3A 70 72 69
76 61 74 65 3A 00 74 6D 70 00 00 0E 00 08 00 03
00 74 00 6D 00 70 00 0F 00 0E 00 06 00 54 00 54
00 73 00 4D 00 42 00 50 00 12 00 0B 70 72 69 76
61 74 65 2F 74 6D 70 00 00 13 00 01 2F 00 FF FF
00 00
CFURLCreateBookmarkDataFromAliasRecord() doesn't create the bookmark data with the kCFURLBookmarkCreationSuitableForBookmarkFile option required by CFURLWriteBookmarkDataToFile().
CFURLCreateBookmarkDataFromAliasRecord() was intended as a way to convert alias records stored a program's own data files to bookmarks with no I/O.
Before CFURLWriteBookmarkDataToFile(), Finder Alias files (bookmark files) were created by the Finder. Those files contained an Alias resource (containing known properties that could be obtained from the Alias resource with FSCopyAliasInfo()) and icon resources. Apple needed the bookmark data in the files written by CFURLWriteBookmarkDataToFile() to provide the same properties. The kCFURLBookmarkCreationSuitableForBookmarkFile option enforces that requirement.
If you have an AliasHandle and want to create a new-style Alias file with bookmark data, you'll need to:
(1) resolve the AliasHandle to an FSRef, create a CFURLRef from the FSRef, and then create the bookmark data using the kCFURLBookmarkCreationSuitableForBookmarkFile option,
or
(2) you'll need to resolve the bookmark data created with CFURLCreateBookmarkDataFromAliasRecord(), and then create a new bookmark data using the kCFURLBookmarkCreationSuitableForBookmarkFile option.
However, you've indicated you'd like to handle this without resolving the AliasHandle, so the only solution is to create an old-style Finder Alias file. Although I know you already know how to accomplish that, it's described at How do I create a Finder alias within an application?.
The first time a user resolves/opens that old-style Alias file with the Finder, the Finder will detect the Alias file needs to be updated (i.e., CFURLCreateByResolvingBookmarkData() will return with isStale == true) and the Finder will create a new bookmark to the Alias file's target and re-write the Alias file. CFURLCreateBookmarkDataFromFile() will continue to support old-style Alias files as long as possible for backwards compatibility.
I have just started studying X86 Assembly Language.
My doubt -
When I am using the DOS DEBUG program to look at memory location, I am getting slightly different values on examining the same memory location using two different segment:offset addresses. I.e.-
Aren't D 40[0]:17 and D 41[0]:7 supposed to give exactly same output? since both of them give same address on adding segment + offset = 400+17 = 410+7 = 417H
The results which I get - (notice they are slightly different)
-D 40:17
0040:0010 00-00 00 1E 00 1E 00 0D 1C .........
0040:0020 44 20 20 39 34 05 34 05-3A 27 39 0A 0D 1C 44 20 D 94.4.:'9...D
0040:0030 20 39 34 05 30 0B 3A 27-31 02 37 08 0D 1C 00 00 94.0.:'1.7.....
0040:0040 93 00 C3 00 00 00 00 00-00 03 50 00 00 10 00 00 ..........P.....
0040:0050 00 18 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0040:0060 0F 0C 00 D4 03 29 30 00-00 00 00 00 91 DA 10 00 .....)0.........
0040:0070 00 00 00 00 00 00 08 00-14 14 14 14 01 01 01 01 ................
0040:0080 1E 00 3E 00 18 10 00 60-F9 11 0B 00 50 01 00 00 ..>....`....P...
0040:0090 00 00 00 00 00 00 10 .......
-D 41:7
0041:0000 00-00 00 2C 00 2C 00 44 20 ...,.,.D
0041:0010 20 39 34 05 31 02 3A 27-37 08 0D 1C 0D 1C 44 20 94.1.:'7.....D
0041:0020 20 39 34 05 30 0B 3A 27-31 02 37 08 0D 1C 00 00 94.0.:'1.7.....
0041:0030 08 00 C3 00 00 00 00 00-00 03 50 00 00 10 00 00 ..........P.....
0041:0040 00 18 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0041:0050 0F 0C 00 D4 03 29 30 00-00 00 00 00 1C DB 10 00 .....)0.........
0041:0060 00 00 00 00 00 00 08 00-14 14 14 14 01 01 01 01 ................
0041:0070 1E 00 3E 00 18 10 00 60-F9 11 0B 00 50 01 00 00 ..>....`....P...
0041:0080 00 00 00 00 00 00 10 .......
You are looking at the BIOS data area, whose contents changes over time since it contains things like the state of shift/control/alt keys, the read/write positions of the keyboard buffer and the timer.