Re: [GTALUG] Odd Ethernet Behaviour

[Alvin Starr via talk]

On 2024-02-12 23:55, Ron / BCLUG via talk wrote:
[snip]

This is a risk unaware Microsoft centric answer.


It's a "Why are there incoming connections to our network?!? And what 
is their purpose? And where do they end up? Who is controlling them?" 
issue.


Imagine being in charge of a large network and seeing countless 
connections to end points inside the network and having no idea what 
they're doing - that *should* scare any IT / network admin.

You are right.
There is a lot to be said for a single point of control.

Complaints about using a VPN make me think of the times when I have had 
use VPNs that forced me to have a separate windows PC.
Its less of a problem now because more and more places have VPNs that 
have Linux clients but that was not always the case, and I found the VPN 
support in organizations that were that windows centric, terrible.


I did have one client a couple of years ago who could not get the linux 
client for their VPN to work and eventually I had to bounce through 2 
web based console apps to get access.
I was allowed to setup an SSH back link to my network where I could then 
sign into the systems.






And this is not just a government issue its a big company based issue.


Yup, agreed 100%.


My personal belief is that companies believe that if they pay for the 
service then they have someone they can sue if things go wrong.
Look at the recent set of remote access and data migration products 
that have had VERY large corporate and government customers and big 
security breaches.


And suing after the fact accomplishes pretty much nothing. Data is 
"gone", reputation is ruined, time is wasted recovering, etc.
The desire to feel that you have someone you can hold accountable has 
just about 0 correlation with the actual ability to hold them accountable.





It's more like, "here's a product we trust to manage incoming 
connections, and if everyone's using this then we can control our 
network much better".


Whether the trust is misplaced or not in any specific product, the 
idea is valid.

There was once a saying.
"Nobody ever got fired for buying IBM".
I think that moved to Cisco some years ago and now I think it can be 
used with AWS.


[snip]

--
Alvin Starr   ||   land:  (647)478-6285
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||

---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Odd Ethernet Behaviour

[David Collier-Brown via talk]

Have a look at tailscale, which I looked at a few years back when 
dealing with a similar IT operation. It looked like a resolution, but 
fortunately I was offered a new job elsewhere.


--dave

On 2024-02-13 02:06, William Park via talk wrote:
Why not comply and install VPN?  I face the same issue at my company, 
and that's how I work from home.  Fortunately, they allow VM.


On 2024-02-12 20:22, Peter King via talk wrote:
Honestly, I won’t do that.  About three weeks ago I had gotten 
approval for a new static ip address, at which point I asked for them 
to allow me to ssh to that address.  I was *refused* and told I had 
to use a VPN because they “have to protect shh from the internet.”  
(!!!)


An IT department that thinks ssh needs to be protected is not a 
department you want to deal with, ever.


If I ask them about bandwidth I fear they will take away ssh access 
from the address I already had.


Yes, this is what your tax dollars pay for.

Sent from my iPad

---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list 
https://gtalug.org/mailman/listinfo/talk

---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Odd Ethernet Behaviour

[William Park via talk]

Why not comply and install VPN?  I face the same issue at my company, 
and that's how I work from home.  Fortunately, they allow VM.


On 2024-02-12 20:22, Peter King via talk wrote:

Honestly, I won’t do that.  About three weeks ago I had gotten approval for a 
new static ip address, at which point I asked for them to allow me to ssh to 
that address.  I was *refused* and told I had to use a VPN because they “have 
to protect shh from the internet.”  (!!!)

An IT department that thinks ssh needs to be protected is not a department you 
want to deal with, ever.

If I ask them about bandwidth I fear they will take away ssh access from the 
address I already had.

Yes, this is what your tax dollars pay for.

Sent from my iPad

---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Odd Ethernet Behaviour

[Ron / BCLUG via talk]

Alvin Starr via talk wrote on 2024-02-12 20:38:

Honestly, I won’t do that.  About three weeks ago I had gotten 
approval for a new static ip address, at which point I asked for them 
to allow me to ssh to that address.  I was *refused* and told I had to 
use a VPN because they “have to protect shh from the internet.”  (!!!)


So, why not set up a VPN?



This is a risk unaware Microsoft centric answer.


It's a "Why are there incoming connections to our network?!? And what is 
their purpose? And where do they end up? Who is controlling them?" issue.


Imagine being in charge of a large network and seeing countless 
connections to end points inside the network and having no idea what 
they're doing - that *should* scare any IT / network admin.




And this is not just a government issue its a big company based issue.


Yup, agreed 100%.


My personal belief is that companies believe that if they pay for the 
service then they have someone they can sue if things go wrong.
Look at the recent set of remote access and data migration products that 
have had VERY large corporate and government customers and big security 
breaches.


And suing after the fact accomplishes pretty much nothing. Data is 
"gone", reputation is ruined, time is wasted recovering, etc.



It's more like, "here's a product we trust to manage incoming 
connections, and if everyone's using this then we can control our 
network much better".


Whether the trust is misplaced or not in any specific product, the idea 
is valid.




But seriously if you can find a service that they will port forward to 
your computer you can then just put SSH on that port and have your access.


Doubtful that IT is going to assist with port forwarding or any method 
of allowing un-monitored and unfettered incoming connections.


Better would be to:

a) install a VPN like IT said
b) use ssh to connect to an outside computer with reverse-tunnelling (I 
forget the term here) and go in through the outside computer



My 2¢

rb

---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Odd Ethernet Behaviour

[Alvin Starr via talk]

On 2024-02-12 20:22, Peter King via talk wrote:

Honestly, I won’t do that.  About three weeks ago I had gotten approval for a 
new static ip address, at which point I asked for them to allow me to ssh to 
that address.  I was *refused* and told I had to use a VPN because they “have 
to protect shh from the internet.”  (!!!)

This is a risk unaware Microsoft centric answer.
And this is not just a government issue its a big company based issue.

My personal belief is that companies believe that if they pay for the 
service then they have someone they can sue if things go wrong.
Look at the recent set of remote access and data migration products that 
have had VERY large corporate and government customers and big security 
breaches.



SSH is free. How can you trust something that is free.

But seriously if you can find a service that they will port forward to 
your computer you can then just put SSH on that port and have your access.


You should take a look at iperf as a network testing tool.
It does require a server you can connect to but it will give you better 
information than the usual web based speed test tools.




An IT department that thinks ssh needs to be protected is not a department you 
want to deal with, ever.

If I ask them about bandwidth I fear they will take away ssh access from the 
address I already had.

Yes, this is what your tax dollars pay for.

Sent from my iPad


On Feb 12, 2024, at 6:43 PM, Ron / BCLUG via talk  wrote:

Peter King via talk wrote on 2024-02-12 13:56:


Ethtool says the new card is running at 1000Mb/s.

That's the link speed, not necessarily reflective of the bandwidth provided by 
upstream.



A different computer behind the same switch (which claims to have gigabit 
ethernet: TP-Link AC1750) also gets those upload and download speeds.
It is, of course, possible that the UofT has throttled my bandwidth, or the 
bandwidth to the building I am located in.

That's where my suspicion immediately goes (or the switch itself if not the 
building).


Maybe open a ticket with support as a next step?  They ought to be able to 
clarify what speed you should be getting.


rb
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


--
Alvin Starr   ||   land:  (647)478-6285
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||

---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Odd Ethernet Behaviour

[Peter King via talk]

Honestly, I won’t do that.  About three weeks ago I had gotten approval for a 
new static ip address, at which point I asked for them to allow me to ssh to 
that address.  I was *refused* and told I had to use a VPN because they “have 
to protect shh from the internet.”  (!!!)

An IT department that thinks ssh needs to be protected is not a department you 
want to deal with, ever.

If I ask them about bandwidth I fear they will take away ssh access from the 
address I already had.

Yes, this is what your tax dollars pay for.

Sent from my iPad

> On Feb 12, 2024, at 6:43 PM, Ron / BCLUG via talk  wrote:
>
> Peter King via talk wrote on 2024-02-12 13:56:
>
>> Ethtool says the new card is running at 1000Mb/s.
>
> That's the link speed, not necessarily reflective of the bandwidth provided 
> by upstream.
>
>
>> A different computer behind the same switch (which claims to have gigabit 
>> ethernet: TP-Link AC1750) also gets those upload and download speeds.
>
>> It is, of course, possible that the UofT has throttled my bandwidth, or the 
>> bandwidth to the building I am located in.
>
> That's where my suspicion immediately goes (or the switch itself if not the 
> building).
>
>
> Maybe open a ticket with support as a next step?  They ought to be able to 
> clarify what speed you should be getting.
>
>
> rb
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Odd Ethernet Behaviour

[Ron / BCLUG via talk]

Peter King via talk wrote on 2024-02-12 13:56:


Ethtool says the new card is running at 1000Mb/s.


That's the link speed, not necessarily reflective of the bandwidth 
provided by upstream.



A different computer behind the same switch (which claims to have 
gigabit ethernet: TP-Link AC1750) also gets those upload and download 
speeds.


It is, of course, possible that the UofT has throttled my bandwidth, or 
the bandwidth to the building I am located in.


That's where my suspicion immediately goes (or the switch itself if not 
the building).



Maybe open a ticket with support as a next step?  They ought to be able 
to clarify what speed you should be getting.



rb
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Odd Ethernet Behaviour

[Peter King via talk]

Well, the first thing I did was take Lennart's advice, because it's 
always good.  I got a NIC with an intel chipset and installed it.  No 
difference.


Tried a different switch port, no difference.  Switched up to Cat 6 
cable, no difference.


Ethtool says the new card is running at 1000Mb/s.

Speedtest-cli says I get just shy of 100Mb/s upload and download.

A different computer behind the same switch (which claims to have 
gigabit ethernet: TP-Link AC1750) also gets those upload and download 
speeds.


On another computer at the UofT, in another building, I get just about 
gigabit ethernet upload and download.  So it isn't a general problem.


When I get more time I will try fooling around with autonegotiation.

It is, of course, possible that the UofT has throttled my bandwidth, or 
the bandwidth to the building I am located in.




On 2/6/24 20:23, David Thornton via talk wrote:

I love problems like this. Puzzles.

1. You might try turning off auto negotiation and "forcing" the link 
to various speeds and see how it responds, and not just the fastest 
speed. ( 
https://phoenixnap.com/kb/ethtool-command-change-speed-duplex-ethernet-card-linux 
) 



2. Try a different switch port.

3. Check the switch's tx/rx error rates & retransmissions.

4. Check the NIC's tx/rx error rates & retransmissions.

5. Compare speed with something "link local", like _on the same 
ethernet segment_ , versus something past the gateway.


6. Compare trace routes into the device from various places, to trace 
route from the device _to_ those various places. There may be some 
asymmetry going on.


David

p.s. for seeing network stuff I like iptraf , and iptraf-ng


On Tue, Feb 6, 2024 at 8:08 PM Peter King via talk  
wrote:


Hello all,

I have a computer located in the University of Toronto network
which shows some odd network behaviour.  For one, I have run
speedtest-cli on it numerous times at various times of the day,
and it consistently returns around 93Mbit upload/download.  For
comparison, a laptop in the same LAN seems to get 700Mbit, while a
computer in a different part of the UofT network gets 900Mb/570Mb.

The NIC has a RealTek chip and uses the r8169 kernel module. 
Ethtool, which gives a live report, does list the card as running
at 1Gb/s.  But that sure isn't the speed I am getting.

This same slow computer also has problems if I reboot it remotely:
most of the time it doesn't come up, though dmesg has the card
detected.  If I start from a cold boot rather than restart, it
comes up correctly most of the time.  In either case just typing
in #netctl start  starts it up just fine.  I was trying
to solve this problem and saw that there are several complaints
along just these lines having to do with the r8169 module.  Some
people suggested downgrading to r8101 but that module is even older.

If the module isn't working well, that might account for the
slower speeds.

Is there any way to tell?  Obviously I can buy another NIC with a
different chipset but don't really want to go to the trouble if
there is an easier way to diagnose the difficulties.

All advice appreciated!  Thanks.

-- 
Peter King			 	peter.k...@utoronto.ca

Department of Philosophy
170 St. George Street #521
The University of Toronto  (416)-946-3170 ofc
Toronto, ON  M5R 2M8
CANADA

http://individual.utoronto.ca/pking/

=
GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC  36F5 1FE6 D32A 7587 EC42)
gpg --keyserverpgp.mit.edu  

  --recv-keys 7587EC42

---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list
https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Odd Ethernet Behaviour

[Lennart Sorensen via talk]

On Tue, Feb 06, 2024 at 07:58:40PM -0500, Peter King via talk wrote:
> Hello all,
> 
> I have a computer located in the University of Toronto network which shows
> some odd network behaviour.  For one, I have run speedtest-cli on it
> numerous times at various times of the day, and it consistently returns
> around 93Mbit upload/download.  For comparison, a laptop in the same LAN
> seems to get 700Mbit, while a computer in a different part of the UofT
> network gets 900Mb/570Mb.
> 
> The NIC has a RealTek chip and uses the r8169 kernel module.  Ethtool, which
> gives a live report, does list the card as running at 1Gb/s.  But that sure
> isn't the speed I am getting.
> 
> This same slow computer also has problems if I reboot it remotely: most of
> the time it doesn't come up, though dmesg has the card detected.  If I start
> from a cold boot rather than restart, it comes up correctly most of the
> time.  In either case just typing in #netctl start  starts it up
> just fine.  I was trying to solve this problem and saw that there are
> several complaints along just these lines having to do with the r8169
> module.  Some people suggested downgrading to r8101 but that module is even
> older.
> 
> If the module isn't working well, that might account for the slower speeds.
> 
> Is there any way to tell? Obviously I can buy another NIC with a different
> chipset but don't really want to go to the trouble if there is an easier way
> to diagnose the difficulties.
> 
> All advice appreciated! Thanks.

Well if you search for it you will find well over a decade of people
complaining about bed throughput on that chip.  Some people claim it
is a problem with the power management in the driver.  I even saw one
claiming a recent 6.5 kernel has finally fixed the performance for them.

I remember the dlink DGE530T used to be popular because it used a marvell
yukon chip with great performance (codeveloped with 3com).  Then rev C1
came out.  Same model name, same packaging, revision only difference.
Used a rebranded realtek 8169.  Different driver, much worse performance.
Many people stopped specing the 530T since it went from good to garbage
because someone made a cost saving revision.  I remember it well, and
not in a good way.  I suggest finding another network card.  Cards with
an intel chip usually behave well.

commit 93a3aa25933461d76141179fc94aa32d5f9d954a
Author: Lennart Sorensen 
Date:   Thu Jul 28 13:18:11 2011 +

r8169: Add support for D-Link 530T rev C1 (Kernel Bug 38862)

The D-Link DGE-530T rev C1 is a re-badged Realtek 8169 named DLG10028C,
unlike the previous revisions which were skge based.  It is probably
the same as the discontinued DGE-528T (0x4300) other than the PCI ID.

The PCI ID is 0x1186:0x4302.

Adding it to r8169.c where 0x1186:0x4300 is already found makes the card
be detected and work.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=38862

Signed-off-by: Len Sorensen 
Signed-off-by: David S. Miller 

-- 
Len Sorensen
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Odd Ethernet Behaviour

[David Thornton via talk]

I love problems like this. Puzzles.

1. You might try turning off auto negotiation and "forcing" the link to
various speeds and see how it responds, and not just the fastest speed. (
https://phoenixnap.com/kb/ethtool-command-change-speed-duplex-ethernet-card-linux
)

2. Try a different switch port.

3. Check the switch's tx/rx error rates & retransmissions.

4. Check the NIC's tx/rx error rates  & retransmissions.

5. Compare speed with something "link local", like _on the same ethernet
segment_ , versus something past the gateway.

6. Compare trace routes into the device from various places, to trace route
from the device _to_ those various places. There may be some
asymmetry going on.

David

p.s. for seeing network stuff I like iptraf , and iptraf-ng


On Tue, Feb 6, 2024 at 8:08 PM Peter King via talk  wrote:

> Hello all,
>
> I have a computer located in the University of Toronto network which shows
> some odd network behaviour.  For one, I have run speedtest-cli on it
> numerous times at various times of the day, and it consistently returns
> around 93Mbit upload/download.  For comparison, a laptop in the same LAN
> seems to get 700Mbit, while a computer in a different part of the UofT
> network gets 900Mb/570Mb.
>
> The NIC has a RealTek chip and uses the r8169 kernel module.  Ethtool,
> which gives a live report, does list the card as running at 1Gb/s.  But
> that sure isn't the speed I am getting.
>
> This same slow computer also has problems if I reboot it remotely: most of
> the time it doesn't come up, though dmesg has the card detected.  If I
> start from a cold boot rather than restart, it comes up correctly most of
> the time.  In either case just typing in #netctl start  starts it
> up just fine.  I was trying to solve this problem and saw that there are
> several complaints along just these lines having to do with the r8169
> module.  Some people suggested downgrading to r8101 but that module is even
> older.
>
> If the module isn't working well, that might account for the slower speeds.
>
> Is there any way to tell?  Obviously I can buy another NIC with a
> different chipset but don't really want to go to the trouble if there is an
> easier way to diagnose the difficulties.
>
> All advice appreciated!  Thanks.
>
> --
> Peter Kingpeter.k...@utoronto.ca
> Department of Philosophy
> 170 St. George Street #521
> The University of Toronto(416)-946-3170 ofc
> Toronto, ON  M5R 2M8
>CANADA
> http://individual.utoronto.ca/pking/
>
> =
> GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC  36F5 1FE6 D32A 7587 EC42)
> gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
>
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list
> https://gtalug.org/mailman/listinfo/talk
>


-- 
David Thornton
https://wiki.quadratic.net
https://github.com/drthornt/
https://twitter.com/northdot9/
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Odd Ethernet Behaviour

[James Knott via talk]

On 2/6/24 19:58, Peter King via talk wrote:

All advice appreciated!


Check the cable.  If it's flakey, to use the technical term, it may work 
at only 10 or 100 Mb.  However, negotiation takes place at 10 Mb, so the 
NIC thinks it has a good connection.


---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

[GTALUG] Odd Ethernet Behaviour

[Peter King via talk]

Hello all,

I have a computer located in the University of Toronto network which 
shows some odd network behaviour.  For one, I have run speedtest-cli on 
it numerous times at various times of the day, and it consistently 
returns around 93Mbit upload/download.  For comparison, a laptop in the 
same LAN seems to get 700Mbit, while a computer in a different part of 
the UofT network gets 900Mb/570Mb.


The NIC has a RealTek chip and uses the r8169 kernel module.  Ethtool, 
which gives a live report, does list the card as running at 1Gb/s.  But 
that sure isn't the speed I am getting.


This same slow computer also has problems if I reboot it remotely: most 
of the time it doesn't come up, though dmesg has the card detected.  If 
I start from a cold boot rather than restart, it comes up correctly most 
of the time.  In either case just typing in #netctl start  
starts it up just fine.  I was trying to solve this problem and saw that 
there are several complaints along just these lines having to do with 
the r8169 module.  Some people suggested downgrading to r8101 but that 
module is even older.


If the module isn't working well, that might account for the slower speeds.

Is there any way to tell? Obviously I can buy another NIC with a 
different chipset but don't really want to go to the trouble if there is 
an easier way to diagnose the difficulties.


All advice appreciated! Thanks.

--
Peter King  peter.k...@utoronto.ca
Department of Philosophy
170 St. George Street #521
The University of Toronto  (416)-946-3170 ofc
Toronto, ON  M5R 2M8
   CANADA

http://individual.utoronto.ca/pking/

=
GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC  36F5 1FE6 D32A 7587 EC42)
gpg --keyserver pgp.mit.edu --recv-keys 7587EC42



OpenPGP_0x1FE6D32A7587EC42.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk