SG-1000 not getting DHCP lease on WAN

[awair]

I'm in China, staying at a hotel that still has wired internet - one of the reasons I purchased the SG-1000.

The SG isn't picking up a DHCP lease.

I've tried two different cables, both work when connected directly to my PC, with full network access & Class B address assigned.

Where should I be looking, what else can I try to get the SG up and running? I've tried using the same IP/mask that were assigned to the PC, but still no traffic flows via the WAN port.

Many thanks,

[awair]

Is this related to this bug?
https://redmine.pfsense.org/issues/7532

I'm not sure if I'm reading this correctly, but is a crossover cable a possible fix?

I don't rate my chances on the hotel adjusting their infrastructure or checking cables to get this working. Would just like to know if it's worth spending any more time to get this working?

[Derelict]

First I would make sure you are actually getting link when you connect: Status > Interfaces should show status as up. Take note of the link speed lower in the status too.

You can also ifconfig cpsw0 in the shell if you are so inclined.

If you're getting link I would check the status of the dhclient request (Status > System Logs, DHCP) if you don't see anything there click on the filter icon (the funnel in the top right) and filter on process dhclient.

You should see something similar to this. See if that gives you any clues.

Mar 23 14:28:13 dhclient 79011 DHCPREQUEST on igb0 to 255.255.255.255 port 67
Mar 23 14:28:13 dhclient 79011 DHCPACK from 10.65.128.1
Mar 23 14:28:13 dhclient REBOOT
Mar 23 14:28:13 dhclient Starting add_new_address()
Mar 23 14:28:13 dhclient ifconfig igb0 inet 192.0.2.132 netmask 255.255.255.0 broadcast 192.0.2.255
Mar 23 14:28:13 dhclient New IP Address (igb0): 192.0.2.132
Mar 23 14:28:13 dhclient New Subnet Mask (igb0): 255.255.255.0
Mar 23 14:28:13 dhclient New Broadcast Address (igb0): 192.0.2.255
Mar 23 14:28:13 dhclient New Routers (igb0): 192.0.2.1
Mar 23 14:28:13 dhclient Adding new routes to interface: igb0
Mar 23 14:28:13 dhclient /sbin/route add default 192.0.2.1
Mar 23 14:28:13 dhclient Creating resolv.conf
Mar 23 14:28:13 dhclient 79011 bound to 192.0.2.132 – renewal in 43200 seconds.

Hard to say if it's a link negotiation issue but it's possible.

[SammyWoo]

@awair:

Is this related to this bug?I don't rate my chances on the hotel adjusting their infrastructure or checking cables to get this working.

U must be new in China because a famous Chinese saying translates to, "Can't do, no available solution."  which enrage most Westerners accustomed to "anything is possible."

Ya, check Link State dude. I assume this SG1000 is known to be good.

[awair]

Many thanks for the suggestions, I hadn't checked the log, but the interface was showing up. This is what I'm getting:

Time	Process	PID	Message
Dec 12 06:50:28	dhclient		FAIL
Dec 12 06:50:28	dhclient	65593	No working leases in persistent database - sleeping.
Dec 12 06:50:28	dhclient	65593	No DHCPOFFERS received.
Dec 12 06:50:21	dhclient	65593	DHCPDISCOVER on cpsw0 to 255.255.255.255 port 67 interval 7
Dec 12 06:50:11	dhclient	65593	DHCPDISCOVER on cpsw0 to 255.255.255.255 port 67 interval 10
Dec 12 06:49:58	dhclient	65593	DHCPDISCOVER on cpsw0 to 255.255.255.255 port 67 interval 13
Dec 12 06:49:47	dhclient	65593	DHCPDISCOVER on cpsw0 to 255.255.255.255 port 67 interval 11
Dec 12 06:49:41	dhclient	65593	DHCPDISCOVER on cpsw0 to 255.255.255.255 port 67 interval 6
Dec 12 06:49:37	dhclient	65593	DHCPDISCOVER on cpsw0 to 255.255.255.255 port 67 interval 4
Dec 12 06:49:33	dhclient	65593	DHCPDISCOVER on cpsw0 to 255.255.255.255 port 67 interval 4
Dec 12 06:49:29	dhclient	65593	DHCPDISCOVER on cpsw0 to 255.255.255.255 port 67 interval 4
Dec 12 06:49:27	dhclient	65593	DHCPDISCOVER on cpsw0 to 255.255.255.255 port 67 interval 2
Dec 12 06:49:12	dhclient		FAIL
Dec 12 06:49:12	dhclient	65593	No working leases in persistent database - sleeping.

I've tried most of the manual settings instead of auto-negotiation: they all show no carrier, except 10BaseT, which is what shows also on Auto.

The green light is lit on the WAN socket, with occasional activity flashing.

I'm not sure if I've ever had the SG-1000 working, as most hotels have done away with ethernet.

I've also completed a Factory Reset, with no change.

I'll check again, when I'm somewhere a bit more normal, but this is where I needed to use it for 3 days, mostly to have seamless/secure access to my servers, rather than bypass anything which is easier with a client app anyway.

The PC confirms an active 10BaseT (full duplex) connection, when connected directly using the same cable. So in some way there is an issue with the SG-1000.


[SammyWoo]

It looks good, but dealing with an unknown SG1000 and you being in a hotel means there is no extra equipment/tools to do any troubleshooting, I'd just live with Windows software firewall for a few days.

[awair]

It's not just the Firewall that I'm after. I need to connect to two private/secure servers via VPN.

pfSense sets up the routes for this, so I can use my iPad, phone(s) or computer, depending on the level of task requested. At the moment, I'm stuck at a desk, and I'd rather not be!

[JKnott]

@awair:

It's not just the Firewall that I'm after. I need to connect to two private/secure servers via VPN.

pfSense sets up the routes for this, so I can use my iPad, phone(s) or computer, depending on the level of task requested. At the moment, I'm stuck at a desk, and I'd rather not be!

Don't forget about the Great Firewall of China.  China takes a dim view of encryption.
https://www.goldenfrog.com/blog/china-blocks-openvpn-vyprvpn-remains-accessible

[awair]

Now back at home with a stable Gigabit environment & updated to 2.4.2_1…

The WAN port auto-negotiates a 1000BaseT connection, and when manually selected, a 100BaseT: but when 10baseT is selected, there is no negotiation.

Does this imply a problem with infrastructure, to with pfsense/SG1000? Where do I look further to verify this?

I would presume that if everything works at 100/1000baseT, then 10baseT should be a given.