Re: [Discuss-gnuradio] UDP Source Error (on windows)

2016-05-23 Thread Geof Nieboer 
Burak,

The only immediate workaround I see is to patch the source code and rebuild
using the scripts, which is likely not worth the effort for the average
user, unless it's absolutely time critical that you get this working on
windows immediately.

Otherwise I just submitted the patch to jcorgan on the windows branch so I
would prefer to wait until it's included in the next GR release then I will
update the windows installer with that new build.  Removing those two lines
of codes appear to get it to run without error, and I ran a UDP source/sink
through a simple loopback with no issues.

Geof

On Mon, May 23, 2016 at 2:09 PM, Abdil Burak BAŞLI 
wrote:

> Hi,
>
>
>
> I think this fix will be affected at the next release. Is there a
> predetermined time for the next release. Or Is there any workaround to use
> UDP source without error at v3.7.9.2.
>
>
>
> Best regards
>
> Burak.
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Source Error (on windows)

2016-05-23 Thread Abdil Burak BAŞLI 
Hi,

I think this fix will be affected at the next release. Is there a predetermined 
time for the next release. Or Is there any workaround to use UDP source without 
error at v3.7.9.2.

Best regards
Burak.


From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+abasli=havelsan.com...@gnu.org] On Behalf Of 
mle...@ripnet.com
Sent: Thursday, May 19, 2016 7:08 PM
To: Andy Walls <a...@silverblocksystems.net>
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UDP Source Error (on windows)


Not sure how this would get leveraged by itself.

But there are likely lots of kernel calls that have parameters that are ignored 
in certain contexts.  I would be astonished if a general-purpose, long-lived, 
operating existed without that being the case from time to time.






On 2016-05-19 11:58, Andy Walls wrote:



On Thu, 2016-05-19 at 11:32 -0400, mle...@ripnet.com<mailto:mle...@ripnet.com> 
wrote:
I'll comment that the Windows socket implementation isn't in
compliance with the spirit of the robustness principle.  But, whatevs.
Easy enough to just remove that option for the UDP case.

I think it's a bit of a security failing of Linux to allow injection of
4 unused bytes into the kernel space from user-space for every locally
opened UDP socket.  I'm not sure how I could exploit it (perhaps coding
a jump instruction to a no-op sled somewhere nearby?),  but I'm not that
creative.

Meh.

-Andy
Dikkat: Bu elektronik posta mesaji kisisel ve ozeldir. Eger size 
gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.Firmamiza gelen 
ve giden mesajlar virus taramasindan gecirilmektedir. Mesajdaki gorusler 
gondericiye ait olup HAVELSAN A.S. resmi gorusu olmak zorunda degildir. 
Attention: This e-mail message is private and privileged.If you are not the 
recipient for whom this e-mail message is intended, please notify the sender 
immediately and delete this e-mail message from your system.All sent and 
received e-mail messages go through a virus scan. Any opinions presented in 
this e-mail message are solely those of the author and do not necessarily 
represent HAVELSAN A.S.`s formal and authorized views.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Source Error (on windows)

2016-05-19 Thread mleech 
Not sure how this would get leveraged by itself. 

But there are likely lots of kernel calls that have parameters that are
ignored in certain contexts.  I would be astonished if a
general-purpose, long-lived, operating existed without that being the
case from time to time. 

On 2016-05-19 11:58, Andy Walls wrote:

> On Thu, 2016-05-19 at 11:32 -0400, mle...@ripnet.com wrote: 
> 
>> I'll comment that the Windows socket implementation isn't in
>> compliance with the spirit of the robustness principle.  But, whatevs.
>> Easy enough to just remove that option for the UDP case.
> 
> I think it's a bit of a security failing of Linux to allow injection of
> 4 unused bytes into the kernel space from user-space for every locally
> opened UDP socket.  I'm not sure how I could exploit it (perhaps coding
> a jump instruction to a no-op sled somewhere nearby?),  but I'm not that
> creative.
> 
> Meh.
> 
> -Andy___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Source Error (on windows)

2016-05-19 Thread Andy Walls 



On Thu, 2016-05-19 at 11:32 -0400, mle...@ripnet.com wrote:
> I'll comment that the Windows socket implementation isn't in
> compliance with the spirit of the robustness principle.  But, whatevs.
> Easy enough to just remove that option for the UDP case.
> 

I think it's a bit of a security failing of Linux to allow injection of
4 unused bytes into the kernel space from user-space for every locally
opened UDP socket.  I'm not sure how I could exploit it (perhaps coding
a jump instruction to a no-op sled somewhere nearby?),  but I'm not that
creative.

Meh.

-Andy


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Source Error (on windows)

2016-05-19 Thread mleech 
I'll comment that the Windows socket implementation isn't in compliance
with the spirit of the robustness principle.  But, whatevs.  Easy enough
to just remove that option for the UDP case. 

On 2016-05-19 08:59, Andy Walls wrote:

>> OK, I was able to reproduce the issue, and it appears to me to a core
>> GNURadio issue not specifically related to the installer
>> 
>> udp_source_impl.cc is setting the SO_LINGER option on the UDP socket,
>> which at least on Windows, causes a WSAENOPROTOOPT exception, because
>> linger doesn't really mean anything for a UDP socket.  
>> 
>> Perhaps the Linux folks can help here, but I'm guessing that this
>> option must be simply ignored on Linux so there is no error for most
>> users.  Looking at the man pages doesn't specify any particular
>> behavior required.
>> 
>> Geof
> 
> SO_LINGER gets processed by the Linux kernel generically here:
> 
> http://lxr.free-electrons.com/source/net/core/sock.c#L644
> 
> with no check against socket type.
> 
> The UDP socket handling doesn't use the resulting SOCK_LINGER flag
> setting.
> http://lxr.free-electrons.com/source/net/ipv4/udp.c
> http://lxr.free-electrons.com/source/net/ipv6/udp.c
> 
> Only TCP and the Bluetooth SCO protocol in the Linux kernel care about
> SO_LINGER.
> 
> Regards,
> Andy
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Source Error (on windows)

2016-05-19 Thread Geof Nieboer 
Thanks Andy,

I will submit a change to remove this set_option from the udp source then.

Geof

On Thu, May 19, 2016 at 3:59 PM, Andy Walls 
wrote:

> >
> > OK, I was able to reproduce the issue, and it appears to me to a core
> > GNURadio issue not specifically related to the installer
> >
> >
> > udp_source_impl.cc is setting the SO_LINGER option on the UDP socket,
> > which at least on Windows, causes a WSAENOPROTOOPT exception, because
> > linger doesn't really mean anything for a UDP socket.
> >
> >
> > Perhaps the Linux folks can help here, but I'm guessing that this
> > option must be simply ignored on Linux so there is no error for most
> > users.  Looking at the man pages doesn't specify any particular
> > behavior required.
> >
> >
> > Geof
>
>
> SO_LINGER gets processed by the Linux kernel generically here:
>
> http://lxr.free-electrons.com/source/net/core/sock.c#L644
>
> with no check against socket type.
>
> The UDP socket handling doesn't use the resulting SOCK_LINGER flag
> setting.
> http://lxr.free-electrons.com/source/net/ipv4/udp.c
> http://lxr.free-electrons.com/source/net/ipv6/udp.c
>
> Only TCP and the Bluetooth SCO protocol in the Linux kernel care about
> SO_LINGER.
>
> Regards,
> Andy
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Source Error (on windows)

2016-05-19 Thread Andy Walls 
> 
> OK, I was able to reproduce the issue, and it appears to me to a core
> GNURadio issue not specifically related to the installer
> 
> 
> udp_source_impl.cc is setting the SO_LINGER option on the UDP socket,
> which at least on Windows, causes a WSAENOPROTOOPT exception, because
> linger doesn't really mean anything for a UDP socket.  
> 
> 
> Perhaps the Linux folks can help here, but I'm guessing that this
> option must be simply ignored on Linux so there is no error for most
> users.  Looking at the man pages doesn't specify any particular
> behavior required.
> 
> 
> Geof


SO_LINGER gets processed by the Linux kernel generically here:

http://lxr.free-electrons.com/source/net/core/sock.c#L644

with no check against socket type.

The UDP socket handling doesn't use the resulting SOCK_LINGER flag
setting.
http://lxr.free-electrons.com/source/net/ipv4/udp.c
http://lxr.free-electrons.com/source/net/ipv6/udp.c

Only TCP and the Bluetooth SCO protocol in the Linux kernel care about
SO_LINGER.

Regards,
Andy


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Source Error (on windows)

2016-05-18 Thread Geof Nieboer 
OK, I was able to reproduce the issue, and it appears to me to a core
GNURadio issue not specifically related to the installer

udp_source_impl.cc is setting the SO_LINGER option on the UDP socket, which
at least on Windows, causes a WSAENOPROTOOPT exception, because linger
doesn't really mean anything for a UDP socket.

Perhaps the Linux folks can help here, but I'm guessing that this option
must be simply ignored on Linux so there is no error for most users.
Looking at the man pages doesn't specify any particular behavior required.

Geof



On Tue, May 17, 2016 at 10:29 PM, Geof Nieboer 
wrote:

> That's a new one, I will see what I can do to repro.  So the 3.6.4.1 was
> working on the same OS (2008) that 3.7.9.2 is not?
>
> On Tue, May 17, 2016 at 4:24 PM, Abdil Burak BAŞLI  > wrote:
>
>> Hi all,
>>
>>
>>
>> I successfully installed GCN Development GNURadio Win64 Binary
>> (v3.7.9.2/v1.1.1) on to the windows host machine (Windows Storage Server
>> 2012 R2 standard, as you know It is the server version of Windows 8).
>>
>> However while communicating SDR via GNURadio, UDP source gives an
>> following socket connection error:
>>
>>
>>
>> My GNURadio GRC contains following units (I also attached the grc picture
>> to the email):
>>
>>
>>
>> UDP  Source->Ishort To Complex -> WX GUI FFT Sink.
>>
>>
>>
>> The same setup works (connects and get data from SDR over UDP Source)
>> with the previous windows GNURadio installation (3.6.4.1). I installed
>> 3.6.4.1 according to following link. This version works but does not
>> contain some feature as latest does.
>>
>>
>>
>>
>> file:///D:/Downloads/GnuRadioInstall/GNURADIO%20and%20WINDOWS%20_%20Michael%20Margaras%20SV1CAL%20%E2%80%93%20Amateur%20Radio%20and%20Electronics.html
>>
>>
>>
>>
>>
>> The error GCN Development GNURadio Win64 Binary (v3.7.9.2/v1.1.1) gives
>> at below:
>>
>>
>> -
>>
>> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
>> C:\DATA\GnuUDPTransfer\Crimson_grc_src.py
>>
>>
>>
>> Using Volk machine: avx
>>
>> gr::fft: can't import wisdom from C:\UTraceback (most recent call last):
>>
>>   File "C:\DATA\GnuUDPTransfer\Crimson_grc_src.py", line 92, in 
>>
>> main()
>>
>>   File "C:\DATA\GnuUDPTransfer\Crimson_grc_src.py", line 86, in main
>>
>> tb = top_block_cls()
>>
>>   File "C:\DATA\GnuUDPTransfer\Crimson_grc_src.py", line 65, in __init__
>>
>> self.blocks_udp_source_0 = blocks.udp_source(gr.sizeof_short*2,
>> "10.10.10.10", 32820, 1400, True)
>>
>>   File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig5.py", line
>> 2260, in make
>>
>> return _blocks_swig5.udp_source_make(itemsize, host, port,
>> payload_size, eof)
>>
>> RuntimeError: set_option: An unknown, invalid, or unsupported option or
>> level was specified in a getsockopt or setsockopt call
>>
>>
>> -
>>
>>
>>
>> Any help will be appreciated.
>>
>> Best Regards,
>>
>>
>>
>> Burak.
>>
>>
>>
>>
>> Dikkat: Bu elektronik posta mesaji kisisel ve ozeldir. Eger size 
>> gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.Firmamiza 
>> gelen ve giden mesajlar virus taramasindan gecirilmektedir. Mesajdaki 
>> gorusler gondericiye ait olup HAVELSAN A.S. resmi gorusu olmak zorunda 
>> degildir. Attention: This e-mail message is private and privileged.If you 
>> are not the recipient for whom this e-mail message is intended, please 
>> notify the sender immediately and delete this e-mail message from your 
>> system.All sent and received e-mail messages go through a virus scan. Any 
>> opinions presented in this e-mail message are solely those of the author and 
>> do not necessarily represent HAVELSAN A.S.`s formal and authorized views.
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio