Apparently we should be removing trailing NULs from options whose
data are NVT ASCII strings.
Other than RFC nitpicking, Microsoft DHCP sometimes sticks those
pesky NULs in, and this breaks 'appending' values via dhclient.conf,
as the pretty print routine will stick '\000' into the generated
strin
On Mon, Jun 25, 2012 at 12:09:33AM +0300, dsp wrote:
> We observe the following behaviour when running nc -ul.
> The server begins on a recvfrom() and when data arrives it
> connects() the socket.
> When the client dies , the server remains in a connected state
> therefore ignoring subsequent data
Hey list!
We observe the following behaviour when running nc -ul.
The server begins on a recvfrom() and when data arrives it
connects() the socket.
When the client dies , the server remains in a connected state
therefore ignoring subsequent data arriving on the port.
Is this really the intended log
committed, thanks ;-)
On Sun, Jun 24, 2012 at 07:09:56PM +0200, Florian Obser wrote:
> inet_net(3) claims only AF_INET is supported for inet_net_ntop() and
> inet_net_pton().
> I take it this is no longer true since revision 1.7
> of inet_net_ntop.c and inet_net_pton.c.
>
> --- inet_net.3~
inet_net(3) claims only AF_INET is supported for inet_net_ntop() and
inet_net_pton().
I take it this is no longer true since revision 1.7
of inet_net_ntop.c and inet_net_pton.c.
--- inet_net.3~ Sun Jun 24 18:55:10 2012
+++ inet_net.3 Sun Jun 24 18:54:45 2012
@@ -84,10 +84,12 @@
as the function
On 2012-06-16 02:37:27 PM, Christiano F. Haesbaert wrote:
> I guess so, I don't use nc too often but it sounds reasonable to me,
> your code has a few notes though, please check inline.
(Sorry for the slow response, was travelling last week)
Thanks for looking at the patch - here's a new one with
Si no podes visualizar este mail, ingresa a:
http://news1.bonuscupon.com.ar/r.html?uid=1.1k.295h.rj.kdbz8mq38m
