Why can't the computer get an ip?

Question

System administration

Hello,
We have a strange problem. I don’t know where to dig and how to test ((
Local network:
zyxel router 2 port: tp-link_1 switch - 5 pc
3 port: tp-link_2 switch - cash desk
Occasionally, but aptly, the pc cash desk cannot get ip from the router. I didn’t find patterns.
I do the same thing several times (I reconnect the lan cable, reboot the router, PC, switches) and at some point the coveted ip is received and the Internet appears. I
made a test cable from the cash register PC to a known working switch, where the Internet is, but it doesn’t help, and the lan cable blinks in full, that is, as I understand it, some kind of data transfer is going on.
This already happened half a year ago several times, but by itself the next four months did not make itself felt, now it started again ((The
router used to be tp-link now zyxel, but zyxel was installed about 2 months, and the problem appeared again a week ago
Help me figure it out Why exactly one PC refuses to receive ip?
In fact, I changed the cable, router and switch and ports in places - the problem remained and I'm confused. Maybe a network card on the PC cash desk, but I don't know how to check it and be 100% sure...

Answer 1

According to the description, the problem can be in any area - from the cash register itself to arp tables.
1) Look at the logs on the router when the cash register tries to get the address. The dhcp requests themselves and their presence in general. Better in debug mode.
2) Look at the logs on the checkout, if possible, run Wireshark (windows) or tcpdump (linux) on the checkout, saving the dump to a file. The dump itself can be viewed in Wireshark - it will be more convenient for you to view it there.
3) If neither one nor the other is possible - put any smart piece of hardware that can log forward traffic - but of course it's not a fact that you have it.
In my experience, this can be both from problems with arp tables, and to the fact that the checkout is trying to request addressing from the wrong network interface.
Trite - I will not advise updating the firmware of the router. because I think already done. Maybe there is a glitch in the firmware - "if the sun is over Egypt and it is sunny outside and a rooster crowed in the morning. then we do not give dhcp data in the next X on any of the poppies from the current date; sleep XXX; No, we changed our minds, now we give it back" - exaggerated a little but I think you get the point.
Router logs to help you !!!
Another option - when the cash register does not receive addressing, plug into the network with a cable of some kind of PC, switch the network interface to the mode of capturing all traffic and analyze it. Suddenly, some kind of shit/program/malware launches a storm over the network at startup. All PCs can handle this, but the checkout can't. The malware stops working - the network returns to normal. I had this about 8 years ago - "thanks" to the accountants. I noticed that something was clearly wrong with the entire network, and not with the PC, only when the indicators on 2 switches flashed all at the same time. I grabbed packets from the network - and there is an oil painting - G above my head.
Start with the logs of the router and the presence of requests to it. and then dig deeper.

Answer 2

1. Try to load different operating systems from a bootable flash drive (Win/Linux) on a problem PC with a cash register and disable/enable the network card programmatically - is ip allocated?
2. If you put a static ip on the problem PC under the current OS and run ping your_gateway -t, for example, are there any long pauses or breaks, how quickly is it restored?
3. If there are problems on another OS - do not spare a penny and buy an inexpensive usb-lan adapter 2.0 for example (it costs $ 3-4), check how the network works on it, maybe a network board malfunction or some kind of compatibility problem.

Answer 3

I will offer an even simpler way - instead of a cash register, connect a laptop or a known working PC and see what happens. if another device works without problems - the problem is at the checkout. if it will also be buggy - the channel or equipment.

Answer 4

Don't write a cool server for a cool game.
Write simple applications, such as chat, sea battle. Learn how to do the basics and then think about how to become a load-forecasting architect.
There is no much or little, there are specific conditions, from which they are already repelled, but it’s realistic - to assess the load, if you don’t even have a working prototype - how?

Answer 5

My opinion is that for a session with a limited number of players, take whatever you want - they don’t take a steam bath and generally didn’t make servers for some games (they have a PTP connection). Sending data 5 times per second is a very low network load.

Answer 6

Go or Java in perspective.
But it’s worth starting with a simple one, with Node.js. Experience will appear - you will already consciously decide where to go.
Nobody writes like this in C.