date:20160829

Re: Problem using RFID reader (ucom0 at uslcom0 portno 0)

2016-08-29 Thread Martijn Rijkeboer


On 08/29/16 18:00, Remco wrote:

Op 08/29/16 om 14:28 schreef Martijn Rijkeboer:

Hi,

I'm having trouble using the Stronglink SL500 RFID reader with OpenBSD.
The SL500 is a USB based RFID reader that attaches to ucom. When I
write data to it and try to read the response, I'm often getting
wrong results. Sometimes the program even lock and unplugging the
device is the only option. I'm using the test program attached below.
This program should produce the following output (as it always does on
Linux):

$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05


When I run the program on OpenBSD-current (AMD64) I get the following:

$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
$ ./test
received: 0x0a 0xbb 0x06 0x00 0x00 0x00 0x07 0x01 0x02 0x04
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0x0a 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00
$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0x0a 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00


In the output above the first run is correct. In the second run the
first response is incorrect. In the third and fourth run the second
response is incorrect. Any suggestions what is wrong? To me it looks
like a bug in ucom or uslcom, but I could also be doing something
wrong...

I've included the test program, lsusb output and dmesg output below.


Kind regards,


Martijn Rijkeboer



Test program




O_NONBLOCK: not sure this is necessary.


The O_NONBLOCK is indeed not necessary.



Check return values, at least of read and write (EAGAIN, partial
read/write ?),
they will probably tell you what's wrong.


None of the calls returned -1, but issuing a `tcflush(fd, TCIOFLUSH)'
before sending the first data fixed the problem. Thanks for your time.

Kind regards,


Martijn Rijkeboer

Re: Problem using RFID reader (ucom0 at uslcom0 portno 0)

2016-08-29 Thread Remco


Op 08/29/16 om 14:28 schreef Martijn Rijkeboer:

Hi,

I'm having trouble using the Stronglink SL500 RFID reader with OpenBSD.
The SL500 is a USB based RFID reader that attaches to ucom. When I
write data to it and try to read the response, I'm often getting
wrong results. Sometimes the program even lock and unplugging the
device is the only option. I'm using the test program attached below.
This program should produce the following output (as it always does on
Linux):

$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05


When I run the program on OpenBSD-current (AMD64) I get the following:

$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
$ ./test
received: 0x0a 0xbb 0x06 0x00 0x00 0x00 0x07 0x01 0x02 0x04
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0x0a 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00
$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0x0a 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00


In the output above the first run is correct. In the second run the
first response is incorrect. In the third and fourth run the second
response is incorrect. Any suggestions what is wrong? To me it looks
like a bug in ucom or uslcom, but I could also be doing something
wrong...

I've included the test program, lsusb output and dmesg output below.


Kind regards,


Martijn Rijkeboer



Test program




O_NONBLOCK: not sure this is necessary.

Check return values, at least of read and write (EAGAIN, partial 
read/write ?),

they will probably tell you what's wrong.

Re: spamd question

2016-08-29 Thread Kasper Haitsma

Thanks Peter for responding.
â
The logging goes to it's own file (/var/log/spamd.log)
Indeed entries are written there for various events.
now I see GREY and WHITE records added nicely in the 5.0 spamdb.
they are syncing between each other, and the syncpackages seem to be
received by the 5.9 nodes but the 5.9 nodes do not register these records
in spamdb
- any idea why?
- any idea how to troubleshoot?

root@<5.9-1> ~# tcpdump -i bge1 port 8025
tcpdump: listening on bge1, link-type EN10MB
15:44:21.056732 <5.0-1>.spamd-sync > <5.9-1>.spamd-sync: udp 164
15:44:22.679540 <5.0-1>.spamd-sync > <5.9-1>.spamd-sync: udp 132
15:44:23.453386 <5.0-1>.spamd-sync > <5.9-1>.spamd-sync: udp 132
15:44:23.804945 <5.0-1>.spamd-sync > <5.9-1>.spamd-sync: udp 148
15:44:24.242281 <5.0-1>.spamd-sync > <5.9-1>.spamd-sync: udp 132

^C
2475 packets received by filter
0 packets dropped by kernel
root@<5.9-1> ~#

thanks


--
Date: Mon, 22 Aug 2016 16:28:06 +0200
From: "Peter N. M. Hansteen" 
To: misc@openbsd.org
Subject: Re: Fwd: spamd question
Message-ID: <20160822142804.ga...@skapet.bsdly.net>

On Mon, Aug 22, 2016 at 04:06:22PM +0200, Kasper Haitsma wrote:
> I have a question regarding the differences between spamd-
> ???sync???
> on OpenBSD 5.0 and OpenBSD 5.9.
> ??? I read this article
>  ???, but
there is
> no indication if this applies to my situation or not.

That's a commit that happened in 2008. OpenBSD 5.0 was released in 2011.

OpenBSD 5.0 has been out of support for a while, but this particular change
should
not be directly relevant to your particular upgrade scenario.

I see you start your spamds with the -v option. That means that you should
be
able to see log entries for syncs wherever your spamd is set up to log to
(check
your syslog.conf), something like

Aug 22 16:16:27 skapet spamd[65037]: new entry 216.126.230.221 from <
cbsupd...@herpprotcol.eu> to , helo reliefs.herpprotcol.eu

If you see something similar, your're good for that part at least.

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"

Problem using RFID reader (ucom0 at uslcom0 portno 0)

2016-08-29 Thread Martijn Rijkeboer


Hi,

I'm having trouble using the Stronglink SL500 RFID reader with OpenBSD.
The SL500 is a USB based RFID reader that attaches to ucom. When I
write data to it and try to read the response, I'm often getting
wrong results. Sometimes the program even lock and unplugging the
device is the only option. I'm using the test program attached below.
This program should produce the following output (as it always does on
Linux):

$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05


When I run the program on OpenBSD-current (AMD64) I get the following:

$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
$ ./test
received: 0x0a 0xbb 0x06 0x00 0x00 0x00 0x07 0x01 0x02 0x04
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0x0a 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00
$ ./test
received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05
received: 0x0a 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00


In the output above the first run is correct. In the second run the
first response is incorrect. In the third and fourth run the second
response is incorrect. Any suggestions what is wrong? To me it looks
like a bug in ucom or uslcom, but I could also be doing something
wrong...

I've included the test program, lsusb output and dmesg output below.


Kind regards,


Martijn Rijkeboer



Test program


#include 
#include 
#include 
#include 

int open_port(void) {
int fd = open("/dev/cuaU0", O_RDWR | O_NONBLOCK);  // OpenBSD
//int fd = open("/dev/ttyUSB0", O_RDWR | O_NONBLOCK);  // Linux
if (fd == -1) {
perror("can't open port");
} else {
fcntl(fd, F_SETFL, 0);
}

struct termios options;
tcgetattr(fd, );
cfsetispeed(, B19200);
cfsetospeed(, B19200);
options.c_cflag |= (CLOCAL | CREAD);
options.c_cflag &= ~CSTOPB;
cfmakeraw();
tcsetattr(fd, TCSANOW, );
return fd;
}

void send_led_green(int fd) {
unsigned char data[] = 
{0xaa,0xbb,0x06,0x00,0x00,0x00,0x07,0x01,0x02,0x04};

write(fd, data, sizeof(data));
}

void send_led_red(int fd) {
unsigned char data[] = 
{0xaa,0xbb,0x06,0x00,0x00,0x00,0x07,0x01,0x01,0x07};

write(fd, data, sizeof(data));
}

void recv_led(int fd) {
unsigned char actual[10];
read(fd, , sizeof(actual));
printf("received: ");
printf("0x%02x ", actual[0]);
printf("0x%02x ", actual[1]);
printf("0x%02x ", actual[2]);
printf("0x%02x ", actual[3]);
printf("0x%02x ", actual[4]);
printf("0x%02x ", actual[5]);
printf("0x%02x ", actual[6]);
printf("0x%02x ", actual[7]);
printf("0x%02x ", actual[8]);
printf("0x%02x ", actual[9]);
printf("\n");
}

int main() {
int fd = open_port();

send_led_green(fd);
recv_led(fd);

send_led_red(fd);
recv_led(fd);

close(fd);
}



$ lsusb
===
Bus 000 Device 001: ID 1b6f:
Bus 001 Device 001: ID 1b6f:
Bus 002 Device 001: ID 1002:
Bus 003 Device 001: ID 1002:
Bus 004 Device 001: ID 1002:
Bus 004 Device 002: ID 05ac:1006 Apple, Inc. Hub in Aluminum Keyboard
Bus 004 Device 003: ID 046d:c069 Logitech, Inc. M500 Laser Mouse
Bus 004 Device 004: ID 05ac:0221 Apple, Inc. Aluminum Keyboard (ISO)
Bus 005 Device 001: ID 1002:
Bus 006 Device 001: ID 1002:
Bus 006 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x 
UART Bridge / myAVR mySmartUSB light

Bus 007 Device 001: ID 1002:



$ lsusb -v -s 6:2
=
Bus 006 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x 
UART Bridge / myAVR mySmartUSB light

Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x10c4 Cygnal Integrated Products, Inc.
  idProduct  0xea60 CP210x UART Bridge / myAVR mySmartUSB light
  bcdDevice1.00
  iManufacturer   1 Silicon Labs
  iProduct2 CP2102 USB to UART Bridge Controller
  iSerial 3 0001
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  2 CP2102 USB to UART Bridge

Re: Installer overwrites partition table

2016-08-29 Thread Mihai Popescu

> "Assumption is the mother of all fuck ups!"
> - Steven Seagal


... you were assuming Steven Seagal said this, which is not true ...

Re: Problem using RFID reader (ucom0 at uslcom0 portno 0)

Re: Problem using RFID reader (ucom0 at uslcom0 portno 0)

Re: spamd question

Problem using RFID reader (ucom0 at uslcom0 portno 0)

Re: Installer overwrites partition table

5 matches

Site Navigation

Mail list logo

Footer information