Re: Reason for Ierrs in netstat

[Masanobu SAITOH]

Hi.

On 2018/02/22 21:18, Frank Wille wrote:

Hi,

one of our servers has some network issues. Symptoms are: Bad ping (twice
as high as comparable machines on the same net), packet loss and increasing
number of Ierrs in "netstat -i".

Is there any chance I can find out the reason behind those Ierrs?


 Currently, the is no way to figure out the reason without modifying if_wm.c


ifp->if_ierrors += 0ULL + /* ensure quad_t */
+ CSR_READ(sc, WMREG_CRCERRS)   /* CRC Error Count */
+ CSR_READ(sc, WMREG_ALGNERRC)  /* Alignment Error Count */
+ CSR_READ(sc, WMREG_SYMERRC)   /* Symbol Error Count */
+ CSR_READ(sc, WMREG_RXERRC)/* receive error Count - R/clr 
*/
+ CSR_READ(sc, WMREG_SEC)   /* Sequence Error Count */
+ CSR_READ(sc, WMREG_CEXTERR)   /* Carrier Extension Error 
Count */
+ CSR_READ(sc, WMREG_RLEC); /* Receive Length Error Count */


 The cable or switch might be bad.






I rebooted the system a few hours ago, and there are some Ierrs again
already:

tethys# netstat -i
Name  Mtu   Network   Address  Ipkts IerrsOpkts Oerrs Colls
wm0   1500  00:30:48:xx:xx:xx  2385235   714  1996966 0 0
[...]


Some more information (system ist running NetBSD/amd64 6.1.5):

wm0 at pci7 dev 0 function 0: Intel i82573E IAMT (rev. 0x03)
wm0: interrupting at ioapic0 pin 16
wm0: PCI-Express bus
wm0: 256 word (8 address bits) SPI EEPROM
wm0: Ethernet address 00:30:48:xx:xx:xx
makphy0 at wm0 phy 1: Marvell 88E Gigabit PHY, rev. 2


wm0: flags=8843 mtu 1500
 
capabilities=7ff80
 
enabled=3f80
 address: 00:30:48:xx:xx:xx
 media: Ethernet autoselect (100baseTX 
full-duplex,flowcontrol,rxpause,txpause)
 status: active
 inet 212.62.xx.xx netmask 0xfff8 broadcast 212.62.xx.xx
 inet6 fe80::230:48ff::%wm0 prefixlen 64 scopeid 0x1




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: nc -N and EOF

[Valery Ushakov]

Patrick Welche  wrote:

> I tried
> 
>   echo "hello from server" | nc -l 1234
> 
>   nc -l 1234 << EOF
>   hello from server
>   EOF
> 
>   echo "hello from server" > tmpfile
>   nc -l 1234 < tmpfile
> 
> and in all cases
> 
>   nc  -N 127.0.0.1 1234
> 
> prints "hello from server" but doesn't exit.

Use

  nc -d localhost 1234

-uwe

Re: bozohttpd

[maya]

On Wed, Feb 28, 2018 at 04:41:57PM +, Patrick Welche wrote:
> /usr/libexec/httpd -d -d -d -d -P /tmp/foo.pid -i 127.0.0.1 -b -s /var/www

works for me.

easier to debug:
 /usr/libexec/httpd -d -d -d -d -P /tmp/foo.pid -i 127.0.0.1 -b -f /var/www

bozohttpd

[Patrick Welche]

Running

/usr/libexec/httpd -d -d -d -d -P /tmp/foo.pid -i 127.0.0.1 -b -s /var/www

and fetching index.html, I see no output whatsoever. Where is it going?

 -s Forces logging to be set to stderr always.


Cheers,

Patrick

Re: nc -N and EOF

[Patrick Welche]

On Tue, Feb 27, 2018 at 09:50:34PM -0500, Eric Hawicz wrote:
> On 2018-02-27 10:33 AM, Patrick Welche wrote:
> >echo "hello from server" | nc -l 1234
> > 
> >nc -l 1234 << EOF
> >hello from server
> >EOF
> > 
> >echo "hello from server" > tmpfile
> >nc -l 1234 < tmpfile
> > 
> > and in all cases
> > 
> >nc  -N 127.0.0.1 1234
> > 
> > prints "hello from server" but doesn't exit. Maybe I'm misunderstanding
> > 
> >   -N  shutdown(2) the network socket after EOF on the input.  Some
> >   servers require this to finish their work.
> > 
> > ?
> Do you hit control-D on the client nc to give it the EOF on the input?

I was hoping to be able to script both sides, and have the file go from
the listener to the client rather than the other way around.

Patrick